[jira] Created: (GERONIMO-5311) Add support for configuration of multipoint server addresses
Add support for configuration of multipoint server addresses Key: GERONIMO-5311 URL: https://issues.apache.org/jira/browse/GERONIMO-5311 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.2.1, 3.0 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.2.1, 3.0 OpenEJB supports multicast and multipoint cluster configurations. We don't have a mechanism for configuring peer servers in a multipoint configuration. We need to add support for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5312) support asynchronous start of ActiveMQ BrokerService
support asynchronous start of ActiveMQ BrokerService Key: GERONIMO-5312 URL: https://issues.apache.org/jira/browse/GERONIMO-5312 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 2.2.1, 3.0 Reporter: Kevan Miller Assignee: Kevan Miller It's possible to configure master-slave configurations of ActiveMQ running within a Geronimo server. However, when a BrokerService is going to be a slave instance, brokerService.start() will block indefinitely. In order to support master-slave configurations, I'd like to allow a BrokerService to start asynchronously (not holding up Geronimo server startup). Note that client configuration (connector/mdb) is a bit tricky... You need to configure clients to use the ActiveMQ discovery or failover protocols. Clients need to be able to find and connect to the master broker. VM or simple tcp-ip configuration won't work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fwd: [Travel Assistance] - Applications Open for ApacheCon NA 2010
All, Note the following Travel Assistance information for ApacheCon 2010. --kevan Begin forwarded message: From: Gav... ga...@16degrees.com.au Date: May 16, 2010 7:25:39 PM EDT To: p...@apache.org Subject: [Travel Assistance] - Applications Open for ApacheCon NA 2010 Reply-To: priv...@incubator.apache.org Hi PMC's Please distribute this notice to your user and dev lists: The Travel Assistance Committee is now taking in applications for those wanting to attend ApacheCon North America (NA) 2010, which is taking place between the 1st and 5th November in Atlanta. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon, but who need some financial support in order to be able to get there. There are limited places available, and all applications will be scored on their individual merit. Financial assistance is available to cover travel to the event, either in part or in full, depending on circumstances. However, the support available for those attending only the barcamp is smaller than that for people attending the whole event. The Travel Assistance Committee aims to support all ApacheCons, and cross-project events, and so it may be prudent for those in Asia and the EU to wait for an event closer to them. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application and details for submitting. Applications for applying for travel assistance are now being accepted, and will close on the 7th July 2010. Good luck to all those that will apply. You are welcome to tweet, blog as appropriate. Regards, The Travel Assistance Committee. - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org
Re: Apply the assign jiras permission
On May 16, 2010, at 10:33 PM, Ben Liang wrote: Hi Donald, I have signed ACL and my jira ID is ben.liang please kindly add me to the contributor list. Hi Ben, You should have contributor rights, now. Look forward to your contributions! --kevan
Re: [VOTE] Release XBean 3.7
Minor points: * Copyright date in the NOTICE file has not been updated * The KEYS file should be deleted * Can the .properties files be updated with source license headers? Their content is trivial/nonsensical, but if syntactically possible would be better to have a header... Major point: * The xbean-finder-shaded jar is not properly licensed, I think. The license file does not include the ASM license. I haven't checked, but it's possible we missed this in previous releases. Here's my -1. --kevan On May 14, 2010, at 7:07 AM, Rick McGuire wrote: Please vote for the geronimo xbean 3.7 release The major changes to this release are: - xbean-blueprint subproject to provide support for Aries blueprint component assembly - xbean-bundleutils subproject to provide useful common utilities for dealing with OSGi bundles. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-030/ tag is here: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) Rick
Re: [VOTE] Release XBean 3.7 - second attempt
Thanks Rick. Looks good. Here's my +1. Apologies about the xbean-finder-shaded mistake. I was confused by the relocation pattern in the pom: relocation patternorg.objectweb.asm/pattern shadedPatternorg.apache.xbean.asm/shadedPattern /relocation Source, build, signature/checksums all look good. --kevan On May 14, 2010, at 10:36 AM, Rick McGuire wrote: Please vote for the geronimo xbean 3.7 release The major changes to this release are: - xbean-blueprint subproject to provide support for Aries blueprint component assembly - xbean-bundleutils subproject to provide useful common utilities for dealing with OSGi bundles. Differences from the 1st attempt: 1) KEYS file has been deleted 2) copyright date in NOTICE file has been updated 3) test properties files have had ASL license headers added. The xbean-finder-shaded license issue that Kevan raised turned out to not be an issue, so no changes were required for that. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-031/ tag is here: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) Rick
Re: [VOTE] special Geronimo OpenEJB 3.1.3.0 release
Seeing some problems... Following files do not have source license headers and IMO must: pom.xml container/openejb-osgi/src/main/resources/default.openejb.conf Some could have them, I believe: container/openejb-activemq4/src/main/resources/login.config container/openejb-core/src/main/resources/login.config container/openejb-osgi/src/main/resources/login.config server/openejb-activemq/src/main/resources/META-INF/org.apache.openejb.server.ServerService/activemq server/openejb-cxf/src/main/resources/META-INF/org.apache.openejb.server.ServerService/cxf I'm skipping the .help/.examples files. Not sure if they syntactically could take license headers... Don't know the licensing for the following file: container/openejb-core/src/main/resources/schema/ejb-jar_1_1.xsd The following file need to be mentioned in the license: container/openejb-jee/src/main/resources/META-INF/schema/xml.xsd server/openejb-axis/src/main/resources/META-INF/schema/soap_encoding_1_1.xsd My build is running now. Given the above, I'm going to be -1. --kevan On May 14, 2010, at 5:30 PM, Rick McGuire wrote: Please vote for the geronimo openejb 3.1.3.0 release This is a version of openejb based on revision r942249. This is a special release to be used on the Geronimo 3.0-M1 release and is being released under the org.apache.geronimo.ext.openejb groupid. This is the working version of openejb that works with Geronimo 3.0. This component is dependent upon the XBean release that is also currently up for a vote. You may need to build XBean yourself to build openejb from the tag file at: https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.7 Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-032/ tag is here: https://svn.apache.org/repos/asf/geronimo/external/tags/openejb-3.1.3.0 Vote open 72 hours. Note also that this is contingent upon the XBean vote also passing. [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) Rick
Re: jconsole instructions
On May 11, 2010, at 1:48 PM, David Jencks wrote: Every time I use jconsole I have to spend a long time trying to figure out how to connect to geronimo. Not sure if its in the wiki but maybe if its on the dev list I'll be able to find instructions again. 1. To get the mbeans in reasonably jsr-77 compliant order start jconsole something like this: jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=type,j2eeType,J2EEServer,J2EEApplication,EJBModule,ResourceAdapterModule,WebModule,name Thanks. I'd always run just plain 'jconsole'. Can't say that I'd suffered greatly, but controlling the mbean tree jconsole builds is probably a good idea... This is an incomplete list. I think its reasonable for everything except jca stuff which have a lot of useless name components. Probably we should fix the abstractName to ObjectName conversion so the property names list comes out more like this, assuming it doesn't contradict jsr77. 2. To connect on localhost use this url: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector and log in with the same password as for deployment, by default system/manager Using Java 6 on Mac OS, I just choose the 'server.jar' local process. Saves me from looking for the URL (which I used to do when running on Java 5). I haven't run jconsole on trunk... Hope this helps me in the future :-D Would prolly be useful to put a script for launching jconsole in bin/ --kevan
Re: jconsole instructions
On May 11, 2010, at 5:49 PM, David Jencks wrote: On May 11, 2010, at 2:40 PM, Kevan Miller wrote: On May 11, 2010, at 1:48 PM, David Jencks wrote: Every time I use jconsole I have to spend a long time trying to figure out how to connect to geronimo. Not sure if its in the wiki but maybe if its on the dev list I'll be able to find instructions again. 1. To get the mbeans in reasonably jsr-77 compliant order start jconsole something like this: jconsole -J-Dcom.sun.tools.jconsole.mbeans.keyPropertyList=type,j2eeType,J2EEServer,J2EEApplication,EJBModule,ResourceAdapterModule,WebModule,name Thanks. I'd always run just plain 'jconsole'. Can't say that I'd suffered greatly, but controlling the mbean tree jconsole builds is probably a good idea... This is an incomplete list. I think its reasonable for everything except jca stuff which have a lot of useless name components. Probably we should fix the abstractName to ObjectName conversion so the property names list comes out more like this, assuming it doesn't contradict jsr77. 2. To connect on localhost use this url: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector and log in with the same password as for deployment, by default system/manager Using Java 6 on Mac OS, I just choose the 'server.jar' local process. Saves me from looking for the URL (which I used to do when running on Java 5). I haven't run jconsole on trunk... That didn't appear to work for me against trunk (I might have done something wrong). I sort of thought that having installed a JMXConnector with security might disable this direct connection but those experiments were a long time ago. Seems to work fine. Local process is org.apache.geronimo.cli.daemon.DaemonCLI --kevan
Re: [RESULT] [VOTE] Release Geronimo Customized Tomcat 7.0.0.0 (Second Try)
On May 8, 2010, at 8:37 AM, Ivan wrote: OK, thanks for all of your support, we pass the vote for Tomcat 7.0.0.1. I will promote it to central repository later. Three binding vote : Rick, Ivan, and Joe Bohn. Ivan, IMO, calling this vote was premature. No strict guidelines were broken, so the vote stands. However, this is not how I would like to see votes run in the Geronimo community. Please don't repeat. And I'll note that I would expect the Geronimo community do do a better job of monitoring... Things that I'm noting: 1) A bare minimum of 3 PMC votes 2) There were several comments/questions on this release. There were answers/responses, but no attempt to see if the questions were resolved satisfactorily. 3) You identified a functional problem with the release, waited 12 hours and called the vote. IMO, this did not provide much time for additional review or comments. No one said I agree. 4) The vote ran for 4 days (minimum is 3). However, given the above conditions, IMO the vote should have run for a longer time. --kevan
Re: [VOTE] transaction manager component 3.0 #2
+1 Source, signature/checksums, build, license/notice all look good. --kevan On May 7, 2010, at 8:30 PM, David Jencks wrote: Please vote for the geronimo transaction manager component consisting of the transaction manager and connector framework 3.0. The main changes in this release are: - connector 1.6 support - retry support in the transaction manager (not well tested yet). The difference between this and the first release attempt is a fix to handling of heuristic exceptions (GERONIMO-5289) and some more tests, and a little more build cleanup. Due to the retry support the interfaces between these two jars have changed incompatibly, thus the jump to version 3. I've attempted to get reasonable osgi package version ranges in the manifests. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-021/ Tag is here: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-3.0/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) thanks david jencks
Re: [VOTE] Geronimo jaspi component 1.1
Source, signature/checksums look good. RAT looks good. I'm unable to build, however. I get a missing dependency: Missing: -- 1) com.sun.xml.bind:jaxb-xjc:jar:2.2 I'm -1 until this is resolved. --kevan On May 5, 2010, at 7:31 PM, David Jencks wrote: Please vote for the geronimo-jaspi 1.1 component. The major changes to this release are: - packaged as an osgi bundle - fairly non-functional classloading in 1.0 replaced by Rick's ProviderLocator that actually works in osgi. - dependencies upgraded to use bundleized dependencies. I spent some time trying to get the manifest entries to look reasonable to me. Since this is the first osgi release I put the package-version at 1.0. The import version ranges are _versionpolicy[$(version;==;$(@)),$(version;+;$(@)))/_versionpolicy for everything except the self-imports which are [1.0,1.1). I suppose it would have been better to use this version range for the jaspic spec as well, but I didn't. There's always something. Maybe next time the maven-bundle-plugin will do this for us. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-012/ tag is here: https://svn.apache.org/repos/asf/geronimo/components/jaspi/tags/geronimo-jaspi-1.1/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) thanks david jencks
Re: [VOTE] Geronimo jaspi component 1.1
On May 10, 2010, at 2:50 PM, Kevan Miller wrote: Source, signature/checksums look good. RAT looks good. I'm unable to build, however. I get a missing dependency: Missing: -- 1) com.sun.xml.bind:jaxb-xjc:jar:2.2 I'm -1 until this is resolved. I may have had a local maven configuration problem (i switch between a local nexus proxy and raw maven builds). Running a new test, now... --kevan
Re: [VOTE] Geronimo jaspi component 1.1
On May 10, 2010, at 2:50 PM, Kevan Miller wrote: Source, signature/checksums look good. RAT looks good. I'm unable to build, however. I get a missing dependency: Missing: -- 1) com.sun.xml.bind:jaxb-xjc:jar:2.2 I'm -1 until this is resolved. Apologies, my mistake... Build looks good. Here's my +1. --kevan --kevan On May 5, 2010, at 7:31 PM, David Jencks wrote: Please vote for the geronimo-jaspi 1.1 component. The major changes to this release are: - packaged as an osgi bundle - fairly non-functional classloading in 1.0 replaced by Rick's ProviderLocator that actually works in osgi. - dependencies upgraded to use bundleized dependencies. I spent some time trying to get the manifest entries to look reasonable to me. Since this is the first osgi release I put the package-version at 1.0. The import version ranges are _versionpolicy[$(version;==;$(@)),$(version;+;$(@)))/_versionpolicy for everything except the self-imports which are [1.0,1.1). I suppose it would have been better to use this version range for the jaspic spec as well, but I didn't. There's always something. Maybe next time the maven-bundle-plugin will do this for us. Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-012/ tag is here: https://svn.apache.org/repos/asf/geronimo/components/jaspi/tags/geronimo-jaspi-1.1/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) thanks david jencks
Re: [VOTE] Release Geronimo Customized Tomcat 7.0.0.0 (Second Try)
On May 4, 2010, at 1:56 PM, Joe Bohn wrote: +1 (assuming the potential license issue mentioned below is not an issue) I was able to build and run the new tomcat image. The license issue pointed out last time is now resolved but there is one other potential issue. I noticed a number of files under jasper-el that are generated using JJTree JavaCC and so have the following header but no Apache license header. For example: /* Generated By:JJTreeJavaCC: Do not edit this line. ELParser.java */ Some other generated files include both a generated header and which is immediately followed by the Apache license header. This seems a little better to me. However, I see that we have released these without the Apache header in earlier versions (and Tomcat as well) - so I presume there must be some valid justification for not including an Apache License header in these files. Just pointing it out now in case it really needs some attention and has just escaped being noticed until now. Comments? I've certainly noticed them in the past... Machine generated files do not require license headers. So, IMO, these files are fine. I do have a question about the version #. IIUC, we are releasing 7.0.0 prior to the TC community. There may be fixes applied to the Tomcat dev tree prior to their 7.0 release. So, this release may not exactly match the functionality of the tomcat release. Is everyone evaluating that in their decision? --kevan
[jira] Created: (GERONIMO-5283) Server restart fails after a hard stop
Server restart fails after a hard stop -- Key: GERONIMO-5283 URL: https://issues.apache.org/jira/browse/GERONIMO-5283 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Kevan Miller Installed the Blog sample, ran it successfully. Stopped the server (kill -9 or reboot your system ;-) I get the following: ka...@root Booting Geronimo Kernel (in Java 1.6.0_17)... Starting Geronimo Application Server v3.0-SNAPSHOT [* ] 94% 21s Starting org.apache.ger...2010-05-04 09:46:28,589 ERROR [DatabaseInitializationGBean] Table/View 'AUTHOR' already exists in Schema 'APP'. [* ] 94% 21s Starting org.apache.ger...2010-05-04 09:46:28,910 ERROR [DatabaseInitializationGBean] Table/View 'HOLDINGEJB' already exists in Schema 'APP'. [*** ] 98% 22s Startup failed org.apache.geronimo.kernel.config.InvalidConfigException: Could not locate configs to start: [default/org.apache.aries.samples.blog.web/1272912147190/wab] at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:154) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:81) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:32) [*** ] 98% 69s Startup failed Note that the server process does not actually end. This is a problem, also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5284) Redeploy of Blog sample fails
Redeploy of Blog sample fails - Key: GERONIMO-5284 URL: https://issues.apache.org/jira/browse/GERONIMO-5284 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 running redeploy of the blog sample fails as follows: $ ./deploy undeploy ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba Using GERONIMO_HOME: /Users/kevan/Demo/geronimo-tomcat7-javaee6-3.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home 2010-05-04 11:30:35,453 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba does not appear to be a the name of a module available on the selected server. Perhaps it has already been stopped or undeployed? If you're trying to specify a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not sure what's running, try the list-modules command. at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:207) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:55) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:173) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5284) Redeploy of Blog sample fails
[ https://issues.apache.org/jira/browse/GERONIMO-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5284: --- Description: running redeploy of the blog sample fails as follows: $ ./deploy redeploy ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba Using GERONIMO_HOME: /Users/kevan/Demo/geronimo-tomcat7-javaee6-3.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Unable to locate Geronimo deployment plan in archive. Calculating default ModuleID from archive name. Attempting to use ModuleID 'default/org.apache.aries.samples.blog.jpa.eba-0.1-incubating//' 2010-05-04 11:28:56,187 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: default/org.apache.aries.samples.blog.jpa.eba-0.1-incubating// does not appear to be a the name of a module available on the selected server. Perhaps it has already been stopped or undeployed? If you're trying to specify a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not sure what's running, try the list-modules command. at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:207) at org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:353) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:173) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) was: running redeploy of the blog sample fails as follows: $ ./deploy undeploy ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba Using GERONIMO_HOME: /Users/kevan/Demo/geronimo-tomcat7-javaee6-3.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home 2010-05-04 11:30:35,453 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba does not appear to be a the name of a module available on the selected server. Perhaps it has already been stopped or undeployed? If you're trying to specify a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not sure what's running, try the list-modules command. at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:207) at org.apache.geronimo.deployment.cli.CommandStart.execute(CommandStart.java:55) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:173) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Redeploy of Blog sample fails - Key: GERONIMO-5284 URL: https://issues.apache.org/jira/browse/GERONIMO-5284 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 running redeploy of the blog sample fails as follows: $ ./deploy redeploy ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba Using GERONIMO_HOME: /Users/kevan/Demo/geronimo-tomcat7-javaee6-3.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Unable to locate Geronimo deployment plan in archive. Calculating default ModuleID from archive name. Attempting to use ModuleID 'default/org.apache.aries.samples.blog.jpa.eba-0.1-incubating//' 2010-05-04 11:28:56,187 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: default/org.apache.aries.samples.blog.jpa.eba-0.1-incubating// does not appear to be a the name of a module available on the selected server. Perhaps it has already been stopped or undeployed? If you're trying to specify a TargetModuleID, use the syntax TargetName|ModuleName instead. If you're not sure what's running, try the list-modules command
[jira] Created: (GERONIMO-5285) deploy, undeploy, deploy of blog sample fails
deploy, undeploy, deploy of blog sample fails - Key: GERONIMO-5285 URL: https://issues.apache.org/jira/browse/GERONIMO-5285 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 After undeploy of blog sample: ./deploy undeploy ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba A subsequent deploy fails: $ ./deploy deploy ../../samples/org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba Using GERONIMO_HOME: /Users/kevan/Demo/geronimo-tomcat7-javaee6-3.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home 2010-05-04 11:31:34,077 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Unable to deploy org.apache.aries.samples.blog.jpa.eba-0.1-incubating.eba: java.io.IOException: Sum file already exists Sum file already exists at org.apache.geronimo.deployment.cli.CommandDeploy.runCommand(CommandDeploy.java:43) at org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:148) at org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:173) at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:65) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Congrats Donald Woods! New ASF Member
Wanted to let the Geronimo community know that Donald Woods is a new member of the ASF. The ASF membership elected Donald in recognition of his many contributions to Geronimo, OpenJPA, and Incubator projects. Congrats to Donald on this well deserved achievement! --kevan
Re: svn commit: r938373 - /geronimo/server/branches/2.2/pom.xml
This is breaking 2.2 builds because of an updated dependency. It's adding a new dependency on org.bouncycastle bcprov-jdk15. We have our own geronimo-crypto library (which was created due to patent issues with bouncycastle library. A new non-patent encumbered bouncycastle jar was created, I think. If so, we may want to switch back to bouncycastle... Either way, need to get the build fixed... --kevan On Apr 27, 2010, at 5:25 AM, genspr...@apache.org wrote: Author: genspring Date: Tue Apr 27 09:25:43 2010 New Revision: 938373 URL: http://svn.apache.org/viewvc?rev=938373view=rev Log: GERONIMO-5277 Update CXF to 2.1.9 , Update myfaces to 1.28 Modified: geronimo/server/branches/2.2/pom.xml Modified: geronimo/server/branches/2.2/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/branches/2.2/pom.xml?rev=938373r1=938372r2=938373view=diff == --- geronimo/server/branches/2.2/pom.xml (original) +++ geronimo/server/branches/2.2/pom.xml Tue Apr 27 09:25:43 2010 @@ -67,7 +67,7 @@ openejbVersion3.1.3-SNAPSHOT/openejbVersion derbyVersion10.5.3.0_1/derbyVersion -cxfVersion2.1.4/cxfVersion +cxfVersion2.1.9/cxfVersion axis2Version1.5/axis2Version axiomVersion1.2.8/axiomVersion springVersion2.5.6/springVersion @@ -1318,7 +1318,7 @@ dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-api/artifactId -version1.2.6/version +version1.2.8/version exclusions exclusion groupIdcommons-logging/groupId @@ -1330,7 +1330,7 @@ dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId -version1.2.6/version +version1.2.8/version exclusions exclusion groupIdcommons-logging/groupId
Re: tomcat test failure?
On May 2, 2010, at 2:17 PM, David Jencks wrote: Anyone else seeing this test failure trace in the tomcat module? I think I have up to date tomcat external and tomcat plugin... I'm seeing the same failure. --kevan
Re: Call for Participation: Technical Talks -- ApacheCon North America 2010
FYI. Forwarding the ApacheCon CFP from annou...@apachecon.com --kevan On Apr 28, 2010, at 1:48 PM, Sally Khudairi wrote: ApacheCon North America 2010 1-5 November 2010 -- Westin Peachtree in Atlanta Technical Tracks: Call For Participation All submissions must be received by Friday, 28 May 2010 at midnight Pacific Time. The official conference, trainings, and expo of The Apache Software Foundation (ASF) returns to Atlanta this November, with dozens of technical, business, and community-focused sessions at the beginner, intermediate, and advanced levels. Over the past decade, the ASF has gone from strength to strength, developing and shepherding nearly 150 Top-Level Projects and new initiatives in the Apache Incubator and Labs. This year's ApacheCon celebrates how Apache technologies have sparked creativity, challenged processes, streamlined development, improved collaboration, launched businesses, bolstered economies, and improved lives. We are proud of our achievements and recognize that the global Apache community --both developers and users-- are responsible for the success and popularity of our products. The ApacheCon Planning Team are soliciting 50-minute technical presentations for the next conference, which will focus on the theme “Servers, the Cloud, and Innovation”. We are particularly interested in highly-relevant, professionally-directed presentations that demonstrate specific probrlems and real-world solutions. Part of the technical program has already been planned; we welcome proposals based on the following Apache Projects and related technical areas: - Cassandra/NoSQL - Content Technologies - (Java) Enterprise Development - Felix/OSGi - Geronimo - Hadoop + friends/Cloud Computing - Lucene, Mahout + friends/Search - Tomcat - Tuscany Submissions are open to anyone with relevant expertise: ASF affiliation is not required to present at, attend, or otherwise participate in ApacheCon. Please keep in mind that whilst we encourage submissions that the highlight the use of specific Apache solutions, we are unable to accept marketing/commercially-oriented presentations. Other proposals, such as panels, or those longer than 50 minutes in duration have been considered in the past. You are welcome to submit an alternate presentation, however, such sessions are accepted under exceptional circumstances. Please be as descriptive as possible, including names/bios of proposed panelists and any related details. All accepted speakers (not co-presenters) qualify for general conference admission and a minimum of two nights lodging at the conference hotel. Additional hotel nights and travel assistance are possible, depending on the number of presentations given and type of assistance needed. To submit a presentation proposal, please send an email to submissions AT apachecon DOT com containing the following information in plaintext (no attachments, please): 1. Your full name, title, and organization 2. Contact information, including your address 3. The name of your proposed session (keep your title simple and relevant to the topic) 4. The technical category of the intended presentation (Cassandra/NoSQL; Content Technologies; (Java) Enterprise Development; Felix/OSGi; Geronimo; Hadoop + friends/Cloud Computing; Lucene, Mahout + friends/Search; Tomcat; or Tuscany) 5. The classification for each presentation (Servers, Cloud, or Innovation) – some presentations may have more than one theme (e.g., a next-generation server can be classified both as Servers and Innovation 6. The intended audience level (beginner, intermediate, advanced) 7. A 75-200 word overview of your presentation 8. A 100-200-word speaker bio that includes prior conference speaking or related experience 9. Feedback or references (with contact information) on presentations given within the last three years To be considered, proposals must be received by Friday, 28 May 2010 at midnight Pacific Time. Please email any questions regarding proposal submissions to cfp AT apachecon DOT com. Technical Tracks Key Dates 23 April 2010: Call For Participation Open 28 May 2010: Call For Participation Closes 11 June 2010: Speaker Acceptance/Rejection Notification 1-5 November 2010: ApacheCon NA 2010 We look forward to seeing you in Atlanta! For the ApacheCon Planning team, Sally Khudairi, Program Lead - To unsubscribe, e-mail: announce-unsubscr...@apachecon.com For additional commands, e-mail: announce-h...@apachecon.com
site problems
http://geronimo.apache.org/ is not correct -- there are problems in the left-hand column. I'm guessing that it has been caused by the recent confluence changes. Anybody able to look at this? --kevan
Re: site problems
On Apr 29, 2010, at 9:05 AM, Joe Bohn wrote: On 4/29/10 8:26 AM, Kevan Miller wrote: http://geronimo.apache.org/ is not correct -- there are problems in the left-hand column. I'm guessing that it has been caused by the recent confluence changes. Anybody able to look at this? --kevan I'm looking into it. It seems that there are some template changes we need to make. I just gave the changes a try on another project with some success so I'll see if I can make it work for Geronimo as well. Thanks Joe. --kevan
Re: [VOTE] Release Geronimo Bundles components for the Geronimo 3.0-M1 release
On Apr 27, 2010, at 6:27 AM, Rick McGuire wrote: On 4/26/2010 10:32 PM, Kevan Miller wrote: Nice stuff Rick. This obviously took some time to prepare the licensing information properly. Thanks! One minor comment -- I notice that some of the new files do not have svn:eol-style=native (i.e. LICENSE.vm). Probably because we don't define the file type in our recommended client configuration -- https://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html. We might want to consider updating... A few questions: * jaxb-impl-2.2_1 -- is this CDDL licensed? or dual-licensed (CDDL/GPL)? The only license I've found for this is CDDL. This URL seems to indicate that JAXB is dual licensed -- https://jaxb.dev.java.net/2.2/ If so, we should include the full license text and make sure we indicate our license choice (CDDL). Some versions of the dual license include instructions on how to apply to a work. Don't see any reason not to use the same wording... * jstl -- same question about dual licensing. Also, the jar contains both LICENSE and LICENSE.txt. I assume LICENSE.txt already existed in the jar? Yes, the LICENSE.txt file came from the original jar. Thanks. --kevan
Re: [VOTE] Release Geronimo Bundles components for the Geronimo 3.0-M1 release
On Apr 27, 2010, at 9:08 AM, Rick McGuire wrote: On 4/27/2010 8:00 AM, Kevan Miller wrote: On Apr 27, 2010, at 6:27 AM, Rick McGuire wrote: On 4/26/2010 10:32 PM, Kevan Miller wrote: Nice stuff Rick. This obviously took some time to prepare the licensing information properly. Thanks! One minor comment -- I notice that some of the new files do not have svn:eol-style=native (i.e. LICENSE.vm). Probably because we don't define the file type in our recommended client configuration -- https://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html. We might want to consider updating... A few questions: * jaxb-impl-2.2_1 -- is this CDDL licensed? or dual-licensed (CDDL/GPL)? The only license I've found for this is CDDL. This URL seems to indicate that JAXB is dual licensed -- https://jaxb.dev.java.net/2.2/ If so, we should include the full license text and make sure we indicate our license choice (CDDL). Some versions of the dual license include instructions on how to apply to a work. Don't see any reason not to use the same wording... I just discovered something very useful to know. You can delete directories from a Nexus staging repository after the item has been closed. I've removed the jaxb-impl from the staging area, and will rollback just the release of that single item and stage a new vote for just jaxb-impl. This vote will now be for all of the bundles except for jaxb-impl, which will allow this to proceed without cancelling the entire vote. Rick * jstl -- same question about dual licensing. Also, the jar contains both LICENSE and LICENSE.txt. I assume LICENSE.txt already existed in the jar? I'm ok with the rollback of jaxb-impl -- as long as it's clear what people are/have voted for. JSTL has a CDDL license, also. Is it CDDL-only or dual licensed, also? --kevan
Re: [VOTE] Release Geronimo Bundles components for the Geronimo 3.0-M1 release
On Apr 27, 2010, at 11:19 AM, Rick McGuire wrote: On 4/27/2010 11:09 AM, Kevan Miller wrote: On Apr 27, 2010, at 9:08 AM, Rick McGuire wrote: On 4/27/2010 8:00 AM, Kevan Miller wrote: On Apr 27, 2010, at 6:27 AM, Rick McGuire wrote: On 4/26/2010 10:32 PM, Kevan Miller wrote: Nice stuff Rick. This obviously took some time to prepare the licensing information properly. Thanks! One minor comment -- I notice that some of the new files do not have svn:eol-style=native (i.e. LICENSE.vm). Probably because we don't define the file type in our recommended client configuration -- https://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html. We might want to consider updating... A few questions: * jaxb-impl-2.2_1 -- is this CDDL licensed? or dual-licensed (CDDL/GPL)? The only license I've found for this is CDDL. This URL seems to indicate that JAXB is dual licensed -- https://jaxb.dev.java.net/2.2/ If so, we should include the full license text and make sure we indicate our license choice (CDDL). Some versions of the dual license include instructions on how to apply to a work. Don't see any reason not to use the same wording... I just discovered something very useful to know. You can delete directories from a Nexus staging repository after the item has been closed. I've removed the jaxb-impl from the staging area, and will rollback just the release of that single item and stage a new vote for just jaxb-impl. This vote will now be for all of the bundles except for jaxb-impl, which will allow this to proceed without cancelling the entire vote. Rick * jstl -- same question about dual licensing. Also, the jar contains both LICENSE and LICENSE.txt. I assume LICENSE.txt already existed in the jar? I'm ok with the rollback of jaxb-impl -- as long as it's clear what people are/have voted for. JSTL has a CDDL license, also. Is it CDDL-only or dual licensed, also? Rats, that's a dual license also. I'll remove that one from the vote also and restage separately. Thanks Rick. So, with the exclusions of jaxb and jstl, I'm +1 for the remaining bundles. --kevan
Re: [VOTE] Release OpenJPA-2.0.0 Plugins for Geronimo 2.1.3-2.1.5 servers
+1 Signatures, checksums, rat, build, license/notice all look good. --kevan On Apr 23, 2010, at 4:15 PM, Donald Woods wrote: I've created a release candidate of a set of plugins that can be used to upgrade an existing Geronimo 2.1.3, 2.1.4, 2.1.5 or 2.1.6-SNAPSHOT server from OpenJPA 1.x to the new OpenJPA 2.0.0 release, so users can start experimenting with a JPA 2.0 certified codebase. You can install the plugins by using the console Plugin portlet and Updating the existing plugin repos to see the g.a.o/plugins/openjpa2 or you can try using the following mirror catalog site: http://people.apache.org/~dwoods/geronimo/openjpa2/ Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-017/ Source tag: https://svn.apache.org/repos/asf/geronimo/plugins/openjpa2/tags/2.1.3/ Source tar/zips: https://repository.apache.org/content/repositories/orgapachegeronimo-017/org/apache/geronimo/plugins/openjpa2/2.1.3/ For plugin installation instructions, see: https://svn.apache.org/repos/asf/geronimo/plugins/openjpa2/tags/README.txt Note: There are 2 plugins at version 2.1.3 to install (openjpa2 and persistence-deployer-jpa20.) You will need to restart your server before running or deploying apps that need JPA2 so the artifactAlias entries will take affect and replace already loaded OpenJPA 1.x and spec jars. The latest version of Daytrader 2.1.3 that can be used for testing can be installed as a plugin from: http://people.apache.org/~dwoods/daytrader-2.1.3/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [VOTE] Release OpenJPA-2.0.0 Plugins for Geronimo 2.2-2.2.1 servers
Hi Donald, Looks pretty good. I wasn't able to install on a 2.2.1-SNAPSHOT server, however. Is it working for you? 2010-04-27 20:54:53,060 ERROR [PluginInstallerGBean] Unable to install plugin org.apache.geronimo.kernel.repository.MissingDependencyException: Plugin is not installable on Geronimo 2.2.1-SNAPSHOT Missing dependency: org.apache.geronimo.configs/transaction/2.2/car at org.apache.geronimo.system.plugin.PluginInstallerGBean.validatePlugin(PluginInstallerGBean.java:1069) at org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:1230) ... --kevan On Apr 23, 2010, at 4:17 PM, Donald Woods wrote: I've created a release candidate of a set of plugins that can be used to upgrade an existing Geronimo 2.2 or 2.2.1-SNAPSHOT server from OpenJPA 1.x to the new OpenJPA 2.0.0 release, so users can start experimenting with a JPA 2.0 certified codebase. You can install the plugins by using the console Plugin portlet and Updating the existing plugin repos to see the g.a.o/plugins/openjpa2 or you can try using the following mirror catalog site: http://people.apache.org/~dwoods/geronimo/openjpa2/ Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-018/ Source tag: https://svn.apache.org/repos/asf/geronimo/plugins/openjpa2/tags/2.2/ Source tar/zips: https://repository.apache.org/content/repositories/orgapachegeronimo-018/org/apache/geronimo/plugins/openjpa2/2.2/ For plugin installation instructions, see: https://svn.apache.org/repos/asf/geronimo/plugins/openjpa2/tags/2.2/README.txt Note: There are 2 plugins at version 2.2 to install (openjpa2 and persistence-deployer-jpa20.) You will need to restart your server before running or deploying apps that need JPA2 so the artifactAlias entries will take affect and replace already loaded OpenJPA 1.x and spec jars. The latest version of Daytrader 2.2-SNAPSHOT that can be used for testing can be installed as a plugin from the normal plugin repos. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Donald
Re: [DISCUSSION] Time to release Geronimo 2.2.1 ?
On Apr 26, 2010, at 5:22 AM, Shawn Jiang wrote: We have had a couple of fixes in the 2.2 branch since the Geronimo 2.2 was released. Maybe it's time to release Geronimo 2.2.1 to bring all the available fixes to Geronimo users. If everybody agree to release the new 2.2.1 release. I'd like to volunteer to be the release mananger of this release. : ) I've created a wiki page[1] to track the current status of 2.2 branch since Geronimo 2.2. If there's something that you want to include in the new release, this is the thread to speak out. [1] https://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+2.2.1+Release+Status Thanks Shawn. Sounds good to me. --kevan
Re: [VOTE] Yoko 1.1 with osgi
On Apr 26, 2010, at 5:51 PM, David Jencks wrote: Kevan, I've talked with Brian Fox and he says the checksums are recalculated when a staging repo is promoted. So, fixing them in the staging repo would have no lasting effect. Based on this would you be interested in revising your -1? Heh. So there's no point in validating the checksums to begin with? :) I'm ok assuming that the checksum issue will be fixed during the release process. Given the fact that I'm happy with the artifacts and signature -- here's my +1 --kevan thanks david jencks On Apr 25, 2010, at 4:27 PM, David Jencks wrote: The bad checksums seem to be because somehow maven 2.2.0 got installed on my system. I have no idea why, but it's known to produce bad checksums. I'll try to contact e.g. brian fox to see what we can do about them. I think usually what has happened in the past is to promote, then fix, but maybe they can be fixed before promotion. thanks david jencks On Apr 25, 2010, at 12:25 PM, Kevan Miller wrote: I'm seeing one blocker issue -- all of the checksums that I have downloaded do not match the corresponding checksums that I compute. For instance: $ md5sum yoko-1.1-source-release.tar.gz ; cat yoko-1.1-source-release.tar.gz.md5 md5sum yoko-1.1-source-release.tar.gz ; cat yoko-1.1-source-release.tar.gz.md5 f9283f77a4dfbfa483a085fb073bc3f7 yoko-1.1-source-release.tar.gz e849d7acbeafe1726252619e651f534c Until these are fixed, I'm -1 for the release. I'm ok with the vote proceeding, if these can be fixed in place (it doesn't look like the release artifacts need to be updated, just the checksums). There's one minor issue in the NOTICE file. The COPYRIGHT date has not been updated: Copyright 1999-2008 The Apache Software Foundation Our convention has been to keep the last year up to date, upon the release. This is not a requirement... --kevan On Apr 22, 2010, at 10:38 PM, David Jencks wrote: Please vote on yoko 1.1, yoko with osgi support. It works enough so an ORB and HandleDelegate can be bound in jndi. There are no non-classloading related code changes from previous yoko releases. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-013/ Tag: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.1/
Re: [VOTE] Release Geronimo Bundles components for the Geronimo 3.0-M1 release
Nice stuff Rick. This obviously took some time to prepare the licensing information properly. Thanks! One minor comment -- I notice that some of the new files do not have svn:eol-style=native (i.e. LICENSE.vm). Probably because we don't define the file type in our recommended client configuration -- https://cwiki.apache.org/GMOxDEV/subversion-client-configuration.html. We might want to consider updating... A few questions: * jaxb-impl-2.2_1 -- is this CDDL licensed? or dual-licensed (CDDL/GPL)? * jstl -- same question about dual licensing. Also, the jar contains both LICENSE and LICENSE.txt. I assume LICENSE.txt already existed in the jar? --kevan On Apr 23, 2010, at 2:45 PM, Rick McGuire wrote: To support the upcoming Geronimo milestone release, I would like to the newly created bundles components. This components are versions of external Geronimo dependencies that have been converted into OSGi jars. This is a single vote for all of the converted dependencies required for the Geronimo 3.0-M1 release. A note on the bundle version numbers. The numbering scheme uses the version number from the original component jar, with a Geronimo version number added using a _n suffix (all of these are the _1 version). The Derby version, 10.5.3.0_1_1 is not a type. This is the wrappering based on the 10.5.3.0_1 version of Derby. The RAT and IANAL plugins have been run against of the projects. All tag svn versions have been successfully built. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-016/ All source repos are relative to location https://svn.apache.org/repos/asf/geronimo/bundles/tags and have the same final element as the artifact name. I am not listing each location individually because the mailing list server rejected my original email as spam because of the large number of links in the email. I apologize for the incovenience. The following components are being voted on bundles-parent-1.0 (this is just the parent pom for all of the bundle components) aspectjrt-1.6.2_1 aspectjweaver-1.6.2_1 axis-1.4_1 backport-util-concurrent-2.2_1 castor-1.0.5_1 commons-digester-1.8_1 commons-discovery-0.4_1 derby-all-10.5.3.0_1_1 dwr-3.0.M1_1 httpcore-4.0.1_1 jaxb-impl-2.2_1 jstl-1.2_1 scannotation-1.0.2_1 sxc-jaxb-0.7.2_1 sxc-runtime-0.7.2_1 wadi-aop-2.1.2_1 wadi-core-2.1.2_1 wadi-group-2.1.2_1 wadi-tribes-2.1.2_1 woden-impl-dom-1.0M8_1 woodstox-3.2.9_1
Re: [VOTE] Yoko 1.1 with osgi
I'm seeing one blocker issue -- all of the checksums that I have downloaded do not match the corresponding checksums that I compute. For instance: $ md5sum yoko-1.1-source-release.tar.gz ; cat yoko-1.1-source-release.tar.gz.md5 md5sum yoko-1.1-source-release.tar.gz ; cat yoko-1.1-source-release.tar.gz.md5 f9283f77a4dfbfa483a085fb073bc3f7 yoko-1.1-source-release.tar.gz e849d7acbeafe1726252619e651f534c Until these are fixed, I'm -1 for the release. I'm ok with the vote proceeding, if these can be fixed in place (it doesn't look like the release artifacts need to be updated, just the checksums). There's one minor issue in the NOTICE file. The COPYRIGHT date has not been updated: Copyright 1999-2008 The Apache Software Foundation Our convention has been to keep the last year up to date, upon the release. This is not a requirement... --kevan On Apr 22, 2010, at 10:38 PM, David Jencks wrote: Please vote on yoko 1.1, yoko with osgi support. It works enough so an ORB and HandleDelegate can be bound in jndi. There are no non-classloading related code changes from previous yoko releases. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-013/ Tag: https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.1/
Re: [VOTE] Release Geronimo Java EE specs (attempt THREE)
On Apr 22, 2010, at 3:43 PM, Donald Woods wrote: Here are 3 scripts attached to help checkout, rat:check and build the tags in the vote. Thanks for the scripts. A few comments: 1) We are voting on source artifacts, not svn. So, I use wget. (e.g. 'wget --no-check-certificate https://repository.apache.org/content/repositories/orgapachegeronimo-007/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.1/geronimo-activation_1.1_spec-1.1-source-release.tar.gz). 2) I generally try to insure that the svn tag is equivalent to the source archive (e.g. 'diff -r --strip-trailing-cr geronimo-activation_1.1_spec-1.1 geronimo-activation_1.1_spec-svn') SVN's handling of $Date tags can make this a bit painful... 3) Easier to use 'svn export' rather than 'svn co' 4) I generally try to verify the signatures and checksums also. --kevan
Re: [VOTE] Release Geronimo Java EE specs (attempt THREE)
On Apr 22, 2010, at 3:43 PM, Donald Woods wrote: Can we ignore the following rat:check failures? geronimo-servlet_3.0_spec-1.0 - src/main/resources/javax/servlet/resources/xml.xsd src/main/resources/javax/servlet/resources/XMLSchema.dtd geronimo-javamail_1.4_spec-1.7 - src/test/resources/wmtom.bin geronimo-javamail_1.4-1.8/geronimo-javamail_1.4_provider - Several files under - src/main/resources/OSGI-INF/providers/ All look fine to me... --kevan
Re: [VOTE] Release Geronimo Java EE specs (attempt THREE)
Looks good. Thanks Rick! Here's my +1 --kevan On Apr 22, 2010, at 8:07 AM, Rick McGuire wrote: To support the upcoming Geronimo milestone release, I would like to release Java EE 6 versions of the geronimo specifications. This is a single vote for all specs new or updated for Java EE 6. In addition, the specs have been updated with common support for OSGi interactions. The RAT and IANAL plugins have been run against of the projects. All non-beta specs have clean TCK signature tests. All tag svn versions have been successfully built. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-030/ Unless noted, the source repos are relative to location https://svn.apache.org/repos/asf/geronimo/specs/tags/ and have the same final element as the artifact name. I am not listing each location individually because the mailing list server rejected my original email as spam because of the large number of links in the email. I apologize for the incovenience. The following specs are being voted on geronimo-activation_1.1_spec-1.1 geronimo-annotation_1.1_spec-1.0 geronimo-atinject_1.0_spec-1.0 geronimo-ejb_3.1_spec-1.0 geronimo-el_2.2_spec-1.0 geronimo-interceptor_1.1_spec-1.0 geronimo-j2ee-connector_1.6_spec-1.0 geronimo-jacc_1.4_spec-1.0 geronimo-jaspic_1.0_spec-1.1 geronimo-javaee-deployment_1.1MR3_spec-1.0.1 geronimo-javamail_1.4_spec-1.7 and the closely associated provider and uber jar releases. geronimo-javamail_1.4-1.8 Source location: geronimo/javamail/tags/geronimo-javamail_1.4-1.8 geronimo-jaxb_2.2_spec-1.0 geronimo-jaxr_1.0_spec-2.1 geronimo-jaxrpc_1.1_spec-2.1 geronimo-jaxrs_1.1_spec-1.0 geronimo-jaxws_2.2_spec-1.0 geronimo-jcdi_1.0_spec-1.0 geronimo-jpa_2.0_spec-1.1 geronimo-jsp_2.2_spec-1.0 geronimo-osgi-support-1.0 geronimo-saaj_1.3_spec-1.1 geronimo-servlet_3.0_spec-1.0 geronimo-stax-api_1.2_spec-1.0 geronimo-validation_1.0_spec-1.1 geronimo-ws-metadata_2.0_spec-1.1.3 geronimo-ccpp_1.0_spec-1.0-beta (this is a beta version that has not been verified via TCK yet)
[RESULT][VOTE] Geronimo Eclipse Plugin 2.1.5 RC1
Delos, For scanning mailing list history, it's helpful if you update the Subject with a [RESULT] --kevan On Apr 23, 2010, at 3:54 AM, Delos wrote: Besides, we also get +1 from Ashish and Forrest, thanks! 2010/4/23 Delos dait...@gmail.com GEP RC1 passed the voting with following result 0: no +1: Donald, Kevan,Ivan -1: no The release process will proceed. Thank you! 2010/4/23 Forrest Xia forres...@gmail.com +1 Did some testing on this RC1 with eclipse 3.5.2 java ee build, everything looks fine, thanks Delos! Forrest -- Best Regards, Delos -- Best Regards, Delos
[jira] Created: (GERONIMO-5268) Context did not start for an unknown reason -- does not help identify the true cause of a deployment failure
Context did not start for an unknown reason -- does not help identify the true cause of a deployment failure Key: GERONIMO-5268 URL: https://issues.apache.org/jira/browse/GERONIMO-5268 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.2, 2.1.5, 3.0 Reporter: Kevan Miller Errors like the following are difficult to debug/diagnose. We should do something to make it easier for users to diagnose the actual issue. $ ./bin/deploy.sh -v --user system --password manager deploy jms-webapp.war Using GERONIMO_HOME: /opt/geronimo-tomcat6-minimal-2.2 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: 22:49:03,936 INFO [AbstractGBeanReference] GBean references are not using proxies 22:49:04,212 INFO [MultiParentClassLoader] ClassLoading behaviour has changed. The Original Classloading mode is in effect. If you are experiencing a problem you can change the behaviour by specifying -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify =safe to revert to the original behaviour. This is a temporary change until we decide whether or not to make it permanent for the 2.0 release 2010-04-22 22:49:13,247 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Operation failed: start of org.apache.activemq.book/jms-webapp/1.0-SNAPSHOT/war failed org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.activemq.book/jms-webapp/1.0-SNAPSHOT/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:527) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1366) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649
[jira] Created: (GERONIMO-5269) ContainerBase.addChild: start: LifecycleException: java.io.IOException: Context did not start for an unknown reason
ContainerBase.addChild: start: LifecycleException: java.io.IOException: Context did not start for an unknown reason Key: GERONIMO-5269 URL: https://issues.apache.org/jira/browse/GERONIMO-5269 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.2, 2.1.5, 3.0 Reporter: Kevan Miller Failures of the following sort provide almost no information to users. The underlying cause is hard to diagnose. We need to do something to provide more information to users for this specific scenario. ./bin/deploy.sh -v --user system --password manager deploy jms-webapp.war Using GERONIMO_HOME: /opt/geronimo-tomcat6-minimal-2.2 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: 22:49:03,936 INFO [AbstractGBeanReference] GBean references are not using proxies 22:49:04,212 INFO [MultiParentClassLoader] ClassLoading behaviour has changed. The Original Classloading mode is in effect. If you are experiencing a problem you can change the behaviour by specifying -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify =safe to revert to the original behaviour. This is a temporary change until we decide whether or not to make it permanent for the 2.0 release 2010-04-22 22:49:13,247 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Operation failed: start of org.foo/jms-webapp/1.0-SNAPSHOT/war failed org.apache.geronimo.kernel.config.LifecycleException: start of org.foo/jms-webapp/1.0-SNAPSHOT/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:527) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1366) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport
[jira] Closed: (GERONIMO-5269) ContainerBase.addChild: start: LifecycleException: java.io.IOException: Context did not start for an unknown reason
[ https://issues.apache.org/jira/browse/GERONIMO-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-5269. -- Resolution: Duplicate oops. ContainerBase.addChild: start: LifecycleException: java.io.IOException: Context did not start for an unknown reason Key: GERONIMO-5269 URL: https://issues.apache.org/jira/browse/GERONIMO-5269 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1.5, 2.2, 3.0 Reporter: Kevan Miller Failures of the following sort provide almost no information to users. The underlying cause is hard to diagnose. We need to do something to provide more information to users for this specific scenario. ./bin/deploy.sh -v --user system --password manager deploy jms-webapp.war Using GERONIMO_HOME: /opt/geronimo-tomcat6-minimal-2.2 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: 22:49:03,936 INFO [AbstractGBeanReference] GBean references are not using proxies 22:49:04,212 INFO [MultiParentClassLoader] ClassLoading behaviour has changed. The Original Classloading mode is in effect. If you are experiencing a problem you can change the behaviour by specifying -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify =safe to revert to the original behaviour. This is a temporary change until we decide whether or not to make it permanent for the 2.0 release 2010-04-22 22:49:13,247 ERROR [DeployTool] Error: org.apache.geronimo.common.DeploymentException: Operation failed: start of org.foo/jms-webapp/1.0-SNAPSHOT/war failed org.apache.geronimo.kernel.config.LifecycleException: start of org.foo/jms-webapp/1.0-SNAPSHOT/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:527) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1366) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged
Re: Legal files in org.apache.gernimo.bundles jars
On Apr 22, 2010, at 12:01 PM, Rick McGuire wrote: I've been working on moving the org.apache.geronimo.bundles components out of the server tree into its own top-level project so these bundles can be released separately. The working copy can be found here: https://svn.apache.org/repos/asf/geronimo/bundles/trunk One issue is how the legal files need to be handled. Since these bundles contain code developed under other licenses, that information needs to be noted in these jars. In addition, the release plugin is gives an error on these components because the source artifact does not contain legal files. I've taken a first pass at fixing this for two of the components, asm-3.1 and jaxb-impl. Here are the steps I've taken: 1) Added a NOTICE and LICENSE file to root of the subproject. This solved the problem of release plugin error. 2) Added src/main/appended-resources/META-INF/LICENSE.vm and NOTICE.vm files to the subproject. These files get appended to the standard apache license files and will contain the LICENSE and NOTICE information for the source jar. The NOTICE and LICENSE files used in the assembly boilerplate is used as the source of the information when possible. All jars will have a LICENSE.vm file, but not all need to have a NOTICE.vm. The asm-3.1 does not require the NOTICE, jaxb-impl does (which I why I chose these for the initial work). I believe this will satisfy our requirements for redistributing these jars, but I'd like some feedback on whether these two are correct before I make the changes to all of the subproject. I haven't looked at the specific test cases, but that sounds like the right approach. Thanks for doing this Rick. --kevan
Re: [VOTE] Geronimo Eclipse Plugin 2.1.5 RC1
Signature/checksums look good. I ran RAT and built successfully. Will leave the testing for others. Here's my +1 --kevan On Apr 18, 2010, at 10:28 PM, Delos wrote: Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 2.1.5 RC1. The source code zip is here: https://repository.apache.org/content/repositories/orgapachegeronimo-036/org/apache/geronimo/devtools/geronimo-eclipse-plugin/2.1.5/geronimo-eclipse-plugin-2.1.5-source-release.zip The deployable zip file is here: http://people.apache.org/dist/geronimo/eclipse/unstable/2.1.5/geronimo-eclipse-plugin-2.1.5-deployable.zip The update site zip file is here: http://people.apache.org/dist/geronimo/eclipse/unstable/2.1.5/geronimo-eclipse-plugin-2.1.5-updatesite.zip The tag is here: https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.1.5 If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/dist/geronimo/eclipse/unstable/updates/PLUGIN_RELEASE-NOTES-2.1.5.txt Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Ganymede or Galileo) of Eclipse for downloading the GEP itself. http://people.apache.org/dist/geronimo/eclipse/unstable/updates Please let me know if there are any questions and/or problems. -- Best Regards, Delos
Re: [VOTE] Release Geronimo Java EE specs (second try)
Rick, I'm having some problems building this source. There are some dependency issues. For example: ejb 3.1 has a dependency on geronimo-jaxrpc_1.1_spec-2.0.1. That should be geronimo-jaxrpc_1.1_spec-2.1. jaxb 2.2 has a dependency on geronimo-activation_1.1_spec-1.0.3 not geronimo-activation_1.1_spec-1.1. I'm also getting an unresolved dependency during build of geronimo-activation_1.1_spec-1.1: Missing: -- 1) org.apache.geronimo.specs:geronimo-osgi-locator:jar:1.0 Unless I'm able to build from source successfully, afraid I'm going to be -1 on these releases. Can you or somebody else double check my results? --kevan On Apr 16, 2010, at 10:43 AM, Rick McGuire wrote: To support the upcoming Geronimo milestone release, I would like to release Java EE 6 versions of the geronimo specifications. This is a single vote for all specs new or updated for Java EE 6. In addition, the specs have been updated with common support for OSGi interactions. The RAT and IANAL plugins have been run against of the projects. All non-beta specs have clean TCK signature tests. Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-030/ Unless noted, the source repos are relative to location https://svn.apache.org/repos/asf/geronimo/specs/tags/ and have the same final element as the artifact name. I am not listing each location individually because the mailing list server rejected my original email as spam because of the large number of links in the email. I apologize for the incovenience. The following specs are being voted on geronimo-activation_1.1_spec-1.1 geronimo-annotation_1.1_spec-1.0 geronimo-atinject_1.0_spec-1.0 geronimo-ejb_3.1_spec-1.0 geronimo-el_2.2_spec-1.0 geronimo-interceptor_1.1_spec-1.0 geronimo-j2ee-connector_1.6_spec-1.0 geronimo-jacc_1.4_spec-1.0 geronimo-jaspic_1.0_spec-1.0 geronimo-javaee-deployment_1.1MR3_spec-1.0.1 geronimo-javamail_1.4_spec-1.7 and the closely associated provider and uber jar releases. geronimo-javamail_1.4-1.8 Source location: geronimo/javamail/tags/geronimo-javamail_1.4-1.8 geronimo-jaxb_2.2_spec-1.0 geronimo-jaxr_1.0_spec-2.1 geronimo-jaxrpc_1.1_spec-2.1 geronimo-jaxrs_1.1_spec-1.0 geronimo-jaxws_2.2_spec-1.0 geronimo-jcdi_1.0_spec-1.0 geronimo-jpa_3.0_spec-1.2 geronimo-jsp_2.2_spec-1.0 geronimo-osgi-support-1.0 geronimo-saaj_1.3_spec-1.1 geronimo-servlet_3.0_spec-1.0 geronimo-stax-api_1.2_spec-1.0 geronimo-validation_1.0_spec-1.1 geronimo-ws-metadata_2.0_spec-1.1.3 geronimo-ccpp_1.0_spec-1.0-beta (this is a beta version that has not been verified via TCK yet)
Re: [VOTE] Release Geronimo Java EE specs (second try)
On Apr 21, 2010, at 2:17 PM, Rick McGuire wrote: On 4/21/2010 2:10 PM, Kevan Miller wrote: Rick, I'm having some problems building this source. There are some dependency issues. For example: ejb 3.1 has a dependency on geronimo-jaxrpc_1.1_spec-2.0.1. That should be geronimo-jaxrpc_1.1_spec-2.1. jaxb 2.2 has a dependency on geronimo-activation_1.1_spec-1.0.3 not geronimo-activation_1.1_spec-1.1. I'm also getting an unresolved dependency during build of geronimo-activation_1.1_spec-1.1: Missing: -- 1) org.apache.geronimo.specs:geronimo-osgi-locator:jar:1.0 This one is likely cause by not building the geronimo-osgi-locator project first. I'm able to build this one ok if I build the other first. The ejb and jaxb issues look like stop-release problems to me, unfortunately. Ya. Would have sworn that this was after building osgi-support, but maybe not... --kevan
[jira] Updated: (GERONIMO-5244) Upgrade to AMQ 5.3.1
[ https://issues.apache.org/jira/browse/GERONIMO-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5244: --- Summary: Upgrade to AMQ 5.3.1 (was: Upgrade to AMQ 5.1.3) Upgrade to AMQ 5.3.1 Key: GERONIMO-5244 URL: https://issues.apache.org/jira/browse/GERONIMO-5244 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.2.1 AMQ 5.3.1 has been released with a number of fixes. We should upgrade branches/2.2... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5244) Upgrade to AMQ 5.3.1
[ https://issues.apache.org/jira/browse/GERONIMO-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-5244. -- Resolution: Fixed No apparent problems. Upgrade to AMQ 5.3.1 Key: GERONIMO-5244 URL: https://issues.apache.org/jira/browse/GERONIMO-5244 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.2.1 AMQ 5.3.1 has been released with a number of fixes. We should upgrade branches/2.2... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4871) Something blocking 'kill -3' signals?
[ https://issues.apache.org/jira/browse/GERONIMO-4871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4871. -- Resolution: Cannot Reproduce Not seeing this problem on 2.2 with Java 6. Java 5 doesn't work, but Java 5 isn't supported on snow leopard, anyway... Something blocking 'kill -3' signals? - Key: GERONIMO-4871 URL: https://issues.apache.org/jira/browse/GERONIMO-4871 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Kevan Miller Fix For: 2.2.1 I occasionally use 'kill -3' to cause a java process to dump all thread stacks. For some reason, this isn't working on Geronimo 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4991) Update AXIS2 stack to 1.5.1
[ https://issues.apache.org/jira/browse/GERONIMO-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-4991: -- Assignee: Kevan Miller Update AXIS2 stack to 1.5.1 --- Key: GERONIMO-4991 URL: https://issues.apache.org/jira/browse/GERONIMO-4991 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: Wish List Reporter: Radim Kolar Assignee: Kevan Miller Fix For: 2.2.1 Recently released Axis2 1.5.1 contains some important bugfixes over 1.5. G shipped version should be updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] Availability of Geronimo 2.1.5
On Apr 19, 2010, at 4:27 AM, Rex Wang wrote: Dear all, News has been published in homepage: http://geronimo.apache.org/ Artifacts has been published in: http://www.apache.org/dist/geronimo/2.1.5/ , will it sync to mirrors in 24 hours? I've (again) pulled the artifacts from geronimo/2.1.5 -- there were issues with the artifacts (not a problem with the 2.1.5 release itself, just problems in the download directory). So, 2.1.5 artifacts won't be available until the issues are resolved. --kevan
[DISCUSS] Release Geronimo Java EE specs
On Apr 15, 2010, at 10:29 AM, Rick McGuire wrote: geronimo-javamail_1.4_spec-1.0.7 Hi Rick, This wasn't quite the spec version that I was expecting... Our last javamail spec release was: geronimo-javamail_1.4_spec-1.6 So, I was expecting something like geronimo-javamail_1.4_spec-1.7.0 Was this a typo? Or did I really miss the boat? --kevan
Fwd: [NOTICE] compromised jira passwords
All, Please note the following and take action as appropriate. --kevan Begin forwarded message: From: Joe Schaefer joe_schae...@yahoo.com Date: April 10, 2010 1:24:14 PM EDT To: commun...@apache.org Subject: [NOTICE] compromised jira passwords Reply-To: commun...@apache.org Hello Apache community@ [1], As you are probably aware we have been working to restore services that have been compromised by a very targetted attack against Apache's jira installation. The good news is that jira is back online, with bugzilla and confluence soon to follow [2]. The bad news is that the hacker was able to rejigger jira's code to sniff any cookies and passwords sent to the server between April 6 and April 9. If you used jira at all this week, including via IDE's that interface via SOAP, it is IMPERATIVE that you take time to immediately reset your jira password, and possibly your ldap password if those match up. If you have admin privs in jira your password was reset by us, so you'll need to use the password reset form in jira to regain access. To have a reset password mailed to your contact information in jira, visit https://issues.apache.org/jira/secure/ForgotPassword!default.jspa When you do login to jira be sure to double-check your contact info. To change your ldap password login to people.apache.org and run /usr/sbin/passwd, or else visit https://svn.apache.org/change-password . Thanks for your patience and diligence in this matter. A blog post will be forthcoming which will provide details of the attack and what we have done to mitigate future hack attempts. [1] feel free to forward this note to any other apache mailing list, public or private. [2] at this time we do not believe the hacker compromised the confluence and bugzilla installs, but we are awaiting confirmation from our admins before bringing those back online. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Geronimo specs and OSGi package export versions
Thanks for the update, Rick. Have you made the OpenJPA community aware of this issue? --kevan
[jira] Commented: (GERONIMO-5243) /activemq-console does not require admin authentication
[ https://issues.apache.org/jira/browse/GERONIMO-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854915#action_12854915 ] Kevan Miller commented on GERONIMO-5243: Hmm. It's in a build that I ran last night. I certainly didn't add a dependency for it... /activemq-console does not require admin authentication --- Key: GERONIMO-5243 URL: https://issues.apache.org/jira/browse/GERONIMO-5243 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Kevan Miller Priority: Blocker Fix For: 2.2.1, 3.0 On branches/2.2 I'm able to access http://localhost:8080/activemq-console without authentication. Since I'm able to inspect Destinations, delete Destinations, etc. , this is not a good thing. We need to secure with geronimo-admin realm, just like the admin console. I haven't tested on trunk, but am guessing this is a problem, there also. activemq-console was not shipped in 2.1.0. So, it's not a problem there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-5243) /activemq-console does not require admin authentication
[ https://issues.apache.org/jira/browse/GERONIMO-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-5243. -- Resolution: Not A Problem I must have been looking at the activemq-server test assembly (which does contain the webconsole), not one of the javaee assemblies... Apologies for the noise... /activemq-console does not require admin authentication --- Key: GERONIMO-5243 URL: https://issues.apache.org/jira/browse/GERONIMO-5243 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Kevan Miller Priority: Blocker Fix For: 2.2.1, 3.0 On branches/2.2 I'm able to access http://localhost:8080/activemq-console without authentication. Since I'm able to inspect Destinations, delete Destinations, etc. , this is not a good thing. We need to secure with geronimo-admin realm, just like the admin console. I haven't tested on trunk, but am guessing this is a problem, there also. activemq-console was not shipped in 2.1.0. So, it's not a problem there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Geronimo 2.1.5 (1st try)
+1 I checked signature/checksums, source files, build, testsuite, and simple tests with a server. All looked good to me. Assuming we pass the TCK, we should be good to go... --kevan On Apr 6, 2010, at 9:46 PM, Rex Wang wrote: Dear All, I have managed to use maven-release-plugin to make a 2.1.5 release candidate The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-005/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/geronimo/2.1.5/geronimo-2.1.5-source-release.zip We have to verify the binaries pass the tck, so open the vote for more than the minimum 72 hours. -- Lei Wang (Rex) rwonly AT apache.org
Re: ejbs need some corba...
On Apr 7, 2010, at 6:39 PM, David Jencks wrote: In my efforts to see how much ejb stuff works in trunk I've found that we need at least a little bit of corba to get anywhere, at least the HandleDelegate, so I'm going to be trying to enable the corba stuff as little as possible to be able to proceed with ejbs. Thanks for the heads up. Will be *great* to start to get those codepaths running... --kevan
[jira] Created: (GERONIMO-5243) /activemq-console does not require admin authentication
/activemq-console does not require admin authentication --- Key: GERONIMO-5243 URL: https://issues.apache.org/jira/browse/GERONIMO-5243 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Kevan Miller Priority: Blocker Fix For: 2.2.1, 3.0 On branches/2.2 I'm able to access http://localhost:8080/activemq-console without authentication. Since I'm able to inspect Destinations, delete Destinations, etc. , this is not a good thing. We need to secure with geronimo-admin realm, just like the admin console. I haven't tested on trunk, but am guessing this is a problem, there also. activemq-console was not shipped in 2.1.0. So, it's not a problem there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5244) Upgrade to AMQ 5.1.3
Upgrade to AMQ 5.1.3 Key: GERONIMO-5244 URL: https://issues.apache.org/jira/browse/GERONIMO-5244 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: ActiveMQ Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.2.1 AMQ 5.3.1 has been released with a number of fixes. We should upgrade branches/2.2... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About G3.0 Java EE 6 Samples
On Apr 5, 2010, at 11:18 PM, Forrest Xia wrote: Hi All, We prepared some samples regarding Jave EE 6 new features, so far including these: Hi Forrest, Cool. It's not quite clear to me how much work has been done and who has done the work. I'm now wondering if this is significant enough that it should be a software grant. Perhaps you can create Jira and post as a patch? snip Or just add them directly under samples? As you can see that some Java EE 6 samples are based on existing ones(such as calculator). I personally prefer the former, since it gives user a clear view about where to look for Java EE 6 samples. Donald's list/grouping seems reasonable. Although I'm not sure that we have to provide redundant EE5 samples to demonstrate compatibility... 2. Shall we turn all of these samples into OSGi bundles? or just make Java EE 6 ones as bundles and keep existing ones unchanged? We need to be clear to our users that they do not need to turn EE artifacts into bundles. We should also provide samples that demonstrate some of the advantages/alternatives of OSGi. --kevan
Re: components dependencies
On Apr 5, 2010, at 9:23 AM, Ivan wrote: For geronimo-schema-java1.4 and java 5 schemas, I wish somebody could double-check the descriptions in the license and notice files in the geronimo-schema-javaee_6 before moving them out. I have mentioned it in the past, and Donald gave me some suggestions to refer to the OpenJPA project. I do update them from my understanding. But ... Anyway, if we are OK with the current descriptions, I would move 1.4 and 1.5 out as soon as possible. IIRC, I took a quick look at the ee6 schema license/notice files and they looked good. Would definitely re-review prior to release. Are we going to/do we need to release 1.4 and 1.5 schema's? Originally the 1.4 and 1.5 schemas had license restrictions which prohibited us including in our svn. If all xsd's have been fixed, then we can move them out. It would be good to do this, but if we don't need to re-release them, it's not absolutely imperative, IMO. --kevan
Re: [VOTE] Release tomcat-parent-6.0.26
On Mar 31, 2010, at 9:54 AM, Donald Woods wrote: We'll also be upgrading 2.2.1 to use this level of Tomcat, right? Absolutely should be. --kevan
Re: 3.0 Milestone Release?
On Mar 31, 2010, at 10:40 AM, Rick McGuire wrote: 2) For our dependencies, will we need real releases, or will we ship snapshots based on know revision levels? Definitely real releases, IMO. If we have specific instances where we don't think this is possible, we can discuss alternatives. The only alternative release technique that I'd consider is to release out of geronimo/external/, but would really, really rather not... --kevan
Re: [VOTE] Release tomcat-parent-6.0.26
+1 I checked source, signature/checksums, and build. All looked good. --kevan On Mar 24, 2010, at 10:44 PM, Delos wrote: This voting is for tomcat-parent-6.0.26. It will be used by Geronimo 2.1.5.It's based on tomcat 6.0.26, built with maven. Besides, we also applied some patches which haven't been included in tomcat 6.0.26. Based on tomcat 6.0.26 tag, we applied additional patches for GERONIMO-3451 - 'Restricted listeners property file not found' error logged during Tomcat server startup (Patch from Shawn Jiang) GERONIMO-4685 - patch for revision 790742 Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-015/ svn tag at: https://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-6.0.26.0/ [ ] +1 go for it [ ] 0 [ ] -1 whoa, hold on a minute thanks a lot! -- Best Regards, Delos
[jira] Created: (GERONIMO-5211) geronimo start command is very verbose
geronimo start command is very verbose -- Key: GERONIMO-5211 URL: https://issues.apache.org/jira/browse/GERONIMO-5211 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 Starting the geronimo server on trunk is currently very verbose. There are a lot of BlueprintContainer messages as Karaf is starting. That's followed by the Karaf banner. Finally, followed by the Geronimo startup which in my latest build includes a number of DigesterFactory log entries. Would be good to start cleaning these up. Note I intend to raise a Jira about use of Karaf and Geronimo commands, in general... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5212) Do we need Karaf when starting Geronimo?
Do we need Karaf when starting Geronimo? Key: GERONIMO-5212 URL: https://issues.apache.org/jira/browse/GERONIMO-5212 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 Starting up Karaf seems to consume a fair amount of time as a Geronimo server is started. Is it needed? I think we should consider slimming down the server startup. I'm not sure what it's buying us, at the moment... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5213) Review Geronimo 3.0 commands need a thorough review
Review Geronimo 3.0 commands need a thorough review --- Key: GERONIMO-5213 URL: https://issues.apache.org/jira/browse/GERONIMO-5213 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 The current set of Geronimo commands (geronimo, deploy, start, stop, shutdown, admin, client) need to be reviewed for functionality. Mostly, they are adopting gshell syntax/semantics. There needs to be a thorough review that the new set of commands are providing all of the features/functions that users are currently using. I think having a single set of commands rather than the duplicate commands (old and newer gshell-based commands) is good. There should be documentation on how to migrate from the old environment to the new. For example, for people using JAVA_OPTS / GERONIMO_OPTS how do they move to the new geronimo command? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
3.0 Milestone Release?
I'm curious to hear the community's thoughts about starting to pull together a 3.0 Milestone release. I think there's been a lot of progress on trunk and that it would be valuable to start pulling things together for a release. If anything, just planning for a release starts to identify hat parts are missing and what needs to be done. Also, gives users a chance to start focusing on what features they are going to need... Thoughts? --kevan
Re: svn commit: r926991 - /geronimo/server/branches/2.2/plugins/activemq/activemq-broker/pom.xml
Thanks Rex. Makes sense.
I guess that's consistent with our treatment of server-security-config
dependencies, but I'm not convinced we're handling them correctly. Pretty
certain that we can build alternate assemblies with the same basic problem...
--kevan
On Mar 24, 2010, at 5:40 AM, rwo...@apache.org wrote:
Author: rwonly
Date: Wed Mar 24 09:40:12 2010
New Revision: 926991
URL: http://svn.apache.org/viewvc?rev=926991view=rev
Log:
GERONIMO-5024 var/security/keystores seems to be a required directory, but is
not being created for custom assemblies
Modified:
geronimo/server/branches/2.2/plugins/activemq/activemq-broker/pom.xml
Modified:
geronimo/server/branches/2.2/plugins/activemq/activemq-broker/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/branches/2.2/plugins/activemq/activemq-broker/pom.xml?rev=926991r1=926990r2=926991view=diff
==
--- geronimo/server/branches/2.2/plugins/activemq/activemq-broker/pom.xml
(original)
+++ geronimo/server/branches/2.2/plugins/activemq/activemq-broker/pom.xml Wed
Mar 24 09:40:12 2010
@@ -51,7 +51,14 @@
version${version}/version
typecar/type
/dependency
-
+
+dependency
+groupIdorg.apache.geronimo.framework/groupId
+artifactIdserver-security-config/artifactId
+version${version}/version
+typecar/type
+/dependency
+
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activemq/artifactId
Re: build failed in branches/2.2
On Mar 24, 2010, at 4:22 PM, Marco Laponder wrote: Hi I am a newbi at building geronimo so it could be by lack of knowledge,in that case forgive me. I am trying to build the 2.2 branch from source. I am at the latest revision (927171) and followed the instructions at http://cwiki.apache.org/GMOxDEV/building-apache-geronimo.html I started with an empty maven repository and am running a mvn clean install. The build fails with a compilation problem: /branches/2.2/plugins/connector/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManagerGBean.java:[ 38,8] cannot find symbol symbol : constructor GeronimoWorkManager(java.util.concurrent.Executor,java.util.concurrent.Executor,java.util.concurrent.Executor,org.apache.geronimo.transact ion.manager.XAWork) inspecting the constructors on the GeronimoWorkManager I can see : public GeronimoWorkManager(GeronimoExecutor sync, GeronimoExecutor start, GeronimoExecutor sched, TransactionContextManager transactionContextManager) and I understand that this is not the expected constructor. Can anyone explain to me how to fix this problem or tell me what I am doing wrong ? Hmm. Where are you getting that signature for the GeronimoWorkManager constructor from? That doesn't match -- https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.4/geronimo-connector/src/main/java/org/apache/geronimo/connector/work/GeronimoWorkManager.java I just removed .m2/repository/org/apache/geronimo/components/geronimo-connector/2.1.4 from my local maven repo and was able to rebuild successfully. I also see the automated build ran successfully -- http://people.apache.org/builds/geronimo/server/binaries/2.2/20100324/build-1400.log The sha checksum of my geronimo-connector-2.1.4.jar is fa36907547ad3239128a76d515d83fa3ba4f2ff4 which matches http://repo2.maven.org/maven2/org/apache/geronimo/components/geronimo-connector/2.1.4/geronimo-connector-2.1.4.jar.sha1 The jar file size is 104357 Are you getting a different jar? BTW, I really hate the way that GeronimoWorkManager is in the same package as GeronimoWorkManagerGBean --kevan
Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 4:57 PM, David Jencks wrote: On Mar 24, 2010, at 12:58 PM, Sangjin Lee wrote: Thanks. So it sounds like it will be pretty much a *requirement* that applications on 3.0 need to be fully OSGi bundles, Well, the idea is that the geronimo deployment process will turn your javaee app into one or more bundles. We set up defaults for the osgi manifest headers but you can modify them in your geronimo plans. Right. So traditional EE apps need not change. You can continue to deploy EE defined artifacts (e.g. WAR/EAR/JAR). Users don't need to turn them into bundles. Applications that used Geronimo deployment plan dependencies are likely to require some changes... and if you were using the shared lib as part of your classloading scheme you will have to convert them all to OSGi bundles. Jars that aren't part of a javaee application need to be converted to bundles before installing them. I guess we could provide a default conversion but usually this doesn't seem to be adequate in practice. Do you think this is going to be a problem for users? David never really liked shared-lib, to begin with... ;-) If you have compelling use cases, now is definitely a good time to speak up... There's certainly a set of users that have found shared lib to be convenient. --kevan
Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 5:30 PM, David Jencks wrote: While I always thought shared lib was a bad idea, at least pre-osgi the concept of a classloader that you could just toss things in made sense. I don't think it makes any sense in osgi. There is no dynamic-export header so whatever implementation you came up with would have to know exactly what packages to export... making the idea of adding more stuff to it useless. If you just make sure your jar is bundleized so the packages you want to use are exported, and install the bundle in the osgi framework, the osgi wiring mechanism will take care of making it available to your app, in a simpler, uniform way that is much more flexible than shared lib was. In other words, plain vanilla osgi all by itself does what shared lib was for much much better. The only inconvenience is that you have to make your libraries into bundles somehow. We can certainly talk about how to help people do that, but that will be generally useful and/or impossible to do well. Understood. And I'm not claiming that we'd end up with the same runtime efficiencies of a common shared lib ClassLoader, in previous versions of Geronimo. However, we're processing WARs and EARs with packaged jar files. And we'd better be pretty good at that. And we're certainly not going to require users to convert these jars into bundles. So, is extending this capability to a sharedlib dirctory (outside of the archive) such a big stretch? It might not be as runtime efficient as it could be, but a class of users might well appreciate its simplicity. We also want to be making it easy for users to bundleize jars and incorporate them into Geronimo. However, I'm not convinced that users should always be required to bundlize their jars... --kevan
[jira] Closed: (GERONIMO-4957) javax.el.CompositeELResolver is not thread-safe
[ https://issues.apache.org/jira/browse/GERONIMO-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4957. -- Resolution: Fixed Fix Version/s: 2.2.1 2.1.5 javax.el.CompositeELResolver is not thread-safe --- Key: GERONIMO-4957 URL: https://issues.apache.org/jira/browse/GERONIMO-4957 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.1.4, 2.1.5, 2.2, 2.2.1, 3.0 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.1.5, 2.2.1 A user reported that they get an intermittent NullPointerException: 17:08:45,133 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186) at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:925) ... The only way I can explain this exception is that multiple threads are simultaneously invoking add() (and the resolvers[] array is becoming corrupted). Or multiple threads are simultaneously accessing add() and getValue() (and getValue() is accessing an uninitialized array element). The EL spec is silent on thread-safety issues for CompositeELResolver (though it does identify thread safety issues for some other classes). I don't see anything spec-wise that prevents multi-threaded access to CompositeELResolver. If anyone has other opinions, let me know. Otherwise, looks like we need to close some timing windows in CompositeELResolver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-5200) high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader
[ https://issues.apache.org/jira/browse/GERONIMO-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-5200: -- Assignee: Kevan Miller high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader -- Key: GERONIMO-5200 URL: https://issues.apache.org/jira/browse/GERONIMO-5200 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 2.2 Environment: Linux 64 bits, geronimo 2.2 build 2009.12.07-18:20:06.045-0800 Reporter: Marco Laponder Assignee: Kevan Miller Attachments: thread.dump Sometimes during the use of our webapplication the cpu of our server has extereme high load caused by geronimo which stays high forever untillI stop geronimo. I have created a thread dump when the cpu load is high (attached to this jira). Suspicious in this thread dump are multiple thread in the containsKey. As not all the access of the resourcesNotFOund map is not synchronized this could be the cause of the problem as this might result in a infinite loop when the contains method is called during a map resize. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5200) high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader
[ https://issues.apache.org/jira/browse/GERONIMO-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-5200: --- Affects Version/s: 2.1.4 Fix Version/s: 2.2.1 2.1.5 high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader -- Key: GERONIMO-5200 URL: https://issues.apache.org/jira/browse/GERONIMO-5200 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 2.1.4, 2.2 Environment: Linux 64 bits, geronimo 2.2 build 2009.12.07-18:20:06.045-0800 Reporter: Marco Laponder Assignee: Kevan Miller Fix For: 2.1.5, 2.2.1 Attachments: thread.dump Sometimes during the use of our webapplication the cpu of our server has extereme high load caused by geronimo which stays high forever untillI stop geronimo. I have created a thread dump when the cpu load is high (attached to this jira). Suspicious in this thread dump are multiple thread in the containsKey. As not all the access of the resourcesNotFOund map is not synchronized this could be the cause of the problem as this might result in a infinite loop when the contains method is called during a map resize. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-5200) high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader
[ https://issues.apache.org/jira/browse/GERONIMO-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-5200. Resolution: Fixed Should be fixed. Now using ConcurrentHashMap, instead of HashSet. high cpu load, probably result of concurrent access of resourcesNotFound in MultiParentClassLoader -- Key: GERONIMO-5200 URL: https://issues.apache.org/jira/browse/GERONIMO-5200 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 2.1.4, 2.2 Environment: Linux 64 bits, geronimo 2.2 build 2009.12.07-18:20:06.045-0800 Reporter: Marco Laponder Assignee: Kevan Miller Fix For: 2.1.5, 2.2.1 Attachments: thread.dump Sometimes during the use of our webapplication the cpu of our server has extereme high load caused by geronimo which stays high forever untillI stop geronimo. I have created a thread dump when the cpu load is high (attached to this jira). Suspicious in this thread dump are multiple thread in the containsKey. As not all the access of the resourcesNotFOund map is not synchronized this could be the cause of the problem as this might result in a infinite loop when the contains method is called during a map resize. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5198) MultiParentClassLoader caching not found resources
[ https://issues.apache.org/jira/browse/GERONIMO-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12848705#action_12848705 ] Kevan Miller commented on GERONIMO-5198: Is your SharedLib a dependency of your application? Or are you actually creating a SharedLib gbean in your application deployment plan? Understand the general nature of your request. Want to be sure we understand you exact environment, also. Will give this some thought... MultiParentClassLoader caching not found resources -- Key: GERONIMO-5198 URL: https://issues.apache.org/jira/browse/GERONIMO-5198 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.2 Environment: Linux 64 bit Reporter: Marco Laponder We have extended the default classpath with a directory by specifying in the deployment plan an org.apache.geronimo.system.sharedlib.SharedLib gbean. So we are able to read application specific files from this directory. It is possbile for out application the resource can not be found at a given time, but the resource exists at a later time because it has been added to the directory. However when geronimo doesn't find the resource its add its name to the 'resourcesNotFound' map in the MultiParentClassLoader.java:571 in the 2.2 branch. The result of this caching is that we cannot find the resource after it has been placed in the direcotry. Would it be possible to configure this behaviour, clear the not found cache or is there an other solution to this problem ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: REMINDER : Upcoming change to SVN authentication
Sending this to any Geronimo committers having problems committing to svn. SVN authentication is now using LDAP. See the instructions below, about changing your LDAP password, if you do not know your LDAP password. This information was sent to committ...@a.o. If you are an ASF Committer, you should be subscribed to the committers mailing list -- it provides you with useful information. --kevan On Mar 18, 2010, at 6:53 PM, Tony Stevenson wrote: On 18/02/2010 19:02, Tony Stevenson wrote: Folks, On March 19th we will be changing the source of authentication for all SVN accounts. REMINDER :: We still intend to make this change. If you do not know if this affects you or not you should read the original email below. For most Committers, we suggest you update your paswords at: https://svn.apache.org/change-password This will then sync your passwords, and you will be able to continue after the cut-over without loss of service. If you already know your LDAP password, which is also used for logins to people.apache.org, you do not have to do this. After the cutover date, your old Subversion HTTP Authentication password will stop working. The technical details: At the moment all committers have a distinct SVN account. This is essentially an entry in a htpasswd file. As you should all know by now we have been working on migrating to LDAP, we have now completed phase 1 of this; we have imported shell/Posix users and groups. What we want to do next is remove this local SVN account, and use LDAP as the authentication provider. This is a simple change, but has some repercussions that may effect a large number of you. After we switch over, the password for SVN will be your current LDAP one. We expect that many of you dont remember your LDAP password, and so what we want you to do is go and reset your LDAP password now, to avoid being unable to commit to SVN. Also, shortly after the LDAP groups were imported Nexus (repository.apache.org) switched to using LDAP for it's authentication source. If you use this and discover you have been unable to login since the cut-over you should use the steps above to resolve your login issues. -- Cheers, Tony Tony Stevenson t...@pc-tony.com - pct...@apache.org pct...@freenode.net - t...@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66
[jira] Created: (GERONIMO-5204) var/security/keystores seems to be a required directory, but is not being created for custom assemblies
var/security/keystores seems to be a required directory, but is not being created for custom assemblies --- Key: GERONIMO-5204 URL: https://issues.apache.org/jira/browse/GERONIMO-5204 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.5, 2.2.1 Reporter: Kevan Miller Priority: Blocker Fix For: 2.1.5, 2.2.1 Looks like there's a problem with customer assemblies. I'm guessing due to recent keystore updates. I created a custom assembly using the following command: deploy/assemble --artifact testserver --groupId org.foo org.apache.geronimo.configs/activemq-broker/2.1.5-SNAPSHOT/car org.apache.geronimo.assemblies/geronimo-boilerplate-minimal/2.1.5-SNAPSHOT/jar When I untarred and started the server, I got the following error: ./geronimo.sh run Using GERONIMO_HOME: /Users/kevan/geronimo/server/branches/2.1/assemblies/geronimo-tomcat6-javaee5/target/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/testserver-1.0 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home Booting Geronimo Kernel (in Java 1.6.0_17)... Starting Geronimo Application Server v2.1.5-SNAPSHOT [*** ] 49% 1s Loading org.apache.ger...2010-03-23 20:30:06,050 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/j2ee-security/2.1.5-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/j2ee-security/2.1.5-SNAPSHOT/car,j2eeType=GBean,name=KeystoreManager java.lang.IllegalStateException: FileKeystoreManager must have a root that's a valid readable directory (not /Users/kevan/geronimo/server/branches/2.1/assemblies/geronimo-tomcat6-javaee5/target/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/testserver-1.0/var/security/keystores) at org.apache.geronimo.security.keystore.FileKeystoreManager.doStart(FileKeystoreManager.java:105) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:563) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:832) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$d9b283b7.startConfiguration(generated) at org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:206) at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:89) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30) [*** ] 49% 1s Startup failed org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.framework/j2ee-security/2.1.5-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:580
Re: Will your project feature at ApacheCon North America 2010?
Apologies for the broadcast message... In thinking about ApacheCon 2010, I began to wonder if there is interest in creating an Enterprise Java track for the conference. I think there is the potential for a lot of interesting content. Many of our projects are busy implementing JSR specs for Java EE6. Also, the OSGi Alliance EEG has created several EE-focuse specifications with more on the way. I'm sure each of our projects have a number of internal developments which we're also interested in sharing. I'm guessing that some of our projects have already initiated their own track programs. Which I think is fine. I don't think it's a conflict to have technology specific tracks. However, if you're interested in joining forces, let me know. I think it would help foster greater interactions between our projects and also result in a very interesting conference track. To help to start aggregating potential presentations, I've created a Wiki page -- http://cwiki.apache.org/confluence/display/GMOxPMGT/ApacheCon+NA+2010+--+Enterprise+Java+Track At this point, we do not need to identify specific presentations. But we do need to insure that there is sufficient interest. If I've left out any projects who you think might be interested in participating, please feel free to pass this along... --kevan On Mar 15, 2010, at 7:22 PM, Nóirín Shirley for the ApacheCon 2010 Planning Team wrote: Dear PMC, ApacheCon 2010 North America is just around the corner, and it's time to roll out a program for this event! We'll be at the Westin Peachtree Plaza in Atlanta, GA, from 1st-5th November. Will you be there? If you'd like your project to be featured in the main conference tracks, please discuss it with your project community. A schedule is not needed at this time, but you have a coherent vision for a one day (6 sessions) program. We are particularly interested in programs that fit current themes, from Servers to Cloud Computing, from Search to NoSQL, as well as Innovation and Emerging Technologies. You'll also need to identify a track program organizer, who will be responsible for liaising with the planners, as well as collecting the session descriptions, speaker bios, and other programming information. Your track organizer should email planners-2010...@apachecon.com with your project's intent to participate, before Sunday, March 21st. Projects will be notified by the end of March as to whether their proposal has been accepted, and full programming should be completed by April 16th. Note that the planning committee will review the proposed tracks, and may offer feedback or specify necessary changes to ensure the success of the event. All accepted speakers (not co-presenters) qualify for general conference admission and a minimum of two nights lodging at the conference hotel. Additional hotel nights and travel assistance are possible, depending on the number of presentations given and type of assistance needed. If you think main track programming isn't for you, don't worry! You should expect to hear from us shortly about opportunities to present Training Sessions, as well as evening Meetups and other events. Looking forward to seeing you in Atlanta! Your ApacheCon 2010 NA Planning Team - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org
Re: {DISCUSS} Remove Spnego Support from Geronimo 2.1.5?
On Mar 22, 2010, at 10:34 PM, Rex Wang wrote: Will Tomcat community plan to apply our fixes to their code base soon? If not, because this Friday we will ship release candidate build of G 2.1.5, I prefer to remove Spnego support this time. The related JIRAs that need to revert are: GERONIMO - 5128 GERONIMO - 5129 Thoughts? I think that's reasonable. I'd rather not start adding additional function that hasn't also been applied to Tomcat. So, unless the patch is accepted soon, I'd be in favor of reverting the updates. --kevan
Re: Issue deploying apache-servicemix-3.2.3 on geronimo server
On Mar 19, 2010, at 12:46 AM, Nandeesh wrote: I am trying deploy servicemix JBI componet servicemix-web-3.2.3.war file on geronimo version geronimo-jetty6-javaee5-2.1.4 but getting following exception HttpManagedServlet - java.lang.NoClassDefFoundError: org/apache/commons/pool/ObjectPoolFactory but i have common-pool in my war file. Looks like class loading issue, can someone there help to resolve this issue? Jacek suggest you send your request to u...@geronimo, not d...@geronimo. u...@geronimo would have been a more appropriate list for your question. I downloaded servicemix-web-3.2.3.war and deployed successfully with the following deployment plan: ?xml version=1.0 encoding=UTF-8? web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.1; dep:environment dep:moduleId dep:groupIdorg.mygroup/dep:groupId dep:artifactIdMyApp/dep:artifactId dep:version1.1/dep:version dep:typecar/dep:type /dep:moduleId !-- Don't load spring classes or resources from parent ClassLoaders. -- dep:hidden-classes dep:filterorg.springframework./dep:filter dep:filterMETA-INF/spring/dep:filter /dep:hidden-classes /dep:environment /web-app --kevan
Re: [VOTE] Release txmanager-2.1.4 - RC1
+1 Source and build all look good. --kevan On Mar 3, 2010, at 4:23 AM, Rex Wang wrote: To support the upcoming Geronimo 2.1.5 release,I would like to release txmanager-2.1.4. However, we need a full TCK against it. Staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-002/ Source tag: https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.4/ Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, -- Lei Wang (Rex) rwonly AT apache.org
[jira] Created: (GERONIMO-5191) G 2.1.5 startup console log messages are being generated
G 2.1.5 startup console log messages are being generated - Key: GERONIMO-5191 URL: https://issues.apache.org/jira/browse/GERONIMO-5191 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.5 Reporter: Kevan Miller Fix For: 2.1.5 I'm seeing a lot of log messages during startup of a G 2.1.5-SNAPSHOT tomcat java ee server, that I didn't see in 2.1.4. They should be cleaned up... INFO: Set JAAS app name Geronimo Mar 17, 2010 4:18:26 PM org.apache.catalina.startup.Embedded start INFO: Starting tomcat server Mar 17, 2010 4:18:26 PM org.apache.catalina.startup.Embedded initNaming INFO: Catalina naming disabled Mar 17, 2010 4:18:27 PM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: :/Applications/YourKit Java Profiler 6.0.12.app/bin/mac:.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java [*** ] 38% 28s Starting org.apache.ger...Mar 17, 2010 4:18:27 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Geronimo (Embedded Tomcat/@VERSION@) Mar 17, 2010 4:18:27 PM org.apache.catalina.realm.RealmBase start INFO: This Realm has already been started [*** ] 38% 29s Starting org.apache.ger...Mar 17, 2010 4:18:27 PM org.apache.catalina.core.DefaultInstanceManager init SEVERE: Restricted listeners property file not found [*** ] 38% 29s Starting org.apache.ger...Mar 17, 2010 4:18:28 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-0.0.0.0-8080 Mar 17, 2010 4:18:28 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-0.0.0.0-8080 Mar 17, 2010 4:18:28 PM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 [*** ] 38% 30s Starting org.apache.ger...Mar 17, 2010 4:18:28 PM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/129 config=null Mar 17, 2010 4:18:28 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-0.0.0.0-8443 Mar 17, 2010 4:18:28 PM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-0.0.0.0-8443 [** ] 77% 38s Loading org.apache.ger...Mar 17, 2010 4:18:36 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [** ] 77% 38s Starting org.apache.ger...Mar 17, 2010 4:18:37 PM org.apache.catalina.core.ApplicationContext log INFO: Initializing Spring root WebApplicationContext [** ] 77% 39s Starting org.apache.ger...Mar 17, 2010 4:18:38 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [*** ] 78% 41s Starting org.apache.ger...Mar 17, 2010 4:18:39 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [] 81% 42s Loading org.apache.ger...Mar 17, 2010 4:18:40 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [* ] 83% 43s Starting org.apache.ger...Mar 17, 2010 4:18:41 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [* ] 84% 43s Loading org.apache.ger...Mar 17, 2010 4:18:41 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [** ] 85% 43s Loading org.apache.ger...Mar 17, 2010 4:18:42 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [** ] 87% 44s Starting org.apache.ger...Mar 17, 2010 4:18:42 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [*** ] 99% 49s Loading org.apache.ger...Mar 17, 2010 4:18:48 PM org.apache.catalina.realm.JAASRealm setUseContextClassLoader INFO: Setting useContextClassLoader = false [] 100% 52s Startup complete -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5185) Getting error as ERROR [DirectoryMonitor] Unable to scan file. It seems deployed was files are automatically deleted from default/reposotry directory
[ https://issues.apache.org/jira/browse/GERONIMO-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846023#action_12846023 ] Kevan Miller commented on GERONIMO-5185: Hmm. Are you sure the original hot-deploy was successful? Sounds like the original deploy failed... Does sound like there is a problem causing the NullPointerException (failure to clean up properly after a deploy error, perhaps?). Is this reproducible? If you have a test app, somebody could test... Getting error as ERROR [DirectoryMonitor] Unable to scan file. It seems deployed was files are automatically deleted from default/reposotry directory --- Key: GERONIMO-5185 URL: https://issues.apache.org/jira/browse/GERONIMO-5185 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.4 Environment: Suse Linux 10 Reporter: Prem Prakash Priority: Blocker Currently we have observed that restarting the gernimo server fails with the beolwo error ERROR [DirectoryMonitor] Unable to scan file java.lang.NullPointerException at org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeploymentTime(DirectoryHotDeployer.java:237) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(DirectoryMonitor.java:240) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:213) at java.lang.Thread.run(Thread.java:735) After inveatigation it seesms that the war file is removed form the /repsotiry/default directory . I am sure we never removed the war files from the respective directory . Is it known issue of gernimo ? Kindly assist -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tx manager component versions
On Mar 16, 2010, at 6:05 PM, David Jencks wrote: I'm thinking of porting the work to deal with retrying stuff that didnt work (GERONIMO-5152) in the tx manager component from trunk back to the 2.1 branch. However, this changes the interaction between the connection management and the tx manager quite a bit -- the tx manager can now request an XAResource from the connection management rather than just getting handed one when a pool starts up. So, I'm wondering what appropriate versions would be. I think that continuing 2.1.x is inappropriate for this size change. I think this would be an osgi major version bump. So at least it should go to 2.2... and trunk to 3.0 Another possibility would be 2.1 3.0 and trunk 4.0 which is more consistent with osgi versions. thoughts? Would be great to have these updates available for G 2.1.x and G 2.2.x servers! Personally, I think moving the tx-manager branch to 2.2 and tx-manager trunk to 3.0 would be just fine. I don't think the OSGi version scheme has much bearing for consumers of 2.1 and the new 2.2. 3.0 gives you a major version bump where you most need it -- where you have the most OSGi consumers and where the spec version bumps. I won't have a strong objection to moving branch to 3.0, if that's what is decided. Just strikes me as slightly confusing... --kevan
[jira] Created: (GERONIMO-5182) Fix compile errors caused by Jetty 8.0.0.M0 release
Fix compile errors caused by Jetty 8.0.0.M0 release --- Key: GERONIMO-5182 URL: https://issues.apache.org/jira/browse/GERONIMO-5182 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Fix For: 3.0 There are multiple updates in the latest Jetty 8.0.0.M0 release which are breaking the build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-5182) Fix compile errors caused by Jetty 8.0.0.M0 release
[ https://issues.apache.org/jira/browse/GERONIMO-5182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-5182: -- Assignee: Kevan Miller Fix compile errors caused by Jetty 8.0.0.M0 release --- Key: GERONIMO-5182 URL: https://issues.apache.org/jira/browse/GERONIMO-5182 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 3.0 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 3.0 There are multiple updates in the latest Jetty 8.0.0.M0 release which are breaking the build -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: time to use maven 2.2.1 for G2.1.5 daily build
On Mar 11, 2010, at 3:54 AM, Rex Wang wrote: Hi Jarek, Could you help update the scripts? I'm curious why? --kevan
Re: time to use maven 2.2.1 for G2.1.5 daily build
On Mar 11, 2010, at 3:54 AM, Rex Wang wrote: Hi Jarek, Could you help update the scripts? Read more of my mail... ;-) So, I assume *why* is because of the move to Genesis 2.0. So, brings up a new question... ;-) Why update G 2.1 to use Genesis 2.0? --kevan
[jira] Closed: (GERONIMO-4959) Remote Deploy Broken on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4959. -- Resolution: Invalid I can only assume I had a configuration problem. For remote deploy to work, you have to have the server's ip address/hostname correct in 3 places: 1) deploy command: e.g. deploy.sh -host x.x.x.x 2) RemoteDeployHostname in config-substitutions.properties 3) ServerHostname in config-substitutions.properties Why require RemoteDeployHostname, when the client had to specify host/ip address, already? And more significantly, IMO, we should not require a specific ip address on ServerHostname. The default value of ServerHostname=0.0.0.0 should work for remote deploy... Something to handle in a separate JIRA. Should target improvements like this for 3.0... Remote Deploy Broken on Jetty - Key: GERONIMO-4959 URL: https://issues.apache.org/jira/browse/GERONIMO-4959 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1.4 Reporter: Kevan Miller Assignee: Forrest Xia Fix For: 2.1.5 I tried to use remote deploy, yesterday. After configuring RemoteDeployHostname, it didn't work. I poked around a bit more. Looks like remote deploy is broken on geronimo-jetty6 but working on geronimo-tomcat6. Should test this on 2.2, also -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: time to use maven 2.2.1 for G2.1.5 daily build
On Mar 11, 2010, at 9:36 PM, Rex Wang wrote: Yes, as Forrest said, I want to move to use maven-release-plugin to help the 2.1.5 release. Please check: http://cwiki.apache.org/GMOxPMGT/geronimo-release-process.html I'm familiar with the release process. As the 2.1 branch predated this process, IMO, it's not absolutely necessary to follow this process for 2.1.5. The real point of my questions are to encourage discussion of *why* you are doing something. That wasn't happening. --kevan
Re: svn commit: r921247 [1/11] - in /geronimo/devtools/eclipse-plugin/trunk: ./ features/org.apache.geronimo.v30.feature/ plugins/org.apache.geronimo.runtime.v30/ plugins/org.apache.geronimo.runtime.v
On Mar 10, 2010, at 3:31 AM, de...@apache.org wrote: Author: delos Date: Wed Mar 10 08:31:28 2010 New Revision: 921247 URL: http://svn.apache.org/viewvc?rev=921247view=rev Log: make trunk build successfully with v30 adapter integration Added: geronimo/devtools/eclipse-plugin/trunk/features/org.apache.geronimo.v30.feature/PLUGIN_RELEASE-NOTES-3.0.0.txt (with props) geronimo/devtools/eclipse-plugin/trunk/plugins/org.apache.geronimo.runtime.v30/ ... Sure are a lot of new files (which are really old files, I think). Delos, You should use svn copy to do this i think. svn copy will preserve svn history. So, there's a better record of changes that have occurred. --kevan
[jira] Commented: (GERONIMO-4959) Remote Deploy Broken on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12844344#action_12844344 ] Kevan Miller commented on GERONIMO-4959: Must be dependent upon network/os environment then. Was definitely required for my testing (btw same for tomcat and jetty). Environment: client = mac os server = ubuntu server running in parallels virtual machine Remote Deploy Broken on Jetty - Key: GERONIMO-4959 URL: https://issues.apache.org/jira/browse/GERONIMO-4959 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1.4 Reporter: Kevan Miller Assignee: Forrest Xia Fix For: 2.1.5 I tried to use remote deploy, yesterday. After configuring RemoteDeployHostname, it didn't work. I poked around a bit more. Looks like remote deploy is broken on geronimo-jetty6 but working on geronimo-tomcat6. Should test this on 2.2, also -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OpenEJB 3.0.2 release plan...
On Mar 9, 2010, at 2:54 AM, Rex Wang wrote: Hi, David Blevins, Since openejb 3.0.2 is a dependency to G 2.1.5, and I don't find any work related with this in openejb mailing list, could you please tell us the exact time when it will be released? Hi Rex, It's best to communicate this with the OpenEJB community on their mailing list and request that they generate a 3.0.2 release. Geronimo would like to create a release which includes OpenEJB 3.0.2. Could the OpenEJB community create a release? --kevan
[jira] Commented: (GERONIMO-5175) Geronimo 2.2 won't start java.lang.NoClassDefFoundError: Could not initialize class org.apache.geronimo.system.configuration.AttributesXmlUtil
[ https://issues.apache.org/jira/browse/GERONIMO-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843188#action_12843188 ] Kevan Miller commented on GERONIMO-5175: Upgrading your JDK level is a good idea. I doubt that there's been much testing of Geronimo on Windows Vista Home. I'd suspect: * permissions problems for the Geronimo install - IIRC Vista can be picky about this. I seem to recall some Vista related issues posted on dev or user list a while back. Don't recall any resolution. * JAVA_HOME/JRE_HOME settings. Are you explicitly setting either of these environment variables? Or is the .bat file calculating a default? Geronimo 2.2 won't start java.lang.NoClassDefFoundError: Could not initialize class org.apache.geronimo.system.configuration.AttributesXmlUtil -- Key: GERONIMO-5175 URL: https://issues.apache.org/jira/browse/GERONIMO-5175 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.2 Environment: Windows Vista Home geronimo-tomcat6-javaee5-2.2-bin.zip Reporter: Jan Stobbe Fix For: 2.2 Can't startup 2010-03-08 21:12:12,124 INFO [Log4jService] -- 2010-03-08 21:12:12,124 INFO [Log4jService] Started Logging Service 2010-03-08 21:12:12,124 INFO [Log4jService] Runtime Information: 2010-03-08 21:12:12,124 INFO [Log4jService] Install Directory = C:\geronimo-tomcat6-javaee5-2.2 2010-03-08 21:12:12,124 INFO [JvmVendor] Sun JVM 1.6.0_02 2010-03-08 21:12:12,124 INFO [Log4jService] JVM in use= Sun JVM 1.6.0_02 2010-03-08 21:12:12,124 INFO [Log4jService] Java Information: 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.runtime.name] = Java(TM) SE Runtime Environment 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.runtime.version] = 1.6.0_02-b06 2010-03-08 21:12:12,124 INFO [Log4jService] System property [os.name] = Windows Vista 2010-03-08 21:12:12,124 INFO [Log4jService] System property [os.version] = 6.0 2010-03-08 21:12:12,124 INFO [Log4jService] System property [sun.os.patch.level]= Service Pack 2 2010-03-08 21:12:12,124 INFO [Log4jService] System property [os.arch] = x86 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.class.version]= 50.0 2010-03-08 21:12:12,124 INFO [Log4jService] System property [locale] = en_US 2010-03-08 21:12:12,124 INFO [Log4jService] System property [unicode.encoding] = UnicodeLittle 2010-03-08 21:12:12,124 INFO [Log4jService] System property [file.encoding] = Cp1252 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.vm.name] = Java HotSpot(TM) Client VM 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.vm.vendor]= Sun Microsystems Inc. 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.vm.version] = 1.6.0_02-b06 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.vm.info] = mixed mode 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.home] = c:\Progra~1\java\jre1.6.0_02 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.classpath]= null 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.library.path] = c:\Progra~1\java\jre1.6.0_02\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\CyberLink\Power2Go\;C:\Program Files\jZip;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\cvsnt; 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.endorsed.dirs]= C:\geronimo-tomcat6-javaee5-2.2\lib\endorsed;c:\Progra~1\java\jre1.6.0_02\lib\endorsed 2010-03-08 21:12:12,124 INFO [Log4jService] System property [java.ext.dirs] = C:\geronimo-tomcat6-javaee5-2.2\lib\ext;c:\Progra~1\java\jre1.6.0_02\lib\ext 2010-03-08 21:12:12,124 INFO [Log4jService] System property [sun.boot.class.path] = C:\geronimo-tomcat6-javaee5-2.2\lib\endorsed\yoko-rmi-spec-1.0.jar;C:\geronimo-tomcat6-javaee5-2.2\lib\endorsed\yoko-spec-corba-1.0.jar;c:\Progra~1\java\jre1.6.0_02\lib\resources.jar;c:\Progra~1\java\jre1.6.0_02\lib\rt.jar;c:\Progra~1\java\jre1.6.0_02\lib\sunrsasign.jar;c:\Progra~1\java\jre1.6.0_02\lib\jsse.jar;c:\Progra~1\java\jre1.6.0_02\lib\jce.jar;c:\Progra~1\java\jre1.6.0_02\lib\charsets.jar;c:\Progra~1\java\jre1.6.0_02\classes 2010-03-08 21:12:12,124 INFO
Re: svn commit: r921195 - in /geronimo/server/trunk: framework/ framework/configs/client-system/src/main/history/ framework/configs/j2ee-system/src/main/history/ framework/configs/jsr88-cli/src/main/h
On Mar 9, 2010, at 7:40 PM, djen...@apache.org wrote: Author: djencks Date: Wed Mar 10 00:40:46 2010 New Revision: 921195 URL: http://svn.apache.org/viewvc?rev=921195view=rev Log: don't include junit in our server snip Modified: geronimo/server/trunk/framework/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/framework/pom.xml?rev=921195r1=921194r2=921195view=diff == --- geronimo/server/trunk/framework/pom.xml (original) +++ geronimo/server/trunk/framework/pom.xml Wed Mar 10 00:40:46 2010 @@ -39,7 +39,7 @@ dependency groupIdorg.eclipse/groupId artifactIdosgi/artifactId -version3.5.0.v20090520/version +version3.5.1.v20090827/version /dependency dependency I'm getting an unresolved dependency for 3.5.1.v20090827 and had to revert back to the previous value. Where are you finding 3.5.1...? --kevan
Re: Welcome Forrest Ming Xia as a new committer
Congrats Forrest! --kevan On Mar 8, 2010, at 8:54 PM, Ivan wrote: I would like to welcome Forrest aboard, as he recently accepted the Geronimo PMC invitation to become a committer. His account (xiaming) was just created, so you should start seeing some commits from him soon. -- Ivan
Re: [DISCUSSION] Release GEP more frequently
On Mar 3, 2010, at 12:58 AM, Delos wrote: Hi all, Johannes suggested that GEP make release more frequently. The reason is user may get new fixes earlier, instead of waiting for next release together with Geronimo server. In this way, it will be more convenient for GEP to provide new improvement, such as support for eclipse of latest version. To support it, the version number of GEP has to be redesigned. We need to add qualifier segment to the version number, such as 2.2.0.0, 2.2.0.1 and 2.2.0.2. Then, for each release of Geronimo server, GEP version will contains server version number as prefix and qualifier segment as 0. For GEP release in future, the qualifier of its version number will increase by 1 until server announce a new release. For example, for Geronimo server 2.2.0, GEP version will be 2.2.0.0; if GEP has to announce a new release after that, its version will be 2.2.0.1. In general, GEP version will evolve as below 1) Version number of GEP will contain four digitals 2) If there is a G server release, GEP will announce a new release for it. GEP version number is three digitals of server version number suffixed with .0 3) GEP may have several maintenance releases. Only last digital increase by 1 for maintenance releases version number. Johannes, please correct me, if there is any mistake in my description. Could you express your attitude toward Johannes' suggestion? Hi Delos, More frequent releases would certainly be a good thing. I don't see how anybody would object to that. Maybe I don't understand the issue (e.g. interdependencies between GEP and G). However, to my knowledge, there's nothing that requires GEP version numbers to stay exactly in sync with Geronimo server releases. So, I'm not sure why 4 version numbers are a *hard* requirement. So, GEP 2.2.x would indicate that it was built for a G 2.2.y server. You just wouldn't know how 'x' compares to 'y'. But a simple practice would be to get the latest GEP 2.2.x release. I will note that this proposal doesn't work too well for users of previous versions of the Geronimo server. What versions of G 2.1.x would a GEP 2.2.y.z correspond to? Or are you suggesting that G 2.1 users should use a GEP 2.1.x adapter? That said, if you, other GEP devs, and especially GEP users would find this version scheme useful, then it sounds good to me. --kevan
Re: [VOTE] Release txmanager-2.1.4 - RC1
On Mar 3, 2010, at 4:54 AM, Jack Cai wrote: My point is that you should run TCK first and show results first before any voting... We often run TCK concurrent with a vote. So, it's not an issue, IMO. The vote passing can be contingent on TCK looking good. A note about TCK runs for components. We are not certifying that our components are *compliant*. At present, we only certify that a Server release is compliant. Running the TCK allows us to prevent introducing problematic component releases for public consumption. Running the TCK allows us to feel comfortable with the validity of the components. So, end result is TCK did not identify any problems. Not until we generate a Server release are we compliant with the EE spec. --kevan
