You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/09/12 00:22:11 UTC
Another really strange mysterious build error
I sometimes get this error building openejb-core:
<testcase time="1.273"
name="org.openejb.deployment.UnpackedModuleDeploymentTest">
<error type="java.lang.NoSuchMethodError"
message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
ClassLoader;)V">java.lang.NoSuchMethodError:
org.apache.commons.logging.LogFactory.release(Ljava/lang/ClassLoader;)V
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
(MultiParentClassLoader.java:386)
at
org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
(JarFileClassLoader.java:147)
at org.apache.geronimo.kernel.config.Configuration.shutdown
(Configuration.java:762)
at org.apache.geronimo.kernel.config.Configuration.doStop
(Configuration.java:742)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
(SimpleConfigurationManager.java:718)
at
org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
(DeploymentConfigurationManager.java:161)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadConfi
guration(SimpleConfigurationManager.java:698)
at
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadConf
iguration(DeploymentConfigurationManager.java:157)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadConfi
guration(SimpleConfigurationManager.java:668)
at
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadConf
iguration(DeploymentConfigurationManager.java:153)
at org.apache.geronimo.deployment.DeploymentContext.close
(DeploymentContext.java:364)
at org.openejb.deployment.DeploymentTestSuite.setUp
(DeploymentTestSuite.java:201)
at org.openejb.deployment.DeploymentTestSuite.access$000
(DeploymentTestSuite.java:90)
at org.openejb.deployment.DeploymentTestSuite$1.protect
(DeploymentTestSuite.java:119)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at org.openejb.deployment.DeploymentTestSuite.run
(DeploymentTestSuite.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.maven.surefire.junit.JUnitTestSet.execute
(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSe
t(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
(SurefireBooter.java:225)
at org.apache.maven.surefire.booter.SurefireBooter.main
(SurefireBooter.java:747)
</error>
</testcase>
I can't quite imagine how this can occur. Can anyone else?
Anyway putting a try/catch block around the code to ignore the error
at least lets the test pass. Should I commit this or can anyone
think of a possible cause so we can actually fix it?
thanks
david jencks
Re: Another really strange mysterious build error
Posted by Jason Dillon <ja...@planet57.com>.
AFAIK, the only was to completely isolate ourselves from these issues
going forward is to have complete control over the dependencies used
in the build. That means, only our repo, only artifacts which we
have blessed to be used, known good pom's... and then version
control/notification system when artifacts change so that we can
track down when something breaks.
You are absolutely right though... this is a very fragile
environment... and I will even go on to say that Maven breeds
fragility in larger more complicated projects.
--jason
On Sep 13, 2006, at 6:53 AM, Kevan Miller wrote:
> I believe this problem was fixed last night by jason and david j
> with an OpenEJB change to trunk/openejb2/pom.xml. The change
> excludes a transitive dependency for commons-logging being pulled
> in for axion.
>
> IIUC, maven/surefire was actively pulling in transitive
> dependencies (unless excluded). In this case, when the itest was
> being run the axion dependency on the old version of commons-
> logging was taking precedence.
>
> This seems like a pretty fragile environment -- this class loading
> behavior could mask problems that might exist in a true server
> environment, or (as we saw here) generate unique itest problems.
> Jason/David, do I have this right? How do we resolve these issues
> in the future?
>
> --kevan
>
> On Sep 13, 2006, at 12:43 AM, anita kulshreshtha wrote:
>
>> As Jacek pointed out it is because of commons-logging jar with a
>> version prior to 1.0.3. It appears that one of the source of this jar
>> is geronimo-kernel! how is that possible?
>>
>> thanks
>> Anita
>>
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [ERROR] BUILD ERROR
>> [INFO]
>> ---------------------------------------------------------------------
>> ---
>> [INFO] Failed to resolve artifact.
>>
>> Missing:
>> ----------
>> 1) commons-logging:commons-logging:jar:1.0
>>
>> Try downloading the file manually from the project website.
>>
>> Then, install it using the command:
>> mvn install:install-file -DgroupId=commons-logging
>> -DartifactId=commons-lo
>> gging \
>> -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
>>
>> Path to dependency:
>> 1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT
>> 2)
>> org.apache.geronimo.modules:geronimo-axis-builder:jar:1.2-SNAPSHOT
>> 3) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-
>> SNAPSHOT
>> 4) commons-logging:commons-logging:jar:1.0
>>
>>
>> --- Jason Dillon <ja...@planet57.com> wrote:
>>
>>> I see this too... have not looked into it, but we need to fix this,
>>> its causing bootstrap builds of G to fail.
>>>
>>> --jason
>>>
>>>
>>> On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
>>>
>>>> I sometimes get this error building openejb-core:
>>>>
>>>> <testcase time="1.273"
>>>> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
>>>> <error type="java.lang.NoSuchMethodError"
>>>> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
>>>> ClassLoader;)V">java.lang.NoSuchMethodError:
>>>> org.apache.commons.logging.LogFactory.release(Ljava/lang/
>>>> ClassLoader;)V
>>>> at
>>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
>>>> (MultiParentClassLoader.java:386)
>>>> at
>>>> org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
>>>> (JarFileClassLoader.java:147)
>>>> at org.apache.geronimo.kernel.config.Configuration.shutdown
>>>
>>>> (Configuration.java:762)
>>>> at org.apache.geronimo.kernel.config.Configuration.doStop
>>>> (Configuration.java:742)
>>>> at
>>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
>>>
>>>> (SimpleConfigurationManager.java:718)
>>>> at
>>>>
>>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
>>>> (DeploymentConfigurationManager.java:161)
>>>> at
>>>>
>>>
>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCo
>> n
>>>
>>>> figuration(SimpleConfigurationManager.java:698)
>>>> at
>>>>
>>>
>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadC
>> o
>>>
>>>> nfiguration(DeploymentConfigurationManager.java:157)
>>>> at
>>>>
>>>
>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCo
>> n
>>>
>>>> figuration(SimpleConfigurationManager.java:668)
>>>> at
>>>>
>>>
>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadC
>> o
>>>
>>>> nfiguration(DeploymentConfigurationManager.java:153)
>>>> at org.apache.geronimo.deployment.DeploymentContext.close
>>>> (DeploymentContext.java:364)
>>>> at org.openejb.deployment.DeploymentTestSuite.setUp
>>>> (DeploymentTestSuite.java:201)
>>>> at org.openejb.deployment.DeploymentTestSuite.access$000
>>>> (DeploymentTestSuite.java:90)
>>>> at org.openejb.deployment.DeploymentTestSuite$1.protect
>>>> (DeploymentTestSuite.java:119)
>>>> at junit.framework.TestResult.runProtected(TestResult.java:
>>>
>>>> 124)
>>>> at org.openejb.deployment.DeploymentTestSuite.run
>>>> (DeploymentTestSuite.java:126)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>>> (NativeMethodAccessorImpl.java:39)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>>> (DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>>> at org.apache.maven.surefire.junit.JUnitTestSet.execute
>>>> (JUnitTestSet.java:210)
>>>> at
>>>>
>>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
>> t
>>>
>>>> Set(AbstractDirectoryTestSuite.java:135)
>>>> at
>>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
>>>> (AbstractDirectoryTestSuite.java:122)
>>>> at
>>> org.apache.maven.surefire.Surefire.run(Surefire.java:129)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>>> (NativeMethodAccessorImpl.java:39)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>>> (DelegatingMethodAccessorImpl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>>> at
>>>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>>>> (SurefireBooter.java:225)
>>>> at org.apache.maven.surefire.booter.SurefireBooter.main
>>>> (SurefireBooter.java:747)
>>>> </error>
>>>> </testcase>
>>>>
>>>> I can't quite imagine how this can occur. Can anyone else?
>>>>
>>>> Anyway putting a try/catch block around the code to ignore the
>>>> error at least lets the test pass. Should I commit this or can
>>>> anyone think of a possible cause so we can actually fix it?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>
>>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>
Re: Another really strange mysterious build error
Posted by Jason Dillon <ja...@planet57.com>.
Maven is not treating commons-logging differently... Maven just gets
easily confused when there are multiple versions of artifacts with
the same ids, some included some excluded.
I ran into this very problem, where it looked like special attention
was being given to commons-logging... and the solution I found was to
exclude all commons-logging 1.0.x and use commons-logging-api and
commons-logging-adapters from the new JCL 1.1
--jason
On Sep 13, 2006, at 8:30 AM, anita kulshreshtha wrote:
> The problem did go away after excluding commons-logging from
> axion.
> However there are 2 issues:
> 1. The path to dependency in '[INFO] Failed to resolve artifact'
> message is wrong. I have seen wrong path before also.
> 2. Maven is supposed to pull in all the transitive dependencies unless
> explicitly excluded. Maven2 seems to be treating commons-logging
> differently than the other jars. In an earlier encounter I had faced a
> similar problem:
> http://www.nabble.com/Re%3A-Questions-about-the-packaging-plugin-
> p3936387.html
> Here is an excerpt from today's debug output:
> [DEBUG] axion:axion:jar:1.0-M3-dev:test (selected for test)
> [DEBUG] commons-logging:commons-logging:jar:1.0:test (setting
> scope
> to: compile)
> [DEBUG] commons-collections:commons-collections:jar:3.0:test
> (selected for test)
> [DEBUG] commons-primitives:commons-primitives:jar:1.0:test
> (selected for test)
> [DEBUG] commons-codec:commons-codec:jar:1.2:test (selected for
> test)
> [DEBUG] While downloading javacc:javacc:3.2
> This artifact has been relocated to net.java.dev.javacc:javacc:3.2.
>
>
> [DEBUG] net.java.dev.javacc:javacc:jar:3.2:test (selected for
> test)
> Axion is a dependency in openejb-builder with 'test' scope. Maven
> sets all its dependencies as test scope. But commons-logging is set to
> compile! Does any one know why it should be like this.
>
> Thanks
> Anita
>
> --- Kevan Miller <ke...@gmail.com> wrote:
>
>> I believe this problem was fixed last night by jason and david j with
>>
>> an OpenEJB change to trunk/openejb2/pom.xml. The change excludes a
>> transitive dependency for commons-logging being pulled in for axion.
>>
>> IIUC, maven/surefire was actively pulling in transitive dependencies
>>
>> (unless excluded). In this case, when the itest was being run the
>> axion dependency on the old version of commons-logging was taking
>> precedence.
>>
>> This seems like a pretty fragile environment -- this class loading
>> behavior could mask problems that might exist in a true server
>> environment, or (as we saw here) generate unique itest problems.
>> Jason/David, do I have this right? How do we resolve these issues in
>>
>> the future?
>>
>> --kevan
>>
>> On Sep 13, 2006, at 12:43 AM, anita kulshreshtha wrote:
>>
>>> As Jacek pointed out it is because of commons-logging jar with a
>>> version prior to 1.0.3. It appears that one of the source of this
>> jar
>>> is geronimo-kernel! how is that possible?
>>>
>>> thanks
>>> Anita
>>>
>>> [INFO]
>>>
>>
> ----------------------------------------------------------------------
>>
>>> --
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>>
>>
> ----------------------------------------------------------------------
>>
>>> --
>>> [INFO] Failed to resolve artifact.
>>>
>>> Missing:
>>> ----------
>>> 1) commons-logging:commons-logging:jar:1.0
>>>
>>> Try downloading the file manually from the project website.
>>>
>>> Then, install it using the command:
>>> mvn install:install-file -DgroupId=commons-logging
>>> -DartifactId=commons-lo
>>> gging \
>>> -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
>>>
>>> Path to dependency:
>>> 1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT
>>> 2)
>>> org.apache.geronimo.modules:geronimo-axis-builder:jar:1.2-SNAPSHOT
>>> 3) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-
>>> SNAPSHOT
>>> 4) commons-logging:commons-logging:jar:1.0
>>>
>>>
>>> --- Jason Dillon <ja...@planet57.com> wrote:
>>>
>>>> I see this too... have not looked into it, but we need to fix
>> this,
>>>> its causing bootstrap builds of G to fail.
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
>>>>
>>>>> I sometimes get this error building openejb-core:
>>>>>
>>>>> <testcase time="1.273"
>>>>> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
>>>>> <error type="java.lang.NoSuchMethodError"
>>>>>
>> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
>>>>> ClassLoader;)V">java.lang.NoSuchMethodError:
>>>>> org.apache.commons.logging.LogFactory.release(Ljava/lang/
>>>>> ClassLoader;)V
>>>>> at
>>>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
>>>>> (MultiParentClassLoader.java:386)
>>>>> at
>>>>> org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
>>>>> (JarFileClassLoader.java:147)
>>>>> at
>> org.apache.geronimo.kernel.config.Configuration.shutdown
>>>>
>>>>> (Configuration.java:762)
>>>>> at org.apache.geronimo.kernel.config.Configuration.doStop
>>>>> (Configuration.java:742)
>>>>> at
>>>>>
>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
>>>>
>>>>> (SimpleConfigurationManager.java:718)
>>>>> at
>>>>>
>>>>
>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
>>>>> (DeploymentConfigurationManager.java:161)
>>>>> at
>>>>>
>>>>
>>>
>>
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
>>>>
>>>>> figuration(SimpleConfigurationManager.java:698)
>>>>> at
>>>>>
>>>>
>>>
>>
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
>>>>
>>>>> nfiguration(DeploymentConfigurationManager.java:157)
>>>>> at
>>>>>
>>>>
>>>
>>
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
>>>>
>>>>> figuration(SimpleConfigurationManager.java:668)
>>>>> at
>>>>>
>>>>
>>>
>>
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
>>>>
>>>>> nfiguration(DeploymentConfigurationManager.java:153)
>>>>> at org.apache.geronimo.deployment.DeploymentContext.close
>>>>> (DeploymentContext.java:364)
>>>>> at org.openejb.deployment.DeploymentTestSuite.setUp
>>>>> (DeploymentTestSuite.java:201)
>>>>> at org.openejb.deployment.DeploymentTestSuite.access$000
>>>>> (DeploymentTestSuite.java:90)
>>>>> at org.openejb.deployment.DeploymentTestSuite$1.protect
>>>>> (DeploymentTestSuite.java:119)
>>>>> at
>> junit.framework.TestResult.runProtected(TestResult.java:
>>>>
>>>>> 124)
>>>>> at org.openejb.deployment.DeploymentTestSuite.run
>>>>> (DeploymentTestSuite.java:126)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>>>> (NativeMethodAccessorImpl.java:39)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>>>> (DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>>>> at org.apache.maven.surefire.junit.JUnitTestSet.execute
>>>>> (JUnitTestSet.java:210)
>>>>> at
>>>>>
>>>>
>>>
>>
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
>>>>
>>>>> Set(AbstractDirectoryTestSuite.java:135)
>>>>> at
>>>>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
>>>>> (AbstractDirectoryTestSuite.java:122)
>>>>> at
>>>> org.apache.maven.surefire.Surefire.run(Surefire.java:129)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>> Method)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>>>> (NativeMethodAccessorImpl.java:39)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>>>> (DelegatingMethodAccessorImpl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>>>> at
>>>>>
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>>>>> (SurefireBooter.java:225)
>>>>> at org.apache.maven.surefire.booter.SurefireBooter.main
>>>>> (SurefireBooter.java:747)
>>>>> </error>
>>>>> </testcase>
>>>>>
>>>>> I can't quite imagine how this can occur. Can anyone else?
>>>>>
>>>>> Anyway putting a try/catch block around the code to ignore the
>>>>> error at least lets the test pass. Should I commit this or can
>>>>> anyone think of a possible cause so we can actually fix it?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>
>>>>
>>>
>>>
>>> __________________________________________________
>>
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Another really strange mysterious build error
Posted by anita kulshreshtha <a_...@yahoo.com>.
The problem did go away after excluding commons-logging from axion.
However there are 2 issues:
1. The path to dependency in '[INFO] Failed to resolve artifact'
message is wrong. I have seen wrong path before also.
2. Maven is supposed to pull in all the transitive dependencies unless
explicitly excluded. Maven2 seems to be treating commons-logging
differently than the other jars. In an earlier encounter I had faced a
similar problem:
http://www.nabble.com/Re%3A-Questions-about-the-packaging-plugin-p3936387.html
Here is an excerpt from today's debug output:
[DEBUG] axion:axion:jar:1.0-M3-dev:test (selected for test)
[DEBUG] commons-logging:commons-logging:jar:1.0:test (setting scope
to: compile)
[DEBUG] commons-collections:commons-collections:jar:3.0:test
(selected for test)
[DEBUG] commons-primitives:commons-primitives:jar:1.0:test
(selected for test)
[DEBUG] commons-codec:commons-codec:jar:1.2:test (selected for
test)
[DEBUG] While downloading javacc:javacc:3.2
This artifact has been relocated to net.java.dev.javacc:javacc:3.2.
[DEBUG] net.java.dev.javacc:javacc:jar:3.2:test (selected for test)
Axion is a dependency in openejb-builder with 'test' scope. Maven
sets all its dependencies as test scope. But commons-logging is set to
compile! Does any one know why it should be like this.
Thanks
Anita
--- Kevan Miller <ke...@gmail.com> wrote:
> I believe this problem was fixed last night by jason and david j with
>
> an OpenEJB change to trunk/openejb2/pom.xml. The change excludes a
> transitive dependency for commons-logging being pulled in for axion.
>
> IIUC, maven/surefire was actively pulling in transitive dependencies
>
> (unless excluded). In this case, when the itest was being run the
> axion dependency on the old version of commons-logging was taking
> precedence.
>
> This seems like a pretty fragile environment -- this class loading
> behavior could mask problems that might exist in a true server
> environment, or (as we saw here) generate unique itest problems.
> Jason/David, do I have this right? How do we resolve these issues in
>
> the future?
>
> --kevan
>
> On Sep 13, 2006, at 12:43 AM, anita kulshreshtha wrote:
>
> > As Jacek pointed out it is because of commons-logging jar with a
> > version prior to 1.0.3. It appears that one of the source of this
> jar
> > is geronimo-kernel! how is that possible?
> >
> > thanks
> > Anita
> >
> > [INFO]
> >
>
----------------------------------------------------------------------
>
> > --
> > [ERROR] BUILD ERROR
> > [INFO]
> >
>
----------------------------------------------------------------------
>
> > --
> > [INFO] Failed to resolve artifact.
> >
> > Missing:
> > ----------
> > 1) commons-logging:commons-logging:jar:1.0
> >
> > Try downloading the file manually from the project website.
> >
> > Then, install it using the command:
> > mvn install:install-file -DgroupId=commons-logging
> > -DartifactId=commons-lo
> > gging \
> > -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> >
> > Path to dependency:
> > 1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT
> > 2)
> > org.apache.geronimo.modules:geronimo-axis-builder:jar:1.2-SNAPSHOT
> > 3) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-
> > SNAPSHOT
> > 4) commons-logging:commons-logging:jar:1.0
> >
> >
> > --- Jason Dillon <ja...@planet57.com> wrote:
> >
> >> I see this too... have not looked into it, but we need to fix
> this,
> >> its causing bootstrap builds of G to fail.
> >>
> >> --jason
> >>
> >>
> >> On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
> >>
> >>> I sometimes get this error building openejb-core:
> >>>
> >>> <testcase time="1.273"
> >>> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
> >>> <error type="java.lang.NoSuchMethodError"
> >>>
> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
> >>> ClassLoader;)V">java.lang.NoSuchMethodError:
> >>> org.apache.commons.logging.LogFactory.release(Ljava/lang/
> >>> ClassLoader;)V
> >>> at
> >>> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
> >>> (MultiParentClassLoader.java:386)
> >>> at
> >>> org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
> >>> (JarFileClassLoader.java:147)
> >>> at
> org.apache.geronimo.kernel.config.Configuration.shutdown
> >>
> >>> (Configuration.java:762)
> >>> at org.apache.geronimo.kernel.config.Configuration.doStop
> >>> (Configuration.java:742)
> >>> at
> >>>
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
> >>
> >>> (SimpleConfigurationManager.java:718)
> >>> at
> >>>
> >>
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
> >>> (DeploymentConfigurationManager.java:161)
> >>> at
> >>>
> >>
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
> >>
> >>> figuration(SimpleConfigurationManager.java:698)
> >>> at
> >>>
> >>
> >
>
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
> >>
> >>> nfiguration(DeploymentConfigurationManager.java:157)
> >>> at
> >>>
> >>
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
> >>
> >>> figuration(SimpleConfigurationManager.java:668)
> >>> at
> >>>
> >>
> >
>
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
> >>
> >>> nfiguration(DeploymentConfigurationManager.java:153)
> >>> at org.apache.geronimo.deployment.DeploymentContext.close
> >>> (DeploymentContext.java:364)
> >>> at org.openejb.deployment.DeploymentTestSuite.setUp
> >>> (DeploymentTestSuite.java:201)
> >>> at org.openejb.deployment.DeploymentTestSuite.access$000
> >>> (DeploymentTestSuite.java:90)
> >>> at org.openejb.deployment.DeploymentTestSuite$1.protect
> >>> (DeploymentTestSuite.java:119)
> >>> at
> junit.framework.TestResult.runProtected(TestResult.java:
> >>
> >>> 124)
> >>> at org.openejb.deployment.DeploymentTestSuite.run
> >>> (DeploymentTestSuite.java:126)
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> >> Method)
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke
> >>> (NativeMethodAccessorImpl.java:39)
> >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> >>> (DelegatingMethodAccessorImpl.java:25)
> >>> at java.lang.reflect.Method.invoke(Method.java:324)
> >>> at org.apache.maven.surefire.junit.JUnitTestSet.execute
> >>> (JUnitTestSet.java:210)
> >>> at
> >>>
> >>
> >
>
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
> >>
> >>> Set(AbstractDirectoryTestSuite.java:135)
> >>> at
> >>>
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
> >>> (AbstractDirectoryTestSuite.java:122)
> >>> at
> >> org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> >> Method)
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke
> >>> (NativeMethodAccessorImpl.java:39)
> >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> >>> (DelegatingMethodAccessorImpl.java:25)
> >>> at java.lang.reflect.Method.invoke(Method.java:324)
> >>> at
> >>>
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
> >>> (SurefireBooter.java:225)
> >>> at org.apache.maven.surefire.booter.SurefireBooter.main
> >>> (SurefireBooter.java:747)
> >>> </error>
> >>> </testcase>
> >>>
> >>> I can't quite imagine how this can occur. Can anyone else?
> >>>
> >>> Anyway putting a try/catch block around the code to ignore the
> >>> error at least lets the test pass. Should I commit this or can
> >>> anyone think of a possible cause so we can actually fix it?
> >>>
> >>> thanks
> >>> david jencks
> >>>
> >>
> >>
> >
> >
> > __________________________________________________
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Another really strange mysterious build error
Posted by Kevan Miller <ke...@gmail.com>.
I believe this problem was fixed last night by jason and david j with
an OpenEJB change to trunk/openejb2/pom.xml. The change excludes a
transitive dependency for commons-logging being pulled in for axion.
IIUC, maven/surefire was actively pulling in transitive dependencies
(unless excluded). In this case, when the itest was being run the
axion dependency on the old version of commons-logging was taking
precedence.
This seems like a pretty fragile environment -- this class loading
behavior could mask problems that might exist in a true server
environment, or (as we saw here) generate unique itest problems.
Jason/David, do I have this right? How do we resolve these issues in
the future?
--kevan
On Sep 13, 2006, at 12:43 AM, anita kulshreshtha wrote:
> As Jacek pointed out it is because of commons-logging jar with a
> version prior to 1.0.3. It appears that one of the source of this jar
> is geronimo-kernel! how is that possible?
>
> thanks
> Anita
>
> [INFO]
> ----------------------------------------------------------------------
> --
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------
> --
> [INFO] Failed to resolve artifact.
>
> Missing:
> ----------
> 1) commons-logging:commons-logging:jar:1.0
>
> Try downloading the file manually from the project website.
>
> Then, install it using the command:
> mvn install:install-file -DgroupId=commons-logging
> -DartifactId=commons-lo
> gging \
> -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
>
> Path to dependency:
> 1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT
> 2)
> org.apache.geronimo.modules:geronimo-axis-builder:jar:1.2-SNAPSHOT
> 3) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-
> SNAPSHOT
> 4) commons-logging:commons-logging:jar:1.0
>
>
> --- Jason Dillon <ja...@planet57.com> wrote:
>
>> I see this too... have not looked into it, but we need to fix this,
>> its causing bootstrap builds of G to fail.
>>
>> --jason
>>
>>
>> On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
>>
>>> I sometimes get this error building openejb-core:
>>>
>>> <testcase time="1.273"
>>> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
>>> <error type="java.lang.NoSuchMethodError"
>>> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
>>> ClassLoader;)V">java.lang.NoSuchMethodError:
>>> org.apache.commons.logging.LogFactory.release(Ljava/lang/
>>> ClassLoader;)V
>>> at
>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
>>> (MultiParentClassLoader.java:386)
>>> at
>>> org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
>>> (JarFileClassLoader.java:147)
>>> at org.apache.geronimo.kernel.config.Configuration.shutdown
>>
>>> (Configuration.java:762)
>>> at org.apache.geronimo.kernel.config.Configuration.doStop
>>> (Configuration.java:742)
>>> at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
>>
>>> (SimpleConfigurationManager.java:718)
>>> at
>>>
>> org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
>>> (DeploymentConfigurationManager.java:161)
>>> at
>>>
>>
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
>>
>>> figuration(SimpleConfigurationManager.java:698)
>>> at
>>>
>>
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
>>
>>> nfiguration(DeploymentConfigurationManager.java:157)
>>> at
>>>
>>
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
>>
>>> figuration(SimpleConfigurationManager.java:668)
>>> at
>>>
>>
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
>>
>>> nfiguration(DeploymentConfigurationManager.java:153)
>>> at org.apache.geronimo.deployment.DeploymentContext.close
>>> (DeploymentContext.java:364)
>>> at org.openejb.deployment.DeploymentTestSuite.setUp
>>> (DeploymentTestSuite.java:201)
>>> at org.openejb.deployment.DeploymentTestSuite.access$000
>>> (DeploymentTestSuite.java:90)
>>> at org.openejb.deployment.DeploymentTestSuite$1.protect
>>> (DeploymentTestSuite.java:119)
>>> at junit.framework.TestResult.runProtected(TestResult.java:
>>
>>> 124)
>>> at org.openejb.deployment.DeploymentTestSuite.run
>>> (DeploymentTestSuite.java:126)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:39)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>> at org.apache.maven.surefire.junit.JUnitTestSet.execute
>>> (JUnitTestSet.java:210)
>>> at
>>>
>>
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
>>
>>> Set(AbstractDirectoryTestSuite.java:135)
>>> at
>>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
>>> (AbstractDirectoryTestSuite.java:122)
>>> at
>> org.apache.maven.surefire.Surefire.run(Surefire.java:129)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:39)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:324)
>>> at
>>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
>>> (SurefireBooter.java:225)
>>> at org.apache.maven.surefire.booter.SurefireBooter.main
>>> (SurefireBooter.java:747)
>>> </error>
>>> </testcase>
>>>
>>> I can't quite imagine how this can occur. Can anyone else?
>>>
>>> Anyway putting a try/catch block around the code to ignore the
>>> error at least lets the test pass. Should I commit this or can
>>> anyone think of a possible cause so we can actually fix it?
>>>
>>> thanks
>>> david jencks
>>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Another really strange mysterious build error
Posted by anita kulshreshtha <a_...@yahoo.com>.
As Jacek pointed out it is because of commons-logging jar with a
version prior to 1.0.3. It appears that one of the source of this jar
is geronimo-kernel! how is that possible?
thanks
Anita
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) commons-logging:commons-logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=commons-logging
-DartifactId=commons-lo
gging \
-Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Path to dependency:
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT
2)
org.apache.geronimo.modules:geronimo-axis-builder:jar:1.2-SNAPSHOT
3) org.apache.geronimo.modules:geronimo-kernel:jar:1.2-SNAPSHOT
4) commons-logging:commons-logging:jar:1.0
--- Jason Dillon <ja...@planet57.com> wrote:
> I see this too... have not looked into it, but we need to fix this,
> its causing bootstrap builds of G to fail.
>
> --jason
>
>
> On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
>
> > I sometimes get this error building openejb-core:
> >
> > <testcase time="1.273"
> > name="org.openejb.deployment.UnpackedModuleDeploymentTest">
> > <error type="java.lang.NoSuchMethodError"
> > message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
> > ClassLoader;)V">java.lang.NoSuchMethodError:
> > org.apache.commons.logging.LogFactory.release(Ljava/lang/
> > ClassLoader;)V
> > at
> > org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
> > (MultiParentClassLoader.java:386)
> > at
> > org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
> > (JarFileClassLoader.java:147)
> > at org.apache.geronimo.kernel.config.Configuration.shutdown
>
> > (Configuration.java:762)
> > at org.apache.geronimo.kernel.config.Configuration.doStop
> > (Configuration.java:742)
> > at
> > org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
>
> > (SimpleConfigurationManager.java:718)
> > at
> >
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
> > (DeploymentConfigurationManager.java:161)
> > at
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
>
> > figuration(SimpleConfigurationManager.java:698)
> > at
> >
>
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
>
> > nfiguration(DeploymentConfigurationManager.java:157)
> > at
> >
>
org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
>
> > figuration(SimpleConfigurationManager.java:668)
> > at
> >
>
org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
>
> > nfiguration(DeploymentConfigurationManager.java:153)
> > at org.apache.geronimo.deployment.DeploymentContext.close
> > (DeploymentContext.java:364)
> > at org.openejb.deployment.DeploymentTestSuite.setUp
> > (DeploymentTestSuite.java:201)
> > at org.openejb.deployment.DeploymentTestSuite.access$000
> > (DeploymentTestSuite.java:90)
> > at org.openejb.deployment.DeploymentTestSuite$1.protect
> > (DeploymentTestSuite.java:119)
> > at junit.framework.TestResult.runProtected(TestResult.java:
>
> > 124)
> > at org.openejb.deployment.DeploymentTestSuite.run
> > (DeploymentTestSuite.java:126)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java:39)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:324)
> > at org.apache.maven.surefire.junit.JUnitTestSet.execute
> > (JUnitTestSet.java:210)
> > at
> >
>
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
>
> > Set(AbstractDirectoryTestSuite.java:135)
> > at
> > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
> > (AbstractDirectoryTestSuite.java:122)
> > at
> org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke
> > (NativeMethodAccessorImpl.java:39)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > (DelegatingMethodAccessorImpl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:324)
> > at
> > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
> > (SurefireBooter.java:225)
> > at org.apache.maven.surefire.booter.SurefireBooter.main
> > (SurefireBooter.java:747)
> > </error>
> > </testcase>
> >
> > I can't quite imagine how this can occur. Can anyone else?
> >
> > Anyway putting a try/catch block around the code to ignore the
> > error at least lets the test pass. Should I commit this or can
> > anyone think of a possible cause so we can actually fix it?
> >
> > thanks
> > david jencks
> >
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Another really strange mysterious build error
Posted by Jason Dillon <ja...@planet57.com>.
I see this too... have not looked into it, but we need to fix this,
its causing bootstrap builds of G to fail.
--jason
On Sep 11, 2006, at 3:22 PM, David Jencks wrote:
> I sometimes get this error building openejb-core:
>
> <testcase time="1.273"
> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
> <error type="java.lang.NoSuchMethodError"
> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
> ClassLoader;)V">java.lang.NoSuchMethodError:
> org.apache.commons.logging.LogFactory.release(Ljava/lang/
> ClassLoader;)V
> at
> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
> (MultiParentClassLoader.java:386)
> at
> org.apache.geronimo.kernel.classloader.JarFileClassLoader.destroy
> (JarFileClassLoader.java:147)
> at org.apache.geronimo.kernel.config.Configuration.shutdown
> (Configuration.java:762)
> at org.apache.geronimo.kernel.config.Configuration.doStop
> (Configuration.java:742)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unload
> (SimpleConfigurationManager.java:718)
> at
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unload
> (DeploymentConfigurationManager.java:161)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
> figuration(SimpleConfigurationManager.java:698)
> at
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
> nfiguration(DeploymentConfigurationManager.java:157)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.unloadCon
> figuration(SimpleConfigurationManager.java:668)
> at
> org.apache.geronimo.deployment.DeploymentConfigurationManager.unloadCo
> nfiguration(DeploymentConfigurationManager.java:153)
> at org.apache.geronimo.deployment.DeploymentContext.close
> (DeploymentContext.java:364)
> at org.openejb.deployment.DeploymentTestSuite.setUp
> (DeploymentTestSuite.java:201)
> at org.openejb.deployment.DeploymentTestSuite.access$000
> (DeploymentTestSuite.java:90)
> at org.openejb.deployment.DeploymentTestSuite$1.protect
> (DeploymentTestSuite.java:119)
> at junit.framework.TestResult.runProtected(TestResult.java:
> 124)
> at org.openejb.deployment.DeploymentTestSuite.run
> (DeploymentTestSuite.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.apache.maven.surefire.junit.JUnitTestSet.execute
> (JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTest
> Set(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute
> (AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess
> (SurefireBooter.java:225)
> at org.apache.maven.surefire.booter.SurefireBooter.main
> (SurefireBooter.java:747)
> </error>
> </testcase>
>
> I can't quite imagine how this can occur. Can anyone else?
>
> Anyway putting a try/catch block around the code to ignore the
> error at least lets the test pass. Should I commit this or can
> anyone think of a possible cause so we can actually fix it?
>
> thanks
> david jencks
>
Re: Another really strange mysterious build error
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/12/06, Jason Dillon <ja...@planet57.com> wrote:
> FYI, I have seen some strange JCL related problems with GShell... and
> I ended up excluding any JCL dependencies that were picked up
> transitively and upgrading to JCL 1.1 to get logging happy again.
Ah, you're right - the transitive dependencies feature of Maven 2
could be the origin of the issue. Completely forgot about it.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: Another really strange mysterious build error
Posted by Jason Dillon <ja...@planet57.com>.
FYI, I have seen some strange JCL related problems with GShell... and
I ended up excluding any JCL dependencies that were picked up
transitively and upgrading to JCL 1.1 to get logging happy again.
--jason
On Sep 11, 2006, at 3:39 PM, Jacek Laskowski wrote:
> On 9/12/06, David Jencks <da...@yahoo.com> wrote:
>> I sometimes get this error building openejb-core:
>>
>> <testcase time="1.273"
>> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
>> <error type="java.lang.NoSuchMethodError"
>> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
>> ClassLoader;)V">java.lang.NoSuchMethodError:
>> org.apache.commons.logging.LogFactory.release(Ljava/lang/
>> ClassLoader;)V
>> at
>> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
>> (MultiParentClassLoader.java:386)
>
> Let's take a look at the history of the class -
> o.a.c.logging.LogFactory, esp. with regards to the release method.
>
> I couldn't find a FishEye instance or such, but
> http://jakarta.apache.org/commons/logging/ lists the javadoc for some
> releases. So, I took a look at
> http://jakarta.apache.org/commons/logging/commons-logging-1.0.2/
> docs/api/
> and noticed that there was no release(ClassLoader) method. Then
> http://jakarta.apache.org/commons/logging/commons-logging-1.0.3/
> docs/api/
> has both - release() and release(ClassLoader). As does the next
> release - 1.0.4 -
> http://jakarta.apache.org/commons/logging/commons-logging-1.0.4/
> docs/apidocs/.
> And does the the last release - 1.1 -
> http://jakarta.apache.org/commons/logging/commons-logging-1.1/
> apidocs/index.html.
>
> So the only version the classloader could pick up was 1.0.2 that
> doesn't contain the method in question.
>
> jlaskowski@dev /cygdrive/c/oss/openejb2
> $ find . -name "pom.xml" -exec grep -q commons-logging {} \; -print
> ./modules/openejb-core/pom.xml
> ./pom.xml
>
> Only does the second pom.xml list commons-logging version.
>
> And that's where my investigation ends. Nothing comes to my mind, but
> may have given you some additional info you might've missed (which I
> believe was unlikely ;-))
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
Re: Another really strange mysterious build error
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/12/06, David Jencks <da...@yahoo.com> wrote:
> I sometimes get this error building openejb-core:
>
> <testcase time="1.273"
> name="org.openejb.deployment.UnpackedModuleDeploymentTest">
> <error type="java.lang.NoSuchMethodError"
> message="org.apache.commons.logging.LogFactory.release(Ljava/lang/
> ClassLoader;)V">java.lang.NoSuchMethodError:
> org.apache.commons.logging.LogFactory.release(Ljava/lang/ClassLoader;)V
> at
> org.apache.geronimo.kernel.config.MultiParentClassLoader.destroy
> (MultiParentClassLoader.java:386)
Let's take a look at the history of the class -
o.a.c.logging.LogFactory, esp. with regards to the release method.
I couldn't find a FishEye instance or such, but
http://jakarta.apache.org/commons/logging/ lists the javadoc for some
releases. So, I took a look at
http://jakarta.apache.org/commons/logging/commons-logging-1.0.2/docs/api/
and noticed that there was no release(ClassLoader) method. Then
http://jakarta.apache.org/commons/logging/commons-logging-1.0.3/docs/api/
has both - release() and release(ClassLoader). As does the next
release - 1.0.4 -
http://jakarta.apache.org/commons/logging/commons-logging-1.0.4/docs/apidocs/.
And does the the last release - 1.1 -
http://jakarta.apache.org/commons/logging/commons-logging-1.1/apidocs/index.html.
So the only version the classloader could pick up was 1.0.2 that
doesn't contain the method in question.
jlaskowski@dev /cygdrive/c/oss/openejb2
$ find . -name "pom.xml" -exec grep -q commons-logging {} \; -print
./modules/openejb-core/pom.xml
./pom.xml
Only does the second pom.xml list commons-logging version.
And that's where my investigation ends. Nothing comes to my mind, but
may have given you some additional info you might've missed (which I
believe was unlikely ;-))
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl