Re: windows build problem with trunk Plugins, BVal :: Core
It's SUN JDK version 1.6.0_20 on my windows. -- Best regards, Han Hong Fang
[BUILD] trunk: Failed for Revision: 1022804
Geronimo Revision: 1022804 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014/build-2100.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 40 minutes 35 seconds [INFO] Finished at: Thu Oct 14 21:46:32 EDT 2010 [INFO] Final Memory: 460M/1000M [INFO] TESTSUITE RESULTS (Failures only) = Assembly: tomcat = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014/logs-2100-tomcat/ Running TestSuite Tests run: 9, Failures: 7, Errors: 0, Skipped: 0, Time elapsed: 22.276 sec <<< FAILURE! -- Running TestSuite Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.545 sec <<< FAILURE! -- Running TestSuite Tests run: 14, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 33.575 sec <<< FAILURE! Assembly: jetty = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014/logs-2100-jetty/ Running TestSuite Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.269 sec <<< FAILURE! -- Running TestSuite Tests run: 9, Failures: 7, Errors: 0, Skipped: 0, Time elapsed: 21.88 sec <<< FAILURE! -- Running TestSuite Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.762 sec <<< FAILURE! Samples: trunk = Log: http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014/samples-2100.log Build status: OK
Re: windows build problem with trunk Plugins, BVal :: Core
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. Just tried building trunk with IBM SDK. You'll definitely need SR8. You'll get inconvertible type error with SR7. Jarek
Re: Problem in BundleClassLoader with javassist?
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. 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 > > > > > > 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.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:254) > at > org.apache.coyote.http11.Http11
Re: JSR 319: Availability Management for Java
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. :) Regards, Alan
Re: windows build problem with trunk Plugins, BVal :: Core
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
[jira] Commented: (GERONIMO-5644) Share global annotation finder among different components
[ https://issues.apache.org/jira/browse/GERONIMO-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921192#action_12921192 ] Ivan commented on GERONIMO-5644: I prefer the idea to add some methods in the MBE, and I think some ModuleBuilders are also required. The only problem I saw now is the scope, especially in the WebModule builder, the scanning scopes depend on some other scanning result. My first rough idea is to refractor our BundleAnnotationFinder. or extends it to have a CompoundBundleAnnotationFinder, and we could regiester some callbacks to it, and those callback classes might have ; a. Scope detection, like these existing filter class b. addClass / isAccepted methods thanks. > Share global annotation finder among different components > - > > Key: GERONIMO-5644 > URL: https://issues.apache.org/jira/browse/GERONIMO-5644 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 3.0 >Reporter: Ivan >Assignee: viola.lu > Fix For: 3.0 > > > Remember that I mentioned it in the past, while working at JSF integration, I > found that the global annoation scanning is required, too. > I am thinking that we could create a BundleAnnotationFinder for each > application, for web application, servlet, jsf, jaxws, webbeans and jax-rs > should be able to share the same finder, for ejb application, ejb and > webbeans should be able to share the same finder. But there might be problems > for the scan scope, as different components might require different scanning > scope. > Anothing solution is that we might provide some callback methods for > interesting annotation, like equal scenario ( Most scanning requiremetns are > in this scenrio), and extend scenario ( guess that webbeans ??? ) > Any comment ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo builds not cleaning up temp files?
Those temp folders shoujld be deleted, I remember that most temp folders are marked as deleteOnExit, and Geronimo will try to delete them once they are out of use. We might need to add more clean up codes. 2010/10/14 Rick McGuire > I started getting quota errors while doing builds today and the > information I found by searching on the error message seems to point to a > problem with my temp files directory. Looking at the temp directory, I find > it is full of geronimo-fileutil* and geronimo-deploymentUtil* directories. > Shouldn't these temporary directories be getting deleted once they are no > longer used? > > Rick > -- Ivan
Re: windows build problem with trunk Plugins, BVal :: Core
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? On Thu, Oct 14, 2010 at 2:06 AM, han hongfang wrote: > I successfully built trunk on windows XP SP3 with JDK 1.6.0_20 this Turesday > (on Revision: 1021600). > -- > Best regards, > > Han Hong Fang >
Re: trunk build problem: Failed to resolve artifact. org.apache.geronimo.components:geronimo-connector:jar:3.1-20101008.144555-2
I retried the build about an hour later, and it ran. I am happy to have a succesful g3 build now! On Thu, Oct 14, 2010 at 2:26 PM, Ted Kirby wrote: > from plugins\connector-1_6 > > [INFO] > > [INFO] Building Geronimo Plugins, Connector 1.6 :: Connector wrappers > [INFO] task-segment: [clean, install] > [INFO] > > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > Error transferring file: Server returned HTTP response code: 502 for > URL: http://repository.apache.o > rg/snapshots/org/apache/geronimo/components/geronimo-connector/3.1-SNAPSHOT/geronimo-connector-3.1-2 > 0101008.144555-2.jar > org.apache.geronimo.components:geronimo-connector:jar:3.1-20101008.144555-2 > > from the specified remote repositories: > apache.snapshots (http://repository.apache.org/snapshots), > codehaus.snapshots (http://snapshots.repository.codehaus.org), > central (http://repo1.maven.org/maven2), > openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots), > java.net (http://download.java.net/maven/1/), > jetty.oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty/), > openqa-releases (http://nexus.openqa.org/content/repositories/releases), > smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/) > > Path to dependency: > 1) > org.apache.geronimo.modules:geronimo-connector-1_6:bundle:3.0-SNAPSHOT > 2) org.apache.geronimo.components:geronimo-connector:jar:3.1-SNAPSHOT > > any ideas? > > Thanks, > Ted >
Problem in BundleClassLoader with javassist?
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 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.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:402) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:254) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:267) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:245) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:260) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:243) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:373) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[BUILD] trunk: Failed for Revision: 1022660
Geronimo Revision: 1022660 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 58 minutes 7 seconds
[INFO] Finished at: Thu Oct 14 16:02:21 EDT 2010
[INFO] Final Memory: 583M/1006M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101014/logs-1500-tomcat/
Running TestSuite
Tests run: 9, Failures: 7, Errors: 0, Skipped: 0, Time elapsed: 21.832 sec <<<
FAILURE!
--
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.516 sec <<<
FAILURE!
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 3 source files to
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/target/classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/src/test/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/src/test/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/target/fragment2-3.0-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[WARNING] Skipping verification of legal files in artifacts:
[WARNING] org.apache.geronimo.testsuite:fragment2:jar:3.0-SNAPSHOT
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/target/fragment2-3.0-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/fragment2/3.0-SNAPSHOT/fragment2-3.0-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo TestSuite :: Java EE 6 Testsuite :: fragment3
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 3 source files to
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/target/classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/src/test/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/src/test/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/target/fragment3-3.0-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[WARNING] Skipping verification of legal files in artifacts:
[WARNING] org.apache.geronimo.testsuite:fragment3:jar:3.0-SNAPSHOT
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/target/fragment3-3.0-SNAPSHOT.jar
to
/home/geronimo/.m2/reposi
[jira] Closed: (GERONIMO-5647) Avoid an NPE if no securiy realm is specified anywhere
[ https://issues.apache.org/jira/browse/GERONIMO-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-5647. -- Resolution: Fixed rev 1022726 > Avoid an NPE if no securiy realm is specified anywhere > -- > > Key: GERONIMO-5647 > URL: https://issues.apache.org/jira/browse/GERONIMO-5647 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty >Affects Versions: 3.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 3.0 > > > the jetty deployment is throwing an NPE if you don't specify a realm anywhere > in login config or geronimo plan. I think the result of avoiding the NPE > (not configuring a ConfigurationFactory reference) will be that you can't > login at runtime. The app where this showed up specifies a (incomplete) > login config but doesn't have any constraints. I don't think this will > introduce any security exposures. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5647) Avoid an NPE if no securiy realm is specified anywhere
Avoid an NPE if no securiy realm is specified anywhere -- Key: GERONIMO-5647 URL: https://issues.apache.org/jira/browse/GERONIMO-5647 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 the jetty deployment is throwing an NPE if you don't specify a realm anywhere in login config or geronimo plan. I think the result of avoiding the NPE (not configuring a ConfigurationFactory reference) will be that you can't login at runtime. The app where this showed up specifies a (incomplete) login config but doesn't have any constraints. I don't think this will introduce any security exposures. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5646) jetty web app can fail to start but not fail deployment
[ https://issues.apache.org/jira/browse/GERONIMO-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-5646. -- Resolution: Fixed rev 1022724. Can anyone think of a better exception to throw than "Exception"? > jetty web app can fail to start but not fail deployment > --- > > Key: GERONIMO-5646 > URL: https://issues.apache.org/jira/browse/GERONIMO-5646 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty >Affects Versions: 3.0 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 3.0 > > > Jetty marks failure-to-start e.g. from an exception in a context listener by > setting an unavailable flag and recording the exception. We've been ignoring > this, we need to check the results and fail the gbean startup if appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5646) jetty web app can fail to start but not fail deployment
jetty web app can fail to start but not fail deployment --- Key: GERONIMO-5646 URL: https://issues.apache.org/jira/browse/GERONIMO-5646 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Jetty marks failure-to-start e.g. from an exception in a context listener by setting an unavailable flag and recording the exception. We've been ignoring this, we need to check the results and fail the gbean startup if appropriate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5050) Integrate OpenWebBeans into Geronimo 3.0.
[ https://issues.apache.org/jira/browse/GERONIMO-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921135#action_12921135 ] David Jencks commented on GERONIMO-5050: I committed a slightly modified version of jarek's patch in rev 1022717. It helps get some of the jcdi tck working. > Integrate OpenWebBeans into Geronimo 3.0. > -- > > Key: GERONIMO-5050 > URL: https://issues.apache.org/jira/browse/GERONIMO-5050 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: javaee6, OpenWebBeans >Affects Versions: 3.0 >Reporter: Rick McGuire > Fix For: 3.0 > > Attachments: openwebbeans.patch > > > A JSR 299 and 330 implementation is required for Java EE6 and the Java EE 6 > web profile. OpenWebBeans is the most feasible candidate for providing these > features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5050) Integrate OpenWebBeans into Geronimo 3.0.
[ https://issues.apache.org/jira/browse/GERONIMO-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor updated GERONIMO-5050: -- Attachment: openwebbeans.patch I'm attaching a patch that contains a very rough OpenWebBeans integration with Geronimo. Hopefully, others might find it useful in their integration work. > Integrate OpenWebBeans into Geronimo 3.0. > -- > > Key: GERONIMO-5050 > URL: https://issues.apache.org/jira/browse/GERONIMO-5050 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: javaee6, OpenWebBeans >Affects Versions: 3.0 >Reporter: Rick McGuire > Fix For: 3.0 > > Attachments: openwebbeans.patch > > > A JSR 299 and 330 implementation is required for Java EE6 and the Java EE 6 > web profile. OpenWebBeans is the most feasible candidate for providing these > features. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSR 319: Availability Management for Java
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? --kevan
trunk build problem: Failed to resolve artifact. org.apache.geronimo.components:geronimo-connector:jar:3.1-20101008.144555-2
from plugins\connector-1_6 [INFO] [INFO] Building Geronimo Plugins, Connector 1.6 :: Connector wrappers [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Error transferring file: Server returned HTTP response code: 502 for URL: http://repository.apache.o rg/snapshots/org/apache/geronimo/components/geronimo-connector/3.1-SNAPSHOT/geronimo-connector-3.1-2 0101008.144555-2.jar org.apache.geronimo.components:geronimo-connector:jar:3.1-20101008.144555-2 from the specified remote repositories: apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), central (http://repo1.maven.org/maven2), openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots), java.net (http://download.java.net/maven/1/), jetty.oss.sonatype.org (http://oss.sonatype.org/content/repositories/jetty/), openqa-releases (http://nexus.openqa.org/content/repositories/releases), smx.svn (http://svn.apache.org/repos/asf/servicemix/m2-repo/) Path to dependency: 1) org.apache.geronimo.modules:geronimo-connector-1_6:bundle:3.0-SNAPSHOT 2) org.apache.geronimo.components:geronimo-connector:jar:3.1-SNAPSHOT any ideas? Thanks, Ted
[jira] Created: (GERONIMO-5645) JSR319 - Availability Management for Java
JSR319 - Availability Management for Java - Key: GERONIMO-5645 URL: https://issues.apache.org/jira/browse/GERONIMO-5645 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Reporter: Alan Cabrera Assignee: Alan Cabrera Adding JSR319 - Availability Management for Java v1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JSR 319: Availability Management for Java
The JSR was approved this summer. If no one minds I'm going to put this into specs. Regards, Alan
Re: trunk build problem: out of space in CodeCache for adapters
I've seen this issue myself when building on Windows. I was able to
make it go away by setting MAVEN_OPTS to
-Xmx1024m -Xms256m -XX:PermSize=64m -XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=64m
The error was somewhat intermittent for me and would sometimes go away
with a reboot. I've not seen the problem since I changed my MAVEN_OPTs.
Rick
On 10/14/2010 1:55 PM, Ted Kirby wrote:
Revision: 1022182
Sun JDK
[INFO]
[INFO] Building Geronimo Build Support :: Plugin
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [groovy:compile {execution: default}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] out of space in CodeCache for adapters
[INFO]
trunk build problem: out of space in CodeCache for adapters
Revision: 1022182
Sun JDK
[INFO]
[INFO] Building Geronimo Build Support :: Plugin
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [groovy:compile {execution: default}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] out of space in CodeCache for adapters
[INFO]
Re: Bean Validation problems in trunk.
On Thu, Oct 14, 2010 at 8:03 AM, Vamsavardhana Reddy wrote: > > > On Wed, Oct 13, 2010 at 11:47 PM, Rick McGuire wrote: > >> The recent changes to the bean validation support appear to be causing >> failures in both the TCK and the bean validation testsuite. I've tried to >> do a little problem determination, but I think Vamsi is probably going to >> need to take a look at this. In the testsuite failures, it looks to me that >> the validation factory configuration is not getting set up correctly so that >> not all of the constraints are getting applied in the tests. Many of the >> failures are just using the default constraint classes. >> > I see that only those constraint classes that are within the same test > project are being used in the validation, but the default ones are not. I > will take a look at what is happening. > As of rev 1005583 (by which the earlier test is reorganized and EJB test is added) the tests are passing. Rev 1005852 is the only other rev that touched plugins\bval, but the change in that rev seems to have not affected the test status. I will investigate further. > > >> In the TCK, I'm seeing a lot of the same failures where the test was >> expecting constraint failures and not getting any, so this is probably the >> same thing. >> >> There's at least one other problem with the TCK. A number of tests are >> getting deploy failures because of errors with the validation.xml. Since >> these tests actually ARE tests for the invalid XML. this suggests that any >> parsing errors discovered at deploy time should not be terminal. >> > hmm... I will change the deployment exceptions to log warning messages > instead. > I have changed the code to log debug messages instead of throwing deployment exceptions. Commited in revision 1022595. This should take care of the TCK tests related to invalid XML. > > >> >> Rick >> > > > > -- > Vamsi > -- Vamsi
[BUILD] trunk: Failed for Revision: 1022246
Geronimo Revision: 1022246 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101013/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20101013
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 54 seconds
[INFO] Finished at: Wed Oct 13 15:45:13 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/20101013/logs-1500-tomcat/
Running TestSuite
Tests run: 9, Failures: 7, Errors: 0, Skipped: 0, Time elapsed: 21.74 sec <<<
FAILURE!
--
Running TestSuite
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 19.586 sec <<<
FAILURE!
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 3 source files to
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/target/classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/src/test/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/src/test/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/target/fragment2-3.0-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[WARNING] Skipping verification of legal files in artifacts:
[WARNING] org.apache.geronimo.testsuite:fragment2:jar:3.0-SNAPSHOT
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment2/target/fragment2-3.0-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/fragment2/3.0-SNAPSHOT/fragment2-3.0-SNAPSHOT.jar
[INFO]
[INFO] Building Geronimo TestSuite :: Java EE 6 Testsuite :: fragment3
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
[INFO] [geronimo-property:set-property {execution: set-property}]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 3 source files to
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/target/classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/src/test/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/src/test/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/target/fragment3-3.0-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[WARNING] Skipping verification of legal files in artifacts:
[WARNING] org.apache.geronimo.testsuite:fragment3:jar:3.0-SNAPSHOT
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/home/geronimo/geronimo/trunk/testsuite/javaee6-testsuite/servlet3.0-test/fragment3/target/fragment3-3.0-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/fragment3/3.0-
[jira] Commented: (GERONIMO-5644) Share global annotation finder among different components
[ https://issues.apache.org/jira/browse/GERONIMO-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920995#action_12920995 ] David Jencks commented on GERONIMO-5644: I think this is a good idea. I would look at what openejb does for one possible implementation strategy. I have considered two options when I've thought about this. I don't know which implementation I'd prefer. 1. we know all the specs we are supporting, so we can just create a finder that looks for anything of any possible interest. If the module that provides deploy time or runtime support for a some of the classes we find isn't running, we just ignore those classes we found. 2. we could have each MBE and if necessary naming builder add the annotations it's interested in to a list. I think this would need a new method in the MBE interface. (2) is more like how we've structured other parts of deployment. There might be other better ways than either of these ideas. > Share global annotation finder among different components > - > > Key: GERONIMO-5644 > URL: https://issues.apache.org/jira/browse/GERONIMO-5644 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 3.0 >Reporter: Ivan >Assignee: viola.lu > Fix For: 3.0 > > > Remember that I mentioned it in the past, while working at JSF integration, I > found that the global annoation scanning is required, too. > I am thinking that we could create a BundleAnnotationFinder for each > application, for web application, servlet, jsf, jaxws, webbeans and jax-rs > should be able to share the same finder, for ejb application, ejb and > webbeans should be able to share the same finder. But there might be problems > for the scan scope, as different components might require different scanning > scope. > Anothing solution is that we might provide some callback methods for > interesting annotation, like equal scenario ( Most scanning requiremetns are > in this scenrio), and extend scenario ( guess that webbeans ??? ) > Any comment ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Geronimo builds not cleaning up temp files?
I started getting quota errors while doing builds today and the information I found by searching on the error message seems to point to a problem with my temp files directory. Looking at the temp directory, I find it is full of geronimo-fileutil* and geronimo-deploymentUtil* directories. Shouldn't these temporary directories be getting deleted once they are no longer used? Rick
Re: java.lang.OutOfMemoryError: PermGen space
hi is fine thank you - best reguards -- View this message in context: http://apache-geronimo.328035.n3.nabble.com/java-lang-OutOfMemoryError-PermGen-space-tp1673175p1700818.html Sent from the Development mailing list archive at Nabble.com.
What should be made available via Geronimo dist?
A question came up recently in this Jira https://issues.apache.org/jira/browse/YOKO-430 about what should be available for download from the Geronimo dist site. Currently, only the server releases are available for download. All of the rest of the components released by the project are only available from the maven central repository. The Apache rules seem to suggest that is not correct practice. It is certainly a discussion that needs to take place. There are some fairly obvious questions that would need to be decided to implement putting additional components on dist: 1) What should be included? A good starting list from the svn tree would include subprojects released from bundles components daytrader javamail specs xbean yoko The external subproject might be a candidate too, but these are really only used in Geronimo releases, so I suspect we might not want to put them on dist. genesis, gshell, and samples might also be candidates. 2) How should dist be organized? Currently, the directory has a subdir for each server release and a subdir for eclipse releases. I suspect we might want to create a subdir for server releases to organize things a little better. For the other components, we might want to consider mimicing the maven repository organization, although we could drop the org/apache levels of the tree since those are shared by other subcomponents. 3) Should existing downloads be reorganized into this new structure? It might be difficult to locate all links to these downloads, so we might not want to move any existing components. 4) Should the downloads be seeded with all existing releases or only new releases be added? 5) How should the download pages be organized? 6) Can any of this process be automated? There are a lot of details involved with releasing things. The more we can automate, the better. Rick
Re: Geronimo 3.0-M1 plugins
On 10/13/2010 11:03 AM, Kevan Miller wrote: On Oct 11, 2010, at 11:30 PM, Kevan Miller wrote: On Oct 11, 2010, at 11:15 PM, chi runhua wrote: I can help with the document but don't have the write permission to GMOxSite space. The new features of GEP 3.0 are documented at GMOxDOC30 space for now such as Installing OSGi Application Development tools https://cwiki.apache.org/GMOxDOC30/installing-osgi-application-development-tools.html I wasn't very specific in my original note and looks like I forgot to include a URL. I was referring to the Server plugins -- http://geronimo.apache.org/plugins/ -- not the Eclipse Plugins... Rick, Looks like you were the release manager. Don't suppose you could be convinced to fix? --kevan I've added a plugins file for 3.0-M1. There's one entry in this file I suspect might need updating. In the "Plugin Farm" plugin, there's a config substitution property for DefaultPluginRepository that has the value ~/.m2/repository I suspect this should be something other than the local repository, but I'm not sure what it should be. Rick
[jira] Created: (GERONIMODEVTOOLS-676) branch 2.1.7 build error
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.
[jira] Updated: (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 ] Han Hong Fang updated GERONIMODEVTOOLS-676: --- Attachment: GERONIMODEVTOOLS-676.patch Patch is available. Please help to review. Thanks! > 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.
[BUILD] branches/2.1: Failed for Revision: 1022380
Geronimo Revision: 1022380 built with tests included See the full build-0200.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20101014/build-0200.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.1/20101014 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 32 minutes 6 seconds [INFO] Finished at: Thu Oct 14 02:37:37 EDT 2010 [INFO] Final Memory: 269M/1009M [INFO] TESTSUITE RESULTS (Failures only) = Assembly: tomcat = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/2.1/20101014/logs-0200-tomcat/ [INFO] Running security-testsuite.security [INFO] Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 62.121 sec <<< FAILURE! Assembly: jetty = See full test results and logs at http://people.apache.org/builds/geronimo/server/binaries/2.1/20101014/logs-0200-jetty/ Samples: branches/2.1 = Log: http://people.apache.org/builds/geronimo/server/binaries/2.1/20101014/samples-0200.log Build status: FAILED
[jira] Closed: (GERONIMO-4713) Disable Tomcat JNDI
[ https://issues.apache.org/jira/browse/GERONIMO-4713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu closed GERONIMO-4713. -- > Disable Tomcat JNDI > --- > > Key: GERONIMO-4713 > URL: https://issues.apache.org/jira/browse/GERONIMO-4713 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 2.2 > Environment: os:winxp >Reporter: viola.lu >Assignee: viola.lu >Priority: Minor > Fix For: 2.2 > > Attachments: Geronimo-4713.patch > > > 1.start up server on windows, from server backgroup console, there are two > warnings: > [MemoryUserDatabase] userdatabase is not persistent, no write permission to > direcotry > NamingContextListener failed to register in JMX:javax.naming.exception root > cause is > java.lang.classnotfoundexception:org.apache.tomcat.dhcp.dhcp.basicdatasourcefactory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-5639) org.osgi.service.blueprint.container.ServiceUnavailableException when shutdown the server
[ https://issues.apache.org/jira/browse/GERONIMO-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu reassigned GERONIMO-5639: -- Assignee: viola.lu > org.osgi.service.blueprint.container.ServiceUnavailableException when > shutdown the server > - > > Key: GERONIMO-5639 > URL: https://issues.apache.org/jira/browse/GERONIMO-5639 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: startup/shutdown >Affects Versions: 3.0 > Environment: Windows 7 x86 > sun jdk 1.6.0_20 >Reporter: Forrest Xia >Assignee: viola.lu > Attachments: config.xml, geronimo.log > > > Steps: > 1. Get the latest G build > 2. Unzip and boot the default instance > 3. Shutdown it > Everything seems ok, but in the geronimo.log there is always an exception > like this: > 2010-10-12 16:35:04,985 INFO [BeanRecipe] Error invoking destroy method > org.osgi.service.blueprint.container.ServiceUnavailableException: The > Blueprint container is being or has been destroyed > at > org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:183) > at > org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:52) > at > org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:208) > at > org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$CgLibProxyFactory$1.loadObject(AbstractServiceReferenceRecipe.java:652) > at > org.apache.yoko.osgi.locator.Register$$EnhancerByCGLIB$$2b0d9326.unregisterProvider() > at org.apache.yoko.osgi.locator.ProviderBean.stop(ProviderBean.java:61) > 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:597) > at > org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:221) > at > org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:844) > at > org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:761) > at > org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:295) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:665) > at > org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:819) > at > org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:204) > at > org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:196) > at > org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:385) > at > org.apache.aries.util.tracker.InternalRecursiveBundleTracker.modifiedBundle(InternalRecursiveBundleTracker.java:89) > at > org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453) > at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237) > at > org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:919) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149) > at > org.eclipse.osgi.framework.internal.core.Framework.publishBundleEventPrivileged(Framework.java:1350) > at > org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Framework.java:1301) > at > org.eclipse.osgi.framework.internal.core.BundleHost.stopWorker(BundleHost.java:470) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.suspend(AbstractBundle.java:546) > at > org.eclipse.osgi.framework.internal.core.Framework.suspendBundle(Framework.java:1098) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.decFWSL(StartLevelManager.java:593) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:261) > at > org.eclipse.osgi.framework.internal.core.StartLevelManager.shutdown(StartLevelManager.java:216) > at > org.eclipse.osgi.framework.internal.core.InternalSystemBundle.suspend(InternalSystemBundle.java:266) > at > org.eclipse.osgi.framework.internal.core.F
[jira] Assigned: (GERONIMO-5644) Share global annotation finder among different components
[ https://issues.apache.org/jira/browse/GERONIMO-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu reassigned GERONIMO-5644: -- Assignee: viola.lu > Share global annotation finder among different components > - > > Key: GERONIMO-5644 > URL: https://issues.apache.org/jira/browse/GERONIMO-5644 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 3.0 >Reporter: Ivan >Assignee: viola.lu > Fix For: 3.0 > > > Remember that I mentioned it in the past, while working at JSF integration, I > found that the global annoation scanning is required, too. > I am thinking that we could create a BundleAnnotationFinder for each > application, for web application, servlet, jsf, jaxws, webbeans and jax-rs > should be able to share the same finder, for ejb application, ejb and > webbeans should be able to share the same finder. But there might be problems > for the scan scope, as different components might require different scanning > scope. > Anothing solution is that we might provide some callback methods for > interesting annotation, like equal scenario ( Most scanning requiremetns are > in this scenrio), and extend scenario ( guess that webbeans ??? ) > Any comment ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5603) NPE error after deploy OpenEJB injection-of-env-entry sample
[ https://issues.apache.org/jira/browse/GERONIMO-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu closed GERONIMO-5603. -- Verified on latest build: 2010.10.14-14:31:12.046+0800. Close it. > NPE error after deploy OpenEJB injection-of-env-entry sample > > > Key: GERONIMO-5603 > URL: https://issues.apache.org/jira/browse/GERONIMO-5603 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 3.0 > Environment: windows xp , jdk 1.6.0._20 > build: 2010.09.08-11:46:48.734+0800 >Reporter: viola.lu >Assignee: Ivan > Fix For: 3.0 > > Attachments: injection-of-env-entry-1.1-SNAPSHOT.jar > > > 1.Deploy openejb sample: injection-of-env-entry to server > 2.Got errors below, but successfully on geronimo 2.2 > ava.lang.NullPointerException > org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:284) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:138) > 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:597) > at > org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:872) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.lang.NullPointerException > at > org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:324) > at > org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:231) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1193) > at > org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:69) > at > org.apache.xbean.osgi.bundle.util.BundleClassLoader.loadClass(BundleClassLoader.java:64) > at > org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1055) > at > org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:684) > at > org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:232) > at > org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:259) > at > org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:647) > at > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java:767) > at > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.getEjbInfo(EjbModuleBuilder.java:694) > at > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.doInitContext(EjbModuleBuilder.java:614) > at > org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext(EjbModuleBuilder.java:600) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:639) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:250) > ... 12 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5534) AccessTimeout warning during server startup.
[ https://issues.apache.org/jira/browse/GERONIMO-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu closed GERONIMO-5534. -- > AccessTimeout warning during server startup. > > > Key: GERONIMO-5534 > URL: https://issues.apache.org/jira/browse/GERONIMO-5534 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 2.2, 2.2.1 >Reporter: Kevan Miller >Assignee: viola.lu > Fix For: 2.2, 2.2.1 > > Attachments: G-5534.patch > > > During server startup on current 2.2.2-SNAPSHOT builds, I'm seeing the > following warning: > 2010-08-16 17:02:12,353 WARN [service] Property "AccessTimeout" not > supported by "DefaultStatefulContainer" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5642) Provide a way to dynamically reload JSP files in Geronimo 3.0
[ https://issues.apache.org/jira/browse/GERONIMO-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920874#action_12920874 ] Ivan commented on GERONIMO-5642: Yes, the location should be somewhere which could be edit by IDE. For Tomcat, I can see that we could add a "debug" element in the vendor deployment descriptor, the element might have "reverse" and "location" attributes. While users configured it, the search order should be FileDirContext specified by the location attribute, then the installed BundleDirContext. Think that Jetty should be able to do the similar things. Thoughts ? > Provide a way to dynamically reload JSP files in Geronimo 3.0 > - > > Key: GERONIMO-5642 > URL: https://issues.apache.org/jira/browse/GERONIMO-5642 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Ivan > Fix For: Wish List > > > Currently, the users could not dynamically reload JSP files as the > application is left packaged, one possible solution is that to keep a tag in > the deployment codes, while it is turned on, we might extract those jsp files > in a "temp" folder, and attach that folder as a alt context, but some details > still need to be considered. > Open a JIRA to track this, I think that we do need this function in the > coming Geronimo 3.0 release, hope that we could find a more gentle way to do > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5644) Share global annotation finder among different components
Share global annotation finder among different components - Key: GERONIMO-5644 URL: https://issues.apache.org/jira/browse/GERONIMO-5644 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: deployment Affects Versions: 3.0 Reporter: Ivan Fix For: 3.0 Remember that I mentioned it in the past, while working at JSF integration, I found that the global annoation scanning is required, too. I am thinking that we could create a BundleAnnotationFinder for each application, for web application, servlet, jsf, jaxws, webbeans and jax-rs should be able to share the same finder, for ejb application, ejb and webbeans should be able to share the same finder. But there might be problems for the scan scope, as different components might require different scanning scope. Anothing solution is that we might provide some callback methods for interesting annotation, like equal scenario ( Most scanning requiremetns are in this scenrio), and extend scenario ( guess that webbeans ??? ) Any comment ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai resolved GERONIMODEVTOOLS-608. Resolution: Fixed Fix Version/s: 3.0 2.1.7 2.2.1 commit the patch in revision 1022388 for 2.1.6 branch and 1022395 for 2.2.1 branch > Publish with GEP takes minutes, while deploy takes seconds > -- > > Key: GERONIMODEVTOOLS-608 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.2.0 > Environment: GEP 2.2 installed in Eclipse (galileo-SR1). >Reporter: Boes >Assignee: Delos Dai > Fix For: 2.2.1, 2.1.7, 3.0 > > Attachments: 608_20100909.patch, getEnvironment.txt, HiThere.ear, > HiThereSlow.ear, reorderModules.txt > > > Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much > more time then deploying the same EAR to Geronimo using the console. See > http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html > After doing some research I found that EAR's that have dependencies in > geronimo-application.xml take a lot of time to publish. This is caused by the > very inefficient implementation of the reorderModules method in the > org.apache.geronimo.st.core.internal.DependencyHelper class. > I installed a GEP development environment and put on tracing. It tested an > EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added > dependency tags for 4 libraries. Tracing shows that this results in parsing > the geronimo-application.xml 1092 (!) times. In code this means that a call > to DependencyHelper.getEnvironment is made 1092 times. > Another inefficient part in the reorderModules method is that the call to > DeploymentUtils.isInstalledModule is repeatedly made for the same module. In > the test I found it was called at least 3 times for each dependent library. > These calls result in a request to Geronimo and take almost a second each. > The best way to solve this bug is to redesign the reordering process and make > it work in a way that both DependencyHelper.getEnvironment and > DeploymentUtils.isInstalledModule are not called more often then needed. I > wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies > are defined in the xml. I can't imagine why it would matter if a module is > installed in Geronimo or not. > What I did to fix this problem and make GEP workable again for me is: > - made sure the DeploymentUtils.isInstalledModule is never called twice for > the same module. Once the DeploymentUtils.isInstalledModule is called for a > certain module, I add this module to a list. Before a next call to > DeploymentUtils.isInstalledModule I verify if the call has been made before. > If so, it doesn't need to be called again. > - reduced the number of times the xml is parsed. I put the results of the > DependencyHelper.getEnvironment for a certain module in a hashmap. Next time > the DependencyHelper.getEnvironment is called for the same module, I returns > the result stored in the hashmap. > After these two modifications GEP is up to speed again. > Removal of the call to DeploymentUtils.isInstalledModule makes GEP even > faster. Just as fast as deployment using the Geronimo console. For me this > works, but I don't know what the impact is for other users. In the attached > code I left it the way it was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
