InfoSphere Master Data Management operational server v11.x OSGi best practices and troubleshooting guide Introduction... 2 Optimal workspace operational server configurations... 3 Bundle project build path... 6 Runtime ClassNotFoundException / NoClassDefError... 7 Exporting services from composite bundles... 8 Deploying a CBA composition unit extension... 10 Class loaders explained cyclical dependencies.... 11 Troubleshooting... 13
Introduction The goal of this article is to show best practices and optimal development practices for developing with the InfoSphere MDM operational server. We will discuss common OSGi patterns, troubleshooting, including failures and resolution, as well as how to best deploy MDM composite bundle (CBA) extensions. The InfoSphere MDM version 11.x operational server is based on an enterprise OSGi architecture, which is modular in nature. The benefits of a modular architecture application design include reducing complexity, reducing time to delivery, and increasing serviceability. The Java EE infrastructure leveraged in previous versions of InfoSphere MDM had limited ability to enforce or encourage a modular design. The advantage of a modular MDM application is to allow customization to be deployed without having to alter the core MDM application. Instead, customizations are attached in the form of extensions to the core MDM application. This is done using composite bundles, or CBA files.
Optimal workspace operational server configurations The InfoSphere MDM Workbench is a tool that supports development of customizations and extensions to MDM operational server. The MDM Workbench allows you to define the desired data model and transactions and then generates the code required to implement the MDM Server extensions. When using workbench to build and deploy your MDM customizations and extensions, there are a few workspace configurations to consider for achieving the best performance and development experience. 1. Workbench workspace server definition settings Publishing CBAs from the MDM Workbench using the "Run server with resources within the workspace" option, sometimes called a "loose config" option, is not desired because it might cause the workspace and the server deployment to be out of sync. Use of this option often results in CBA deployment errors where the MDM EBA application fails to start. To resolve this, you must manually remove the CBA deployment using the WebSphere Application Server administrative console to return the application back to its original state. The optimal configuration is to use the "Run server with resources on Server" publishing option. Although this option will be slower, it is more stable. This option is a true reflection of a deployment to the production environment because the CBA is physically built, packaged, and deployed in the internal bundle repository of WebSphere Application Server. The second server definition option is to avoid publishing changes automatically to the server. Since publishing can be a time consuming operation, we want to avoid doing this for every simple changes we do in the workspace. The option to publish only when we have sufficient changes is ideal. -Double click (or Right click and select Open) to open the server s definition.
Note: Un-deploy any previously deployed CBA assets from the server prior to switching the plublishing settings. Finally, we recommend Start server with a generated script to be unchecked to allow proper MDM logging to occur. 2. Run server in debug mode Avoid re-publishing the CBA and bundle changes to the server for simple Java class changes. We can opt to run the server in debug mode and leverage the hot swap of Java code (also known as the Hot Method Replace ) feature. When running the application server in debug mode, hot method replace allows most application changes to be picked up automatically without requiring a republish, application restart or server restart. There are cases where we cannot simply rely on the hot method replace. Application structure changes such as OSGi blueprint changes, manifest change, CBA manifest changes and code refactoring will still require a republish. 3. Remove legacy applications and services
If your MDM implementation doesn t require the use of the Legacy UIs and/or legacy JAX-RPC web services, you can choose to uninstall these components from the application server. This will increase the startup performance of the application server and also reduce memory consumption. The MDM JAX-RPC web services are deployed as a CBA extension. Note that the JAX-RPC web services have been deprecated in InfoSphere MDM v10 and replaced by the new JAX-WS specification. It is recommended to migrate your existing JAX-RPC web services implementation to the new specifications but this may not always be possible. Uninstalling JAX-RPC web services is as simple as removing the CBA extension from the composition unit of the InfoSphere MDM operational server. 1. In WebSphere Application Server Administrative Console, Navigate to Applications --> Application Types --> Business Level Applications, and select the MDM-Operational-server-EBA-E001. Then select com.ibm.mdm.hub.server.app_e001-0001.eba. See below: 2. Select Extensions for this composition unit. 3. Select the com.ibm.mdm.server.jaxrpcws.cba CBA currently attached to the EBA and click Remove. 4. Save changes to master configuration file. 5. Return to the previous screen and click Update to latest deployment. 6. Save changes to master configuration file. 4. Apply WebSphere interim fixes for performance improvements See the following InfoSphere MDM technote for more info. http://www-01.ibm.com/support/docview.wss?uid=swg21651235
Bundle project build path When developing OSGi bundles in Rational Application Developer and the MDM Workbench, bundle projects are configured to use the OSGi and Plug-in dependencies build path options to resolved compile time dependencies. These options reflect the packages and classpath entries defined in the bundles manifest. Adding libraries or project references directly to the project s build path will NOT be reflected at runtime. Doing so is not desired and will lead to runtime exceptions (for example,. ClassNotFoundException). It is also not recommended to modify the Accessible rules of the Plug-in dependencies, again which can lead to runtime issues. The correct approach to enhance the bundle s classpath is to import the packages of the desired classes in the bundles manifest. There are cases where a import package is not possible. This can be because the desired dependency is not present in the RAD/RSA target runtime or simply that the package is not exported from the source bundle, making it not visible. Let s look at different approaches to enhance the bundle s classpath. Import Package: resolves classes from OSGi bundles present on the target runtime. The source bundle must also export the package for a successful resolution.
*Note: Packages imported in a bundle must also be imported in its associated CBA. Deployment Assembly: used to enhance the bundle s classpath with additional libraries. This is particularly useful when dealing with a thirdparty library or utility JAR that is not an OSGi bundle. Runtime ClassNotFoundException / NoClassDefError Most often a ClassNotFoundException or NoClassDefError in the context of an OSGi application is due to a missing import package. Confirm all package imports referenced in your source have an associated import package entry in the bundle s manifest. Also, confirm that all classes defined in the bundle s blueprint for services and beans are also being imported in the bundle s manifest. Given the following blueprint services, the com.dwl.base.extensionframework, com.ibm.mdm.common.servicefactory.api, com.ibm.mdm.common.servicefactory and com.dwl.tcrm.coreparty.interfaces packages must be imported. Failing to import any of these packages will result in a blueprint container initialization exception.
Exporting services from composite bundles Often the extension, addition or other customizations fail to resolve because the CBA is not exposing its services outside of its scope. Services must be exported from the CBA to allow the InfoSphere MDM engine s internal listeners to register the services with their associated brokers. When a service is defined in the bundle s blueprint file, this service must also be added to the CompositeBundle-ExportService manifest header of the COMPOSITEBUNDLE.MF. Example: We have the following Addition Controller service defined in our blueprint. Blueprint.xml <service id="controller.additionsamplestxn" interface="com.ibm.mdm.commonentity.samples.interfaces.additionsamplestxn"> <service-properties> <entry key="osgi.jndi.service.name"> <list> <value>addsample</value> </list> </entry> </service-properties> <bean class="com.ibm.mdm.commonentity.samples.controller.additionsamplestxnbean" /> </service> For this controller service to be visible to the MDM engine we must export it in the CBA. The service is bound to the interface. This is the value which we use for the export. COMPOSITEBUNDLE.MF CompositeBundle-ExportService: com.ibm.mdm.commonentity.samples.interfaces.additionsamplestxn You can use the OSGi composite bundle manifest editor in Workbench to add or remove services. Open the COMPOSITEBUNDLE.MF located under the META-INF folder of the CBA project. In the manifest editor, under the Overview tab, click Add in the Exported Services
section. The OSGi services dialog will open and show available services to export. Select the service(s) desired and click OK.
Deploying a CBA composition unit extension This topic has been documented in a paper that you can view at the following site: MDM CBA Deployment This paper covers the following deployment options: 1. InfoSphere MDM Workbench tooling. 2. Using the WebSphere Application Server Administrative Console. In addition to the options motioned above, you can also use wsadmin scripting. Here is a sample jacl script. AdminTask.addLocalRepositoryBundle('-file c:/c.cba') AdminConfig.save() AdminTask.addOSGiExtension('-cuName com.ibm.mdm.hub.server.app_cu.eba - symbolicname CommonEntitySamplesCba -version 11.0.0.201306101714') AdminConfig.save() AdminTask.editCompUnit('[-blaID WebSphere:blaname=com.ibm.mdm.hub.server.app - cuid WebSphere:cuname=com.ibm.mdm.hub.server.app_CU.eba -CompUnitStatusStep [[com.ibm.mdm.hub.server.app.eba true]]]') AdminConfig.save() We won t cover scripting in details as the WebSphere documentation has this covered fairly well. http://www-01.ibm.com/support/knowledgecenter/api/content/sseqtp_8.5.5/com.ibm.websphere.osgi.doc/ae/ta_admin_ext_acu_wsadmin.html?locale=en http://www-01.ibm.com/support/knowledgecenter/api/content/sseqtp_8.5.5/com.ibm.websphere.osgi.doc/ae/ta_admin_update_acu_wsadmin.html?locale=en Managing and updating multiple CBA extensions There are cases where the customizations might be packaged in multiple CBA extensions. This is often the case when multiple development teams are working on individual domains with different release cycles. WebSphere doesn t directly support updating a CBA extension bundle. Instead a remove or an add is necessary. This is where the tooling is limited. Scripting and the WebSphere Application Sever Administrative Console is often the better alternative to managing multiple CBAs, because it enables you to update the composition unit only when all the CBA bundles have been either removed or added.
Class loaders explained cyclical dependencies. It is important to understand that enterprise OSGi applications differ from JEE applications because enterprise OSGi applications have multiple classloaders. Effectively each OSGi bundle of the application has its own classloader and is isolated from other bundles unless explicitly defined in its manifest. A bundle must be told what it sees and also what is allows others to see. This is done using the manifest import and export packages. It is important to note that cyclical dependencies are not allowed in OSGi. For instance, imagine that Bundle A imports package com.ibm.test.api found in Bundle B and Bundle B imports package com.ibm.test.impl exported by Bundle A. This will cause a cyclical dependency between Bundle A and B. To resolve this common scenario, refactoring is often needed to work around the cyclical dependency. A new bundle, Bundle C, could be introduced to share the common APIs for both Bundle A and B to consume. Applications often have third party library dependencies. These libraries, often legacy libraries or open source, are not always OSGi bundles. This is usually not a problem since we can simply embed the library within the bundle s classpath to resolve the class dependencies but if other bundles within our application or CBA have the same dependency, we would be forced to make the packages from the library accessible (by exporting them), or by duplicating the library in the deployment of the other bundles. This is not desired and the better approach is to first see if there is an equivalent OSGi bundle version of the library. If this is not the case, we can simply wrap the jar in a self contained bundle and export its packages. This is often referred to as a wrapped bundle. This approach allows us to reference the wrapper bundle using import packages instead of having to package the library within the bundle. We are effectively creating a bundle out of a non OSGi library. This bundle can also be made into a shared bundle, allowing it to be provisioned by multiple applications or CBAs. Shared bundles are not application specific (for example, the common logging bundle, Log4j). A single instance of the bundle can be used by multiple applications or CBAs. Shared bundles must be provided by reference rather than contained directly in the application. Shared bundles are deployed in the WebSphere Application Server Internal Bundle Repository (IBR), where they can be referenced using the Use Bundle header in the application s manifest, or provisioned by a package import dependency of an application bundle.
Here is diagram demonstrating Shared bundles, and how the IBR can be leveraged to share bundles across extension CBAs. This capability allows you to avoid repackaging common utility bundles across CBAs. For example, consider the use of a common logging utility bundle, Log4j. You would initially deploy this logging bundle in the IBR. When extension CBA is deployed, it would provision the logging bundle from the IBR if the necessary packages are being imported by the CBA. A common logging bundle is used here as an example but the same would apply for third party vendor integration such as Trillium. The Trillium API JAR could be wrapped into a bundle, deployed in the IBR to be consumed by the integration adapters. Another advantage of this is that it decreases the size of the CBAs, speeding up deployment time.
Troubleshooting This section describes troubleshooting steps for common issues encountered in customizing the InfoSphere MDM operational server with OSGi technologies. Consulting this section could save you time by helping you to address common problems with this aspect of the product before calling IBM support. 1. java.lang.runtimeexception: Application could not be initialized. Application Name and Version could not be resolved. This error typically indicates that the InfoSphere MDM EBA application symbolic name doesn t match the entries in the APPSOFTWARE configuration table. Confirm that the appsoftware entry matches the EBA symbolic name by executing the following SQL statement: select * from APPSOFTWARE; In WebSphere Application Sever Administrative Console, navigate to Applications -- > Application Types --> Assets Under Assets, click on the MDM operational server EBA com.ibm.mdm.hub.server.app-e001.eba asset. On the following screen, click on "Export the deployment manifest from this application". Open the deployment.mf file and search for "Application-SymbolicName", next to it will be the value which needs to correspond to the entry in appsoftware table. 2. Troubleshooting OSGi Services Many different things can go wrong with OSGi services and InfoSphere MDM customizations. The following list steps to take to help diagnose service related issues. 1) Confirm the service is registered by analyzing the WebSphere Application Server log or in the server console in Rational Application Developer. The first step to take after successfully deploying the CBA extension is to confirm that all the bundle services are getting registered by the InfoSphere MDM engine s listeners. The InfoSphere MDM operational server will log specific entries when a new service is registered. For this you must look at the WebSphere systemout.log (or in the server console in Rational Application Developer) for signs that your services are getting registered. [4/14/14 8:50:46:358 EDT] 00000051 BObjQueryFact I BObjQueryFactoryBroker.registerFactory: com.ibm.mdm.common.servicefactory.bobjqueryfactoryimpl@d781e54 Bundle: CommonEntitySamples/11.0.0.qualifier
[4/14/14 8:50:46:358 EDT] 00000051 BObjQueryFact I Properties: {service.id=383, objectclass=[ljava.lang.string;@e12f53d3, service.ranking=10} [4/14/14 8:50:46:360 EDT] 00000051 BObjQueryFact I {com.ibm.mdm.commonentity.samples.bobj.query.commonentitysamplesmodulebobjqueryfactory=com.ibm.mdm.commonentity.samples.bobj.query.commonentitysa mplesmodulebobjqueryfactoryimpl@fd7395f1, com.dwl.base.bobj.query.dwlbusinessservicesmodulebobjqueryfactory=com.ibm.mdm.commonentity.samples.bobj.query.xdwlbusinessservicesmodulebobjquery FactoryImpl@13a5b9e8} [4/14/14 8:50:46:368 EDT] 00000051 BObjPersisten I BObjPersistenceFactoryBroker.registerFactory: com.ibm.mdm.common.servicefactory.bobjpersistencefactoryimpl@f397feb5 Bundle: CommonEntitySamples/11.0.0.qualifier [4/14/14 8:50:46:370 EDT] 00000051 BObjPersisten I Properties: {service.id=384, objectclass=[ljava.lang.string;@31b05798, service.ranking=10} [4/14/14 8:50:46:371 EDT] 00000051 BObjPersisten I {com.ibm.mdm.commonentity.samples.bobj.query.commonentitysamplesmodulebobjpersistencefactory=com.ibm.mdm.commonentity.samples.bobj.query.commonent itysamplesmodulebobjqueryfactoryimpl@f3457243, com.dwl.base.bobj.query.dwlbusinessservicesmodulebobjpersistencefactory=com.ibm.mdm.commonentity.samples.bobj.query.xdwlbusinessservicesmodulebobjq ueryfactoryimpl@efea3430} [4/14/14 8:50:46:380 EDT] 00000051 CodeTypeMetad I CodeTypeMetadataBroker.registerFactory: com.ibm.mdm.common.codetype.component.codetypemetadatafactoryserviceimpl@b7169462 Bundle: CommonEntitySamples/11.0.0.qualifier [4/14/14 8:50:46:381 EDT] 00000051 CodeTypeMetad I Properties: {service.id=385, objectclass=[ljava.lang.string;@4f891929, code.type.name=[cdnotetp]} [4/14/14 8:50:46:392 EDT] 00000051 MDMSchemaURLB I Registering schema URL bundleentry://2.fwk1942931946/mdm- RESOURCES/xsd/CommonEntitySamples.xsd-fragment with service ranking 0 [4/14/14 8:50:46:415 EDT] 00000051 BObjBroker I BObjBroker.registerFactory: com.ibm.mdm.common.bobj.bobjfactoryserviceimpl@86cf2988 Bundle: CommonEntitySamples/11.0.0.qualifier [4/14/14 8:50:46:416 EDT] 00000051 BObjBroker I Properties: {service.id=388, objectclass=[ljava.lang.string;@e5c329ad, business.object=[notebobj, ReminderBObj, NoteTypeTypeBObj, XQuestionnaireBObjExt, XQuestionnaire2BObjExt, QuestionnaireBObj, XQuestionBObjExt, QuestionBObj], service.ranking=10} [4/14/14 8:50:46:438 EDT] 00000051 ComponentBrok I ComponentBroker.registerFactory: com.ibm.mdm.common.component.componentfactoryserviceimpl@7b46700b [4/14/14 8:50:46:439 EDT] 00000051 ComponentBrok I Properties: {service.id=390, objectclass=[ljava.lang.string;@e56d196e, business.component=[additionsamples_component]} If a service registration log entry as described above cannot be found, you can start a deeper service analysis. More often than not, the service was not exported from the CBA meaning it is not visible to the InfoSphere MDM operational server application scope. The simple solution in this case is explained in the Exporting services from composite bundles chapter. If the service is exported in the CBA manifest, you can look for signs of failures during the registration phase, again using the WebSphere Application Server log or in the server console view in Rational Application Developer. Tip: Specifying the activation policy of services to eager will often gives us a better detail view of what went wrong at registration time. In the blueprint definition file of the service in question, set the default activation to eager for the entire blueprint: or for individual services: Republish the changes and pay close attention to the log. 2) Errors found during registration Example error 1: Unable to find a matching constructor on class [4/14/14 8:56:05:620 EDT] 0000004f ServiceRecipe E org.apache.aries.blueprint.container.servicerecipe createservice Error retrieving service from ServiceRecipe[name='BObjFactoryService'] org.osgi.service.blueprint.container.componentdefinitionexception: Unable to find a matching constructor on class com.ibm.mdm.common.bobj.bobjfactoryserviceimpl for arguments [{XQuestionnaireBObjExt=class com.ibm.mdm.commonentity.samples.component.xquestionnairebobjext, XQuestionnaire2BObjExt=class com.ibm.mdm.commonentity.samples.component.xquestionnaire2bobjext, ReminderBObj=class com.ibm.mdm.commonentity.samples.component.reminderbobj,
NoteBObj=class com.ibm.mdm.commonentity.samples.component.notebobj, QuestionBObj=class com.ibm.mdm.commonentity.samples.component.xquestionbobjext, NoteTypeTypeBObj=class com.ibm.mdm.commonentity.samples.codetable.obj.notetypetypebobj, XQuestionBObjExt=class com.ibm.mdm.commonentity.samples.component.xquestionbobjext}] when instanciating bean #recipe-144 at org.apache.aries.blueprint.container.beanrecipe.getinstance(beanrecipe.java:336) at org.apache.aries.blueprint.container.beanrecipe.internalcreate2(beanrecipe.java:806) at org.apache.aries.blueprint.container.beanrecipe.internalcreate(beanrecipe.java:787) at org.apache.aries.blueprint.di.abstractrecipe.create(abstractrecipe.java:106) at org.apache.aries.blueprint.container.servicerecipe.createservice(servicerecipe.java:285) at org.apache.aries.blueprint.container.servicerecipe.internalgetservice(servicerecipe.java:252) at org.apache.aries.blueprint.container.servicerecipe.getservice(servicerecipe.java:364) at org.apache.aries.blueprint.container.servicerecipe$triggerservicefactory.getservice(servicerecipe.java:517) at org.eclipse.osgi.internal.serviceregistry.serviceuse$1.run(serviceuse.java:120) at java.security.accesscontroller.doprivileged(accesscontroller.java:273) Caused by: org.osgi.service.blueprint.container.componentdefinitionexception: Unable to find a matching constructor on class com.ibm.mdm.common.bobj.bobjfactoryserviceimpl for arguments [{XQuestionnaireBObjExt=class com.ibm.mdm.commonentity.samples.component.xquestionnairebobjext, XQuestionnaire2BObjExt=class com.ibm.mdm.commonentity.samples.component.xquestionnaire2bobjext, ReminderBObj=class com.ibm.mdm.commonentity.samples.component.reminderbobj, NoteBObj=class com.ibm.mdm.commonentity.samples.component.notebobj, QuestionBObj=class com.ibm.mdm.commonentity.samples.component.xquestionbobjext, NoteTypeTypeBObj=class com.ibm.mdm.commonentity.samples.codetable.obj.notetypetypebobj, XQuestionBObjExt=class com.ibm.mdm.commonentity.samples.component.xquestionbobjext}] when instanciating bean #recipe-144 at org.apache.aries.blueprint.container.beanrecipe.getinstance(beanrecipe.java:336) at org.apache.aries.blueprint.container.beanrecipe.internalcreate2(beanrecipe.java:806) at org.apache.aries.blueprint.container.beanrecipe.internalcreate(beanrecipe.java:787) at org.apache.aries.blueprint.di.abstractrecipe.create(abstractrecipe.java:106) at org.apache.aries.blueprint.container.servicerecipe.createservice(servicerecipe.java:285) The blueprint service or bean definition is likely incorrect and doesn t obey the specification defined by InfoSphere MDM. The example above is indicating that the BObjFactoryServiceImpl bean definition was not correct. A quick look at the blueprint definition of our bundle shows that the bean is missing a mandatory argument in its definition. Blueprint is missing an argument. Corrected blueprint.
Example error 2: Unable to load class and java.lang.classnotfoundexception [4/14/14 9:06:24:045 EDT] 00000051 AbstractRecip E org.apache.aries.blueprint.di.abstractrecipe doloadtype Unable to load class com.ibm.mdm.common.bobj.bobjfactoryserviceimpl from recipe BeanRecipe[name='#recipe-145'] [4/14/14 9:06:24:046 EDT] 00000051 ServiceRecipe E org.apache.aries.blueprint.container.servicerecipe createservice Error retrieving service from ServiceRecipe[name='BObjFactoryService'] org.osgi.service.blueprint.container.componentdefinitionexception: Unable to load class com.ibm.mdm.common.bobj.bobjfactoryserviceimpl from recipe BeanRecipe[name='#recipe-145'] at org.apache.aries.blueprint.di.abstractrecipe.doloadtype(abstractrecipe.java:195) at org.apache.aries.blueprint.di.abstractrecipe.loadtype(abstractrecipe.java:161) at org.apache.aries.blueprint.container.beanrecipe.loadclass(beanrecipe.java:249) at org.apache.aries.blueprint.container.beanrecipe.gettype(beanrecipe.java:895) at org.apache.aries.blueprint.container.beanrecipe.getinstance(beanrecipe.java:323) at org.apache.aries.blueprint.container.beanrecipe.internalcreate2(beanrecipe.java:806) at org.apache.aries.blueprint.container.beanrecipe.internalcreate(beanrecipe.java:787) at org.apache.aries.blueprint.di.abstractrecipe.create(abstractrecipe.java:106) at org.apache.aries.blueprint.container.servicerecipe.createservice(servicerecipe.java:285) at org.apache.aries.blueprint.container.servicerecipe.internalgetservice(servicerecipe.java:252) at org.apache.aries.blueprint.container.servicerecipe.internalcreate(servicerecipe.java:149) at org.apache.aries.blueprint.di.abstractrecipe$1.call(abstractrecipe.java:79) at java.util.concurrent.futuretask$sync.innerrun(futuretask.java:314) at java.util.concurrent.futuretask.run(futuretask.java:149) Caused by: java.lang.classnotfoundexception: com.ibm.mdm.common.bobj.bobjfactoryserviceimpl at org.eclipse.osgi.internal.loader.bundleloader.findclassinternal(bundleloader.java:506) at org.eclipse.osgi.internal.loader.bundleloader.findclass(bundleloader.java:422) at org.eclipse.osgi.internal.loader.bundleloader.findclass(bundleloader.java:410) at org.eclipse.osgi.internal.baseadaptor.defaultclassloader.loadclass(defaultclassloader.java:107) at java.lang.classloader.loadclass(classloader.java:661) at org.eclipse.osgi.internal.loader.bundleloader.loadclass(bundleloader.java:338) at org.eclipse.osgi.framework.internal.core.bundlehost.loadclass(bundlehost.java:232) at org.eclipse.osgi.framework.internal.core.abstractbundle.loadclass(abstractbundle.java:1197) at org.apache.aries.blueprint.container.blueprintcontainerimpl.loadclass(blueprintcontainerimpl.java:419) at org.apache.aries.blueprint.container.blueprintrepository.loadclass(blueprintrepository.java:410) at org.apache.aries.blueprint.container.generictype.parse(generictype.java:113) at org.apache.aries.blueprint.di.abstractrecipe.doloadtype(abstractrecipe.java:168)... 32 more [4/14/14 9:06:24:048 EDT] 00000051 ServiceRecipe E org.apache.aries.blueprint.container.servicerecipe createservice Error retrieving service from ServiceRecipe[name='BObjFactoryService'] org.osgi.service.blueprint.container.componentdefinitionexception: org.osgi.service.blueprint.container.componentdefinitionexception: Unable to load class com.ibm.mdm.common.bobj.bobjfactoryserviceimpl from recipe BeanRecipe[name='#recipe-145'] at org.apache.aries.blueprint.container.servicerecipe.createservice(servicerecipe.java:310) at org.apache.aries.blueprint.container.servicerecipe.internalgetservice(servicerecipe.java:252) at org.apache.aries.blueprint.container.servicerecipe.internalcreate(servicerecipe.java:149) at org.apache.aries.blueprint.di.abstractrecipe$1.call(abstractrecipe.java:79) at java.util.concurrent.futuretask$sync.innerrun(futuretask.java:314) at java.util.concurrent.futuretask.run(futuretask.java:149) Caused by: org.osgi.service.blueprint.container.componentdefinitionexception: Unable to load class com.ibm.mdm.common.bobj.bobjfactoryserviceimpl from recipe BeanRecipe[name='#recipe-145'] at org.apache.aries.blueprint.di.abstractrecipe.doloadtype(abstractrecipe.java:195) at org.apache.aries.blueprint.di.abstractrecipe.loadtype(abstractrecipe.java:161) at org.apache.aries.blueprint.container.beanrecipe.loadclass(beanrecipe.java:249) Caused by: java.lang.classnotfoundexception: com.ibm.mdm.common.bobj.bobjfactoryserviceimpl at org.eclipse.osgi.internal.loader.bundleloader.findclassinternal(bundleloader.java:506) at org.eclipse.osgi.internal.loader.bundleloader.findclass(bundleloader.java:422) at org.eclipse.osgi.internal.loader.bundleloader.findclass(bundleloader.java:410) The blueprint service or bean definition is referencing a class or interface which its package has not been imported in the manifest of the bundle. See section on Runtime ClassNotFoundException / NoClassDefError for more info. 3) Using the OSGi application console When there is no clear sign in the WebSphere log that the service failed to register, we can use the OSGi application console to further diagnose and confirm if the service was registered by the OSGi framework. Launch the osgiapplicationconsole The console can be accessed from a command line window, under <server profile bin dir>\osgiapplicationconsole.bat/sh or from the WebSphere Application Server Administrative Console.
We will only cover the WebSphere Application Server Administrative Console version in this article. For more info on the osgiapplicationconsole, consult the WebSphere Application Server documentation. In the WebSphere administrative console, navigate to: Business-level applications MDM-operational-server-EBA-<instance> com.ibm.mdm.hib.server.app-<instance>_0001.eba Click on OSGI application console under Additional Properties section. The following screen will list the InfoSphere MDM EBA along with any custom CBA extensions which have been applied to InfoSphere MDM. To analyze the content of CBA, navigate down the CBA In this diagram, we list the bundles from the legacy jax-rpc CBA which in MDM is deployed as an extension. To list the services exported from the CBA, click on the cba asset, and then on Bundle services
The following dicpicts what we are exporting 4 services (2 ResponseConstructor and 2 Request Parser services) Clicking down on the service identifier will display additional details on the service. (ie. Bundle that registered the service, service properties) If the service you are interested in is not listed in the CBA bundle service list, this would indicate that the service in question was not added to the exported services of the CBA manifest, or that a failure occurred during service registration.
3. The InfoSphere MDM operational server application won t start Error: Failed to add the composite bundle xxx extension to application Browse the WebSphere SystemOut.log and FFDC folder for signs as to why the application failed to start. The FFDC traces will generally contain the root cause. Ensure that the deployment is clean, un-deploy the CBA and all its assets through the WebSphere Application Server Administrative Console, stop WebSphere, delete the content from the./appserver/profiles/appsvr0##/wstemp folder.
Reference materials: http://www.ibm.com/developerworks/websphere/techjournal/1007_robinson/1007_robins on.html http://wiki.eclipse.org/context_class_loader_enhancements