2014-11-07

Apache Camel please explain me what these endpoint options mean

In the upcoming Apache Camel 2.15, we have made Camel smarter. It is now able to act as a teacher and explain to you how its configured and what those options mean.

The first lesson Camel can do is to tell you how all the endpoints have been configured and what these option mean.

Lessons we are working on next is to let Camel explain the options for the EIPs are.

Okay a picture is worth a thousand words, so let me show a screenshot from Apache Karaf, where you can use the new endpoint-explain command to explain how the endpoints have been configured.


The screenshot from Apache is from the SQL example which I have installed in Karaf. This example uses a number of endpoints, and among those a timer to trigger every 5 seconds. As you can see from above, the command list the endpoint uri: timer://foo?period=5s and then explain the option(s) below. As the uri only has 1 option, there is only one listed. We can see that the option is named period. Its java type is a long. The json schema type is integer. We can see the value is 5s, and below the description which explains what the value does.
So why is there two types listed? The idea is that there is a type that is suitable for tooling etc, as it has a simpler category of types accordingly to the JSonSchema specification. The actual type in Java is listed as well.
The timer endpoint has many more options, so we can use the --verbose option to list all the options, as shown below:


The explain endpoint functionality is also available as JMX or as Java API on the CamelContext. For JMX each endpoint mbean has an explain operation that returns a tabular data with the data as above. This is illustrated in the screenshot below from jconsole:


In addition there is a generic explainEndpointJson operation on the CamelContext MBean, this allows to explain any arbitrary uri that is provided. So you can explain endpoints that are not in use by Camel.

So how does this works?

During the built of the Apache Camel release, for each component we generate a HTML and JSon schema where each endpoint option is documented with their name, type, and description. And for enums we list the possible values.

Here is an example of such a json schema for the camel-sql component:



Now for this to work, the component must support the uri options, which requires to annotation the endpoint with the @UriEndpoint. Though the Camel team has not migrated all the 160+ components in the Camel release yet. But we plan to migrate the components over time.

And certainly now where we have this new functionality, it encourages us to migrate all the components.

So where do we get the documentation? Well its just java code, so all you have to do is to have getter/setter for an endpoint option. Add the @UriParam annotation, and for the setter you just add javadoc. Yes we grab the javadoc as the documentation. So its just documented in one place and its in the source code, as standard javadoc.
I hope we in the future can auto generate the Camel website documentation for the components, so we do not have to maintain that separately in its wiki system. But that would take hard work to implement. But eventually we should get there, so every component is documented in the source code. For example we could have a readme.md for each component that has all the component documentation, and then the endpoint options is injected from the Camel built system into that readme.md file automatic. Having readme.md files also allow github users to browse the Camel component documentation nicely using github style ;o

So what is next?

The hawtio web console will integrate this as well, so users with Camel 2.15 onwards have that information in the web console out of the box.

And then its onwards to include documentation about the EIP in the XML schemas for Spring/Blueprint users. And improve the javadoc for the EIPs, as that then becomes the single source of documentation as well. This then allows tooling such as Eclipse / IDEA / Netbeans and whatnot to show the documentation when people develop their Camel routes in the XML editor, as the documentation is provided in the XSD as xsd:documentation tags.

We have captured some thoughts what else to do in the CAMEL-7999 ticket. If you have any ideas what else to improve or whatnot, then we love feedback from the community.


8 comments:

dantheperson said...

How far away is 2.15?

Claus Ibsen said...

End of Q1 2015 is our current target.

dennisk1718 said...

Awesome!

Alexandre Estela said...

Hi Claus,

How do you generate the HTML/JSON schema to document an endpoint? You also mention generating Javadoc, but how does that use the @UriEndpoint and @UriParam? Is there a specific Camel tool?

I tried using the camel-package-maven-plugin as stated in http://camel.apache.org/endpoint-annotations.html but the 2 goals I found did not generate much :)

Any insight appreciated!

Alex

Claus Ibsen said...

Alex, see how we do it in camel-labs where you need to have camel-apt on classpath and the other plugin to generate the component list file. The former is for the json, and the latter is for component.properties.

https://github.com/camel-labs/camel-labs/blob/master/iot/components/pom.xml

Alexandre Estela said...

Hi Claus,

Thanks for the guidelines; could you please be more precise on how to use camel-apt to generate the json? While looking at the sources I am still missing something here.

Alex

Alexandre Estela said...

Claus,

Sorry for my last comment, I missed the generated json and html files next to the class files :) thanks again for your support!

Alex

Claus Ibsen said...

Good to know. Yeah just including camel-apt should be enough and the java compiler will use it.