Building Your Event-Driven Architecture : Implementing Event-Driven Architecture with Software AG Products : Troubleshooting NERV : NERV Troubleshooting Information : Troubleshooting NERV Emit Configuration Bundles
Troubleshooting NERV Emit Configuration Bundles
Problem: I have a bundle, which overrides the default NERV emit configuration, but it does not work
Solution:
1. Connect to the OSGi console where you expect your emit configuration bundle to be active.
For more information about how to connect to the OSGi console for a single profile, see Starting the OSGi Console for a Single OSGi Profile.
2. Locate your emit configuration bundle in the Common Platform and mark its ID.
*Use the nervDefinedEmit command to list bundles that declare an emit configuration using an emit.xml configuration file.
*Use the ss command to list bundles where the emit logic is defined not following the convention for NERV emit configuration bundles (for example, programmatically or using declarative services).
3. Depending on the state of your bundle, do the following:
*If your bundle is not in an active state, use the diag <bundle_id> command to diagnose why it was not started, resolve any dependency issues, then use the start <bundle_id> command to start your bundle.
*If your bundle is in an active state, use the bundle <bundle_id> command to list all services that the bundle uses and exposes.
To successfully emit events with NERV, your bundle must:
*Use services from other bundles - either an instance of the org.apache.camel.Component service, or some of the other NERV services.
*Expose some services - either an Apache Camel-related class, or an instance of a container or a class (for example, an instance of the BlueprintContainer or the DelegatedExecutionOsgiBundleApplicationContext classes).
Note:  
If your emit configuration bundle also defines a component, you might not need to use any other services.
If the bundle <bundle_id> command output does not list any exposed services, diagnose why they are not used.
i. Check the content of your log file, located by default in the log directory under Software AG_directory /profiles/<profile_name>.
ii. In the OSGi console, restart your bundle using the stop <bundle_id> and start <bundle_id> commands, then check the content of the log file again. It should contain information about the start-up of your bundle and some indications why the bundle was not instantiated and exposed correctly.
Some of the most common reasons are:
Common reasons
Possible solutions
An XML parsing error or exception indicates that the component configuration file is not grammatically correct.
The parser usually prints out the number of the line which causes the error or exception. Locate it in the component configuration file and fix it.
A ClassNotFoundException or a NoClassDefFoundError indicate that the bundle imports are not correct, and that the Common Platform cannot locate a certain class while instantiating your bundle.
Make sure that the Import-Package statement of your MANIFEST file includes the classes from the Apache Camel package, the Spring classes, as well as any other classes you might need.
A Blueprint-related or a Spring-related exception or warning message indicates that the framework instantiating and exposing the component service encountered an exception.
Examine the stack trace and try to fix the issue. Check whether another service with the same componentId is not already declared in the same Common Platform instance.
Copyright © 2016 - 2016 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback