[jira] Created: (GERONIMO-4118) Deployer GShell commands do not support offline deployment
Deployer GShell commands do not support offline deployment -- Key: GERONIMO-4118 URL: https://issues.apache.org/jira/browse/GERONIMO-4118 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: commands Affects Versions: 2.1.x, 2.2 Reporter: Jarek Gawor Deployer GShell commands do not support offline deployment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Sat, Feb 10, 2007 at 03:02:54PM -0800, David Jencks wrote: Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Hi folks, Sorry to resurrect an old thread but I was curious what's up with this. I just got a spiffy new PC which led to some poking around in the offline deployer code to find out why there's 10s of dead air everytime I run an offline deployment command. Turns out that it's in the active MQ code - there are two connections and for some reason each connection shutdown sits for ~5s. But that leads to a different question, which is why does the offline deployer tool start active MQ? I found that when the OfflineDeployerStarter.startPersistentOfflineConfigurations() method starts the openejb-deployer config a whole mess of other things start, including active MQ. This is where I start to lose the trail. In the openejb-deployer there are some module/gbean/xml-attribute/environment/dependencies, which in this case are openejb, openejb-core, geronimo-openejb, and system-database, but I don't see active MQ. Is active MQ a dependency of one of these dependencies? I guess that offline deployment isn't a popular feature so I don't expect this to be a high priority issue but I think there was consensus back in February that this should be fixed before the thread went cold. I'll help if I can, but I'm at the limits of my Geronimo knowledge so pointers would be appreciated. Thanks, Toby
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
I think this is a very important issue and I apologize for letting it slide under my radar. I still don't know enough about openejb3 to know how to fix it myself. I guess I think the release notes for 2.0 should include a warning saying that use of the offline deployer for ejb apps is not advised. It's pretty easy to see why activemq is being started: openejb-deployer needed to deploy your ejb app openejb-deployer requires openejb (runtime) to be running in order to work (this is the problem) openejb requires activemq (I imagine this is basically for convenience, but I don't actually know how tied openejb is to a particular jms implementation (amq)) thanks for bringing this up again. david jencks On Aug 3, 2007, at 12:07 PM, toby cabot wrote: On Sat, Feb 10, 2007 at 03:02:54PM -0800, David Jencks wrote: Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Hi folks, Sorry to resurrect an old thread but I was curious what's up with this. I just got a spiffy new PC which led to some poking around in the offline deployer code to find out why there's 10s of dead air everytime I run an offline deployment command. Turns out that it's in the active MQ code - there are two connections and for some reason each connection shutdown sits for ~5s. But that leads to a different question, which is why does the offline deployer tool start active MQ? I found that when the OfflineDeployerStarter.startPersistentOfflineConfigurations() method starts the openejb-deployer config a whole mess of other things start, including active MQ. This is where I start to lose the trail. In the openejb-deployer there are some module/gbean/xml-attribute/environment/dependencies, which in this case are openejb, openejb-core, geronimo-openejb, and system-database, but I don't see active MQ. Is active MQ a dependency of one of these dependencies? I guess that offline deployment isn't a popular feature so I don't expect this to be a high priority issue but I think there was consensus back in February that this should be fixed before the thread went cold. I'll help if I can, but I'm at the limits of my Geronimo knowledge so pointers would be appreciated. Thanks, Toby
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
Thanks for the info, David, and the quick response. I've monkeyed around a little more and it looks as if the axis-deployer, axis2-deployer and cxf-deployer also start active MQ as a side effect. Evidently my application doesn't use any of these features because I can disable them in deployer-config.xml (and add j2ee-system which appears to be necessary) and the offline deployer still deploys my application just fine and runs a *lot* faster. If you'd like I'll log a bug with this info. Thanks again, Toby
[jira] Updated: (GERONIMO-2765) Offline deployment broken in geronimo-tomcat-j2ee-1.2-SNAPSHOT
[ https://issues.apache.org/jira/browse/GERONIMO-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2765: --- Affects Version/s: (was: 1.1.2) 1.2 Fix Version/s: (was: 1.1.2) Offline deployment broken in geronimo-tomcat-j2ee-1.2-SNAPSHOT --- Key: GERONIMO-2765 URL: https://issues.apache.org/jira/browse/GERONIMO-2765 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.2 Environment: All Reporter: Leonard Flournoy Steps to reproduce offline deployment failure with geronimo-tomcat-j2ee configuration of Geronimo 1.2. 1. Display OS Java version information: $ cat /proc/version Linux version 2.6.9-42.0.3.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 SMP Mon Sep 25 17:28:02 EDT 2006 $ java -version java version 1.5.0_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) Java HotSpot(TM) Server VM (build 1.5.0_09-b03, mixed mode) 2. Check out geronimo v1.2 display version information: $ svn checkout https://svn.apache.org/repos/asf/geronimo/server/branches/1.2 geronimo-1.2 $ svn info Path: . URL: https://svn.apache.org/repos/asf/geronimo/server/branches/1.2 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 498232 ... 3. Build: $ cd geronimo-1.2 $ mvn clean install 4. Extract geronimo-tomcat-j2ee-1.2-SNAPSHOT-bin.tar.gz: $ cd ~ $ tar -xzf geronimo-1.2/assemblies/geronimo-tomcat-j2ee/target/geronimo-tomcat-j2ee -1.2-SNAPSHOT-bin.tar.gz 5. Start geronimo (to confirm a working installation): $ cd geronimo-tomcat-j2ee-1.2-SNAPSHOT $ bin/geronimo.sh start 6. Perform online deployment/undeployment: $ bin/deploy.sh deploy ~/wasce_samples/applications/hello/target/hello-1.1.1.war ~/wasce_samples/applications/hello/target/hello-1.1.1-web.xml $ bin/deploy.sh undeploy wasce-samples/hello//war 7. Stop Geronimo: $ bin/geronimo.sh stop 8. Attempt an offline deployment (war file and deployment plan attached): $ bin/deploy.sh --offline deploy ~/wasce_samples/applications/hello/target/hello-1.1.1.war ~/wasce_samples/applications/hello/target/hello-1.1.1-web.xml Using GERONIMO_BASE: /home/eric/geronimo-tomcat-j2ee-1.2-SNAPSHOT Using GERONIMO_HOME: /home/eric/geronimo-tomcat-j2ee-1.2-SNAPSHOT Using GERONIMO_TMPDIR: /home/eric/geronimo-tomcat-j2ee-1.2-SNAPSHOT/var/temp Using JRE_HOME:/usr/java/jdk1.5.0_09/jre Exception in thread main java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/ModuleConfigurer at org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConnect ion.java:207) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:15 7) at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:314) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3183. -- fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Assignee: Donald Woods Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Should DisconnectedDeploymentManager allow offline deployment?
The distribute method of the DisconnectedDeploymentManager returns an IllegalStateException. Should this still remain a restriction with the new offline deployment support? Or is there much more additional work required to support offline deployment through JSR88? thx -sachin
Re: Should DisconnectedDeploymentManager allow offline deployment?
no, I didn't read the spec.. I just assumed it was optional or something, rather then a spec violation. No I don't think it is currently using it. thx -sachin On May 23, 2007, at 11:33 AM, David Jencks wrote: Have you checked the specs on the disconnected deployment manager? IIRC by spec it can't deploy, distribute, undeploy, redeploy. or do anything except give you access to the DConfigBeans. In particular the offline deployer should not be trying to use a disconnected deployment manager. Is it currently? thanks david jencks On May 23, 2007, at 6:33 AM, Sachin Patel wrote: The distribute method of the DisconnectedDeploymentManager returns an IllegalStateException. Should this still remain a restriction with the new offline deployment support? Or is there much more additional work required to support offline deployment through JSR88? thx -sachin
Re: Should DisconnectedDeploymentManager allow offline deployment?
Have you checked the specs on the disconnected deployment manager? IIRC by spec it can't deploy, distribute, undeploy, redeploy. or do anything except give you access to the DConfigBeans. In particular the offline deployer should not be trying to use a disconnected deployment manager. Is it currently? thanks david jencks On May 23, 2007, at 6:33 AM, Sachin Patel wrote: The distribute method of the DisconnectedDeploymentManager returns an IllegalStateException. Should this still remain a restriction with the new offline deployment support? Or is there much more additional work required to support offline deployment through JSR88? thx -sachin
[jira] Created: (GERONIMO-3183) fix offline deployment in minimal configurations
fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Fix For: 2.0-M6 The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497916 ] toby cabot commented on GERONIMO-3183: -- Chunks 5-8 fix these stack traces. They're unlikely to appear in normal operations but might be seen during development: [EMAIL PROTECTED]:/download$ geronimo-jetty6-minimal-2.0-SNAPSHOT/bin/deploy.sh -o list-modules Using GERONIMO_BASE: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_HOME: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/java/jdk1.6.0_01/jre Error: Unable to query modules javax.enterprise.deploy.spi.exceptions.TargetException at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:175) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getRunningModules(JMXDeploymentManager.java:136) at org.apache.geronimo.deployment.cli.CommandListModules.execute(CommandListModules.java:63) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: java.lang.NullPointerException at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:149) ... 6 more ... and ... [EMAIL PROTECTED]:/download$ geronimo-jetty6-minimal-2.0-SNAPSHOT/bin/deploy.sh -o list-targets Using GERONIMO_BASE: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_HOME: /download/geronimo-jetty6-minimal-2.0-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/usr/java/jdk1.6.0_01/jre Available Targets: Exception in thread main java.lang.NullPointerException at org.apache.geronimo.deployment.cli.CommandListTargets.execute(CommandListTargets.java:37) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102
[jira] Updated: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3183: - Attachment: minimal-offline-patch.txt This patch makes a few changes. The most important are to add persistence-jpa10-deployer to the minimal assembly pom.xml files, add the j2ee-system config to the offline-deployer-config.xml files and sync the jetty and tomcat offline-deployer-config.xml files. Along the way I fixed some stack traces caused when no modules or targets can be found (which is not a typical condition) and improved the diagnostics when more than one ConfigurationManager is found (which is also not typical). fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3183: -- Assignee: Donald Woods fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Assigned To: Donald Woods Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498059 ] Donald Woods commented on GERONIMO-3183: When I apply the patch, I still cannot deploy the Servlet-Examples war to the minimal Tomcat assembly using deploy -o deploy servlet-examples-2.0-SNAPSHOT.war due to the persistant-jpa-deployer having a dependency on the openjpa config - Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.configs/openjpa//car fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Assigned To: Donald Woods Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498080 ] Donald Woods commented on GERONIMO-3183: Committed revision 540803 in trunk. Applied the second-half of the patch, which adds some improved diagnostics. Offline deployment still fails in the minimal assemblies for the Servlet examples war fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Assigned To: Donald Woods Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3183) fix offline deployment in minimal configurations
[ https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3183. Resolution: Fixed Regression: [Regression] Committed revision 540815 in trunk. Updated offline deplyer configs and verified that servlets-examples can be deployed to the minimal-tomcat assembly. The minimal configs no longer include the jpa10-deployer, as they did not include openjpa. Toby, thanks for testing this and supplying a patch. fix offline deployment in minimal configurations Key: GERONIMO-3183 URL: https://issues.apache.org/jira/browse/GERONIMO-3183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M6 Environment: Fedora Core 4 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Reporter: toby cabot Assigned To: Donald Woods Fix For: 2.0-M6 Attachments: minimal-offline-patch.txt The deployer's offline mode in the jetty6-minimal and tomcat6-minimal assemblies throws: org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration() at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120) at org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71) at org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102) at org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271) ... 19 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Feb 10, 2007, at 6:54 PM, David Blevins wrote: On Feb 10, 2007, at 3:02 PM, David Jencks wrote: The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Should be easy to fix. Is there an offline deployer somewhere I can update? The list of modules started for the offline deployer is in var/config/ offline-deployer.list, but gianny has a better way to run the offline deployer in the works. However, I don't see how that is relevant to my comment. The offline deployer shouldn't be starting runtime components, so the current offline-deployer-list should continue to be correct (as far as openejb goes anyway, maybe not cxf/axis2). Looking at the current openejb module plan I see that it won't open any ports but does require the transaction manager to start up which attempts full transaction recovery. This is really not appropriate for offline deployment. thanks david jencks -David
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Feb 11, 2007, at 4:04 PM, David Jencks wrote: On Feb 10, 2007, at 6:54 PM, David Blevins wrote: On Feb 10, 2007, at 3:02 PM, David Jencks wrote: The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Should be easy to fix. Is there an offline deployer somewhere I can update? The list of modules started for the offline deployer is in var/ config/offline-deployer.list, but gianny has a better way to run the offline deployer in the works. However, I don't see how that is relevant to my comment. Sorry, but I don't really get what to put what where. OpenEJB-wise, I can get you an online deployer and an offline deployer as fast as flicking a switch -- we support both. I'm just trying to understand what do to on the Geronimo side. We only have one config for an openejb-deployer. Do we want an online one (capable of adding containers etc based on the needs of the app) and an offline one or just an offline one or just an online one? I'm cool with whatever. -David
New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. thanks david jencks
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Feb 10, 2007, at 3:02 PM, David Jencks wrote: The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Should be easy to fix. Is there an offline deployer somewhere I can update? -David
[jira] Created: (GERONIMO-2765) Offline deployment broken in geronimo-tomcat-j2ee-1.2-SNAPSHOT
Offline deployment broken in geronimo-tomcat-j2ee-1.2-SNAPSHOT --- Key: GERONIMO-2765 URL: https://issues.apache.org/jira/browse/GERONIMO-2765 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 1.1.2 Environment: All Reporter: Leonard Flournoy Fix For: 1.1.2 Steps to reproduce offline deployment failure with geronimo-tomcat-j2ee configuration of Geronimo 1.2. 1. Display OS Java version information: $ cat /proc/version Linux version 2.6.9-42.0.3.ELsmp ([EMAIL PROTECTED]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)) #1 SMP Mon Sep 25 17:28:02 EDT 2006 $ java -version java version 1.5.0_09 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) Java HotSpot(TM) Server VM (build 1.5.0_09-b03, mixed mode) 2. Check out geronimo v1.2 display version information: $ svn checkout https://svn.apache.org/repos/asf/geronimo/server/branches/1.2 geronimo-1.2 $ svn info Path: . URL: https://svn.apache.org/repos/asf/geronimo/server/branches/1.2 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 498232 ... 3. Build: $ cd geronimo-1.2 $ mvn clean install 4. Extract geronimo-tomcat-j2ee-1.2-SNAPSHOT-bin.tar.gz: $ cd ~ $ tar -xzf geronimo-1.2/assemblies/geronimo-tomcat-j2ee/target/geronimo-tomcat-j2ee -1.2-SNAPSHOT-bin.tar.gz 5. Start geronimo (to confirm a working installation): $ cd geronimo-tomcat-j2ee-1.2-SNAPSHOT $ bin/geronimo.sh start 6. Perform online deployment/undeployment: $ bin/deploy.sh deploy ~/wasce_samples/applications/hello/target/hello-1.1.1.war ~/wasce_samples/applications/hello/target/hello-1.1.1-web.xml $ bin/deploy.sh undeploy wasce-samples/hello//war 7. Stop Geronimo: $ bin/geronimo.sh stop 8. Attempt an offline deployment (war file and deployment plan attached): $ bin/deploy.sh --offline deploy ~/wasce_samples/applications/hello/target/hello-1.1.1.war ~/wasce_samples/applications/hello/target/hello-1.1.1-web.xml Using GERONIMO_BASE: /home/eric/geronimo-tomcat-j2ee-1.2-SNAPSHOT Using GERONIMO_HOME: /home/eric/geronimo-tomcat-j2ee-1.2-SNAPSHOT Using GERONIMO_TMPDIR: /home/eric/geronimo-tomcat-j2ee-1.2-SNAPSHOT/var/temp Using JRE_HOME:/usr/java/jdk1.5.0_09/jre Exception in thread main java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/ModuleConfigurer at org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConnect ion.java:207) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:15 7) at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:314) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: offline deployment with deploy distribute?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: lundi 13 février 2006 23:04 To: dev@geronimo.apache.org Subject: Re: offline deployment with deploy distribute? Well, I should mention that you can dump the module in the hot deploy directory, which may be good enoguh to get you going for now. Currently we don't notice if you dumped a *newer* copy of the file in there while the server was down, but if it's a new deployment it'll get deployed next time the server starts. The down side is we don't validate anything when you copy it in there, only when the server starts up and attempts the deployment. Ok that explains a few things! Thanks for mentioning it. Thanks -Vincent On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Aaron, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: lundi 13 février 2006 20:15 To: dev@geronimo.apache.org Subject: Re: offline deployment with deploy distribute? The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. I need a Java API for integrating it in Cargo. Right now one integration pain is that it's not possible to relocate the location of the var/ directory. David Jencks made a proposal on this list last week but I don't know if it has progressed much since then. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm pretty sure you'll have users ask for this. It's useful in situation where you need to prepare a container configuration and package it as part of your build for example. I know you guys are working on a packager that would create a G configuration but unfortunately the current implementation is using Maven1 and is not easily reusable in Java code. If you had a pure java implementation independent of Maven that would help a lot. In any case all containers do support offline deployments so I'm pretty sure G will have to provide that too in some manner. I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Kevan pointed me to http://issues.apache.org/jira/browse/GERONIMO-1507. Thanks -Vincent On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Re: offline deployment with deploy distribute?
On Mon, Feb 13, 2006 at 02:14:51PM -0500, Aaron Mulder wrote: I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Please see http://issues.apache.org/jira/browse/GERONIMO-1507 for a start at an offline deploy tool based on David's Maven plugins. Haven't had much time to look into it recently but if there was at least one other person interested it would be easier to raise its priority level higher than Top Gear re-runs :) Toby
offline deployment with deploy distribute?
Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0-SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader-plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0-SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader-plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Re: offline deployment with deploy distribute?
The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Thanks, Aaron http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0-SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader-plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0-SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader-plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Re: offline deployment with deploy distribute?
Vincent, I don't wish to hijack this thread, but I thought the Cargo plugin doesn't yet support the containers that ships with Geronimo. The plugin for Tomcat 5.5.x needs JDK 1.5. I am interested in the work that you are doing with Cargo Geronimo. http://www.mail-archive.com/dev@geronimo.apache.org/msg17578.html Cheers Prasad On 2/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Thanks, Aaron http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0-SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader-plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0-SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader-plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Cargo and G (was RE: offline deployment with deploy distribute?)
Hi Prasad, -Original Message- From: Prasad Kashyap [mailto:[EMAIL PROTECTED] Sent: lundi 13 février 2006 20:39 To: dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: offline deployment with deploy distribute? Vincent, I don't wish to hijack this thread, but I thought the Cargo plugin doesn't yet support the containers that ships with Geronimo. The plugin for Tomcat 5.5.x needs JDK 1.5. I'm not sure what you mean by the containers that ships with Geronimo. AFAIK G supports Jetty 5.x and Tomcat 5.5.x. Cargo 0.7 supports Tomcat 5.5.x and only Jetty 4.x. However Cargo 0.8 supports Jetty 5.x and 6.x too (thanks to JanB). There are several ways to use Cargo: - through the Java API - through an extension: - Ant tasks - maven1 plugin - maven2 plugin - netbeans and IntelliJ IDEA plugins If you have found an issue with Tomcat 5.5.x please let us know on the Cargo lists! I am interested in the work that you are doing with Cargo Geronimo. http://www.mail-archive.com/dev@geronimo.apache.org/msg17578.html Very cool. I had missed that email. I'd love to provide all the help require for you to use Cargo. Make sure you talk to the Cargo team on the mailing lists. You'll find us very open to helping and collaborating. Thanks -Vincent On 2/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Thanks, Aaron http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
RE: offline deployment with deploy distribute?
Hi Aaron, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: lundi 13 février 2006 20:15 To: dev@geronimo.apache.org Subject: Re: offline deployment with deploy distribute? The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. I need a Java API for integrating it in Cargo. Right now one integration pain is that it's not possible to relocate the location of the var/ directory. David Jencks made a proposal on this list last week but I don't know if it has progressed much since then. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm pretty sure you'll have users ask for this. It's useful in situation where you need to prepare a container configuration and package it as part of your build for example. I know you guys are working on a packager that would create a G configuration but unfortunately the current implementation is using Maven1 and is not easily reusable in Java code. If you had a pure java implementation independent of Maven that would help a lot. In any case all containers do support offline deployments so I'm pretty sure G will have to provide that too in some manner. I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Kevan pointed me to http://issues.apache.org/jira/browse/GERONIMO-1507. Thanks -Vincent On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Re: offline deployment with deploy distribute?
Well, I should mention that you can dump the module in the hot deploy directory, which may be good enoguh to get you going for now. Currently we don't notice if you dumped a *newer* copy of the file in there while the server was down, but if it's a new deployment it'll get deployed next time the server starts. The down side is we don't validate anything when you copy it in there, only when the server starts up and attempts the deployment. Aaron On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Aaron, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: lundi 13 février 2006 20:15 To: dev@geronimo.apache.org Subject: Re: offline deployment with deploy distribute? The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. I need a Java API for integrating it in Cargo. Right now one integration pain is that it's not possible to relocate the location of the var/ directory. David Jencks made a proposal on this list last week but I don't know if it has progressed much since then. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm pretty sure you'll have users ask for this. It's useful in situation where you need to prepare a container configuration and package it as part of your build for example. I know you guys are working on a packager that would create a G configuration but unfortunately the current implementation is using Maven1 and is not easily reusable in Java code. If you had a pure java implementation independent of Maven that would help a lot. In any case all containers do support offline deployments so I'm pretty sure G will have to provide that too in some manner. I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Kevan pointed me to http://issues.apache.org/jira/browse/GERONIMO-1507. Thanks -Vincent On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Re: Cargo and G (was RE: offline deployment with deploy distribute?)
Vincent, That's excellent. I guess the Container support on the Cargo home site is not updated yet. That's fine. So similar to Tomcat 5.5.x container support, does v0.8 impose a requirement of JDK 1.5 while using goals for Jetty 5.x ? Cheers Prasad On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Prasad, -Original Message- From: Prasad Kashyap [mailto:[EMAIL PROTECTED] Sent: lundi 13 février 2006 20:39 To: dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: offline deployment with deploy distribute? Vincent, I don't wish to hijack this thread, but I thought the Cargo plugin doesn't yet support the containers that ships with Geronimo. The plugin for Tomcat 5.5.x needs JDK 1.5. I'm not sure what you mean by the containers that ships with Geronimo. AFAIK G supports Jetty 5.x and Tomcat 5.5.x. Cargo 0.7 supports Tomcat 5.5.x and only Jetty 4.x. However Cargo 0.8 supports Jetty 5.x and 6.x too (thanks to JanB). There are several ways to use Cargo: - through the Java API - through an extension: - Ant tasks - maven1 plugin - maven2 plugin - netbeans and IntelliJ IDEA plugins If you have found an issue with Tomcat 5.5.x please let us know on the Cargo lists! I am interested in the work that you are doing with Cargo Geronimo. http://www.mail-archive.com/dev@geronimo.apache.org/msg17578.html Very cool. I had missed that email. I'd love to provide all the help require for you to use Cargo. Make sure you talk to the Cargo team on the mailing lists. You'll find us very open to helping and collaborating. Thanks -Vincent On 2/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Thanks, Aaron http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
RE: Cargo and G (was RE: offline deployment with deploy distribute?)
-Original Message- From: Prasad Kashyap [mailto:[EMAIL PROTECTED] Sent: lundi 13 février 2006 23:08 To: Vincent Massol Cc: dev@geronimo.apache.org Subject: Re: Cargo and G (was RE: offline deployment with deploy distribute?) Vincent, That's excellent. I guess the Container support on the Cargo home site is not updated yet. That's fine. Yep we're a bit late. BTW if you want to use the latest cargo snapshots you can get them from the Cargo m2 repository on: http://cargo.codehaus.org/dist2-snapshot/ So similar to Tomcat 5.5.x container support, does v0.8 impose a requirement of JDK 1.5 while using goals for Jetty 5.x ? AFAIK Jetty 5.x runs with JDK 1.4. -Vincent On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Prasad, -Original Message- From: Prasad Kashyap [mailto:[EMAIL PROTECTED] Sent: lundi 13 février 2006 20:39 To: dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: offline deployment with deploy distribute? Vincent, I don't wish to hijack this thread, but I thought the Cargo plugin doesn't yet support the containers that ships with Geronimo. The plugin for Tomcat 5.5.x needs JDK 1.5. I'm not sure what you mean by the containers that ships with Geronimo. AFAIK G supports Jetty 5.x and Tomcat 5.5.x. Cargo 0.7 supports Tomcat 5.5.x and only Jetty 4.x. However Cargo 0.8 supports Jetty 5.x and 6.x too (thanks to JanB). There are several ways to use Cargo: - through the Java API - through an extension: - Ant tasks - maven1 plugin - maven2 plugin - netbeans and IntelliJ IDEA plugins If you have found an issue with Tomcat 5.5.x please let us know on the Cargo lists! I am interested in the work that you are doing with Cargo Geronimo. http://www.mail-archive.com/dev@geronimo.apache.org/msg17578.html Very cool. I had missed that email. I'd love to provide all the help require for you to use Cargo. Make sure you talk to the Cargo team on the mailing lists. You'll find us very open to helping and collaborating. Thanks -Vincent On 2/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: The offline option has gone away for 1.0. There are Maven tasks you can use to start the server, deploy some stuff, and then shut the server down again -- not sure if that would work for you. There was talk about creating a dedicated offline development tool, but I don't think it's been a super-high priority. Of course, having more use cases helps motivate things like that. :) I'm not sure if there's a JIRA for this or not -- if you get a chance, can you review the JIRAs in the deployment category and see if there's one discussing offline deployment and if not add one and describe why you need it? Thanks, Aaron http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220 On 2/13/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi, Still working on the G integration in Cargo. I need to find a way to deploy an archive before the container is started. I read on http://tinyurl.com/8dfxj that I should use the distribute command with the --offline option. I'm using G 1.0 and it's failing: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar --offline distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: No such command: '--offline' Command-line deployer syntax: deployer [general options] command [command options] [...] If I don't use --offline I get: C:\apps\geronimo-1.0-tomcat\binjava -jar deployer.jar distribute C:\dev\m2book\code\j2ee\daytrader\ear\target\daytrader-ear-1.0- SNAPSHOT.ear C:\dev\m2book\code\j2ee\daytrader\ear\src\main\deployment\dayTrader- plan.xml Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused: connect] Any idea? Is the --offline option supported in G 1.0? Thanks -Vincent
Re: offline deployment - status
I've made some progress on this and it seems to work OK for basic j2ee deployments, except for the problem below. It's not pretty but it does what I need for the time being. If anyone else is interested in this I could clean it up and post it to the list, and if anyone's got a tip about the problem below I'd be mucho grateful. On Tue, Jan 10, 2006 at 02:01:08PM -0500, toby cabot wrote: It's all good until the code reaches the SwitchingModuleBuilder, which is configured by default to deploy to Tomcat, so since I'm using Jetty it fails to find a builder and I get foo.war is not a war messages. It looks as if SwitchingModuleBuilder's defaultNamespace is overridden in assemblies/j2ee-jetty-server's config.xml, but I'm not clear on how to override this parameter when I'm in a command-line environment. I'm not even clear on how this gets overridden when the plugin is run in a configs/*-jetty directory. Pointers appreciated. Thanks, Toby
Re: offline deployment - status
On Jan 19, 2006, at 12:46 PM, toby cabot wrote: I've made some progress on this and it seems to work OK for basic j2ee deployments, except for the problem below. It's not pretty but it does what I need for the time being. If anyone else is interested in this I could clean it up and post it to the list, and if anyone's got a tip about the problem below I'd be mucho grateful. I'd really appreciate it if you would open a jira and keep your progress posted as patches to it. On Tue, Jan 10, 2006 at 02:01:08PM -0500, toby cabot wrote: It's all good until the code reaches the SwitchingModuleBuilder, which is configured by default to deploy to Tomcat, so since I'm using Jetty it fails to find a builder and I get foo.war is not a war messages. It looks as if SwitchingModuleBuilder's defaultNamespace is overridden in assemblies/j2ee-jetty-server's config.xml, but I'm not clear on how to override this parameter when I'm in a command-line environment. I'm not even clear on how this gets overridden when the plugin is run in a configs/*-jetty directory. Pointers appreciated. I'm not sure I have the whole context here, but basically you should use the web container specific plan namespaces to point out which container you want to target. This is what we do in the configs, so there is a daytrader-jetty, a daytrader-tomcat, etc etc etc. If this doesn't answer your question right away please explain further :-) thanks david jencks Thanks, Toby
Re: offline deployment?
On Wed, Jan 04, 2006 at 10:12:00AM -0800, David Jencks wrote: Unless someone twists my arm severely I was planning on looking at this again after 2 other items, jetspeed integration and a transaction manager patch: if you wanted to get started on this first I'd be very happy :-). I've started messing around with this and hit a snag. I've made a new jar called offline.jar that's pretty much a clone of the existing deployer.jar 'cept it runs a different main class, which itself is pretty much a clone of the existing deployer main class. It's all good until the code reaches the SwitchingModuleBuilder, which is configured by default to deploy to Tomcat, so since I'm using Jetty it fails to find a builder and I get foo.war is not a war messages. It looks as if SwitchingModuleBuilder's defaultNamespace is overridden in assemblies/j2ee-jetty-server's config.xml, but I'm not clear on how to override this parameter when I'm in a command-line environment. I'm not even clear on how this gets overridden when the plugin is run in a configs/*-jetty directory. Pointers appreciated. Thanks, Toby
Re: offline deployment?
On Tue, Jan 03, 2006 at 03:58:55PM -0800, Dain Sundstrom wrote: Will the hot deployment directory satisfy you needs? I tried to think of an approach using hot deployment that would work, but none are as clean as offline deployment. But I'm probably a corner case: I use Geronimo embedded in a system with lots of other software around it, running in a sealed box rather than a typical PC-like environment. I cross-develop; with offline deployment I can distribute my application into Geronimo during the build process, then move it to a target machine and run it on a read-only partition. Of course I have to move various logs, etc to /var but that's easily done by tweaks to various plan.xml files. I've also done some experiments recently to allow Geronimo to have multiple config-stores so I can have my core software in read-only storage and deploy other stuff to /var. Using hot deployment would be much more complex as I'd have to modify the hot deployer to read from /var and deploy to a read-write config store. It also leaves a lot of processing to the target machines that currently happens on development machines. It's do-able but I like that with offline distribute my code is in a read-only config store so it can't be messed with. I've got a workaround with online distribution but it's a clumsier build process since I have to fire up the server, wait some arbitrary time for the deployer to become available, distribute, and shut down the server. I can probably live with that but offline distribution is much cleaner. I recognize that my requirements aren't typical so I'm happy to (as with multiple config stores) do some work to help make it happen. I just don't want to go off half-cocked and end up with something that's a crime against the Geronimo architecture. What do you think of the approach that I mentioned in my previous email? Am I barking up the right tree? Thanks, Toby
Re: offline deployment?
On Jan 3, 2006, at 7:34 AM, toby cabot wrote: Hi Folks, I guess it's possible that I'm the only person that used offline deployment, at least I don't see a lot of people clamoring to bring it back. It's very useful for me, though, so I'd like to find out if there's a possibility of bringing it back onto HEAD (and hopefully the 1.0 branch, too). I'll probably need to hack something for my needs but I'd just as soon do it in a way that's Geronimo-savvy. It's definitely something we need in some form. From discussion on this list it looks as if the preferred approach is to try to use the same approach that the build-time maven plugins do. From my naive reading of the code, it looks as if that happens in two passes: first the geronimo-packaging-plugin takes a deployable resource (ear, war, etc) and generates a configuration archive from that, then the geronimo-assembly-plugin moves the car into the ConfigurationStore. The configurations are mentioned in config.xml (hand-coded?) which causes them to get started when Geronimo runs. I see notes in the code that the packaging plugin uses the Maven repository, so in order to work on machines without Maven I imagine that we'd need to use the Geronimo repository instead. Is this more-or-less on the right track? I'd appreciate any tips or pointers, especially if I'm about to head off in the wrong direction. That's about right. I tried to make both the packaging and assembly plugins modular so that the class that does the work accepts arbitrary repository and config-store implementations so that all that is needed for the offline config-builder or assembler is to construct something using the geronimo repo and config store rather than the maven ones. My idea was to control these plugins primarily with a properties file, but allowing overrides using command line properties. I recall writing a primitive version of the command line packager but never tested it and I'm not sure if I committed it before my hard drive broke. Something similar should work for the assembler. One question I have about this is, where do the dependencies come from? The maven assembly plugin makes sure all the dependencies for the config are copied from the maven repo into the geronimo repo. I guess a command line version of this should fail if the dependencies aren't already in the repo? Or should it accept some other repo anyway? Or use a remote maven repo? I don't know. One missing piece that perhaps can be added to the assembly plugin as well is modification of config.xml. I suppose a good start would be to have a flag that indicates whether the config should be loaded or not, and, similarly to the online deployer, either add an element to config.xml or set load=true if the flag says to load the config. Unless someone twists my arm severely I was planning on looking at this again after 2 other items, jetspeed integration and a transaction manager patch: if you wanted to get started on this first I'd be very happy :-). Command line tools are not something I know how to make useable so I'm sure anything I came up with would need editing by others anyway. many thanks, david jencks Thanks, Toby
offline deployment?
Hi Folks, I guess it's possible that I'm the only person that used offline deployment, at least I don't see a lot of people clamoring to bring it back. It's very useful for me, though, so I'd like to find out if there's a possibility of bringing it back onto HEAD (and hopefully the 1.0 branch, too). I'll probably need to hack something for my needs but I'd just as soon do it in a way that's Geronimo-savvy. From discussion on this list it looks as if the preferred approach is to try to use the same approach that the build-time maven plugins do. From my naive reading of the code, it looks as if that happens in two passes: first the geronimo-packaging-plugin takes a deployable resource (ear, war, etc) and generates a configuration archive from that, then the geronimo-assembly-plugin moves the car into the ConfigurationStore. The configurations are mentioned in config.xml (hand-coded?) which causes them to get started when Geronimo runs. I see notes in the code that the packaging plugin uses the Maven repository, so in order to work on machines without Maven I imagine that we'd need to use the Geronimo repository instead. Is this more-or-less on the right track? I'd appreciate any tips or pointers, especially if I'm about to head off in the wrong direction. Thanks, Toby
Re: offline deployment?
Will the hot deployment directory satisfy you needs? -dain On Jan 3, 2006, at 7:34 AM, toby cabot wrote: Hi Folks, I guess it's possible that I'm the only person that used offline deployment, at least I don't see a lot of people clamoring to bring it back. It's very useful for me, though, so I'd like to find out if there's a possibility of bringing it back onto HEAD (and hopefully the 1.0 branch, too). I'll probably need to hack something for my needs but I'd just as soon do it in a way that's Geronimo-savvy. From discussion on this list it looks as if the preferred approach is to try to use the same approach that the build-time maven plugins do. From my naive reading of the code, it looks as if that happens in two passes: first the geronimo-packaging-plugin takes a deployable resource (ear, war, etc) and generates a configuration archive from that, then the geronimo-assembly-plugin moves the car into the ConfigurationStore. The configurations are mentioned in config.xml (hand-coded?) which causes them to get started when Geronimo runs. I see notes in the code that the packaging plugin uses the Maven repository, so in order to work on machines without Maven I imagine that we'd need to use the Geronimo repository instead. Is this more-or-less on the right track? I'd appreciate any tips or pointers, especially if I'm about to head off in the wrong direction. Thanks, Toby
[jira] Closed: (GERONIMO-1294) Remove offline deployment capabilities from deployer.jar
[ http://issues.apache.org/jira/browse/GERONIMO-1294?page=all ] David Jencks closed GERONIMO-1294: -- Resolution: Fixed Fixed in this possibly unnumbered revision Deleting modules/assembly Sendingmodules/deploy-tool/project.xml Deleting modules/deploy-tool/src/java/org/apache/geronimo/deployment/Bootstrap.java Deleting modules/deploy-tool/src/java/org/apache/geronimo/deployment/ShutdownBootstrap.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDeploy.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDistribute.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandListModules.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandListTargets.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandLogin.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandPackage.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandRedeploy.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandStart.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/DeployTool.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/ServerConnection.java Sending modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/StopServer.java Deleting modules/installer Transmitting file data svn: Commit succeeded, but other errors follow: svn: Error bumping revisions post-commit (details follow): update makes it look like Updated to revision 354830. Remove offline deployment capabilities from deployer.jar Key: GERONIMO-1294 URL: http://issues.apache.org/jira/browse/GERONIMO-1294 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.0 Attachments: offline-deploy.patch David asked for a patch that removes offline deployment from the deployer.jar tool. So, here it is. I haven't tested this since it breaks the assembly module, but hey, it looks right and compiles. :) -- 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-1294) Remove offline deployment capabilities from deployer.jar
Remove offline deployment capabilities from deployer.jar Key: GERONIMO-1294 URL: http://issues.apache.org/jira/browse/GERONIMO-1294 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M5 Reporter: Aaron Mulder Assigned to: David Jencks Fix For: 1.0 Attachments: offline-deploy.patch David asked for a patch that removes offline deployment from the deployer.jar tool. So, here it is. I haven't tested this since it breaks the assembly module, but hey, it looks right and compiles. :) -- 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-1294) Remove offline deployment capabilities from deployer.jar
[ http://issues.apache.org/jira/browse/GERONIMO-1294?page=all ] Aaron Mulder updated GERONIMO-1294: --- Attachment: offline-deploy.patch Remove offline deployment capabilities from deployer.jar Key: GERONIMO-1294 URL: http://issues.apache.org/jira/browse/GERONIMO-1294 Project: Geronimo Type: Improvement Components: deployment Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.0 Attachments: offline-deploy.patch David asked for a patch that removes offline deployment from the deployer.jar tool. So, here it is. I haven't tested this since it breaks the assembly module, but hey, it looks right and compiles. :) -- 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: online and offline deployment
Jeremy, What is your feeling on the package --install command? Because right now, that runs in offline mode, and assumes that it should install into a file-based local configuration store. Which means it's subject to all the problems you've raised if the server is not using a file-based local configuration store, etc. Of course we use this during server construction. But it might be best to start the server immediately after bootstrapping the deployer, and do all the rest of the server construction tasks as online deployments. (That would also have the pleasant side effect of making it all run faster, because you wouldn't be starting and stopping a kernel for every deployment.) Then the bootstrapping would be the only operation that actually installed in offline mode, and we could remove the unsafe --install option from the package command -- or actually make the package command perform the installation in online mode, if we have a deployment module that knows how to deploy a CAR file. Or better yet, have the package command run in reverse order -- first distribute the configuration into the running server, and then dump a CAR file from the configuration in the config store. I think someone raised some of these possibilities before, but I don't remember who. Aaron On Mon, 8 Nov 2004, Jeremy Boynes wrote: I argue that JSR-88 features such as start, stop, ... that are intended for online use do not work in offline mode and trying to implement them is resulting in an incomplete solution that will be problematic in all but the degenerate case. The plan to hack start based on a specific implementation of ConfigurationStore is indicative that there is something fundamentally wrong here. Aaron tried to implement the feature as planned, ran into a problem, and asked on the list if anyone minded if he hacked around it. I did, for reasons that have been explained. Can you take another look at the mails again and see if you can come up with a proposal that works? I would hate to waste another day writing a another mail that you do not understand. And despite the on-list conversations that make it pretty clear I think there are technical problems, to keep you happy here is a formal -1 veto on any implementation intended for general use that couples the standalone deployer to the implementation of the target server's config store or which requires the deployer to boot the target server to do offline deployment. I have already +1'd Aaron's existing changes. -- Jeremy
Re: online and offline deployment
On Nov 9, 2004, at 9:27 AM, Jeremy Boynes wrote: Aaron Mulder wrote: Jeremy, What is your feeling on the package --install command? Because right now, that runs in offline mode, and assumes that it should install into a file-based local configuration store. Which means it's subject to all the problems you've raised if the server is not using a file-based local configuration store, etc. The original purpose of that (in the old offline deployer) was to install the generated configuration in the /deployer's/ config store to that it could be used to resolved dependencies for future deployments. It was the happy co-incidence (ok, a bootstrap hack) that the deployer and server were using the same store that allowed us to pre-load configurations into it. Of course we use this during server construction. But it might be best to start the server immediately after bootstrapping the deployer, and do all the rest of the server construction tasks as online deployments. (That would also have the pleasant side effect of making it all run faster, because you wouldn't be starting and stopping a kernel for every deployment.) I'm all for making it faster but I have reservations about starting the server during the build process as that will trigger a lot of initialization code (like creating a transaction log, a Derby database, etc.) We could nuke it after building the configs but that seems funky. One thing that was talked about a while ago (off-list probably :-) ) was the concept of having a deployment server that could be used to perform deployments. It would basically be the deployment config running as a Daemon which a deployer could talk to; the server would do the deployment and return the configuration it built to the deployer. As the configurations were portable they could then be moved around to the servers where they were intended to run. If we changed the bootstrap code to build such a deployment server, then it could used during the build process and we would not have to create new JVMs all the time. It should be possible to boot such a server inside the Maven VM and talk to it directly. In fact, with a couple of minor tweaks that might even be possible with the current standalone deployment config. I don't think this will work until all the deployment code is in different modules from the runtime code. That's why I've been trying so hard to get it separated. david jencks Then the bootstrapping would be the only operation that actually installed in offline mode, and we could remove the unsafe --install option from the package command -- or actually make the package command perform the installation in online mode, if we have a deployment module that knows how to deploy a CAR file. Or better yet, have the package command run in reverse order -- first distribute the configuration into the running server, and then dump a CAR file from the configuration in the config store. Aside from building the initial deployer (the hard coded Bootstrap class) I don't think we should do anything special to build the default server configuration. We should be able to do it the same way any other user would configure their own server. The challenge facing us and any other user is the same - pre-loading a server's configuration store. The command line executable CAR can be built by the standalone deployer as can all of its configurations. The problem is how to get them into the new server's store(s). As I've said before, we currently hack this by making the deployer and server use the same store but we really need to find a general solution. I have a half-baked idea about a special type of bootstrap deployment where the deployer would interact with a fledging server to set up its stores and repositories and then install the appropriate jars and configurations. This would be driven by bootstrap plan (probably in XML) that told it what to do. I need to think a bit more and I'll send in a proposal to the list when its a little more done. Hey, perhaps we could discuss this off-list at ApacheCon ;-) -- Jeremy
Re: online and offline deployment
Just to reiterate, I think Jeremy is saying that using the deployer tool for offline install is limited because it doesn't know what GBeans the server is using for the ConfigStore and PersistentConfigList and so on. If we instead actually start the server to do an offline deployment/installation, then all the corrct GBeans will be running and that is no longer an issue. An alternative would be for the deployer to inspect the server's configuration when it starts, and load every dependency from the immediate parent of the module to be deployed up through the root, and that should identify the correct ConfigStore and PersistentConfigList. But this is tricky too, since how would it know what ConfigStore to load the configurations out of (including the configuration for the ConfigStore, aargh!). In the end, I suspect this depends on how server.jar was packaged, and if you plan to start your server with start-my-server.jar instead of server.jar then I don't know how the deployer would know that, so I don't know where it would get the original ConfigStore reference from -- perhaps we'd need to give it an option to identify your server startup JAR. But I think this would still fail if the server was running (since you'd probably clash for ports trying to load some of the services between ConfigStore and application), so it's an offline deploy in name only. Another option is that we can provide a tool that works 100% for the default server configuration (LocalConfigStore+FileConfigurationList). But it would not work in the face of customizations to the 2 core components: if you swap out your LocalConfigStore, then the tool would not work (it would install into the wrong place), and if you swap out your PersistentConfigurationList then the tool would be unable to mark any module to be started. If we wanted to, we could make offline deploy tools available for different combinations of those GBeans, or give you a procedure to build a new deploy tool from an old one. The main reason I feel that this is important is that most other products support it. Generally if you copy a new EAR over an old one while the server is not running, and then start the server, the new version of the EAR will deploy on startup. (Tomcat 5 in the one I can think of that doesn't do this). I just hate to tell people that things that used to work won't work any more if they move to Geronimo. On the other hand, I think this behavior was mostly implemented via a hot deploy directory, so if we provide a GBean for a hot deploy directory, then maybe we don't need a offline deploy tool at all (beyond for building the server). And I guess the last issue is related. In the long run, it will be nice/necessary to have some kind of packaged-configuration-handling features, in the deploy tool or another tool: - extract a CAR file from an entry in a server's ConfigStore - sign a CAR file (either in the server's ConfigStore or as a file) - transfer a packaged configuration directly from one server to another - deploy a CAR file into a server Aaron On Sat, 6 Nov 2004, Jeremy Boynes wrote: As promised Thursday, here are the details of my concerns about mixing offline and online deployment. My concerns on this issue stem from how we package GBeans together for use by the kernel. Rather than handling them one-by-one, Geronimo uses the notion of a pre-canned Configuration which contains a number of GBean instances and the classpath information needed to load them. Configurations can be loaded by the kernel and when started bring all the GBeans they contain online together. A key feature of Configurations is they are portable between different Geronimo installations - specifically a Configuration can run in any Geronimo kernel that can resolve its dependencies. This is less critical for the single-server mode we have now but is very important as Geronimo scales to clustered or grid configurations - it allows us to efficiently move applications between the servers on demand. This also has benefits where change management is important, such as business critical installations. For example, a Configuration can be built and signed in a test or integration environment and moved *provably unchanged* though the test, stage and release to production process. Alternatively, an OEM can release an application to channel as a signed Configuration, end-users can have the assurance it has not been tampered with, and the OEM can reduce costs by reducing problems caused by variations in the end-user environment. In the kernel, the process of loading and unloading Configuration is handled by a ConfigurationManager that uses ConfigurationStores to store them. The store exposes a simple API for installing and uninstalling Configurations and for retrieving them so they can be loaded. We have a simple LocalConfigStore implementation that uses the local filesystem
Re: online and offline deployment
Aaron Mulder wrote: Just to reiterate, I think Jeremy is saying that using the deployer tool for offline install is limited because it doesn't know what GBeans the server is using for the ConfigStore and PersistentConfigList and so on. If we instead actually start the server to do an offline deployment/installation, then all the corrct GBeans will be running and that is no longer an issue. An alternative would be for the deployer to inspect the server's configuration when it starts, and load every dependency from the immediate parent of the module to be deployed up through the root, and that should identify the correct ConfigStore and PersistentConfigList. But this is tricky too, since how would it know what ConfigStore to load the configurations out of (including the configuration for the ConfigStore, aargh!). In the end, I suspect this depends on how server.jar was packaged, and if you plan to start your server with start-my-server.jar instead of server.jar then I don't know how the deployer would know that, so I don't know where it would get the original ConfigStore reference from -- perhaps we'd need to give it an option to identify your server startup JAR. But I think this would still fail if the server was running (since you'd probably clash for ports trying to load some of the services between ConfigStore and application), so it's an offline deploy in name only. Another option is that we can provide a tool that works 100% for the default server configuration (LocalConfigStore+FileConfigurationList). But it would not work in the face of customizations to the 2 core components: if you swap out your LocalConfigStore, then the tool would not work (it would install into the wrong place), and if you swap out your PersistentConfigurationList then the tool would be unable to mark any module to be started. If we wanted to, we could make offline deploy tools available for different combinations of those GBeans, or give you a procedure to build a new deploy tool from an old one. The main reason I feel that this is important is that most other products support it. Generally if you copy a new EAR over an old one while the server is not running, and then start the server, the new version of the EAR will deploy on startup. (Tomcat 5 in the one I can think of that doesn't do this). I just hate to tell people that things that used to work won't work any more if they move to Geronimo. On the other hand, I think this behavior was mostly implemented via a hot deploy directory, so if we provide a GBean for a hot deploy directory, then maybe we don't need a offline deploy tool at all (beyond for building the server). And I guess the last issue is related. In the long run, it will be nice/necessary to have some kind of packaged-configuration-handling features, in the deploy tool or another tool: - extract a CAR file from an entry in a server's ConfigStore - sign a CAR file (either in the server's ConfigStore or as a file) - transfer a packaged configuration directly from one server to another - deploy a CAR file into a server Aaron On Sat, 6 Nov 2004, Jeremy Boynes wrote: As promised Thursday, here are the details of my concerns about mixing offline and online deployment. My concerns on this issue stem from how we package GBeans together for use by the kernel. Rather than handling them one-by-one, Geronimo uses the notion of a pre-canned Configuration which contains a number of GBean instances and the classpath information needed to load them. Configurations can be loaded by the kernel and when started bring all the GBeans they contain online together. A key feature of Configurations is they are portable between different Geronimo installations - specifically a Configuration can run in any Geronimo kernel that can resolve its dependencies. This is less critical for the single-server mode we have now but is very important as Geronimo scales to clustered or grid configurations - it allows us to efficiently move applications between the servers on demand. This also has benefits where change management is important, such as business critical installations. For example, a Configuration can be built and signed in a test or integration environment and moved *provably unchanged* though the test, stage and release to production process. Alternatively, an OEM can release an application to channel as a signed Configuration, end-users can have the assurance it has not been tampered with, and the OEM can reduce costs by reducing problems caused by variations in the end-user environment. In the kernel, the process of loading and unloading Configuration is handled by a ConfigurationManager that uses ConfigurationStores to store them. The store exposes a simple API for installing and uninstalling Configurations and for retrieving them so they can be loaded. We have a simple LocalConfigStore implementation that uses the local filesystem to store them; other implementations
Re: online and offline deployment
Bruce, Can you state your current opinion and reasoning? I think that's more valuable than a vote, at this stage. I know I'd like to have a broader discussion to try to agree on the best solution, or at least the best specific options to propose for a vote. For example, I think we've kind of gone past the point where 1 tool or 2 tools is a useful vote -- if two, it's a question of which two and what our goals should be for each. If one, again, what do we attempt to support in that one? Thanks, Aaron On Sun, 7 Nov 2004, Bruce Snyder wrote: I spent part of last night and part of this morning re-reading all of this info to better understand the dilemma over the deploy tool. After reading these two messages a couple times I feel like I understand the issues at hand far better than when I cast my vote. I'm sure that others will find themselves with the same quandary I currently have, whereby upon further education of the issues surrounding the deployment tool, I wish I could recast my vote. If others do, in fact, have the same sentiment, then I propose that the deploy tool vote be recalled and we start a fresh vote on the same topic, or, I just change my vote. Does anyone else feel this way? Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\\F9EG)E=\\$\\!FFEI+F-O;0\\`\\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: online and offline deployment
Aaron Mulder wrote: Can you state your current opinion and reasoning? I think that's more valuable than a vote, at this stage. I know I'd like to have a broader discussion to try to agree on the best solution, or at least the best specific options to propose for a vote. For example, I think we've kind of gone past the point where 1 tool or 2 tools is a useful vote -- if two, it's a question of which two and what our goals should be for each. If one, again, what do we attempt to support in that one? I thought that the dilemma for the vote was regarding the simplication of the deployment tool for code sake rather than for the user sake (i.e. one tool was difficult to code whereas two tools was difficult for the user). I see now that there is a need for two tools, each of which serves a very specific purpose. I now think that much of the dilemma surrounds the term 'deploy'. I cast my vote in favor of a single tool simply from a user's point of view, all the while thinking that the strategy pattern would easily sort out the coding dilemma. Bruce -- perl -e 'print unpack(u30,0G)[EMAIL PROTECTED]5R\\F9EG)E=\\$\\!FFEI+F-O;0\\`\\`);' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: online and offline deployment
Thank you Jeremy, this is a very clear explanation of the architecture. I agree completely with your point of view. I think we should get some version of this explanation on the wiki. I apologize for not entering this discussion earlier, but I didn't have time to think through the issues thoroughly. I have thought all along that offline deployment was a bad idea and should not be used outside very restricted bootstrap scenarios. I would prefer our assembly to proceed by starting a server as soon as possible and using the maven plugin to distribute the modules to that running server. I don't think drop, wait wonder hot deployment should be supported. This only supports deployment of applications with embedded plans or applications that need no plan. I think there are almost no useful applications that will work without a plan to at least resolve resource-refs. I would prefer we put more effort into tools that help identify the minimum amount of information needed for a plan and generate the plan, and then deploy to a running server. To me, making sure the online deployment/undeployment cycle is really reliable even in the face of multiple deployment errors and long chains of parent configurations that are not previously started is a much better idea than supporting any offline deployment. thanks david jencks On Nov 6, 2004, at 9:51 PM, Jeremy Boynes wrote: As promised Thursday, here are the details of my concerns about mixing offline and online deployment. My concerns on this issue stem from how we package GBeans together for use by the kernel. Rather than handling them one-by-one, Geronimo uses the notion of a pre-canned Configuration which contains a number of GBean instances and the classpath information needed to load them. Configurations can be loaded by the kernel and when started bring all the GBeans they contain online together. A key feature of Configurations is they are portable between different Geronimo installations - specifically a Configuration can run in any Geronimo kernel that can resolve its dependencies. This is less critical for the single-server mode we have now but is very important as Geronimo scales to clustered or grid configurations - it allows us to efficiently move applications between the servers on demand. This also has benefits where change management is important, such as business critical installations. For example, a Configuration can be built and signed in a test or integration environment and moved *provably unchanged* though the test, stage and release to production process. Alternatively, an OEM can release an application to channel as a signed Configuration, end-users can have the assurance it has not been tampered with, and the OEM can reduce costs by reducing problems caused by variations in the end-user environment. In the kernel, the process of loading and unloading Configuration is handled by a ConfigurationManager that uses ConfigurationStores to store them. The store exposes a simple API for installing and uninstalling Configurations and for retrieving them so they can be loaded. We have a simple LocalConfigStore implementation that uses the local filesystem to store them; other implementations are possible using different persistence approaches such as databases, LDAP or proprietary configuration management systems. The deployment system in Geronimo is the interface between user-domain artifacts such as J2EE modules (EARs, WARs, etc.) or deployment plans and the configuration management system described above. It essentially combines modules with plans and generates Configurations. It comprises three parts: * External interfaces such as the command line tool, console or JSR-88 provider that get the modules and plans from the user * ConfigurationBuilders such as EARConfigBuilder and ServiceConfigBuilder that do the combination and produce the target Configuration * Back-end interfaces that store the Configuration either in a ConfigurationStore or as an output file The ConfigurationBuilders are GBeans and run inside a Geronimo kernel. Apart from ease of implementation, they also have access to the resources provided by that system - for example, they can use the Repository to load classes during processing, and they can use the ConfigurationManager to load other Configurations that the target may be dependent on. To support online deployment, we run a deployment system inside the same kernel as the J2EE server - it is actually part of the org/apache/geronimo/Server Configuration although work is progress to allow it to be run as a separate dependent configuation. The JSR-88 provider interacts with this deployment system to fulfill the spec requirements for distribute, start, stop, undeploy etc. For example, during a distribute operation the module and plan are passed to the deployment system, it uses an EARConfigBuilder to produce the output Configuration, which it then installs
Re: online and offline deployment
On Sun, 7 Nov 2004, David Jencks wrote: I don't think drop, wait wonder hot deployment should be supported. This only supports deployment of applications with embedded plans or applications that need no plan. I don't understand the objections to this. embedded plans is the way every J2EE application I've ever seen has worked, save the days when WebSphere made you save your plan to DB2 instead of XML files. Every tool in the space today puts your plans in the archive. Granted, the current J2EE leadership seems to think that no application archive should contain server-specific information, but that is not a standard, that is a paradigm shift. Don't you think it will take a long time before the average J2EE developer stops trying to pack their server-specific deployment descriptor (or deployment plan) into their archives? Refusing to support the by-far-most-common method of J2EE packaging and deployment is IMHO only going to turn people off to the product, even if you argue that it's more correct. This is still a different issue than offline deployment, though, since a directory scanner would only work while the server was online. As well, I'd be fine if the directory scanner declined to deploy anything without a Geronimo plan, or just produced errors along the lines of unable to resolve reference to foo, please include a Geronimo deployment plan (geronimo-jetty.xml)... Aaron
Re: online and offline deployment
On Sun, 7 Nov 2004, Jeremy Boynes wrote: ... If someone implements this (dealing, of course, with all the nasties) then all the better; in fact, IIRC there is some old scanning code of mine lying around in the repo somewhere. However, due to the technical issues I would still not advocate scanning as being the recommended way of deploying an application into Geronimo. Right. This I agree with 100%. I am fine with recommending external plans and online deployment tools. I just believe we should be willing to support the old style too. I believe David took a somewhat firmer position than you: On Sun, 7 Nov 2004, David Jencks wrote: I don't think drop, wait wonder hot deployment should be supported. That's what I was objecting to. Supported, yes; recommended, no. Aaron
Re: How to updated config.list during offline deployment
Aaron Mulder wrote: I'd like to be able to add entries to config.list when the server is not running and I'm doing a deployment. The problem is, the configuration list GBean isn't running -- it's not in the minimal set started by the deployer. And even if it was, it would install a shutdown hook that basically saved an empty file when the deployer finished. Anyone mind if I just have a little logic in the deployer to update this file directly? Yes, I mind. The config.list file is specific to the actual implementation of the PersistentConfigurationList GBean and the deployer should not assume that as other implementations may exist. The other thing is that the --install option does just that - install but not start (it is meant to be similar to JSR-88 distribute). I believe this can be better solved by adding an option to server.jar that adds a new configId to the list to be run, something like: java -jar bin/server.jar --add my/new/config -- Jeremy
Re: How to updated config.list during offline deployment
On Nov 4, 2004, at 11:18 AM, Jeremy Boynes wrote: Aaron Mulder wrote: I'd like to be able to add entries to config.list when the server is not running and I'm doing a deployment. The problem is, the configuration list GBean isn't running -- it's not in the minimal set started by the deployer. And even if it was, it would install a shutdown hook that basically saved an empty file when the deployer finished. Anyone mind if I just have a little logic in the deployer to update this file directly? Yes, I mind. The config.list file is specific to the actual implementation of the PersistentConfigurationList GBean and the deployer should not assume that as other implementations may exist. The other thing is that the --install option does just that - install but not start (it is meant to be similar to JSR-88 distribute). I believe this can be better solved by adding an option to server.jar that adds a new configId to the list to be run, something like: java -jar bin/server.jar --add my/new/config So I would have to do this: java -jar bin/server.jar --install file.ear java -jar bin/server.jar --add my/new/config I think that the vast majority of the time I would just want this: java -jar bin/server.jar --deploy file.ear which would do both of the above commands in one go -dain
Re: How to updated config.list during offline deployment
I'm working on the new deployer not the old one. As per the proposed deployer syntax message, this one actually offers a JSR-88 start method while the server is not running, which equates to updating the config list to include the module. I'd rather not start the server to do that... Also, the bulk of the feedback on the thread before that was that having two tools to handle deployment tasks was bad. Aaron On Thu, 4 Nov 2004, Jeremy Boynes wrote: The other thing is that the --install option does just that - install but not start (it is meant to be similar to JSR-88 distribute). I believe this can be better solved by adding an option to server.jar that adds a new configId to the list to be run, something like: java -jar bin/server.jar --add my/new/config -- Jeremy
Re: How to updated config.list during offline deployment
Aaron Mulder wrote: I'm working on the new deployer not the old one. As per the proposed deployer syntax message, this one actually offers a JSR-88 start method while the server is not running, which equates to updating the config list to include the module. I'd rather not start the server to do that... Also, the bulk of the feedback on the thread before that was that having two tools to handle deployment tasks was bad. Pardon me for being dumb but how can you start a module if the server is down? I think we may be trying to hard to kludge 88-style operations into a mode that 88 was not intended to support. -- Jeremy
Re: How to updated config.list during offline deployment
On Thu, 4 Nov 2004, Jeremy Boynes wrote: Pardon me for being dumb but how can you start a module if the server is down? I think we may be trying to hard to kludge 88-style operations into a mode that 88 was not intended to support. If you deploy to a server that's not running, then the module will be started next time the server starts. If you distribute to a server that's not running, then the module will not be started next time the server starts. The alternative is to have two tools for online/offline mode (you missed the boat if you intend to fight for that), or one tool where only half the options work any any given time (ick). Aaron
Re: How to updated config.list during offline deployment
Aaron Mulder wrote: If you deploy to a server that's not running, then the module will be started next time the server starts. If you distribute to a server that's not running, then the module will not be started next time the server starts. You mean, you hope that it starts - you would have to look at the server to see if it actually did. So this has the same copy-and-pray utility as dumping the module in a directory. I think either you would be checking as you watched the server start (the --add option) or you would test by pinging the server once it had started. The latter option here is exactly as hard as just calling start My issue is the ambiguity in the outcome of what you propose. -- Jeremy
Re: How to updated config.list during offline deployment
What I am proposing is the equivalent of using the current deploy tool, and then adding the module's configId to the server command line next time you start it -- which is what you can do today. I don't see how that makes the situation worse. You seem to be sugesting that the deploy tool should only work fully when the server is running, and if the server is not running, then you need to use a different command to start the server and deploy at the same time. Is that right? Aaron On Thu, 4 Nov 2004, Jeremy Boynes wrote: You mean, you hope that it starts - you would have to look at the server to see if it actually did. So this has the same copy-and-pray utility as dumping the module in a directory. I think either you would be checking as you watched the server start (the --add option) or you would test by pinging the server once it had started. The latter option here is exactly as hard as just calling start My issue is the ambiguity in the outcome of what you propose.
Re: How to updated config.list during offline deployment
Aaron Mulder wrote: What I am proposing is the equivalent of using the current deploy tool, and then adding the module's configId to the server command line next time you start it -- which is what you can do today. I don't see how that makes the situation worse. No, you were proposing having the deployment tool hack the internal file used by a specific GBean. I object to that as it relies on implementation detail. You seem to be sugesting that the deploy tool should only work fully when the server is running, and if the server is not running, then you need to use a different command to start the server and deploy at the same time. Is that right? No, I was proposing adding the command line option to the server that added a configId to the list retrieved from the last-known-configs GBean. This is a portable way of achieving what you were trying to do above. It is also simply start and not deploy You can install(distribute) offline to your heart's content but I don't want the user fooled into thinking their app is startable when it isn't. The deploy tool (as in distribute/start) can *only* work with a running server as that is the only way to tell if the application is startable. I think the typical usage will be: start server repeat write code build (with distribute/start to online server) test until app works or it's time to go home rather than repeat write code build (with 'deploy' to offline server) start server check logs for errors test stop server until app works or it's time to go home We should make the first simple and reliable. -- Jeremy
Re: How to updated config.list during offline deployment
On Thu, 4 Nov 2004, Jeremy Boynes wrote: No, you were proposing having the deployment tool hack the internal file used by a specific GBean. I object to that as it relies on implementation detail. Hmm. Obviously we're not on the same page here. So you would be totally comfortable with this if we use the GBean to access the file, rather than writing to it directly? You seem to be sugesting that the deploy tool should only work fully when the server is running, and if the server is not running, then you need to use a different command to start the server and deploy at the same time. Is that right? No, I was proposing adding the command line option to the server that added a configId to the list retrieved from the last-known-configs GBean. This is a portable way of achieving what you were trying to do above. It is also simply start and not deploy Is this your position: - the deploy tool should not support start when the server is not running (but it's fine to support it when the server is running) - the server should offer a command line argument that gets you the start functionality If so, I would claim this uses two tools (deployer.jar, server.jar) and also makes the deployer behave differently depending on whether the server is running (start works, start doesn't work). Also, how is the server.jar option you're proposing different than the existing option to just pass a configId on the command line? What does the new option do that the old one doesn't? Thanks, Aaron
