Geronimo VM-appliance?
I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux +openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare- minimum for folks that need a starting point to roll uber-custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating-system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues? Anyways, seems like a good idea, I'd like to see it happen, its not that hard... what do you folks think? --jason
Re: Geronimo VM-appliance?
I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) thanks david jencks On Dec 15, 2008, at 12:01 AM, Jason Dillon wrote: I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux+openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare-minimum for folks that need a starting point to roll uber- custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating-system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues? Anyways, seems like a good idea, I'd like to see it happen, its not that hard... what do you folks think? --jason
Re: [jira] Closed: (XBEAN-118) how remote access datasource by jndi
JIRA j...@apache.org wrote: [ https://issues.apache.org/jira/browse/XBEAN-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed XBEAN-118. -- Resolution: Won't Fix This is out of scope for xbean-jndi. xbean-jndi is designed to be an in-memory naming system. The problem with trying to serialize and deserialize a datasource deployed in a javaee container is... you have 2 choices: 1. set up the connection pool, managed connection factory, and transaction manager in the new vm. This is never going to work. e.g. what is the tm id going to be. 2. proxy the connections back to the javaee server. This also is ridiculous. If you want db connectivity in a particular vm set up a datasource there adapted to the resources available in that vm. how remote access datasource by jndi Key: XBEAN-118 URL: https://issues.apache.org/jira/browse/XBEAN-118 Project: XBean Issue Type: Wish Components: naming Affects Versions: 3.5 Reporter: javahan Priority: Critical I'm trying to remote lookup a datasource object by jndi,but i can get the following exception.How do I do? java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:157) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:972) at com.cvicse.inforsuite.system.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:1188) at com.cvicse.inforsuite.system.jmx.KernelDelegate.invoke(KernelDelegate.java:697) at com.cvicse.inforsuite.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) at com.cvicse.inforsuite.system.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:117) at com.cvicse.inforsuite.gjndi.GlobalContextGBean$$EnhancerByCGLIB$$6d77930b.lookup(generated) at com.jmx.test.JndiServiceTest.testJndiObject(JndiServiceTest.java:55) 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:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1309) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:139) ... 25 more Caused by: java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:258) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:304) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) -- This message is automatically
Re: [jira] Closed: (XBEAN-118) how remote access datasource by jndi
thanks for you answer,but why geronimo hasn't provides a kind of method to get remote datasoruce as weblogic application server? Properties prop = new Properties(); prop.put(Context.INITIAL_CONTEXT_FACTORY, weblogic.jndi.WLInitialContextFactory); prop.put(Context.PROVIDER_URL, t3://192.168.0.1:7001); prop.put(Context.SECURITY_PRINCIPAL,system); prop.put(Context.SECURITY_CREDENTIALS,weblogic); InitialContext ic = new InitialContext(prop); ds = (DataSource) ic.lookup(dbName); JIRA j...@apache.org wrote: [ https://issues.apache.org/jira/browse/XBEAN-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed XBEAN-118. -- Resolution: Won't Fix This is out of scope for xbean-jndi. xbean-jndi is designed to be an in-memory naming system. The problem with trying to serialize and deserialize a datasource deployed in a javaee container is... you have 2 choices: 1. set up the connection pool, managed connection factory, and transaction manager in the new vm. This is never going to work. e.g. what is the tm id going to be. 2. proxy the connections back to the javaee server. This also is ridiculous. If you want db connectivity in a particular vm set up a datasource there adapted to the resources available in that vm. how remote access datasource by jndi Key: XBEAN-118 URL: https://issues.apache.org/jira/browse/XBEAN-118 Project: XBean Issue Type: Wish Components: naming Affects Versions: 3.5 Reporter: javahan Priority: Critical I'm trying to remote lookup a datasource object by jndi,but i can get the following exception.How do I do? java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:157) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:972) at com.cvicse.inforsuite.system.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:1188) at com.cvicse.inforsuite.system.jmx.KernelDelegate.invoke(KernelDelegate.java:697) at com.cvicse.inforsuite.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) at com.cvicse.inforsuite.system.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:117) at com.cvicse.inforsuite.gjndi.GlobalContextGBean$$EnhancerByCGLIB$$6d77930b.lookup(generated) at com.jmx.test.JndiServiceTest.testJndiObject(JndiServiceTest.java:55) 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:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1309) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:139) ... 25 more Caused by: java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:258) at
[BUILD] trunk: Failed for Revision: 726645
Geronimo Revision: 726645 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215/build-0300.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215/unit-test-reports [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.systempropertyprofileactiva...@1f6a1f6a [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@1f6a1f6a [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:compile' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [INFO] [car:package] [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.systempropertyprofileactiva...@1f6a1f6a [WARNING] Component returned which is not the same manager. Ignored. component=org.apache.maven.profiles.activation.alwaysonprofileactiva...@1f6a1f6a [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:provided' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen ...e with exception of classes directly in package org.xmlpull.v1 )/... @15:169) for project xpp3:xpp3_min at /home/geronimo/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom [WARNING] POM for 'xpp3:xpp3_min:pom:1.1.4c:compile' is invalid
Re: Geronimo VM-appliance?
On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) Thats what I've been realizing... But can we link to it/documented it from apache? --jason
[jira] Commented: (XBEAN-118) how remote access datasource by jndi
[ https://issues.apache.org/jira/browse/XBEAN-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656575#action_12656575 ] javahan commented on XBEAN-118: --- thanks for you answer,but why geronimo hasn't provides a kind of method to get remote datasoruce as weblogic application server? Properties prop = new Properties(); prop.put(Context.INITIAL_CONTEXT_FACTORY, weblogic.jndi.WLInitialContextFactory); prop.put(Context.PROVIDER_URL, t3://192.168.0.1:7001); prop.put(Context.SECURITY_PRINCIPAL,system); prop.put(Context.SECURITY_CREDENTIALS,weblogic); InitialContext ic = new InitialContext(prop); ds = (DataSource) ic.lookup(dbName); Quoted from: http://www.nabble.com/-jira--Created%3A-%28XBEAN-118%29-how-remote-access-datasource-by-jndi-tp20949717s134p20951613.html how remote access datasource by jndi Key: XBEAN-118 URL: https://issues.apache.org/jira/browse/XBEAN-118 Project: XBean Issue Type: Wish Components: naming Affects Versions: 3.5 Reporter: javahan Priority: Critical I'm trying to remote lookup a datasource object by jndi,but i can get the following exception.How do I do? java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:157) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:972) at com.cvicse.inforsuite.system.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:1188) at com.cvicse.inforsuite.system.jmx.KernelDelegate.invoke(KernelDelegate.java:697) at com.cvicse.inforsuite.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) at com.cvicse.inforsuite.system.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:117) at com.cvicse.inforsuite.gjndi.GlobalContextGBean$$EnhancerByCGLIB$$6d77930b.lookup(generated) at com.jmx.test.JndiServiceTest.testJndiObject(JndiServiceTest.java:55) 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:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1309) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:139) ... 25 more Caused by: java.io.NotSerializableException: org.tranql.connector.jdbc.DataSource at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:258) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:304) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at
Re: Geronimo VM-appliance?
Any idea why kinda of images you'd like to see? I'm gonna try and craft a simple, base-os+Geronimo image to test out. But I think we might want one which has say roller configured perhaps even another which can demonstrate AMQ's message distribution over a cluster. --jason On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) thanks david jencks On Dec 15, 2008, at 12:01 AM, Jason Dillon wrote: I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux+openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare-minimum for folks that need a starting point to roll uber- custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating- system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues? Anyways, seems like a good idea, I'd like to see it happen, its not that hard... what do you folks think? --jason
[jira] Created: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file or
directory whose META-INF directory contains the persistence.xml file is termed
the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying it
on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment, while on
the console OpenJPA throws exceptions because it tries to resolve the jar-file
paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4467) null pointer acess in code.
[
https://issues.apache.org/jira/browse/GERONIMO-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bohn reassigned GERONIMO-4467:
--
Assignee: Joe Bohn
null pointer acess in code.
---
Key: GERONIMO-4467
URL: https://issues.apache.org/jira/browse/GERONIMO-4467
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Shawn Jiang
Assignee: Joe Bohn
Priority: Minor
Fix For: 2.1.4, 2.2
Attachments: 4467_shawn.patch
null pointer acess in code.
{code}
if (file == null) {
throw new IOException(Entry not found: name= +
file.getAbsolutePath());
} else if (file.isDirectory()) {
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 726697
Geronimo Revision: 726697 built with tests included
See the full build-0900.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215/build-0900.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215/unit-test-reports
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: plugin-farm-datasource-2.2-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm-datasource/target/plugin-farm-datasource-2.2-SNAPSHOT.car
to
/home/geronimo/.m2/repository/org/apache/geronimo/configs/plugin-farm-datasource/2.2-SNAPSHOT/plugin-farm-datasource-2.2-SNAPSHOT.car
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Plugins, Clustering :: Plugin Farm
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm/target/resources/META-INF/plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm/target/resources/META-INF/plan.xml
[INFO] Started deployer:
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car
[INFO] [car:prepare-metadata]
[INFO] [car:archive-car]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm/target/plugin-farm-2.2-SNAPSHOT.car
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: plugin-farm-2.2-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm/target/plugin-farm-2.2-SNAPSHOT.car
to
/home/geronimo/.m2/repository/org/apache/geronimo/configs/plugin-farm/2.2-SNAPSHOT/plugin-farm-2.2-SNAPSHOT.car
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronimo Plugins, Clustering :: Plugin Farm Member
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm-member/target/resources/META-INF/plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm-member/target/resources/META-INF/plan.xml
[INFO] Started deployer:
org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car
[INFO] [car:prepare-metadata]
[INFO] [car:archive-car]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm-member/target/plugin-farm-member-2.2-SNAPSHOT.car
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: plugin-farm-member-2.2-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/clustering/plugin-farm-member/target/plugin-farm-member-2.2-SNAPSHOT.car
to
/home/geronimo/.m2/repository/org/apache/geronimo/configs/plugin-farm-member/2.2-SNAPSHOT/plugin-farm-member-2.2-SNAPSHOT.car
[INFO] [car:update-pluginlist]
[INFO]
[INFO] Building Geronim Plugin Farm Node Server Assembly
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.apache.geronimo.genesis.plugins:tools-maven-plugin:
checking for updates from central
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.geronimo.genesis.plugins:tools-maven-plugin' does
not exist or no valid version could be found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: The plugin
'org.apache.geronimo.genesis.plugins:tools-maven-plugin' does not exist
[jira] Resolved: (GERONIMO-4467) null pointer acess in code.
[
https://issues.apache.org/jira/browse/GERONIMO-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bohn resolved GERONIMO-4467.
Resolution: Fixed
Comitted in trunk rev. 726699 and branches/2.1 rev. 726700 - Thanks for the
patch!
null pointer acess in code.
---
Key: GERONIMO-4467
URL: https://issues.apache.org/jira/browse/GERONIMO-4467
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Shawn Jiang
Assignee: Joe Bohn
Priority: Minor
Fix For: 2.1.4, 2.2
Attachments: 4467_shawn.patch
null pointer acess in code.
{code}
if (file == null) {
throw new IOException(Entry not found: name= +
file.getAbsolutePath());
} else if (file.isDirectory()) {
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4337) Upgrade to activeMQ 5.x
[ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656644#action_12656644 ] Jarek Gawor commented on GERONIMO-4337: --- Btw, I've noticed that with the new activemq plugin a activemq-data directory is created under the current working directory instead somewhere underneath the server instance/var/ directory. Upgrade to activeMQ 5.x --- Key: GERONIMO-4337 URL: https://issues.apache.org/jira/browse/GERONIMO-4337 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 Attachments: geronimo-plugins.xml, plugins.svn.diff.zip, svn.diff Upgrade activemq support to 5.x. A few steps along the way: - create an activemq5 work area under plugins - move the specification of amq version from the root pom dependency management to the activemq and activemq5 plugins. - keep only the broker gbean - use an activemq configuration file in var/activemq, referenced by the broker gbean - update dependencies to latest activemq - figure out how much of the current jms portlet functionality can be reasonably kept. From discussions with Hiram I think that trying to reconfigure the broker while its running is a very bad idea and we should just drop the parts of the console that try to do this. - investigate how to run the amq console in geronimo, preferably as portlets inside the g. admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: (was: geronimo-jarfile.tar.gz)
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: my-ear-1.0-SNAPSHOT.ear
geronimo-jarfile.tar.gz
The EAR contains an empty servlet set to load-on-startup just to make the
error visible on deployment.
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: (was: my-ear-1.0-SNAPSHOT.ear)
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Geronimo v2.2 discussion
Given where we are with 2.2, we did not create the branch last Friday as planned in the 2.2 Status page. I'll work with Joe today/tomorrow to get the status page updated and a new target date set. -Donald Hernan Cunico wrote: Hi All, We kinda started to have some discussion some time ago but couldn't find any hit on nabble so not sure were we left it. I added a Geronimo v2.2 Roadmap ../GMOxDEV/geronimo-v22-roadmap.html page at the top of the Development section in the wiki front page, http://cwiki.apache.org/geronimo/ so we can resume the discussion and collect all our thoughts in one place. (edit access is limited to committers/contributors though) Does anybody already have a list? Cheers! Hernan
[jira] Updated: (GERONIMO-4468) jar-file elements are interpreted relatively to EAR root
[
https://issues.apache.org/jira/browse/GERONIMO-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Janko Heilgeist updated GERONIMO-4468:
--
Attachment: geronimo-jarfile.tar.gz
my-ear-1.0-SNAPSHOT.ear
Simplified sample EAR
jar-file elements are interpreted relatively to EAR root
--
Key: GERONIMO-4468
URL: https://issues.apache.org/jira/browse/GERONIMO-4468
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.3
Reporter: Janko Heilgeist
Attachments: geronimo-jarfile.tar.gz, my-ear-1.0-SNAPSHOT.ear
The jar-file elements in a persistence.xml are wrongly interpreted as
relative to the EAR's root.
EJB 3.0 persistence spec, section 6.2:
{quote}
[...] A persistence unit is defined by a persistence.xml file. The jar file
or directory whose META-INF directory contains the persistence.xml file is
termed the root of the persistence unit. [...]
{quote}
EJB 3.0 persistence spec, section 6.2:
{quote}
One or more JAR files may be specified using the jar-file elements [...] Such
JAR files are specified relative to the root of the persistence unit [...].
{quote}
The attached EAR is correctly verified by the Glassfish verifier. Deploying
it on Geronimo 2.1.3 or 2.2-SNAPSHOT results in a successful deployment,
while on the console OpenJPA throws exceptions because it tries to resolve
the jar-file paths relative to the EAR's root:
{quote}
openjpa-1.0.3-r420667:677674 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.1.3/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-ear-1.0-SNAPSHOT.ear/my-entities1-1.0-SNAPSHOT.jar
(No such file or directory)
openjpa-1.2.0-r422266:683325 nonfatal general error
org.apache.openjpa.persistence.PersistenceException:
$HOME/geronimo-tomcat6-javaee5-2.2-SNAPSHOT/repository/com/heilgeist/testcase/geronimo/jarfile/my-ear/1.0-SNAPSHOT/my-entities2-1.0-SNAPSHOT.jar
(No such file or directory)
{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Geronimo VM-appliance?
OS+Java 6+FF3+Server+Samples+Eclipse+GEP would be ideal for developers -Donald Jason Dillon wrote: Any idea why kinda of images you'd like to see? I'm gonna try and craft a simple, base-os+Geronimo image to test out. But I think we might want one which has say roller configured perhaps even another which can demonstrate AMQ's message distribution over a cluster. --jason On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) thanks david jencks On Dec 15, 2008, at 12:01 AM, Jason Dillon wrote: I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux+openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare-minimum for folks that need a starting point to roll uber-custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating-system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues? Anyways, seems like a good idea, I'd like to see it happen, its not that hard... what do you folks think? --jason
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
Are you proposing GShell becoming a TLP and not a Geronimo subproject? -Donald Jason Dillon (JIRA) wrote: Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1
Re: Geronimo v2.2 discussion
Joe and I agree that January 9th seems like a good 2.2 branch target, given where we currently stand on: - TCK - SNAPSHOT depends (Axis2, OpenEJB and Geornimo txmanager, specs, components, ...) - Admin Console XSS/XSRF exposure - AMQ 5.2 integration status - Additional testing needed for: - Monitoring - Farming - Plugins, Plugingroups and custom assemblies - Reviewing User Docs - Validating Samples and DayTrader work on 2.2 - . . . -Donald Donald Woods wrote: Given where we are with 2.2, we did not create the branch last Friday as planned in the 2.2 Status page. I'll work with Joe today/tomorrow to get the status page updated and a new target date set. -Donald Hernan Cunico wrote: Hi All, We kinda started to have some discussion some time ago but couldn't find any hit on nabble so not sure were we left it. I added a Geronimo v2.2 Roadmap ../GMOxDEV/geronimo-v22-roadmap.html page at the top of the Development section in the wiki front page, http://cwiki.apache.org/geronimo/ so we can resume the discussion and collect all our thoughts in one place. (edit access is limited to committers/contributors though) Does anybody already have a list? Cheers! Hernan
[jira] Created: (GERONIMO-4469) Missing schema's in /schema directory?
Missing schema's in /schema directory? -- Key: GERONIMO-4469 URL: https://issues.apache.org/jira/browse/GERONIMO-4469 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.2 Reporter: Kevan Miller Fix For: 2.2 There are 5 fewer schemas in a G 2.2 directory than in a 2.1.4 directory. One missing .xsd is geronimo-module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4470) non-overridable filters working properly
non-overridable filters working properly Key: GERONIMO-4470 URL: https://issues.apache.org/jira/browse/GERONIMO-4470 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.4, 2.1.4, 2.2 Reporter: Kevan Miller Fix For: 2.2 If we're unable to load a non-overridable class from a parent classloader and inverse classloading is configured, looks like we'll try to load the class from the local ClassLoader. I don't think this is correct. If we're unable to load from a parent classloader, should always return a ClassNotFoundException... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
No, it just seems that subprojects don't seem to use the parents namespace. mina, activemq seems to follow that, even xbean does that. so i figured I would drop the extra layer. --jason On Dec 16, 2008, at 12:39 AM, Donald Woods wrote: Are you proposing GShell becoming a TLP and not a Geronimo subproject? -Donald Jason Dillon (JIRA) wrote: Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1
[jira] Commented: (GERONIMO-4470) non-overridable filters working properly
[ https://issues.apache.org/jira/browse/GERONIMO-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656850#action_12656850 ] David Jencks commented on GERONIMO-4470: I don't see why you think this is a problem. We aren't overriding a definition from a parent classloader, right? With typical use of filters org.foo.package.name. it will be hard to make it so org.foo.package.name.ParentClass is correctly loaded from the parent but a org.foo.package.name.subpackage.ChildClassOnlyInLocalClassloader can be loaded at all. Is this causing any actual problems? non-overridable filters working properly Key: GERONIMO-4470 URL: https://issues.apache.org/jira/browse/GERONIMO-4470 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.4, 2.1.4, 2.2 Reporter: Kevan Miller Fix For: 2.2 If we're unable to load a non-overridable class from a parent classloader and inverse classloading is configured, looks like we'll try to load the class from the local ClassLoader. I don't think this is correct. If we're unable to load from a parent classloader, should always return a ClassNotFoundException... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4458) Another ClassLoader deadlock during server startup
[
https://issues.apache.org/jira/browse/GERONIMO-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevan Miller reassigned GERONIMO-4458:
--
Assignee: Kevan Miller
Another ClassLoader deadlock during server startup
--
Key: GERONIMO-4458
URL: https://issues.apache.org/jira/browse/GERONIMO-4458
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Reporter: Kevan Miller
Assignee: Kevan Miller
Priority: Critical
Fix For: 2.2
G 2.2 TCK testing is running into a ClassLoader deadlock. Here are the
stacktraces:
{noformat}
Found one Java-level deadlock:
=
RMI TCP Connection(4)-9.42.75.229:
waiting to lock monitor 0x0849be70 (object 0xd57192c8, a
org.apache.geronimo.kernel.config.MultiParentClassLoader),
which is held by main
main:
waiting to lock monitor 0x0849bed4 (object 0xd50ca400, a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader),
which is held by RMI TCP Connection(4)-9.42.75.229
Java stack information for the threads listed above:
===
RMI TCP Connection(4)-9.42.75.229:
at
org.aspectj.weaver.tools.WeavingAdaptor$WeavingAdaptorMessageHolder.init(WeavingAdaptor.java:498)
at
org.aspectj.weaver.tools.WeavingAdaptor.createMessageHandler(WeavingAdaptor.java:179)
at
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:111)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156)
at
org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
- locked 0xd4f23b40 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:52)
at
org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:43)
at
sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:455)
- locked 0xd4f23b40 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
- locked 0xd4ea35c8 (a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:483)
- locked 0xd50ca440 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:441)
- locked 0xd50ca440 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
- locked 0xd50ca400 (a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:483)
- locked 0xd51f63e8 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:392)
- locked 0xd51f63e8 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
[jira] Assigned: (GERONIMO-4469) Missing schema's in /schema directory?
[ https://issues.apache.org/jira/browse/GERONIMO-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4469: - Assignee: Jarek Gawor Missing schema's in /schema directory? -- Key: GERONIMO-4469 URL: https://issues.apache.org/jira/browse/GERONIMO-4469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.2 There are 5 fewer schemas in a G 2.2 directory than in a 2.1.4 directory. One missing .xsd is geronimo-module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4469) Missing schema's in /schema directory?
[ https://issues.apache.org/jira/browse/GERONIMO-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656854#action_12656854 ] Jarek Gawor commented on GERONIMO-4469: --- In 2.1 geronimo-jetty-*.xsd and geroniom-tomcat-*.xsd schemas were installed on both assemblies. In trunk, the geronimo-jetty-*.xsd schemas are installed only on the Jetty assembly and the geronimo-tomcat-*.xsd schemas are installed only on the Tomcat assembly. That accounts for 2 schema files. Missing schema's in /schema directory? -- Key: GERONIMO-4469 URL: https://issues.apache.org/jira/browse/GERONIMO-4469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.2 There are 5 fewer schemas in a G 2.2 directory than in a 2.1.4 directory. One missing .xsd is geronimo-module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4470) non-overridable filters working properly
[ https://issues.apache.org/jira/browse/GERONIMO-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656865#action_12656865 ] Kevan Miller commented on GERONIMO-4470: I noticed the behavior while looking at the code. It seemed inconsistent to me. So, created a Jira to track. for hidden-classes filterfoo/filter/hidden-classes, we will *never* search a parent for a foo.* classes. for non-overridable filterbar/filter/non-overridable, we won't load a bar.* classes, if we find the class in a parent. However, if we don't find a bar.LocalOnly in a parent, we'll also try to load from the local ClassLoader. This seems inconsistent to me. And as you note, it's unlikely to behave properly... I would expect the local ClassLoader to never be searched, in this case. Prolly a relatively minor issue. We can argue semantics... Perhaps you have an argument for why the current behavior is a good thing? non-overridable filters working properly Key: GERONIMO-4470 URL: https://issues.apache.org/jira/browse/GERONIMO-4470 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.4, 2.1.4, 2.2 Reporter: Kevan Miller Fix For: 2.2 If we're unable to load a non-overridable class from a parent classloader and inverse classloading is configured, looks like we'll try to load the class from the local ClassLoader. I don't think this is correct. If we're unable to load from a parent classloader, should always return a ClassNotFoundException... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4458) Another ClassLoader deadlock during server startup
[
https://issues.apache.org/jira/browse/GERONIMO-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656871#action_12656871
]
Kevan Miller commented on GERONIMO-4458:
Agreed that the contextclassloader change is not needed -- my mistake.
I agree that disallowing potentially cyclical classloader traversals will avoid
deadlocks. I'll code this and assuming I'm happy with the implementation (and
it works), will commit.
Note that I think we require the following checks during transform()
if classloader is parent of transformer-agent, then ignore.
if classloader is a parent of an individual ClassFileTransformer
implementation, then ignore for the individual transformer.
I'm not advocating this for it's functionality, but it's needed to avoid
deadlocks, given current config structure. The alternative is to compute the
superset of all parents (transformer-agent parents and each
ClassFileTransformer implementation parents).
I think there are a few dependency issues which we should probably address
while we're in the neighborhood...
1) wadi-clustering has a dependency on the aspectj config, I don't know why
that's needed...
2) GERONIMO-3141 moved transformer-agent jars into the system classpath. I
don't think that will be needed any longer and the jars can move back to
transformer-agent.
Another ClassLoader deadlock during server startup
--
Key: GERONIMO-4458
URL: https://issues.apache.org/jira/browse/GERONIMO-4458
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Reporter: Kevan Miller
Assignee: Kevan Miller
Priority: Critical
Fix For: 2.2
G 2.2 TCK testing is running into a ClassLoader deadlock. Here are the
stacktraces:
{noformat}
Found one Java-level deadlock:
=
RMI TCP Connection(4)-9.42.75.229:
waiting to lock monitor 0x0849be70 (object 0xd57192c8, a
org.apache.geronimo.kernel.config.MultiParentClassLoader),
which is held by main
main:
waiting to lock monitor 0x0849bed4 (object 0xd50ca400, a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader),
which is held by RMI TCP Connection(4)-9.42.75.229
Java stack information for the threads listed above:
===
RMI TCP Connection(4)-9.42.75.229:
at
org.aspectj.weaver.tools.WeavingAdaptor$WeavingAdaptorMessageHolder.init(WeavingAdaptor.java:498)
at
org.aspectj.weaver.tools.WeavingAdaptor.createMessageHandler(WeavingAdaptor.java:179)
at
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:111)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156)
at
org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
- locked 0xd4f23b40 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:52)
at
org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:43)
at
sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:455)
- locked 0xd4f23b40 (a
org.apache.geronimo.kernel.config.MultiParentClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:69)
- locked 0xd4ea35c8 (a
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader)
at
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader.loadClass(ChildrenConfigurationClassLoader.java:52)
at
[BUILD] trunk: Failed for Revision: 726928
Geronimo Revision: 726928 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 37 minutes 44 seconds
[INFO] Finished at: Mon Dec 15 21:43:08 EST 2008
[INFO] Final Memory: 631M/989M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081215/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:43.027
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 35 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:00:59.593)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:27.757)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.596)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.285)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:14.364)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:18.207)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:42.241)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:46.574)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:51.403)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:45.051)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:29.309)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.091)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:30.638)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:49.741)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:54.116)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:48.963)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:26.271)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:50.109)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
Seems like something we should vote on, given our specs, samples, components and plugin subprojects all use org.apache.geronimo.* -Donald Jason Dillon wrote: No, it just seems that subprojects don't seem to use the parents namespace. mina, activemq seems to follow that, even xbean does that. so i figured I would drop the extra layer. --jason On Dec 16, 2008, at 12:39 AM, Donald Woods wrote: Are you proposing GShell becoming a TLP and not a Geronimo subproject? -Donald Jason Dillon (JIRA) wrote: Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1
[jira] Resolved: (GERONIMO-4469) Missing schema's in /schema directory?
[ https://issues.apache.org/jira/browse/GERONIMO-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4469. --- Resolution: Fixed Committed changes to trunk (revision 726939) to install geronimo-module-1.2.xsd and geronimo-javabean-xmlattribute-1.0.xsd schemas. With this change and my initial comment on the container schemas that should cover all the 'missing' schemas (I was seeing 4 'missing' schemas instead of 5. If I missed one please let me know which one). Missing schema's in /schema directory? -- Key: GERONIMO-4469 URL: https://issues.apache.org/jira/browse/GERONIMO-4469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.2 There are 5 fewer schemas in a G 2.2 directory than in a 2.1.4 directory. One missing .xsd is geronimo-module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-4469) Missing schema's in /schema directory?
[ https://issues.apache.org/jira/browse/GERONIMO-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656854#action_12656854 ] ga...@mcs.anl.gov edited comment on GERONIMO-4469 at 12/15/08 8:46 PM: - In 2.1 geronimo-jetty-\*.xsd and geroniom-tomcat-\*.xsd schemas were installed on both assemblies. In trunk, the geronimo-jetty-\*.xsd schemas are installed only on the Jetty assembly and the geronimo-tomcat-\*.xsd schemas are installed only on the Tomcat assembly. That accounts for 2 schema files. was (Author: ga...@mcs.anl.gov): In 2.1 geronimo-jetty-*.xsd and geroniom-tomcat-*.xsd schemas were installed on both assemblies. In trunk, the geronimo-jetty-*.xsd schemas are installed only on the Jetty assembly and the geronimo-tomcat-*.xsd schemas are installed only on the Tomcat assembly. That accounts for 2 schema files. Missing schema's in /schema directory? -- Key: GERONIMO-4469 URL: https://issues.apache.org/jira/browse/GERONIMO-4469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.2 There are 5 fewer schemas in a G 2.2 directory than in a 2.1.4 directory. One missing .xsd is geronimo-module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo VM-appliance?
If it's for developers, maybe add Maven too. -Jack 2008/12/16 Donald Woods dwo...@apache.org OS+Java 6+FF3+Server+Samples+Eclipse+GEP would be ideal for developers -Donald Jason Dillon wrote: Any idea why kinda of images you'd like to see? I'm gonna try and craft a simple, base-os+Geronimo image to test out. But I think we might want one which has say roller configured perhaps even another which can demonstrate AMQ's message distribution over a cluster. --jason On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) thanks david jencks On Dec 15, 2008, at 12:01 AM, Jason Dillon wrote: I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux+openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare-minimum for folks that need a starting point to roll uber-custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating-system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues?
