geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Another really strange mysterious build error
Date Wed, 13 Sep 2006 13:53:39 GMT
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 <jason@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


Mime
View raw message