Re: JMS tutorial using ActiveMQ ,Tomcat and Axis
Hi Thanks for kind help. now i can start do develope how message send and receive. but some times i have got error message when i run console base producer and consumer [java] WARN ActiveMQConnection - Cleanup failed [java] org.apache.activemq.ConnectionClosedException: The connection is already closed [java] at org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1030) [java] at org.apache.activemq.ActiveMQConnection.cleanup(ActiveMQConnection.java:1191) [java] at org.apache.activemq.ActiveMQConnection.transportFailed(ActiveMQConnection.java:1585) [java] at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1338) [java] at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:102) [java] at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:102) [java] at org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:102) [java] at org.apache.activemq.transport.TransportSupport.onException(TransportSupport.java:90) [java] at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:149) [java] at java.lang.Thread.run(Thread.java:595) can you help me ? thanks -- View this message in context: http://www.nabble.com/JMS-tutorial-using-ActiveMQ-%2CTomcat-and-Axis-t1525151.html#a4151737 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: JMS tutorial using ActiveMQ ,Tomcat and Axis
[java] WARN ActiveMQConnection - Cleanup failed [java] org.apache.activemq.ConnectionClosedException: The connection is already closed Maybe two reason cause this. 1. your activemq is shutted down. 2.your code is error. If you used a cached connection,but it is closed now,and when you use it,you do not make a check. I always use a new Connection,because I use it in schedule ,there is no need for me to cache it. You should check your code. Best Wishes. -- I love Java! I love Sports! I love this Game ! home:http://www.jsports.org blog: http://blog.csdn.net/jsports http://blog.matrix.org.cn/page/jsports
[jira] Created: (GERONIMO-1942) InPlace deployment does not work with EjbModules
InPlace deployment does not work with EjbModules Key: GERONIMO-1942 URL: http://issues.apache.org/jira/browse/GERONIMO-1942 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 In place deployment fails with EJBModules. When pointing to the exploded ejbjar using the --inPlace option the classes to not resolve... Error: Unable to distribute temp: Remote interface class not found: org.apache.test.My -- 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
trunk build: geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar
when i build from trunk, i get this error: BUILD FAILED File.. L:\work\geronimo\geronimo\maven.xml Element... maven:reactor Line.. 222 Column 148 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee_1.4_spec-1.1-SNAPSHOT.jar how to fix it? argyn
Re: [announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
Congratulations Guillaume! Gianny Dain Sundstrom wrote: The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. Guillaume has consistently brought unique and very difficult use cases to the XBean project (along with patches), and it is these diverse requirements that will ultimately make XBean a success. We believe he will be an excellent addition to the project and will help foster these values in others. Please join us in congratulating Guillaume, The Apache Geronimo PMC
OpenEJB Build Error
Just hit the following compilation error on openejb after and svn up
on both g and openejb.
[javac] Compiling 150 source files to /Users/sppatel/geronimo/
branches/1.1/openejb/modules/openejb-builder/target/classes
[javac] /Users/sppatel/geronimo/branches/1.1/openejb/modules/
openejb-builder/src/java/org/openejb/deployment/
OpenEJBModuleBuilder.java:136:
org.openejb.deployment.OpenEJBModuleBuilder is not abstract and does
not override abstract method createModule
(java.lang.Object,java.util.jar.JarFile,java.lang.String,java.net.URL,or
g.apache.geronimo.kernel.repository.Environment,java.lang.Object,org.apa
che.geronimo.gbean.AbstractName,org.apache.geronimo.kernel.Naming,org.ap
ache.geronimo.deployment.ModuleIDBuilder) in
org.apache.geronimo.j2ee.deployment.ModuleBuilder
[javac] public class OpenEJBModuleBuilder implements
ModuleBuilder {
[javac]^
[javac] 1 error
- sachin
[jira] Assigned: (GERONIMO-1928) CLI doesn't allow --inPlace as an option
[ http://issues.apache.org/jira/browse/GERONIMO-1928?page=all ] Sachin Patel reassigned GERONIMO-1928: -- Assign To: Sachin Patel CLI doesn't allow --inPlace as an option Key: GERONIMO-1928 URL: http://issues.apache.org/jira/browse/GERONIMO-1928 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Assignee: Sachin Patel Priority: Critical Fix For: 1.1 The --inPlace argument is not accepted by the command line deployer. The following error is recieved: Error: No such command: '--inPlace' This option needs to be added to the syntax help as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1928) CLI doesn't allow --inPlace as an option
[ http://issues.apache.org/jira/browse/GERONIMO-1928?page=all ] Sachin Patel resolved GERONIMO-1928: Resolution: Fixed CLI doesn't allow --inPlace as an option Key: GERONIMO-1928 URL: http://issues.apache.org/jira/browse/GERONIMO-1928 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Assignee: Sachin Patel Priority: Critical Fix For: 1.1 The --inPlace argument is not accepted by the command line deployer. The following error is recieved: Error: No such command: '--inPlace' This option needs to be added to the syntax help as well. -- 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-1943) cli.CommandRedeploy implementation doesn't support inPlace
cli.CommandRedeploy implementation doesn't support inPlace -- Key: GERONIMO-1943 URL: http://issues.apache.org/jira/browse/GERONIMO-1943 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 Looking at the implementation of CommandRedeploy it looks as if it does not support inPlace deployment. -- 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: OpenEJB Build Error
FYI a ModuleIDBuilder parameter was added to the
ModuleBuilder.createModule methods
- sachin
On Apr 29, 2006, at 10:26 AM, Sachin Patel wrote:
Just hit the following compilation error on openejb after and svn
up on both g and openejb.
[javac] Compiling 150 source files to /Users/sppatel/geronimo/
branches/1.1/openejb/modules/openejb-builder/target/classes
[javac] /Users/sppatel/geronimo/branches/1.1/openejb/modules/
openejb-builder/src/java/org/openejb/deployment/
OpenEJBModuleBuilder.java:136:
org.openejb.deployment.OpenEJBModuleBuilder is not abstract and
does not override abstract method createModule
(java.lang.Object,java.util.jar.JarFile,java.lang.String,java.net.URL,
org.apache.geronimo.kernel.repository.Environment,java.lang.Object,org
.apache.geronimo.gbean.AbstractName,org.apache.geronimo.kernel.Naming,
org.apache.geronimo.deployment.ModuleIDBuilder) in
org.apache.geronimo.j2ee.deployment.ModuleBuilder
[javac] public class OpenEJBModuleBuilder implements
ModuleBuilder {
[javac]^
[javac] 1 error
- sachin
Re: user-apps directory
Good thoughts. I would also like to see all of the non-core apps (like Daytrader, Magicgball, LDAP demo and realm, ...) moved out from under asf/geronimo/trunk/applications (like has been done for Daytrader) into a common subproject like asf/geronimo/applications or samples. This subproject could then also hold deployment plans for other applications (like JRoller and Petstore) and be setup to create a runnable application testsuite using the same steps as we have today in Magicgball to extract a server, start it and deploy apps to it. -Donald Dave Colasurdo wrote: Keeping with the theme of talking to myself.. I guess it is simpler to just change the groupid in the sample deployment plans to user-apps. Of course users are free to specify any groupid they want .. but the default in the sample plans that we provide (including our documentation) will result in the user applications being separated from the geronimo plumbing by naming convention without any code impact.. -Dave- Dave Colasurdo wrote: This reminds me of a topic from a few weeks ago.. Is there a JIRA open to address separating the end user applications from the geronimo internal plumbing? Specifically, /Geronimo-1.1/repository/geronimo/ seems like a strange spot for end user applications. Searching for deployed applications seems a bit like looking for a needle in the haystack. /Geronimo-1.1/repository/ has nearly 40 directories /Geronimo-1.1/repository/geronimo has nearly 70 directories. How about a simple /Geronimo-1.1/user-apps/ that contains only deployed user applications? Thanks -Dave- David Jencks (JIRA) wrote: remove config-store directories from assemblies, now that they aren't used any more --- Key: GERONIMO-1932 URL: http://issues.apache.org/jira/browse/GERONIMO-1932 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 modify the assembly plugin to not create the bogus empty unused obsolete config-store directory smime.p7s Description: S/MIME Cryptographic Signature
Re: The name of key store type is hardcoded in the sources
#1 is not an option. We removed the normal Bouncy Castle distribution from AG 1.0-M5, due to included code with IP restrictions that required users to acquire an IDEA license. Only a few portions of Bouncy Castle that was needed and did not have IP restrictions was pulled into the geronimo source tree under modules/util. Where is JKS hard-coded? Can you not override JKS in var/config/config.xml to use your different provider? If not, then please open a JIRA issue with details on the problems you run into. -Donald Nikolay Chugunov wrote: Hello The name of Sun-specific key store type is hardcoded in the sources, so it might not work on non-Sun VMs. From my point of view, there are two ways to fix this problem: 1. Always use BKS key store of Bouncy Castle ( http://www.bouncycastle.org) security provider, because it is open-source project. Geronimo can use BKS if I just replace JKS word to BKS of in the source of Geronimo. In this case Bouncy Castle security provider should be in class path in Geronimo. 2. Change sources so Geronimo will use a key store type which exists in VM. Key store type existing in VM can be discovered by invoking KeyStore.getDefaultType() method. Disadvantage of this way: if I build Geronimo on Sun VM, it generates JKS key store file, which might not be read by other VM, because of lack JKS key store implementation. So binary builds might not work on other VMs. Can you advise which way Geronimo should use? **Nikolay *Chugunov** * ** *Intel* Middleware Product Division*** .* smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (GERONIMO-1943) cli.CommandRedeploy implementation doesn't support inPlace
[ http://issues.apache.org/jira/browse/GERONIMO-1943?page=comments#action_12377096 ] Aaron Mulder commented on GERONIMO-1943: I think the theory was that it should do an in-place redeploy if the original deployment was in-place, so it would ignore the command-line flag. What do you think of that approach? cli.CommandRedeploy implementation doesn't support inPlace -- Key: GERONIMO-1943 URL: http://issues.apache.org/jira/browse/GERONIMO-1943 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 Looking at the implementation of CommandRedeploy it looks as if it does not support inPlace deployment. -- 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: OpenEJB Build Error
My fault, I put in Geronimo changes and forgot to check in the
corresponding OpenEJB changes. It should be OK now.
Thanks,
Aaron
On 4/29/06, Sachin Patel [EMAIL PROTECTED] wrote:
FYI a ModuleIDBuilder parameter was added to the
ModuleBuilder.createModule methods
- sachin
On Apr 29, 2006, at 10:26 AM, Sachin Patel wrote:
Just hit the following compilation error on openejb after and svn
up on both g and openejb.
[javac] Compiling 150 source files to /Users/sppatel/geronimo/
branches/1.1/openejb/modules/openejb-builder/target/classes
[javac] /Users/sppatel/geronimo/branches/1.1/openejb/modules/
openejb-builder/src/java/org/openejb/deployment/
OpenEJBModuleBuilder.java:136:
org.openejb.deployment.OpenEJBModuleBuilder is not abstract and
does not override abstract method createModule
(java.lang.Object,java.util.jar.JarFile,java.lang.String,java.net.URL,
org.apache.geronimo.kernel.repository.Environment,java.lang.Object,org
.apache.geronimo.gbean.AbstractName,org.apache.geronimo.kernel.Naming,
org.apache.geronimo.deployment.ModuleIDBuilder) in
org.apache.geronimo.j2ee.deployment.ModuleBuilder
[javac] public class OpenEJBModuleBuilder implements
ModuleBuilder {
[javac]^
[javac] 1 error
- sachin
[jira] Commented: (GERONIMO-1931) Deployers and the deploying classes are in separate class loader hierarchies
[ http://issues.apache.org/jira/browse/GERONIMO-1931?page=comments#action_12377097 ] Aaron Mulder commented on GERONIMO-1931: This hits OpenEJB MdbBuilder in that it tries to instantiate an ActivationSpec and then call validate() on it. However, the deployer has a different ActivationSpec class than the configuration ClassLoader that it uses to load the ActivationSpec implementation. As a result, it has to use reflection to call validate and to deal with the exception class (same problem there) that indicates validation failures. When this is fixed, MdbBuilder should be fixed as well. Just a note, there's a new class o.a.g.kernel.util.ClassLoaderDumper that prints out the CL hierarchy and then the JARs in each CL in the path, to help with debugging. Deployers and the deploying classes are in separate class loader hierarchies Key: GERONIMO-1931 URL: http://issues.apache.org/jira/browse/GERONIMO-1931 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Dain Sundstrom Fix For: 1.2 The deployers are loaded from the main KernelConfiguraitonManager, where as when we deploy the new deployments are loaded from a private SimpleConfigurationManager. This means two classloaders are completely separate and deployers see different versions of the spec classes. Therefor, the deployers can't make use of instanceof and can use code like this: TimedObject.class.inAssignable(beanClass) This makes deployers unnecessarily complex and error prone. This can easily be addressed by having the private SimpleConfigurationManager in the DeploymentContext first check main KernelConfigurationManager to see if the configuration exists before reloading it from disk. -- 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-1944) Add test of MDB to ActiveMQ with only message-destination-type and message-destination-link
Add test of MDB to ActiveMQ with only message-destination-type and message-destination-link --- Key: GERONIMO-1944 URL: http://issues.apache.org/jira/browse/GERONIMO-1944 Project: Geronimo Type: Test Security: public (Regular issues) Components: OpenEJB, ActiveMQ Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2 Currently the openejb-jar.xml still needs the RA link, but it can go without activation spec config params. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1943) cli.CommandRedeploy implementation doesn't support inPlace
[ http://issues.apache.org/jira/browse/GERONIMO-1943?page=all ] Sachin Patel resolved GERONIMO-1943: Resolution: Won't Fix Yes, thats sounds good. cli.CommandRedeploy implementation doesn't support inPlace -- Key: GERONIMO-1943 URL: http://issues.apache.org/jira/browse/GERONIMO-1943 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 Looking at the implementation of CommandRedeploy it looks as if it does not support inPlace deployment. -- 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-1414) Console About page does not set the shortcut icon
[ http://issues.apache.org/jira/browse/GERONIMO-1414?page=all ] Erin Mulder updated GERONIMO-1414: -- Attachment: 1414-console-about-favicon.patch 1414-console-about-favicon.patch adds the necessary line without reformatting the rest of the file. Console About page does not set the shortcut icon - Key: GERONIMO-1414 URL: http://issues.apache.org/jira/browse/GERONIMO-1414 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Environment: Latest AG 1.0 branch from 20051221 Reporter: Donald Woods Priority: Trivial Attachments: 1414-console-about-favicon.patch, Geronimo-1414.patch The SHORTCUT ICON is not being set to the favicon.ico for the About page. The Login and Portal pages are setting it correctly, so this update is just for consistantcy. -- 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-1945) Console's web application list does not show WARs that are deployed inside EARs
Console's web application list does not show WARs that are deployed inside EARs --- Key: GERONIMO-1945 URL: http://issues.apache.org/jira/browse/GERONIMO-1945 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.0 Reporter: Erin Mulder In the console, click on Applications - Web App WARs. The resulting list of web applications does not include any web application that is packaged as part of an EAR. (The list is populated inside ConfigManagerPortlet.doView) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1421) DB portlet failure in Tomcat only
[ http://issues.apache.org/jira/browse/GERONIMO-1421?page=comments#action_12377120 ] Aaron Mulder commented on GERONIMO-1421: Currently we have a very limited workaround to substitute %3B for ; and nothing else. Will try a more general fix of URL-Encoding the JDBC URL to handle and so on. DB portlet failure in Tomcat only - Key: GERONIMO-1421 URL: http://issues.apache.org/jira/browse/GERONIMO-1421 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, Tomcat Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 - create a new database pool using the DB portlet - select the Derby Embedded type - pick the derby or derby-client JAR - give it a new or existing database name - add ;create=true to the end of the generated URL - click test This procedure works in the Jetty build but does not work in the Tomcat build. In Tomcat, it just redirects to the main screen for that portlet without any error message. The database is actually created (visible in the DB Manager portlet). This does not happen if you remove ;create=true from the URL and use an existing database. -- 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-1376) Console should display context path in Installed Web Applications page
[ http://issues.apache.org/jira/browse/GERONIMO-1376?page=all ] Erin Mulder updated GERONIMO-1376: -- Attachment: 1376-console-show-context.patch This patch changes the web app page in the console to add a URL column that displays the context path (hyperlinked to the running application). The URL column is empty for any stopped webapps, and it doesn't appear at all on the EAR and EJB-JAR pages. Console should display context path in Installed Web Applications page Key: GERONIMO-1376 URL: http://issues.apache.org/jira/browse/GERONIMO-1376 Project: Geronimo Type: Wish Security: public(Regular issues) Components: console Versions: 1.0-M5 Environment: all Reporter: Anita Kulshreshtha Priority: Trivial Attachments: 1376-console-show-context.patch Console should display context path for running web applications. -- 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-1376) Console should display context path in Installed Web Applications page
[ http://issues.apache.org/jira/browse/GERONIMO-1376?page=all ] Erin Mulder updated GERONIMO-1376: -- Patch Info: [Patch Available] Console should display context path in Installed Web Applications page Key: GERONIMO-1376 URL: http://issues.apache.org/jira/browse/GERONIMO-1376 Project: Geronimo Type: Wish Security: public(Regular issues) Components: console Versions: 1.0-M5 Environment: all Reporter: Anita Kulshreshtha Priority: Trivial Attachments: 1376-console-show-context.patch Console should display context path for running web applications. -- 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-1360) Misleading error for missing web deployer
[ http://issues.apache.org/jira/browse/GERONIMO-1360?page=all ] Erin Mulder updated GERONIMO-1360: -- Patch Info: [Patch Available] Misleading error for missing web deployer - Key: GERONIMO-1360 URL: http://issues.apache.org/jira/browse/GERONIMO-1360 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: 1360-missing-deployer-error-msg.patch I recently experienced trouble deploying an ear file containing a war module. After a lot of head scratching (and waste of Aaron's time) I discovered that the source of the error was that the jetty-deployer wasn't started. The error returned by the deployer was Module was not a war: Adventure.war, which didn't help me a lot to say the least. The error is printed from EARConfigBuilder.java in module j2ee-builder. I'm on the 1.0 candidate build being voted about earlier today. Transcript [1] at the bottom of this mail exposes the error. I know that I'm partly to blame (the jetty-deployer is active in the default configuration), but nonetheless someone might want to create a JIRA? Kindly, Jakob Transcript [1]: $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Distributed org/apache/geronimo/Adventure1.0.1 ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager stop geronimo/jetty-deployer/1.0/car Stopped geronimo/jetty-deployer/1.0/car ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Error: Operation failed: Module was not a war: adventure.war --- [2] Running configurations: + geronimo/activemq-broker/1.0/car + geronimo/j2ee-server/1.0/car + geronimo/jetty-deployer/1.0/car + geronimo/ldap-realm/1.0/car + geronimo/uddi-jetty/1.0/car `- uddi-jetty @ http://jrf:8080/juddi `- uddi-db + geronimo/online-deployer/1.0/car + geronimo/activemq/1.0/car + geronimo/directory/1.0/car + geronimo/j2ee-security/1.0/car + geronimo/j2ee-deployer/1.0/car + geronimo/system-database/1.0/car + geronimo/j2ee-system/1.0/car + geronimo/rmi-naming/1.0/car + geronimo/jetty/1.0/car + geronimo/webconsole-jetty/1.0/car `- geronimo-console-standard-1.0.war @ http://jrf:8080/console-standard `- geronimo-console-framework-1.0.war @ http://jrf:8080/console + geronimo/geronimo-gbean-deployer/1.0/car -- 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-1683) Web app context-root should trim whitespace
[ http://issues.apache.org/jira/browse/GERONIMO-1683?page=all ] Erin Mulder updated GERONIMO-1683: -- Patch Info: [Patch Available] Web app context-root should trim whitespace --- Key: GERONIMO-1683 URL: http://issues.apache.org/jira/browse/GERONIMO-1683 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: 1683-context-root-trim-new.patch, 1683-context-root-trim.patch If you have an element like this: context-root /something /context-root Then the whitespace is included in the context root -- it becomes return space space /something instead of just /something. We should trim the whitespace. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1421) DB portlet failure in Tomcat only
[ http://issues.apache.org/jira/browse/GERONIMO-1421?page=all ] Aaron Mulder resolved GERONIMO-1421: Resolution: Fixed DB portlet failure in Tomcat only - Key: GERONIMO-1421 URL: http://issues.apache.org/jira/browse/GERONIMO-1421 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, Tomcat Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 - create a new database pool using the DB portlet - select the Derby Embedded type - pick the derby or derby-client JAR - give it a new or existing database name - add ;create=true to the end of the generated URL - click test This procedure works in the Jetty build but does not work in the Tomcat build. In Tomcat, it just redirects to the main screen for that portlet without any error message. The database is actually created (visible in the DB Manager portlet). This does not happen if you remove ;create=true from the URL and use an existing database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1376) Console should display context path in Installed Web Applications page
[ http://issues.apache.org/jira/browse/GERONIMO-1376?page=all ] Aaron Mulder resolved GERONIMO-1376: Fix Version: 1.1 Resolution: Fixed Assign To: Aaron Mulder Patch applied, thanks! Console should display context path in Installed Web Applications page Key: GERONIMO-1376 URL: http://issues.apache.org/jira/browse/GERONIMO-1376 Project: Geronimo Type: Wish Security: public(Regular issues) Components: console Versions: 1.0-M5 Environment: all Reporter: Anita Kulshreshtha Assignee: Aaron Mulder Priority: Trivial Fix For: 1.1 Attachments: 1376-console-show-context.patch Console should display context path for running web applications. -- 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-1529) Console should display Geronimo Version
[ http://issues.apache.org/jira/browse/GERONIMO-1529?page=all ]
Erin Mulder updated GERONIMO-1529:
--
Attachment: 1529-display-geronimo-version.patch
Here's a patch (1529-display-geronimo-version.patch) that displays the Geronimo
version in the startup sequence and on the server info page.
Console should display Geronimo Version
---
Key: GERONIMO-1529
URL: http://issues.apache.org/jira/browse/GERONIMO-1529
Project: Geronimo
Type: Improvement
Security: public(Regular issues)
Components: console, Logging
Versions: 1.0, 1.0-M5, 1.0-M4, 1.0-M3, 1.0-M2, 1.0-M1, 1.1, 1.2, 1.x
Reporter: Matthias Schmidt
Priority: Minor
Attachments: 1529-display-geronimo-version.patch, showVersion.patch
One should be able to figure out geronimo's Version by:
a) looking in the Console, perhaps under Server Info
b) looking in the Logfiles.
for a) one can do the following:
---
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java
2006-01-23 14:57:59.0 +0100
+++
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java.CHANGE
2006-01-23 15:02:27.0 +0100
@@ -34,6 +34,7 @@
import org.apache.geronimo.console.BasePortlet;
import org.apache.geronimo.console.util.PortletManager;
import org.apache.geronimo.management.geronimo.JVM;
+import org.apache.geronimo.console.GeronimoVersion;
/**
* Calculates various information about the server to display in the server
@@ -71,6 +72,8 @@
Date bootDate = jvm.getKernelBootTime();
svrProps.put(Kernel Boot Time, bootDate);
+svrProps.put(Geronimo Version, new
GeronimoVersion().GERONIMO_VERSION);
+
renderRequest.setAttribute(svrProps, svrProps);
jvmProps.put(Java Version, jvm.getJavaVersion());
---
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
2006-01-11 17:34:52.0 +0100
+++
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp.CHANGE
2006-01-23 15:06:42.0 +0100
@@ -5,6 +5,7 @@
script type='text/javascript'
src='/console-standard/dwr/engine.js'/script
script type='text/javascript' src='/console-standard/dwr/util.js'/script
+
portlet:defineObjects/
table width=100%
@@ -19,6 +20,10 @@
td class=MediumBackgroundKernel Up Time/td
td class=MediumBackgrounddiv id=portlet:namespace/UpTimeNot
Yet Available/div/td
/tr
+ tr
+td class=LightBackground width=20% nowrapGeronimo Version/td
+td class=LightBackground width=80%${svrProps['Geronimo
Version']}/td
+ /tr
/table
br
!--
--
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-1529) Console should display Geronimo Version
[ http://issues.apache.org/jira/browse/GERONIMO-1529?page=all ]
Erin Mulder updated GERONIMO-1529:
--
Patch Info: [Patch Available]
Console should display Geronimo Version
---
Key: GERONIMO-1529
URL: http://issues.apache.org/jira/browse/GERONIMO-1529
Project: Geronimo
Type: Improvement
Security: public(Regular issues)
Components: console, Logging
Versions: 1.0, 1.0-M5, 1.0-M4, 1.0-M3, 1.0-M2, 1.0-M1, 1.1, 1.2, 1.x
Reporter: Matthias Schmidt
Priority: Minor
Attachments: 1529-display-geronimo-version.patch, showVersion.patch
One should be able to figure out geronimo's Version by:
a) looking in the Console, perhaps under Server Info
b) looking in the Logfiles.
for a) one can do the following:
---
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java
2006-01-23 14:57:59.0 +0100
+++
applications/console-standard/src/java/org/apache/geronimo/console/infomanager/ServerInfoPortlet.java.CHANGE
2006-01-23 15:02:27.0 +0100
@@ -34,6 +34,7 @@
import org.apache.geronimo.console.BasePortlet;
import org.apache.geronimo.console.util.PortletManager;
import org.apache.geronimo.management.geronimo.JVM;
+import org.apache.geronimo.console.GeronimoVersion;
/**
* Calculates various information about the server to display in the server
@@ -71,6 +72,8 @@
Date bootDate = jvm.getKernelBootTime();
svrProps.put(Kernel Boot Time, bootDate);
+svrProps.put(Geronimo Version, new
GeronimoVersion().GERONIMO_VERSION);
+
renderRequest.setAttribute(svrProps, svrProps);
jvmProps.put(Java Version, jvm.getJavaVersion());
---
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp
2006-01-11 17:34:52.0 +0100
+++
applications/console-standard/src/webapp/WEB-INF/view/infomanager/svrInfoNormal.jsp.CHANGE
2006-01-23 15:06:42.0 +0100
@@ -5,6 +5,7 @@
script type='text/javascript'
src='/console-standard/dwr/engine.js'/script
script type='text/javascript' src='/console-standard/dwr/util.js'/script
+
portlet:defineObjects/
table width=100%
@@ -19,6 +20,10 @@
td class=MediumBackgroundKernel Up Time/td
td class=MediumBackgrounddiv id=portlet:namespace/UpTimeNot
Yet Available/div/td
/tr
+ tr
+td class=LightBackground width=20% nowrapGeronimo Version/td
+td class=LightBackground width=80%${svrProps['Geronimo
Version']}/td
+ /tr
/table
br
!--
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1559) Console displays the incorrect locale
[ http://issues.apache.org/jira/browse/GERONIMO-1559?page=comments#action_12377128 ] Erin Mulder commented on GERONIMO-1559: --- The code in question just displays the value of the system property 'user.timezone'. I don't think there is anything that Geronimo can do if the JVM is reporting the wrong time zone. Console displays the incorrect locale - Key: GERONIMO-1559 URL: http://issues.apache.org/jira/browse/GERONIMO-1559 Project: Geronimo Type: Wish Security: public(Regular issues) Components: console Versions: 1.0 Environment: WinXP SP2 Reporter: Mihael Sedmak When listing the System Property values for the Server JVM, under the User section, the console displays user.timezone = Europe/Belgrade which is incorrect. The timezone on the machine which runs Geronimo is set to Sarajevo, Skopje, Warsaw, Zagreb -- 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-1769) Console should create links for all sections including the current section
[ http://issues.apache.org/jira/browse/GERONIMO-1769?page=all ] Erin Mulder updated GERONIMO-1769: -- Attachment: 1769-console-navigation-links.patch This patch preserves the current look of selected navigation items, but makes them into links so that you can always get back to the main page of a section. It also fixes a few other minor bugs and usability issues in the navigation menu. There is a lot more that could be done to clean up the CSS/layout in console-framework. However, it probably makes sense to move to Jetspeed first. Console should create links for all sections including the current section Key: GERONIMO-1769 URL: http://issues.apache.org/jira/browse/GERONIMO-1769 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0 Environment: Windows XP, JDK 1.5.0_05 Reporter: Joseph B. Ottinger Priority: Trivial Attachments: 1769-console-navigation-links.patch In the console, if I select JMS (for example) and want to go back to the main JMS page, I should be able to select JMS again. However, it's not a hyperlink if I'm in the JMS section. It should be! -- 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-1769) Console should create links for all sections including the current section
[ http://issues.apache.org/jira/browse/GERONIMO-1769?page=all ] Erin Mulder updated GERONIMO-1769: -- Patch Info: [Patch Available] Console should create links for all sections including the current section Key: GERONIMO-1769 URL: http://issues.apache.org/jira/browse/GERONIMO-1769 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0 Environment: Windows XP, JDK 1.5.0_05 Reporter: Joseph B. Ottinger Priority: Trivial Attachments: 1769-console-navigation-links.patch In the console, if I select JMS (for example) and want to go back to the main JMS page, I should be able to select JMS again. However, it's not a hyperlink if I'm in the JMS section. It should be! -- 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-1864) Deploy no longer starts a web application by default
[ http://issues.apache.org/jira/browse/GERONIMO-1864?page=all ] Erin Mulder updated GERONIMO-1864: -- Attachment: no-geronimo-plan.war I was not able to reproduce this bug using the attached WAR (which does not include a geronimo-web.xml). I ran the latest 1.1 branch (on Sun JVM 1.4.2_11, Linux), and tried about a dozen combinations of the following: * Tomcat, Jetty * WAR, exploded directory * Command-line deployer, hot-deploy directory, web console deployer All of them started the web application automatically after deployment. Deploy no longer starts a web application by default Key: GERONIMO-1864 URL: http://issues.apache.org/jira/browse/GERONIMO-1864 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Attachments: no-geronimo-plan.war I deployed a very simple web applicaion from the command line. The application deployed successfully and no error messages or any sort were issued (aside from the message the indicated a plan was not provided and a default plan would be used). When I couldn't access the application I checked and noticed that it had not been started. Another individual has also mentioned hitting the same problem so I don't believe it is unique to me. -- 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-1938) Plugins portlet 'help' link throws PortletException
[ http://issues.apache.org/jira/browse/GERONIMO-1938?page=all ] Erin Mulder updated GERONIMO-1938: -- Attachment: 1938-plugin-portlet-fixes.patch This patch updates portlet.xml to remove the Help link. It also fixes the name (Import/Export Plugins instead of Import/Export Configurations) Plugins portlet 'help' link throws PortletException --- Key: GERONIMO-1938 URL: http://issues.apache.org/jira/browse/GERONIMO-1938 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Chris Cardona Attachments: 1938-plugin-portlet-fixes.patch Not sure if this 'help' link should be removed since the 'view' link already gives a description of the portlet including how to use it. -- 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-1938) Plugins portlet 'help' link throws PortletException
[ http://issues.apache.org/jira/browse/GERONIMO-1938?page=all ] Erin Mulder updated GERONIMO-1938: -- Patch Info: [Patch Available] Plugins portlet 'help' link throws PortletException --- Key: GERONIMO-1938 URL: http://issues.apache.org/jira/browse/GERONIMO-1938 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Chris Cardona Attachments: 1938-plugin-portlet-fixes.patch Not sure if this 'help' link should be removed since the 'view' link already gives a description of the portlet including how to use it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1864) Deploy no longer starts a web application by default
[ http://issues.apache.org/jira/browse/GERONIMO-1864?page=all ] Joe Bohn resolved GERONIMO-1864: Resolution: Fixed I was discussing this problem with Aaron shortly after creating the JIRA and he integrated a fix. Hence the reason that Erin could not reproduce.This JIRA just never was marked as fixed. Deploy no longer starts a web application by default Key: GERONIMO-1864 URL: http://issues.apache.org/jira/browse/GERONIMO-1864 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Attachments: no-geronimo-plan.war I deployed a very simple web applicaion from the command line. The application deployed successfully and no error messages or any sort were issued (aside from the message the indicated a plan was not provided and a default plan would be used). When I couldn't access the application I checked and noticed that it had not been started. Another individual has also mentioned hitting the same problem so I don't believe it is unique to me. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1939) Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer
[ http://issues.apache.org/jira/browse/GERONIMO-1939?page=comments#action_12377138 ] Erin Mulder commented on GERONIMO-1939: --- Internet Explorer doesn't have built-in SVG support. Ideally, the page should prompt you to download the Adobe plugin. Is that happening? If not, we should try to figure out the right HTML magic and/or add a message with an explicit link. Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer - Key: GERONIMO-1939 URL: http://issues.apache.org/jira/browse/GERONIMO-1939 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Chris Cardona I've tested it to work on Firefox v1.5.0.2 but the graph doesn't show up on IE v6.0. -- 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: user-apps directory
Dain and I had talked about this on Friday. I think the direction needs to be to NOT have user artifacts in the Geronimo repo its just the way it is right now. I think the idea of making a groupId of user-apps is fine. Perhaps something like installedJ2EEApps would catch someone's eye faster. Dave Colasurdo wrote: Keeping with the theme of talking to myself.. I guess it is simpler to just change the groupid in the sample deployment plans to user-apps. Of course users are free to specify any groupid they want .. but the default in the sample plans that we provide (including our documentation) will result in the user applications being separated from the geronimo plumbing by naming convention without any code impact.. -Dave- Dave Colasurdo wrote: This reminds me of a topic from a few weeks ago.. Is there a JIRA open to address separating the end user applications from the geronimo internal plumbing? Specifically, /Geronimo-1.1/repository/geronimo/ seems like a strange spot for end user applications. Searching for deployed applications seems a bit like looking for a needle in the haystack. /Geronimo-1.1/repository/ has nearly 40 directories /Geronimo-1.1/repository/geronimo has nearly 70 directories. How about a simple /Geronimo-1.1/user-apps/ that contains only deployed user applications? Thanks -Dave- David Jencks (JIRA) wrote: remove config-store directories from assemblies, now that they aren't used any more --- Key: GERONIMO-1932 URL: http://issues.apache.org/jira/browse/GERONIMO-1932 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 modify the assembly plugin to not create the bogus empty unused obsolete config-store directory
Re: user-apps directory
+1...great idea. Matt Hogstrom wrote: Dain and I had talked about this on Friday. I think the direction needs to be to NOT have user artifacts in the Geronimo repo its just the way it is right now. I think the idea of making a groupId of user-apps is fine. Perhaps something like installedJ2EEApps would catch someone's eye faster. Dave Colasurdo wrote: Keeping with the theme of talking to myself.. I guess it is simpler to just change the groupid in the sample deployment plans to user-apps. Of course users are free to specify any groupid they want .. but the default in the sample plans that we provide (including our documentation) will result in the user applications being separated from the geronimo plumbing by naming convention without any code impact.. -Dave- Dave Colasurdo wrote: This reminds me of a topic from a few weeks ago.. Is there a JIRA open to address separating the end user applications from the geronimo internal plumbing? Specifically, /Geronimo-1.1/repository/geronimo/ seems like a strange spot for end user applications. Searching for deployed applications seems a bit like looking for a needle in the haystack. /Geronimo-1.1/repository/ has nearly 40 directories /Geronimo-1.1/repository/geronimo has nearly 70 directories. How about a simple /Geronimo-1.1/user-apps/ that contains only deployed user applications? Thanks -Dave- David Jencks (JIRA) wrote: remove config-store directories from assemblies, now that they aren't used any more --- Key: GERONIMO-1932 URL: http://issues.apache.org/jira/browse/GERONIMO-1932 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 modify the assembly plugin to not create the bogus empty unused obsolete config-store directory
EAR Child Modules
So I deployed an EAR with an EJB JAR and a WAR, but the ConfigurationData appears to include only the WAR in its list of child modules. Is that expected? I would still expect to see the EJB JAR listed as a child module even though it doesn't have it's own class loader, etc. Thanks, Aaron
Re: EAR Child Modules
That is the way it works. I'm not sure if there is anything we can do about this now, or if it is something we want to do something about. I don't really care either way. -dain On Apr 29, 2006, at 8:33 PM, Aaron Mulder wrote: So I deployed an EAR with an EJB JAR and a WAR, but the ConfigurationData appears to include only the WAR in its list of child modules. Is that expected? I would still expect to see the EJB JAR listed as a child module even though it doesn't have it's own class loader, etc. Thanks, Aaron
[jira] Created: (GERONIMO-1946) SingleFileHotDeploy does not correctly resolve the configuration ID.
SingleFileHotDeploy does not correctly resolve the configuration ID. Key: GERONIMO-1946 URL: http://issues.apache.org/jira/browse/GERONIMO-1946 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Environment: all Reporter: Joe Bohn Assigned to: Joe Bohn Fix For: 1.1 The resolve method included in the new SingleFileHotDeploy function has some processing to resolve a configuration ID that is not fully qualified. There is a small error that cases it to not be able to return the id that it did successfully resolve (it attempts to modify a reference to return the new configID which won't work with pass by reference). -- 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-1947) Repeat hot deployment of WARs with no Geronimo plan
Repeat hot deployment of WARs with no Geronimo plan --- Key: GERONIMO-1947 URL: http://issues.apache.org/jira/browse/GERONIMO-1947 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.0 Environment: Linux, Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode) Reporter: Erin Mulder Priority: Critical Fix For: 1.1 I created a WAR with no deployment plan (see attached no-geronimo-plan.war) and copied it to the hot deployment directory. Now, every time I start the server, it tries to deploy it again with a different version number. It does get an error at that point, but the console is showing N copies and the startup sequence is showing N-1, where N is the number of server restarts since I originally deployed it. Here's a snippet from the console: Component Name URL State Commands default/no-geronimo-plan/1146368518972/war /no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146368650976/war /no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146368847429/war /no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146369719473/war /no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146370013515/war /no-geronimo-plan running Stop Uninstall Here's what it looks like at startup: Booting Geronimo Kernel (in Java 1.4.2_11)... Starting Geronimo Application Server v.1.1-SNAPSHOT [**] 100% 22s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 127.0.0.1 Remote Login Listener 8019 127.0.0.1 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-SNAPSHOT/car RAR: geronimo/activemq/1.1-SNAPSHOT/car RAR: geronimo/system-database/1.1-SNAPSHOT/car WAR: default/no-geronimo-plan/1146368518972/war WAR: default/no-geronimo-plan/1146368650976/war WAR: default/no-geronimo-plan/1146368847429/war WAR: default/no-geronimo-plan/1146369719473/war WAR: geronimo/remote-deploy-jetty/1.1-SNAPSHOT/car WAR: geronimo/welcome-jetty/1.1-SNAPSHOT/car Web Applications: http://wildfire:8080/ http://wildfire:8080/console http://wildfire:8080/console-standard http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/remote-deploy Geronimo Application Server started 00:06:49,487 ERROR [DirectoryMonitor] Unable to scan file /files/dev/geronimo-1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/deploy/no-geronimo-plan.war during initialization java.lang.IllegalArgumentException: Invalid id: no-geronimo-plan at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:168) at org.apache.geronimo.deployment.hot.DirectoryHotDeployer.isFileDeployed(DirectoryHotDeployer.java:166) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(DirectoryMonitor.java:191) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:169) at java.lang.Thread.run(Thread.java:534) 00:06:53,496 INFO [Hot Deployer] Deploying no-geronimo-plan.war 00:06:53,840 WARN [JettyModuleBuilder] Web application does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. Deployed default/no-geronimo-plan/1146370013515/war @ http://wildfire:8080/no-geronimo-plan I'll clean out the server and try to reproduce from scratch. -- 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-1947) Repeat hot deployment of WARs with no Geronimo plan
[ http://issues.apache.org/jira/browse/GERONIMO-1947?page=all ] Erin Mulder updated GERONIMO-1947: -- Attachment: no-geronimo-plan.war Repeat hot deployment of WARs with no Geronimo plan --- Key: GERONIMO-1947 URL: http://issues.apache.org/jira/browse/GERONIMO-1947 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Environment: Linux, Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode) Reporter: Erin Mulder Priority: Critical Fix For: 1.1 Attachments: no-geronimo-plan.war I created a WAR with no deployment plan (see attached no-geronimo-plan.war) and copied it to the hot deployment directory. Now, every time I start the server, it tries to deploy it again with a different version number. It does get an error at that point, but the console is showing N copies and the startup sequence is showing N-1, where N is the number of server restarts since I originally deployed it. Here's a snippet from the console: Component NameURL State Commands default/no-geronimo-plan/1146368518972/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146368650976/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146368847429/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146369719473/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146370013515/war/no-geronimo-plan running Stop Uninstall Here's what it looks like at startup: Booting Geronimo Kernel (in Java 1.4.2_11)... Starting Geronimo Application Server v.1.1-SNAPSHOT [**] 100% 22s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 127.0.0.1 Remote Login Listener 8019 127.0.0.1 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-SNAPSHOT/car RAR: geronimo/activemq/1.1-SNAPSHOT/car RAR: geronimo/system-database/1.1-SNAPSHOT/car WAR: default/no-geronimo-plan/1146368518972/war WAR: default/no-geronimo-plan/1146368650976/war WAR: default/no-geronimo-plan/1146368847429/war WAR: default/no-geronimo-plan/1146369719473/war WAR: geronimo/remote-deploy-jetty/1.1-SNAPSHOT/car WAR: geronimo/welcome-jetty/1.1-SNAPSHOT/car Web Applications: http://wildfire:8080/ http://wildfire:8080/console http://wildfire:8080/console-standard http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/remote-deploy Geronimo Application Server started 00:06:49,487 ERROR [DirectoryMonitor] Unable to scan file /files/dev/geronimo-1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/deploy/no-geronimo-plan.war during initialization java.lang.IllegalArgumentException: Invalid id: no-geronimo-plan at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:168) at org.apache.geronimo.deployment.hot.DirectoryHotDeployer.isFileDeployed(DirectoryHotDeployer.java:166) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(DirectoryMonitor.java:191) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:169) at java.lang.Thread.run(Thread.java:534) 00:06:53,496 INFO [Hot Deployer] Deploying no-geronimo-plan.war 00:06:53,840 WARN [JettyModuleBuilder] Web application does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. Deployed default/no-geronimo-plan/1146370013515/war @ http://wildfire:8080/no-geronimo-plan I'll clean out the server and try to reproduce from scratch. -- 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-1946) SingleFileHotDeploy does not correctly resolve the configuration ID.
[ http://issues.apache.org/jira/browse/GERONIMO-1946?page=all ] Joe Bohn updated GERONIMO-1946: --- Attachment: 1946_SingleFileHotDeploy.patch SingleFileHotDeploy does not correctly resolve the configuration ID. Key: GERONIMO-1946 URL: http://issues.apache.org/jira/browse/GERONIMO-1946 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1 Attachments: 1946_SingleFileHotDeploy.patch The resolve method included in the new SingleFileHotDeploy function has some processing to resolve a configuration ID that is not fully qualified. There is a small error that cases it to not be able to return the id that it did successfully resolve (it attempts to modify a reference to return the new configID which won't work with pass by reference). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1946) SingleFileHotDeploy does not correctly resolve the configuration ID.
[ http://issues.apache.org/jira/browse/GERONIMO-1946?page=all ] Joe Bohn reassigned GERONIMO-1946: -- Assign To: Dain Sundstrom (was: Joe Bohn) SingleFileHotDeploy does not correctly resolve the configuration ID. Key: GERONIMO-1946 URL: http://issues.apache.org/jira/browse/GERONIMO-1946 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: all Reporter: Joe Bohn Assignee: Dain Sundstrom Fix For: 1.1 Attachments: 1946_SingleFileHotDeploy.patch The resolve method included in the new SingleFileHotDeploy function has some processing to resolve a configuration ID that is not fully qualified. There is a small error that cases it to not be able to return the id that it did successfully resolve (it attempts to modify a reference to return the new configID which won't work with pass by reference). -- 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
