Re: Deployment pblm in G1.1
I'm seeing a different result with a simple HelloWorld.war test. It deploys fine on G1.0 but doesn't on G1.1.. I've tried on both linux and windows... I've attached the war.. # java -jar deployer.jar --user system --password manager deploy /home/davecola/HelloWorld/HelloWorld.war Error: Unable to distribute HelloWorld.war: Cannot deploy the requested application module (moduleFile=/home/davecola/geronimo-1.1-041006-2/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp/geronimo-deployer4021.tmpdir/HelloWorld.war) Nothing is added to the geronimo.log file.. Thoughts? Thanks -Dave- Dain Sundstrom wrote: Just verified it works without a plan. The deployment actually works, but an exception is thrown from the command line tool. $ java -jar ../../assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/bin/deployer.jar deploy target/geronimo-welcome-1.1-SNAPSHOT.war javax.management.MalformedObjectNameException: Invalid value: 'geronimo.config:name=Unspecified/geronimo-welcome-1.1-SNAPSHOT/1/car' at javax.management.ObjectName.parsePropertyValue(ObjectName.java:571) at javax.management.ObjectName.convertStringToProperties(ObjectName.java:462) at javax.management.ObjectName.parse(ObjectName.java:399) at javax.management.ObjectName.init(ObjectName.java:76) at org.apache.geronimo.deployment.plugin.local.CommandSupport.loadChildren(CommandSupport.java:326) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:70) at java.lang.Thread.run(Thread.java:552) Error: Operation failed: Invalid value: 'geronimo.config:name=Unspecified/geronimo-welcome-1.1-SNAPSHOT/1/car' After running that you can access the welcome application at: http://localhost:8080/geronimo-welcome-1.1-SNAPSHOT/ -dain On Apr 12, 2006, at 1:18 PM, Dain Sundstrom wrote: It is supposed to work as it did before, if not it is a bug. My guess is Dave's application has a geronimo-web.xml file in the old format. We currently don't have an auto-upgrade filter installed in the server yet, so you will need t update the plan to the 1.1 schemas. -dain On Apr 12, 2006, at 7:46 AM, Aaron Mulder wrote: I don't know whether a geronimo-web.xml is supposed to be required now. I sure hope not. But if you do provide a plan, it wouldn't shock me if the config ID was required -- it was certainly required in 1.0 if you did use a Geronimo plan. I think we should get David or Dain to chime in. Thanks, Aaron On 4/12/06, Dave Colasurdo [EMAIL PROTECTED] wrote: Does anyone know the answers to the attached questions? I've heard that others are having similar deployment problems with G1.1 cmdline deployment.. Should I open JIRAs? Thanks -Dave- Dave Colasurdo wrote: BTW, My questions refer to simple web application WARs.. Thanks -Dave- Dave Colasurdo wrote: Can someone please provide details on G1.1 deployment... :) 1) G1.0 user applications did not always require a deployment plan. Shouldn't these same applications deploy on G1.1 without a plan? This doesn't appear to be working.. 2) G1.0 allowed for a plan with mininal info (basically just context-root). This doesn't appear to be working for G1.1.. 3) Can someone please provide a few simple plans that include/exclude a configid in the plan? The existing G1.0 plans don't appear to work for G1.1. Thanks -Dave- Sachin Patel wrote: Actually I'm confused now... I thought the configId attribute was being removed and not supported, looks like it still being used in daytrader??? - sachin On Apr 10, 2006, at 4:31 PM, Sachin Patel wrote: Sorry hit send to quick... looking at the new g-config schema... looks like u need an envionment element declared... xs:complexType name=environmentType xs:sequence xs:element name=configId type=sys:artifactType minOccurs=0 xs:annotation xs:documentation configId holds elements for the groupId, artifactId, and version of the configuration version can be ommitted in which case a timestamp is used. /xs:documentation /xs:annotation /xs:element - sachin On Apr 10, 2006, at 4:24 PM, Sachin Patel wrote: I think your configID is wrong - sachin On Apr 10, 2006, at 4:19 PM, Dave Colasurdo wrote: Yep.. Here it is... ?xml version=1.0? web-app xmlns=http://geronimo.apache.org/xml/ns/web; xmlns:naming=http://geronimo.apache.org/xml/ns/naming; configId=HelloWorld context-root/hello/context-root /web-app Also tried: ?xml version=1.0? web-app xmlns=http://geronimo.apache.org/xml/ns/web; xmlns:naming=http://geronimo.apache.org/xml/ns/naming; context-root/hello/context-root /web-app Thanks -Dave- Aaron Mulder wrote: Does the WAR have a geronimo-web.xml? If so, can you post the contents? Thanks, Aaron On 4/10/06, Dave
Re: commons logging issue
Thanks Pablo, Should this be addressed? The practical impact is sometimes an application will deploy fine in Geronimo/Tomcat but not Geronimo/Jetty (because it will use jars unavailable in the former) or the other way around (because app jars will conflict with Geronimo's, as already discussed in other thread). Is there any reason why the repositories differ for both versions? Cheers, Guilherme Pablo wrote: Guilherme Rios wrote: Paul McMahan wrote: I'm not sure why deployment didn't fail in jetty, perhaps you would have seen a failure later on when you tried to access your servlets(?). Hi, I recall noticing a few days ago some jars missing from Geronimo/Jetty /repository when compared to Geronimo/Tomcat. Commons Logging was one, there was also one or two others missing. Can anyone pls confirm that? (I do not have access to my installation at this very moment) This could be the reason why it works on Geronimo/Jetty but not Geronimo/Tomcat. Regards, Guilherme Hi I'm sending lists of jars for both jetty and tomcat. There are a few differences... Cheers Pablo Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: commons logging issue
Our long term goal is to isolate web applications from the system classes. This means that by default a web application will only see the spec jars required by the servlet spec. Then if an application needs more jars, they can either add them to the WEB-INF/lib or the geronimo repository and add a dependency. I would have liked to get this into 1.1, but I think 1.1 will ship before I can get to it. -dain On Apr 13, 2006, at 7:18 AM, Guilherme Rios wrote: Thanks Pablo, Should this be addressed? The practical impact is sometimes an application will deploy fine in Geronimo/Tomcat but not Geronimo/ Jetty (because it will use jars unavailable in the former) or the other way around (because app jars will conflict with Geronimo's, as already discussed in other thread). Is there any reason why the repositories differ for both versions? Cheers, Guilherme Pablo wrote: Guilherme Rios wrote: Paul McMahan wrote: I'm not sure why deployment didn't fail in jetty, perhaps you would have seen a failure later on when you tried to access your servlets(?). Hi, I recall noticing a few days ago some jars missing from Geronimo/Jetty /repository when compared to Geronimo/Tomcat. Commons Logging was one, there was also one or two others missing. Can anyone pls confirm that? (I do not have access to my installation at this very moment) This could be the reason why it works on Geronimo/Jetty but not Geronimo/Tomcat. Regards, Guilherme Hi I'm sending lists of jars for both jetty and tomcat. There are a few differences... Cheers Pablo Send instant messages to your online friends http:// uk.messenger.yahoo.com
RE: commons logging issue
I have found that if the commons-logging.jar file is in my app's lib directory, then Geronimo chokes on it. However, deployments of the exact same WAR file on Tomcat, Sun, Oracle servers work fine if the commons-logging.jar file is present. I always figured it was a class loader error in Geronimo. Maybe that assumption is incorrect!!?? - Ray Clough -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Thursday, April 13, 2006 9:53 AM To: user@geronimo.apache.org Subject: Re: commons logging issue Our long term goal is to isolate web applications from the system classes. This means that by default a web application will only see the spec jars required by the servlet spec. Then if an application needs more jars, they can either add them to the WEB-INF/lib or the geronimo repository and add a dependency. I would have liked to get this into 1.1, but I think 1.1 will ship before I can get to it. -dain On Apr 13, 2006, at 7:18 AM, Guilherme Rios wrote: Thanks Pablo, Should this be addressed? The practical impact is sometimes an application will deploy fine in Geronimo/Tomcat but not Geronimo/ Jetty (because it will use jars unavailable in the former) or the other way around (because app jars will conflict with Geronimo's, as already discussed in other thread). Is there any reason why the repositories differ for both versions? Cheers, Guilherme Pablo wrote: Guilherme Rios wrote: Paul McMahan wrote: I'm not sure why deployment didn't fail in jetty, perhaps you would have seen a failure later on when you tried to access your servlets(?). Hi, I recall noticing a few days ago some jars missing from Geronimo/Jetty /repository when compared to Geronimo/Tomcat. Commons Logging was one, there was also one or two others missing. Can anyone pls confirm that? (I do not have access to my installation at this very moment) This could be the reason why it works on Geronimo/Jetty but not Geronimo/Tomcat. Regards, Guilherme Hi I'm sending lists of jars for both jetty and tomcat. There are a few differences... Cheers Pablo Send instant messages to your online friends http:// uk.messenger.yahoo.com
RE: JMS Connector deployment for SPECjAppServer2004
The name-gbean-link issue is no more important for SjAS, but it looks like a bug to me anyway, so I filed it to Jira as http://issues.us.apache.org/jira/browse/GERONIMO-1841 Vasily -Original Message- From: Zakharov, Vasily M [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 12:12 AM To: user@geronimo.apache.org Subject: RE: JMS Connector deployment for SPECjAppServer2004 Matt, I've created a JIRA issue with the DD's, it's http://issues.apache.org/jira/browse/GERONIMO-1800 I'm not sure if I chose the right component, issue type and priority, please fix them if I made them wrong. :) Also, please remove issue GERONIMO-1799, I created it accidentially. :( The main DD is written basing on your work, the database and JMS descriptor were created using the examples in the documentation and the corresponding descriptors for DayTrader. In fact, I managed to resolve the issue described in my previous message, it turned out to be a rather simple thing - inside workmanager I used name instead of gbean-link (I learned that by reading DayTrader JMS desciptor). When I changed that, the connector began to start normally. I wonder if we should file a bug about name tag being processed incorrectly? Thank you, Vasily Zakharov Intel Middleware Product Division -Original Message- From: Matt Hogstrom [mailto:[EMAIL PROTECTED] Sent: Friday, March 31, 2006 2:40 AM To: user@geronimo.apache.org Subject: Re: JMS Connector deployment for SPECjAppServer2004 Vasily, Can you open a JIRA and attach your current descriptors to it? I assume your using the one that is in geronimo/sandbox/contrib/specjappserver2004. I have the databases setup here so I can start it and take a look. Thanks for looking in to this. SPECj is a monster and not fit for man nor beast :). Matt Zakharov, Vasily M wrote: Hi, all, After being busy with other things for a long time, I'm now back to SPECjAppServer2004. :) One of the problems I encounter is that the JMS connector I created fails to start and exceptions occur when I'm trying to access it. I'm trying to deploy a JMS Connector on Geronimo 1.0 with the deployment plan (shown below). The deployment goes ok, and the connector is visible as running at Console/Applications/J2EEConnectors, but it's visible as Starting forever (instead of Running) at Console/Services/JMS/JMSConnectionFactories, while its adminobjects are visible normally at Console/Services/JMS/JMSDestinationManager. When I'm clicking test connection on the connector, the following diagnostic appears on the screen: Failed: Operations can only be invoke while the GBean is running: geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=SPE CjAppServerJMS,j2eeType=JCAManagedConnectionFactory,name=SPECConnectionF actory When I'm clicking detail on the connector, the Error occurred in portlet! message appears on the screen and the exceptions (shown below) appear in the log. Any idea what may I be doing wrong? Thank you! Vasily Zakharov Intel Middleware Product Division The deployment plan I use is: ?xml version=1.0 encoding=UTF-8? connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector-1.0; configId=SPECjAppServerJMS parentId=geronimo/activemq/1.0/car resourceadapter resourceadapter-instance resourceadapter-nameSPECJMSResources/resourceadapter-name config-property-setting name=ServerUrltcp://localhost:61616/config-property-setting config-property-setting name=UserNamenot needed/config-property-setting config-property-setting name=Passwordnot needed/config-property-setting workmanager nameDefaultWorkManager/name /workmanager /resourceadapter-instance outbound-resourceadapter connection-definition connectionfactory-interfacejavax.jms.ConnectionFactory/connectionfact ory-interface connectiondefinition-instance nameSPECConnectionFactory/name implemented-interfacejavax.jms.QueueConnectionFactory/implemented-int erface implemented-interfacejavax.jms.TopicConnectionFactory/implemented-int erface connectionmanager xa-transaction transaction-caching/ /xa-transaction single-pool max-size10/max-size min-size0/min-size blocking-timeout-milliseconds5000/blocking-timeout-milliseconds idle-timeout-minutes0/idle-timeout-minutes match-one/ /single-pool /connectionmanager /connectiondefinition-instance /connection-definition /outbound-resourceadapter /resourceadapter adminobject
Re: Deployment pblm in G1.1
Dain, I just rebuilt the server and the application (from scratch)and am now seeing the same behavior you describe on Jetty. Simple applications deploy either with or without a plan... Though an exception is thrown for both cases.. This behavior is consistent when a plan is specified for Tomcat. However, I'm continuing to see the original failure Error: Unable to distribute Hello2.war: Cannot deploy the requested application module for *tomcat* when a plan is not specified. Thanks -Dave- Dain Sundstrom wrote: Are you up to date? I get the following $ java -jar bin/deployer.jar deploy ~/HelloWorld.war javax.management.MalformedObjectNameException: Invalid value: 'geronimo.config:name=Unspecified/HelloWorld/1/car' at javax.management.ObjectName.parsePropertyValue(ObjectName.java:571) at javax.management.ObjectName.convertStringToProperties(ObjectName.java:462) at javax.management.ObjectName.parse(ObjectName.java:399) at javax.management.ObjectName.init(ObjectName.java:76) at org.apache.geronimo.deployment.plugin.local.CommandSupport.loadChildren(CommandSupport.java:326) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:70) at java.lang.Thread.run(Thread.java:552) Error: Operation failed: Invalid value: 'geronimo.config:name=Unspecified/HelloWorld/1/car' Which is the same error as before, but the deployment actually worked and I can access the app at: http://localhost:8080/HelloWorld/ -dain On Apr 13, 2006, at 7:09 AM, Dave Colasurdo wrote: I'm seeing a different result with a simple HelloWorld.war test. It deploys fine on G1.0 but doesn't on G1.1.. I've tried on both linux and windows... I've attached the war.. # java -jar deployer.jar --user system --password manager deploy /home/davecola/HelloWorld/HelloWorld.war Error: Unable to distribute HelloWorld.war: Cannot deploy the requested application module (moduleFile=/home/davecola/geronimo-1.1-041006-2/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp/geronimo-deployer4021.tmpdir/HelloWorld.war) Nothing is added to the geronimo.log file.. Thoughts? Thanks -Dave-
Re: commons logging issue
Ray, If I understood the discussions around this topic that happened this week, the problem you noticed has to do with conflicts between WEB-INF/lib jars and Geronimo jars, because currently they share the same classloader. Sticking to the track of this thread, you may try to deploy your war to Geronimo/Jetty and most likely won't have any problems, because its repository does not have a copy of this jar. There are two workarounds for this that I am aware of: 1. Add the container-specific geronimo-web.xml to WEB-INF (or tell the deployer which one to use when you deploy your app) and make sure it has something like... hidden-classesfilterorg.apache.commons.logging/filter/hidden-classes 2. Remove commons-logging.jar from your app so the repository version will be used instead. I believe this is what you did, right? You could also erase commons-logging.jar from the repository, but I don't think anyone would advise that. Until the issue is dealt with, I think the best workaround for similar problems is going with a geronimo-web.xml given to the classloader at deploy time, and not inside your WEB-INF, so the app remains proprietary descriptor free. If you erase the jar from it, you may have problems deploying it to other servers. Hope this helps, Guilherme Clough, Ray C PWR escreveu: I have found that if the commons-logging.jar file is in my app's lib directory, then Geronimo chokes on it. However, deployments of the exact same WAR file on Tomcat, Sun, Oracle servers work fine if the commons-logging.jar file is present. I always figured it was a class loader error in Geronimo. Maybe that assumption is incorrect!!?? - Ray Clough ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
RE: commons logging issue
Thanks. I thought it seemed like a classloader bug! Nice to know I was right. I've taken to using Ant magic to remove it from the Geronimo-build WAR file. - Ray Clough -Original Message- From: Guilherme Rios [mailto:[EMAIL PROTECTED] Sent: Thursday, April 13, 2006 3:39 PM To: user@geronimo.apache.org Subject: Re: commons logging issue Ray, If I understood the discussions around this topic that happened this week, the problem you noticed has to do with conflicts between WEB-INF/lib jars and Geronimo jars, because currently they share the same classloader. Sticking to the track of this thread, you may try to deploy your war to Geronimo/Jetty and most likely won't have any problems, because its repository does not have a copy of this jar. There are two workarounds for this that I am aware of: 1. Add the container-specific geronimo-web.xml to WEB-INF (or tell the deployer which one to use when you deploy your app) and make sure it has something like... hidden-classesfilterorg.apache.commons.logging/filter/hidden-clas ses 2. Remove commons-logging.jar from your app so the repository version will be used instead. I believe this is what you did, right? You could also erase commons-logging.jar from the repository, but I don't think anyone would advise that. Until the issue is dealt with, I think the best workaround for similar problems is going with a geronimo-web.xml given to the classloader at deploy time, and not inside your WEB-INF, so the app remains proprietary descriptor free. If you erase the jar from it, you may have problems deploying it to other servers. Hope this helps, Guilherme Clough, Ray C PWR escreveu: I have found that if the commons-logging.jar file is in my app's lib directory, then Geronimo chokes on it. However, deployments of the exact same WAR file on Tomcat, Sun, Oracle servers work fine if the commons-logging.jar file is present. I always figured it was a class loader error in Geronimo. Maybe that assumption is incorrect!!?? - Ray Clough ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
