Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

53.2. How to use the Framework

Overview
링크 복사

The procedure for implementing a component using the API framework involve a mixture of automated code generation, implementing Java code, and customizing the build, by editing Maven POM files. FIG gives an overview of this development process.

Figure 53.1. Using the API Component Framework

Figure showing the parts of an API component implementation
View larger image
Figure showing the parts of an API component implementation

Java API
링크 복사

The starting point for your API component is always a Java API. Generally speaking, in the context of Camel, this usually means a Java client API, which connects to a remote server endpoint. The first question is, where does the Java API come from? Here are a few possibilities:
  • Implement the Java API yourself (though this typically would involve a lot of work and is generally not the preferred approach).
  • Use a third-party Java API. For example, the Apache Camel Box component is based on the third-party Box Java SDK library.
  • Generate the Java API from a language-neutral interface. For example, the Apache Camel LinkedIn component obtains its Java API by converting a WADL description of its REST services to Java (using the Apache CXF wadl2java tool).

Javadoc metadata
링크 복사

You have the option of providing metadata for the Java API in the form of Javadoc (which is needed for generating code in the API component framework). If you use a third-party Java API from a Maven repository, you will usually find that the Javadoc is already provided in the Maven artifact. But even in the cases where Javadoc is not provided, you can easily generate it, using the maven-javadoc-plugin Maven plug-in.
Note
Currently, there is a limitation in the processing of Javadoc metadata, such that generic nesting is not supported. For example, java.util.List<String> is supported, but java.util.List<java.util.List<String>> is not. The workaround is to specify the nested generic type as java.util.List<java.util.List> in a signature file.

Signature file metadata
링크 복사

If for some reason it is not convenient to provide Java API metadata in the form of Javadoc, you have the option of providing metadata in the form of signature files. The signature files consist of a list of method signatures (one method signature per line). These files can be created manually and are needed only at build time.
Note the following points about signature files:
  • You must create one signature file for each proxy class (Java API class).
  • The method signatures must not include a raises clause. All exceptions raised at runtime are wrapped in a RuntimeCamelException and returned from the endpoint.
  • Class names that specify the type of an argument must be fully-qualified class names (except for the java.lang.* types). There is no mechanism for importing package names.
  • Currently, there is a limitation in the signature parser, such that generic nesting is not supported. For example, java.util.List<String> is supported, whereas java.util.List<java.util.List<String>> is not. The workaround is to specify the nested generic type as java.util.List<java.util.List>.
The following shows a simple example of the contents of a signature file: 
public String sayHi();
public String greetMe(String name);
public String greetUs(String name1, String name2);
Copy to Clipboard Toggle word wrap

Generate starting code with the Maven archetype
링크 복사

The easiest way to get started developing an API component is to generate an initial Maven project using the camel-archetype-api-component Maven archetype. For details of how to run the archetype, see Section 54.1, “Generate Code with the Maven Archetype”.
After you run the Maven archetype, you will find two sub-projects under the generated ProjectName directory:
ProjectName-api
This project contains the Java API, which forms the basis of the API component. When you build this project, it packages up the Java API in a Maven bundle and generates the requisite Javadoc as well. If the Java API and Javadoc are already provided by a third-party, however, you do not need this sub-project.
ProjectName-component
This project contains the skeleton code for the API component.

Edit component classes
링크 복사

You can edit the skeleton code in ProjectName-component to develop your own component implementation. The following generated classes make up the core of the skeleton implementation: 
ComponentNameComponent
ComponentNameEndpoint
ComponentNameConsumer
ComponentNameProducer
ComponentNameConfiguration
Copy to Clipboard Toggle word wrap

Customize POM files
링크 복사

You also need to edit the Maven POM files to customize the build, and to configure the camel-api-component-maven-plugin Maven plug-in.

Configure the camel-api-component-maven-plugin
링크 복사

The most important aspect of configuring the POM files is the configuration of the camel-api-component-maven-plugin Maven plug-in. This plug-in is responsible for generating the mapping between API methods and endpoint URIs, and by editing the plug-in configuration, you can customize the mapping.
For example, the following camel-api-component-maven-plugin plug-in configuration shows a minimal configuration for an API class called ExampleJavadocHello: 
<configuration>
  <apis>
    <api>
      <apiName>hello-javadoc</apiName>
      <proxyClass>org.jboss.fuse.example.api.ExampleJavadocHello</proxyClass>
      <fromJavadoc/>
    </api>
  </apis>
</configuration>
Copy to Clipboard Toggle word wrap
In this example, the hello-javadoc API name is mapped to the ExampleJavadocHello class, which means you can invoke methods from this class using URIs of the form, scheme://hello-javadoc/endpoint. The presence of the fromJavadoc element indicates that the ExampleJavadocHello class gets its metadata from Javadoc.

OSGi bundle configuration
링크 복사

The sample POM for the component sub-project, ProjectName-component/pom.xml, is configured to package the component as an OSGi bundle. The component POM includes a sample configuration of the maven-bundle-plugin. You should customize the configuration of the maven-bundle-plugin plug-in, to ensure that Maven generates a properly configured OSGi bundle for your component.

Build the component
링크 복사

When you build the component with Maven, the camel-api-component-maven-plugin plug-in automatically generates the API mapping classes (which define the mapping between the Java API and the endpoint URI syntax), placing them into the target/generated-classes project subdirectory. When you are dealing with a large and complex Java API, this generated code actually constitutes the bulk of the component source code.
When the Maven build completes, the compiled code and resources are packaged up as an OSGi bundle and stored in your local Maven repository as a Maven artifact.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat