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

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



Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}