[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on AS7-708: --------------------------------- Can you go into more detail? Looking at SEAMFORGE-156 I don't see exactly what is being asked for; in particular I don't know what you mean by "classpath scanning". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- To elaborate on this issue: 1. JBoss AS 7 appears to have some functionality that scans classes in JARs upon deployment. Presumably it is looking for CDI/JPA/Bean Validation annotations (just a guess). 2. This functionality fails if the classes being scanned refer to other classes (either through field types or method parameters) that are not on the classpath. I do not believe it is realistic to expect to go hunting through all classes in a JAR and that all of them should resolve. It is quite common for a JAR to have optional dependencies. 3. JBoss AS 6 had (I think) a very similar scanning mechanism. There, you could configure /server/default/deployers/scanning-deployers-jboss-beans.xml to ignore certain exceptions. Many exceptions were ignored by default (including NoClassDefFoundError). I do not know what the equivalent is in AS 7. 4. I attach a WAR that fails to deploy with the following error. Basically, Spring is not on the classpath and metawidget-all.jar has an optional dependency on Spring. However AS 7 should be more forgiving if it is going to go calling Class.privateGetDeclaredFields(): 13:03:04,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."catch-demo.war".INSTALL: org.jboss.msc.service.StartException in servi ce jboss.deployment.unit."catch-demo.war".INSTALL: Failed to process phase INSTALL of deployment "catch-demo.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] Caused by: java.lang.NoClassDefFoundError: org/springframework/context/MessageSource at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_20] at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_20] at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_20] at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:53) at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:65) at org.jboss.as.ee.component.AbstractComponentDescription.prepareComponentConfiguration(AbstractComponentDescription.java:392) at org.jboss.as.ee.component.AbstractComponentDescription.createComponentConfiguration(AbstractComponentDescription.java:363) at org.jboss.as.ee.component.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:104) at org.jboss.as.ee.component.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:67) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102) ... 4 more Caused by: java.lang.ClassNotFoundException: org.springframework.context.MessageSource from [Module "deployment.catch-demo.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17] ... 14 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard edited comment on AS7-708 at 5/2/11 11:16 PM: -------------------------------------------------------------- To elaborate on this issue: 1. JBoss AS 7 appears to have some functionality that scans classes in JARs upon deployment. Presumably it is looking for CDI/JPA/Bean Validation annotations (just a guess). 2. This functionality fails if the classes being scanned refer to other classes (either through field types or method parameters) that are not on the classpath. I do not believe it is realistic to expect to go hunting through all classes in a JAR and that all of them should resolve. It is quite common for a JAR to have optional dependencies. 3. JBoss AS 6 had (I think) a very similar scanning mechanism. There, you could configure /server/default/deployers/scanning-deployers-jboss-beans.xml to ignore certain exceptions. Many exceptions were ignored by default (including NoClassDefFoundError). I do not know what the equivalent is in AS 7. 4. I attach a WAR that fails to deploy on AS 7 (jboss-7.0.0.Beta3) with the following error. Basically, Spring is not on the classpath and metawidget-all.jar has an optional dependency on Spring. However AS 7 should be more forgiving if it is going to go calling Class.privateGetDeclaredFields() - it could trigger all manner of exceptions (see scanning-deployers-jboss-beans.xml). 13:03:04,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."catch-demo.war".INSTALL: org.jboss.msc.service.StartException in servi ce jboss.deployment.unit."catch-demo.war".INSTALL: Failed to process phase INSTALL of deployment "catch-demo.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] Caused by: java.lang.NoClassDefFoundError: org/springframework/context/MessageSource at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_20] at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_20] at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_20] at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:53) at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:65) at org.jboss.as.ee.component.AbstractComponentDescription.prepareComponentConfiguration(AbstractComponentDescription.java:392) at org.jboss.as.ee.component.AbstractComponentDescription.createComponentConfiguration(AbstractComponentDescription.java:363) at org.jboss.as.ee.component.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:104) at org.jboss.as.ee.component.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:67) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102) ... 4 more Caused by: java.lang.ClassNotFoundException: org.springframework.context.MessageSource from [Module "deployment.catch-demo.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17] ... 14 more was (Author: kennardconsulting): To elaborate on this issue: 1. JBoss AS 7 appears to have some functionality that scans classes in JARs upon deployment. Presumably it is looking for CDI/JPA/Bean Validation annotations (just a guess). 2. This functionality fails if the classes being scanned refer to other classes (either through field types or method parameters) that are not on the classpath. I do not believe it is realistic to expect to go hunting through all classes in a JAR and that all of them should resolve. It is quite common for a JAR to have optional dependencies. 3. JBoss AS 6 had (I think) a very similar scanning mechanism. There, you could configure /server/default/deployers/scanning-deployers-jboss-beans.xml to ignore certain exceptions. Many exceptions were ignored by default (including NoClassDefFoundError). I do not know what the equivalent is in AS 7. 4. I attach a WAR that fails to deploy on AS 7 (jboss-7.0.0.Beta3) with the following error. Basically, Spring is not on the classpath and metawidget-all.jar has an optional dependency on Spring. However AS 7 should be more forgiving if it is going to go calling Class.privateGetDeclaredFields(): 13:03:04,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."catch-demo.war".INSTALL: org.jboss.msc.service.StartException in servi ce jboss.deployment.unit."catch-demo.war".INSTALL: Failed to process phase INSTALL of deployment "catch-demo.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] Caused by: java.lang.NoClassDefFoundError: org/springframework/context/MessageSource at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_20] at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_20] at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_20] at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:53) at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:65) at org.jboss.as.ee.component.AbstractComponentDescription.prepareComponentConfiguration(AbstractComponentDescription.java:392) at org.jboss.as.ee.component.AbstractComponentDescription.createComponentConfiguration(AbstractComponentDescription.java:363) at org.jboss.as.ee.component.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:104) at org.jboss.as.ee.component.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:67) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102) ... 4 more Caused by: java.lang.ClassNotFoundException: org.springframework.context.MessageSource from [Module "deployment.catch-demo.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17] ... 14 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on AS7-708: --------------------------------- Ah I see. That's not actually what is happening here. The class reflection index is something that is used to cache information about classes which are referenced by deployment descriptors, annotated with Java EE annotations, or referenced thereby. Suppressing the exception is definitely not the appropriate solution here, since AS 7 approaches annotation scanning completely differently from AS 6. What might be a better solution is to allow the specification of a pattern which class names can be matched against, which tells the scanner to ignore annotations (maybe just certain annotations) from that class. As an aside, the error message here is pretty awful. However, we are retooling part of the EE component installation process so I suspect that once that is done it will look somewhat better. But ideally we'd have an error saying "Failed to install EJB class org.foo.MyWhatever" before going into the mind-numbing detail, so the user at least knows where to look. Solutions for deployment issues should follow directly from the errors describing them. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- David, Thanks for the prompt response and thorough analysis. When you say "The error here is the result of actually attempting to install a component (usually an EJB but could also be a ManagedBean or a servlet)". I am not sure if any classes in metawidget-all.jar qualify? None are marked @Session or @Entity or @ManagedBean, and none are Servlets. Can you investigate further to see which class is triggering the error? Then I will make changes to metawidget-all.jar if I can. Regards, Richard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on AS7-708: --------------------------------- Interesting. It may alternatively be a class referenced in an annotation like @Interceptor. I will try to scan that JAR as soon as I get the chance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Lincoln Baxter III commented on AS7-708: ---------------------------------------- I am experiencing the same problem with SeamForge generated applications using metawidget. I see AS is crashing on something, most likely an import statement that cannot be resolved due to the fact that Spring is not bundled in the application. This seems like a scanning bug to me. AS should not fail if a file it scans cannot be successfully classloaded/resolved. People may very well put compiled classes without dependencies into their JAR files. AS should probably warn if this occurs, but the exception should not be Fatal. This is currently blocking us from getting SeamForge apps deploying on AS7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on AS7-708: --------------------------------- I'm not arguing that it shouldn't be fixed. I'm just saying that regardless of how this "seems", this is not part of the scanning phase like it was in AS 6, so arguing about ignoring the error in the scanning phase is wasting breath. This exception is being thrown once all components have been already been discovered (via scanning and descriptor processing), and are on their way to being instantiated, that is all. The scanning layer has no reason to believe that there is anything amiss about the components it is trying to instantiate. I don't think a blanket "ignore errors" is necessarily wise either. I think we should: # fix the error message to say exactly what component failed, what kind it is, and why it failed (right now it's just giving the "why" without the "what") ## In the component description, we can link the resource root, provide a textual component type ("EJB", "Managed Bean", etc.), and a source file (deployment descriptor, class file), so when exceptions are thrown, we can use that information to present cogent error messages. ## In the instantiation phase we can make sure to catch all exception types and supplement them with this info. # do one of the following: ## provide deployment descriptor overrides to disable certain components by name or class ## provide descriptor overrides to disable annotation and/or descriptor scanning on a per-JAR basis (if this error is being triggered by a bundled JAR for example) ## provide descriptor overrides to disable components by JAR (bundled JARs again) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on AS7-708: --------------------------------- I understand why we'd want this to work. The problem is that if there's no way to distinguish this error from a legitimate problem in a user deployment, it will cause management issues. If a deployment goes wrong, people will expect their deployment plans to roll things back to prevent a possible disaster in customer-facing applications. So we need to be able to tell the difference between a "safe" missing class and a problematic one. That distinction might or might not be possible. If not, then we must err on the side of proper error reporting. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] jaikiran pai edited comment on AS7-708 at 5/17/11 2:41 AM: ----------------------------------------------------------- Your .war contains a .war/WEB-INF/lib/metawidget-all.jar which contains metawidget-all.jar/META-INF/metawidget-spring.tld (among other tlds). This tld file leads to the org.metawidget.jsp.tagext.html.spring.SpringMetawidgetTag class being picked up as a EE module class and this later leads to the NoClassDefFoundError due to the missing Spring libraries. Technically, as per spec, all tlds at spec defined locations (like this one) are eligible for annotation processing (among other things). So I believe you'll have to probably repackage that jar to include the Spring tlds only in a Spring environment or maybe in general, we could somehow allow skipping certain tlds (and other such component defining artifacts) during deployment (David?). As of now, I've added some log messages in the code (at DEBUG level) https://github.com/jaikiran/jboss-as/commit/7b79aa658066b1e355975249101b5... to atleast help us identify which class leads to this problem. I'll ask David to pull this upstream. was (Author: jaikiran): Your .war contains a .war/WEB-INF/lib/metawidget-all.jar which contains metawidget-all.jar/META-INF/metawidget-spring.tld (among other tlds). This tld file leads to the org.metawidget.jsp.tagext.html.spring.SpringMetawidgetTag class being picked up as a EE module class and this later leads to the NoClassDefFoundError due to the missing Spring libraries. Technically, as per spec, all tlds at spec defined locations (like this one) are eligible for annotation processing (among other things). So I believe you'll have to probably repackage that jar to include the Spring tlds only in a Spring environment or maybe in general, we could somehow allow certain tlds (and other such component defining artifacts) from being picked up during deployment (David?). As of now, I've added some log messages in the code (at DEBUG level) https://github.com/jaikiran/jboss-as/commit/7b79aa658066b1e355975249101b5... to atleast help us identify which class leads to this problem. I'll ask David to pull this upstream. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- So the logic here is: JBoss AS 7 is trying to load the class to see what annotations it has, because *if* it has annotations like @ManagedBean or @Stateless then JBoss AS 7 needs to prepare it for injection/something? However, in this case the offending class does *not* have any such annotations. Could we perhaps say that 'being unable to determine if an eligible class has annotations' and 'being unable to act upon the annotations defined in an eligible class' are (subtly) different things? That the first could be a warning and the latter an error? Because presumably many classes are 'eligible' and this is going to cause problems for JARs with optional dependencies? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- Jaikiran, Understood. My concern is that "a feature which would allow skipping certain jars" sounds like something each JBoss end-user is going to have to configure? I would be much happier if this were the other way around: a warning by default and "a feature which would allow being more strict"? You could still give a hard error if you can actually determine the class has annotations, just not for classes you can't instantiate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- Jaikiran, Yes, deploys fine on Glassfish 3.1 Final. Regards, Richard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Lincoln Baxter III commented on AS7-708: ---------------------------------------- I think that the best user experience in this case would be to do what weld does when it cannot load a class to scan it, and ignore the class while proceeding with the deployment. https://issues.jboss.org/browse/WELD-740 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Cloves Almeida commented on AS7-708: ------------------------------------ The Vaadin JAR import classes on gwt-user (they have a justifiable use for that) that are only needed compile-time. Because of this error, one is unable to deploy Vaadin applications properly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- Can I humbly suggest a compromise? It sounds like this is affecting several projects, but unfortunately it's a complex issue. It's going to take a while to 'come up with the right set of requirements'. So while we're all debating that, can we just have this hard error turned into a log (WARN, even an ERROR or SEVERE if you want) rather than stopping the whole deployment? We can turn it back into 'stopping the whole deployment' once we're sure what the requirements are. Richard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Lincoln Baxter III commented on AS7-708: ---------------------------------------- I agree with this course of action. Halting deployment is almost always a bad idea! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- Gerry, Sorry for your pain! Note that a workaround for Metawidget is to use modular dependencies (and not include ones you don't need, such as the Spring ones). See http://metawidget.org/doc/reference/en/html/ch09s05.html#section-howto-pe... However, I would love to see this resolved as Lincoln suggested. Clearly it is impacting users. Regards, Richard. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.sy... ] Richard Kennard commented on AS7-708: ------------------------------------- Fair enough. Opened new AS7-2077 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira