- Build and Run the Examples
- Examples for Standalone & Remote WildFly
- Examples for WildFly Integration
JBoss OSGi comes with a number of examples that demonstrate supported functionality and show best practices. All examples are part of the binary distribution and tightly integrated in our Maven Build Process.
The examples can be either run against an embedded OSGi framework or against WildFly. Here is how you build and run the standalone framework tests.
To run the examples against WildFly, you need to provide the target container that the runtime should connect to. This can be done with the target.container system property.
This section covers example tests that run both in the standalone and remote WildFly runtimes.
The BlueprintTestCase shows how a number of components can be wired together and registered as OSGi service through the Blueprint Container Service.
The example uses this simple blueprint descriptor
The Blueprint Container registers two services ServiceA and ServiceB. ServiceA is backed up by BeanA, ServiceB is backed up by the anonymous BeanB. BeanA is injected into BeanB and the MBeanServer gets injected into BeanA. Both beans are plain POJOs. There is no BundleActivator neccessary to register the services.
The example test verifies the correct wiring like this
The DeclarativeServicesTestCase shows how a service can be made available through a Declarative Services descriptor.
The test then verifies that the service becomes available
The EventAdminTestCase uses the EventAdmin service to send/receive events.
The NamingStandaloneTestCase gets the JNDIContextManager service and verifies JNDI access.
The MBeanServerTestCase tracks the MBeanServer service and registers a pojo with JMX. It then verifies the JMX access.
The BundleStateTestCase uses JMX to control the bundle state through the BundleStateMBean.
This section covers example tests that only run both in the remote WildFly integration.
The ManagedBeansTestCase deploys and EAR file that contains a WAR and three bundles. The first bundle tracks payment service providers
The other two bundles each provide an OSGi payment service, which gets injected into the webapp via CDI. The advantage of this approach is that we can construct modular web applications from independent components (i.e. bundles) which have lifecyle. We can therefore easily add/remove/start/stop/update payment service providers.
The EnterpriseArchiveTestCase shows that OSGi bundles can be deployed as part on an EAR. It is guaranteed the contained bundles all get 'installed' before they get 'resolved' and 'started'. With a large set of individual bundle deployments that have complex interdependencies it would be hard to deploy the bundles in the correct order. EAR deployments fix that ordering issue.
The StatelessBeanTestCase verifies that an EJB can be deployed as OSGi bundle. The stateless session bean then accesses on OSGi services
The HttpServiceTestCase deploys a Service that registeres a servlet and a resource with the HttpService.
The test then verifies that the registered servlet context and the registered resource can be accessed.
The XMLBindingTestCase verifies that an OSGi bundle can use the JAXB integration that is available in WildFly
The PersistenceTestCase verifies that an OSGi bundle can use the Hibernate JPA integration in WildFly
The TransactionTestCase gets the UserTransaction service and registers a transactional user object (i.e. one that implements Synchronization) with the TransactionManager service. It then verifies that modifications on the user object are transactional.
This functionality is only available in the context of AS7.
The LifecycleInterceptorTestCase deployes a bundle that contains some metadata and an interceptor bundle that processes the metadata and registeres an http endpoint from it. The idea is that the bundle does not process its own metadata. Instead this work is delegated to some specialized metadata processor (i.e. the interceptor).
Each interceptor is itself registered as a service. This is the well known Whiteboard Pattern.
The ResourceInjectionTestCase verifies that resources can be injected in OSGi bundle activators.
The RestEndpointTestCase verifies that OSGi bundles can provide REST endpoints. REST endpoints can therefore be part of larger modular applications and have lifecycle - they can be started/stopped/updated, etc. REST endpoints can access OSGi services.
The WebServiceEndpointTestCase verifies that OSGi bundles can provide WebService endpoints. WebService endpoints can therefore be part of larger modular applications and have lifecycle - they can be started/stopped/updated, etc. WebService endpoints can access OSGi services.
The WebAppTestCase deploys an OSGi Web Application Bundle (WAB). Similar to HTTP Service Example it registers a servlet and resources with the WebApp container. This is done through a standard web.xml descriptor.
The associated OSGi manifest looks like this.
The test verifies that we can access the servlet and some resources.
The XML parser test cases get a DocumentBuilderFactory/SAXParserFactory respectivly and unmarshalls an XML document using that parser.