[GUVNOR-1538] Do not include gwt-dev in the guvnor-webapp classpath - JBoss Issue Tracker

Details

Type: Bug
Status: Resolved (View Workflow)
Priority: Critical
Resolution: Out of Date
Affects Version/s: drools-5.3.0.Beta1
Fix Version/s: drools-6.0.0.Alpha1
Labels:
None

Description

When deploying to jboss as 5.1 with the seam 3/weld upgrade:

11:34:44,013 ERROR [AbstractKernelController] Error installing to PreReal: name=vfszip:/home/gdesmet/opt/appserver/jboss-5.1.0.GA/server/default/deploy/guvnor-5.3.0-SNAPSHOT-jboss-as-5.1.war/ state=PostClassLoader mode=Manual requiredState=PreReal

org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/home/gdesmet/opt/appserver/jboss-5.1.0.GA/server/default/deploy/guvnor-5.3.0-SNAPSHOT-jboss-as-5.1.war/

        at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)

        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.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:662)

Caused by: java.lang.NoClassDefFoundError: com/google/gwt/core/ext/Generator

        at java.lang.ClassLoader.defineClass1(Native Method)

        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)

        at java.lang.ClassLoader.defineClass(ClassLoader.java:616)

        at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)

        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)

        at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)

        at java.security.AccessController.doPrivileged(Native Method)

        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)

        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)

        at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)

        at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)

        at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)

        at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)

        at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)

        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)

        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)

        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)

        at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

        at org.jboss.classloading.plugins.visitor.AbstractResourceContext.loadClass(AbstractResourceContext.java:118)

        at org.jboss.webbeans.integration.deployer.env.WebBeanDiscoveryDeployer$WBDiscoveryVisitor.visit(WebBeanDiscoveryDeployer.java:134)

        at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264)

        at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)

        at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:361)

        at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)

        at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)

        at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)

        at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)

        at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:306)

        at org.jboss.virtual.VFS.visit(VFS.java:421)

        at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:437)

        at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:101)

        at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:160)

        at org.jboss.webbeans.integration.deployer.env.WebBeanDiscoveryDeployer.deploy(WebBeanDiscoveryDeployer.java:109)

        at org.jboss.webbeans.integration.deployer.env.WebBeanDiscoveryDeployer.deploy(WebBeanDiscoveryDeployer.java:45)

        at org.jboss.deployers.vfs.spi.deployer.AbstractOptionalVFSRealDeployer.deploy(AbstractOptionalVFSRealDeployer.java:57)

        at org.jboss.deployers.spi.deployer.helpers.AbstractOptionalRealDeployer.internalDeploy(AbstractOptionalRealDeployer.java:74)

        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)

        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)

        ... 29 more

Caused by: java.lang.ClassNotFoundException: com.google.gwt.core.ext.Generator

        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)

        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

        at java.lang.Class.forName0(Native Method)

        at java.lang.Class.forName(Class.java:247)

        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:292)

        at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)

        at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)

        at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

        ... 68 more

Problem:
AssetEditorFactoryGenerator imports com.google.gwt.core.ext.Generator, a gwt-dev only class

Root problem:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/commit/55864f7fef03cab20ba656ae3268601e273ec439#commitcomment-453418

Gliffy Diagrams

Issue Links

blocks

GUVNOR-1448 Upgrade to Seam 3 and weld

Resolved

is blocked by

GUVNOR-1196 Build: Split up drools-guvnor into guvnor-gwt-client and guvnor-webapp

Resolved

relates to

GUVNOR-1494 Automatically discover and register Asset editors based on property file and asset editor annotation

Resolved

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Geoffrey De Smet added a comment - 14/Jul/11 6:20 AM

Looks like weld is scanning that class and failing on it as it extends the generator class. Which might explain why without the seam 3 upgrade it doesn't appear.
So how do we solve this? Reverting jervis's commit is to big. Splitting up gwt client and server side will bury me in merge conflicts...

Show

Geoffrey De Smet added a comment - 14/Jul/11 6:20 AM Looks like weld is scanning that class and failing on it as it extends the generator class. Which might explain why without the seam 3 upgrade it doesn't appear. So how do we solve this? Reverting jervis's commit is to big. Splitting up gwt client and server side will bury me in merge conflicts...

Hide

Permalink

Jervis Liu added a comment - 17/Jul/11 9:37 AM

Hi Geoffrey, I fixed it by removing AssetEditorFactoryGenerator from the build directory once gwt compile is done its job. As a side note, gwt-dev can not be removed from the pom dependencies. This is because AssetEditorFactoryGenerator has to be compiled by someone, so its either the javac or the gwt:compile. But it can not be compiled by gwt:compile as it is not a GWT client side code. Of course, the problem can be solved if gwt-maven-plugin is enhanced to have a goal to allow GWT to compile any utility or generator classes that are needed by gwt:compile, like what gwt-maven-plugin does with the gwt:generateAsyc goal. But to be honest, I do not see such a goal brings much benefit comparing to letting javac do the compile job except this way gwt can handle the build classpath explicitly. Anyway, let me know if the fix works for you.

Thanks,
Jervis

Show

Jervis Liu added a comment - 17/Jul/11 9:37 AM Hi Geoffrey, I fixed it by removing AssetEditorFactoryGenerator from the build directory once gwt compile is done its job. As a side note, gwt-dev can not be removed from the pom dependencies. This is because AssetEditorFactoryGenerator has to be compiled by someone, so its either the javac or the gwt:compile. But it can not be compiled by gwt:compile as it is not a GWT client side code. Of course, the problem can be solved if gwt-maven-plugin is enhanced to have a goal to allow GWT to compile any utility or generator classes that are needed by gwt:compile, like what gwt-maven-plugin does with the gwt:generateAsyc goal. But to be honest, I do not see such a goal brings much benefit comparing to letting javac do the compile job except this way gwt can handle the build classpath explicitly. Anyway, let me know if the fix works for you. Thanks, Jervis

Hide

Permalink

Geoffrey De Smet added a comment - 17/Jul/11 10:52 AM - edited

Thanks Jervis. Removing the gwt-dev jar dependency outright is not possible at this time.

I agree with that it's the maven-gwt-plugin that needs to fix this. I 'll leave the issue open, because having the gwt-dev jar in our dependencies is very high risk (and possible even already problematic) because the gwt-dev jar shades jdt-compiler (with an older version) and several other jars. In essence this means that our compile classpath != runtime classpath if gwt-dev is not the last in the java compiler classpath (which it is probably not, it's somewhere in the middle) (also note that it must be first in the gwt compiler classpath or compilation breaks, which it is due to a patch I send to maven-gwt-compiler).
Furthermore, users might depend on the guvnor-webapp pom.xml and therefor this gwt-dev shading problems might extend to their builds.

In short term, fixing ~~GUVNOR-1196~~ (splitting server and client side modules) will at least contain the issue to the client side.

Show

Geoffrey De Smet added a comment - 17/Jul/11 10:52 AM - edited Thanks Jervis. Removing the gwt-dev jar dependency outright is not possible at this time. I agree with that it's the maven-gwt-plugin that needs to fix this. I 'll leave the issue open, because having the gwt-dev jar in our dependencies is very high risk (and possible even already problematic) because the gwt-dev jar shades jdt-compiler (with an older version) and several other jars. In essence this means that our compile classpath != runtime classpath if gwt-dev is not the last in the java compiler classpath (which it is probably not, it's somewhere in the middle) (also note that it must be first in the gwt compiler classpath or compilation breaks, which it is due to a patch I send to maven-gwt-compiler). Furthermore, users might depend on the guvnor-webapp pom.xml and therefor this gwt-dev shading problems might extend to their builds. In short term, fixing GUVNOR-1196 (splitting server and client side modules) will at least contain the issue to the client side.

Hide

Permalink

Geoffrey De Smet added a comment - 11/Aug/11 11:19 AM

Because GWT-dev is on the classpath, it's impossible to upgrade to seam3-arquillian as gwt-dev shades tomcat which breaks arquillian (and because it's shaded, it can't be excluded properly).

Is there any way we can avoid from having GWT-dev in the classpath?

Show

Geoffrey De Smet added a comment - 11/Aug/11 11:19 AM Because GWT-dev is on the classpath, it's impossible to upgrade to seam3-arquillian as gwt-dev shades tomcat which breaks arquillian (and because it's shaded, it can't be excluded properly). Is there any way we can avoid from having GWT-dev in the classpath?

Hide

Permalink

Jervis Liu added a comment - 13/Aug/11 2:59 AM

We need GWT-dev as long as we still compile AssetEditorFactoryGenerator by javac. I was thinking of a gwt-maven-plugin goal that can compile AssetEditorFactoryGenerator using gwt-maven-plugin's own classpath.

The last resort is to write my own code generator instead of extending from GWT Generator.

I will chat with you on IRC to figure out which approach is best for our current situation. At the same time, if this stops your seam3 work, you can check in AssetEditorFactoryImpl.java to source control that is generated by AssetEditorFactoryGenerator then remove AssetEditorFactoryGenerator from code base temporarily.

Show

Jervis Liu added a comment - 13/Aug/11 2:59 AM We need GWT-dev as long as we still compile AssetEditorFactoryGenerator by javac. I was thinking of a gwt-maven-plugin goal that can compile AssetEditorFactoryGenerator using gwt-maven-plugin's own classpath. The last resort is to write my own code generator instead of extending from GWT Generator. I will chat with you on IRC to figure out which approach is best for our current situation. At the same time, if this stops your seam3 work, you can check in AssetEditorFactoryImpl.java to source control that is generated by AssetEditorFactoryGenerator then remove AssetEditorFactoryGenerator from code base temporarily.

Hide

Permalink

Geoffrey De Smet added a comment - 13/Aug/11 8:49 AM

The GWT maven-plugin patch is definitely a good idea, but how do we get gwt-dev in the classpath in our intellij/eclipse correctly without having to add it manually?
It would definitely need to be in it's own src directory (src/main/gwt-*-java for something.

A more pressing issue is to split up the gwtclient and webapp sources and that will fix some trouble (including the arquillian tomcat issue) too. But that's another deep rabbit hole

Meanwhile I've found a way to hack it on my fork, by getting tomcat before gwt-dev on the classpath - although it might cause trouble later (during gwt compilation or in hosted mode).

Show

Geoffrey De Smet added a comment - 13/Aug/11 8:49 AM The GWT maven-plugin patch is definitely a good idea, but how do we get gwt-dev in the classpath in our intellij/eclipse correctly without having to add it manually? It would definitely need to be in it's own src directory (src/main/gwt-*-java for something. A more pressing issue is to split up the gwtclient and webapp sources and that will fix some trouble (including the arquillian tomcat issue) too. But that's another deep rabbit hole Meanwhile I've found a way to hack it on my fork, by getting tomcat before gwt-dev on the classpath - although it might cause trouble later (during gwt compilation or in hosted mode).

Hide

Permalink

Michael Anstis added a comment - 18/Nov/13 4:29 AM

6.0.x does not package GWT libraries.

Show

Michael Anstis added a comment - 18/Nov/13 4:29 AM 6.0.x does not package GWT libraries.

People

Assignee:

Unassigned

Reporter:

Geoffrey De Smet

Votes:

0 Vote for this issue

Watchers:

4 Start watching this issue

Dates

Created:

14/Jul/11 5:47 AM

Updated:

18/Nov/13 4:29 AM

Resolved:

18/Nov/13 4:29 AM

Development

Agile

View on Board