Re: Problem in BundleClassLoader with javassist?
On Oct 15, 2010, at 2:25 AM, Rick McGuire wrote: > On 10/14/2010 7:29 PM, David Jencks wrote: >> I'm seeing a problem I can't figure out with javassist's attempt to create a >> proxy using our BundleClassloader. Sometimes it works (with classes from >> OpenWebBeans) but sometimes it doesn't (with classes from the bundle the >> BundleClassLoader is wrapping). >> >> Basically, javassist gets a class in the bundle, constructs bytecode for a >> subclass, and calls defineClass on the BundleClassloader: it gets an >> exception back that the superclass (that we started with) can't be loaded. > The problem is not that the superclass can't be "loaded". This is an > IllegalAccessError, which is generally a permission problem between the class > and its superclass. One cause of this is attempting to define a class using > the same package name as the superclass and the two classes are defined using > different classloaders (which would be the case here). This would occur if > the jar containing the superclass is sealed. Another cause might be the > access permissions on the superclass. Any fields or methods of the > superclass defined with default scope cannot be accessed by a superclass > defined using a different classloader than the superclass. Since this error > appears to be occurring on a field access, this is what I suspect is causing > the error. That makes sense to me. I found that if we eliminated the original error that prompted OWB to change the classloader provider by fixing the imports for an OWB bundle, we can avoid the problem entirely. cf OWB-473. I'm still curious when changing the javassist cl. provider would be appropriate many thanks! david jencks > > Rick > >> I mucked around in OWB so that the classloader hidden inside the bundle is >> used, and this problem goes away. If anyone has some classloader expertise >> to figure out what is going on or make plausible suggestions that would be >> great. >> >> To see this for yourself, relatively quickly, set the tests to >> >> >>> name="org.jboss.jsr299.tck.tests.lookup.injectionpoint.*"/> >> >> >> in jcdi-tck-runner/src/test/resources/tck-tests.xml >> and run >> >> mvn clean test -Dgeronimo-assembly -Dincontainer -DassemblyId=tomcat7-javaee6 >> >> in jcdi-test-runner >> >> >> >> I get something like this in the report at >> geronimo/tck/branches/3.0/jcdi-tck-runner/target/surefire-reports/JSR-299 >> TCK/JSR-299 TCK.html >> >> java.lang.RuntimeException: by java.lang.IllegalAccessError: class >> org.jboss.jsr299.tck.tests.lookup.injectionpoint.FieldInjectionPointBean_$$_javassist_14 >> cannot access its superclass >> org.jboss.jsr299.tck.tests.lookup.injectionpoint.FieldInjectionPointBean >> at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509) >> at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486) >> at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422) >> at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394) >> at >> org.apache.webbeans.util.SecurityUtil$PrivilegedActionForProxyFactory.run(SecurityUtil.java:301) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(SecurityUtil.java:184) >> at >> org.apache.webbeans.proxy.JavassistProxyFactory.getProxyClass(JavassistProxyFactory.java:303) >> at >> org.apache.webbeans.proxy.JavassistProxyFactory.createNormalScopedBeanProxy(JavassistProxyFactory.java:170) >> at >> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:817) >> at >> org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:137) >> at >> org.jboss.jsr299.tck.impl.OldSPIBridge.getInstanceByType(OldSPIBridge.java:42) >> at >> org.jboss.jsr299.tck.AbstractJSR299Test.getInstanceByType(AbstractJSR299Test.java:160) >> at >> org.jboss.jsr299.tck.tests.lookup.injectionpoint.InjectionPointTest.testApiTypeInjectionPoint(InjectionPointTest.java:192) >> at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244) >> at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) >> at >> org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:237) >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201) >> at >> or
Re: Problem in BundleClassLoader with javassist?
On Oct 14, 2010, at 8:19 PM, Jarek Gawor wrote: > David, > > The JavassistProxyFactory.getProxyClass() first tries to create a > proxy using SecurityUtil.doPrivilegedCreateClass(factory); and then > falls back to using the context classloader - the bundle classloader. > What's the exception generated by > SecurityUtil.doPrivilegedCreateClass(factory)? > > Just from looking at the ProxyFactory code, it should pick up the > right classloader (from superclass or interfaces) by default. The problems start when OWB tries to proxy one of its own classes, in webbeans-jsf, which doesn't import the javassist classes needed for the proxy. This causes OWB to replace the default javassist classloader provider with the one that uses the context classloader. For some reason this one works OK for the OWB class. However, it doesn't work for the tck class, presumably for the field access problem Rick pointed out. Making the OWB bundle import that javassist packages needed for the proxy fixes the first problem, so OWB never messes with the javassist classloader provider and it continues to be installed and work. cf OWB-473 Many thanks for the comments and inspiration! david jencks > > Jarek > > On Thu, Oct 14, 2010 at 7:29 PM, David Jencks wrote: >> I'm seeing a problem I can't figure out with javassist's attempt to create a >> proxy using our BundleClassloader. Sometimes it works (with classes from >> OpenWebBeans) but sometimes it doesn't (with classes from the bundle the >> BundleClassLoader is wrapping). >> >> Basically, javassist gets a class in the bundle, constructs bytecode for a >> subclass, and calls defineClass on the BundleClassloader: it gets an >> exception back that the superclass (that we started with) can't be loaded. >> I mucked around in OWB so that the classloader hidden inside the bundle is >> used, and this problem goes away. If anyone has some classloader expertise >> to figure out what is going on or make plausible suggestions that would be >> great. >> >> To see this for yourself, relatively quickly, set the tests to >> >> >> > name="org.jboss.jsr299.tck.tests.lookup.injectionpoint.*"/> >> >> >> in jcdi-tck-runner/src/test/resources/tck-tests.xml >> and run >> >> mvn clean test -Dgeronimo-assembly -Dincontainer -DassemblyId=tomcat7-javaee6 >> >> in jcdi-test-runner >> >> >> >> I get something like this in the report at >> geronimo/tck/branches/3.0/jcdi-tck-runner/target/surefire-reports/JSR-299 >> TCK/JSR-299 TCK.html >> >> java.lang.RuntimeException: by java.lang.IllegalAccessError: class >> org.jboss.jsr299.tck.tests.lookup.injectionpoint.FieldInjectionPointBean_$$_javassist_14 >> cannot access its superclass >> org.jboss.jsr299.tck.tests.lookup.injectionpoint.FieldInjectionPointBean >>at >> javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509) >>at >> javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486) >>at >> javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422) >>at >> javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394) >>at >> org.apache.webbeans.util.SecurityUtil$PrivilegedActionForProxyFactory.run(SecurityUtil.java:301) >>at java.security.AccessController.doPrivileged(Native Method) >>at >> org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(SecurityUtil.java:184) >>at >> org.apache.webbeans.proxy.JavassistProxyFactory.getProxyClass(JavassistProxyFactory.java:303) >>at >> org.apache.webbeans.proxy.JavassistProxyFactory.createNormalScopedBeanProxy(JavassistProxyFactory.java:170) >>at >> org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:817) >>at >> org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:137) >>at >> org.jboss.jsr299.tck.impl.OldSPIBridge.getInstanceByType(OldSPIBridge.java:42) >>at >> org.jboss.jsr299.tck.AbstractJSR299Test.getInstanceByType(AbstractJSR299Test.java:160) >>at >> org.jboss.jsr299.tck.tests.lookup.injectionpoint.InjectionPointTest.testApiTypeInjectionPoint(InjectionPointTest.java:192) >>at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244) >>at >> org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) >>at >> org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) >>at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) >>at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) >>at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:237) >>at
Re: windows build problem with trunk Plugins, BVal :: Core
On Oct 15, 2010, at 12:48 PM, Ted Kirby wrote:
> Thanks Kevan. I did try the build with JRE 1.6.0 IBM Windows 32 build
> pwi3260sr8fp1-20100624_01 (SR8 FP1), and think I got past this
> problem. I got out of memory:
>
> [INFO]
>
> [INFO] Building Geronimo Plugins, Connector 1.6 :: Builder
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting file set:
> C:\svn\g\trunk\plugins\connector-1_6\geronimo-connector-builder-1_6\target
> (included: [**], excluded: [])
> [INFO] [genesis:validate-configuration {execution: default}]
> [INFO] [geronimo-property:set-property {execution: set-property}]
> [INFO] [xmlbeans:xmlbeans {execution: default}]
> Time to build schema type system: 0.921 seconds
> Time to generate code: 9.844 seconds
> JVMDUMP006I Processing dump event "systhrow", detail
> "java/lang/OutOfMemoryError" - please wait.
> JVMDUMP032I JVM requested Snap dump using
> 'C:\svn\g\trunk\Snap.20101015.111238.8152.0001.trc' in res
> ponse to an event
> JVMDUMP010I Snap dump written to
> C:\svn\g\trunk\Snap.20101015.111238.8152.0001.trc
> JVMDUMP032I JVM requested Heap dump using
> 'C:\svn\g\trunk\heapdump.20101015.111238.8152.0002.phd' in
> response to an event
> JVMDUMP010I Heap dump written to
> C:\svn\g\trunk\heapdump.20101015.111238.8152.0002.phd
> JVMDUMP032I JVM requested Java dump using
> 'C:\svn\g\trunk\javacore.20101015.111238.8152.0003.txt' in
> response to an event
> JVMDUMP010I Java dump written to
> C:\svn\g\trunk\javacore.20101015.111238.8152.0003.txt
> JVMDUMP013I Processed dump event "systhrow", detail
> "java/lang/OutOfMemoryError".
> java.lang.OutOfMemoryError: Failed to create a thread: retVal
> -1073741830, errno 12
> null
> java.lang.OutOfMemoryError: Failed to create a thread: retVal
> -1073741830, errno 12
>
> I was using MAVEN_OPTS=-Xmx1500m -XX:MaxPermSize=512m
-XX:MaxPermSize=512m is not going to have any effect on an IBM runtime.
Search for ("Failed to create a thread" outofmemoryerror ) and you'll find
information like
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.60/diag/problem_determination/win_oom_thread.html
Counter-intuitively, you may find that reducing your -Xmx setting (e.g.
-Xmx1024) may fix this problem. The .txt file may have information on the
number of threads being created. There are also settings to reduce the amount
of real memory that is allocated by default for each thread (IIRC). I can help
look at those files, if you'd like.
I'm pretty confident that if there's sufficient motivation to get your building
running on Windows IBM JDK, we can get it running...
--kevan
>
> I then went back to the Sun JDK and the build ran successfully with
> MAVEN_OPTS=-Xmx1024m -Xms256m -XX:PermSize=64m -XX:MaxPermSize=256m
> -XX:ReservedCodeCacheSize=64m
>
> On Thu, Oct 14, 2010 at 11:14 PM, Kevan Miller wrote:
>>
>> On Oct 14, 2010, at 7:48 PM, Ted Kirby wrote:
>>
>>> Thanks Shawn and Janet. I switched to Sun JDK, and not only got by
>>> this problem, but, after a couple others, I got a successful build!
>>> WooHoo!
>>>
>>> I was getting the error with JRE 1.6.0 IBM Windows 32 build
>>> pwi3260sr7-20091217_01 (SR7). Do we support building only with Sun
>>> JDK?
>>
>> Umm. No. I can't think why we'd say that. Would seem there are two
>> possibilities:
>>
>> 1) IBM JDK has more strict validation and we should fix our source (I'm not
>> sure if Shawn and Janet are using Sun or IBM JDK), or
>> 2) There's a compiler bug
>>
>> Google 'inconvertible types' and you'll get a number of hits for compiler
>> bugs in this area. Your IBM JDK is nearly a year old. I'd guess there's a
>> decent chance that upgrading would fix your problem.
>>
>> --kevan
>>
>>
>>
Re: windows build problem with trunk Plugins, BVal :: Core
Thanks Kevan. I did try the build with JRE 1.6.0 IBM Windows 32 build
pwi3260sr8fp1-20100624_01 (SR8 FP1), and think I got past this
problem. I got out of memory:
[INFO]
[INFO] Building Geronimo Plugins, Connector 1.6 :: Builder
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
C:\svn\g\trunk\plugins\connector-1_6\geronimo-connector-builder-1_6\target
(included: [**], excluded: [])
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [xmlbeans:xmlbeans {execution: default}]
Time to build schema type system: 0.921 seconds
Time to generate code: 9.844 seconds
JVMDUMP006I Processing dump event "systhrow", detail
"java/lang/OutOfMemoryError" - please wait.
JVMDUMP032I JVM requested Snap dump using
'C:\svn\g\trunk\Snap.20101015.111238.8152.0001.trc' in res
ponse to an event
JVMDUMP010I Snap dump written to
C:\svn\g\trunk\Snap.20101015.111238.8152.0001.trc
JVMDUMP032I JVM requested Heap dump using
'C:\svn\g\trunk\heapdump.20101015.111238.8152.0002.phd' in
response to an event
JVMDUMP010I Heap dump written to
C:\svn\g\trunk\heapdump.20101015.111238.8152.0002.phd
JVMDUMP032I JVM requested Java dump using
'C:\svn\g\trunk\javacore.20101015.111238.8152.0003.txt' in
response to an event
JVMDUMP010I Java dump written to
C:\svn\g\trunk\javacore.20101015.111238.8152.0003.txt
JVMDUMP013I Processed dump event "systhrow", detail
"java/lang/OutOfMemoryError".
java.lang.OutOfMemoryError: Failed to create a thread: retVal
-1073741830, errno 12
null
java.lang.OutOfMemoryError: Failed to create a thread: retVal
-1073741830, errno 12
I was using MAVEN_OPTS=-Xmx1500m -XX:MaxPermSize=512m
I then went back to the Sun JDK and the build ran successfully with
MAVEN_OPTS=-Xmx1024m -Xms256m -XX:PermSize=64m -XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=64m
On Thu, Oct 14, 2010 at 11:14 PM, Kevan Miller wrote:
>
> On Oct 14, 2010, at 7:48 PM, Ted Kirby wrote:
>
>> Thanks Shawn and Janet. I switched to Sun JDK, and not only got by
>> this problem, but, after a couple others, I got a successful build!
>> WooHoo!
>>
>> I was getting the error with JRE 1.6.0 IBM Windows 32 build
>> pwi3260sr7-20091217_01 (SR7). Do we support building only with Sun
>> JDK?
>
> Umm. No. I can't think why we'd say that. Would seem there are two
> possibilities:
>
> 1) IBM JDK has more strict validation and we should fix our source (I'm not
> sure if Shawn and Janet are using Sun or IBM JDK), or
> 2) There's a compiler bug
>
> Google 'inconvertible types' and you'll get a number of hits for compiler
> bugs in this area. Your IBM JDK is nearly a year old. I'd guess there's a
> decent chance that upgrading would fix your problem.
>
> --kevan
>
>
>
Re: svn commit: r1022868 - in /geronimo/devtools/eclipse-plugin/branches/2.1.7: eclipse/pom.xml plugins/org.apache.geronimo.runtime.common/pom.xml plugins/org.apache.geronimo.runtime.v21/pom.xml pom.x
On Oct 15, 2010, at 8:19 AM, Ted Kirby wrote: > Delos, > > I know you thanked Hong Fang Han for the patch in the JIRA, but is it > not also the practice to include the thanks in the svn commit log > message? Yes it is. It serves several purposes: 1) We love contributions. The more thanks we give to the contributor, the better. It also helps other community members notice the contribution 2) It explicitly notes that this code is not created by the committer, but the contributor. The svn commit message ties this information into our svn repository. Otherwise, we are dependent upon the information in the Jira... --kevan
Re: JSR 319: Availability Management for Java
On Oct 14, 2010, at 11:14 PM, Alan D. Cabrera wrote: > > On Oct 14, 2010, at 1:08 PM, Kevan Miller wrote: > >> >> On Oct 14, 2010, at 2:07 PM, Alan D. Cabrera wrote: >> >>> The JSR was approved this summer. If no one minds I'm going to put this >>> into specs. >> >> Can't think of any objections. Can't say that I've looked at the spec... >> Something you're going to be working on? > > It's a nice, clean, abstraction between containers and the availability > agents that manage the container's and the container's deployment units > lifecycle. Very nice loose coupling that doesn't try to be a swiss army > knife of management, which is refreshing. > > I think that I can weave it into Geronimo without affecting how Geronimo > works now but thus provide a way for availability agents to cleanly plugin if > needed. I'll do the work in a sandbox to solicit comments before I do any > real damage. :) Heh. Thanks. Sounds interesting. --kevan
Re: svn commit: r1022868 - in /geronimo/devtools/eclipse-plugin/branches/2.1.7: eclipse/pom.xml plugins/org.apache.geronimo.runtime.common/pom.xml plugins/org.apache.geronimo.runtime.v21/pom.xml pom.x
Delos,
I know you thanked Hong Fang Han for the patch in the JIRA, but is it
not also the practice to include the thanks in the svn commit log
message? I have been dormant in the community for a while, and need
to get up to speed with current practice.
Thanks,
Ted
On Fri, Oct 15, 2010 at 5:36 AM, wrote:
> Author: delos
> Date: Fri Oct 15 09:36:28 2010
> New Revision: 1022868
>
> URL: http://svn.apache.org/viewvc?rev=1022868&view=rev
> Log:
> GERONIMODEVTOOLS-676 update version number of dependency and moduels to make
> 2.1 branch build successfully
>
> Modified:
> geronimo/devtools/eclipse-plugin/branches/2.1.7/eclipse/pom.xml
>
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.common/pom.xml
>
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.v21/pom.xml
> geronimo/devtools/eclipse-plugin/branches/2.1.7/pom.xml
>
> Modified: geronimo/devtools/eclipse-plugin/branches/2.1.7/eclipse/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/branches/2.1.7/eclipse/pom.xml?rev=1022868&r1=1022867&r2=1022868&view=diff
> ==
> --- geronimo/devtools/eclipse-plugin/branches/2.1.7/eclipse/pom.xml (original)
> +++ geronimo/devtools/eclipse-plugin/branches/2.1.7/eclipse/pom.xml Fri Oct
> 15 09:36:28 2010
> @@ -21,14 +21,14 @@
>
> org.apache.geronimo.devtools
> eclipse
> - 3.0.0
> + 2.1.7
> pom
> Geronimo Eclipse Plugin :: Eclipse
>
>
> org.apache.geronimo.devtools
> geronimo-eclipse-plugin
> - 3.0.0-SNAPSHOT
> + 2.1.7-SNAPSHOT
> ../pom.xml
>
>
>
> Modified:
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.common/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.common/pom.xml?rev=1022868&r1=1022867&r2=1022868&view=diff
> ==
> ---
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.common/pom.xml
> (original)
> +++
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.common/pom.xml
> Fri Oct 15 09:36:28 2010
> @@ -190,7 +190,7 @@
>
> org.apache.geronimo.devtools
> eclipse
> - ${version}
> + ${pom.version}
> pom
>
>
>
> Modified:
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.v21/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.v21/pom.xml?rev=1022868&r1=1022867&r2=1022868&view=diff
> ==
> ---
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.v21/pom.xml
> (original)
> +++
> geronimo/devtools/eclipse-plugin/branches/2.1.7/plugins/org.apache.geronimo.runtime.v21/pom.xml
> Fri Oct 15 09:36:28 2010
> @@ -27,7 +27,7 @@
> ../pom.xml
>
>
> - 2.1.6
> + 2.1.7-SNAPSHOT
>
>
>
>
> Modified: geronimo/devtools/eclipse-plugin/branches/2.1.7/pom.xml
> URL:
> http://svn.apache.org/viewvc/geronimo/devtools/eclipse-plugin/branches/2.1.7/pom.xml?rev=1022868&r1=1022867&r2=1022868&view=diff
> ==
> --- geronimo/devtools/eclipse-plugin/branches/2.1.7/pom.xml (original)
> +++ geronimo/devtools/eclipse-plugin/branches/2.1.7/pom.xml Fri Oct 15
> 09:36:28 2010
> @@ -263,7 +263,7 @@
>
> org.apache.geronimo.devtools
> maven-eclipsepde-plugin
> - 1.0
> + 1.1
>
>
> ${settings.localRepository}/eclipse/eclipse/
>
>
>
>
[BUILD] trunk: Failed for Revision: 1022839
Geronimo Revision: 1022839 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20101015/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20101015 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 46 minutes 44 seconds [INFO] Finished at: Fri Oct 15 03:52:18 EDT 2010 [INFO] Final Memory: 456M/1005M [INFO] TESTSUITE RESULTS (Failures only) = Assembly: tomcat = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/trunk/20101015/logs-0300-tomcat/ Running TestSuite Tests run: 9, Failures: 7, Errors: 0, Skipped: 0, Time elapsed: 21.77 sec <<< FAILURE! -- Running TestSuite Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.576 sec <<< FAILURE! Assembly: jetty = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/trunk/20101015/logs-0300-jetty/ Running TestSuite Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.3 sec <<< FAILURE! [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connection failure; ignoring: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] [org.apache.geronimo.mavenplugins.geronimo.ServerProxy] : Connecting to: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector [org.apache.geronimo.mavenplugins.geronimo.Server
[jira] Resolved: (GERONIMODEVTOOLS-676) branch 2.1.7 build error
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai resolved GERONIMODEVTOOLS-676. Resolution: Fixed Build successfully with your patch. commit it in revision 1022868. Thanks Hong Fang Han for the patch! > branch 2.1.7 build error > > > Key: GERONIMODEVTOOLS-676 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-676 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.7 >Reporter: Han Hong Fang >Assignee: Han Hong Fang > Attachments: GERONIMODEVTOOLS-676.patch > > > Branch 2.1.7 build error due to incorrect version number etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problem in BundleClassLoader with javassist?
On 10/14/2010 7:29 PM, David Jencks wrote: I'm seeing a problem I can't figure out with javassist's attempt to create a proxy using our BundleClassloader. Sometimes it works (with classes from OpenWebBeans) but sometimes it doesn't (with classes from the bundle the BundleClassLoader is wrapping). Basically, javassist gets a class in the bundle, constructs bytecode for a subclass, and calls defineClass on the BundleClassloader: it gets an exception back that the superclass (that we started with) can't be loaded. The problem is not that the superclass can't be "loaded". This is an IllegalAccessError, which is generally a permission problem between the class and its superclass. One cause of this is attempting to define a class using the same package name as the superclass and the two classes are defined using different classloaders (which would be the case here). This would occur if the jar containing the superclass is sealed. Another cause might be the access permissions on the superclass. Any fields or methods of the superclass defined with default scope cannot be accessed by a superclass defined using a different classloader than the superclass. Since this error appears to be occurring on a field access, this is what I suspect is causing the error. Rick I mucked around in OWB so that the classloader hidden inside the bundle is used, and this problem goes away. If anyone has some classloader expertise to figure out what is going on or make plausible suggestions that would be great. To see this for yourself, relatively quickly, set the tests to in jcdi-tck-runner/src/test/resources/tck-tests.xml and run mvn clean test -Dgeronimo-assembly -Dincontainer -DassemblyId=tomcat7-javaee6 in jcdi-test-runner I get something like this in the report at geronimo/tck/branches/3.0/jcdi-tck-runner/target/surefire-reports/JSR-299 TCK/JSR-299 TCK.html java.lang.RuntimeException: by java.lang.IllegalAccessError: class org.jboss.jsr299.tck.tests.lookup.injectionpoint.FieldInjectionPointBean_$$_javassist_14 cannot access its superclass org.jboss.jsr299.tck.tests.lookup.injectionpoint.FieldInjectionPointBean at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509) at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486) at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422) at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394) at org.apache.webbeans.util.SecurityUtil$PrivilegedActionForProxyFactory.run(SecurityUtil.java:301) at java.security.AccessController.doPrivileged(Native Method) at org.apache.webbeans.util.SecurityUtil.doPrivilegedCreateClass(SecurityUtil.java:184) at org.apache.webbeans.proxy.JavassistProxyFactory.getProxyClass(JavassistProxyFactory.java:303) at org.apache.webbeans.proxy.JavassistProxyFactory.createNormalScopedBeanProxy(JavassistProxyFactory.java:170) at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:817) at org.apache.webbeans.container.InjectableBeanManager.getReference(InjectableBeanManager.java:137) at org.jboss.jsr299.tck.impl.OldSPIBridge.getInstanceByType(OldSPIBridge.java:42) at org.jboss.jsr299.tck.AbstractJSR299Test.getInstanceByType(AbstractJSR299Test.java:160) at org.jboss.jsr299.tck.tests.lookup.injectionpoint.InjectionPointTest.testApiTypeInjectionPoint(InjectionPointTest.java:192) at org.jboss.testharness.AbstractTest.run(AbstractTest.java:244) at org.jboss.testharness.impl.runner.TestRunner.run(TestRunner.java:61) at org.jboss.testharness.impl.runner.servlet.ServletTestRunner.doGet(ServletTestRunner.java:120) at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:237) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:713) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:146) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.c
