Over a million developers have joined DZone.

Change the Studio Category of your DevKit Component

DZone's Guide to

Change the Studio Category of your DevKit Component

· Integration Zone ·
Free Resource

Discover how you can get APIs and microservices to work at true enterprise scale.

Anyone that has used DevKit to write a Mule extension and then wanted to add it to Studio, may have notice that the extension will appear under the Cloud Connectors category in the palette. This is not a problem when the extension is actually a Cloud Connector, but is sort of a problem when it was something else (for example a component like the LDAP connector). This is not an issue anymore since DevKit 3.3.2, as you can now use the @Category annotation at class definition level (Connector or Module) to select under which category you want your extension to be listed in:

@Connector(name = "ldap", schemaVersion = "3.4", friendlyName="LDAP", minMuleVersion="3.4", description="LDAP Connector that allows you to connect to any LDAP server and perform every LDAP operation")
@Category(name = "org.mule.tooling.category.core", description = "Components")
public class LDAPConnector

It is important to mention that:

  • You can only add the connector to one of the existing Studio categories (this means you cannot define your own category)
  • The values for name and description attributes of @Category need to have specific values (please don’t be creative), as shown in the following list:
    • Endpoints: org.mule.tooling.category.endpoints
    • Scopes: org.mule.tooling.category.scopes
    • Components: org.mule.tooling.category.core
    • Transformers: org.mule.tooling.category.transformers
    • Filters: org.mule.tooling.category.filters
    • Flow Control: org.mule.tooling.category.flowControl
    • Error Handling: org.mule.tooling.ui.modules.core.exceptions
    • Cloud Connectors (DEFAULT): org.mule.tooling.category.cloudconnector
    • Miscellaneous: org.mule.tooling.ui.modules.core.miscellaneous
    • Security: org.mule.tooling.category.security

Too ‘meh’ to build the category annotation yourself? Just copy/paste from the following gist:

import org.mule.api.annotations.Category;

// Endpoint
@Category(name = "org.mule.tooling.category.endpoints", description = "Endpoints")

// Scope
@Category(name = "org.mule.tooling.category.scopes", description = "Scopes")

// Component
@Category(name = "org.mule.tooling.category.core", description = "Components")

// Transformer
@Category(name = "org.mule.tooling.category.transformers", description = "Transformers")

// Filters
@Category(name = "org.mule.tooling.category.filters", description = "Filters")

// Flow Control
@Category(name = "org.mule.tooling.category.flowControl", description = "Flow Control")

// Error Handling
@Category(name = "org.mule.tooling.ui.modules.core.exceptions", description = "Error Handling")

// Cloud Connectors
@Category(name = "org.mule.tooling.category.cloudconnector", description = "Cloud Connectors")

// Miscellaneous
@Category(name = "org.mule.tooling.ui.modules.core.miscellaneous", description = "Miscellaneous")

// Security
@Category(name = "org.mule.tooling.category.security", description = "Security")

Hope this tip helps you place your Mule extensions under the right Studio category.

Related posts:

  1. Mule School: Invoking component methods using Entry Point Resolvers
  2. Mule Component Bindings
  3. Extending Mule with DevKit – the LDAPConnector
  4. Mule School: Invoking Java Component over HTTP


APIs and microservices are maturing, quickly. Learn what it takes to manage modern APIs and microservices at enterprise scale.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}