[jira] Closed: (GERONIMO-2978) ClientCommandLine and Daemon improvement to reduce reliance on lib/
[ https://issues.apache.org/jira/browse/GERONIMO-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2978. --- Resolution: Fixed Fix Version/s: 2.0-beta1 This is now implemented. ClientCommandLine and Daemon improvement to reduce reliance on lib/ --- Key: GERONIMO-2978 URL: https://issues.apache.org/jira/browse/GERONIMO-2978 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.0-M3 Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-beta1 ClientCommandLine and Daemon can be improved to leverage the MainBootstrapper boot approach in order to reduce reliance on lib/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: activemq modules in trunk still using org.apache.activemq for package
On Mar 17, 2007, at 4:09 AM, Jason Dillon wrote: I think its high time this was changed to org.apache.geronimo.activemq. Any objections? Not from me... Sounds good. --kevan
Re: activemq modules in trunk still using org.apache.activemq for package
On Mar 18, 2007, at 8:01 AM, Kevan Miller wrote: On Mar 17, 2007, at 4:09 AM, Jason Dillon wrote: I think its high time this was changed to org.apache.geronimo.activemq. Any objections? Not from me... Sounds good. --kevan
What is a plugin? geronimo or maven?
It looks to me as if we are well on our way to use the groupId of org.apache.geronimo.plugins for both maven plugins and geronimo plugins. This might not be the wisest thing we ever did. What if we changed the maven plugins to use org.apache.geronimo.maven? Aside from massive backwards compatibility problems :-) this seems to me as if it might be the most appropriate naming change. thanks david jencks
Is geronimo plugin support broken?
I was trying to get my local repo to act as a plugin repository last night and got this exception when I tried to use the command line install-plugin command, which makes me wonder if we broke plugin support? This is with g. trunk. $ java -jar bin/deployer.jar install-plugin ~/.m2/repository/org/ apache/geronimo/plugins/roller-derby-database/2.0-SNAPSHOT/roller- derby-database-2.0-SNAPSHOT.car Exception in thread main java.lang.NullPointerException at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDep loyerName(AbstractDeployCommand.java:65) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init (AbstractDeployCommand.java:61) at org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager $1.init(RemoteDeploymentManager.java:208) at org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager.startI nstall(RemoteDeploymentManager.java:207) at org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager$ $FastClassByCGLIB$$f35307f7.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke (KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$ $1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke (MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke (DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke (MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke (DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke (JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl $PrivilegedOperation.run(RMIConnectionImpl.java:1245) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (RMIConnectionImpl.java:1348) at javax.management.remote.rmi.RMIConnectionImpl.invoke (RMIConnectionImpl.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (TCPTransport.java:707) at java.lang.Thread.run(Thread.java:613) thanks david jencks
[jira] Created: (GERONIMO-2979) More improvements to the Geronimo Axis2 Integration
More improvements to the Geronimo Axis2 Integration --- Key: GERONIMO-2979 URL: https://issues.apache.org/jira/browse/GERONIMO-2979 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: webservices Reporter: Lasantha Ranaweera This patch will improve the existing coding of the Geronimo Axis2 integration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2952) Add more test cases to Axis2 JAXWS integration
[ https://issues.apache.org/jira/browse/GERONIMO-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lasantha Ranaweera closed GERONIMO-2952. Resolution: Duplicate GERONIMO-2979 will handle this issue. Add more test cases to Axis2 JAXWS integration --- Key: GERONIMO-2952 URL: https://issues.apache.org/jira/browse/GERONIMO-2952 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Reporter: Lasantha Ranaweera Attachments: GERONIMO-2952-1.patch, GERONIMO-2952.patch This patch will add more test scenarios to Axis2 JAXWS integration. Existing test cases has been renamed. The newly added WSDLs will be used to implement the WSDL existing scenario of the JAXWS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: What is a plugin? geronimo or maven?
This has always been confusing to me too. I like your suggestion. +1 Best wishes, Paul On 3/18/07, David Jencks [EMAIL PROTECTED] wrote: It looks to me as if we are well on our way to use the groupId of org.apache.geronimo.plugins for both maven plugins and geronimo plugins. This might not be the wisest thing we ever did. What if we changed the maven plugins to use org.apache.geronimo.maven? Aside from massive backwards compatibility problems :-) this seems to me as if it might be the most appropriate naming change. thanks david jencks
Re: Is geronimo plugin support broken?
I was able to install the welcome app as a plugin from my local repo using the admin console, but I was not able to install that same plugin using the CLI. So I think the problem might be specific to the CLI. Best wishes, Paul On 3/18/07, David Jencks [EMAIL PROTECTED] wrote: I was trying to get my local repo to act as a plugin repository last night and got this exception when I tried to use the command line install-plugin command, which makes me wonder if we broke plugin support? This is with g. trunk. $ java -jar bin/deployer.jar install-plugin ~/.m2/repository/org/ apache/geronimo/plugins/roller-derby-database/2.0-SNAPSHOT/roller- derby-database-2.0-SNAPSHOT.car Exception in thread main java.lang.NullPointerException at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDep loyerName(AbstractDeployCommand.java:65) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init (AbstractDeployCommand.java:61) at org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager $1.init(RemoteDeploymentManager.java:208) at org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager.startI nstall(RemoteDeploymentManager.java:207) at org.apache.geronimo.deployment.plugin.jmx.RemoteDeploymentManager$ $FastClassByCGLIB$$f35307f7.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke (KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$ $1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke (MBeanGBeanBridge.java:168) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke (DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke (MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke (DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke (JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation (RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100 (RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl $PrivilegedOperation.run(RMIConnectionImpl.java:1245) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation (RMIConnectionImpl.java:1348) at javax.management.remote.rmi.RMIConnectionImpl.invoke (RMIConnectionImpl.java:782) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (TCPTransport.java:707) at java.lang.Thread.run(Thread.java:613) thanks david jencks
Re: [HACKATHON] Raleigh, NC Monday 19 - Tuesday 20
Folks, Can folks post their TODO/Wish list for the hackathon? Personally here's what i am looking at. - Understand work already done in cxf integration and figure out what's missing to reach the same level of integration - Figure out what else needs to be done for both cxf and axis2 integration for feature completion - Review/understand some of the tck work already done so far (if any!) - Figure out how Lin and Lasantha can help between now and 2.0 final and how i can help them. - Figure out what is missing in Axis2. Since my primary objective is to make sure Axis2 1.2 has whatever is needed for G 2.0 final. Want to try avoiding cutting a Axis2 1.3 as much as possible. - Figure out what is needed in Axis 1.X specifically w.r.t SAAJ versions issue. We may need to cut Axis 1.5. - Work/code any high priority items needed ASAP Thanks, dims On 3/15/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Hrmmmnot in front of me...I'll find it before Monday :) On Mar 15, 2007, at 3:50 PM, Lin Sun wrote: Me too. Matt, do you want to tell us the room # for folks who don't want to meet you at the lobby?:-) Lin Jarek Gawor wrote: Me too. Jarek On 3/15/07, Joe Bohn [EMAIL PROTECTED] wrote: I'll be there. Joe Matt Hogstrom wrote: Dims said he'll be in the Raleigh area and since a lot of other committers area it would be good to get folks that are around together. For those that are interested in joining I have a room that we can use from 0900 - 1800 on Monday and Tuesday. The address is: 4205 South Miami Blvd Durham, NC 27703 Come to the lobby and ask for me and I'll be happy to let you in. I've got a conference room for about 10 people for both days with network connectivity and the like. Anyone in the area that is interested to come and hang out for the day or just a few hours is welcome. I expect folks will be on IRC and use the dev list for communication just like any informal get together. If anyone is interested I could probably open up a call in number if folks want to listen to each other type or otherwise interact. If folks are interested in that, contact me directly for call in information as that wouldn't be appropriate to post a passcode publicly. If there are folks that are interested I'll do my best to make that happen. The times are Eastern. Respond to this e-mail if your planing on showing up. I'll be there :) -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: What is a plugin? geronimo or maven?
Sounds good to me and 2.0 is a great time for it. -Donald David Jencks wrote: It looks to me as if we are well on our way to use the groupId of org.apache.geronimo.plugins for both maven plugins and geronimo plugins. This might not be the wisest thing we ever did. What if we changed the maven plugins to use org.apache.geronimo.maven? Aside from massive backwards compatibility problems :-) this seems to me as if it might be the most appropriate naming change. thanks david jencks smime.p7s Description: S/MIME Cryptographic Signature
Re: What is a plugin? geronimo or maven?
The maven plugins should be changed to org.apache.geronimo.mavenplugins IMO, been on my list... just never happened. --jason On Mar 18, 2007, at 8:52 AM, David Jencks wrote: It looks to me as if we are well on our way to use the groupId of org.apache.geronimo.plugins for both maven plugins and geronimo plugins. This might not be the wisest thing we ever did. What if we changed the maven plugins to use org.apache.geronimo.maven? Aside from massive backwards compatibility problems :-) this seems to me as if it might be the most appropriate naming change. thanks david jencks
Re: What is a plugin? geronimo or maven?
+1 to change. either one is ok. -- dims On 3/18/07, Jason Dillon [EMAIL PROTECTED] wrote: The maven plugins should be changed to org.apache.geronimo.mavenplugins IMO, been on my list... just never happened. --jason On Mar 18, 2007, at 8:52 AM, David Jencks wrote: It looks to me as if we are well on our way to use the groupId of org.apache.geronimo.plugins for both maven plugins and geronimo plugins. This might not be the wisest thing we ever did. What if we changed the maven plugins to use org.apache.geronimo.maven? Aside from massive backwards compatibility problems :-) this seems to me as if it might be the most appropriate naming change. thanks david jencks -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: svn commit: r519684 - in /geronimo/server/trunk: configs/jasper/ configs/jsr88-deploymentfactory/ modules/geronimo-deploy-jsr88-bootstrapper/ modules/geronimo-jasper/ modules/geronimo-myfaces-buil
Ugh... more svn:ingore stuff... is it too much trouble to get people to update their ~/.subversion/config to add these ignores? I find it very useful at times to use `svn status` to find out what generated stuff is in a tree. I can do this very easily by turning off my local ignores, but when people keep adding svn:ignore properties to directories its almost impossible to use `svn status` for this purpose. I would really like to see local ignores being used, and for folks to stop leaning on the svn:ingore property so much for stuff they *personally* want to have ignored. --jason On Mar 18, 2007, at 1:22 PM, [EMAIL PROTECTED] wrote: Author: dims Date: Sun Mar 18 13:22:36 2007 New Revision: 519684 URL: http://svn.apache.org/viewvc?view=revrev=519684 Log: ignore target and *.iml files Modified: geronimo/server/trunk/configs/jasper/ (props changed) geronimo/server/trunk/configs/jsr88-deploymentfactory/ (props changed) geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ (props changed) geronimo/server/trunk/modules/geronimo-jasper/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces-builder/ (props changed) geronimo/server/trunk/repository/ (props changed) geronimo/server/trunk/testsupport/test-deployment-javaee_5/ (props changed) Propchange: geronimo/server/trunk/configs/jasper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/configs/jsr88-deploymentfactory/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-jasper/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces-builder/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/repository/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/testsupport/test-deployment- javaee_5/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1 @@ +*.iml
Re: svn commit: r519684 - in /geronimo/server/trunk: configs/jasper/ configs/jsr88-deploymentfactory/ modules/geronimo-deploy-jsr88-bootstrapper/ modules/geronimo-jasper/ modules/geronimo-myfaces-buil
I had no idea there was a possibility to have a local ignore configuration! This is great! What would you like to see in the svn:ignore? Nothing? target? ?? thanks david jencks On Mar 18, 2007, at 4:36 PM, Jason Dillon wrote: Ugh... more svn:ingore stuff... is it too much trouble to get people to update their ~/.subversion/config to add these ignores? I find it very useful at times to use `svn status` to find out what generated stuff is in a tree. I can do this very easily by turning off my local ignores, but when people keep adding svn:ignore properties to directories its almost impossible to use `svn status` for this purpose. I would really like to see local ignores being used, and for folks to stop leaning on the svn:ingore property so much for stuff they *personally* want to have ignored. --jason On Mar 18, 2007, at 1:22 PM, [EMAIL PROTECTED] wrote: Author: dims Date: Sun Mar 18 13:22:36 2007 New Revision: 519684 URL: http://svn.apache.org/viewvc?view=revrev=519684 Log: ignore target and *.iml files Modified: geronimo/server/trunk/configs/jasper/ (props changed) geronimo/server/trunk/configs/jsr88-deploymentfactory/ (props changed) geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ (props changed) geronimo/server/trunk/modules/geronimo-jasper/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces-builder/ (props changed) geronimo/server/trunk/repository/ (props changed) geronimo/server/trunk/testsupport/test-deployment-javaee_5/ (props changed) Propchange: geronimo/server/trunk/configs/jasper/ - - --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/configs/jsr88-deploymentfactory/ - - --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ - - --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-jasper/ - - --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces/ - - --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces-builder/ - - --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/repository/ - - --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/testsupport/test-deployment- javaee_5/ - - --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1 @@ +*.iml
Re: svn commit: r519684 - in /geronimo/server/trunk: configs/jasper/ configs/jsr88-deploymentfactory/ modules/geronimo-deploy-jsr88-bootstrapper/ modules/geronimo-jasper/ modules/geronimo-myfaces-buil
Personally, I would only like to see target in svn:ignore, since that is the one location that is expected to have generated stuff for m2 builds. Everything else, that I personally want to ignore I add in ~/.subversion/config in the [miscellany] section: global-ignores = *.log *.save *.o *.lo *.la #*# .*~ *~ .#* .DS_Store build dist target *.ipr *.iml *.iws .project .classpath .settings --jason On Mar 18, 2007, at 1:54 PM, David Jencks wrote: I had no idea there was a possibility to have a local ignore configuration! This is great! What would you like to see in the svn:ignore? Nothing? target? ?? thanks david jencks On Mar 18, 2007, at 4:36 PM, Jason Dillon wrote: Ugh... more svn:ingore stuff... is it too much trouble to get people to update their ~/.subversion/config to add these ignores? I find it very useful at times to use `svn status` to find out what generated stuff is in a tree. I can do this very easily by turning off my local ignores, but when people keep adding svn:ignore properties to directories its almost impossible to use `svn status` for this purpose. I would really like to see local ignores being used, and for folks to stop leaning on the svn:ingore property so much for stuff they *personally* want to have ignored. --jason On Mar 18, 2007, at 1:22 PM, [EMAIL PROTECTED] wrote: Author: dims Date: Sun Mar 18 13:22:36 2007 New Revision: 519684 URL: http://svn.apache.org/viewvc?view=revrev=519684 Log: ignore target and *.iml files Modified: geronimo/server/trunk/configs/jasper/ (props changed) geronimo/server/trunk/configs/jsr88-deploymentfactory/ (props changed) geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ (props changed) geronimo/server/trunk/modules/geronimo-jasper/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces-builder/ (props changed) geronimo/server/trunk/repository/ (props changed) geronimo/server/trunk/testsupport/test-deployment-javaee_5/ (props changed) Propchange: geronimo/server/trunk/configs/jasper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/configs/jsr88-deploymentfactory/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-jasper/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces-builder/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/repository/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/testsupport/test-deployment- javaee_5/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1 @@ +*.iml
[jira] Updated: (GERONIMO-2455) Upgrade to new MX4J service release
[ https://issues.apache.org/jira/browse/GERONIMO-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GERONIMO-2455: --- Fix Version/s: 1.2 Upgrade to new MX4J service release --- Key: GERONIMO-2455 URL: https://issues.apache.org/jira/browse/GERONIMO-2455 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1, 1.1.1, 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.1.2, 1.2 Attachments: mx4j-3.0.2-bundle.jar, mx4j-jmx-3.0.2-bundle.jar, mx4j-remote-3.0.2-bundle.jar, mx4j-tools-3.0.2-bundle.jar There's a timing hole in the mx4j Monitor implementation. In some scenarios, a Monitor will not receive an appropriate Notifcation after being started. The fix for the problem has been committed to mx4j head. I've run tests using a private build from mx4j head, all looks well. Once available, we should upgrade to the mx4j service release 3.0.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2455) Upgrade to new MX4J service release
[ https://issues.apache.org/jira/browse/GERONIMO-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481976 ] Jason Dillon commented on GERONIMO-2455: I've updated 1.2 to use 3.0.2... but 1.1 is still using m1 and these jars aren't in the m1 central repo. We could add the jars to the 1.1's repository module and then update the version of mx4j to 3.0.2 too... but are we ever going to release 1.1.2? The build for 1.1 is a *huge* mess... Upgrade to new MX4J service release --- Key: GERONIMO-2455 URL: https://issues.apache.org/jira/browse/GERONIMO-2455 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1, 1.1.1, 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.1.2, 1.2 Attachments: mx4j-3.0.2-bundle.jar, mx4j-jmx-3.0.2-bundle.jar, mx4j-remote-3.0.2-bundle.jar, mx4j-tools-3.0.2-bundle.jar There's a timing hole in the mx4j Monitor implementation. In some scenarios, a Monitor will not receive an appropriate Notifcation after being started. The fix for the problem has been committed to mx4j head. I've run tests using a private build from mx4j head, all looks well. Once available, we should upgrade to the mx4j service release 3.0.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
G 1.2 and IBM JDK (GERONIMO-433)
Can someone who has the IBM 1.5 JDK installed please try to compile and run G 1.2? Should be easy enough to verify that it works... if you have the JDK installed. Might take like 30 minutes tops to verify. Can someone please try this, and comment on this issue if it works/ doesn't work: https://issues.apache.org/jira/browse/GERONIMO-433 Thanks, --jason
Re: What is a plugin? geronimo or maven?
We may want to take this time to fix a few other groupId thingys too... We should change the base server/trunk groupId to: org.apache.geronimo.server And perhaps change the 'applications' groupId to simply 'apps'... anyways, we'd end up with ids like: testsupport/* org.apache.geronimo.server modules/* org.apache.geronimo.server configs/* org.apache.geronimo.server.configs applications/* org.apache.geronimo.server.apps maven-plugins/* org.apache.geronimo.server.mavenplugins assemblies/*org.apache.geronimo.server.assemblies testsuite/* org.apache.geronimo.server.testsuite If we want to use org.apache.geronimo.server.maven for our plugins, then I suggest we rename maven-plugins/* to maven/* to keep things consistent. And actually I would do the same for applications/ *, rename it to apps/*. I also think that we should still re-organize modules/* configs/* into groups based on the features they provide (like all activemq, jetty, tomcat, etc) and I would put the configuration modules in the same group dirs. For an example of that peep at the structure of the g1.1-activemq4 stuff I just added: https://svn.apache.org/repos/asf/geronimo/sandbox/g1.1-activemq4/ This is how I would recommend we eventually get our modules organized... into directories which contain all of the modules (and config modules) for a particular integration. This makes it much easier to work on a specific feature... can simply `cd feature; mvn` to build those modules. And, well.. if we keep along the same idea of structure reform, I think we should probably start to think about dropping those geronimo- prefixes that we have everywhere. I don't believe they are useful, and only eat up space in the filename length. The groupId should be sufficient to indicate these are Geronimo artifacts, we don't need to remind people by adding that to the artifact name too. Some of this might be more disruptive than we can handle for right now, especially while trying to get 2.0 out ASAP. I was hoping to delay most of the major reorganization surgery until 2.1. But I think a few of the groupId-based changes can be done for 2.0 soonish if we want. For the larger moving stuff around... I am going to use svk2 to setup a branch in the sandbox, pulling in new changes from trunk to keep it up to date. From what I've been told svk2 handles merges from source into target branches when the target branch has stuff moved around... and I want to make sure that works. If it does... well, then the whole restructuring will be trivial, we can keep working on trunk asis then once the new structure is happy, we can just switch over with very little merge overhead. --jason On Mar 18, 2007, at 1:23 PM, Davanum Srinivas wrote: +1 to change. either one is ok. -- dims On 3/18/07, Jason Dillon [EMAIL PROTECTED] wrote: The maven plugins should be changed to org.apache.geronimo.mavenplugins IMO, been on my list... just never happened. --jason On Mar 18, 2007, at 8:52 AM, David Jencks wrote: It looks to me as if we are well on our way to use the groupId of org.apache.geronimo.plugins for both maven plugins and geronimo plugins. This might not be the wisest thing we ever did. What if we changed the maven plugins to use org.apache.geronimo.maven? Aside from massive backwards compatibility problems :-) this seems to me as if it might be the most appropriate naming change. thanks david jencks -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Created: (GERONIMO-2980) Repackage org.apache.activemq.gbean.* into org.apache.geronimo.activemq.gbean.*
Repackage org.apache.activemq.gbean.* into org.apache.geronimo.activemq.gbean.*
---
Key: GERONIMO-2980
URL: https://issues.apache.org/jira/browse/GERONIMO-2980
Project: Geronimo
Issue Type: Improvement
Security Level: public (Regular issues)
Components: ActiveMQ
Affects Versions: 2.0
Reporter: Jason Dillon
Assigned To: Jason Dillon
Currently the ActiveMQ integration components use the package
{{org.apache.activemq.gbean}}. These are classes _in_ the Geronimo project and
should be in the {{org.apache.geronimo.activemq}} package.
This affects these modules:
* geronimo-activemq-gbean-management
* geronimo-activemq-gbean
* activemq-broker (config)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: activemq modules in trunk still using org.apache.activemq for package
Somewhat related, I think we should rename the modules: configs/activemq - configs/activemq-ra modules/geronimo-activemq-gbean - modules/geronimo-activemq modules/geronimo-activemq-gbean-management - modules/geronimo- activemq-management I always get confused about the configs/activemq... its really the resource adapter configuration. And IMO its irrelevant to have 'gbean' in our module names. --jason On Mar 18, 2007, at 5:01 AM, Kevan Miller wrote: On Mar 17, 2007, at 4:09 AM, Jason Dillon wrote: I think its high time this was changed to org.apache.geronimo.activemq. Any objections? Not from me... Sounds good. --kevan
[jira] Updated: (GERONIMO-2980) Repackage org.apache.activemq.gbean.* into org.apache.geronimo.activemq.*
[
https://issues.apache.org/jira/browse/GERONIMO-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated GERONIMO-2980:
---
Summary: Repackage org.apache.activemq.gbean.* into
org.apache.geronimo.activemq.* (was: Repackage org.apache.activemq.gbean.*
into org.apache.geronimo.activemq.gbean.*)
Really don't need to have that extra gbean package.
Repackage org.apache.activemq.gbean.* into org.apache.geronimo.activemq.*
-
Key: GERONIMO-2980
URL: https://issues.apache.org/jira/browse/GERONIMO-2980
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.0
Reporter: Jason Dillon
Assigned To: Jason Dillon
Currently the ActiveMQ integration components use the package
{{org.apache.activemq.gbean}}. These are classes _in_ the Geronimo project
and should be in the {{org.apache.geronimo.activemq}} package.
This affects these modules:
* geronimo-activemq-gbean-management
* geronimo-activemq-gbean
* activemq-broker (config)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2980) Repackage org.apache.activemq.gbean.* into org.apache.geronimo.activemq.*
[
https://issues.apache.org/jira/browse/GERONIMO-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481985
]
Jason Dillon commented on GERONIMO-2980:
Should also renamed the activemq modules at this time too:
* configs/activemq - configs/activemq-ra
* modules/geronimo-activemq-gbean - modules/geronimo-activemq
* modules/geronimo-activemq-gbean-management -
modules/geronimo-activemq-management
I always get confused about the configs/activemq... its really the resource
adapter configuration. And IMO its irrelevant to have 'gbean' in our module
names.
Repackage org.apache.activemq.gbean.* into org.apache.geronimo.activemq.*
-
Key: GERONIMO-2980
URL: https://issues.apache.org/jira/browse/GERONIMO-2980
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.0
Reporter: Jason Dillon
Assigned To: Jason Dillon
Currently the ActiveMQ integration components use the package
{{org.apache.activemq.gbean}}. These are classes _in_ the Geronimo project
and should be in the {{org.apache.geronimo.activemq}} package.
This affects these modules:
* geronimo-activemq-gbean-management
* geronimo-activemq-gbean
* activemq-broker (config)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Fwd: Websphere 6.1 and MBean registration issue
Hi I have done some but not a lot of work on this. (I have spent the last week sick :( ) I agree that it would be better to avoid the use of queryname if posible. I will have more of a detailed look tomorrow and get back to you. David Grant M wrote: Hey David, I was wondering if you already had a workable solution for the MBean registration issue? I was thinking instead of putting the code in the AsyncBaseLifecycle it should instead go in the base MBean code. I'll raise a JIRA issue and we can continue discussion of it. Grant -- Forwarded message -- From: Guillaume Nodet [EMAIL PROTECTED] Date: Mar 17, 2007 9:40 AM Subject: Re: Websphere 6.1 and MBean registration issue To: servicemix-dev@geronimo.apache.org On 3/16/07, Grant M [EMAIL PROTECTED] wrote: Hi, I've been out of touch for a while with swapping to a new job and all and I was wondering whether David Potter had forwarded a solution to the MBean registration issue in Websphere? If not I'd like to open the floor to discussions on a possible fix. I don't think so, but you should ping him and cc this list to see if he has worked on it already. I think the possible use of querynames could be fraught with issues especially in clustered environments. Would it be possible to change the base MBean itself so that upon registration it updated the objectName? That way changes would be propagated correctly? I noticed in the code there is references to property change listeners and was wondering whether this meant it was already implemented? Yeah, it should be possible to retrieve the new value of the Objectname and use it instead of the one ServiceMix generates. I think this is the only change to make, but i may miss something: where do you want to propagate the change ? Anyway, property change listeners should generate jmx notifications, provided that the setter call the needed method of course. Cheers, Grant M -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/ -- View this message in context: http://www.nabble.com/Websphere-6.1-and-MBean-registration-issue-tf3417186s12049.html#a9544352 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
DeadProxyException when shutdown from console (jetty)
Anyone know why DeadProxyException are getting tosses like they are going out of style when using the console to shutdown the server in Jetty? I've snipped out most of them... but there are a ton that are thrown. Insane call depth too... This appears to be something with the Jetty integration, shutdown with tomcat via the console doesn't puke up anything. Though, both spit this out [] received stop signal which is kinda odd. snip Booting Geronimo Kernel (in Java 1.5.0_07)... ... Geronimo Application Server started [] received stop signal 16:41:45,014 ERROR [log] EXCEPTION org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:87) at org.apache.geronimo.management.geronimo.WebModule$$EnhancerByCGLIB $$90fecc6f.destroyInstance(generated) at org.apache.geronimo.jetty6.InternalJettyServletHolder.destroyInstance (InternalJettyServletHolder.java:93) at org.mortbay.jetty.servlet.ServletHolder.doStop(ServletHolder.java: 294) at org.apache.geronimo.jetty6.InternalJettyServletHolder.internalDoStop (InternalJettyServletHolder.java:129) at org.apache.geronimo.jetty6.InternalJettyServletHolder.access$100 (InternalJettyServletHolder.java:47) at org.apache.geronimo.jetty6.InternalJettyServletHolder $StopCommand.lifecycleMethod(InternalJettyServletHolder.java:142) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCom mand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleCom mand(ThreadClassloaderHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCom mand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleComm and(ComponentContextHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCom mand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleComma nd(InstanceContextHandler.java:81) at org.apache.geronimo.jetty6.InternalJettyServletHolder.doStop (InternalJettyServletHolder.java:118) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.servlet.ServletHandler.doStop (ServletHandler.java:174) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.handler.HandlerWrapper.doStop (HandlerWrapper.java:129) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.handler.HandlerWrapper.doStop (HandlerWrapper.java:129) at org.mortbay.jetty.servlet.SessionHandler.doStop (SessionHandler.java:124) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop (AbstractImmutableHandler.java:40) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop (AbstractImmutableHandler.java:40) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop (AbstractImmutableHandler.java:40) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.handler.HandlerWrapper.doStop (HandlerWrapper.java:129) at org.mortbay.jetty.handler.ContextHandler.doStop (ContextHandler.java:559) at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java: 482) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.JettyWebAppContext $StopCommand.lifecycleMethod(JettyWebAppContext.java:386) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCom mand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleCom mand(ThreadClassloaderHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCom mand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleComm and(ComponentContextHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCom mand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleComma nd(InstanceContextHandler.java:81) at org.apache.geronimo.jetty6.JettyWebAppContext.doStop (JettyWebAppContext.java:353) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance (GBeanInstance.java:1149) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop (GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop (GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop
[jira] Created: (GERONIMO-2981) DeadProxyException when shutdown from console (jetty)
DeadProxyException when shutdown from console (jetty)
-
Key: GERONIMO-2981
URL: https://issues.apache.org/jira/browse/GERONIMO-2981
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: console, Jetty
Affects Versions: 2.0
Reporter: Jason Dillon
Assigned To: David Jencks
DeadProxyException are getting tosses like they are going out of style when
using the console to shutdown the server in Jetty.
{noformat}
Booting Geronimo Kernel (in Java 1.5.0_07)...
...
Geronimo Application Server started
[] received stop signal
16:41:45,014 ERROR [log] EXCEPTION
org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
at
org.apache.geronimo.management.geronimo.WebModule$$EnhancerByCGLIB$$90fecc6f.destroyInstance(generated)
at
org.apache.geronimo.jetty6.InternalJettyServletHolder.destroyInstance(InternalJettyServletHolder.java:93)
at
org.mortbay.jetty.servlet.ServletHolder.doStop(ServletHolder.java:294)
at
org.apache.geronimo.jetty6.InternalJettyServletHolder.internalDoStop(InternalJettyServletHolder.java:129)
at
org.apache.geronimo.jetty6.InternalJettyServletHolder.access$100(InternalJettyServletHolder.java:47)
at
org.apache.geronimo.jetty6.InternalJettyServletHolder$StopCommand.lifecycleMethod(InternalJettyServletHolder.java:142)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:52)
at
org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleCommand(ThreadClassloaderHandler.java:57)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:50)
at
org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleCommand(ComponentContextHandler.java:57)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:50)
at
org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCommand(InstanceContextHandler.java:81)
at
org.apache.geronimo.jetty6.InternalJettyServletHolder.doStop(InternalJettyServletHolder.java:118)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.mortbay.jetty.servlet.ServletHandler.doStop(ServletHandler.java:174)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:129)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:129)
at
org.mortbay.jetty.servlet.SessionHandler.doStop(SessionHandler.java:124)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop(AbstractImmutableHandler.java:40)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop(AbstractImmutableHandler.java:40)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop(AbstractImmutableHandler.java:40)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.mortbay.jetty.handler.HandlerWrapper.doStop(HandlerWrapper.java:129)
at
org.mortbay.jetty.handler.ContextHandler.doStop(ContextHandler.java:559)
at org.mortbay.jetty.webapp.WebAppContext.doStop(WebAppContext.java:482)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:65)
at
org.apache.geronimo.jetty6.JettyWebAppContext$StopCommand.lifecycleMethod(JettyWebAppContext.java:386)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:52)
at
org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleCommand(ThreadClassloaderHandler.java:57)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:50)
at
org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleCommand(ComponentContextHandler.java:57)
at
org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleCommand(AbstractImmutableHandler.java:50)
at
org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCommand(InstanceContextHandler.java:81)
at
org.apache.geronimo.jetty6.JettyWebAppContext.doStop(JettyWebAppContext.java:353)
Re: [HACKATHON] Raleigh, NC Monday 19 - Tuesday 20
Good list to start with. Remember thatnot everyone that will be there will be committers that have submitted NDAs so I think the TCK discussion is best left for the geronimo-tck mailing list. See you on Monday :) On Mar 18, 2007, at 3:22 PM, Davanum Srinivas wrote: Folks, Can folks post their TODO/Wish list for the hackathon? Personally here's what i am looking at. - Understand work already done in cxf integration and figure out what's missing to reach the same level of integration - Figure out what else needs to be done for both cxf and axis2 integration for feature completion - Review/understand some of the tck work already done so far (if any!) - Figure out how Lin and Lasantha can help between now and 2.0 final and how i can help them. - Figure out what is missing in Axis2. Since my primary objective is to make sure Axis2 1.2 has whatever is needed for G 2.0 final. Want to try avoiding cutting a Axis2 1.3 as much as possible. - Figure out what is needed in Axis 1.X specifically w.r.t SAAJ versions issue. We may need to cut Axis 1.5. - Work/code any high priority items needed ASAP Thanks, dims On 3/15/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Hrmmmnot in front of me...I'll find it before Monday :) On Mar 15, 2007, at 3:50 PM, Lin Sun wrote: Me too. Matt, do you want to tell us the room # for folks who don't want to meet you at the lobby?:-) Lin Jarek Gawor wrote: Me too. Jarek On 3/15/07, Joe Bohn [EMAIL PROTECTED] wrote: I'll be there. Joe Matt Hogstrom wrote: Dims said he'll be in the Raleigh area and since a lot of other committers area it would be good to get folks that are around together. For those that are interested in joining I have a room that we can use from 0900 - 1800 on Monday and Tuesday. The address is: 4205 South Miami Blvd Durham, NC 27703 Come to the lobby and ask for me and I'll be happy to let you in. I've got a conference room for about 10 people for both days with network connectivity and the like. Anyone in the area that is interested to come and hang out for the day or just a few hours is welcome. I expect folks will be on IRC and use the dev list for communication just like any informal get together. If anyone is interested I could probably open up a call in number if folks want to listen to each other type or otherwise interact. If folks are interested in that, contact me directly for call in information as that wouldn't be appropriate to post a passcode publicly. If there are folks that are interested I'll do my best to make that happen. The times are Eastern. Respond to this e-mail if your planing on showing up. I'll be there :) -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
Re: [HACKATHON] Raleigh, NC Monday 19 - Tuesday 20
Dims, Please share this info. with dev list because it will enable bit more contribution for me on these areas too. Have a nice time :-) . Lasantha Davanum Srinivas wrote: Folks, Can folks post their TODO/Wish list for the hackathon? Personally here's what i am looking at. - Understand work already done in cxf integration and figure out what's missing to reach the same level of integration - Figure out what else needs to be done for both cxf and axis2 integration for feature completion - Review/understand some of the tck work already done so far (if any!) - Figure out how Lin and Lasantha can help between now and 2.0 final and how i can help them. - Figure out what is missing in Axis2. Since my primary objective is to make sure Axis2 1.2 has whatever is needed for G 2.0 final. Want to try avoiding cutting a Axis2 1.3 as much as possible. - Figure out what is needed in Axis 1.X specifically w.r.t SAAJ versions issue. We may need to cut Axis 1.5. - Work/code any high priority items needed ASAP Thanks, dims On 3/15/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Hrmmmnot in front of me...I'll find it before Monday :) On Mar 15, 2007, at 3:50 PM, Lin Sun wrote: Me too. Matt, do you want to tell us the room # for folks who don't want to meet you at the lobby?:-) Lin Jarek Gawor wrote: Me too. Jarek On 3/15/07, Joe Bohn [EMAIL PROTECTED] wrote: I'll be there. Joe Matt Hogstrom wrote: Dims said he'll be in the Raleigh area and since a lot of other committers area it would be good to get folks that are around together. For those that are interested in joining I have a room that we can use from 0900 - 1800 on Monday and Tuesday. The address is: 4205 South Miami Blvd Durham, NC 27703 Come to the lobby and ask for me and I'll be happy to let you in. I've got a conference room for about 10 people for both days with network connectivity and the like. Anyone in the area that is interested to come and hang out for the day or just a few hours is welcome. I expect folks will be on IRC and use the dev list for communication just like any informal get together. If anyone is interested I could probably open up a call in number if folks want to listen to each other type or otherwise interact. If folks are interested in that, contact me directly for call in information as that wouldn't be appropriate to post a passcode publicly. If there are folks that are interested I'll do my best to make that happen. The times are Eastern. Respond to this e-mail if your planing on showing up. I'll be there :)
Re: DeadProxyException when shutdown from console (jetty)
On Mar 18, 2007, at 7:49 PM, Jason Dillon wrote: Anyone know why DeadProxyException are getting tosses like they are going out of style when using the console to shutdown the server in Jetty? Ya, this is a side effect of some changes I made so we'd construct the managed objects for jetty and do the injection. Will try to get to fixing it soon. Maybe I can do the same for tomcat when we construct the objects for them :-) Aside from hurting your eyes is it causing problems? thanks david jencks I've snipped out most of them... but there are a ton that are thrown. Insane call depth too... This appears to be something with the Jetty integration, shutdown with tomcat via the console doesn't puke up anything. Though, both spit this out [] received stop signal which is kinda odd. snip Booting Geronimo Kernel (in Java 1.5.0_07)... ... Geronimo Application Server started [] received stop signal 16:41:45,014 ERROR [log] EXCEPTION org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:87) at org.apache.geronimo.management.geronimo.WebModule$ $EnhancerByCGLIB$$90fecc6f.destroyInstance(generated) at org.apache.geronimo.jetty6.InternalJettyServletHolder.destroyInstance( InternalJettyServletHolder.java:93) at org.mortbay.jetty.servlet.ServletHolder.doStop (ServletHolder.java:294) at org.apache.geronimo.jetty6.InternalJettyServletHolder.internalDoStop (InternalJettyServletHolder.java:129) at org.apache.geronimo.jetty6.InternalJettyServletHolder.access$100 (InternalJettyServletHolder.java:47) at org.apache.geronimo.jetty6.InternalJettyServletHolder $StopCommand.lifecycleMethod(InternalJettyServletHolder.java:142) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleC ommand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleC ommand(ThreadClassloaderHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleC ommand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleCo mmand(ComponentContextHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleC ommand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCom mand(InstanceContextHandler.java:81) at org.apache.geronimo.jetty6.InternalJettyServletHolder.doStop (InternalJettyServletHolder.java:118) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.servlet.ServletHandler.doStop (ServletHandler.java:174) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.handler.HandlerWrapper.doStop (HandlerWrapper.java:129) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.handler.HandlerWrapper.doStop (HandlerWrapper.java:129) at org.mortbay.jetty.servlet.SessionHandler.doStop (SessionHandler.java:124) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop (AbstractImmutableHandler.java:40) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop (AbstractImmutableHandler.java:40) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStop (AbstractImmutableHandler.java:40) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.mortbay.jetty.handler.HandlerWrapper.doStop (HandlerWrapper.java:129) at org.mortbay.jetty.handler.ContextHandler.doStop (ContextHandler.java:559) at org.mortbay.jetty.webapp.WebAppContext.doStop (WebAppContext.java:482) at org.mortbay.component.AbstractLifeCycle.stop (AbstractLifeCycle.java:65) at org.apache.geronimo.jetty6.JettyWebAppContext $StopCommand.lifecycleMethod(JettyWebAppContext.java:386) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleC ommand(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycleC ommand(ThreadClassloaderHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleC ommand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleCo mmand(ComponentContextHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycleC ommand(AbstractImmutableHandler.java:50) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCom mand(InstanceContextHandler.java:81) at org.apache.geronimo.jetty6.JettyWebAppContext.doStop
Re: DeadProxyException when shutdown from console (jetty)
On Mar 18, 2007, at 5:41 PM, David Jencks wrote: Anyone know why DeadProxyException are getting tosses like they are going out of style when using the console to shutdown the server in Jetty? Ya, this is a side effect of some changes I made so we'd construct the managed objects for jetty and do the injection. Will try to get to fixing it soon. Maybe I can do the same for tomcat when we construct the objects for them :-) Aside from hurting your eyes is it causing problems? Not really, except that if there are any other exceptions tossed during shutdown its hard to track them down as the console traces barf all over things. --jason
Re: svn commit: r519684 - in /geronimo/server/trunk: configs/jasper/ configs/jsr88-deploymentfactory/ modules/geronimo-deploy-jsr88-bootstrapper/ modules/geronimo-jasper/ modules/geronimo-myfaces-buil
Thanks Jason. I really had no idea either. -- dims On 3/18/07, Jason Dillon [EMAIL PROTECTED] wrote: Personally, I would only like to see target in svn:ignore, since that is the one location that is expected to have generated stuff for m2 builds. Everything else, that I personally want to ignore I add in ~/.subversion/config in the [miscellany] section: global-ignores = *.log *.save *.o *.lo *.la #*# .*~ *~ .#* .DS_Store build dist target *.ipr *.iml *.iws .project .classpath .settings --jason On Mar 18, 2007, at 1:54 PM, David Jencks wrote: I had no idea there was a possibility to have a local ignore configuration! This is great! What would you like to see in the svn:ignore? Nothing? target? ?? thanks david jencks On Mar 18, 2007, at 4:36 PM, Jason Dillon wrote: Ugh... more svn:ingore stuff... is it too much trouble to get people to update their ~/.subversion/config to add these ignores? I find it very useful at times to use `svn status` to find out what generated stuff is in a tree. I can do this very easily by turning off my local ignores, but when people keep adding svn:ignore properties to directories its almost impossible to use `svn status` for this purpose. I would really like to see local ignores being used, and for folks to stop leaning on the svn:ingore property so much for stuff they *personally* want to have ignored. --jason On Mar 18, 2007, at 1:22 PM, [EMAIL PROTECTED] wrote: Author: dims Date: Sun Mar 18 13:22:36 2007 New Revision: 519684 URL: http://svn.apache.org/viewvc?view=revrev=519684 Log: ignore target and *.iml files Modified: geronimo/server/trunk/configs/jasper/ (props changed) geronimo/server/trunk/configs/jsr88-deploymentfactory/ (props changed) geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ (props changed) geronimo/server/trunk/modules/geronimo-jasper/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces-builder/ (props changed) geronimo/server/trunk/repository/ (props changed) geronimo/server/trunk/testsupport/test-deployment-javaee_5/ (props changed) Propchange: geronimo/server/trunk/configs/jasper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/configs/jsr88-deploymentfactory/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-jasper/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces-builder/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/repository/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/testsupport/test-deployment- javaee_5/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1 @@ +*.iml -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Created: (GERONIMO-2982) servlet-mapping url patterns may need / prepended
servlet-mapping url patterns may need / prepended --- Key: GERONIMO-2982 URL: https://issues.apache.org/jira/browse/GERONIMO-2982 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Jetty Affects Versions: 2.0-M3 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0-beta1 Apparently if we find a servlet-mapping url-pattern that doesn't start with / or * we should treat it as if it starts with /, such as by prepending / before further processing. I haven't tracked down the spec support for this behavior and could use some advice from greg on whether its actually reasonable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r519684 - in /geronimo/server/trunk: configs/jasper/ configs/jsr88-deploymentfactory/ modules/geronimo-deploy-jsr88-bootstrapper/ modules/geronimo-jasper/ modules/geronimo-myfaces-buil
No worries... I think that most folks that add stuff to svn:ingore don't realize there is a local global-ignores that can be used to ignore files for their preference which doesn't force that preference on everyone. --jason On Mar 18, 2007, at 5:59 PM, Davanum Srinivas wrote: Thanks Jason. I really had no idea either. -- dims On 3/18/07, Jason Dillon [EMAIL PROTECTED] wrote: Personally, I would only like to see target in svn:ignore, since that is the one location that is expected to have generated stuff for m2 builds. Everything else, that I personally want to ignore I add in ~/.subversion/config in the [miscellany] section: global-ignores = *.log *.save *.o *.lo *.la #*# .*~ *~ .#* .DS_Store build dist target *.ipr *.iml *.iws .project .classpath .settings --jason On Mar 18, 2007, at 1:54 PM, David Jencks wrote: I had no idea there was a possibility to have a local ignore configuration! This is great! What would you like to see in the svn:ignore? Nothing? target? ?? thanks david jencks On Mar 18, 2007, at 4:36 PM, Jason Dillon wrote: Ugh... more svn:ingore stuff... is it too much trouble to get people to update their ~/.subversion/config to add these ignores? I find it very useful at times to use `svn status` to find out what generated stuff is in a tree. I can do this very easily by turning off my local ignores, but when people keep adding svn:ignore properties to directories its almost impossible to use `svn status` for this purpose. I would really like to see local ignores being used, and for folks to stop leaning on the svn:ingore property so much for stuff they *personally* want to have ignored. --jason On Mar 18, 2007, at 1:22 PM, [EMAIL PROTECTED] wrote: Author: dims Date: Sun Mar 18 13:22:36 2007 New Revision: 519684 URL: http://svn.apache.org/viewvc?view=revrev=519684 Log: ignore target and *.iml files Modified: geronimo/server/trunk/configs/jasper/ (props changed) geronimo/server/trunk/configs/jsr88-deploymentfactory/ (props changed) geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ (props changed) geronimo/server/trunk/modules/geronimo-jasper/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces/ (props changed) geronimo/server/trunk/modules/geronimo-myfaces-builder/ (props changed) geronimo/server/trunk/repository/ (props changed) geronimo/server/trunk/testsupport/test-deployment-javaee_5/ (props changed) Propchange: geronimo/server/trunk/configs/jasper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/configs/jsr88- deploymentfactory/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-deploy-jsr88- bootstrapper/ -- --- svn:ignore (original) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -1 +1,3 @@ target +*.iml + Propchange: geronimo/server/trunk/modules/geronimo-jasper/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/modules/geronimo-myfaces- builder/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/repository/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1,2 @@ +*.iml +target Propchange: geronimo/server/trunk/testsupport/test-deployment- javaee_5/ -- --- svn:ignore (added) +++ svn:ignore Sun Mar 18 13:22:36 2007 @@ -0,0 +1 @@ +*.iml -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Commented: (GERONIMO-2455) Upgrade to new MX4J service release
[ https://issues.apache.org/jira/browse/GERONIMO-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482004 ] Kevan Miller commented on GERONIMO-2455: Great. Thanks Jason. I doubt seriously that we'll ever have a 1.1.2. There'd be a bunch of updates required to meet new Apache src header licensing requirements. It would take a lot of work. The 1.1.x build problems are pretty troubling, though. I would assume that an attempt to build 1.1.1 would encounter the same problems... Upgrade to new MX4J service release --- Key: GERONIMO-2455 URL: https://issues.apache.org/jira/browse/GERONIMO-2455 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1, 1.1.1, 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Fix For: 1.1.2, 1.2 Attachments: mx4j-3.0.2-bundle.jar, mx4j-jmx-3.0.2-bundle.jar, mx4j-remote-3.0.2-bundle.jar, mx4j-tools-3.0.2-bundle.jar There's a timing hole in the mx4j Monitor implementation. In some scenarios, a Monitor will not receive an appropriate Notifcation after being started. The fix for the problem has been committed to mx4j head. I've run tests using a private build from mx4j head, all looks well. Once available, we should upgrade to the mx4j service release 3.0.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Fisheye
How did you get this setup? Can we get this up for Geronimo too? --jason On Mar 18, 2007, at 5:33 PM, David Blevins wrote: FYI, we've been added to the Cenqua FishEye server for ASF projects. Thanks to Cenqua for the hosting and Infra for giving us the nod! http://fisheye6.cenqua.com/browse/openejb -David
Re: Fisheye
On Mar 18, 2007, at 5:53 PM, Jason Dillon wrote: How did you get this setup? Can we get this up for Geronimo too? Ping Infra and Cenqua. It's pretty much a case by case basis. Geronimo's section of svn is pretty large so they may just want to wait till there is a generally available setup. --jason On Mar 18, 2007, at 5:33 PM, David Blevins wrote: FYI, we've been added to the Cenqua FishEye server for ASF projects. Thanks to Cenqua for the hosting and Infra for giving us the nod! http://fisheye6.cenqua.com/browse/openejb -David
Re: activemq modules in trunk still using org.apache.activemq for package
On Mar 18, 2007, at 7:10 PM, Jason Dillon wrote: Somewhat related, I think we should rename the modules: configs/activemq - configs/activemq-ra modules/geronimo-activemq-gbean - modules/geronimo-activemq modules/geronimo-activemq-gbean-management - modules/geronimo- activemq-management I always get confused about the configs/activemq... its really the resource adapter configuration. And IMO its irrelevant to have 'gbean' in our module names. Those seem logical, to me... --kevan
Re: [HACKATHON] Raleigh, NC Monday 19 - Tuesday 20
On Mar 18, 2007, at 3:22 PM, Davanum Srinivas wrote: Folks, Can folks post their TODO/Wish list for the hackathon? Personally here's what i am looking at. - Understand work already done in cxf integration and figure out what's missing to reach the same level of integration - Figure out what else needs to be done for both cxf and axis2 integration for feature completion - Review/understand some of the tck work already done so far (if any!) - Figure out how Lin and Lasantha can help between now and 2.0 final and how i can help them. - Figure out what is missing in Axis2. Since my primary objective is to make sure Axis2 1.2 has whatever is needed for G 2.0 final. Want to try avoiding cutting a Axis2 1.3 as much as possible. - Figure out what is needed in Axis 1.X specifically w.r.t SAAJ versions issue. We may need to cut Axis 1.5. - Work/code any high priority items needed ASAP Sounds good. Not sure that I'll have much to contribute on these topice, but I'll plan on stopping in to say hello... --kevan
Re: [HACKATHON] Raleigh, NC Monday 19 - Tuesday 20
Dims, I'll contribute, but I will be 2000 miles away... Lets keep all up to date as I think I can help contribute in this area. I have a good idea of what is missing (since I have been so entrenched in it), so feel free to ping me. Thanks, Jeff Kevan Miller wrote: On Mar 18, 2007, at 3:22 PM, Davanum Srinivas wrote: Folks, Can folks post their TODO/Wish list for the hackathon? Personally here's what i am looking at. - Understand work already done in cxf integration and figure out what's missing to reach the same level of integration - Figure out what else needs to be done for both cxf and axis2 integration for feature completion - Review/understand some of the tck work already done so far (if any!) - Figure out how Lin and Lasantha can help between now and 2.0 final and how i can help them. - Figure out what is missing in Axis2. Since my primary objective is to make sure Axis2 1.2 has whatever is needed for G 2.0 final. Want to try avoiding cutting a Axis2 1.3 as much as possible. - Figure out what is needed in Axis 1.X specifically w.r.t SAAJ versions issue. We may need to cut Axis 1.5. - Work/code any high priority items needed ASAP Sounds good. Not sure that I'll have much to contribute on these topice, but I'll plan on stopping in to say hello... --kevan
Re: G 1.2 and IBM JDK (GERONIMO-433)
I compiled the latest branches/1.2 with the IBM 1.5.0 SR4 SDK on SLED10 i386 without any problems. I extracted the geronimo-tomcat-j2ee-1.2-SNAPSHOT-bin.tar.gz assembly and used ./geronimo.sh run to start the server and was able to log into the Console and viewed the Info, JVM and DB Info portlets via Firefox and then logged out. I wouldn't call this enough of a test to tell users that everything will work on the IBM JVMs, given we have seen problems in past releases with SSL and Certificate handling that required code changes for WASCE. There was a problem with shutdown, which I don't think is unique to the IBM SDK. When I used Ctrl+C, there was a never ending display of Java exceptions and I finally had to kill the Java process. 22:27:31,345 WARN [GeronimoConnectionEventListener] connectionErrorOccurred called with null SQL Exception: No current connection. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setAutoCommit(Unknown Source) at org.apache.derby.iapi.jdbc.BrokeredConnection.setAutoCommit(Unknown Source) at org.tranql.connector.jdbc.ManagedXAConnection.cleanup(ManagedXAConnection.java:143) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalReturn(SinglePoolConnectionInterceptor.java:136) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.returnConnection(AbstractSinglePoolConnectionInterceptor.java:123) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.returnConnection(TransactionEnlistingInterceptor.java:95) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.returnConnection(TransactionCachingInterceptor.java:105) As the above exception seemed to be thrown in a never ending loop, I don't have the very beginning of the log -Donald Jason Dillon wrote: Can someone who has the IBM 1.5 JDK installed please try to compile and run G 1.2? Should be easy enough to verify that it works... if you have the JDK installed. Might take like 30 minutes tops to verify. Can someone please try this, and comment on this issue if it works/doesn't work: https://issues.apache.org/jira/browse/GERONIMO-433 Thanks, --jason smime.p7s Description: S/MIME Cryptographic Signature
Re: G 1.2 and IBM JDK (GERONIMO-433)
I just started the same assembly with the Sun 1.5.0_11 SDK, went through the same Console steps and the server shutdown without any exceptions I'll try to gather more log info tomorrow. For now, I'd have to say 1.2 has some issue with the IBM JVMs BTW - I started with a clean .m2 repo, so it's using all of the latest artifacts. -Donald Donald Woods wrote: I compiled the latest branches/1.2 with the IBM 1.5.0 SR4 SDK on SLED10 i386 without any problems. I extracted the geronimo-tomcat-j2ee-1.2-SNAPSHOT-bin.tar.gz assembly and used ./geronimo.sh run to start the server and was able to log into the Console and viewed the Info, JVM and DB Info portlets via Firefox and then logged out. I wouldn't call this enough of a test to tell users that everything will work on the IBM JVMs, given we have seen problems in past releases with SSL and Certificate handling that required code changes for WASCE. There was a problem with shutdown, which I don't think is unique to the IBM SDK. When I used Ctrl+C, there was a never ending display of Java exceptions and I finally had to kill the Java process. 22:27:31,345 WARN [GeronimoConnectionEventListener] connectionErrorOccurred called with null SQL Exception: No current connection. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setAutoCommit(Unknown Source) at org.apache.derby.iapi.jdbc.BrokeredConnection.setAutoCommit(Unknown Source) at org.tranql.connector.jdbc.ManagedXAConnection.cleanup(ManagedXAConnection.java:143) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalReturn(SinglePoolConnectionInterceptor.java:136) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.returnConnection(AbstractSinglePoolConnectionInterceptor.java:123) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.returnConnection(TransactionEnlistingInterceptor.java:95) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.returnConnection(TransactionCachingInterceptor.java:105) As the above exception seemed to be thrown in a never ending loop, I don't have the very beginning of the log -Donald Jason Dillon wrote: Can someone who has the IBM 1.5 JDK installed please try to compile and run G 1.2? Should be easy enough to verify that it works... if you have the JDK installed. Might take like 30 minutes tops to verify. Can someone please try this, and comment on this issue if it works/doesn't work: https://issues.apache.org/jira/browse/GERONIMO-433 Thanks, --jason smime.p7s Description: S/MIME Cryptographic Signature
Re: G 1.2 and IBM JDK (GERONIMO-433)
Thanks for looking into this :-) --jason On Mar 18, 2007, at 7:54 PM, Donald Woods wrote: I just started the same assembly with the Sun 1.5.0_11 SDK, went through the same Console steps and the server shutdown without any exceptions I'll try to gather more log info tomorrow. For now, I'd have to say 1.2 has some issue with the IBM JVMs BTW - I started with a clean .m2 repo, so it's using all of the latest artifacts. -Donald Donald Woods wrote: I compiled the latest branches/1.2 with the IBM 1.5.0 SR4 SDK on SLED10 i386 without any problems. I extracted the geronimo-tomcat- j2ee-1.2-SNAPSHOT-bin.tar.gz assembly and used ./geronimo.sh run to start the server and was able to log into the Console and viewed the Info, JVM and DB Info portlets via Firefox and then logged out. I wouldn't call this enough of a test to tell users that everything will work on the IBM JVMs, given we have seen problems in past releases with SSL and Certificate handling that required code changes for WASCE. There was a problem with shutdown, which I don't think is unique to the IBM SDK. When I used Ctrl+C, there was a never ending display of Java exceptions and I finally had to kill the Java process. 22:27:31,345 WARN [GeronimoConnectionEventListener] connectionErrorOccurred called with null SQL Exception: No current connection. at org.apache.derby.impl.jdbc.Util.newEmbedSQLException (Unknown Source) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException (Unknown Source) at org.apache.derby.impl.jdbc.Util.noCurrentConnection (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.commit (Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.setAutoCommit (Unknown Source) at org.apache.derby.iapi.jdbc.BrokeredConnection.setAutoCommit (Unknown Source) at org.tranql.connector.jdbc.ManagedXAConnection.cleanup (ManagedXAConnection.java:143) at org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto r.internalReturn(SinglePoolConnectionInterceptor.java:136) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn terceptor.returnConnection (AbstractSinglePoolConnectionInterceptor.java:123) at org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto r.returnConnection(TransactionEnlistingInterceptor.java: 95) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor. returnConnection(TransactionCachingInterceptor.java:105) As the above exception seemed to be thrown in a never ending loop, I don't have the very beginning of the log -Donald Jason Dillon wrote: Can someone who has the IBM 1.5 JDK installed please try to compile and run G 1.2? Should be easy enough to verify that it works... if you have the JDK installed. Might take like 30 minutes tops to verify. Can someone please try this, and comment on this issue if it works/doesn't work: https://issues.apache.org/jira/browse/GERONIMO-433 Thanks, --jason
Re: Why is trunk using 1.0 and 1.1 of geronimo-j2ee-connector_1.5_spec
1.0 is coming from tranql (see below). Thanks Anita Path to dependency: 1) org.apache.geronimo.modules:geronimo-connector-builder:jar:2.0-SNAPSH T 2) org.tranql:tranql:jar:1.4.1 3) org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0 --- Jason Dillon [EMAIL PROTECTED] wrote: Actually... Im seeing some insano build behavior... where one build downloads this jar and another doesn't... both start out with a clean repo, both report build success... --jason On Mar 16, 2007, at 9:30 PM, Jason Dillon wrote: I see both of these puppies getting downloaded... anyone know why? --jason Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front
[jira] Resolved: (GERONIMO-2982) servlet-mapping url patterns may need / prepended
[
https://issues.apache.org/jira/browse/GERONIMO-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved GERONIMO-2982.
Resolution: Fixed
Assignee: Greg Wilkins (was: David Jencks)
Changed in rev 519834 to prepend / to a path url pattern if missing. Greg,
is this reasonable?
thanks
UrlPatternType[] urlPatterns =
servletMappingType.getUrlPatternArray();
for (UrlPatternType patternType : urlPatterns) {
String urlPattern = patternType.getStringValue().trim();
if (!urlPattern.startsWith(*) !urlPattern.startsWith(/))
{
urlPattern = / + urlPattern;
}
if (!knownServletMappings.contains(urlPattern)) {
knownServletMappings.add(urlPattern);
checkString(urlPattern);
SetString urlsForServlet =
servletMappings.get(servletName);
if (urlsForServlet == null) {
urlsForServlet = new HashSetString();
servletMappings.put(servletName, urlsForServlet);
}
urlsForServlet.add(urlPattern);
}
}
}
servlet-mapping url patterns may need / prepended
---
Key: GERONIMO-2982
URL: https://issues.apache.org/jira/browse/GERONIMO-2982
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Jetty
Affects Versions: 2.0-M3
Reporter: David Jencks
Assigned To: Greg Wilkins
Fix For: 2.0-beta1
Apparently if we find a servlet-mapping url-pattern that doesn't start with /
or * we should treat it as if it starts with /, such as by prepending /
before further processing. I haven't tracked down the spec support for this
behavior and could use some advice from greg on whether its actually
reasonable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: JPA Testsuite Error in Console
Something I missed in my previous mail. Looks like test method in the JPATest class is failing in the middle (simply speaking it doesn't call the service method of TestServlet). Any ideas Thanks, Lasantha Kevan Miller wrote: On Mar 15, 2007, at 2:34 AM, Lasantha Ranaweera wrote: Hi, I just tried to run the JPA testsuite after starting the server using java -javaagent:bin/jpa.jar -jar bin/server.jar command and noticed the following error in the console. It doesn't fail the test suite anyway. Is it relating to some other known bug or not? Insight would be greatly appriciated. Thanks, Lasantha 3666 WARN [RMI TCP Connection(10)-127.0.1.1] openjpa.Enhance - An exception was thrown while attempting to perform class file transformation on org/apache/geronimo/gbean/GBeanLifecycle$$FastClassByCGLIB$$e6d2946a: 0|false|0.9.6-incubating org.apache.openjpa.util.GeneralException: org.apache.geronimo.gbean.GBeanLifecycle$$FastClassByCGLIB$$e6d2946a in classloader org.apache.geronimo.testsuite/jpa-ear/2.0-SNAPSHOT/ear at org.apache.openjpa.enhance.PCClassFileTransformer.needsEnhance(PCClassFileTransformer.java:179) at org.apache.openjpa.enhance.PCClassFileTransformer.transform(PCClassFileTransformer.java:117) at org.apache.openjpa.persistence.PersistenceProviderImpl$ClassTransformerImpl.transform(PersistenceProviderImpl.java:140) at org.apache.geronimo.persistence.TransformerWrapper.transform(TransformerWrapper.java:43) at org.apache.geronimo.transformer.TransformerCollection.transform(TransformerCollection.java:36) ... Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.GBeanLifecycle$$FastClassByCGLIB$$e6d2946a in classloader org.apache.geronimo.testsuite/jpa-ear/2.0-SNAPSHOT/ear at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:303) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.openjpa.enhance.PCClassFileTransformer.needsEnhance(PCClassFileTransformer.java:171) ... 99 more Hi Lasantha, Yes, it's expected. I planned on sending a note to dev, but forgot... Now that we've enabled the jpa javaagent (see http://svn.apache.org/viewvc?view=revrevision=517581) in the server, you'll see these warning messages. (this has nothing to do with Surefire...). As you noted, it's not causing errors -- just pretty annoying. Masking the warning was not a trivial log4j property (or you wouldn't be seeing them...). At a minimum we'll mask the warnings. Better to avoid/fix the classloading issues all together. FYI -- the CNFE occurs for cglib generated classes... --kevan
