RE: Unit/Stress Tests
True enough. One thing I think that we should not normally run is tests that require hand configuration to truly run well. For example, the GSSAPI tests, if you don't have Kerberos running on your machine, then it will take more than a few minutes to complete. Maybe we could name those tests *ConfiguableTest.java and just exclude those. Alan -Original Message- From: David Blevins [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 03, 2004 10:26 AM To: [EMAIL PROTECTED] Subject: Re: Unit/Stress Tests On Tue, Aug 03, 2004 at 08:41:44AM -0400, Alan D. Cabrera wrote: IMHO, if something breaks for them, then something is broken for their configuration and they should know about it; this is the raison d'etre of unit tests. I agree with the raison d'etre of unit tests, was talking about stress tests which I think are beasts of a different nature. -David
[status] build: SUCCESSFUL, test: SUCCESSFUL | Linux 2.4.26, 2004-08-04
NIGHTLY BUILD/TEST Date: Wed Aug 4 05:34:06 EDT 2004 Kernel: Linux 2.4.26 Host: beaver.codehaus.org Java: 1.4.2_04-b05, mixed mode Maven: 1.0 CHECKOUT: incubator-geronimo BUILDING: incubator-geronimo BUILD SUCCESSFUL Total time: 23 minutes 6 seconds Finished at: Wed Aug 04 05:58:37 EDT 2004
[jira] Assigned: (GERONIMO-261) NullPointerException deploying EAR jetty module
Message: The following issue has been re-assigned. Assignee: Gianny DAMOUR (mailto:[EMAIL PROTECTED]) - View the issue: http://issues.apache.org/jira/browse/GERONIMO-261 Here is an overview of the issue: - Key: GERONIMO-261 Summary: NullPointerException deploying EAR jetty module Type: Bug Status: Open Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Gianny DAMOUR Reporter: Eduardo Piva Created: Sat, 3 Jul 2004 12:11 PM Updated: Wed, 4 Aug 2004 5:35 AM Environment: Linux kernel 2.6.7-rc3 JVM 1.4 Description: If you specify a resource-env-ref or resource-ref in a web.xml file, and do not specify the respective informations in the geronimo-jetty.xml file, you can get a NullPointerException. If you do not specify a configId or parentId in a geronimo-jetty.xml, when you're creating a URI object, it will cause a NullPointerException, because a null value is passed to URI constructor (http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html#URI(java.lang.String)) If you create a war file without a WEB-INF/geronimo-jetty.xml file, it will cause a NullPointerException. The fix for these three issues are simple, and can be found in the following files (a diff will show where I touched): http://www.las.ic.unicamp.br/~eduardo/geronimo/ENCConfigBuilder.java http://www.las.ic.unicamp.br/~eduardo/geronimo/JettyModuleBuilder.java All these issues now generates a DeploymentException error, with a message inside it. To verify the URI issue, I just added a catch to NullPointerException when I create a URI object. I think that this is Ok, but it can be changed to something more elegant. This issue can happen in more places. I found that with ejb and connector modules we have the same problem. If the URI object was created in the method getConfigId, in Class EARConfigBuilder, it would be much nicer. But, to do that, we need to change the signature of Interface ModuleBuilder, so that getConfigId and getParentId returns String, and then we can see if this String is null inside EARConfigBuilder, and then return a URI 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: immutable wiki?
On Mon, Jul 19, 2004 at 09:45:53AM -0400, toby cabot wrote: It looks as if the apache wikis (including Geronimo's) are all in Immutable page mode. Turns out that you used to be able to anonymously edit pages but now you need to create a profile first, using the UserPreferences link in the upper-right corner of the page. Pages are immutable until you log in.
[jira] Reopened: (GERONIMO-169) EJB 2.0 DTD deployment descriptor support
Message: The following issue has been reopened. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-169 Here is an overview of the issue: - Key: GERONIMO-169 Summary: EJB 2.0 DTD deployment descriptor support Type: New Feature Status: Reopened Priority: Minor Project: Apache Geronimo Components: deployment Fix Fors: 1.0-M2 Versions: 1.0-M1 Assignee: David Jencks Reporter: David Blevins Created: Sat, 24 Apr 2004 4:55 PM Updated: Wed, 4 Aug 2004 1:29 PM Description: Currently only ejb-jar.xml files containing the EJB 2.1 xml schema header can be parsed and deployed. Depolyment descriptors using the EJB 2.0 DTD are not deployable. - 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-169) EJB 2.0 DTD deployment descriptor support
The following comment has been added to this issue: Author: David Blevins Created: Wed, 4 Aug 2004 1:33 PM Body: EJB 2.0 MDB to EJB 2.1 DD conversion doesn't quite work. This deployment descriptor ... ?xml version=1.0 encoding=UTF-8? !DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN http://java.sun.com/dtd/ejb-jar_2_0.dtd; ejb-jar id=ejb-jar_ID enterprise-beans message-driven ejb-nameBasicMessageBean/ejb-name ejb-classorg.acme.BasicMessageBean/ejb-class transaction-typeContainer/transaction-type message-driven-destination destination-typejavax.jms.Queue/destination-type /message-driven-destination /message-driven /enterprise-beans /ejb-jar ...yields the following at deployment Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee] at org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaConversionUtils.java:287) at org.apache.geronimo.schema.SchemaConversionUtils.convertToEJBSchema(SchemaConversionUtils.java:108) at org.openejb.deployment.OpenEJBModuleBuilder.installModule(OpenEJBModuleBuilder.java:310) - View this comment: http://issues.apache.org/jira/browse/GERONIMO-169?page=comments#action_37036 - View the issue: http://issues.apache.org/jira/browse/GERONIMO-169 Here is an overview of the issue: - Key: GERONIMO-169 Summary: EJB 2.0 DTD deployment descriptor support Type: New Feature Status: Reopened Priority: Minor Project: Apache Geronimo Components: deployment Fix Fors: 1.0-M2 Versions: 1.0-M1 Assignee: David Jencks Reporter: David Blevins Created: Sat, 24 Apr 2004 4:55 PM Updated: Wed, 4 Aug 2004 1:33 PM Description: Currently only ejb-jar.xml files containing the EJB 2.1 xml schema header can be parsed and deployed. Depolyment descriptors using the EJB 2.0 DTD are not deployable. - 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: JSP compilation
On Thu, Jul 22, 2004 at 09:40:42AM -0700, Jeremy Boynes wrote:
The simple hack I have been using is to stick it in ${java.home}/lib/ext
If you're using a jdk on Linux you'll want to copy tools.jar from
$JAVA_HOME/lib to $JAVA_HOME/jre/lib/ext .
[jira] Assigned: (GERONIMO-264) exceptions being swallowed at startup
Message: The following issue has been re-assigned. Assignee: Alan Cabrera (mailto:[EMAIL PROTECTED]) - View the issue: http://issues.apache.org/jira/browse/GERONIMO-264 Here is an overview of the issue: - Key: GERONIMO-264 Summary: exceptions being swallowed at startup Type: Improvement Status: Open Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Alan Cabrera Reporter: toby cabot Created: Mon, 12 Jul 2004 1:06 PM Updated: Wed, 4 Aug 2004 2:43 PM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: some exceptions that are thrown during startup are swallowed and don't show up in the logs. i'm at the 'monkey and typewriter' stage of the geronimo learning curve so i'm a good randomness injector. i had a problem where geronimo would try to start up and then go directly to shutdown for no apparent reason. actually, i think i've had a few: 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from stopped to starting 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] ra test setting configParameter to NewStringValue 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] BaseManagedConnectionFactory() 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] SpreadManagedConnectionFactory() 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from starting to failed 15:50:18,426 INFO [Kernel] Starting kernel shutdown i'll include a patch that logs the problem in the catch clause in Configuration.doStart(). There might be better places to do this, but as long as it gets done *somewhere* i'm happy. regards, toby - 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-169) EJB 2.0 DTD deployment descriptor support
Message: The following issue has been closed. Resolver: David Jencks Date: Wed, 4 Aug 2004 2:51 PM This mdb problem is fixed, as well as an npe when there are no environment entries. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-169 Here is an overview of the issue: - Key: GERONIMO-169 Summary: EJB 2.0 DTD deployment descriptor support Type: New Feature Status: Closed Priority: Minor Resolution: FIXED Project: Apache Geronimo Components: deployment Fix Fors: 1.0-M2 Versions: 1.0-M1 Assignee: David Jencks Reporter: David Blevins Created: Sat, 24 Apr 2004 4:55 PM Updated: Wed, 4 Aug 2004 2:51 PM Description: Currently only ejb-jar.xml files containing the EJB 2.1 xml schema header can be parsed and deployed. Depolyment descriptors using the EJB 2.0 DTD are not deployable. - 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-264) exceptions being swallowed at startup
The following issue has been updated: Updater: toby cabot (mailto:[EMAIL PROTECTED]) Date: Wed, 4 Aug 2004 3:09 PM Comment: this diff should merge cleanly with Daemon r1.9, the previous ones will probably conflict. Changes: Attachment changed to Daemon-1_9-diff.txt - For a full history of the issue, see: http://issues.apache.org/jira/browse/GERONIMO-264?page=history - View the issue: http://issues.apache.org/jira/browse/GERONIMO-264 Here is an overview of the issue: - Key: GERONIMO-264 Summary: exceptions being swallowed at startup Type: Improvement Status: Open Priority: Minor Project: Apache Geronimo Components: deployment Versions: 1.0-M2 Assignee: Alan Cabrera Reporter: toby cabot Created: Mon, 12 Jul 2004 1:06 PM Updated: Wed, 4 Aug 2004 3:09 PM Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Description: some exceptions that are thrown during startup are swallowed and don't show up in the logs. i'm at the 'monkey and typewriter' stage of the geronimo learning curve so i'm a good randomness injector. i had a problem where geronimo would try to start up and then go directly to shutdown for no apparent reason. actually, i think i've had a few: 15:50:17,290 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from stopped to starting 15:50:17,292 DEBUG [Configuration] ClassPath for skeleton/RA resolved to [file:/home/tcabot/try/incubator-geronimo/target/config-store/8/connector/skeleton-ra.jar] ra test setting configParameter to NewStringValue 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] BaseManagedConnectionFactory() 15:50:17,737 DEBUG [SpreadManagedConnectionFactory] SpreadManagedConnectionFactory() 15:50:18,425 DEBUG [GBeanMBean] geronimo.config:name=skeleton/RA State changed from starting to failed 15:50:18,426 INFO [Kernel] Starting kernel shutdown i'll include a patch that logs the problem in the catch clause in Configuration.doStart(). There might be better places to do this, but as long as it gets done *somewhere* i'm happy. regards, toby - 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: Unit/Stress Tests (Bite Sized Task)
On Wed, Aug 04, 2004 at 05:01:57PM -0500, Dain Sundstrom wrote: On Aug 3, 2004, at 2:09 PM, Dain Sundstrom wrote: That's basically a 20 minute difference with only 4.5 minutes reportedly spend on our tests. What is taking up the other 15 minutes? Is setUp/tearDown not counted in the test time? If not, the zillions of kernels we create in setUp methods could easily explain the difference. I would wager that the 15 minutes is spent launching the java vms. It looks like on my machine that there is one vm launched for each unit test. On a very small module, my test time with fork on was 30s and with fork off was 10s. It occurs to me this could be just like the setContextClassLoader permission issue in that we may be forking the test vm for no reason. Can someone try to run the unit tests with maven.junit.fork=true commented out in the etc/global.properties file? I'm interested if only a few tests are failing, or is most tests fail for a single simple reason. If we can fix this, we can all be more productive. Gave it a shot yesterday. The org.apache.geronimo.system.url.GeronimoURLFactoryTest tests error out and I couldn't get the build to continue even with the maven.test.failure.ignore=true flag. Maven2 uses separate classloaders for running each testcase so forking is largely unneeded. Things that mess with the VM itself though (URLFactories, SecurityManagers, etc.) would probably still need to be forked. For now, we could go module by module and see if we can get find some that don't need to be forked. -David
How to build all projects at once
I've found a way to build tranql[-connector], howl, geronimo, openejb, and activemq in one build using maven multiproject. I put the project.xml and project.properties files I use at http://www.apache.org/~djencks/universal-build/ You'll need to modify the project.properties file unless you have the same directory layout as me. Assuming you put the downloaded files in a directory, I have the projects laid out like this: activemq/activemq/[modules etc] geronimo/1geronimo/[modules etc] howl/howl/logger (etc) openejb/1openejb/[modules etc] tranql[tranql, connector, vendors] To those not on the openejb lists... the openejb itests are now run inside the normal build: the itests module starts a geronimo server , deploys the itest ejb-jar, runs the tests, undeploys the jar, and stops geronimo. It should be fairly easy to imitate this for e.g. running the activemq itests. thanks david jencks
