This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 779194 - (SOA-1588) ESB deployments don't see classes in the lib dir of the.esb archive
ESB deployments don't see classes in the lib dir of the.esb archive
Status: CLOSED NEXTRELEASE
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB, Configuration, Integration, Compatibility (Show other bugs)
5.0.0 ER2
Unspecified Unspecified
urgent Severity urgent
: ---
: 5.0.0 ER8
Assigned To: Kevin Conner
http://jira.jboss.org/jira/browse/SOA...
:
Depends On: SOA-1927
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-10 14:20 EST by Aaron Pestel
Modified: 2010-02-09 12:52 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
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 12:52:49 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBESB-2972 None None None Never
JBoss Issue Tracker JBIDE-5740 None None None Never
JBoss Issue Tracker SOA-1588 None None None Never

  None (edit)
Description Aaron Pestel 2009-11-10 14:20:33 EST
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 14:20:53 EST
Attachment: Added: EsbProjectWithLib.esb
Comment 2 Daniel Bevenius 2009-11-11 05:09:57 EST
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 09:05:27 EST
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 09:14:46 EST
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 09:42:42 EST
Link: Added: This issue related JBESB-2972
Comment 6 Aaron Pestel 2009-11-11 09:43:09 EST
Link: Added: This issue is related to JBESB-2972
Comment 7 Aaron Pestel 2009-11-11 09:43:34 EST
Link: Removed: This issue is related to JBESB-2972 
Comment 8 Aaron Pestel 2009-11-11 09:47:26 EST
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 09:48:05 EST
Workaround Description: Added: Move .jar files to the root directory or "jars" directory of the .esb archive.
Comment 10 Len DiMaggio 2009-11-11 10:16:30 EST
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 10:28:27 EST
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 10:39:01 EST
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 11:28:56 EST
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 11:29:23 EST
Link: Added: This issue is related to JBESB-2974
Comment 15 Kevin Conner 2009-11-11 12:04:28 EST
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 12:39:50 EST
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 12:47:29 EST
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 13:14:02 EST
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 13:27:01 EST
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 14:04:44 EST
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 04:54:53 EST
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 08:09:58 EST
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 09:29:49 EST
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 08:36:10 EST
Link: Added: This issue related SOA-1835
Comment 25 Len DiMaggio 2010-01-15 08:41:37 EST
Link: Added: This issue related SOA-1837
Comment 26 Darrin Mison 2010-01-26 20:47:30 EST
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-26 22:04:56 EST
Link: Added: This issue related JBIDE-5740
Comment 28 Kevin Conner 2010-01-27 05:49:50 EST
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 Darrin Mison 2010-01-31 18:17:07 EST
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 12:20:35 EST
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 09:52:18 EST
Link: Added: This issue depends SOA-1927
Comment 32 Len DiMaggio 2010-02-09 12:52:49 EST
Verified in CR1 build.

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