Re: Geronimo VM-appliance?
If it's for developers, maybe add Maven too. -Jack 2008/12/16 Donald Woods > 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... obvio
[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-tabpanel&focusedCommentId=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.
[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.
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
[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
[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-tabpanel&focusedCommentId=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.(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
[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-tabpanel&focusedCommentId=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 foo, we will *never* search a parent for a foo.* classes. for bar, 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-4469) Missing schema's in /schema directory?
[ https://issues.apache.org/jira/browse/GERONIMO-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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] 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.(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
[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-tabpanel&focusedCommentId=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.
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] 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.
[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.
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
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 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? --
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] Commented: (GERONIMO-4337) Upgrade to activeMQ 5.x
[ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 /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] 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.
[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
[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.
[jira] Updated: (GERONIMO-4468) 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 > 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 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} > > 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) > > 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) 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) > 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 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} > > 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) > > 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) 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) > 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 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} > > 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) > > 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) 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. > 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 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} > > 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) > > 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] Created: (GERONIMO-4468) elements are interpreted relatively to EAR root
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 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} 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) 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?
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] 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-tabpanel&focusedCommentId=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() > 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.TCPTrans
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
[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 )
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() >> 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.wr
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() >> 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) >>
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
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