Bug 779194 (SOA-1588) - ESB deployments don't see classes in the lib dir of the.esb archive
Summary: ESB deployments don't see classes in the lib dir of the.esb archive
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-1588
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB, Configuration, Integration, Compatibility
Version: 5.0.0 ER2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 5.0.0 ER8
Assignee: Kevin Conner
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On: SOA-1927
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-10 19:20 UTC by Aaron Pestel
Modified: 2010-02-09 17:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Full SOA Platform Embedded 5.0 ER2 with "default" configuration using Sun JDK 1.6.0_11-b03
Last Closed: 2010-02-09 17:52:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
EsbProjectWithLib.esb (1.94 KB, application/octet-stream)
2009-11-10 19:20 UTC, Aaron Pestel
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 779450 0 high CLOSED ESB examples packaged with JBDS 3.0 fail with SOA-P 5.0 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 779452 0 urgent CLOSED SOA-P 5.0 could not be used as a Drools runtime (in JBDS 3.0) 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker JBESB-2972 0 None None None Never
Red Hat Issue Tracker JBIDE-5740 0 None None None Never
Red Hat Issue Tracker SOA-1588 0 None None None Never

Internal Links: 779450 779452

Description Aaron Pestel 2009-11-10 19:20:33 UTC
Date of First Response: 2009-11-11 05:09:57
Workaround Description: Move .jar files to the root directory or "jars" directory of the .esb archive.
project_key: SOA

The attached .esb archive has a simple ESB service that uses a custom action defined in the MyAction.jar in the lib dir of the .esb archive.  It deploys fine on SOA-P Embedded 4.3 CP02 "default" configuration, but fails with ClassNotFoundException on SOA-P Embedded 5.0 ER2 "default" configuration.  Here is the SOA-P Server Console log:

13:09:19,698 INFO  [EsbDeployment] Starting ESB Deployment 'EsbProjectWithLib.esb'
13:09:19,782 INFO  [AbstractFileGateway] No value specified for: max-millis-for-response -  This will be an 'inbound-only' gateway
13:09:19,785 ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfszip:/home/apestel/Products/jboss-soa-p.5.0.0/jboss-as/server/default/deploy/EsbProjectWithLib.esb/ state=Create
java.lang.RuntimeException: java.lang.RuntimeException: Failed to find action class 'com.test.MyAction'.
	at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:147)
	at org.jboss.soa.esb.listeners.deployers.mc.EsbDeployment.start(EsbDeployment.java:121)
	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:243)
	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:111)
	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
	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:1633)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
	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:1440)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
	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.hotdeploy.HDScanner.scan(HDScanner.java:371)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:256)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: Failed to find action class 'com.test.MyAction'.
	at org.jboss.soa.esb.listeners.config.mappers.XMLBeansModel.getContractPublisher(XMLBeansModel.java:379)
	at org.jboss.soa.esb.listeners.config.mappers.XMLBeansModel.getServicePublishers(XMLBeansModel.java:352)
	at org.jboss.soa.esb.listeners.config.model.Model101SchemaParser$Model101Adapter.getServicePublishers(Model101SchemaParser.java:117)
	at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:126)
	... 55 more
Caused by: java.lang.ClassNotFoundException: com.test.MyAction
	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:247)
	at org.jboss.soa.esb.util.ClassUtil.forName(ClassUtil.java:93)
	at org.jboss.soa.esb.listeners.config.mappers.XMLBeansModel.getContractPublisher(XMLBeansModel.java:377)
	... 58 more
13:09:19,787 INFO  [EsbDeployment] Destroying 'EsbProjectWithLib.esb'
13:09:19,829 WARN  [HDScanner] Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):

DEPLOYMENTS IN ERROR:
  Deployment "jboss.esb.vfszip:/home/apestel/Products/jboss-soa-p.5.0.0/jboss-as/server/default/deploy/EsbProjectWithLib.esb/" is in error due to the following reason(s): java.lang.ClassNotFoundException: com.test.MyAction

	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:994)
	at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:940)
	at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873)
	at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.checkComplete(MainDeployerAdapter.java:128)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:378)
	at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:256)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)

Comment 1 Aaron Pestel 2009-11-10 19:20:53 UTC
Attachment: Added: EsbProjectWithLib.esb


Comment 2 Daniel Bevenius 2009-11-11 10:09:57 UTC
This is a configurable option in the ESB. For more information please refer to this wiki page: http://www.jboss.org/community/wiki/JBossAS5integrationforESB4x

Comment 3 Aaron Pestel 2009-11-11 14:05:27 UTC
Ok, makes sense.  I verified that if I put the .jar in a "jars" directory or in the base .esb archive directory, then it works.

However, I don't think that is an acceptable solution to this Jira for two reasons:

1.)  JBDS creates an ESB project with a lib directory where users have been and will continue to assume that .esb dependent jars will need to go.  By default, that's not going to work for them anymore.

2.)  Existing users (like myself) are going to have .esb archives where the jars are in the "lib" directory and they work on SOA-P 4.3, but will not work on SOA-P 5.0

I would recommend that the configuration default to "lib" instead of "jars".  If we want to allow both, that's fine too.  But until JBDS is changed, I think "MyEsb.esb/lib" needs to be a default location for jars that the esb services are dependent on.

Comment 4 Daniel Bevenius 2009-11-11 14:14:46 UTC
We can certainly have both and more options if you have any other suggestions too. Please create a jira in the ESB project for this and I'll make sure it gets done. 

If this is a requirement for the platform then would updating deployers/esb.deployer/META-INF/esb-deployers-jboss-beans.xml be an option until we have updated the ESB project file:
 <property name="libs">
            <set elementClass="java.lang.String">
                <value>.</value>
                <value>jars</value>
                <value>lib</value>
            </set>
</property>

Thanks 

Comment 5 Aaron Pestel 2009-11-11 14:42:42 UTC
Link: Added: This issue related JBESB-2972


Comment 6 Aaron Pestel 2009-11-11 14:43:09 UTC
Link: Added: This issue is related to JBESB-2972


Comment 7 Aaron Pestel 2009-11-11 14:43:34 UTC
Link: Removed: This issue is related to JBESB-2972 


Comment 8 Aaron Pestel 2009-11-11 14:47:26 UTC
I've created the requested ESB jira (JBESB-2972) and linked to this Jira.  I really don't care as much what we decide to do on the ESB community side, I'm just trying to make sure SOA-P 5 is a smooth transition for my SOA-P 4.3 users.

Personally, I would just leave lib as the default unless there is a compelling reason to add a "jars" folder instead of a "lib" folder.  If there is a compelling reason for the change, then I would recommend leaving both of them until JBDS has been updated to create a "jars" folder in an ESB project instead of a "lib" folder.

Comment 9 Aaron Pestel 2009-11-11 14:48:05 UTC
Workaround Description: Added: Move .jar files to the root directory or "jars" directory of the .esb archive.


Comment 10 Len DiMaggio 2009-11-11 15:16:30 UTC
For new customers building new apps, the different "jar" name will not be a problem.

But - as Aaron says - for 4.3 users, the different name may cause confusion, and will require (manual) migration steps.

Why can't we have the default remain as 'lib' and document how users can define their own specific values?

Comment 11 Kevin Conner 2009-11-11 15:28:27 UTC
The problem is that there never *was* a default location.  The as4 behaviour was to recursively discover jars/deployments and deal with them, whereas the as5 behaviour has changed.

This will 'break' all deployments which contained nested jars etc, and is a consequence of moving to as5.

There are other restrictions, besides this.

Comment 12 Kevin Conner 2009-11-11 15:39:01 UTC
The other point to note is that the 'standard', as defined by our quickstarts, is to place the jars in the top level of the esb archive and this does work.

Comment 13 Aaron Pestel 2009-11-11 16:28:56 UTC
We could debate what defines "standard" in this case, but it would probably not be productive.  I just did a quick scan of the docs to see if our docs discuss this and I didn't see anything, so created this Jira:  JBESB-2974

Please note that this will still likely be an issue for new customers if they are using JBDS (which at least most of my new customers do).  When one creates an ESB project with JBDS, the ESB project has a "lib" directory automatically created.  I think most users will assume that is where JAR libraries go.  That's where I put my libraries before I started testing SOA-P 5 ER2.

One thing I haven't heard yet is the reason for the change to have a specific "jars" directory.  If the quickstarts put jars in the root directory and JBDS creates a "lib" dir for each ESB project, why did we create a different directory altogether for jars to go in?

Comment 14 Aaron Pestel 2009-11-11 16:29:23 UTC
Link: Added: This issue is related to JBESB-2974


Comment 15 Kevin Conner 2009-11-11 17:04:28 UTC
Debating it is not the issue, but giving us your requirement is.  What we have is a starting point and, while it will definitely not suit everybody, it does fit with the examples as *we* provide them.

As this change is part of the underlying AS, I would hope that there is EAP documentation that describes it.  In any case we do describe it in our wiki, as pointed out by Daniel earlier, and I'm sure this can be incorporated into the platform docs if necessary.

The ESB issue has been changed into a Feature Request, please add all your requirements to that task.

Comment 16 Aaron Pestel 2009-11-11 17:39:50 UTC
My requirements would be twofold:

1.)  ESB archives that deploy successfully on SOA-P 4.3 should also deploy successfully on SOA-P 5.0 unless there was some absolutely necessary change that will not allow us to maintain backward compatibility and therefore we are going to advertise it as clearly and obviously as possible to ease customer migration pains.

2.)  Whether JBDS is part of the ESB "we" team or not, our customers use them together and we want them to use them together.  Therefore, the projects and conventions that are created by the JBDS ESB plugin should work with the SOA-P.  Concretely, if JBDS creates an ESB project by default containing a lib directory, SOA-P should by default load JARs that are placed in that lib directory. 

As to the documentation, I hope we do not expect SOA-P users to look at EAP docs to figure out how to deploy JARs in .esb archives.  So yes, please incorporate this documentation into the platform docs. 

Comment 17 Kevin Conner 2009-11-11 17:47:29 UTC
1 - If it is something which is directly under our control then that should be the case

2- Not sure what JBDS is doing but, as far as I am aware, the version targeted for SOA 5 is still under development.

Please add your requirements to the JBESB issue so that we can flesh it out and investigate a way forward.

Comment 18 Burr Sutter 2009-11-11 18:14:02 UTC
This sounds like a backward compatibility issue therefore it needs to be documented at a minimum in the SOA-P5 docs.   I have asked Brian F to provide comment on the JBDS side of things.

Comment 19 Kevin Conner 2009-11-11 18:27:01 UTC
Okay, it seems that what I am trying to say is not clear enough so let me try again.

In many respects JBDS and lib/*.jar are irrelevant to this discussion.  AS4 allows any user of ESB the ability to use any structure they wish, and it works.  As 5 does not allow this as we currently have to be explicit.

If we just do what has been asked, 'fixing lib/*.jar' then something else will undoubtedly come up.  If we are going to enforce a structure, without people needing to add a simple xml file, then we need to step back and document what is *really* needed.

There are many structure being used out there, and nearly all of them will fail in some way with the move to as5.

as5 is a very different base from as4, with different requirements.

We need to gather broad requirements about what is needed, not just a single facet.

Comment 20 Max Rydahl Andersen 2009-11-11 19:04:44 UTC
from my pov 90% of this is purely a runtime issue not specific to JBDS.

That being said I always had a really weird feeling about .esb archives since I haven't been able to find 
any good explanation of the classloader logic for .esb's  (i.e. why aren't it just following standard EAR or Jar packaging
instead of mixing them both ?)

anyway, the current structure is based on the ESB docs and based on how the quickstarts looked for ESB 4.x afaik.

If we need something different for SOA-P 5 (and it's matching ESB?) we need to be told - but why change from lib to jars ? lib is the standard name used in EAR's for jar's that should be automatically added. Why another ?

In my opinion stick with having /lib since that is what worked and were used before ?





Comment 21 Kevin Conner 2009-11-12 09:54:53 UTC
Max, I completely agree with you that this should be a runtime issue and this would be the case, if we had a proper (enforceable) structure.

Unfortunately the as4 deployer did not disable the app server's 'russian doll' behaviour and this is why we are having this discussion.

As for the /lib structure, we have never had that.  It only worked for the JBDS deployments until now *because of* the 'russian doll' behaviour of the application server.  In the same manner, many other users of ESB have *their own* structure which also works as a consequence of that behaviour.

As I said earlier, focussing on /lib/*.jar is the *wrong problem*.


Comment 22 Max Rydahl Andersen 2009-11-12 13:09:58 UTC
Ok, but could we then be told what structure we should use instead ? Preferably one that works both on SOA 4 and SOA 5 so we dont have to maintain redundant behavior 

Saying you don't have /lib structure might be true for the core runtime not knowing specifically about it but both docs, examples, the tooling and the actual execution worked with /lib.





Comment 23 Kevin Conner 2009-11-12 14:29:49 UTC
Our docs and examples definitely do not deploy a lib directory, not sure about the JBDS ones.

Irrespective of that, what I am trying to get people to realise is that this issue extends well beyond adding /lib/*.jar to the classpath, for JBDS or otherwise.  I have already asked for explicit requirements to be attached to JBESB-2972 but so far nothing has been added.  My concern is that what is being asked for is not properly understood and that this will keep rolling on unless we take the time and address it properly.

Failing that the fallback options are as already described, adding a jboss-structure.xml to the deployment or changing the ESB deployer configuration.  I don't want to do the latter without full agreement of what is required.


Comment 24 Len DiMaggio 2010-01-15 13:36:10 UTC
Link: Added: This issue related SOA-1835


Comment 25 Len DiMaggio 2010-01-15 13:41:37 UTC
Link: Added: This issue related SOA-1837


Comment 26 Dana Mison 2010-01-27 01:47:30 UTC
Adding as a migration issue in the SOA 5.0.0 Release Notes:

The JBoss Enterprise SOA Platform 5.0 requires that JAR files in ESB archives are placed in either the
root directory of the archive or in the jars directory. Previous versions did not have this restriction.

JBoss Developer Studio creates ESB projects with a lib directory. Do not use this directory to store JAR files.

Comment 27 Aaron Pestel 2010-01-27 03:04:56 UTC
Link: Added: This issue related JBIDE-5740


Comment 28 Kevin Conner 2010-01-27 10:49:50 UTC
Sorry Darrin, the comment about the lib directory is now out of date.

JBESB-2972 has recently added jars in the lib directory to the classpath, explicitly for supporting JBDS.

Comment 29 Dana Mison 2010-01-31 23:17:07 UTC
ok, migration issue note updated to:

The JBoss Enterprise SOA Platform 5.0 requires that JAR files in ESB archives are placed in the root directory of the archive, the /jars directory, or the /lib directory . Previous versions did not have this restriction.  

Comment 30 Kevin Conner 2010-02-04 17:20:35 UTC
Len is going to create a separate issue for the doc changes, just to track separately.

This is now just representing the code changes.

Comment 31 Len DiMaggio 2010-02-09 14:52:18 UTC
Link: Added: This issue depends SOA-1927


Comment 32 Len DiMaggio 2010-02-09 17:52:49 UTC
Verified in CR1 build.


Note You need to log in before you can comment on or make changes to this bug.