[ https://issues.jboss.org/browse/JBDS-2185?page=com.atlassian.jira.plugin.... ] Craig Ringer updated JBDS-2185: ------------------------------- Description: When attempting to import JBoss AS 7.1.1.Final, checked out from git, as a Maven project into JBoss Developer Studio 5.0 beta 3 on an x64 Fedora machine with JDK7, JBoss Developer Studio becomes unresponsive partway through the import. It sometimes then fails with an error message, and sometimes just ends up stuck in what appears to be some kind of infinite loop until killed. I haven't installed any add-ons or extras, it's stock JBoss Developer Studio 5.0 Beta 3. I've tried increasing the memory parameters from the already generous initial allocations to: -Xms512m -Xmx1592m with no improvement. I have 8GB to play with so I'll be throwing a ridiculous amount of RAM at and trying again, but this should not be necessary in any case, not just to *import* a maven project, even a big one. All I'm trying to do is import AS7 so I can add the AS7 project to the source search path when debugging a test case that's triggering a bug in AS7, so I don't have to manually add each and every source jar from as7 to my source search path. This seemed like the easy way to do it. was: When attempting to import JBoss AS 7.1.1.Final, checked out from git, as a Maven project into JBoss Developer Studio 5.0 beta 3, JBoss Developer Studio becomes unresponsive partway through the import. It sometimes then fails with an error message, and sometimes just ends up stuck in what appears to be some kind of infinite loop until killed. I haven't installed any add-ons or extras, it's stock JBoss Developer Studio 5.0 Beta 3. I've tried increasing the memory parameters from the already generous initial allocations to: -Xms512m -Xmx1592m with no improvement. I have 8GB to play with so I'll be throwing a ridiculous amount of RAM at and trying again, but this should not be necessary in any case, not just to *import* a maven project, even a big one. Steps to Reproduce: git clone git://github.com/jbossas/jboss-as.git jboss-as cd jboss-as git checkout 7.1.1.Final ./build.sh mvn dependency:sources mvn dependency:resolve -Dclassifier=javadoc then launch jbdevstudio and: File->Import Maven -> Existing Maven Projects Browse for your jboss-as dir with a checked out copy of 7.1.1.Final in it. Wait while JBDS5 analyses each POM. Proceed to import all modules. You will be prompted with the warning: "No marketplace entries found to handle javacc-maven-plugin:2.5:jjtree-javacc in Eclipse. Please see Help for more information." regarding cmp/pom.xml. The action proposed is "Resolve Later". Click "Finish"; you don't care if the project doesn't build right now, you just want to import it. The import will begin and the modules will show up in the workspace's projects list, but the UI will be non-responsive except for the moving progress bouncer at the bottom-right and a percentage completion marker. This will reach somewhere between 93% and 98% before ceasing to advance. After some minutes or hours the frame of a dialog may appear overlaid over jbdevstudio with no content in it. Sometimes this dialog gets content (though still no title bar) reading: "An internal error occurred while showing an internal error." "You are recommended to exit the workbench" "Subsequent errors may happen and may terminate the workbench without warning." "See the .log file for more details." "Do you want to exit the workbench?" "[Yes] [No]" At least on my Gnome 3 Shell system the dialog is not responsive to mouse input. In my most recent trial with an import of only a subset of AS7 I was able to dismiss it with the escape key; on previous occasions it's been totally nonresponsive or blank. was: git clone git://github.com/jbossas/jboss-as.git jboss-as cd jboss-as git checkout 7.1.1.Final ./build.sh mvn dependency:sources mvn dependency:resolve -Dclassifier=javadoc then launch jbdevstudio and: File->Import Maven -> Existing Maven Projects Browse for your jboss-as dir with a checked out copy of 7.1.1.Final in it. Proceed to import all modules. The import will begin and the modules will show up in the workspace's projects list, but the UI will be non-responsive except for the moving progress bouncer at the bottom-right and a percentage completion marker. This will reach somewhere between 93% and 98% before ceasing to advance. After some minutes or hours the frame of a dialog may appear overlaid over jbdevstudio with no content in it. Sometimes this dialog gets content (though still no title bar) reading: "An internal error occurred while showing an internal error." "You are recommended to exit the workbench" "Subsequent errors may happen and may terminate the workbench without warning." "See the .log file for more details." "Do you want to exit the workbench?" "[Yes] [No]" At least on my Gnome 3 Shell system the dialog is not responsive to mouse input. In my most recent trial with an import of only a subset of AS7 I was able to dismiss it with the escape key; on previous occasions it's been totally nonresponsive or blank. -- 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/JBDS-2185?page=com.atlassian.jira.plugin.... ] Craig Ringer commented on JBDS-2185: ------------------------------------ Frustratingly, I can't reproduce the total crash on a clean workspace and clean git checkout now. I always get the NPE during import, but JBDS5 doesn't seem to be becoming totally un-responsive like it was. Argh. After the import completes items in the menus like File->Exit and File->Switch Workspace stop doing anything, so it's clearly not all happy. -- 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/JBDS-2185?page=com.atlassian.jira.plugin.... ] Craig Ringer updated JBDS-2185: ------------------------------- Attachment: import-error-log.log.gz Error log from importing AS7 into clean workspace -- 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/JBDS-2185?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-2185: ------------------------------------------- Note, your log has some very weird exceptions concerning classnotfoundexceptions and SWT widget disposed errors. The latter explains why you can't call the menu actions, the first one ... no idea. needs investigation. -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-12087: ------------------------------------- Fixde NPE upstream : https://github.com/jbosstools/m2e-apt/issues/12 Now we need to include the proper build in JBDS and JBT Target Platform. -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen updated JBIDE-12087: ---------------------------------------- Priority: Blocker (was: Major) crap - that severely dampens the usability of APT if it is always enabled. Fred/Snjezana - got a patch ? -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-12087: ------------------------------------ The above fix for https://github.com/jbosstools/m2e-apt/issues/12 (https://github.com/jbosstools/m2e-apt/commit/f3354bfd3a5ce72b01d7e6ee6588...) was picked up in build #11, and is available in build #14 here: http://download.jboss.org/jbosstools/updates/requirements/m2eclipse/m2e-a... It is therefore also in: * JBT reqs mirror (Indigo SR2 - http://download.jboss.org/jbosstools/updates/indigo/SR2/) * JBT/JBDS Central -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Fred Bricon edited comment on JBIDE-12087 at 6/5/12 4:22 AM: ------------------------------------------------------------- 3 remarks : * m2e-apt enables AP only when a project dependency contains META-INF/services/com.sun.mirror.apt.AnnotationProcessorFactory, not when using the JDK as a JRE container. Turns out jboss as project have tools.jar as a transitive dependency because of their byteman dependency. So tools.jar is treated as any other dependencies, m2e-apt finds META-INF/services/com.sun.mirror.apt.AnnotationProcessorFactory and things go wrong. * ProjectUtils.containsAptProcessors() is only called on project configuration requests (AbstractProjectConfigurator#configure(request, monitor)), not on any project change, so project builds should not be impacted by these lookups. * The "javax.xml.parsers.FactoryConfigurationError: Provider _redirected._SAXParserFactory not found exception" exception looks like a severe leakage of classes from a project classpath to the Eclipse platform itself, _redirected._SAXParserFactory being one of jboss modules classes, so the problem is more serious than it looks IMO : I haven't tested yet but I have the feeling you could get the same catastrophic results enabling apt on a regular project, putting jboss modules on the factory path. We could try to ignore tools.jar when analysing APT dependencies before enabling JDT APT (but that'll probably require some ugly tricks) As for the use of a custom classloader, that might be a good thing, although I'm not sure how it'll help performance-wise here (except avoiding locking jars, an issue I haven't seen so far). m2e-apt can be disabled in the workspace or project preferences : Maven > Annotation Processing was (Author: fbricon): 3 remarks : * m2e-apt enables AP only when a project dependency contains META-INF/services/com.sun.mirror.apt.AnnotationProcessorFactory, not when using the JDK as a JRE container. Turns out jboss as project have tools.jar as a transitive dependency because of their byteman dependency. So tools.jar is treated as any other dependencies, m2e-apt finds META-INF/services/com.sun.mirror.apt.AnnotationProcessorFactory and things go wrong. * ProjectUtils.containsAptProcessors() is only called on project configuration requests (AbstractProjectConfigurator#configure(request, monitor)), not on any project change, so project builds should not be impacted by these lookups. * The "javax.xml.parsers.FactoryConfigurationError: Provider _redirected._SAXParserFactory not found exception" exception looks like a severe leakage classes from a project classpath to the Eclipse platform itself, _redirected._SAXParserFactory behind one of jboss modules classes, so the problem is more serious than it looks IMO : I haven't tested yet but I have the feeling you could get the same catastrophic results enabling apt on a regular project, putting jboss modules on the factory path. We could try to ignore tools.jar when analysing APT dependencies before enabling JDT APT (but that'll probably require some ugly tricks) As for the use of a custom classloader, that might be a good thing, although I'm not sure how it'll help performance-wise here (except avoiding locking jars, an issue I haven't seen so far). m2e-apt can be disabled in the workspace or project preferences : Maven > Annotation Processing -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-12087: --------------------------------------- A classloader is better optimized for searching classes/resources and would certainly increase performance. It is also possible to use the Eclipse Java model that doesn't lock jars and uses Java indexer for searching. There is yet another issue in m2e-apt. It adds all jars from the classpath to .factorypath which is not correct and probably causes the javax.xml.parsers.FactoryConfigurationError excption. BTW I haven't said m2e-apt locks jars. The JDK classloader locks them if you are using a special classloader. -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-12087: -------------------------------- Workaround Description: As a workaround, before importing the JBoss AS projects, m2e-apt needs to be disabled in the workspace preferences. * Window > Preferences > Maven > Annotation Processing * select "Do not automatically configure/execute Annotation Processing from pom.xml" Workaround: Workaround Exists -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Fred Bricon commented on JBIDE-12087: ------------------------------------- Ok so since we'd have a .factorypath, we don't need m2e-apt at all then, or do we? -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-12087: --------------------------------------------- Snejzana - you seem to be ignoring the point of m2e-apt. m2e-apt makes no sense to have if .factorypath is required. m2e-apt allows you to *not* use eclipse APT but delegate to Maven which has advantages (i.e. multiple output folders etc.) WELD-835 example is a *workaround* because m2e-apt was not present at the time. So suggesting to require .factorypath in users projects is not sane. What is sane or rather is problematic is that we cannot guard against "bad annotation processors" such as the JBoss Logging + userclasses with refs to JBoss Modules that tweak the running vm. Therefore we agreed on the triage call to disable m2e-apt by default until we can provide finer control than just global on/off. Beyond that you mention performance impact because all annotation processors are active - please take that to a separate issue and say where this is a problem since annotationprocessors are *not* invoked unless users classes actually have the annotation types they refer to; so this should have *minimal* impact. -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-12087: --------------------------------------- {quote} Snejzana - you seem to be ignoring the point of m2e-apt. {quote} I understand what your intention in adding m2e-apt was. I have said that we can't know if the user needs AP and, if he does need it, which jars need to be included in .factorypath. The most simple way to do it is to add the correct .factorypath to the project. Adding all jars to .factorypath isn't correct. This is the reason why I think the AP processor is correctly defined in WELD-835. We could do this some other way, but would have to have the following information: - AP needs/doesn't need to be enabled - if AP needs to be enabled, what jars/folders to include in the Eclipse APT generator {quote} What is sane or rather is problematic is that we cannot guard against "bad annotation processors" such as the JBoss Logging + userclasses with refs to JBoss Modules that tweak the running vm. {quote} If you mean LoggingToolsProcessor, this processor will work regularly if you add: jboss-logging-processor.jar jboss-logging.jar tools.jar org.eclipse.jst.ws.annotations.core (PLUGIN) to .factorypath However, when adding all the jars to the .factorypath, Eclipse will crash. {quote} Beyond that you mention performance impact because all annotation processors are active - please take that to a separate issue and say where this is a problem since annotationprocessors are not invoked unless users classes actually have the annotation types they refer to; so this should have minimal impact. {quote} If AP is enabled, it has to check if the user classes have or don't have annotations types each time when some class is changed. But, that is not the only problem with performance. The main problem is searching META-INF/services/xxxx resources. -- 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/JBIDE-12087?page=com.atlassian.jira.plugi... ] Fred Bricon resolved JBIDE-12087. --------------------------------- Resolution: Done m2e-apt has been disabled by default. Fixing LOGTOOL-51 should allow jboss-as users to enable it though. -- 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