Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
The weblogic thin-client works this way - clustering is built into the client using portable interceptors and the JDK ORB. andy At 04:37 AM 5/5/2006, Filip Hanik - Dev Lists wrote: Jules Gosnell wrote: David Blevins wrote: On May 4, 2006, at 12:57 AM, Jules Gosnell wrote: Sort of. Both your explanations involve smartening the java clients on the other end of WS or CORBA to play nice. ?? smart java stubs for RMI over OpenEJB-protocol (what is it called?) or IIOP. for WS, the load-balancer will do it. The goal of those protocols is to interop in a language agnostic fashion. WS are all stateless for EJB, so there is nothing to cluster anyway. stateless calls are still clustered - the load-balancing and failover considerations still exist - you just do not require session affinity (stickiness). If you are talking about server-side requirements, then I agree. But for IIOP, would we simply not offer clustering to people using CORBA to interop with clients in other languages or on other platforms? to tell the truth, these cases have escaped my radar - My CORBA knowledge is pretty thin and I have only really considered it in a java/java environment - I am sure that Kresten would be much better positioned to answer this question... I will CC this to him, in case he would like to pick it up... corba is not far from RMI, and the corba implementation that you use, create their own stubs, and those stubs can do the same stuff as smart RMI stubs. I'm sure that corba could even do dynamic proxies in some sort of sense, they werent able to when I used it a long time ago, but if the technology has kept up, then yes, you should be able to build in significant logic in the clients. Filip ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
At 10:39 PM 5/4/2006, David Blevins wrote: stateless for EJB, so there is nothing to cluster anyway. But for IIOP, would we simply not offer clustering to people using CORBA to interop with clients in other languages or on other platforms? Some ORBs support multiple profiles for clustering (Borland is one) the IOR format is standard but the client still has to know what to do. WLS has its own clustered IOR format which we have published to some ISVs. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Created: (GERONIMODEVTOOLS-79) wtp adapter doesnt work with wtp 1.5rc1a
wtp adapter doesnt work with wtp 1.5rc1a Key: GERONIMODEVTOOLS-79 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-79 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.0.0 Environment: windows xp x86 Reporter: Panagiotis Korros Priority: Critical The geronimo plugin 1.0 gives me this error when i try to publish a project using wtp 1.5rc1a. java.lang.NoSuchMethodError: org.eclipse.wst.common.frameworks.datamodel.IDataModel.getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; at org.apache.geronimo.core.DeploymentUtils.createJarFile(DeploymentUtils.java:73) at org.apache.geronimo.core.commands.DistributeCommand.execute(DistributeCommand.java:43) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:77) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:69) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.distribute(GeronimoServerBehaviour.java:337) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:258) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:230) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:214) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:800) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Directory Update (Jeff?)
Hi, I have created a patch to move the G directory module to ApacheDS 1.0 RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at /maven nor at /maven2. The most recent version is 0.9.3. The same situation for MINA. So I can't post the patch right now since it will not work without these jars. Alex, I just want to let you know about this situation. 2006/4/24, Alex Karasulu [EMAIL PROTECTED]: Aaron Mulder wrote: I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. Ya all including RC1 should be in the M2 repo if not let me know. Alex Thanks, Aaron On 4/24/06, Jeff Genender [EMAIL PROTECTED] wrote: Alex, Can you get the jars in ibiblio and I can get the integration going? I am only seeing 0.9.2 in ibiblio at the moment. Thanks, Jeff Alex Karasulu wrote: Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex -- Alexei Zakharov, Intel Middleware Product Division
Issues Closed: week of 05-05-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1978] little-G for Jetty * [GERONIMO-1848] Shared Library support via a GBean ** Bug * [GERONIMO-1904] Precompile JSPs for all apps by default * [GERONIMO-1985] More then one configuration mananger was found in kernel with daytrader-derby-jetty-streamer-client * [GERONIMO-1937] Resource reference names not trimmed for whitespace * [GERONIMO-1946] SingleFileHotDeploy fixes for resolve, no force restart, empty target, and messages * [GERONIMO-1891] Meaningless ERROR printed by attribute manager during redeploy * [GERONIMO-1940] Bad deployment can't be undeployed * [GERONIMO-1925] JSP Example Plugin Install/Uninstall/Install doesn't work * [GERONIMO-1387] Geronimo Console Applications portlets fail after starting app client. * [GERONIMO-1954] Failed web app deployment cannot be undeployed * [GERONIMO-1506] DB info portlet should use new GeronimoVersion * [GERONIMO-1508] 1.1 won't accept plans with 1.0 configIds in references, parents, imports, etc. * [GERONIMO-1769] Console should create links for all sections including the current section * [GERONIMO-1683] Web app context-root should trim whitespace * [GERONIMO-1961] SingleFileHotDeployer - Application is not started on server restart * [GERONIMO-1962] SingleFileHotDeployer: Messages on the deployment status are not issued to console or log file. * [GERONIMO-1789] Exceptions while adding SQL Realm thru Admin Console * [GERONIMO-1973] javamail Session class using wrong classloader search sequence for resolving providers. * [GERONIMO-1970] During deployment, ModuleBuilders don't log an error if call to DeploymentUtil.recursiveDelete(dir) does not work * [GERONIMO-1949] Some Tomcat Jetty web app deployment errors do not identify web app module name associated with the error * [GERONIMO-1931] Deployers and the deploying classes are in separate class loader hierarchies * [GERONIMO-1414] Console About page does not set the shortcut icon ** Improvement * [GERONIMO-1231] Error on startup: java.lang.NoClassDefFoundError at javax.crypto.Mac.getInstance... * [GERONIMO-1529] Console should display Geronimo Version
Re: hot deployment directory
Matt Hogstrom wrote: As Aaron said we have made significant progress in testing againnst our test harnesses but there are lingering issues that need to be addressed. Aaron (aka the JIRA magnet) has identified several usability and bug issues. The first release that we put our is stable (DayTrader runs in most modes) but we do need to fix the lingering file lock problems, files being left behind on deploy, etc. If you have some time Geir we have lots and lots of JIRAs and could use some warm bodies :) Heh. I've ordered more Round Tuits. :) I was just wondering - I had it in my head that it was inflight for release, and was surprised with Aaron's suggestion that more work be done in 1.1. I understand now. Thanks geir Matt Geir Magnusson Jr wrote: Aaron Mulder wrote: Please do any work in the 1.1 branch. Right now 1.2 is in a very uncertain state. Though, I suspect the issues will be different in 1.1, so you may want to start by testing the same things there. IIRC, the hot deployer does not yet check the timestamp of the deployments in it its directory during startup and compare those to the timestamps of the current modules to determine whether an existing file there is the same as ever or a new version was copied in while the server was down. That should be doable in 1.1. I thought 1.1 was done and in testing in prep for release? geir
[jira] Commented: (GERONIMODEVTOOLS-79) wtp adapter doesnt work with wtp 1.5rc1a
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-79?page=comments#action_12378013 ] Sachin Patel commented on GERONIMODEVTOOLS-79: -- This is correct, the there are breaking API changes from WTP 1.0x to 1.5 and the plugin will need to be ported over. wtp adapter doesnt work with wtp 1.5rc1a Key: GERONIMODEVTOOLS-79 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-79 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.0.0 Environment: windows xp x86 Reporter: Panagiotis Korros Priority: Critical The geronimo plugin 1.0 gives me this error when i try to publish a project using wtp 1.5rc1a. java.lang.NoSuchMethodError: org.eclipse.wst.common.frameworks.datamodel.IDataModel.getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; at org.apache.geronimo.core.DeploymentUtils.createJarFile(DeploymentUtils.java:73) at org.apache.geronimo.core.commands.DistributeCommand.execute(DistributeCommand.java:43) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:77) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:69) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.distribute(GeronimoServerBehaviour.java:337) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:258) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:230) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:214) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:800) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-1988) Change configId to moduleId in xml
The patch to me looks like a safe enough fix and its assuring that tck didn't blow up. So +0 from me. I would have to react to this change as well, but the impact for me should be minimal. For the other subtasks you created (1990, 1991), what are the plan for those? - sachin On May 5, 2006, at 1:50 AM, Dain Sundstrom wrote: The patch is done. It was very easy since we transfer the environment data from xmlbeans into our own pojo representation. This means I only needed to update the marshaling code. For that, I just used intellij to rename the elements in xmlbean generated code. After that is was a matter of updating the schema to match the code, regenerating the xmlbeans code, and updating the plans. I made the following changes to the schema: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo- module-1.1.xsd As for the tck, we only need to update the server plans and not the test plans since the test plans are run though the upgrade code. I didn't have to touch the upgrade code at all since it is using our environment pojo tree (a good example of why having our own pojo tree is so nice). I ran a few sections of the tck and they all passed with the the patch in place. The patch is attached to GERONIMO-1988. So what do you think? -dain On May 4, 2006, at 2:11 PM, Matt Hogstrom wrote: Thanks bubba (that's Southern for Dain...don't ask me how they came up with that) Dain Sundstrom wrote: I am going to create a patch. If it works (and is small), we can discuss committing it. -dain On May 4, 2006, at 2:00 PM, Matt Hogstrom wrote: Dain, I know we've talked about this on Irc but there didn't seem to be consensus (I think djencks had some concerns). Could you summarize the change in a note? I know that you don't want to end up in an embroiled debate on the issue but I'm concerned that this will set us back. The grumpy release manager Matt Dain Sundstrom (JIRA) wrote: Change configId to moduleId in xml -- Key: GERONIMO-1988 URL: http://issues.apache.org/jira/browse/GERONIMO-1988 Project: Geronimo Type: Sub-task Security: public (Regular issues) Versions: 1.0 Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Priority: Blocker Fix For: 1.1 The word configuration in xml files should be replaced with module before we ship 1.1. We are planning on replacing all uses of configuration with module in 1.2 and the only place this appears in user code is in the vendor deployment descriptors (xml). It is important that we make as few schema changes between releases as to have minimal disruption on users.
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
OK, here's the deal. I was able to recreate this problem on an XP box, following the steps John mentioned. However, it works fine when you include the options in the geronimo.bat file. %_EXECJAVA% %JAVA_OPTS% %GERONIMO_OPTS% -DXorg.apache.geronimo.NewClassLoader=true -Dorg.apache.geronimo.base.dir=%GERONIMO_BASE% -Djava.io.tmpdir=%GERONIMO_TMPDIR% -jar %_JARFILE% %_LONG_OPT% %CMD_LINE_ARGS% Cheers Prasad. On 5/4/06, John Sisson [EMAIL PROTECTED] wrote: Haven't had a chance to debug this.. Can others reproduce? This problem only seems to occur when using the NewClassLoader. John C:\Tempset GERONIMO_OPTS=-DXorg.apache.geronimo.NewClassLoader=true C:\Tempgeronimo-1.1-SNAPSHOT\bin\geronimo.bat run --long Using GERONIMO_BASE: C:\Temp\geronimo-1.1-SNAPSHOT Using GERONIMO_HOME: C:\Temp\geronimo-1.1-SNAPSHOT Using GERONIMO_TMPDIR: C:\Temp\geronimo-1.1-SNAPSHOT\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Booting Geronimo Kernel (in Java 1.4.2_10)... Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car started in 1/20 0s Configuration geronimo/j2ee-server/1.1-SNAPSHOT/car started in 2/20 1s Configuration geronimo/j2ee-security/1.1-SNAPSHOT/car started in 3/20 1s Configuration geronimo/axis/1.1-SNAPSHOT/car started in 4/20 0s Configuration geronimo/openejb/1.1-SNAPSHOT/car started in 5/20 0s Configuration geronimo/system-database/1.1-SNAPSHOT/car started in 6/20 3s Configuration geronimo/activemq-broker/1.1-SNAPSHOT/car started in 7/20 1s Configuration geronimo/activemq/1.1-SNAPSHOT/car started in 8/20 0s Configuration geronimo/tomcat/1.1-SNAPSHOT/car started in 9/20 2s Configuration geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car started in 10/20 1s Configuration geronimo/j2ee-deployer/1.1-SNAPSHOT/car started in 11/20 0s Configuration geronimo/openejb-deployer/1.1-SNAPSHOT/car started in 12/20 0s Configuration geronimo/client-deployer/1.1-SNAPSHOT/car started in 13/20 0s Configuration geronimo/axis-deployer/1.1-SNAPSHOT/car started in 14/20 0s Configuration geronimo/sharedlib/1.1-SNAPSHOT/car started in 15/20 0s Configuration geronimo/tomcat-deployer/1.1-SNAPSHOT/car started in 16/20 0s Configuration geronimo/welcome-tomcat/1.1-SNAPSHOT/car started in 17/20 0s Configuration geronimo/webconsole-tomcat/1.1-SNAPSHOT/car10:32:03,159 ERROR [StandardContext] Error reading tld listeners javax.serv let.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$$b8616351.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
Re: ActiveMQ 4.0 final release candidate recut
I think that's because the parent pom has not been published to the official repository location yet. I think if you add http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/ to your settings.xml then it should work. Regards, Hiram On 5/5/06, James Strachan [EMAIL PROTECTED] wrote: Looks great! The notice files licenses all look fine to me. The only minor nit right now is I can't run the activemq-web-demo and activemq-web-console from the binary distro due to the parent pom not downloading... http://www.rafb.net/paste/results/9SUFGr18.html On 5/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Folks, I have rebuild the final release candidate again. We are now including the activemq-web-demo and activemq-web-console projects in the example directory of the final distribution. Also we are now also will be publishing to a maven 2 repository in addition to the maven 1 repository. The https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/activemq tag has been updated. The binary distributions are now at: http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/incubator-activemq/distributions/ The maven 1 repository layout for this release is at: http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/ The maven 2 repository layout for this release is at: http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/ -- Regards, Hiram -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
John, I got hte same error using tomcat (see below) but jetty seemed to work OK. The error indicates that tomcat can't load the portlet taglib descriptor file. The code in tomcat that tries to load it looks like: inputSource = new InputSource( context.getServletContext().getResourceAsStream(resourcePath)); [EMAIL PROTECTED] bin]$ java -DXorg.apache.geronimo.NewClassLoader=true -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-SNAPSHOT [** ] 84% 25s Loading geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext] Error reading tld listeners javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$$42172c3b.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) 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:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:411) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:174) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:505) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:486) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 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
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
Paul, Can you dump the URLClassLoader paths? This may help find th answer... Jeff Paul McMahan wrote: John, I got hte same error using tomcat (see below) but jetty seemed to work OK. The error indicates that tomcat can't load the portlet taglib descriptor file. The code in tomcat that tries to load it looks like: inputSource = new InputSource( context.getServletContext().getResourceAsStream(resourcePath)); [EMAIL PROTECTED] bin]$ java -DXorg.apache.geronimo.NewClassLoader=true -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-SNAPSHOT [** ] 84% 25s Loading geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext] Error reading tld listeners javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$$42172c3b.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) 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:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:411) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:174) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:505) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:486) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at
[jira] Updated: (GERONIMO-1992) Exception in ConfigManager during redeploy
[ http://issues.apache.org/jira/browse/GERONIMO-1992?page=all ] Aaron Mulder updated GERONIMO-1992: --- Description: If you deploy version 1 of an app, then redeploy version 2, you end up with version 1 in the repository (unloaded) and version 2 in the repository (loaded and running). Then if you redeploy version 3, it dies. I assume it's dying trying to interact with the unloaded version 1. The stack trace is: 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.kernel.config.Configuration$$EnhancerByCGLIB$$2c5e9c59.getId(generated) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.getResolvedParentIds(SimpleConfigurationManager.java:1133) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.reloadConfiguration(SimpleConfigurationManager.java:721) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.reloadConfiguration(SimpleConfigurationManager.java:709) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) A similar problem comes up in the console, presumably also trying to deal with the unloaded module: 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.kernel.config.Configuration$$EnhancerByCGLIB$$d92f9886.getGBeans(generated) at org.apache.geronimo.kernel.config.Configuration.findGBeanDatas(Configuration.java:692) at org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:625) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:610) at org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:589) at org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:527) at org.apache.geronimo.console.util.PortletManager.getModule(PortletManager.java:374) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:141) To replicate this, deploy an application with no version in the module ID, copy the directory for it out of the repository, redeploy it to a newer version, and then copy the old version back into the repository (so it's in the repo but the server is not aware of it per se). was: If you deploy version 1 of an app, then redeploy version 2, you end up with version 1 in the repository (unloaded) and version 2 in the repository (loaded and running). Then if you redeploy version 3, it dies. I assume it's dying trying to interact with the unloaded version 1. The stack trace is: 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.kernel.config.Configuration$$EnhancerByCGLIB$$2c5e9c59.getId(generated) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.getResolvedParentIds(SimpleConfigurationManager.java:1133) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.reloadConfiguration(SimpleConfigurationManager.java:721) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.reloadConfiguration(SimpleConfigurationManager.java:709) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) Exception in ConfigManager during redeploy -- Key: GERONIMO-1992 URL: http://issues.apache.org/jira/browse/GERONIMO-1992 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.1 If you deploy version 1 of an app, then redeploy version 2, you end up with version 1 in the repository (unloaded) and version 2 in the repository (loaded and running). Then if you redeploy version 3, it dies. I assume it's dying trying to interact with the unloaded version 1. The stack trace is: 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.kernel.config.Configuration$$EnhancerByCGLIB$$2c5e9c59.getId(generated) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.getResolvedParentIds(SimpleConfigurationManager.java:1133) at
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
There's a ClassLoaderDumper in the current tree that might be useful for this. Though it does kind of result in information overload. :) Thanks, Aaron On 5/5/06, Jeff Genender [EMAIL PROTECTED] wrote: Paul, Can you dump the URLClassLoader paths? This may help find th answer... Jeff Paul McMahan wrote: John, I got hte same error using tomcat (see below) but jetty seemed to work OK. The error indicates that tomcat can't load the portlet taglib descriptor file. The code in tomcat that tries to load it looks like: inputSource = new InputSource( context.getServletContext().getResourceAsStream(resourcePath)); [EMAIL PROTECTED] bin]$ java -DXorg.apache.geronimo.NewClassLoader=true -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-SNAPSHOT [** ] 84% 25s Loading geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext] Error reading tld listeners javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$$42172c3b.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) 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:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:411) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:174) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:505) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:486) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.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:122) at
Re: [VOTE] XBean 2.3 release
The VOTE results are 5 +1, no +0, no -1. I have published the binaries at http://www.apache.org/dist/java-repository/org.apache.xbean/ http://www.apache.org/dist/maven-repository/org/apache/xbean/ Cheers, Guillaume Nodet Guillaume Nodet wrote: I have put some binaries of the new xbean-2.3 release. They are available at http://people.apache.org/~gnodet/xbean-2.3/ [ ] +1 Release the binary as XBean 2.3 [ ] -1 Veto the release (provide specific comments) If the vote passes, I will put the binaries in their official distribution repositories. Cheers, Guillaume Nodet
Re: [jira] Created: (GERONIMO-1988) Change configId to moduleId in xml
On May 5, 2006, at 5:10 AM, Sachin Patel wrote: The patch to me looks like a safe enough fix and its assuring that tck didn't blow up. So +0 from me. I would have to react to this change as well, but the impact for me should be minimal. For the other subtasks you created (1990, 1991), what are the plan for those? For 1990, someone just needs to sweep through the text and replace configuration with module. It looks like the console has already been converted. 1991 is something we need to delay until 1.2 since it involves renaming many classes. -dain
[jira] Assigned: (GERONIMO-1981) Web Connector has GBean=(container name) in AbstractName
[ http://issues.apache.org/jira/browse/GERONIMO-1981?page=all ] David Jencks reassigned GERONIMO-1981: -- Assign To: Aaron Mulder (was: David Jencks) Web Connector has GBean=(container name) in AbstractName Key: GERONIMO-1981 URL: http://issues.apache.org/jira/browse/GERONIMO-1981 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 The GBean name for the default Jetty AJP connector appears to be (forgive the URL encoding but this came from the console): geronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%3FGBean%3DJettyWebContainer%2CServiceModule%3Dgeronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%2Cj2eeType%3DGBean%2Cname%3DJettyAJP13Connector The problem is the part of the connector name that appears to say GBean=JettyWebContainer I believe that was introduced in an attempt to have a standard JSR-77 component list its parent module with its parent module type, but that doesn't seem to make sense for parents of type GBean. Can we remove the ParentType=ParentName block for parents of type GBean? If not, then we have a bug that when creating a new web connector we don't add the ParentType=ParentName block. e.g., see JettyManagerImpl.addConnector, which runs this: AbstractName name = kernel.getNaming().createChildName(containerName, uniqueName, NameFactory.GERONIMO_SERVICE); And that gets a name without the GBean=JettyWebConnector, which means even if the name= component is the same as an existing connector, it comes out with a distinct AbstractName. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1981) Web Connector has GBean=(container name) in AbstractName
[ http://issues.apache.org/jira/browse/GERONIMO-1981?page=comments#action_12378077 ] David Jencks commented on GERONIMO-1981: I looked in the log and the ajp connector abstract name is geronimo/jetty/1.1-SNAPSHOT/car?ServiceModule=geronimo/jetty/1.1-SNAPSHOT/car,j2eeType=GBean,name=JettyAJP13Connector I can't figure out where you are finding what you pasted. Web Connector has GBean=(container name) in AbstractName Key: GERONIMO-1981 URL: http://issues.apache.org/jira/browse/GERONIMO-1981 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Assignee: David Jencks Priority: Blocker Fix For: 1.1 The GBean name for the default Jetty AJP connector appears to be (forgive the URL encoding but this came from the console): geronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%3FGBean%3DJettyWebContainer%2CServiceModule%3Dgeronimo%2Fjetty%2F1.1-SNAPSHOT%2Fcar%2Cj2eeType%3DGBean%2Cname%3DJettyAJP13Connector The problem is the part of the connector name that appears to say GBean=JettyWebContainer I believe that was introduced in an attempt to have a standard JSR-77 component list its parent module with its parent module type, but that doesn't seem to make sense for parents of type GBean. Can we remove the ParentType=ParentName block for parents of type GBean? If not, then we have a bug that when creating a new web connector we don't add the ParentType=ParentName block. e.g., see JettyManagerImpl.addConnector, which runs this: AbstractName name = kernel.getNaming().createChildName(containerName, uniqueName, NameFactory.GERONIMO_SERVICE); And that gets a name without the GBean=JettyWebConnector, which means even if the name= component is the same as an existing connector, it comes out with a distinct AbstractName. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1974) Can't redeploy a copy of an application using a different version in the module ID
[ http://issues.apache.org/jira/browse/GERONIMO-1974?page=all ] Aaron Mulder reassigned GERONIMO-1974: -- Assign To: Dain Sundstrom (was: Aaron Mulder) Can't redeploy a copy of an application using a different version in the module ID Key: GERONIMO-1974 URL: http://issues.apache.org/jira/browse/GERONIMO-1974 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Prasad Kashyap Assignee: Dain Sundstrom Priority: Blocker Fix For: 1.1 Attachments: 1974-redeploy-improvements.patch, redeploy-stacktrace.txt If you deploy an application with version foo/bar/1.0/baz and then change the plan to be foo/bar/1.1/baz and try to redeploy it doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1974) Can't redeploy a copy of an application using a different version in the module ID
[ http://issues.apache.org/jira/browse/GERONIMO-1974?page=all ] Aaron Mulder updated GERONIMO-1974: --- Attachment: 1974-redeploy-improvements.patch Here's the work in progress. It fixes most of the problems, except there's still a lingering problem with redeploying a stopped configuration. It looks like in thet scenario, the new configuration is loaded but not started, but the ConfigurationStatus in the ConfigurationModel isn't put into the loaded state. Therefore ConfigurationManager.isLoaded returns false, but ConfigurationManager.load fails because certain GBeans already exist. In other words, the heart of the problem appears to be the ConfigurationStatus being out of sync with the actual status of the configuration. Dain, if you can review the changes to SimpleConfigurationManager and look into this last remaining issue, that would be great. To reproduce, apply the patch, build, and make a symlink jetty from the Geronimo tree to the assembly output and run this sequence: java -jar jetty/bin/deployer.jar --verbose undeploy welcome-jetty java -jar jetty/bin/deployer.jar --verbose deploy applications/welcome/target/geronimo-welcome-1.1-SNAPSHOT.war java -jar jetty/bin/deployer.jar --verbose stop geronimo-welcome-1.1-SNAPSHOT java -jar jetty/bin/deployer.jar --verbose redeploy applications/welcome/target/geronimo-welcome-1.1-SNAPSHOT.war (everything up to here appears to work OK) java -jar jetty/bin/deployer.jar --verbose start geronimo-welcome-1.1-SNAPSHOT java -jar jetty/bin/deployer.jar --verbose stop geronimo-welcome-1.1-SNAPSHOT java -jar jetty/bin/deployer.jar --verbose start geronimo-welcome-1.1-SNAPSHOT The start commands either fail or say the module is already running, and the stop commands do nothing, but list-modules never shows it as running. Starting from the console blows up with the stack trace shown below. The web URL http://localhost:8080/geronimo-welcome-1.1-SNAPSHOT/ never shows anything. Redeploy seems to work OK if the original module was running, regardless of whether it had a module ID with a version and whether you changed the version if it had one. org.apache.geronimo.kernel.config.LifecycleException: load of default/geronimo-welcome-1.1-SNAPSHOT/1146848427688/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:300) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:228) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:110) ... Caused by: org.apache.geronimo.kernel.GBeanAlreadyExistsException: GBean already registered: geronimo.config:name=default/geronimo-welcome-1.1-SNAPSHOT/1146848427688/war at org.apache.geronimo.kernel.basic.BasicRegistry.register(BasicRegistry.java:88) at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:355) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:141) Can't redeploy a copy of an application using a different version in the module ID Key: GERONIMO-1974 URL: http://issues.apache.org/jira/browse/GERONIMO-1974 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Prasad Kashyap Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: 1974-redeploy-improvements.patch, redeploy-stacktrace.txt If you deploy an application with version foo/bar/1.0/baz and then change the plan to be foo/bar/1.1/baz and try to redeploy it doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
Thanks Aaron. I added ClassLoaderDumper.dump(this.getContainer()); at GeronimoBeforeAfterValve line 31 (which is right before the error occurs in catalina). The output is attached. I'm not sure how useful this is so let me know if you need some other type of info. Paul On 5/5/06, Aaron Mulder [EMAIL PROTECTED] wrote: There's a ClassLoaderDumper in the current tree that might be useful for this. Though it does kind of result in information overload. :) Thanks, Aaron On 5/5/06, Jeff Genender [EMAIL PROTECTED] wrote: Paul, Can you dump the URLClassLoader paths? This may help find th answer... Jeff Paul McMahan wrote: John, I got hte same error using tomcat (see below) but jetty seemed to work OK. The error indicates that tomcat can't load the portlet taglib descriptor file. The code in tomcat that tries to load it looks like: inputSource = new InputSource( context.getServletContext().getResourceAsStream(resourcePath)); [EMAIL PROTECTED] bin]$ java -DXorg.apache.geronimo.NewClassLoader=true -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-SNAPSHOT [** ] 84% 25s Loading geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext] Error reading tld listeners javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$$42172c3b.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) 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:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:411) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:174) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:505) at
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
Hi,
I build two hours ago, rev 400058 on winXP. I am not seeing this
problem, I used java -D bin\server.jar. Here is a
snapshot from admin console JVM -- under Etc :
Xorg.apache.geronimo.NewClassLoader true
activemq.broker.disable-clean-shutdown true
awt.toolkit sun.awt.windows.WToolkit
catalina.base
D:\anita\geronimo\geronimo-1.1\assemblies\j2ee-tomcat-server\target\geronimo-1.1-SNAPSHOT\var\catalina
catalina.home var/catalina
catalina.useNaming false
common.loader ${catalina.home}/common/classes
${catalina.home}/common/i18n/*.jar
${catalina.home}/common/endorsed/*.jar
${catalina.home}/common/lib/*.jar
derby.storage.fileSyncTransactionLogtrue
derby.system.home
D:\anita\geronimo\geronimo-1.1\assemblies\j2ee-tomcat-server\target\geronimo-1.1-SNAPSHOT\var\derby
file.encoding Cp1252
file.encoding.pkg sun.io
file.separator \
java.naming.factory.initial
com.sun.jndi.rmi.registry.RegistryContextFactory
java.naming.factory.url.pkgsorg.apache.geronimo.naming
java.naming.provider.urlrmi://0.0.0.0:1099
..
Thnaks
Anita
--- Aaron Mulder [EMAIL PROTECTED] wrote:
There's a ClassLoaderDumper in the current tree that might be useful
for this. Though it does kind of result in information overload. :)
Thanks,
Aaron
On 5/5/06, Jeff Genender [EMAIL PROTECTED] wrote:
Paul,
Can you dump the URLClassLoader paths? This may help find th
answer...
Jeff
Paul McMahan wrote:
John, I got hte same error using tomcat (see below) but jetty
seemed
to work OK. The error indicates that tomcat can't load the
portlet
taglib descriptor file. The code in tomcat that tries to load it
looks
like:
inputSource =
new InputSource(
context.getServletContext().getResourceAsStream(resourcePath));
[EMAIL PROTECTED] bin]$ java
-DXorg.apache.geronimo.NewClassLoader=true -jar server.jar
Booting Geronimo Kernel (in Java 1.4.2_10)...
Starting Geronimo Application Server v1.1-SNAPSHOT
[** ] 84% 25s Loading
geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext]
Error
reading tld listeners javax.servlet.ServletException: Exception
processing TLD at resource path /WEB-INF/tld/portlet.tld in
context
/console
javax.servlet.ServletException: Exception processing TLD at
resource
path /WEB-INF/tld/portlet.tld in context /console
at
org.apache.catalina.startup.TldConfig.tldScanTld(TldConfig.java:547)
at
org.apache.catalina.startup.TldConfig.execute(TldConfig.java:300)
at
org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4193)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4049)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:331)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:186)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313)
at
org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
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.tomcat.TomcatContainer$$EnhancerByCGLIB$$42172c3b.addContext(generated)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
Fixed it. It had nothing to do with the class loader layout. The findResource method was returning an invalid jar URL. The the url was missing the file: protocol on the nested jar. It was difficult to find, since the error occurred in xerces as it attempted to load a schema. It seems to do some sort of URL string manipulation. Anyway, it is fixed now. -dain On May 5, 2006, at 11:00 AM, Paul McMahan wrote: Thanks Aaron. I added ClassLoaderDumper.dump(this.getContainer()); at GeronimoBeforeAfterValve line 31 (which is right before the error occurs in catalina). The output is attached. I'm not sure how useful this is so let me know if you need some other type of info. Paul On 5/5/06, Aaron Mulder [EMAIL PROTECTED] wrote: There's a ClassLoaderDumper in the current tree that might be useful for this. Though it does kind of result in information overload. :) Thanks, Aaron On 5/5/06, Jeff Genender [EMAIL PROTECTED] wrote: Paul, Can you dump the URLClassLoader paths? This may help find th answer... Jeff Paul McMahan wrote: John, I got hte same error using tomcat (see below) but jetty seemed to work OK. The error indicates that tomcat can't load the portlet taglib descriptor file. The code in tomcat that tries to load it looks like: inputSource = new InputSource( context.getServletContext().getResourceAsStream(resourcePath)); [EMAIL PROTECTED] bin]$ java -DXorg.apache.geronimo.NewClassLoader=true -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-SNAPSHOT [** ] 84% 25s Loading geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext] Error reading tld listeners javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld (TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute (TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds (StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201 (GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start (GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal (ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext (TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$ $9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$ $42172c3b.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart (TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) 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:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean (BasicKernel.java:379) at
Re: New classloader causing problems on Tomcat ? - Exception processing TLD
Hmm... It works for me (rev 400058) without any change. I also tried with geronimo run geronimo run --long works every time! This is from getenv Variable GERONIMO_OPTs has the value : DXorg.apache.geronimo.NewClassLoader=true--- Thanks Anita --- Dain Sundstrom [EMAIL PROTECTED] wrote: Fixed it. It had nothing to do with the class loader layout. The findResource method was returning an invalid jar URL. The the url was missing the file: protocol on the nested jar. It was difficult to find, since the error occurred in xerces as it attempted to load a schema. It seems to do some sort of URL string manipulation. Anyway, it is fixed now. -dain On May 5, 2006, at 11:00 AM, Paul McMahan wrote: Thanks Aaron. I added ClassLoaderDumper.dump(this.getContainer()); at GeronimoBeforeAfterValve line 31 (which is right before the error occurs in catalina). The output is attached. I'm not sure how useful this is so let me know if you need some other type of info. Paul On 5/5/06, Aaron Mulder [EMAIL PROTECTED] wrote: There's a ClassLoaderDumper in the current tree that might be useful for this. Though it does kind of result in information overload. :) Thanks, Aaron On 5/5/06, Jeff Genender [EMAIL PROTECTED] wrote: Paul, Can you dump the URLClassLoader paths? This may help find th answer... Jeff Paul McMahan wrote: John, I got hte same error using tomcat (see below) but jetty seemed to work OK. The error indicates that tomcat can't load the portlet taglib descriptor file. The code in tomcat that tries to load it looks like: inputSource = new InputSource( context.getServletContext().getResourceAsStream(resourcePath)); [EMAIL PROTECTED] bin]$ java -DXorg.apache.geronimo.NewClassLoader=true -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-SNAPSHOT [** ] 84% 25s Loading geronimo/webconsole-tomc...10:37:39,091 ERROR [StandardContext] Error reading tld listeners javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console javax.servlet.ServletException: Exception processing TLD at resource path /WEB-INF/tld/portlet.tld in context /console at org.apache.catalina.startup.TldConfig.tldScanTld (TldConfig.java:547) at org.apache.catalina.startup.TldConfig.execute (TldConfig.java:300) at org.apache.catalina.core.StandardContext.processTlds (StandardContext.java:4193) at org.apache.catalina.core.StandardContext.start (StandardContext.java:4049) at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201 (GeronimoStandardContext.java:67) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:331) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.geronimo.tomcat.GeronimoStandardContext.start (GeronimoStandardContext.java:186) at org.apache.catalina.core.ContainerBase.addChildInternal (ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:524) at org.apache.geronimo.tomcat.TomcatContainer.addContext (TomcatContainer.java:313) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$ $9370b073.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:817) 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.tomcat.TomcatContainer$$EnhancerByCGLIB$ $42172c3b.addContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart (TomcatWebAppContext.java:448) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:981) at
Re: Directory Update (Jeff?)
Alexei Zakharov wrote: Hi, I have created a patch to move the G directory module to ApacheDS 1.0 RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at /maven nor at /maven2. The most recent version is 0.9.3. The same situation for MINA. So I can't post the patch right now since it will not work without these jars. Alex, I just want to let you know about this situation. Hmmm I'm seeing the RC2 jars just fine. Take a look here at the core jar for example: http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/ Also MINA stuff is here: http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/ HTH, Alex 2006/4/24, Alex Karasulu [EMAIL PROTECTED]: Aaron Mulder wrote: I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. Ya all including RC1 should be in the M2 repo if not let me know. Alex Thanks, Aaron On 4/24/06, Jeff Genender [EMAIL PROTECTED] wrote: Alex, Can you get the jars in ibiblio and I can get the integration going? I am only seeing 0.9.2 in ibiblio at the moment. Thanks, Jeff Alex Karasulu wrote: Jeff Genender wrote: If the changes are not huge, I can probably do it. Alex, are the updates significant? Since 0.9.2 I'd say RC1 is a significant update. There are package name changes to comply with Directory's TLP domain name which are perhaps the most significant changes. There are changes to a couple dependencies. For the most part the code has been cleaned up and several *severe* bugs have been corrected and tested. RC1 is also an order of magnitude faster. We plan to get another 1.0 release candidate (RC2) out soon perhaps by the end of this week coming week or week there after. But looking at emails out there from Dain and Aaron it sounds to me like the update to G can take place any time after the 1.1 release. Let us know if you have any problems or need a hand while performing an upgrade either to RC1 or RC2 when it comes out. Regards, Alex -- Alexei Zakharov, Intel Middleware Product Division
Commit configId to moduleId?
I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo- module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
Re: Apache Geronimo Principles Goals
Dain Sundstrom wrote: Sorry for the late reply. I have had these notes for days and just keep forgetting to post them. Notes in line... On Apr 23, 2006, at 8:07 PM, Aaron Mulder wrote: Apache Geronimo Principles Goals === Principles === How about stating these with heading words like Competitive, Flexiable, and Just Works that tie into the Goals section. This is kind of the executive summary... * Be competitive with other application servers * Be flexible to include exactly what a user wants (lightweight, heavyweight, I know it is the same thing, but I'd state it as only what a user wants and nothing more Probably nitpicky but I think only what a user needs. There could be wierd dependencies that include more than a user wants. product integration, customized admin tools, etc.). Make it easy to get there from the initial download. flexiable enough to adapt to (almost) any operating environment. I thinking of university environments where 90% of the server install is shared and students get their own apps and logs dirs. Another one is ISVs with shared installations for customers. * Be the IntelliJ of app servers (it thinks like you do, works like you expect, etc.) -- alternately, be the OS X of app servers (easy to use and even the hard stuff just works) I would state this one as Just Works or Simple. The server should work as an average-joe would expect. If I throw a jar into web-inf/lib and restart my web app it should get picked up (it doesn't currently). Intuitive comes to mind. === Goals === Flexibility --- Geronimo should meet anyone's needs from very lightweight to very heavyweight. Generally, the distribution option should be: 1) Minimal -- kernel and command-line/script administration tools only 2) Web -- web container and web admin tools 3) J2EE -- certified J2EE stack with web admin tools 4) Installer -- select from the above canned solutions and customize +1...server templates :) The included tools must make it extremely easy to download and install additional features (e.g. plugins) to add on to the basic distribution. And, of course, anyone is free to create more comprehensive distributions by bundling plugins and distributing the resulting package. and changing the directory layout. It should be possible to get an app running and then have 1-click options to strip down the server to only what that application requires. It should also be possible to easily replicate a Geronimo installation to another machine (or to another existing Geronimo installation). It should also be possible to export an environment to run a J2EE application client in (ideally, export it as a dynamic Java Web Start configuration so you can just run it on your local PC by clicking a link in the console). This feature should be available via a utility, so a user can easily add a download a think-client button to their web application. I'd also add create an applet and create an installer options. We should define who we are talking about. For a single developer the above makes sense. Are the above tools adequate for the user that has 12,000 servers with some minor differences in deployment options? Performance Scalability - Performance must be comparable to other application servers in key areas. Geronimo should support clustering of web and EJB components for scalability and fail-over fault tolerance. Geronimo should work with common hardware load-balancers. Integration with load balancers would be a neat add-on. For instance when a server comes online it can interact with the load balancers to accept work / go offline. Benchmarks should be made available with clear instructions for users to configure and run them on Geronimo as well as on other application servers. There should be clear performance tuning guidelines, and the performance tuning options should be extremely accessible (e.g. provide a dashboard- style page with all the settings to tune a web application in one place along with recommendations for the various settings). Benchmarks we create should reflect real world applications. Application Portability --- It should be as easy as possible to port applications to Geronimo, meaning: to and from Geronimo - reduce the need for Geronimo-specific XML configuration files - simplify and minimize required settings in Geronimo-specific XML configuration files (e.g. eliminate nested namespaces, provide optimized file formats for common things like database pools, eliminate target names in references) - Isolate the application classpath from Server internals (Spring, logging) - Make common but non-standard code work (global JNDI lookups, etc.) - Support file layouts, config files, scripts, termininology from other popular application servers (or stay as similar as possible) - Provide conversion tools to
Re: Commit configId to moduleId?
I'll defer to the body of committers as to how important this is and if it should go into for 1.1. Personally I don't think it really matters what the name is. ModuleId has its own set of baggage and so will everything else. I'm more concerned about another disruptive change to the users which will eventually require them to change their plans. Even if we decide to provide a conversion utility to bridge the gap for now we'll eventually deprecate it and force them to change. My personal opinion is -0 and weould prefer to leave it alone. Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo-module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
Re: RELEASE-NOTES-1.1
Thanks for bringing this together Hernan. Let's get this kicked around over the weekend. Hernan Cunico wrote: Hi All, I put the RELEASE-NOTES-1.1 available on confluence so it will be easier for you to provide some input. It is based on the previous version and it needs a lot of work. Here are some of the areas where I'm hoping to gather and summarize your feedback * Future Road Map at a Glance * Significant Changes Since the 1.0 release * Overall Project Status * Significant Missing Features * Known issues Some of these will get more complete as we get closer to a release candidate but I will really like to start seeing your feedback earlier :) I also need your comments for the overall summary of changes that will go into the documentation, I can not include it if you do not provide input. Here is the link to the v1.1 documentation. http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation Cheers! Hernan
[jira] Updated: (GERONIMO-1889) Changing pooling parameters for connector does not persist to config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1889?page=all ] Paul McMahan updated GERONIMO-1889: --- Attachment: GERONIMO-1889.patch.2 Thanks to Aaron for the helpful suggestion on a better way to persist attributes. I was thrown off when working on the previous patch by the fact that using a proxy didn't help persist certain attributes. Turns out those attributes were not specified as manageable by their corresponding gbeans. Adding them to the gbean's manageable interfaces and then updating them from the console via a proxy fixed the problem. One problem remains, though, which is that the host and port attributes for activemq connectors don't persist correctly when changed from the console. I assume its because they are not specified as manageable in the activemq gbean. I will investigate further and open an activemq jira if necessary to get that fixed. Changing pooling parameters for connector does not persist to config.xml Key: GERONIMO-1889 URL: http://issues.apache.org/jira/browse/GERONIMO-1889 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector, kernel, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Paul McMahan Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-1889.patch, GERONIMO-1889.patch.2 To replicate: Open the console Select Database Pools Click the edit link to the right of System Datasource Change pool max size to 119 Click Save Click the edit link to the right of System Datasource Confirm that it shows a pool max size of 119 Shut down the server Grep config.xml for 119, it does not appear Start the server Edit the System Datasource again, confirm that the pool max size is NOT 119 Also need to check whether changing the data connection properties is persisted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1889) Changing pooling parameters for connector does not persist to config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1889?page=all ] Paul McMahan reassigned GERONIMO-1889: -- Assign To: Aaron Mulder (was: Paul McMahan) attached a new patch that implements your suggestion Changing pooling parameters for connector does not persist to config.xml Key: GERONIMO-1889 URL: http://issues.apache.org/jira/browse/GERONIMO-1889 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector, kernel, console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: GERONIMO-1889.patch, GERONIMO-1889.patch.2 To replicate: Open the console Select Database Pools Click the edit link to the right of System Datasource Change pool max size to 119 Click Save Click the edit link to the right of System Datasource Confirm that it shows a pool max size of 119 Shut down the server Grep config.xml for 119, it does not appear Start the server Edit the System Datasource again, confirm that the pool max size is NOT 119 Also need to check whether changing the data connection properties is persisted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Commit configId to moduleId?
On May 5, 2006, at 1:55 PM, Matt Hogstrom wrote: I'll defer to the body of committers as to how important this is and if it should go into for 1.1. Personally I don't think it really matters what the name is. ModuleId has its own set of baggage and so will everything else. I'm more concerned about another disruptive change to the users which will eventually require them to change their plans. Even if we decide to provide a conversion utility to bridge the gap for now we'll eventually deprecate it and force them to change. My personal opinion is -0 and weould prefer to leave it alone. We've already had a vote to change it, so the question is when. If Dain is willing to back out the change immediately if it doesn't look good in the tck, then I'm fine with it now. My $0.02 -David Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo- module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
[jira] Created: (SM-427) Additional CGI Headers for Http component
Additional CGI Headers for Http component - Key: SM-427 URL: https://issues.apache.org/activemq/browse/SM-427 Project: ServiceMix Type: Improvement Components: servicemix-components Environment: All Platform Reporter: Soumadeep Sen Attachments: HttpMarshaler.patch Additional CGI Headers in http component -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Commit configId to moduleId?
I agree we should change it to have minimal impact on users and ISVs in future geronimo releases. Hopefully future releases won't require major changes to the schema like in this release. Leaving it as is may cause confusion when docs, articles etc. for different versions uses different terminology. The earlier we change it, the less users will be impacted (as we will have more users using later releases). John Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo-module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
Re: Commit configId to moduleId?
I would say commit it, and if there are any major problems with the tck, then we back out, otherwise I would rather us fix it for the tck to pass and keep the change to use moduleId in 1.1. --jason On 5/5/06, David Blevins [EMAIL PROTECTED] wrote: On May 5, 2006, at 1:55 PM, Matt Hogstrom wrote: I'll defer to the body of committers as to how important this is and if it should go into for 1.1. Personally I don't think it really matters what the name is. ModuleId has its own set of baggage and so will everything else. I'm more concerned about another disruptive change to the users which will eventually require them to change their plans. Even if we decide to provide a conversion utility to bridge the gap for now we'll eventually deprecate it and force them to change. My personal opinion is -0 and weould prefer to leave it alone. We've already had a vote to change it, so the question is when. If Dain is willing to back out the change immediately if it doesn't look good in the tck, then I'm fine with it now. My $0.02 -David Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo- module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
[jira] Created: (GERONIMO-1993) Build failure during assembly of j2ee-installer
Build failure during assembly of j2ee-installer --- Key: GERONIMO-1993 URL: http://issues.apache.org/jira/browse/GERONIMO-1993 Project: Geronimo Type: Bug Security: public (Regular issues) Components: installer Versions: 1.1 Environment: Win XP Reporter: Anita Kulshreshtha Priority: Minor Fix For: 1.1 The build is failing during the assembly of j2ee-installer. The installer still allows the jsp-examples-* and servlet-examples-* cars to be installed in the server repository. The other servers i.e. j2ee-*-server do not install these configurations anymore. We should remove these from the installer as well. This may not be an issue on linux machines. .. [java] Adding resource: ImgPacksPanel.img.17 [java] Adding resource: ImgPacksPanel.img.18 [java] Adding resource: ImgPacksPanel.img.19 [java] Adding resource: ImgPacksPanel.img.20 [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InstallPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ProcessPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InfoPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/FinishPanel.jar [java] - Fatal error : [java] D:\X\geronimo\geronimo-1.1\assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/ geronimo-izpack.xml:96: D:\X\geronimo\geronimo-1.1\assemblies\j2ee-installer\target\geronimo-1.1 -SNAPSHOT\repository\geronimo\jsp-examples-tomcat\1.1-SNAPSHOT\jsp-examples-tomcat-1.1-SNAPSHOT.car\ WEB-INF\classes\org\apache\jsp\jsp2\jspattribute\shuffle_jsp$shuffle_jspHelper.class [java] com.izforge.izpack.compiler.CompilerException:
Re: Commit configId to moduleId?
Sounds like the consensus is to change it (although I don't remember a formal vote although I do remember the discussion). For my part it sounds like we're changing the configId to moduleId to decrease confusion. It seems odd that the modules are called CARs (Configuration Archives) or some such thing. I think we're making the server more confusing because now less things actually line up from a naming perspective. It just doesn't feel like we're giving our users a lot of stability. As David said, Just my $0.02. I would like to see more input from people though. I've been travelling so I must have missed the vote to put it in. Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo-module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
Re: Commit configId to moduleId?
Dave, thanks for the reminder of the vote. I was thinking in terms of Dain's first note in this chain. I believe I voted +1 in that original moduleId thread. After considering this further I'm revising my opinion as I don't think we're solving the problem; just creating new ones. I think I'd be more in favor of making the terminology consistent throughout the server but that is more than can be contained in 1.1. Regardless, let's hear from Kevan. Thanks for keeping me honest :) Matt David Blevins wrote: On May 5, 2006, at 1:55 PM, Matt Hogstrom wrote: I'll defer to the body of committers as to how important this is and if it should go into for 1.1. Personally I don't think it really matters what the name is. ModuleId has its own set of baggage and so will everything else. I'm more concerned about another disruptive change to the users which will eventually require them to change their plans. Even if we decide to provide a conversion utility to bridge the gap for now we'll eventually deprecate it and force them to change. My personal opinion is -0 and weould prefer to leave it alone. We've already had a vote to change it, so the question is when. If Dain is willing to back out the change immediately if it doesn't look good in the tck, then I'm fine with it now. My $0.02 -David Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo-module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
Re: Commit configId to moduleId?
I'd be happy if we never ended up calling any file a .[a-zA-Z]ar. I think that the ear/war/rar thing is lame to start with, the folks that continue to use the same lame extension naming system (sar, har, dar, car) just perpetuate this silly system that Sun dropped on us. If we need to use extensions to clarify what something is, then lets use something more sensible. Like for a module, why not just use .module? If you want to still say its a jar, then .module.jar, but please lets not make it a .mar. --jason On May 5, 2006, at 7:40 PM, Matt Hogstrom wrote: Sounds like the consensus is to change it (although I don't remember a formal vote although I do remember the discussion). For my part it sounds like we're changing the configId to moduleId to decrease confusion. It seems odd that the modules are called CARs (Configuration Archives) or some such thing. I think we're making the server more confusing because now less things actually line up from a naming perspective. It just doesn't feel like we're giving our users a lot of stability. As David said, Just my $0.02. I would like to see more input from people though. I've been travelling so I must have missed the vote to put it in. Dain Sundstrom wrote: I think now is the time to discuss if we want to commit the change from configId to moduleId. If we decide to commit the patch, the timing of the actual commit will be determined by Kevan to have the smallest impact on the TCK. The patch makes the following changes: o Renamed root element from configuration to module o Renamed environment element from configId to moduleId o Renamed schema from geronimo-config-1.1.xsd to geronimo- module-1.1.xsd Based on conversations over the past few days, I think we all agree that configuration is a poor name choice, and we want to change it. I also think that we all agree that if we are going to make the change we should change the xml schemas before 1.1 ships to have minimal impact on users (we already have schema changes going into 1.1). Should we commit? -dain
[jira] Assigned: (GERONIMO-1640) Upgrade to Tomcat 5.5.15
[ http://issues.apache.org/jira/browse/GERONIMO-1640?page=all ] Kevan Miller reassigned GERONIMO-1640: -- Assign To: Kevan Miller (was: Jeff Genender) Upgrade to Tomcat 5.5.15 Key: GERONIMO-1640 URL: http://issues.apache.org/jira/browse/GERONIMO-1640 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: Tomcat Versions: 1.0 Reporter: Jeff Genender Assignee: Kevan Miller Priority: Critical Fix For: 1.x Upgrading to Tomcat 5.5.15 due to bug in 5.5.12. WIll keep this issue open for a while to track issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1640) Upgrade to Tomcat 5.5.15
[ http://issues.apache.org/jira/browse/GERONIMO-1640?page=all ] Kevan Miller resolved GERONIMO-1640: Fix Version: 1.1 (was: 1.x) Resolution: Fixed Upgraded Tomcat and Jasper versions to 5.5.15 for Geronimo and OpenEJB. New version of Jasper added a development option which provides additional debugging information on error scenarios. However, this feature must be disabled for compliant jsp behavior... Committed revision 400233 Upgrade to Tomcat 5.5.15 Key: GERONIMO-1640 URL: http://issues.apache.org/jira/browse/GERONIMO-1640 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: Tomcat Versions: 1.0 Reporter: Jeff Genender Assignee: Kevan Miller Priority: Critical Fix For: 1.1 Upgrading to Tomcat 5.5.15 due to bug in 5.5.12. WIll keep this issue open for a while to track issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1994) geronimo-installer-1.1-SNAPSHOT.jar cannot be launched
geronimo-installer-1.1-SNAPSHOT.jar cannot be launched -- Key: GERONIMO-1994 URL: http://issues.apache.org/jira/browse/GERONIMO-1994 Project: Geronimo Type: Bug Security: public (Regular issues) Components: installer Versions: 1.1 Reporter: John Sisson Priority: Blocker Fix For: 1.1 If I double click on the geronimo-installer-1.1-SNAPSHOT.jar file in Windows XP, I get the error: Java Virtual Machine Launcher Could not find the main class. Program will exit! This appears to be due to the jar missing the META-INF/Manifest.mf that identifies the startup class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Wiki has moved
Just a heads up; we've finally moved off the codehaus wiki installation to a new confluence install here http://goopen.org/confluence/display/ACTIVEMQ/Home So please use this wiki for all future edits; I've just made the old codehaus wiki read-only. We've got Pier's Auto-Export plugin working so we can generate static HTML from the wiki... http://activemq.goopen.org/home.html it needs a bit of tweaking but we should have it all sorted soon to generate a nice static HTML apache website from this wiki. -- James --- http://radio.weblogs.com/0112098/
Re: Wiki has moved
James Strachan wrote: Just a heads up; we've finally moved off the codehaus wiki installation to a new confluence install here http://goopen.org/confluence/display/ACTIVEMQ/Home So please use this wiki for all future edits; I've just made the old codehaus wiki read-only. We've got Pier's Auto-Export plugin working so we can generate static HTML from the wiki... http://activemq.goopen.org/home.html it needs a bit of tweaking but we should have it all sorted soon to generate a nice static HTML apache website from this wiki. -- James --- http://radio.weblogs.com/0112098/ Who is hosting this site so we know who to contact in case of problems? John
Re: Wiki has moved
On 5/5/06, John Sisson [EMAIL PROTECTED] wrote: James Strachan wrote: Just a heads up; we've finally moved off the codehaus wiki installation to a new confluence install here http://goopen.org/confluence/display/ACTIVEMQ/Home So please use this wiki for all future edits; I've just made the old codehaus wiki read-only. We've got Pier's Auto-Export plugin working so we can generate static HTML from the wiki... http://activemq.goopen.org/home.html it needs a bit of tweaking but we should have it all sorted soon to generate a nice static HTML apache website from this wiki. -- James --- http://radio.weblogs.com/0112098/ Who is hosting this site so we know who to contact in case of problems? Its currently hosted on a dedicated box in the LogicBlaze rack it should be all Nagios'd up shortly so it should get rebooted if confluence goes funny etc. Hopefully one day we can move this installation onto Apache hardware when the infrastructure team are happy to host confluence. In the meantime just ping the dev list if you hit any issues with the wiki. Hopefully soon we'll be able to sync the static HTML generated from the wiki with subversion etc. -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ 4.0 final release candidate recut
Looks great! The notice files licenses all look fine to me. The only minor nit right now is I can't run the activemq-web-demo and activemq-web-console from the binary distro due to the parent pom not downloading... http://www.rafb.net/paste/results/9SUFGr18.html On 5/5/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Folks, I have rebuild the final release candidate again. We are now including the activemq-web-demo and activemq-web-console projects in the example directory of the final distribution. Also we are now also will be publishing to a maven 2 repository in addition to the maven 1 repository. The https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/activemq tag has been updated. The binary distributions are now at: http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/incubator-activemq/distributions/ The maven 1 repository layout for this release is at: http://people.apache.org/~chirino/incubator-activemq-4.0/maven1/ The maven 2 repository layout for this release is at: http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/ -- Regards, Hiram -- James --- http://radio.weblogs.com/0112098/
Re: error in http-binding example
Could you try with 3.0-SNAPSHOT ? Cheers, Guillaume Nodet On 5/5/06, emicalc [EMAIL PROTECTED] wrote: Hello, I have this problem with HTPP-binding example (in servicemix-2.0.2); I start the service and then I start the client with ant command but there is the following error: D:\Program Files\servicemix-2.0.2\assembly\target\servicemix-2.0.2\bin\servicemi x-2.0.2\examples\http-bindingant Buildfile: build.xml init: compile: run: [echo] Running example client [java] Exception in thread main java.io.IOException: Server returned HTTP response code: 500 for URL: http://localhost:8912 [java] at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Ht tpURLConnection.java:1149) [java] at HttpClient.main(Unknown Source) [java] Java Result: 1 BUILD SUCCESSFUL Total time: 29 seconds D:\Program Files\servicemix-2.0.2\assembly\target\servicemix-2.0.2\bin\servicemi x-2.0.2\examples\http-bindingjava -version java version 1.5.0_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) thank's you -- View this message in context: http://www.nabble.com/error-in-http-binding-example-t1562542.html#a4243486 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: error in http-binding example
yes,..but I have this problem with 3.0 snapshot: http://www.nabble.com/servicemix-3.0-problem-t1555398.html Can you help me? -- View this message in context: http://www.nabble.com/error-in-http-binding-example-t1562542.html#a4243809 Sent from the ServiceMix - Dev forum at Nabble.com.
Wiki has moved!
Just a heads up; we've finally moved off the codehaus wiki installation to a new confluence install here http://goopen.org/confluence/display/SM/Home So please use this wiki for all future edits; I've just made the old codehaus wiki read-only. We've got Pier's Auto-Export plugin working so we can generate static HTML directly from the wiki so we should soon have a cleaner way to keep the static Apache site in sync with the wiki. If anyone has any issues with the wiki please ping the dev list. -- James --- http://radio.weblogs.com/0112098/
Re: error in http-binding example
One solution would be to download the binary distribution. Or just try to build the assembly without building the other modules. If you find any information on your problem, please report back, but I have no way to reproduce it ... Cheers, Guillaume Nodet On 5/5/06, emicalc [EMAIL PROTECTED] wrote: yes,..but I have this problem with 3.0 snapshot: http://www.nabble.com/servicemix-3.0-problem-t1555398.html Can you help me? -- View this message in context: http://www.nabble.com/error-in-http-binding-example-t1562542.html#a4243809 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Resolved: (SM-411) Uncomment https test in org.apache.servicemix.http.HttpSpringTest#testSsl and make it work
[ https://issues.apache.org/activemq/browse/SM-411?page=all ] Guillaume Nodet resolved SM-411: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Fri May 5 16:58:15 2006 New Revision: 400214 URL: http://svn.apache.org/viewcvs?rev=400214view=rev Log: SM-411 et SM-426: fix servicemix-http client side ssl support Modified: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/CommonsHttpSSLSocketFactory.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ProviderProcessor.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpSpringTest.java incubator/servicemix/trunk/servicemix-http/src/test/resources/org/apache/servicemix/http/spring.xml Uncomment https test in org.apache.servicemix.http.HttpSpringTest#testSsl and make it work -- Key: SM-411 URL: https://issues.apache.org/activemq/browse/SM-411 Project: ServiceMix Type: Test Components: servicemix-http Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-426) ProviderProcessor https connection fails
[ https://issues.apache.org/activemq/browse/SM-426?page=all ] Guillaume Nodet resolved SM-426: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Fri May 5 16:58:15 2006 New Revision: 400214 URL: http://svn.apache.org/viewcvs?rev=400214view=rev Log: SM-411 et SM-426: fix servicemix-http client side ssl support Modified: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/CommonsHttpSSLSocketFactory.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ProviderProcessor.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpSpringTest.java incubator/servicemix/trunk/servicemix-http/src/test/resources/org/apache/servicemix/http/spring.xml ProviderProcessor https connection fails Key: SM-426 URL: https://issues.apache.org/activemq/browse/SM-426 Project: ServiceMix Type: Bug Components: servicemix-http Versions: 3.0 Environment: Windows XP Reporter: Kevin Bouchard Assignee: Guillaume Nodet Fix For: 3.0-M2 Original Estimate: 1 minute Remaining: 1 minute The trustStorePassword is not set correctly at service assembly startup, precisely when the CommonsHttpSSLSocketFactory is created. This issue cause a NullPointerException to be thrown when the trustStore location is not set in the classpath of the application. Once this problem is fixed, the connection still fails. The reason is that the CommonsHttpSSLSocketFactory is not called when the socket is to be created. The DefaultSSLSocketFactory is called instead since Protocol.registerProtocol(https,protocol) function is missing at service assembly startup. This cause a SocketException to be thrown with reason password can't be null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
