Page History

...

Add the following line in your pom.xml of the project reportincident.webservice

Code Block

			<!-- CXF wsdl2java generator, will plugin to the compile goal -->
			<plugin>
				<groupId>org.apache.cxf</groupId>
				<artifactId>cxf-codegen-plugin</artifactId>
				<version>${cxf-version}</version>
				<executions>
					<execution>
						<id>generate-sources</id>
						<phase>generate-sources</phase>
						<configuration>
							<sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
							<wsdlOptions>
								<wsdlOption>
									<wsdl>${basedir}/src/main/resources/META-INF/wsdl/report_incident.wsdl</wsdl>
								</wsdlOption>
							</wsdlOptions>
						</configuration>
						<goals>
							<goal>wsdl2java</goal>
						</goals>
					</execution>
				</executions>

			</plugin>

...

To transform the reportincident.model project, we will execute the steps 1) 2) and 3) because no services must be registered for this project. So, update the pom.xml file created and add/change what is put in the code below in the comment <!- - STEP -->

Code Block

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.apache.camel.example</groupId>
	<artifactId>reportincident.model</artifactId>

        <!-- STEP 1 -->
	<packaging>bundle</packaging>

	<name>Report Incident Model Bundle</name>
	<version>1.0-SNAPSHOT</version>

	<properties>
		<felix-version>1.4.3</felix-version>
		<camel-version>2.0-M1</camel-version>
		<commons-lang>2.4</commons-lang>
	</properties>

	<dependencies>
		<!-- Camel bindy  -->
		<dependency>
			<groupId>org.apache.camel</groupId>
			<artifactId>camel-bindy</artifactId>
			<version>${camel-version}</version>
		</dependency>
		<dependency>
			<groupId>commons-lang</groupId>
			<artifactId>commons-lang</artifactId>
			<version>${commons-lang}</version>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<!-- to compile with 1.5 -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.5</source>
					<target>1.5</target>
				</configuration>
			</plugin>
                        
                        <!-- STEP 2 -->
			<!-- to generate the MANIFEST-FILE of the bundle -->
			<plugin>
				<groupId>org.apache.felix</groupId>
				<artifactId>maven-bundle-plugin</artifactId>
				<extensions>true</extensions>
				<version>${felix-version}</version>
				<configuration>
					<manifestLocation>META-INF</manifestLocation>
					<instructions>
						<Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>

                                                
<!-- STEP 3 -->
						<Export-Package>
						             '=META-INF.org.apache.camel.example.reportincident.model',
						    org.apache.camel.example.reportincident.model
						</Export-Package>

                                <!-- STEP 3 -->
						<Export-Package>
						    '=META-INF.org.apache.camel.example.reportincident.model',             <_failok>true</_failok>
						    org.apache.camel.example.reportincident.model
		</instructions>
				</Export-Package>configuration>
			</plugin>

		</plugins>
	
                                                <_failok>true</_failok>
					</instructions>
				</configuration>
			</plugin>

		</plugins>
	</build>
</project>

Remarks :

</build>
</project>

Remarks :

The model bundle does not need The model bundle does not need to import 'specific' packages so the tag <Import-Packages> can be skipped but packages will be added automatically
by the felix/bnd tool to the MANIFEST.MF file if import statements are defined in the classes or maven dependencies are declared
The tag <_failok>true</_failok> is added to inform the plugin that it can continue the creation of the MANIFEST.MF file even if an error/warning occurs. This is the case here because files located under META-INF directory must be exported.
The hibernate file must be exported with the classpath of the bundle. This is why the line '=META-INF.org.apache.camel.example.reportincident.model' has
been added to export the packagename containing this file

...

Nevertheless, it is interesting to mention that we have exported the package }} and defined {{ org.apache.camel.example.reportincident.dao and defined org.apache.camel.example.reportincident.dao.impl as private. Why, the reason is very simple. We would like to export only the interface to another 'service' bundles and keep internally the implementation.

Code Block
<Private-<Private-Package>org.apache.camel.example.reportincident.dao.impl</Private-Package> <Export-Package>org.apache.camel.example.reportincident.dao <dao</Export-Package>

Tip
Discovering all the classes used by a third party library like Hibernate can be cumbersome and takes time. An interesting alternative is to use the command 'DynamicImport-Package' to resolve classloading issue. <DynamicImport-Package> *</DynamicImport-Package>

In order to test the tip, update your pom.xml with the following info :

Code Block

    <Import-Package>
	META-INF.org.apache.camel.example.reportincident.model,
	com.mysql.jdbc,
	org.apache.camel.example.reportincident.model,
	org.apache.commons.dbcp,
	*
    </Import-Package>
    <Private-Package>
	org.apache.camel.example.reportincident.dao.impl
    </Private-Package>
    <Export-Package>
	org.apache.camel.example.reportincident.dao
    </Export-Package>
    <DynamicImport-Package>*</DynamicImport-Package>

and look at the result generated by the plugin. The Import-Package section is dry.

...

DynamicImport-Package>

and look at the result generated by the plugin. The Import-Package section is dry.

Now that our pom.xml is configured we will modified our spring.xml files to allow our DAO service to be registered as a OSGI service. Why, because the classes of the bundle reportincident.service uses this DAO class but required also additional functionalities like (Hibernate SessionFactory, Spring Transaction management, ...) who will be instantiated and configured when the persistence bundle/service will be started.

Additional motivations are also provided in the OSGI specification :

Enterprise application developers working with technologies such as those described in chapter 2 would like to be
able to take advantage of the OSGi platform. The core features of enterprise programming models previously
described must be retained for enterprise applications deployed in OSGi. The current OSGi specifications are
lacking in the following areas with respect to this requirement:
• There is no defined component model for the internal content of a bundle. Declarative Services only
supports the declaration of components that are publicly exposed.
• The configuration (property injection) and assembly (collaborator injection) support is very basic
compared to the functionality offered by frameworks such as Spring.
• There is no model for declarative specification of services that cut across several components (aspects or
aspect-like functionality)
• Components that interact with the OSGi runtime frequently need to depend on OSGi APIs, meaning that
unit testing outside of an OSGi runtime is problematic
• The set of types and resources visible from the context class loader is unspecified. The context class
loader is heavily used in enterprise application libraries
• Better tolerance of the dynamic aspects of the OSGi platform is required. The programming model should
make it easy to deal with services that may come and go, and with collections of such services, via simple
abstractions such as an injecting a constant reference to an object implementing a service interface, or to
a managed collection of such objects. See the description of osgi:reference in the Spring Dynamic
Modules specification for an example of the level of support required here.
Providing these capabilities on the OSGi platform will facilitate the adoption of OSGi as a deployment platform for
enterprise applications. This should be done in a manner that is familiar to enterprise Java developers, taking into
account the unique requirements of the OSGi platform. The benefits also extend to other (non-enterprise) OSGi
applications that will gain the ability to write simpler, more testable bundles backed by a strong component model.

Create the file persistence-osgi.xml in the directory src/main/resources/META-INF/spring and add the lines :

Code Block

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:osgi="http://www.springframework.org/schema/osgi"
  xsi:schemaLocation="
      http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd
      http://www.springframework.org/schema/osgi
      http://www.springframework.org/schema/osgi/spring-osgi.xsd">
                      
    <osgi:service ref="incidentDAO" interface="org.apache.camel.example.reportincident.dao.IncidentDAO"/>

</beans>

...

Notice also that to use this osgi spring namespace, we have imported a new schema http://www.springframework.org/schema/osgi/spring-osgi.xsd^{Image Removed} in the persistence-osgi.xml file
More than one interface can be part of an OSGI service.

...

3) reportincident.service

Like in the service reportincident.persistence, we will replace our pom.xml file with the one provide in the zip file.

Routing/Mediation service

...

Child pages

Versions Compared

Old Version 5

New Version 6

Key

3) reportincident.service

Routing/Mediation service