4 Replies Latest reply on Jul 9, 2010 4:21 PM by clewis

Multiple Scoped ESB deployments

clewis Jun 8, 2010 2:33 PM

Hi,

We're trying to deploy multiple esb applications to a single server node and are having difficulty figuring out how to configure the jboss-classloading.xml file. We're running ESB 4.7 on AS 5.1.0 with two server nodes based on the ALL configuration; the JMS Queues are clustered. On the first node we're running a single esb that listens for files and puts messages on a JMS Queue. On the second node, we'd like to run 3 different esb applications that pull from the queue. Each esb has its own set of properties, rules, etc. and shares a common core jar file. If we run a single esb application on node 2 or run multiple with each application on its own node (i.e node 2, 3 and 4), everything works fine. If we try to run multiple non-scoped applications on the same node, all the configuration values are taken from the first application loaded by the server. If we try to scope the applications we're getting ClassCastExceptions; however running a single scoped application still runs fine. Its only when we add the second scoped application that we start getting the ClassCastException.

The jboss-classloading.xml files look like the following for each respective esb:

<classloading xmlns="urn:jboss:classloading:1.0"
domain="APP3"
name="APP3"
import-all="true"
version="0.0.0"
parent-first="false"
parentDomain="DefaultDomain"

Here's an excerpt from one of the jboss-esb.xml files showing the action that's failing:

Here's the stack trace we get after the server successfully deploys the first application and attempts to deploy the second:

13:55:07,122 ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfszip:/C:/jboss-5.1.0.GA/server/node2/deploy/APP-REPORT.esb/ state=Create
org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Error configuring action processing pipeline
    at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:191)
    at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
    at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109)
    at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66)
    at org.jboss.soa.esb.listeners.deployers.mc.EsbDeployment.start(EsbDeployment.java:122)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
    at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
    at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
    at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
    at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
    at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
    at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
    at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
    at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
    at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
    at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
    at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
    at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
    at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
    at org.jboss.system.ServiceController.start(ServiceController.java:460)
    at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
    at sun.reflect.GeneratedMethodAccessor272.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
    at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
    at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
    at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
    at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:286)
    at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
    at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:1568)
    at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1533)
    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:943)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
    at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
    at org.jboss.system.ServiceController.start(ServiceController.java:460)
    at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
    at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
    at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
    at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
    at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
    at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
    at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
    at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
    at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
    at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
    at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
    at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
    at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
    at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
    at org.jboss.Main.boot(Main.java:221)
    at org.jboss.Main$1.run(Main.java:556)
    at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.soa.esb.ConfigurationException: Unexpected exception during lifecycle initialisation
    at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.initialise(ActionProcessingPipeline.java:383)
    at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:187)
    ... 85 more
Caused by: java.lang.ClassCastException: org.xyz.app.core.persister.database.DefaultFilePersister cannot be cast to org.xyz.app.core.persister.database.FileMessageStore
    at org.xyz.app.core.service.persister.DefaultNonRecordPersisterService.initialise(DefaultNonRecordPersisterService.java:83)
    at org.jboss.soa.esb.listeners.message.OverriddenActionPipelineProcessor.initialise(OverriddenActionPipelineProcessor.java:130)
    at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.initialise(ActionProcessingPipeline.java:378)
    ... 86 more

Is there a way to make this configuration work?

Thanks,

Carl

1. Re: Multiple Scoped ESB deployments

tfennelly Jun 9, 2010 4:42 AM (in response to clewis)

I think you'd need to go back to the scoped apps and repackage your esb to contain all the dependencies it needs.

BTW.... I assume your DefaultFilePersister actually does extend/implement your FileMessageStore? Seems like the FileMessageStore class loaded by DefaultNonRecordPersisterService is different to that loaded by DefaultFilePersister (different classloaders)?

I'd try adding these dependencies to the .esb itself (assuming they're not already). Sure this can lead to some duplication of jars across multiple .esb modules, but might at least be a step towards fixing your scoping issue.
1 of 1 people found this helpful
Actions

2. Re: Multiple Scoped ESB deployments

clewis Jun 9, 2010 10:24 AM (in response to tfennelly)

Tom Fennelly wrote:

I think you'd need to go back to the scoped apps and repackage your esb to contain all the dependencies it needs.

BTW.... I assume your DefaultFilePersister actually does extend/implement your FileMessageStore?

Yes, the DefaultFilePersister does implement FileMessageStore which extends MessageStore.

Seems like the FileMessageStore class loaded by DefaultNonRecordPersisterService is different to that loaded by DefaultFilePersister (different classloaders)?

Yes, It seems to be using a different classloader but I don't understand why. If I'm understanding correctly how the scoping of the classloader works, each esb application has its own dedicated class loader, so even though each application uses the same class definitions they should not be shareing the same classloader.

I'd try adding these dependencies to the .esb itself (assuming they're not already). Sure this can lead to some duplication of jars across multiple .esb modules, but might at least be a step towards fixing your scoping issue.

The esb applications each contain their own copy of core.jar (which contains among other classes,
the DefaultFilePersister, FileMessageStore, and DefaultNonRecordPersisterService). 
Actually we've tried to make each esb contain everything it needs to run, so that we'd have the
flexiblity of deploying them on a single node or spread out across mutliple nodes/servers.

If app1.esb contains:
     core-1.0.jar
     RouterRules.properties
     RouterRules.drl
     META-INF
          jboss-esb.xml
          jboss-classloading.xml
          deployment.xml

and app2.esb contains:
     core-1.0.jar
     RouterRules.properties
     RouterRules.drl
     META-INF
          jboss-esb.xml
          jboss-classloading.xml
          deployment.xml

Given the jboss-classloading.xml definitions defined in the previous post:

Shouldn't each esb application use its own classloader, so essentially, given the example above,
there would be two copies of the dependencies each in their own sandbox where app1 is not aware
that the same class has been loaded by app2 and vice versa?

Thanks,

Carl

3. Re: Multiple Scoped ESB deployments

beve Jun 13, 2010 1:37 PM (in response to clewis)
Hi,

I agree with Tom here that I prefer to put utility jars inside of every .esb deployment to simplify things. These types of classes are usually just util/helper classes and they don't get passed between services and there is no great risk of running into class loading issues. But there is nothing stopping you from doing this and versioning those utility jars. Hopefully the attached example will make this clearer.

But I do think that you might want to share a jar in other cases. The use case I have is that we have a canonical data format on our esb. The format is defined in xml schemas but we also generate a class representation using jaxb.

I've created a sample project as a kind of proof of concept for myself and using it as a referens before restructuring our projects. I've attached it to this thread. Note that we are using JBoss AS 5.1.0 and this uses features of the new MicroContainer.

What this example project shows is two esb services, 'service1' and 'service2', that share a domain-model.jar between them. 'service1' creates an instance of a Customer object and sends it to 'service2'. The Customer object has a version as does the domain-model.jar.
New versions of the domain-model.jar can be deployed without effecting existing services. For example, if you are adding a new service which
required an update of the Customer class old services are uneffected as they depend on the previous version.
Redeploying the domain-model.jar will cause all services that depend on that specific version of domain-model.jar to be redeployed. By updating the version of domain-model.jar and then updating the versions of 'service1' and 'service2' you'll see that we can deploy new versions of them without effecting the older versions.

There is a readme.txt in the root project which describes the steps of running the example.

Hope this helps,

Regards,

/Daniel

esb-osgi-style.jar 9.7 MB

1 of 1 people found this helpful
Actions
4. Re: Multiple Scoped ESB deployments

clewis Jul 9, 2010 4:21 PM (in response to beve)

Hi Daniel,

Thank you very much for the explaination and sample code, it does clear up a few things. I was able to get your sample code working, however I still wasn't able to get our application to work. We've put this aside for the moment and are looking at deploying each app on its own server node. At some point I'll return to this problem but for the moment we're looking at a different deployment configuration.

Thanks again for your help.

-Carl
Actions

Go to original post