9:17 a.m.
I have been trying to use Embedded Server API in the testsuite of one of the JBoss EJB3
components. The setup details are:
- JBoss AS 6.0 M1 (built from tag)
- Embedded Trunk (1.0.0-SNAPSHOT)
- Java 1.6
In the EJB3 component project, the embedded API is being pulled in by the following
dependency:
| <dependency>
| <groupId>org.jboss.embedded</groupId>
| <artifactId>jboss-embedded-depchain</artifactId>
| <version>1.0.0-SNAPSHOT</version>
| <scope>test</scope>
| <type>pom</type>
| </dependency>
|
The jboss-embedded-depchain brings in all the dependencies required for the JBoss AS.
Within the testsuite, the Embedded Server is booted as follows:
| private static org.jboss.logging.Logger logger = Logger.getLogger(Blah.class);
|
| /**
| * JBoss AS server
| */
| private JBossASEmbeddedServer server;
| ...// uses the classloader of the client application
| this.server = JBossASEmbeddedServerFactory.createServer();
| this.server.getConfiguration().jbossHome(jbossHome);
| logger.info("Starting server at " + jbossHome);
| this.server.start();
| logger.info("Server at " + jbossHome + " started");
|
So now on to the problems i am running into. The EJB3 component where this testsuite
resides, has it's own set of dependencies apart from the dependency on embedded server
API. So it declares it's own version of jboss-logging-spi (note, that i am using the
logging dependency as a simple example here, but the dependency can be anything).
Let's say the version being used in the project is 2.0.5.GA and the one being used
within the AS is 2.1.1.GA. So effectively, Maven decides that the version i declare in my
pom is the nearest and decides to include that in the classpath of this project. So i now
have 2.0.5.GA of jboss-logging in the classpath.
When i then try to create and boot the server through the embeded API, it fails to boot
because the AS expects a different version of logging spi (2.1.1.GA) to be available in
the classpath. Just for completeness, here's the exception stacktrace:
| 20:27:15,042 ERROR [AbstractKernelController] Error installing to Instantiated:
name=LogBridgeHandler state=Described
| java.lang.NoClassDefFoundError: org/jboss/logging/log4j/JDKLevel
| at org.jboss.logbridge.LevelMapper.<init>(LevelMapper.java:43)
| at org.jboss.logbridge.LogBridgeHandler.<init>(LogBridgeHandler.java:46)
| at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
| at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
| at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
| at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
| at
org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:149)
| at
org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
| at
org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
| at
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:295)
| at
org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:116)
| 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.InstantiateAction.installActionInternal(InstantiateAction.java:66)
| 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:1632)
| 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.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
| at
org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
| at
org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
| at
org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
| at
org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:92)
| at
org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:162)
| at
org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:318)
| at
org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:376)
| at
org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:434)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.lang.ClassNotFoundException: org.jboss.logging.log4j.JDKLevel
| 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)
| ... 38 more
|
But as i said, this is not limited to logging versions, but is a more generic issue.
So here's the questions:
1) Relying on Maven (or more generically a dependency resolution tool) to bring in the
right set of dependencies to boot the AS *from within some other project* probably
isn't the right thing? i.e. project A which is a client of the Embedded server API,
might need it's own version of an artifact which conflicts with the AS required
version of the same artifact. And then letting the build tool decide which one is best out
of these 2 versions could lead to issues.
Infact, in this scenario, *both* the versions should be brought in, for both the AS and
the client application to work as expected (see #2 below).
2) Theoretically, when the AS is being created/booted it should use its own different
classloader than the classloader of the application which is triggering the boot. This way
the client application can have it's own different versions of the same artifacts
which the AS requires. Probably, the Embedded server implementation should internally
create a classloader out of the right set of jars (/locations) for the AS and then use
that classloader for AS boot/deploy and other operations. How to get hold of the right set
of jars is a different step (step#3 below).
3) Maybe if the Embedded server API knows of JBOSS_HOME locations, then probably it can
create the classpath for the AS based on the known library locations of the AS
(JBOSS_HOME/lib, JBOSS_HOME/common/lib etc...)? But this is going to tie the Embedded
server implementation to a specific version of AS, since if tomorrow the AS decides to
have it's libraries in a different location then Embedded server implementation will
be affected too. Actually, it needs a bit more thinking, to get a solution.
Thoughts?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267903#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...