July 2013 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-980) Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration)

by Lennart Jörelid (JIRA)

[ https://issues.jboss.org/browse/FORGE-980?page=com.atlassian.jira.plugin.... ] Lennart Jörelid commented on FORGE-980: --------------------------------------- h3. ClassLoading bug possibly identified I provided a classloading debug printout for both potential classloaders (i.e. ThreadContext classloader and getClass().getClassLoader()) [attached to this issue as a file]. Assuming those standard classloaders are the ones actually used (and no JBoss Modules magic contortions are used on this level, the analysis should prove valid. None of these 2 standard classloaders contain the JARs copies as module dependencies to the active plugin, and I believe that the root cause is illustrated in the debug printout in the attached jbossForgeClassLoadingDebugging_1_incorrectRejectionMaybe.png file - the pathFilter of the ModuleClassLoader has the REJECT flag set for the dependent JARs of the plugin, implying that no dependencies of the JAR holding the plugin are actually present within the classpath of the Forge Plugin class. h3. Initial conclusion This is a rather big bug, but should be decently simple to fix - given that the ModuleLoader pathFilter is a simple configuration property. Attaching a trace file, which acquires the URLs to "/META-INF/MANIFEST.MF" for both classloader hierarchies at two places (within the Forge Plugin's constructor and within the command handler method of the Plugin). Note 2 things: # The Forge APIs are available only in the Constructor of the plugin, and only through the ThreadContext classloader. Is this desired/done by design? (i.e. why not provide the forge APIs within the Forge Plugin handler methods too?) # From what I can see in the debug logs, the ModuleClassLoader claims that it should load classes from the locations where the dependent modules are kept... but it clearly does not. The module.xml in the dependencies directory under ~/.forge/plugins/..../dependencies/[correctPluginVersion]/ seems, however, to contain the correct resource-roots: {code:xml} $ cat module.xml <?xml version="1.0" encoding="UTF-8" standalone="no"?> <module xmlns="urn:jboss:module:1.0" name="se.jguru.nazgul.forge.factory.impl.aggregate.nazgul-forge-factory-impl-aggregate.dependencies" slot="1.0.0-SNAPSHOT-686874c7-26ea-4afb-a271-848133c8fb9c"> <resources> <resource-root path="nazgul-forge-factory-api-1.0.0-SNAPSHOT.jar"/> <resource-root path="nazgul-forge-factory-model-1.0.0-SNAPSHOT.jar"/> <resource-root path="nazgul-core-persistence-model-1.4.4-SNAPSHOT.jar"/> <resource-root path="nazgul-core-xmlbinding-api-1.4.4-SNAPSHOT.jar"/> <resource-root path="nazgul-core-reflection-api-1.4.4-SNAPSHOT.jar"/> <resource-root path="nazgul-core-algorithms-api-1.4.4-SNAPSHOT.jar"/> <resource-root path="jaxb-api-osgi-2.2.7.jar"/> <resource-root path="commons-lang3-3.1.jar"/> <resource-root path="nazgul-forge-analyzer-impl-nazgul-1.0.0-SNAPSHOT.jar"/> <resource-root path="nazgul-forge-analyzer-api-1.0.0-SNAPSHOT.jar"/> <resource-root path="slf4j-simple-1.5.10.jar"/> <resource-root path="slf4j-api-1.5.10.jar"/> <resource-root path="nazgul-tools-validation-aspect-2.0.7.jar"/> <resource-root path="nazgul-tools-validation-api-2.0.7.jar"/> <resource-root path="aspectjrt-1.7.2.jar"/> </resources> <dependencies> <module name="javax.api"/> <module name="org.jboss.forge.shell.api"/> </dependencies> </module> {code} > Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration) > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-980 > URL: https://issues.jboss.org/browse/FORGE-980 > Project: Forge > Issue Type: Bug > Reporter: Lennart Jörelid > Attachments: jbossForgeClassLoadingDebugging_1_incorrectRejectionMaybe.png, jbossForgeClassLoadingDebugging_2_okModuleClassLoader.png > > > https://community.jboss.org/message/825612 > Following a successful build, including unit tests for the Forge plugin, the installation (forge source-install . ) fails with a ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration within the ~/.forge/runtime.log. > This class is located in forge-maven-api, which should be available for all plugins being installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-980) Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration)

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-980?page=com.atlassian.jira.plugin.... ] George Gastaldi updated FORGE-980: ---------------------------------- Forum Reference: https://community.jboss.org/message/825612 > Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration) > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-980 > URL: https://issues.jboss.org/browse/FORGE-980 > Project: Forge > Issue Type: Bug > Reporter: Lennart Jörelid > Attachments: jbossForgeClassLoadingDebugging_1_incorrectRejectionMaybe.png, jbossForgeClassLoadingDebugging_2_okModuleClassLoader.png > > > https://community.jboss.org/message/825612 > Following a successful build, including unit tests for the Forge plugin, the installation (forge source-install . ) fails with a ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration within the ~/.forge/runtime.log. > This class is located in forge-maven-api, which should be available for all plugins being installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-980) Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration)

by Lennart Jörelid (JIRA)

[ https://issues.jboss.org/browse/FORGE-980?page=com.atlassian.jira.plugin.... ] Lennart Jörelid updated FORGE-980: ---------------------------------- Attachment: jbossForgeClassLoadingDebugging_1_incorrectRejectionMaybe.png Note that the Plugin JAR uses a ResourceLoader which has its pathFilter set to "ACCEPT", while the NativeLibraryResourceLoader has its pathFilter set to "REJECT". > Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration) > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-980 > URL: https://issues.jboss.org/browse/FORGE-980 > Project: Forge > Issue Type: Bug > Reporter: Lennart Jörelid > Attachments: jbossForgeClassLoadingDebugging_1_incorrectRejectionMaybe.png, jbossForgeClassLoadingDebugging_2_okModuleClassLoader.png > > > https://community.jboss.org/message/825612 > Following a successful build, including unit tests for the Forge plugin, the installation (forge source-install . ) fails with a ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration within the ~/.forge/runtime.log. > This class is located in forge-maven-api, which should be available for all plugins being installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-980) Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration)

by Lennart Jörelid (JIRA)

[ https://issues.jboss.org/browse/FORGE-980?page=com.atlassian.jira.plugin.... ] Lennart Jörelid updated FORGE-980: ---------------------------------- Attachment: jbossForgeClassLoadingDebugging_2_okModuleClassLoader.png Debug information for the ModuleClassLoader. > Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration) > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-980 > URL: https://issues.jboss.org/browse/FORGE-980 > Project: Forge > Issue Type: Bug > Reporter: Lennart Jörelid > Attachments: jbossForgeClassLoadingDebugging_1_incorrectRejectionMaybe.png, jbossForgeClassLoadingDebugging_2_okModuleClassLoader.png > > > https://community.jboss.org/message/825612 > Following a successful build, including unit tests for the Forge plugin, the installation (forge source-install . ) fails with a ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration within the ~/.forge/runtime.log. > This class is located in forge-maven-api, which should be available for all plugins being installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-980) Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration)

by Lennart Jörelid (JIRA)

[ https://issues.jboss.org/browse/FORGE-980?page=com.atlassian.jira.plugin.... ] Lennart Jörelid commented on FORGE-980: --------------------------------------- Fixed a project to simplify debugging, where the Plugin implementation itself does not use the abstract superclass from another Maven JAR (included in the module.xml of the active Plugin). Instead, I delegate to a class which, in turn, extends the abstract superclass from another Maven JAR. It seems that the classloading is completely broken here; the ClassNotFoundException is generated when trying to find a JBoss core class. Both the class and the module is definitely present, contrary to what is claimed by the JBoss ModuleClassLoader in the stacktrace above. Reproduced the error on a Windows 7 box as well: {code} Caused by: java.lang.ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration from [Module "se.jguru.nazgul.f orge.factory.impl.aggregate.nazgul-forge-factory-impl-aggregate.dependencies:1.0.0-SNAPSHOT-d4c152bc-963a-4600-a696-dee4 c9c34968" from local module loader @4d865b28 (roots: C:\Applications\forge-distribution-1.2.3.Final\modules,C:\Users\len jo\.forge\plugins,C:\Development\nazgul\nazgul_forge\factory\factory-impl-aggregate)]^M at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)^M at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)^M at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)^M at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)^M at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)^M at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)^M ... 11 more {code} The interesting thing is that the ModuleClassLoader seems to use a ResourceLoaderSpec which rejects the modules packaged with the Forge Plugin - but not the modules within the JBoss Forge distribution/modules folder. Attaching two screenshots showing debug information from the two active classloaders. > Failed retrieving forge modules (ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration) > ----------------------------------------------------------------------------------------------------- > > Key: FORGE-980 > URL: https://issues.jboss.org/browse/FORGE-980 > Project: Forge > Issue Type: Bug > Reporter: Lennart Jörelid > > https://community.jboss.org/message/825612 > Following a successful build, including unit tests for the Forge plugin, the installation (forge source-install . ) fails with a ClassNotFoundException: org.jboss.forge.maven.plugins.Configuration within the ~/.forge/runtime.log. > This class is located in forge-maven-api, which should be available for all plugins being installed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-990) Upgrade to Arquillian 1.1.0.Final

by George Gastaldi (JIRA)

George Gastaldi created FORGE-990: ------------------------------------- Summary: Upgrade to Arquillian 1.1.0.Final Key: FORGE-990 URL: https://issues.jboss.org/browse/FORGE-990 Project: Forge Issue Type: Component Upgrade Components: Test Harness Affects Versions: 2.0.0.Alpha6 Reporter: George Gastaldi Fix For: 2.x Future -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-989) Support rollback of installed addons

by George Gastaldi (JIRA)

George Gastaldi created FORGE-989: ------------------------------------- Summary: Support rollback of installed addons Key: FORGE-989 URL: https://issues.jboss.org/browse/FORGE-989 Project: Forge Issue Type: Feature Request Components: Addon Manager Affects Versions: 2.0.0.Alpha6 Reporter: George Gastaldi Assignee: George Gastaldi Priority: Critical Fix For: 2.0.0.Alpha7 After an installation is performed, it should be possible to revert the repository to a previous state. It should be possible to log every install/remove request for each addon and group them by transaction savepoints. Eg: - Install Addon A which depends on B,C,D ( C and D already installed) Log: Transaction #1 Addon A: INSTALLED Addon B: INSTALLED - Install Addon E which depends on A Log: Transaction #2 Addon E: INSTALLED Rollback of each transaction should have the following behavior: - Rollback of Transaction #2 should remove Addon E. - Rollback of Transaction #1 should remove A, B. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-988) Refactor AddonManager to support addon version conflicts

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-988?page=com.atlassian.jira.plugin.... ] George Gastaldi updated FORGE-988: ---------------------------------- Component/s: Addon Manager (was: Container) > Refactor AddonManager to support addon version conflicts > -------------------------------------------------------- > > Key: FORGE-988 > URL: https://issues.jboss.org/browse/FORGE-988 > Project: Forge > Issue Type: Enhancement > Components: Addon Manager > Affects Versions: 2.0.0.Alpha6 > Reporter: George Gastaldi > Assignee: George Gastaldi > Priority: Critical > Fix For: 2.0.0.Alpha7 > > > Given that Addons A(1.0), B (1.0), C(1.0) are installed in an AddonRepository, and C(1.0) depends on B(1.0), when an addon D(1.0) to be installed requires B(1.1), there should be a way to warn against incompatibilities and let the user decide what to do. Same when D(1.0) depends on B(2.0) > Basically an addon version is composed of Major.Minor.Micro > In relation to the installed addon version and the requested addon version the following rules should be followed: > - When Major version is different, the addons are assumed be completely incompatible (even if in practice that is not true). Fail installation > - When Minor version is different, compatibility may be assured only if the requested version is less or equal to the required version. Prompt for installation of necessary version. > - When Micro version is different, the addon is totally compatible, thus no compatibility check is required. No problem to install -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-988) Refactor AddonManager to support addon version conflicts

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-988?page=com.atlassian.jira.plugin.... ] Work on FORGE-988 started by George Gastaldi. > Refactor AddonManager to support addon version conflicts > -------------------------------------------------------- > > Key: FORGE-988 > URL: https://issues.jboss.org/browse/FORGE-988 > Project: Forge > Issue Type: Enhancement > Components: Container > Affects Versions: 2.0.0.Alpha6 > Reporter: George Gastaldi > Assignee: George Gastaldi > Priority: Critical > Fix For: 2.0.0.Alpha7 > > > Given that Addons A(1.0), B (1.0), C(1.0) are installed in an AddonRepository, and C(1.0) depends on B(1.0), when an addon D(1.0) to be installed requires B(1.1), there should be a way to warn against incompatibilities and let the user decide what to do. Same when D(1.0) depends on B(2.0) > Basically an addon version is composed of Major.Minor.Micro > In relation to the installed addon version and the requested addon version the following rules should be followed: > - When Major version is different, the addons are assumed be completely incompatible (even if in practice that is not true). Fail installation > - When Minor version is different, compatibility may be assured only if the requested version is less or equal to the required version. Prompt for installation of necessary version. > - When Micro version is different, the addon is totally compatible, thus no compatibility check is required. No problem to install -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (FORGE-988) Refactor AddonManager to support addon version conflicts

by George Gastaldi (JIRA)

George Gastaldi created FORGE-988: ------------------------------------- Summary: Refactor AddonManager to support addon version conflicts Key: FORGE-988 URL: https://issues.jboss.org/browse/FORGE-988 Project: Forge Issue Type: Enhancement Components: Container Affects Versions: 2.0.0.Alpha6 Reporter: George Gastaldi Assignee: George Gastaldi Priority: Critical Fix For: 2.0.0.Alpha7 Given that Addons A(1.0), B (1.0), C(1.0) are installed in an AddonRepository, and C(1.0) depends on B(1.0), when an addon D(1.0) to be installed requires B(1.1), there should be a way to warn against incompatibilities and let the user decide what to do. Same when D(1.0) depends on B(2.0) Basically an addon version is composed of Major.Minor.Micro In relation to the installed addon version and the requested addon version the following rules should be followed: - When Major version is different, the addons are assumed be completely incompatible (even if in practice that is not true). Fail installation - When Minor version is different, compatibility may be assured only if the requested version is less or equal to the required version. Prompt for installation of necessary version. - When Micro version is different, the addon is totally compatible, thus no compatibility check is required. No problem to install -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues July 2013