Heads Up: big change to deployment
I just committed a big change to deployment... I have changed deployment to no longer build into a packed Jar file, instead it builds into a temp directory and once complete moves the temp directory into the config store. If a packed car file is needed, the deployer simply jars up the temp directory. This should make adding support for manifest class path entries trivial, as the standard URLClassLoader can handle like 80% of the cases. I also added code to meticulously track temp files and delete them asap... my old implementation left tons of temp files around. I haven't tested this on windows yet, but I heading over to my windows machine right now to test it. Can someone on linux check if the build works? Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
[jira] Updated: (GERONIMO-356) tomcat-plan.xml : Missing Dependency mx4j/jars/mx4j-2.0.1.jar
The following issue has been updated: Updater: Ralf Barkow (mailto:[EMAIL PROTECTED]) Date: Mon, 4 Oct 2004 4:04 PM Comment: Patched project.xml file (modules/tomcat/project.xml) Changes: Attachment changed to geronimoTomcat-project_xml.patch - For a full history of the issue, see: http://issues.apache.org/jira/browse/GERONIMO-356?page=history - View the issue: http://issues.apache.org/jira/browse/GERONIMO-356 Here is an overview of the issue: - Key: GERONIMO-356 Summary: tomcat-plan.xml : Missing Dependency mx4j/jars/mx4j-2.0.1.jar Type: Task Status: Unassigned Priority: Major Project: Apache Geronimo Components: buildsystem Tomcat Versions: 1.0-M3 Assignee: Reporter: Ralf Barkow Created: Mon, 4 Oct 2004 12:18 PM Updated: Mon, 4 Oct 2004 4:04 PM Description: Eclipse reported an error in line 88 of TomcatGBean.java: The type javax.management.MBeanRegistration cannot be resolved. It is indirectly referenced from required .class files. The error disappeared after adding MAVEN_REPO/mx4j/jars/mx4j-2.0.1.jar as classpath variable entry to the geronimo-tomcat project in my eclipse workspace. So, I think there is a dependency missing in tomcat-plan.xml (see attached patch). - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Heads Up: big change to deployment
Well looks like this doesn't work on windows. I don't think windows is letting me move the temp directory to the config store because the URLClassLoader on windows holds locks open on the jar files inside of the config store. I'll add some code that copies the files from the temp dir into the config store. I hope later we can just have our own implementation of URLClassLoader that we can call close on to release open file locks on windows. This shouldn't take about an hour to fix. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Oct 4, 2004, at 4:01 PM, Dain Sundstrom wrote: I just committed a big change to deployment... I have changed deployment to no longer build into a packed Jar file, instead it builds into a temp directory and once complete moves the temp directory into the config store. If a packed car file is needed, the deployer simply jars up the temp directory. This should make adding support for manifest class path entries trivial, as the standard URLClassLoader can handle like 80% of the cases. I also added code to meticulously track temp files and delete them asap... my old implementation left tons of temp files around. I haven't tested this on windows yet, but I heading over to my windows machine right now to test it. Can someone on linux check if the build works? Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Heads Up: big change to deployment
On Mon, 4 Oct 2004, Dain Sundstrom wrote: Can someone on linux check if the build works? At first glance, no: BUILD FAILED File.. /home/ammulder/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [multiproject:install-callback] -- /data/cvs/geronimo/modules/assembly/maven.xml:205:15: bootstrap:bootstrap Could not move source directory into config store: source=/tmp/geronimo-deployment-64539.tmp, destination=/data/cvs/geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/config-store/13 Total time: 3 minutes 1 seconds Finished at: Mon Oct 04 19:47:58 EDT 2004 Aaron
Re: Heads Up: big change to deployment
All that stuff worked for me on a fresh checkout on the windows pc I have hiding in the corner :) It looks like you didn't update openejb. I get an exception moving the temp dir into the config store. -dain On Oct 4, 2004, at 5:22 PM, Aaron Mulder wrote: Okay, when I tried a maven complete-rebuild, I got: The build cannot continue because of the following unsatisfied dependency: geronimo-client-builder-1.0-SNAPSHOT.jar If I try to build the client-builder module, it can't find some openejb stuff: data/cvs/geronimo/modules/client-builder/src/java/org/apache/geronimo/ client/builder/AppClientModuleBuilder.java:70: package org.openejb.client.naming does not exist import org.openejb.client.naming.RemoteEJBObjectFactory; ^ /data/cvs/geronimo/modules/client-builder/src/java/org/apache/ geronimo/client/builder/AppClientModuleBuilder.java:71: package org.openejb.client.naming does not exist import org.openejb.client.naming.RemoteEJBRefAddr; Then I tried a maven multiproject:install, and I got this: /data/cvs/geronimo/openejb/modules/core/src/java/org/openejb/ deployment/OpenEJBModuleBuilder.java:67: cannot resolve symbol symbol : class IOUtil location: package util import org.apache.geronimo.deployment.util.IOUtil; ^ /data/cvs/geronimo/openejb/modules/core/src/java/org/openejb/ deployment/OpenEJBModuleBuilder.java:68: cannot resolve symbol symbol : class JarUtil location: package util import org.apache.geronimo.deployment.util.JarUtil; ... It's hard to troubleshoot when I get a different error every time. :) Aaron On Mon, 4 Oct 2004, Aaron Mulder wrote: On Mon, 4 Oct 2004, Dain Sundstrom wrote: Can someone on linux check if the build works? At first glance, no: BUILD FAILED File.. /home/ammulder/.maven/cache/maven-multiproject-plugin-1.3.1/ plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [multiproject:install-callback] -- /data/cvs/geronimo/modules/assembly/maven.xml:205:15: bootstrap:bootstrap Could not move source directory into config store: source=/tmp/geronimo-deployment-64539.tmp, destination=/data/cvs/geronimo/modules/assembly/target/geronimo-1.0- SNAPSHOT/config-store/13 Total time: 3 minutes 1 seconds Finished at: Mon Oct 04 19:47:58 EDT 2004 Aaron
Re: Heads Up: big change to deployment
There is still a bug with resolving URIs on Windows. It looks like you can't resolve an absolute file location (e.g., c:\a\b\c) against a file uri unless you specify the file protocol on the uri. Anyway, I'm about to commit it... just verifying the change. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Oct 4, 2004, at 6:46 PM, Aaron Mulder wrote: On Mon, 4 Oct 2004, Dain Sundstrom wrote: All that stuff worked for me on a fresh checkout on the windows pc I have hiding in the corner :) It looks like you didn't update openejb. I get an exception moving the temp dir into the config store. You're right -- I had to update all the child projects first. Then I was back to the same error as before, but it seems to be working fine after your latest commit. Aaron
Delete your temp files
Part of the deployment system rewrite was an effort to clean up our handling of temp files. I carefully went though our entire active code base (1) searching for places where we create temp a file or directory, and added code that explicitly deletes the file or directory. Since we are writing a server that could run for months (assuming we get everything right), we can not rely on the VM's deleteOnExit for files and we have no such hook for temp directories. Right now there should be no place, including test code, where we leave a temp file. This change was long and tedious, and I don't want to have to do it again, so please please please be careful to delete your temp file as soon as possible after creating it. -dain (1) active being everything in our normal build process which excludes specs, sandbox and axis.
Questions on Geronimo clustering support
Hi, I am trying to get a feel for how EJB/JNDI clustering will be implemented in Geronimo and when it might be implemented. I remember reading somewhere in the mail archives that the clustering module in Geronimo has been abandoned and that ActiveCluster will be used. Is it envisaged that another clustering module will be developed or the existing one changed? Is EJB/JNDI clustering planned to be supported in the Geronimo 1.0 release or is this non-essential functionality that will be in a later release? Is the WADI project planning on providing EJB Tier clustering in addition to Web Tier clustering? Thanks, John
[jira] Created: (GERONIMO-359) OpenEJB does not convert RollbackExceptions to TransactionRolledBack[Local]Exception
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-359 Here is an overview of the issue: - Key: GERONIMO-359 Summary: OpenEJB does not convert RollbackExceptions to TransactionRolledBack[Local]Exception Type: Bug Status: Unassigned Priority: Major Project: Apache Geronimo Components: OpenEJB Versions: 1.0-M2 Assignee: Reporter: David Jencks Created: Mon, 4 Oct 2004 9:34 PM Updated: Mon, 4 Oct 2004 9:34 PM Description: TransactionRolledBack[Local]Exception is not referenced in OpenEJB. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
cdejb deploy not working
It would appear to me that openejb is a bit buggy and readily throws exceptions rather than diagnostics when it is unhappy with or confused by a configuration. So, I present the following to see if anyone else thinks openejb is messing up in this particular case. I was trying to get Kevin Boone's cdejb project to work in Geronimo, mainly as an exercise to see if I could get the configuration right. It's an EJB demo that's been around for ages and has worked in many versions of JBoss (see http://www.kevinboone.com/webapptut.pdf). When deploying cd.jar, I get the following exception from openejb: [EMAIL PROTECTED] cdejb]$ make deploy java -jar /home/craigj/geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar --install --module cd.jar org.apache.geronimo.deployment.DeploymentException: Unable to initialize EJBContainer GBean: ejbName=CDBean at org.openejb.deployment.CMPEntityBuilder.createBean(CMPEntityBuilder.java:270) at org.openejb.deployment.CMPEntityBuilder.buildBeans(CMPEntityBuilder.java:104) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:393) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:332) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:145) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:82) at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231) at org.apache.geronimo.system.main.CommandLine.init(CommandLine.java:106) at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:64) Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 at org.openejb.entity.cmp.CMPInstanceContextFactory.init(CMPInstanceContextFactory.java:125) at org.openejb.entity.cmp.CMPContainerBuilder.buildIt(CMPContainerBuilder.java:260) at org.openejb.AbstractContainerBuilder.createConfiguration(AbstractContainerBuilder.java:332) at org.openejb.deployment.CMPEntityBuilder.createBean(CMPEntityBuilder.java:265) ... 8 more Is there anything obviously wrong with the following ejb-jar.xml file? ?xml version=1.0 encoding=US-ASCII? ejb-jar xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd; version=2.1 display-nameMusicCDs/display-name enterprise-beans entity descriptionModels a music CD/description ejb-nameCDBean/ejb-name homecom.web_tomorrow.cd.CDHome/home remotecom.web_tomorrow.cd.CD/remote ejb-classcom.web_tomorrow.cd.CDBean/ejb-class persistence-typeContainer/persistence-type prim-key-classjava.lang.String/prim-key-class reentrantfalse/reentrant cmp-version2.x/cmp-version !-- Get exception in CMPEntityBuilder if following omitted. -- abstract-schema-nameBasicCmp/abstract-schema-name cmp-fieldfield-nameid/field-name/cmp-field cmp-fieldfield-nametitle/field-name/cmp-field cmp-fieldfield-nameartist/field-name/cmp-field cmp-fieldfield-nametype/field-name/cmp-field cmp-fieldfield-namenotes/field-name/cmp-field primkey-fieldid/primkey-field /entity session descriptionModels a music CD collection/description ejb-nameCDCollectionBean/ejb-name homecom.web_tomorrow.cd.CDCollectionHome/home remotecom.web_tomorrow.cd.CDCollection/remote ejb-classcom.web_tomorrow.cd.CDCollectionBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type ejb-ref ejb-ref-nameejb/CD/ejb-ref-name ejb-ref-typeEntity/ejb-ref-type homecom.web_tomorrow.cd.CDHome/home remotecom.web_tomorrow.cd.CD/remote ejb-linkCDBean/ejb-link /ejb-ref /session /enterprise-beans assembly-descriptor container-transaction method ejb-nameCDBean/ejb-name method-name*/method-name /method trans-attributeRequired/trans-attribute /container-transaction /assembly-descriptor /ejb-jar This might be caused by MethodHelper.getSuperIndex(enhancedClass, signature) returning -1, which probably means it didn't find some method. For reference, here is the openejb-jar.xml file: ?xml version=1.0? openejb-jar xmlns=http://www.openejb.org/xml/ns/openejb-jar; configId=my/cdejb parentId=org/apache/geronimo/DefaultDatabase cmp-connection-factoryDefaultDatasource/cmp-connection-factory enterprise-beans session ejb-nameCDCollectionBean/ejb-name jndi-namecd/CDCollection/jndi-name /session entity ejb-nameCDBean/ejb-name jndi-namecd/CD/jndi-name /entity /enterprise-beans /openejb-jar Cheers, Craig
[jira] Created: (GERONIMO-360) wrong tx policy for at least StatefulSession ejbCreate method
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-360 Here is an overview of the issue: - Key: GERONIMO-360 Summary: wrong tx policy for at least StatefulSession ejbCreate method Type: Bug Status: Unassigned Priority: Major Project: Apache Geronimo Components: OpenEJB Versions: 1.0-M2 Assignee: Reporter: David Jencks Created: Mon, 4 Oct 2004 11:03 PM Updated: Mon, 4 Oct 2004 11:03 PM Description: Spec (2.1, p 88, note at top) indicates that the ejbCreate (and other) method(s) of a SFSB should execute in an unspecified tx context. Getting a stack trace to the itest BasicStatefulBean ejbCreate reveals that the call goes through the Required tx policy rather than NotSupported policy. Why this hasn't been causing an itest failure is not clear, but it will soon. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-352) TransactionContext is not associated with imported transactions
The following comment has been added to this issue: Author: David Jencks Created: Tue, 5 Oct 2004 12:04 AM Body: This is fixed, but an additional refactoring and simplification is possible, namely to create a new ImportedTransactionContext class that includes the info in the inner TransactionContextManager.ImportedTransactionInfo class. - View this comment: http://issues.apache.org/jira/browse/GERONIMO-352?page=comments#action_53702 - View the issue: http://issues.apache.org/jira/browse/GERONIMO-352 Here is an overview of the issue: - Key: GERONIMO-352 Summary: TransactionContext is not associated with imported transactions Type: Bug Status: Open Priority: Major Project: Apache Geronimo Components: connector Versions: 1.0-M2 Assignee: David Jencks Reporter: David Jencks Created: Sun, 3 Oct 2004 10:08 AM Updated: Tue, 5 Oct 2004 12:04 AM Description: The WorkManager starts and ends imported transactions by directly interacting with the XAWork interface, implemented by the TransactionManagerProxy. Whether or not there is a TransactionContext associated with this transaction, it won't be repeatedly associated with the multiple calls in the same transaction, thus losing ejb caching/dirty info etc. Solution: the tx import interfaces should be moved out into TransactionContextManager. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: svn commit: rev 51860 - geronimo/trunk/modules/assembly/src/plan
[EMAIL PROTECTED] wrote: +reference name=serverInfogeronimo.system:role=ServerInfo/reference attribute name=Url type=java.lang.Stringtcp://localhost:61616/attribute reference name=ActiveMQContainergeronimo.server:type=JMSServer,container=ActiveMQ/reference That's just struck me that I'm not sure how the discussion ended up regarding the case of a attribute's name? Should it be written in the lower- or uppercase? Or it doesn't matter? Jacek
Re: svn commit: rev 47628 - in geronimo/trunk/modules: j2ee/src/java/org/apache/geronimo/j2ee/deployment j2ee/src/test/org/apache/geronimo/j2ee/deployment naming/src/java/org/apache/geronimo/naming/deployment
[EMAIL PROTECTED] wrote: Author: dain Date: Thu Sep 30 22:13:01 2004 New Revision: 47628 Added: geronimo/trunk/modules/j2ee/src/java/org/apache/geronimo/j2ee/deployment/EJBRefInfo.java + * @version $Revision$ $Date$ Let's try it again, Dain, could you update the templates to use $Rev$ instead of $Revision$? Jacek
Re: RMI startup failure
David Blevins wrote: Seems we're getting classloading issues from our RMIClassLoaderSpi. After a clean build, this no workie. $ cd modules/assembly/target/geronimo-1.0-SNAPSHOT $ java -Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoaderSpiImpl -jar bin/server.jar It fails with the attached output. If I do the same thing in OpenEJB, it's all good. $ cd openejb/modules/assembly/target/openejb-2.0-SNAPSHOT $ java -Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoaderSpiImpl -jar bin/server.jar We got something goofy with our plans? Looks like a conflict with something in JMXRemoting. But I am concerned that something needs special commmand line properties to start and would assume due to that the RMIClassLoaderSPIImpl has not been used in quite a while. -- Jeremy
Re: RMI startup failure
I feel your pain:-) I get these errors whenever I include that in a geronimo deploy plugin startRemoteServer command. As you say, it doesn't seem to be a problem with openejb. david jencks On Oct 5, 2004, at 1:47 AM, David Blevins wrote: Seems we're getting classloading issues from our RMIClassLoaderSpi. After a clean build, this no workie. $ cd modules/assembly/target/geronimo-1.0-SNAPSHOT $ java -Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoa derSpiImpl -jar bin/server.jar It fails with the attached output. If I do the same thing in OpenEJB, it's all good. $ cd openejb/modules/assembly/target/openejb-2.0-SNAPSHOT $ java -Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoa derSpiImpl -jar bin/server.jar We got something goofy with our plans? -Davidstartup-error.log
Re: svn commit: rev 51860 - geronimo/trunk/modules/assembly/src/plan
On Oct 5, 2004, at 3:04 AM, Jacek Laskowski wrote: [EMAIL PROTECTED] wrote: +reference name=serverInfogeronimo.system:role=ServerInfo/reference attribute name=Url type=java.lang.Stringtcp://localhost:61616/attribute reference name=ActiveMQContainergeronimo.server: type=JMSServer,container=ActiveMQ/reference That's just struck me that I'm not sure how the discussion ended up regarding the case of a attribute's name? Should it be written in the lower- or uppercase? Or it doesn't matter? The current convention is for attributes to follow Java variable naming conventions (i.e., lower case first character camel cased after) and for references to follow Java class naming conventions (i.e., capital first character camel cased after). -dain
Re: svn commit: rev 47628 - in geronimo/trunk/modules: j2ee/src/java/org/apache/geronimo/j2ee/deployment j2ee/src/test/org/apache/geronimo/j2ee/deployment naming/src/java/org/apache/geronimo/naming/deployment
On Oct 5, 2004, at 4:19 AM, Jacek Laskowski wrote: [EMAIL PROTECTED] wrote: Author: dain Date: Thu Sep 30 22:13:01 2004 New Revision: 47628 Added: geronimo/trunk/modules/j2ee/src/java/org/apache/geronimo/j2ee/ deployment/EJBRefInfo.java + * @version $Revision$ $Date$ Let's try it again, Dain, could you update the templates to use $Rev$ instead of $Revision$? Doh! I thought I fixed that. -dain
Re: RMI startup failure
That's exactly what I'm trying to do. Need this for the Geronimo itests to run. -David On Tue, Oct 05, 2004 at 08:02:39AM -0700, David Jencks wrote: I feel your pain:-) I get these errors whenever I include that in a geronimo deploy plugin startRemoteServer command. As you say, it doesn't seem to be a problem with openejb. david jencks On Oct 5, 2004, at 1:47 AM, David Blevins wrote: Seems we're getting classloading issues from our RMIClassLoaderSpi. After a clean build, this no workie. $ cd modules/assembly/target/geronimo-1.0-SNAPSHOT $ java -Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoa derSpiImpl -jar bin/server.jar It fails with the attached output. If I do the same thing in OpenEJB, it's all good. $ cd openejb/modules/assembly/target/openejb-2.0-SNAPSHOT $ java -Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoa derSpiImpl -jar bin/server.jar We got something goofy with our plans? -Davidstartup-error.log
RE: svn commit: rev 51860 - geronimo/trunk/modules/assembly/src/plan
-Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] The current convention is for attributes to follow Java variable naming conventions (i.e., lower case first character camel cased after) and for references to follow Java class naming conventions (i.e., capital first character camel cased after). This is good Wiki info. How do I edit an immutable page? Regards, Alan - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
Re: svn commit: rev 51860 - geronimo/trunk/modules/assembly/src/plan
On Oct 5, 2004, at 9:24 AM, Alan Cabrera wrote: -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] The current convention is for attributes to follow Java variable naming conventions (i.e., lower case first character camel cased after) and for references to follow Java class naming conventions (i.e., capital first character camel cased after). This is good Wiki info. How do I edit an immutable page? First you spend an hour trying to get a login to MoinMoin... then you spend another hour trying to figure out how to make MoinMoin line up the text on the page correctly. Have Fun :( -dain
Re: svn commit: rev 51860 - geronimo/trunk/modules/assembly/src/plan
On Tue, 5 Oct 2004, Dain Sundstrom wrote: First you spend an hour trying to get a login to MoinMoin... then you spend another hour trying to figure out how to make MoinMoin line up the text on the page correctly. That's okay, you would have just spent those two hours reading Slashdot anyway. :) Aaron
[jira] Closed: (GERONIMO-249) Ear, war, ejb-jar, and rar manifest Class-Path entries are ignored by configuration builders
Message: The following issue has been closed. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-249 Here is an overview of the issue: - Key: GERONIMO-249 Summary: Ear, war, ejb-jar, and rar manifest Class-Path entries are ignored by configuration builders Type: Bug Status: Closed Priority: Major Resolution: FIXED Project: Apache Geronimo Components: deployment Fix Fors: 1.0-M3 Versions: 1.0-M1 Assignee: Dain Sundstrom Reporter: Simon Godik Created: Mon, 21 Jun 2004 11:20 PM Updated: Tue, 5 Oct 2004 10:20 AM Description: I have an EAR which contains an EJB-JAR which has a Class-Path entry to another library jar. During deployment I get a NoClassDefFoundError for classes that are in that library jar as it can't find it in the temp directory. Trying to use a dependency in the EAR doesn't help - are these supported? - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: RMI startup failure
My theory is that this is a client side problem and that the list of dependencies in project.xml is different in the openejb itests and geronimo and activemq itests. I haven't investigated yet though. david jencks On Oct 5, 2004, at 9:33 AM, David Blevins wrote: On Tue, Oct 05, 2004 at 10:16:16AM -0400, Alan Cabrera wrote: -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 10:06 AM To: [EMAIL PROTECTED] Subject: Re: RMI startup failure David Blevins wrote: Seems we're getting classloading issues from our RMIClassLoaderSpi. After a clean build, this no workie. $ cd modules/assembly/target/geronimo-1.0-SNAPSHOT $ java - Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoa de rS piImpl -jar bin/server.jar It fails with the attached output. If I do the same thing in OpenEJB, it's all good. $ cd openejb/modules/assembly/target/openejb-2.0-SNAPSHOT $ java - Djava.rmi.server.RMIClassLoaderSpi=org.apache.geronimo.rmi.RMIClassLoa de rS piImpl -jar bin/server.jar We got something goofy with our plans? Looks like a conflict with something in JMXRemoting. But I am concerned that something needs special commmand line properties to start and would assume due to that the RMIClassLoaderSPIImpl has not been used in quite a while. A gentle reminder, people who have spaces in their home directory will need to use RMIClassLoaderSPIImpl. You have any idea on why using this in Geronimo would fail? What GBean that relies upon the RMIClassLoaderSpi and what classloader should the RMIClassLoaderSpi be in? -David
[jira] Created: (GERONIMO-361) Switch Jetty downloads back to ibiblio or mortbay
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-361 Here is an overview of the issue: - Key: GERONIMO-361 Summary: Switch Jetty downloads back to ibiblio or mortbay Type: Task Status: Unassigned Priority: Major Project: Apache Geronimo Assignee: Reporter: Jeremy Boynes Created: Tue, 5 Oct 2004 10:30 AM Updated: Tue, 5 Oct 2004 10:30 AM Description: org.mortbay.jetty-5.1-SNAPSHOT.jar is currently being downloaded from my home directory due to delays in SF.net updates and/or snapshots at mortbay. This needs to move back to ibiblio or mortbay - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-300) Deployer reports a wrong cause when a given module doesn't exist
The following issue has been updated: Updater: Dain Sundstrom (mailto:[EMAIL PROTECTED]) Date: Tue, 5 Oct 2004 11:00 AM Changes: Version changed from 1.0-M3 - For a full history of the issue, see: http://issues.apache.org/jira/browse/GERONIMO-300?page=history - View the issue: http://issues.apache.org/jira/browse/GERONIMO-300 Here is an overview of the issue: - Key: GERONIMO-300 Summary: Deployer reports a wrong cause when a given module doesn't exist Type: Bug Status: Unassigned Priority: Trivial Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Reporter: Jacek Laskowski Created: Thu, 16 Sep 2004 1:50 PM Updated: Tue, 5 Oct 2004 11:00 AM Description: When Deployer is invoked with a module that doesn't exist it reports a wrong cause: $ (cd target/geronimo-1.0-SNAPSHOT; java -jar bin/deployer.jar --module non/existing/module) org.apache.geronimo.deployment.DeploymentException: No deployer found for this module type: file:/c:/projects/geronimo/t runk/modules/assembly/target/geronimo-1.0-SNAPSHOT/non/existing/module at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:168) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142) at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:765) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerIntercep tor.java:205) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231) at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:93) It should validate if a given module exists at all before handing it over to module deployers. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-300) Deployer reports a wrong cause when a given module doesn't exist
Message: The following issue has been closed. Resolver: Dain Sundstrom Date: Tue, 5 Oct 2004 11:00 AM I added a bunch more checks for missing files and such - View the issue: http://issues.apache.org/jira/browse/GERONIMO-300 Here is an overview of the issue: - Key: GERONIMO-300 Summary: Deployer reports a wrong cause when a given module doesn't exist Type: Bug Status: Closed Priority: Trivial Resolution: FIXED Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Reporter: Jacek Laskowski Created: Thu, 16 Sep 2004 1:50 PM Updated: Tue, 5 Oct 2004 11:00 AM Description: When Deployer is invoked with a module that doesn't exist it reports a wrong cause: $ (cd target/geronimo-1.0-SNAPSHOT; java -jar bin/deployer.jar --module non/existing/module) org.apache.geronimo.deployment.DeploymentException: No deployer found for this module type: file:/c:/projects/geronimo/t runk/modules/assembly/target/geronimo-1.0-SNAPSHOT/non/existing/module at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:168) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:87) at org.apache.geronimo.gbean.jmx.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142) at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:765) at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121) at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerIntercep tor.java:205) at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231) at org.apache.geronimo.system.main.CommandLine.main(CommandLine.java:93) It should validate if a given module exists at all before handing it over to module deployers. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-284) alt-dd is not implemented
Message: The following issue has been closed. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-284 Here is an overview of the issue: - Key: GERONIMO-284 Summary: alt-dd is not implemented Type: Bug Status: Closed Priority: Minor Resolution: FIXED Project: Apache Geronimo Components: deployment Fix Fors: 1.0-M3 Versions: 1.0-M1 Assignee: Gianny DAMOUR Reporter: Gianny DAMOUR Created: Sun, 8 Aug 2004 1:45 AM Updated: Tue, 5 Oct 2004 11:05 AM Description: The optional alt-dd element associated to a module within an application.xml file is not used. Moreover, it could be useful to have the capability to provide an alt-dd element for Geronimo specific DD within geronimo-application.xml. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: RMI startup failure
On Tue, Oct 05, 2004 at 11:33:14AM -0500, David Blevins wrote: Looks like a conflict with something in JMXRemoting. But I am concerned that something needs special commmand line properties to start and would assume due to that the RMIClassLoaderSPIImpl has not been used in quite a while. A gentle reminder, people who have spaces in their home directory will need to use RMIClassLoaderSPIImpl. You have any idea on why using this in Geronimo would fail? What GBean that relies upon the RMIClassLoaderSpi and what classloader should the RMIClassLoaderSpi be in? To answer part of my own question, the RMIClassLoaderSpi provider must be in the system classloader. Worse yet, the provider is instaniated and assigned to a private static final in RMIClassLoader. It works in OpenEJB because it has geronimo-core in the manifest class-path of it's server.jar, I just need to add that to Geronimo's server.jar as well. As far as the other question of who relies on it, it's hard to tell... -- The RMIClassLoaderSpi is supplied on the command line -- The RMIRegistryService is in the system package -- The RMIClassLoaderSpiImpl is in the core package -- The JMXConnector in jmxremoting seems to be the only thing that actually breaks when the above three things go wrong. -David
[jira] Created: (GERONIMO-362) Problem with proxies for ConnectionFactories
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-362 Here is an overview of the issue: - Key: GERONIMO-362 Summary: Problem with proxies for ConnectionFactories Type: Bug Status: Unassigned Priority: Major Project: Apache Geronimo Assignee: Reporter: Jeremy Boynes Created: Tue, 5 Oct 2004 12:00 PM Updated: Tue, 5 Oct 2004 12:00 PM Description: The ActiveMQ Connector is being deployed with the connectionfactory-interface being set to javax.jms.ConnectionFactory which is a superclass of QueueConnectionFactory and TopicConnectionFactory. A resource-ref that references this with the interface defined as one of the subclasses does not work as the generated proxy does not implement the subclasses. Being able to deploy a single instance of the superclass seems useful but we need to verify if that is compliant. If it is, then we would also need to ensure the proxy implements the appropriate interfaces (specifically the subclass being requested). Adding proxies is useful in that allows access to the resource to be shut off or suspended in repsonse to the target's lifecycle. However, in some cases those proxies may be passed back to the resource and may cause problems unless they are unwrapped to expose the original object. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-362) Problem with proxies for ConnectionFactories
The following comment has been added to this issue: Author: Jeremy Boynes Created: Tue, 5 Oct 2004 12:00 PM Body: A workaround for now is simply to return the original object rather than proxying it. - View this comment: http://issues.apache.org/jira/browse/GERONIMO-362?page=comments#action_53723 - View the issue: http://issues.apache.org/jira/browse/GERONIMO-362 Here is an overview of the issue: - Key: GERONIMO-362 Summary: Problem with proxies for ConnectionFactories Type: Bug Status: Unassigned Priority: Major Project: Apache Geronimo Assignee: Reporter: Jeremy Boynes Created: Tue, 5 Oct 2004 12:00 PM Updated: Tue, 5 Oct 2004 12:00 PM Description: The ActiveMQ Connector is being deployed with the connectionfactory-interface being set to javax.jms.ConnectionFactory which is a superclass of QueueConnectionFactory and TopicConnectionFactory. A resource-ref that references this with the interface defined as one of the subclasses does not work as the generated proxy does not implement the subclasses. Being able to deploy a single instance of the superclass seems useful but we need to verify if that is compliant. If it is, then we would also need to ensure the proxy implements the appropriate interfaces (specifically the subclass being requested). Adding proxies is useful in that allows access to the resource to be shut off or suspended in repsonse to the target's lifecycle. However, in some cases those proxies may be passed back to the resource and may cause problems unless they are unwrapped to expose the original object. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: RMI startup failure
David Blevins wrote: To answer part of my own question, the RMIClassLoaderSpi provider must be in the system classloader. Worse yet, the provider is instaniated and assigned to a private static final in RMIClassLoader. It works in OpenEJB because it has geronimo-core in the manifest class-path of it's server.jar, I just need to add that to Geronimo's server.jar as well. Perhaps better would be to move this class into common or system to avoid placing the junk drawer on the system classpath. -- Jeremy
Re: RMI startup failure
On Tue, Oct 05, 2004 at 12:14:37PM -0700, Jeremy Boynes wrote: David Blevins wrote: To answer part of my own question, the RMIClassLoaderSpi provider must be in the system classloader. Worse yet, the provider is instaniated and assigned to a private static final in RMIClassLoader. It works in OpenEJB because it has geronimo-core in the manifest class-path of it's server.jar, I just need to add that to Geronimo's server.jar as well. Perhaps better would be to move this class into common or system to avoid placing the junk drawer on the system classpath. Works for me. -David
Important: maven command line options
I'm thinking about using the maven multiproject plugin as replacement for our current reactor build. Before I do this, I'd like to know which options of our current build people are using... Are you using any of the following command line options module.types Comma seperated list of module types (ie. specs or modules) module.includes Comma seperated list of module names (ie. common, core, ...) modules Same as module.includes, module.includes initializes to this value module.excludes Comma seperated list of module names to exclude Also if you are using anything off the beaten path let me know. Thanks, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
[jira] Commented: (GERONIMO-362) Problem with proxies for ConnectionFactories
The following comment has been added to this issue: Author: David Jencks Created: Tue, 5 Oct 2004 1:02 PM Body: I've modified the admin object deployment to return the actual admin object rather than a proxy. I'm reluctant to apply the same change to connection factories because I think we may get in trouble with serialization. The current proxies are serializable and work (on the same vm) when deserialized. If this is not a requirement (e.g. during passivate/activate) I can implement this for connection factories. Meanwhile I think you have to declare the jms connection factory twice in ra.xml, once for QueueConnectionFactory and once for TopicConnectionFactory. - View this comment: http://issues.apache.org/jira/browse/GERONIMO-362?page=comments#action_53726 - View the issue: http://issues.apache.org/jira/browse/GERONIMO-362 Here is an overview of the issue: - Key: GERONIMO-362 Summary: Problem with proxies for ConnectionFactories Type: Bug Status: Unassigned Priority: Major Project: Apache Geronimo Assignee: Reporter: Jeremy Boynes Created: Tue, 5 Oct 2004 12:00 PM Updated: Tue, 5 Oct 2004 1:02 PM Description: The ActiveMQ Connector is being deployed with the connectionfactory-interface being set to javax.jms.ConnectionFactory which is a superclass of QueueConnectionFactory and TopicConnectionFactory. A resource-ref that references this with the interface defined as one of the subclasses does not work as the generated proxy does not implement the subclasses. Being able to deploy a single instance of the superclass seems useful but we need to verify if that is compliant. If it is, then we would also need to ensure the proxy implements the appropriate interfaces (specifically the subclass being requested). Adding proxies is useful in that allows access to the resource to be shut off or suspended in repsonse to the target's lifecycle. However, in some cases those proxies may be passed back to the resource and may cause problems unless they are unwrapped to expose the original object. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-363) Better logging for Work exceptions
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-363 Here is an overview of the issue: - Key: GERONIMO-363 Summary: Better logging for Work exceptions Type: Improvement Status: Open Priority: Major Project: Apache Geronimo Components: connector Fix Fors: 1.0-M3 Versions: 1.0-M2 Assignee: Aaron Mulder Reporter: Aaron Mulder Created: Tue, 5 Oct 2004 1:28 PM Updated: Tue, 5 Oct 2004 1:28 PM Description: When a connector submits a Work and that Work throws an exception, the server silently consumes it unless the connector also supplied a WorkListener. This should be changed so the error is logged to the console in the absence of a WorkListener. - JIRA INFORMATION: 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 If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Important: maven command line options
On Tue, Oct 05, 2004 at 12:50:40PM -0700, Dain Sundstrom wrote: I'm thinking about using the maven multiproject plugin as replacement for our current reactor build. Before I do this, I'd like to know which options of our current build people are using... Are you using any of the following command line options module.types Comma seperated list of module types (ie. specs or modules) module.includes Comma seperated list of module names (ie. common, core, ...) modules Same as module.includes, module.includes initializes to this value module.excludes Comma seperated list of module names to exclude I use -Dmodules=foo,bar,assembly on a fairly regular basis. You trying to figure out which ones are worth the pain of adding to multiproject?
Re: Important: maven command line options
This is a little off topic, but it would be nice to have a target that does nothing but update any third-party libraries that have changed, so you could run that once and then do maven -o instead of having to run maven online and have it attempt to download the same libraries dozens of times each -- and worse yet, if the build fails, you need to run online next time too because you never know if it got all the updates before it died. Anyway, as far as the real question goes, I use -Dmodules=... sometimes but it wouldn't break my heart if I had to change to the appropriate directory and run maven there instead. Aaron On Tue, 5 Oct 2004, David Blevins wrote: On Tue, Oct 05, 2004 at 12:50:40PM -0700, Dain Sundstrom wrote: I'm thinking about using the maven multiproject plugin as replacement for our current reactor build. Before I do this, I'd like to know which options of our current build people are using... Are you using any of the following command line options module.types Comma seperated list of module types (ie. specs or modules) module.includes Comma seperated list of module names (ie. common, core, ...) modules Same as module.includes, module.includes initializes to this value module.excludes Comma seperated list of module names to exclude I use -Dmodules=foo,bar,assembly on a fairly regular basis. You trying to figure out which ones are worth the pain of adding to multiproject?
Re: Frontend tools
On Oct 5, 2004, at 1:00 PM, Geir Magnusson Jr wrote: On Oct 4, 2004, at 11:17 AM, Aaron Mulder wrote: I know the main developer of MC4J, a cool (Swing-based) JMX management console -- check out the screen shots and stuff. (His name is Greg Hinkle) I was using mc4j. I liked it. I hope to get Greg on board with Geronimo. If so, and if that project continues to use (what is essentially) the Mozilla Public License, would we be able to distribute it as part of Geronimo? Yes last time I looked at it, it required the netbeans runtime environment which was H_U_G_E... does anyone know if he has a standalone swing (or swt) version yet? -dain
Re: Important: maven command line options
On Oct 5, 2004, at 1:39 PM, David Blevins wrote: On Tue, Oct 05, 2004 at 12:50:40PM -0700, Dain Sundstrom wrote: I'm thinking about using the maven multiproject plugin as replacement for our current reactor build. Before I do this, I'd like to know which options of our current build people are using... Are you using any of the following command line options module.types Comma seperated list of module types (ie. specs or modules) module.includes Comma seperated list of module names (ie. common, core, ...) modules Same as module.includes, module.includes initializes to this value module.excludes Comma seperated list of module names to exclude I use -Dmodules=foo,bar,assembly on a fairly regular basis. You trying to figure out which ones are worth the pain of adding to multiproject? Yes.. the good news is I think that is the easy one to implement :) -dain
Re: Frontend tools
On Tue, 5 Oct 2004, Dain Sundstrom wrote: last time I looked at it, it required the netbeans runtime environment which was H_U_G_E... does anyone know if he has a standalone swing (or swt) version yet? -- Forwarded message -- Date: Tue, 5 Oct 2004 17:13:24 -0400 (EDT) From: Greg Hinkle [EMAIL PROTECTED] To: Aaron Mulder [EMAIL PROTECTED] Subject: Re: Frontend tools (fwd) Hey... that's cool. I'll make sure Geronimo has first class (relatively speaking of course) support for this release. Unfortunately I'm only going to be able to do so much about the size. I've cut out all server dependencies (you point at your install during use), but I'm tightly tied to the netbeans platform :( and I also use some cool utilities like JGraph. I'll probably only get it down to about an 8 meg install... but we'll see.
