Troubleshooting NERV Component Configuration Bundles
Problem: I have deployed a NERV Component bundle which overrides the default NERV component, but my messages are still not sent to the specified JMS provider
Solution:
1. Connect to the OSGi console where you expect the configuration bundle to be active.
2. Use the nervDefaultJms command to check which is the currently active JMS provider.
If the command output indicates that the default JMS provider is the one specified in your user-defined configuration bundle, then events should be sent to that JMS provider by default, and you should check whether events are actually being sent and if the receiving side is configured correctly.
If the command output indicates that the default JMS provider is different than the one that you specified in your user-defined configuration bundle, then either the component did not get activated, or was not configured correctly.
3. Locate your configuration bundle in the Common Platform profile and make a note of its ID.
Use the
nervDefinedComponents command to list bundles that define a component in a component.xml file following the convention for NERV configuration bundles.
Use the
ss command to list bundles that declare components not following the convention for NERV configuration bundles (for example, programmatically or using declarative services).
4. Depending on the state of your configuration 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 expose a component for usage by NERV, your bundle must expose at least one service of type org.apache.camel.Component with a componentId=nervDefaultJMS property (properties for the services are listed right after the service type).
If the bundle <bundle_id> command output lists an org.apache.camel.Component service type with a correct componentId=nervDefaultJMS property, then a race condition might exist inside the OSGi registry which prevented NERV from picking up the service registration. Use the stop <bundle_id> and start <bundle_id> commands to restart your bundle. Alternatively, you can also restart the whole Common Platform instance. If this resolves the problem, you should decrease the bundle start level, so it starts later than NERV.
If the bundle <bundle_id> command output does not list a component service, diagnose why the service was not started.
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 org.apache.camel and org.apache.camel.component.jms classes from the Apache Camel package, the org.springframework.jndi and org.springframework.jms.connection Spring classes, as well as the specific JMS provider classes. |
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. |
Problem: I have deployed a NERV Component bundle, which declares a component, but when I try to use it, it doesn’t work
Solution:
1. Connect to the OSGi console where you expect the configuration bundle to be active.
2. Use the nervActiveComponents command to list the currently active component bundles on the system.
If the command output lists your component bundle, then it is currently active and available for usage. Double check the configuration for using the component to make sure it is set correctly.
If the command output does not list your component bundle, then it is not currently active, it was not properly instantiated, or it has not been defined correctly.
3. Locate your configuration bundle in the Common Platform and mark its ID.
Use the
nervDefinedComponents command to list bundles that define a component in a component.xml file following the convention for NERV configuration bundles.
Use the
ss command to list bundles that declare components not following the convention for NERV configuration bundles (for example, programmatically or using declarative services).
4. Depending on the state of your configuration 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 expose a component for usage by NERV, your bundle must expose at least one service of type org.apache.camel.Component.
If the bundle <bundle_id> command output does not list a component service, diagnose why the service was not started.
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 org.apache.camel and org.apache.camel.component.jms classes from the Apache Camel package, the org.springframework.jndi and org.springframework.jms.connection Spring classes, as well as the specific JMS provider classes. |
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. |
