Kaha store
Something we need to address for the Kaha persistent store is pluggable strategies for the indexing of data for both the List and Map container types. Currently, an IndexItem is a fixed size, but can be iterated as a bi- directional linked list. The IndexItem holds offsets to the the data value and optional data key which is held in rolling data logs. Data values/keys are variable in length. When a Container is loaded, the IndexItem is loaded in to an in- memory structure - so for a Map Container a Map will hold the key - the value being the IndexItem - so that getting a data value involves looking up the IndexItem - then retrieving the data value associated with the IndexItem from disk. This works reasonably well and is fine medium size collections of messages (~20-30million with the default heap size for a message broker). But to ensure the Kaha Store can handle indexing larger number of messages with a relatively small memory footprint - we are obviously going to need something a little more sophisticated. Apart from a B-Tree - something that I've though about is using different types of caching - as the activemq message store really uses FIFO queues, a FIFO cache strategy would seem like a good strategy? thoughts ? cheers, Rob
Re: Kaha store
On 7/10/06, Rob Davies [EMAIL PROTECTED] wrote: Something we need to address for the Kaha persistent store is pluggable strategies for the indexing of data for both the List and Map container types. +1 Currently, an IndexItem is a fixed size, but can be iterated as a bi- directional linked list. The IndexItem holds offsets to the the data value and optional data key which is held in rolling data logs. Data values/keys are variable in length. When a Container is loaded, the IndexItem is loaded in to an in- memory structure - so for a Map Container a Map will hold the key - the value being the IndexItem - so that getting a data value involves looking up the IndexItem - then retrieving the data value associated with the IndexItem from disk. This works reasonably well and is fine medium size collections of messages (~20-30million with the default heap size for a message broker). But to ensure the Kaha Store can handle indexing larger number of messages with a relatively small memory footprint - we are obviously going to need something a little more sophisticated. Apart from a B-Tree - something that I've though about is using different types of caching - as the activemq message store really uses FIFO queues, a FIFO cache strategy would seem like a good strategy? thoughts ? +1 cheers, Rob -- Regards, Hiram Blog: http://hiramchirino.com
Re: Failover with Network Connections
sounds good to me! On 10 Jul 2006, at 16:46, Hiram Chirino wrote: Howdy, Using failover to reestablish network connections setup with static has always been a bid doggy. For example, it cause all kinds of problem when using it also with SSH tunnels. See: http://issues.apache.org/activemq/browse/AMQ-802 I have implemented connection recovery now in the static: discovery agent. Unless anybody objects, I'm going to commit my changes to the static discovery agent and ignore the failover option on the network connectors. -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Resolved: (AMQ-806) Support a ?trace=true option on the http client side transport
[ https://issues.apache.org/activemq/browse/AMQ-806?page=all ] Hiram Chirino resolved AMQ-806: --- Resolution: Fixed implemented Support a ?trace=true option on the http client side transport -- Key: AMQ-806 URL: https://issues.apache.org/activemq/browse/AMQ-806 Project: ActiveMQ Type: New Feature Components: Transport Reporter: Hiram Chirino Assignee: Hiram Chirino Priority: Minor Fix For: 4.0.2, 4.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-807) JMS connections using the http:// protocol may not detect connections failures correctly.
[ https://issues.apache.org/activemq/browse/AMQ-807?page=all ] Hiram Chirino resolved AMQ-807: --- Resolution: Fixed fixed. JMS connections using the http:// protocol may not detect connections failures correctly. - Key: AMQ-807 URL: https://issues.apache.org/activemq/browse/AMQ-807 Project: ActiveMQ Type: Bug Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 If for example the broker is restarted, the broker will not inform a client using the broker again that it's connection state is gone. Also the client would startup a background poll thread before its' connection was established. This cause it to go into a busy loop hiting the server and the server sending back clientID not specified error messages until the ConnectionInfo was sent to the broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-809) Make it easier to just enable the command trancing of the TransportLogger.
[ https://issues.apache.org/activemq/browse/AMQ-809?page=all ] Hiram Chirino resolved AMQ-809: --- Resolution: Fixed implemented. Make it easier to just enable the command trancing of the TransportLogger. -- Key: AMQ-809 URL: https://issues.apache.org/activemq/browse/AMQ-809 Project: ActiveMQ Type: Improvement Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 The log4j category for trace logging of message currently org.apache.activemq.transport.TransportLogger:n this makes it hard to enable the debug logging of just the trace messages since org.apache.activemq.transport is too broad of a category and TransportLogger:n is a variable category name. We should make it org.apache.activemq.transport.TransportLogger.Connection:n so that it's easier to just enable the logging for this one component. Also log usage of the other request methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-810) When using Topics with consumers with selectors over a network of brokers, only the first consumer gets messages delivered.
When using Topics with consumers with selectors over a network of brokers, only the first consumer gets messages delivered. --- Key: AMQ-810 URL: https://issues.apache.org/activemq/browse/AMQ-810 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1, 4.0.2 The subscription conduit is blocking out subsequent subscriptions from being propagated over the network bridge -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-803) The static discovery agent should include reconnect logic when it is notified that one of it's sevices failed.
[ https://issues.apache.org/activemq/browse/AMQ-803?page=all ] Hiram Chirino resolved AMQ-803: --- Resolution: Fixed implemented. The static discovery agent should include reconnect logic when it is notified that one of it's sevices failed. -- Key: AMQ-803 URL: https://issues.apache.org/activemq/browse/AMQ-803 Project: ActiveMQ Type: New Feature Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 This could substancially make the network connector code simpler since it does not need to deal with failover connections which cause problems for the connector. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-805) Restart network bridges if they ever get stopped
[ https://issues.apache.org/activemq/browse/AMQ-805?page=all ] Hiram Chirino resolved AMQ-805: --- Resolution: Fixed Fixed. Restart network bridges if they ever get stopped Key: AMQ-805 URL: https://issues.apache.org/activemq/browse/AMQ-805 Project: ActiveMQ Type: Improvement Reporter: Hiram Chirino Assignee: Hiram Chirino Right now it seems like we only trap remote exceptions and then restart the bridge. I think we should restart the network bridge if the bridge fails for any reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-802) Broker Network connections over SSH tunnels do not get established.
[ https://issues.apache.org/activemq/browse/AMQ-802?page=all ] Hiram Chirino resolved AMQ-802: --- Resolution: Fixed Fixed.. failover should not be used with static: connections anymore. Broker Network connections over SSH tunnels do not get established. --- Key: AMQ-802 URL: https://issues.apache.org/activemq/browse/AMQ-802 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Due to the way that ssh tunnels accept a connection but then close a socket if they cannot establish a connection to the remote host, the network connector fails to re-connect to the remote host when it is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Switch to Maven 2?? Delete our m1 build files??
Sweet... nuke the m1 build :-) --jason On Jul 10, 2006, at 10:01 PM, Hiram Chirino wrote: Hi Folks, So to me it looks like our maven 2 build is now is now producing an equivalent binary distribution to our maven 1 build. Openwire is now getting generated correctly with m2 also. I think we are over the hump and anything left should just be small details. Do you think we should delete our m1 build files to avoid confusion and encourage folks to do the switch? -- Regards, Hiram Blog: http://hiramchirino.com
Re: Switch to Maven 2?? Delete our m1 build files??
+1 -dain On Jul 10, 2006, at 10:01 PM, Hiram Chirino wrote: Hi Folks, So to me it looks like our maven 2 build is now is now producing an equivalent binary distribution to our maven 1 build. Openwire is now getting generated correctly with m2 also. I think we are over the hump and anything left should just be small details. Do you think we should delete our m1 build files to avoid confusion and encourage folks to do the switch? -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (SM-484) Missing dependencies for Maven 2 build
Missing dependencies for Maven 2 build -- Key: SM-484 URL: https://issues.apache.org/activemq/browse/SM-484 Project: ServiceMix Type: Bug Components: servicemix-core, servicemix-wsn2005 Versions: incubation Reporter: Marc Tremblay Attachments: patch.txt 1. The servicemix-core/pom.xml is missing the activeio-core library from the project dependencies. 2. The servicemix-wsn2005/pom.xml is missing the jaxb-impl library from the maven-antrun-plugin dependencies. The attached patch enables the build to succeed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: JIRA Wiki syntax turned off for Geronimo, GShell
FYI...Target is to get JIRA upgraded by the end of the week (according to Jeff).--jasonBegin forwarded message:From: Jeff Turner [EMAIL PROTECTED]Date: July 9, 2006 8:26:03 PM PDTTo: [EMAIL PROTECTED]Cc: Jason Dillon [EMAIL PROTECTED]Subject: JIRA Wiki syntax turned off for Geronimo, GShell Hi,I've turned off JIRA wiki rendering for the two projects that had itenabled (Geronimo and GShell), as there is a bug in the renderer whichallows XSS attacks:http://jira.atlassian.com/browse/JRA-9090We can reenable it after the next upgrade.--Jeff
Re: [jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
On Jul 9, 2006, at 8:57 PM, Kevan Miller wrote: On Jul 9, 2006, at 3:00 PM, Jeremy Boynes wrote: On Jul 9, 2006, at 11:08 AM, Jeremy Boynes wrote: On Jul 9, 2006, at 9:16 AM, David Jencks wrote: There's a geronimo version of the commonj spec at org.apache.geronimo.specs:geronimo-commonj_1.1_spec:1.0:jar at ibiblio. I'm not entirely sure what auspices this was published under since geronimo doesn't have a tck for commonj. If there are any problems with this jar please speak up on the geronimo dev list. David, I'm not sure what you mean by what auspices... I mean that this is the only spec we have released without having a tck to test against. It's not entirely clear that the corba jar is a spec since IIUC it is entirely generated from IDL, but we didn't release it until the tck passed. On the other hand IIUC we did later release a corba spec jar that doesn't work at all. thanks david jencks Thanks David, I'll use that for now. There is also a version in the Apache WebServices WSRF project but they don't seem to have published it. I found a couple of problems in Geronimo's version with the signatures (e.g. exceptions missing). I modified the Geronimo source to match the spec javadoc I downloaded and it seems to compile now. Attached is a patch for geronimo-spec (from https:// svn.apache.org/repos/asf/geronimo/specs/trunk) geronimo-commonj.patch This bumps the commonj spec jar version to 1.0.1-SNAPSHOT - hope that's the right version. Dave, if this works for you can you get a snapshot version uploaded so that Tuscany folk won't have to build from source. Jeremy, Thanks for pointing these problems out. I'll start working on getting a SNAPSHOT... A few comments: TimerManager.isSuspended(), isSuspending(), waitForStop(), and waitForSuspend() look correct to me. The javadoc for TimerManager.suspend() gives mixed messages. I'm going to keep the suspend() throws IllegalStateException for now... Let me know if you have evidence as to what it should be. Your WorkCompletedException used a few Java 5 methods, I backed it down so it will build under 1.4. --kevan
[jira] Assigned: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ http://issues.apache.org/jira/browse/GERONIMO-1887?page=all ] David Jencks reassigned GERONIMO-1887: -- Assign To: David Jencks (was: Paul McMahan) Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: http://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.x Reporter: Paul McMahan Assignee: David Jencks Priority: Minor Fix For: 1.1.1 Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- 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
Regarding ClassLoader Changes in Geronimo 1.1
Hi, I have an application that is packaged as an EAR. The WAR inside the EAR is having some images in the images directory directly inside the war. In Geronimo 1.0, I was able to access them using Thread.currentThread().getContextClassLoader().getResource() method, but now I am unable to do so. On debugging I found that the classloader I got for 1.0 was WebappClassLoader from Tomcat which had access to the files, while for 1.1, I got JarFileClassLoader of geronimo which did not have access to those files. Can anyone throw further light on this problem. Thanks Manu
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On 7/10/06, Sachin Patel [EMAIL PROTECTED] wrote: No critical reason, just a time frame on when I'll upload the driver to the distribution size if no -1's have been casted. That's interesting...would that mean that if Geronimo 1.2 is about to release only 72 hours matters or 3+ votes? The first one just unzips into your ECLIPSE_HOME. Once released, the second is the distribution that gets unzipped into the update manager site. The packaging is a little different. The second one can also be tested by unzipping anywhere on your filesystem and creating a local update site to it. The site.xml is not really needed to test it. Which one do I need to download and what are the steps to test it out? Just unpack to $ECLIPSE_HOME dir? Just downloaded Eclipse 3.2 and am ready to give it a whirl. You can start with Eclipse 3.2 but will need to go to the update manager to add WTP and its requirements. Or you can download the WTP-all in one package. I'm working as-we speak on a eclipse-plugin FAQ for the wiki that will contain further detailed info. Looking forward to reading it. Another question is about the naming - why is the plugin named - g-eclipse-... nor geronimo-eclipse-...? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=comments#action_12420014 ] Mario Ruebsam commented on GERONIMO-2125: - Everything is ok in this example as long the ejb.jar is existent. If the ejb.jar is removed from the ear and the application.xml, the class org.apache.geronimo.itest.TestServlet could not be load. Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path - Key: GERONIMO-2125 URL: http://issues.apache.org/jira/browse/GERONIMO-2125 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: 1.1 release Reporter: Mario Ruebsam Assignee: David Jencks Priority: Blocker Fix For: 1.2, 1.1.1 Attachments: ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, manifestcp-itest-v2.jar, manifestcp-itest.jar A working EAR for Geronimo 1.0 with this structure: app.ear/ app.jar cpa.jar found.jar webclient.war The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF Class-Path: app.jar cpa.jar found.jar Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because of the missing classes in the JARs which are not found. Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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: ActiveMQ Destinations
On 7/10/06, srsprasad [EMAIL PROTECTED] wrote: How to get the List of Queues or Topics presently active in Broker. A code sample will really help me alot. Thanks in advance... The FAQ has lots of useful information http://incubator.apache.org/activemq/faq.html e.g. http://incubator.apache.org/activemq/how-can-i-get-a-list-of-the-topics-and-queues-in-a-broker.html -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=all ] Mario Ruebsam updated GERONIMO-2125: Attachment: ear-1.0-SNAPSHOT.ear ear without the ejb.jar Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path - Key: GERONIMO-2125 URL: http://issues.apache.org/jira/browse/GERONIMO-2125 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: 1.1 release Reporter: Mario Ruebsam Assignee: David Jencks Priority: Blocker Fix For: 1.2, 1.1.1 Attachments: ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, ear-1.0-SNAPSHOT.ear, manifestcp-itest-v2.jar, manifestcp-itest.jar A working EAR for Geronimo 1.0 with this structure: app.ear/ app.jar cpa.jar found.jar webclient.war The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF Class-Path: app.jar cpa.jar found.jar Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because of the missing classes in the JARs which are not found. Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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
Unassigned Patches: week of 07-10-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Feb 21 2006 - GERONIMO-1396 - Provide consistent look and feel for table views in the web console across all portlets Feb 23 2006 - GERONIMO-1648 - Eliminate unnecessary config parent (import) dependencies Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 6 2006 - GERONIMO-1701 - Improve the EJB Server portlet Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 6 2006 - GERONIMO-1783 - Welcome application i18n Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started May 3 2006 - GERONIMO-1976 - Change Welcome Application for G1.1 May 10 2006 - GERONIMO-1518 - Installer - only copy jars needed by selected configuration May 12 2006 - GERONIMO-2014 - Geronimo uses outdated version of ApacheDS
[M2 build] : Error building application uddi-db on XP
Seeing this error on Windows XP only. Unable to recreate it on Linux.
I am trying to build the trunk using m2. I began with a clean repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error occurs.
Cheers
Prasad
Re: [M2 build] : Error building application uddi-db on XP
On 7/10/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Seeing this error on Windows XP only. Unable to recreate it on Linux. I am trying to build the trunk using m2. I began with a clean repo and did a fresh checkout. I executed build.bat and it ran the bootstrap stage. Then I executed build.bat -Dstage=assembly -Dmaven.test.skip=true. It failed while trying to build applications/uddi-db with the following error ... Embedded error: Unable to delete file C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck Got exactly the same error while building Geronimo in svnkmerge/m2migration and was about to write to dev (!) What a coincidence, isn't it? Doing other stuff and haven't looked into it yet. If you know the answer, please speak up. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 10, 2006, at 5:16 AM, Jacek Laskowski wrote:On 7/10/06, Sachin Patel [EMAIL PROTECTED] wrote: No critical reason, just a time frame on when I'll upload the driver to thedistribution size if no -1's have been casted. That's interesting...would that mean that if Geronimo 1.2 is about torelease only 72 hours matters or 3+ votes?Is it required that every PMC must vote? If not, then yes, I would think so. A released is only stopped if a -1 is received, not if people abstain from a vote. The first one just unzips into your ECLIPSE_HOME. Once released, the secondis the distribution that gets unzipped into the update manager site. Thepackaging is a little different. The second one can also be tested byunzipping anywhere on your filesystem and creating a "local" update site toit. The site.xml is not really needed to test it.Which one do I need to downloadand what are the steps to test it out? Just unpack to $ECLIPSE_HOMEdir? Just downloaded Eclipse 3.2 and am ready to give it a whirl.You can start with Eclipse 3.2 but will need to go to the update manager toadd WTP and its requirements. Or you can download the WTP-all in onepackage. I'm working as-we speak on a eclipse-plugin FAQ for the wiki thatwill contain further detailed info. Looking forward to reading it.Another question is about the naming - why is the plugin named -g-eclipse-... nor geronimo-eclipse-...?No reason. I can rename them. Keep in mind these zips are not the primary way of installation and only an alternate, as the recommended approach to installing is through the update manager.Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin
Re: svn commit: r420418 - in /geronimo/specs/trunk: ./ geronimo-spec-commonj/src/main/java/commonj/timers/ geronimo-spec-commonj/src/main/java/commonj/work/
On Jul 10, 2006, at 12:32 AM, Jason Dillon wrote:
You know... every field in an interface is by default public static
and final. Adding these modifiers is redundant.
You're right, of course. They already had redundant 'public
static'. The patch that Jeremy submitted added the 'final'. I was in
match-the-code-with-the-javadoc mode... As they do no harm, I'll
leave them in.
On Jul 9, 2006, at 9:23 PM, [EMAIL PROTECTED] wrote:
Author: kevan
Date: Sun Jul 9 21:23:46 2006
New Revision: 420418
URL: http://svn.apache.org/viewvc?rev=420418view=rev
Log:
GERONIMO-2179 Fix multiple signature problems with commonj specs
Modified:
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkEvent.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkItem.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkManager.java
geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkRejectedException.java
geronimo/specs/trunk/pom.xml
Modified: geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-commonj/src/main/java/commonj/timers/TimerManager.java?
rev=420418r1=420417r2=420418view=diff
=
=
--- geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java (original)
+++ geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/timers/TimerManager.java Sun Jul 9 21:23:46 2006
@@ -35,12 +35,12 @@
*/
public interface TimerManager {
-static long IMMEDIATE = 0;
-static long INDEFINITE = java.lang.Long.MAX_VALUE;
+static final long IMMEDIATE = 0;
+static final long INDEFINITE = java.lang.Long.MAX_VALUE;
-boolean isStopped() throws IllegalStateException;
+boolean isStopped();
-boolean isStopping() throws IllegalStateException;
+boolean isStopping();
boolean isSuspended() throws IllegalStateException;
Modified: geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-commonj/src/main/java/commonj/work/RemoteWorkItem.java?
rev=420418r1=420417r2=420418view=diff
=
=
--- geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java (original)
+++ geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/RemoteWorkItem.java Sun Jul 9 21:23:46 2006
@@ -33,7 +33,7 @@
/**
* @version $Rev: 46019 $ $Date: 2004-09-14 05:56:06 -0400 (Tue,
14 Sep 2004) $
*/
-public interface RemoteWorkItem extends Comparable, WorkItem {
+public interface RemoteWorkItem extends WorkItem {
WorkManager getPinnedWorkManager();
void release();
Modified: geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-commonj/src/main/java/commonj/work/
WorkCompletedException.java?rev=420418r1=420417r2=420418view=diff
=
=
--- geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java (original)
+++ geronimo/specs/trunk/geronimo-spec-commonj/src/main/java/
commonj/work/WorkCompletedException.java Sun Jul 9 21:23:46 2006
@@ -28,22 +28,45 @@
package commonj.work;
+import java.util.List;
+import java.util.ArrayList;
+import java.util.Collections;
+
/**
* @version $Rev: 46019 $ $Date: 2004-09-14 05:56:06 -0400 (Tue,
14 Sep 2004) $
*/
-public class WorkCompletedException extends Exception {
+public class WorkCompletedException extends WorkException {
+
+private final List exceptionList;
public WorkCompletedException() {
super();
+exceptionList = Collections.EMPTY_LIST;
}
public WorkCompletedException(String message) {
super(message);
+exceptionList = Collections.EMPTY_LIST;
}
public WorkCompletedException(String message, Throwable cause) {
super(message, cause);
+exceptionList = Collections.singletonList(cause);
}
public WorkCompletedException(Throwable cause) {
super(cause);
+exceptionList = Collections.singletonList(cause);
+}
+public WorkCompletedException(String message, List list) {
+super(message);
+if ((list != null) (list.size() 0)) {
+
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 10, 2006, at 9:07 AM, Sachin Patel wrote:On Jul 10, 2006, at 5:16 AM, Jacek Laskowski wrote:On 7/10/06, Sachin Patel [EMAIL PROTECTED] wrote: No critical reason, just a time frame on when I'll upload the driver to thedistribution size if no -1's have been casted. That's interesting...would that mean that if Geronimo 1.2 is about torelease only 72 hours matters or 3+ votes?Is it required that every PMC must vote? If not, then yes, I would think so. A released is only stopped if a -1 is received, not if people abstain from a vote.No, that's not right. A release is a majority vote. You can't "veto" a release with a -1. And, I think, there's no minimum vote requirement. Although if you only have 3 +1 votes, then I'd say something is probably wrong... 72 hours seems to be considered a minimum vote timeframe... I think we had something similar for some of the G 1.1 release votes...--kevan The first one just unzips into your ECLIPSE_HOME. Once released, the secondis the distribution that gets unzipped into the update manager site. Thepackaging is a little different. The second one can also be tested byunzipping anywhere on your filesystem and creating a "local" update site toit. The site.xml is not really needed to test it.Which one do I need to downloadand what are the steps to test it out? Just unpack to $ECLIPSE_HOMEdir? Just downloaded Eclipse 3.2 and am ready to give it a whirl.You can start with Eclipse 3.2 but will need to go to the update manager toadd WTP and its requirements. Or you can download the WTP-all in onepackage. I'm working as-we speak on a eclipse-plugin FAQ for the wiki thatwill contain further detailed info. Looking forward to reading it.Another question is about the naming - why is the plugin named -g-eclipse-... nor geronimo-eclipse-...?No reason. I can rename them. Keep in mind these zips are not the primary way of installation and only an alternate, as the recommended approach to installing is through the update manager.Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin
Re: Geronimo/Equinox integration status?
Hi Alan, On Sun, Jul 09, 2006 at 09:39:30AM -0700, Alan D. Cabrera wrote: toby cabot wrote: What's the status of the Geronimo/Equinox (OSGi server) integration? XBean is built on Spring and Spring is coming out w/ OSGi support. Dain has some other XBean - OSGi stuff in the oven as well. So, I would say that yes, Geronimo booting inside an OSGi kernel is a real possibility. Thanks for the info. As no good deed goes unpunished I've got a follow-up question: what's the relationship between Geronimo (and I assume GBeans) to XBeans? I see some stuff on the web about how XBeans is an extension to Spring (although xbean.org seems to unreachable to me ATM), but is XBean intended as a replacement for GBean? Thanks, Toby
Re: [jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
On Jul 9, 2006, at 8:57 PM, Kevan Miller wrote: Jeremy, Thanks for pointing these problems out. I'll start working on getting a SNAPSHOT... Thanks A few comments: TimerManager.isSuspended(), isSuspending(), waitForStop(), and waitForSuspend() look correct to me. The javadoc for TimerManager.suspend() gives mixed messages. I'm going to keep the suspend() throws IllegalStateException for now... Let me know if you have evidence as to what it should be. For suspend, the JavaDoc declares no exception but as it is a RuntimeException it can still be thrown (and listed in the Throws section). It's confusing and in real life irrelevant but I would recommend removing it - some signature checkers will flag it being there as an problem. Sorry about isSuspended and isSuspending. With waitForStop and waitForSuspend I only changed the parameter name to match the documentation and not the signature. The name in the doc is timeout_ms which includes the unit which I thought was a little clearer. Your WorkCompletedException used a few Java 5 methods, I backed it down so it will build under 1.4. Thanks, guess I've been in 1.5 mode too long. -- Jeremy
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
Ok thanks for the correction. So what classifies a veto?On Jul 10, 2006, at 9:54 AM, Kevan Miller wrote:On Jul 10, 2006, at 9:07 AM, Sachin Patel wrote:On Jul 10, 2006, at 5:16 AM, Jacek Laskowski wrote:On 7/10/06, Sachin Patel [EMAIL PROTECTED] wrote: No critical reason, just a time frame on when I'll upload the driver to thedistribution size if no -1's have been casted. That's interesting...would that mean that if Geronimo 1.2 is about torelease only 72 hours matters or 3+ votes?Is it required that every PMC must vote? If not, then yes, I would think so. A released is only stopped if a -1 is received, not if people abstain from a vote.No, that's not right. A release is a majority vote. You can't "veto" a release with a -1. And, I think, there's no minimum vote requirement. Although if you only have 3 +1 votes, then I'd say something is probably wrong... 72 hours seems to be considered a minimum vote timeframe... I think we had something similar for some of the G 1.1 release votes...--kevan The first one just unzips into your ECLIPSE_HOME. Once released, the secondis the distribution that gets unzipped into the update manager site. Thepackaging is a little different. The second one can also be tested byunzipping anywhere on your filesystem and creating a "local" update site toit. The site.xml is not really needed to test it.Which one do I need to downloadand what are the steps to test it out? Just unpack to $ECLIPSE_HOMEdir? Just downloaded Eclipse 3.2 and am ready to give it a whirl.You can start with Eclipse 3.2 but will need to go to the update manager toadd WTP and its requirements. Or you can download the WTP-all in onepackage. I'm working as-we speak on a eclipse-plugin FAQ for the wiki thatwill contain further detailed info. Looking forward to reading it.Another question is about the naming - why is the plugin named -g-eclipse-... nor geronimo-eclipse-...?No reason. I can rename them. Keep in mind these zips are not the primary way of installation and only an alternate, as the recommended approach to installing is through the update manager.Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin -sachin
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: m2-plugins.patch configs.patch These patches are built against rev 418907. The first server that starts has been assembled! http://issues.apache.org/jira/browse/GERONIMO-1737#action_12419584 The m2-plugins.patch includes all the earlier modifications and - Allows the configs to be built with just mvn (no clean) and - Changes 'dependencies' goal to prepare-plan (cosmetic change) Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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: [Vote] Geronimo Eclipse Plugin v1.1.0
On Jul 10, 2006, at 10:03 AM, Sachin Patel wrote:Ok thanks for the correction. So what classifies a veto?IIUC, only code (i.e. a commit) can be vetoed. If any license/legal-type issues are uncovered in the release, then that's probably a stop-release problem (effectively a veto). I think our goal should be to avoid releasing with any outstanding -1 votes, but it's not a requirement...--kevanOn Jul 10, 2006, at 9:54 AM, Kevan Miller wrote:On Jul 10, 2006, at 9:07 AM, Sachin Patel wrote:On Jul 10, 2006, at 5:16 AM, Jacek Laskowski wrote:On 7/10/06, Sachin Patel [EMAIL PROTECTED] wrote: No critical reason, just a time frame on when I'll upload the driver to thedistribution size if no -1's have been casted. That's interesting...would that mean that if Geronimo 1.2 is about torelease only 72 hours matters or 3+ votes?Is it required that every PMC must vote? If not, then yes, I would think so. A released is only stopped if a -1 is received, not if people abstain from a vote.No, that's not right. A release is a majority vote. You can't "veto" a release with a -1. And, I think, there's no minimum vote requirement. Although if you only have 3 +1 votes, then I'd say something is probably wrong... 72 hours seems to be considered a minimum vote timeframe... I think we had something similar for some of the G 1.1 release votes...--kevan The first one just unzips into your ECLIPSE_HOME. Once released, the secondis the distribution that gets unzipped into the update manager site. Thepackaging is a little different. The second one can also be tested byunzipping anywhere on your filesystem and creating a "local" update site toit. The site.xml is not really needed to test it.Which one do I need to downloadand what are the steps to test it out? Just unpack to $ECLIPSE_HOMEdir? Just downloaded Eclipse 3.2 and am ready to give it a whirl.You can start with Eclipse 3.2 but will need to go to the update manager toadd WTP and its requirements. Or you can download the WTP-all in onepackage. I'm working as-we speak on a eclipse-plugin FAQ for the wiki thatwill contain further detailed info. Looking forward to reading it.Another question is about the naming - why is the plugin named -g-eclipse-... nor geronimo-eclipse-...?No reason. I can rename them. Keep in mind these zips are not the primary way of installation and only an alternate, as the recommended approach to installing is through the update manager.Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl -sachin -sachin
[jira] Created: (AMQ-802) Broker Network connections over SSH tunnels do not get established.
Broker Network connections over SSH tunnels do not get established. --- Key: AMQ-802 URL: https://issues.apache.org/activemq/browse/AMQ-802 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1, 4.0.2 Due to the way that ssh tunnels accept a connection but then close a socket if they cannot establish a connection to the remote host, the network connector fails to re-connect to the remote host when it is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How were the Geronimo 1.0 and 1.1 artifacts published to a Maven2 Repo?
Donald, I had to manually publish these for the M2. At the time the tag was cut the pom.xml did not have updated entries for M2 to properly publish them. The pom is being corrected for 1.2-SNAPSHOT. Donald Woods wrote: Still wondering how this was done Did someone have to run mvn install:install-file ... for every Geronimo 1.0 and 1.1 artifact to get them published to a Maven 2 repo? Since the Eclipse plug-in and any plug-ins we publish to GeronimoPlugins require artifacts from Maven 2, we need this documented somewhere -Donald Donald Woods wrote: For Geronimo 1.1, both of the Eclipse plugin and Daytrader sample require valid Maven2 POM files in order to determine the dependencies/imports when building, so how were these created from the current Maven1 based Geronimo 1.0 and 1.1 builds? Is there a way we can automate this for our local Geronimo 1.1.1-SNAPSHOT builds? -Donald
[jira] Commented: (AMQ-802) Broker Network connections over SSH tunnels do not get established.
[ https://issues.apache.org/activemq/browse/AMQ-802?page=comments#action_36538 ] Hiram Chirino commented on AMQ-802: --- This can even lead to a busy loop as the failover connection establishes a connection and then the network bridge detects that the connection failed and then failover starts again and the loop restarts. Broker Network connections over SSH tunnels do not get established. --- Key: AMQ-802 URL: https://issues.apache.org/activemq/browse/AMQ-802 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Due to the way that ssh tunnels accept a connection but then close a socket if they cannot establish a connection to the remote host, the network connector fails to re-connect to the remote host when it is started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-803) The static multicast discovery agent should include reconnect logic when it is notified that one of it's sevices failed.
The static multicast discovery agent should include reconnect logic when it is notified that one of it's sevices failed. Key: AMQ-803 URL: https://issues.apache.org/activemq/browse/AMQ-803 Project: ActiveMQ Type: New Feature Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.0.2, 4.1 This could substancially make the network connector code simpler since it does not need to deal with failover connections which cause problems for the connector. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-804) Use of Temporary Destinations over broker networks can cause the network bridges to die.
Use of Temporary Destinations over broker networks can cause the network bridges to die. Key: AMQ-804 URL: https://issues.apache.org/activemq/browse/AMQ-804 Project: ActiveMQ Type: Bug Components: Broker Reporter: Hiram Chirino Fix For: 4.1 And when the bridge dies, it is not re-established. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-804) Use of Temporary Destinations over broker networks can cause the network bridges to die.
[ https://issues.apache.org/activemq/browse/AMQ-804?page=comments#action_36540 ] Hiram Chirino commented on AMQ-804: --- I noticed that the issue is cause when the client the created the temporary destination and a subscription to that temporary destination is killed. The remote broker sometimes gets the destination removed and consumer removed commands in the wrong order. The error happens when the destination removed arrives before the consumer removed at the network bridge. When the destination remove command executes it fails because it still has a subscription active on it. Use of Temporary Destinations over broker networks can cause the network bridges to die. Key: AMQ-804 URL: https://issues.apache.org/activemq/browse/AMQ-804 Project: ActiveMQ Type: Bug Components: Broker Reporter: Hiram Chirino Fix For: 4.1 And when the bridge dies, it is not re-established. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2063) Stopping a TSSbean also stops the orb it's attached to
[ http://issues.apache.org/jira/browse/GERONIMO-2063?page=all ] Donald Woods updated GERONIMO-2063: --- Regression: [Regression] Priority: Critical (was: Major) Isn't this a critical problem for Geronimo 1.1, given that the Orb is shutdown if ANY EJB based apps are stopped or undeployed? Seems that this would be a show-stooper for any developer or Eclipse user, who tries to do a redeploy while developing/testing their app. This seems like a major regression from Geronimo 1.0 to me Stopping a TSSbean also stops the orb it's attached to -- Key: GERONIMO-2063 URL: http://issues.apache.org/jira/browse/GERONIMO-2063 Project: Geronimo Type: Bug Security: public(Regular issues) Components: CORBA Versions: 1.1 Reporter: David Jencks Priority: Critical Fix For: 1.1.1 While working with the MagicGBall I noticed that you can't stop and start the application: when you try to start it again you get an exception saying the orb is shut down. I deployed the app using the console, the magicGBall ear, and either one of the plans in magicgball/target/plan. I stopped and tried to start the app after deployment using the console. I won't argue much if this gets taken out of 1.1. -- 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-2063) Stopping a TSSbean also stops the orb it's attached to
[ http://issues.apache.org/jira/browse/GERONIMO-2063?page=comments#action_12420098 ] David Jencks commented on GERONIMO-2063: I haven't checked, but I'm very confident that this problem was also present in geronimo 1.0. I believe the simplest workaround is to package the orb and tss bean(s) in the same configuration, possibly the same configuration as the ejb app. Then the orb and tss beans will have the same lifecycle unless you manually stop or start a tss bean. Note that the tck is set up this way and our sample corba configs are also set up this way. The problem occurs if you package the tss beans with your application rather than with your orb. Stopping a TSSbean also stops the orb it's attached to -- Key: GERONIMO-2063 URL: http://issues.apache.org/jira/browse/GERONIMO-2063 Project: Geronimo Type: Bug Security: public(Regular issues) Components: CORBA Versions: 1.1 Reporter: David Jencks Priority: Critical Fix For: 1.1.1 While working with the MagicGBall I noticed that you can't stop and start the application: when you try to start it again you get an exception saying the orb is shut down. I deployed the app using the console, the magicGBall ear, and either one of the plans in magicgball/target/plan. I stopped and tried to start the app after deployment using the console. I won't argue much if this gets taken out of 1.1. -- 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: (AMQ-805) Restart network bridges if they ever get stopped
Restart network bridges if they ever get stopped Key: AMQ-805 URL: https://issues.apache.org/activemq/browse/AMQ-805 Project: ActiveMQ Type: Improvement Reporter: Hiram Chirino Assigned to: Hiram Chirino Right now it seems like we only trap remote exceptions and then restart the bridge. I think we should restart the network bridge if the bridge fails for any reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-744) add a vmstat agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on
[ https://issues.apache.org/activemq/browse/AMQ-744?page=all ] Adrian Co resolved AMQ-744: --- Resolution: Fixed Added summary for blocks received, blocks sent, context switch, user time, system time, idle time, wait time. add a vmstat agent to the maven activemq performance plugin so we can track the CPU, IO, RAM use on the machine we are running the test on Key: AMQ-744 URL: https://issues.apache.org/activemq/browse/AMQ-744 Project: ActiveMQ Type: Improvement Components: Performance Test Reporter: james strachan Assignee: Adrian Co Fix For: 4.1 When running a performance test it would be good to spawn off a process to run 'vmstat' which works on linux and solaris (the flags may differ etc) which outputs the amout of CPU use in system/user code and how much is idle together with RAM IO numbers. I'd be good to include in each snapshot whatever vmstat numbes we can find so we can see how the box was doing as the test was running. e.g. sample index=5 ... machine cpuSystem=50 cpuUser=25 cpuIdle=25 ram=44 io=1000/ /sample Note that we may wanna make a few different machine monitoring agents using different tools - so lets make it pluggable - let 'em write whatever XML they can - though we should be able to get linux and solaris done (linux only would be fine for now) To call vmstat we'll need to do a System.exec() then parse the results etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ http://issues.apache.org/jira/browse/GERONIMO-1887?page=all ] David Jencks updated GERONIMO-1887: --- Fix Version: 1.2 (was: 1.1.1) Fixed in 1.1.1 in rev 420574 Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: http://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.x Reporter: Paul McMahan Assignee: David Jencks Priority: Minor Fix For: 1.2 Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- 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: [jira] Updated: (TUSCANY-527) First cut of the work scheduler implementation
On Jul 9, 2006, at 3:00 PM, Jeremy Boynes wrote: On Jul 9, 2006, at 11:08 AM, Jeremy Boynes wrote: On Jul 9, 2006, at 9:16 AM, David Jencks wrote: There's a geronimo version of the commonj spec at org.apache.geronimo.specs:geronimo-commonj_1.1_spec:1.0:jar at ibiblio. I'm not entirely sure what auspices this was published under since geronimo doesn't have a tck for commonj. If there are any problems with this jar please speak up on the geronimo dev list. Thanks David, I'll use that for now. There is also a version in the Apache WebServices WSRF project but they don't seem to have published it. I found a couple of problems in Geronimo's version with the signatures (e.g. exceptions missing). I modified the Geronimo source to match the spec javadoc I downloaded and it seems to compile now. Attached is a patch for geronimo-spec (from https:// svn.apache.org/repos/asf/geronimo/specs/trunk) geronimo-commonj.patch This bumps the commonj spec jar version to 1.0.1-SNAPSHOT - hope that's the right version. Dave, if this works for you can you get a snapshot version uploaded so that Tuscany folk won't have to build from source. Jeremy, There's a new SNAPSHOT on people.apache.org -- http://people.apache.org/repository/org.apache.geronimo.specs/jars/ geronimo-commonj_1.1_spec-1.0.1-SNAPSHOT.jar --kevan
[jira] Commented: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ http://issues.apache.org/jira/browse/GERONIMO-1887?page=comments#action_12420103 ] David Jencks commented on GERONIMO-1887: This issue was in fact completed in 1.1 previously, rev 420574 broke the console. This was not detectable without a clean build. I hope the m2 war plugin is not so flaky. Restored to working state in rev 420581. Still needs review for 1.2. Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: http://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.x Reporter: Paul McMahan Assignee: David Jencks Priority: Minor Fix For: 1.2 Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- 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: Regarding ClassLoader Changes in Geronimo 1.1
Manu George wrote: Hi, I have an application that is packaged as an EAR. The WAR inside the EAR is having some images in the images directory directly inside the war. In Geronimo 1.0, I was able to access them using Thread.currentThread().getContextClassLoader().getResource() method, but now I am unable to do so. On debugging I found that the classloader I got for 1.0 was WebappClassLoader from Tomcat which had access to the files, while for 1.1, I got JarFileClassLoader of geronimo which did not have access to those files. Can anyone throw further light on this problem. Thanks Manu Hi, can you try to get the correct resource URL via the URL javax.servlet.ServletContext.getResource(String path) method? Once you have the base URL to the war you can easily load your resources from the war. Thanks, Mario
TCK Dog
Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. What do you think? -David
Re: 1.1 Press Release
From what I understand, the code release has been made available on the Geronimo web site and a general announcement has been made with regards to its availability. Geronimo folks: do you want this also issued as an official press release? If so, do you have any customers or partners we could include as part of the announcement? E.g. quotes or complementary announcements? On Sat, 8 Jul 2006, Sally Khudairi wrote: Hello Matt, Thank you for your note. I'm curious -- did this release go out? If so, where was it distributed and via which channels? I didn't see any feedback from the PRC on this, so I'm just double-checking to make sure I haven't missed any emails. Thanks in advance for this. Kind regards, Sally --- Matt Hogstrom [EMAIL PROTECTED] wrote: Here is the press release. I've included Jacek's comments. I am not sure of the City and State so I'll defer to the PRC to update those. Cheers Apache Software Foundation Announces Release of Apache Geronimo Version 1.1 Usability Improvements Simplify Configuration and Deployment of J2EE Applications (City, State) July 05, 2006 -- The Apache Software Foundation is pleased to announce the release of Apache Geronimo Version 1.1, an open source application server from the Apache community. The release continues the J2EE certification path led by the previous version of Geronimo, providing a fully compliant and usable J2EE container suitable for everything from development to enterprise deployments. Apache Geronimo v1.1 introduces several structural changes improving scalability, portability and overall organization, as well as including new features and functionality. Enhancements have been made to the administration console including memory utilization graphics and plugins to improve usability. Also, improvements have been made to the innovative configuration and administration/plug-in architecture. Whereas the previous version offered a full J2EE configuration, v1.1 includes a �Little G� configuration, a smaller footprint web-oriented version of Geronimo that can be scaled up to JMS or full J2EE using plug-ins as users� needs change. The addition of Little G provides an option for those who want to use Geronimo for lightweight applications without the additional installation overhead. One of the main goals of Apache Geronimo is flexibility. Geronimo is flexible enough to include only the capabilities that users want and need. Geronimo already offers a modular architecture that makes it easy to create custom distributions with custom feature sets. With v1.1, we (the Apache Geronimo Team) looked at users� needs and added even more features to benefit those needs, increase functionality, and extend usability. The flexible, easy-to-use, and easy-to-configure application server is built from best-of-breed open source components and is fully licensed under the business-friendly Apache Software License offering multiple benefits to organizations and their development teams. The software is available for download from the Apache Geronimo web site (http://geronimo.apache.org/). About the Apache Software Foundation The Apache Software Foundation provides organizational, legal and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors' potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products. For more information on The Apache Software Foundation, please visit http://www.apache.org/. Java and J2EE are trademarks or registered trademarks of Sun Microsystems,Inc. in the United States and other countries. All other trademarks or registered trademarks herein are property of their respective owners. mobile +1 617 921 8656 :: fax +1 617 321 4085 siphttp://www.dorsetcafe.com/ trade http://www.haloworldwide.com/ self http://www.khudairi.net/ skype sallykhudairi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: TCK Dog
On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. What do you think? I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. So, it's not one dog, but several... Although I certainly had a lot of help from you, David J, and Dain, It'd be great to see a broader base of participation... I see the following pieces: 1) Keeping builds running through Continuum 2) Keeping tests running through GBuild 3) Monitoring/advertising test results. 4) Fixing problems It's #4 that can be the killer and where we should be working as a team... but the others can eat up time, also. I have #1 going for 1.1.1-SNAPSHOT and 1.2-SNAPSHOT. Hope to get #2 going later today... Now, would be a great time for getting more people involved... --kevan
Geronimo 1.1 JARs in Maven 2 Repo
Since we don't necessarily plan on converting Geronimo 1.1.x to Maven 2, can we post the 1.1 JARs in a Maven 2 repo somewhere, with a structure corresponding to the new 1.2/Maven 2 group IDs (o.a.g.*) but no POMs? That would help with building plugins using Maven 2 against the 1.1 JARs (such as kernel, system, etc.). At least if you put in an explicit dependency in your plugin POM it should be able to pull the JARs for you. (And of course they're only needed at compile time since they'll be pulled in via parent module dependencies at runtime.) If no one has any better idea, maybe I'll post them on my people.apache.org for now. But if we can agree to post them to the Maven 2 repo at iBiblio that would be great. Thanks, Aaron
Re: 1.1 Press Release
Susan Wu wrote: From what I understand, the code release has been made available on the Geronimo web site and a general announcement has been made with regards to its availability. Geronimo folks: do you want this also issued as an official press release? If so, do you have any customers or partners we could include as part of the announcement? E.g. quotes or complementary announcements? Susan, What are your thoughts here? I think you probably could have a line of customers or partners who would like to be a part of the announcement, especially certain small brand-spanking-new struggling companies ;-) Jeff On Sat, 8 Jul 2006, Sally Khudairi wrote: Hello Matt, Thank you for your note. I'm curious -- did this release go out? If so, where was it distributed and via which channels? I didn't see any feedback from the PRC on this, so I'm just double-checking to make sure I haven't missed any emails. Thanks in advance for this. Kind regards, Sally --- Matt Hogstrom [EMAIL PROTECTED] wrote: Here is the press release. I've included Jacek's comments. I am not sure of the City and State so I'll defer to the PRC to update those. Cheers Apache Software Foundation Announces Release of Apache Geronimo Version 1.1 Usability Improvements Simplify Configuration and Deployment of J2EE Applications (City, State) July 05, 2006 -- The Apache Software Foundation is pleased to announce the release of Apache Geronimo Version 1.1, an open source application server from the Apache community. The release continues the J2EE certification path led by the previous version of Geronimo, providing a fully compliant and usable J2EE container suitable for everything from development to enterprise deployments. Apache Geronimo v1.1 introduces several structural changes improving scalability, portability and overall organization, as well as including new features and functionality. Enhancements have been made to the administration console including memory utilization graphics and plugins to improve usability. Also, improvements have been made to the innovative configuration and administration/plug-in architecture. Whereas the previous version offered a full J2EE configuration, v1.1 includes a �Little G� configuration, a smaller footprint web-oriented version of Geronimo that can be scaled up to JMS or full J2EE using plug-ins as users� needs change. The addition of Little G provides an option for those who want to use Geronimo for lightweight applications without the additional installation overhead. One of the main goals of Apache Geronimo is flexibility. Geronimo is flexible enough to include only the capabilities that users want and need. Geronimo already offers a modular architecture that makes it easy to create custom distributions with custom feature sets. With v1.1, we (the Apache Geronimo Team) looked at users� needs and added even more features to benefit those needs, increase functionality, and extend usability. The flexible, easy-to-use, and easy-to-configure application server is built from best-of-breed open source components and is fully licensed under the business-friendly Apache Software License offering multiple benefits to organizations and their development teams. The software is available for download from the Apache Geronimo web site (http://geronimo.apache.org/). About the Apache Software Foundation The Apache Software Foundation provides organizational, legal and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors' potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products. For more information on The Apache Software Foundation, please visit http://www.apache.org/. Java and J2EE are trademarks or registered trademarks of Sun Microsystems,Inc. in the United States and other countries. All other trademarks or registered trademarks herein are property of their respective owners. mobile +1 617 921 8656 :: fax +1 617 321 4085 siphttp://www.dorsetcafe.com/ trade http://www.haloworldwide.com/ self http://www.khudairi.net/ skype sallykhudairi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: openejb itests?
Bill,
Here's the latest patch:
http://issues.apache.org/jira/secure/attachment/12336616/geronimo-deployment-plugin-RTC-VOTE.3.patch
Now let's see how itests are doing.
Cheers
Prasad.
On 7/7/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Hi Bill,
No. I applied the patch against an existing copy of the trunk tree and
local repo. Let me apply this against the latest tree (the one that
has Jason's big patch). I'll also clean out the local repo. I'll let
you know shortly.
Cheers
Prasad
On 7/7/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi Prasad,
Perhaps I'm missing another patch or something?
The top level pom (geronimo/pom.xml) sets the src directory to 'src/java'.
The deployment plugin has its src in the standard m2 place of
'src/main/java'. Thus nothing gets compiled. I reset the src directory to
'src/main/java' and I get many compile errors.
I applied the patch (and only that patch) to a fresh clean check out of
geronimo Rev 419886 (head of trunk).
I must be missing something if you are able to get a clean compile.
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
On Jul 6, 2006, at 8:04 PM, Prasad Kashyap wrote:
Oh I forgot to mention.
Check the *.log files in the top level module and individual modules.
If I remember right, you can run the mvn site:site command to generate
an HTML page of the results.
Cheers
Prasad
On 7/6/06, Bill Dudney [EMAIL PROTECTED] wrote:
Hi Prasad,
Thanks, - I guess I was hoping that it was something smaller :-)
I had to;
1) install the jetty version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
2) install the tomcat version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
3) enable the utils
3) delete the explicit mention of version from the maven-site-plugin in
teardown-tests.pom.xml
4) add junit as a dependency otherwise the mvn failed unless
-Dmaven.test.skip=true was specified
5) run mvn
Although the build succeeds, nothing appears to happen (see attached log)
From what I can tell the geronimo-deployment-plugin is not being built
correctly, none of the src's are being compiled and placed into the jar
file. I poked around but the reason escapes me...
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Geronimo Integration Tests
[INFO] Geronimo :: itests :: system
[INFO] Geronimo :: itests :: webcontainer
[INFO] Geronimo :: itests :: teardown
[INFO]
[INFO] Building Geronimo Integration Tests
[INFO]task-segment: [install]
[INFO]
[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip
[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
[delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml
to
/Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom
[INFO]
[INFO] Building Geronimo :: itests :: system
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing
Re: TCK Dog -- monitoring results
On Jul 10, 2006, at 11:19 AM, Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. [...] I see the following pieces: 3) Monitoring/advertising test results. You have any ideas on what we can do raise awareness of what is going on with our tck status, or track what's not being worked on? Hey all you committers, any suggestions? Do you actually peek at the results on a regular basis? If not, do you have any suggestions on what would be the best way to communicate TCK status? -David
Re: How were the Geronimo 1.0 and 1.1 artifacts published to a Maven2 Repo?
Why do we need to do this? M2 can load M1 artifacts from an M1 repo. Regards, Alan Matt Hogstrom wrote: Donald, I had to manually publish these for the M2. At the time the tag was cut the pom.xml did not have updated entries for M2 to properly publish them. The pom is being corrected for 1.2-SNAPSHOT. Donald Woods wrote: Still wondering how this was done Did someone have to run mvn install:install-file ... for every Geronimo 1.0 and 1.1 artifact to get them published to a Maven 2 repo? Since the Eclipse plug-in and any plug-ins we publish to GeronimoPlugins require artifacts from Maven 2, we need this documented somewhere -Donald Donald Woods wrote: For Geronimo 1.1, both of the Eclipse plugin and Daytrader sample require valid Maven2 POM files in order to determine the dependencies/imports when building, so how were these created from the current Maven1 based Geronimo 1.0 and 1.1 builds? Is there a way we can automate this for our local Geronimo 1.1.1-SNAPSHOT builds? -Donald
Re: TCK Dog
On Jul 10, 2006, at 3:33 PM, Alan D. Cabrera wrote: Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. What do you think? I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. So, it's not one dog, but several... Although I certainly had a lot of help from you, David J, and Dain, It'd be great to see a broader base of participation... I see the following pieces: 1) Keeping builds running through Continuum 2) Keeping tests running through GBuild 3) Monitoring/advertising test results. 4) Fixing problems It's #4 that can be the killer and where we should be working as a team... but the others can eat up time, also. I have #1 going for 1.1.1-SNAPSHOT and 1.2-SNAPSHOT. Hope to get #2 going later today... Now, would be a great time for getting more people involved... We have a special Jira project for #4, no? Not that this solves the problem but, I was just wondering. No, not that I'm aware of. I thought there were issues getting a Jira set up with necessary permissions. Would be really nice, though... I've just been using our tck mailing list for this... --kevan
[jira] Commented: (GERONIMO-2168) NPE when deploying RAR
[
http://issues.apache.org/jira/browse/GERONIMO-2168?page=comments#action_12420162
]
Tim Howe commented on GERONIMO-2168:
This is indeed strange. I modified GBeanInstance.java like so:
{{private String printException(Throwable t) {
StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
+System.err.println(t = + t);
+System.err.println(printWriter = + printWriter);
t.printStackTrace(printWriter);
printWriter.flush();
return stringWriter.toString();
}
}}
And here's the output I got on my console:
{{t = null
printWriter = [EMAIL PROTECTED]
}}
I don't know how it's even possible to throw a null. I wrote a small test
class and attempting to throw null seems to result in a NullPointerException.
But somehow by the time this gets to printException(Throwable), it's null.
I've put more println()s in the exception handler itself to see if I can find
anything further.
NPE when deploying RAR
--
Key: GERONIMO-2168
URL: http://issues.apache.org/jira/browse/GERONIMO-2168
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Versions: 1.1
Environment: Solaris 9 (Sparc), Java 1.5.0_06 (also appears in 1.4.2_05)
Reporter: Tim Howe
Priority: Critical
I've been using Geronimo 1.0, and now 1.1, as the app server for the
development of a JCA connector for our proprietary EIS and generally
been very happy with it.
I've had no problem running servlets, deploying WARs, and the like.
However, I've run into a problem deploying a RAR that I built. I view
it as highly probably that there's a bug somewhere in my resource
adapter, but it seems to be triggering a bug in Geronimo, which appears
in both Java 1.4.2 and 1.5:
{quote}
{{23:52:38,091 ERROR [GBeanInstanceState] Error while starting; GBean is now
in the FAILED state:
abstractName=com.celebrityresorts/rcc/0/rar?J2EEApplication=null,JCAConnectionFactory=Celebrity%20Resorts%20RCC%20development%20instance,JCAResource=com.celebrityresorts/rcc/0/rar,ResourceAdapter=com.celebrityresorts/rcc/0/rar,ResourceAdapterModule=com.celebrityresorts/rcc/0/rar,j2eeType=JCAManagedConnectionFactory,name=Celebrity%20Resorts%20RCC%20development%20instance
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:401)
at java.io.PrintWriter.print(PrintWriter.java:546)
at java.io.PrintWriter.println(PrintWriter.java:683)
at java.lang.Throwable.printStackTrace(Throwable.java:510)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.printException(GBeanInstance.java:1047)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:983)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540)}}
{quote}
and so on. The only thing I can figure is that somehow the Exception
getting thrown is null, but I can't see how, as it seems to stem from
bq. {{throw new Exception(A reference has failed so construction can not
complete);}}
so I'm very confused. Of course it's also quite late for me and I may
be reading the stack trace wrong.
--
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: Geronimo Tooling 1.1 Release Plans
On Jul 10, 2006, at 3:29 PM, Lin Sun wrote:Hi Sachin,I tried the plugin today. I am able to start the server and run my firstsimple application which is great! Here are some comments I have so far.1) You probably already knew this - Download and Install button doesn't workyet. I went over to the eclipse update site, and didn't see any 1.1features or plugins there. This is part of the publishing process. Once the release is voted on, the jars will be published to the update site.2) I tried the new static content (I interpret that as html only)automatically republish feature today. It worked well! One thing I noticed is that after I made a change to the html file and saveit, the server's state changed from synchronized to republish whichindicated a republish was needed here. But actually it was not needed as Isaw the changes in the browser right away without the republish. My guessis that you are getting the republish state from WTP framework when a changeis saved in my project but this can be confusing to the users.This feature is not yet implemented fully.Lin-Original Message-From: Sachin Patel [mailto:[EMAIL PROTECTED]] On Behalf Of Sachin PatelSent: Friday, July 07, 2006 2:51 PMTo: dev@geronimo.apache.orgSubject: Re: Geronimo Tooling 1.1 Release PlansThanks Paul, see inline...On Jul 7, 2006, at 11:13 AM, Paul McMahan wrote: Sachin, I just checked out the RC3 and it looks GREAT!! I love thefact that using the Eclipse plugin I can create a web project, deployit to Geronimo, debug/update my JSP and see the changes reflectedimmediately (and I mean *immediately*) via a simple app republish, "simple app republish" Simple as it is to do, this is still a problem that needs to be solved. And is partially solved in this release. If you are working with static content only, if you open the server editor and select the "run resources from workspace" option, and restart the server and redeploy your app, any changes to static content dont require a republish and you can simply refresh your browser. I want to be able to run an entire ear from within the project without having to generate an ear, and this will take some work in the server to be able to do this. So currently this feature is restricted to stand-alone web apps with static only content. -sachin
[jira] Commented: (GERONIMO-2168) NPE when deploying RAR
[
http://issues.apache.org/jira/browse/GERONIMO-2168?page=comments#action_12420169
]
Tim Howe commented on GERONIMO-2168:
I made the following change as well:
{{
if (instance instanceof GBeanLifecycle) {
checkIfShouldFail();
try {
((GBeanLifecycle) instance).doStart();
} catch (Exception e) {
+System.err.println(e = + e);
+e.printStackTrace();
stateReason = the doStart method threw an exception. \n +
printException(e);
throw e;
}
}
}}
And on stderr out comes:
{{
e = null
}}
Then the e.printStackTrace() generates an NPE of course. According to the Java
spec this behavior shouldn't even be possible. Does anyone have any thoughts?
NPE when deploying RAR
--
Key: GERONIMO-2168
URL: http://issues.apache.org/jira/browse/GERONIMO-2168
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Versions: 1.1
Environment: Solaris 9 (Sparc), Java 1.5.0_06 (also appears in 1.4.2_05)
Reporter: Tim Howe
Priority: Critical
I've been using Geronimo 1.0, and now 1.1, as the app server for the
development of a JCA connector for our proprietary EIS and generally
been very happy with it.
I've had no problem running servlets, deploying WARs, and the like.
However, I've run into a problem deploying a RAR that I built. I view
it as highly probably that there's a bug somewhere in my resource
adapter, but it seems to be triggering a bug in Geronimo, which appears
in both Java 1.4.2 and 1.5:
{quote}
{{23:52:38,091 ERROR [GBeanInstanceState] Error while starting; GBean is now
in the FAILED state:
abstractName=com.celebrityresorts/rcc/0/rar?J2EEApplication=null,JCAConnectionFactory=Celebrity%20Resorts%20RCC%20development%20instance,JCAResource=com.celebrityresorts/rcc/0/rar,ResourceAdapter=com.celebrityresorts/rcc/0/rar,ResourceAdapterModule=com.celebrityresorts/rcc/0/rar,j2eeType=JCAManagedConnectionFactory,name=Celebrity%20Resorts%20RCC%20development%20instance
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:401)
at java.io.PrintWriter.print(PrintWriter.java:546)
at java.io.PrintWriter.println(PrintWriter.java:683)
at java.lang.Throwable.printStackTrace(Throwable.java:510)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.printException(GBeanInstance.java:1047)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:983)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540)}}
{quote}
and so on. The only thing I can figure is that somehow the Exception
getting thrown is null, but I can't see how, as it seems to stem from
bq. {{throw new Exception(A reference has failed so construction can not
complete);}}
so I'm very confused. Of course it's also quite late for me and I may
be reading the stack trace wrong.
--
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: TCK Dog -- monitoring results
On Jul 10, 2006, at 3:38 PM, David Blevins wrote: On Jul 10, 2006, at 11:19 AM, Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. [...] I see the following pieces: 3) Monitoring/advertising test results. You have any ideas on what we can do raise awareness of what is going on with our tck status, or track what's not being worked on? Some sort of jira reporting system (as Alan mentioned) would be useful for tracking problems. The GBuild summary reports certainly help out a lot. Biggest problem is probably getting from the report to having enough data to start categorizing/diagnosing the problem. --kevan Hey all you committers, any suggestions? Do you actually peek at the results on a regular basis? If not, do you have any suggestions on what would be the best way to communicate TCK status? -David
Re: [jira] Commented: (GERONIMO-2168) NPE when deploying RAR
Donald Woods (JIRA) writes: Have you tried removing the spaces from the name and giving it a real Maven friendly version number like 0.1 instead of 0? I just gave this a go and no dice. Thanks though; any other thoughts?
Re: [M2 build] : Error building application uddi-db on XP
This is another windows sucks problem... this one being windows file locking sucks. You will only see this on windows. But... what appears to be more troubling is that the antrun plugin is running twice! :-( --jason On Jul 10, 2006, at 5:17 AM, Jacek Laskowski wrote: On 7/10/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Seeing this error on Windows XP only. Unable to recreate it on Linux. I am trying to build the trunk using m2. I began with a clean repo and did a fresh checkout. I executed build.bat and it ran the bootstrap stage. Then I executed build.bat -Dstage=assembly -Dmaven.test.skip=true. It failed while trying to build applications/uddi-db with the following error ... Embedded error: Unable to delete file C:\Apache\geronimo\trunk\applications\uddi-db\target\resources \META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck Got exactly the same error while building Geronimo in svnkmerge/m2migration and was about to write to dev (!) What a coincidence, isn't it? Doing other stuff and haven't looked into it yet. If you know the answer, please speak up. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Geronimo 1.1 JARs in Maven 2 Repo
On Jul 10, 2006, at 12:36 PM, Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Maven 1 repos can be used from Maven 2. I didn't know that. Why would we need to post maven 1 jars into a maven 2 repository? Well, if you're creating a Maven 2 project now, and you use the group ID geronimo, you know this is going to have to change as soon as 1.2 is released. It might be nice to be able to go ahead and use the new Geronimo 1.2/Maven 2 group IDs like org.apache.geronimo.modules for 1.1 as that would stay valid for 1.2 and beyond. So if we put the 1.1 JARs in a Maven 2 repo with the group ID org.apache.geronimo.modules then any Geronimo-using POMs written today could be forward-compatible. What do you think? I sure hope we manage to change the groupIds to org.apache.geronimo before anything gets released. thanks david jencks Thanks, Aaron
[jira] Commented: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ http://issues.apache.org/jira/browse/GERONIMO-1887?page=comments#action_12420176 ] David Jencks commented on GERONIMO-1887: Sorry, that was ambiguous. I meant that someone needs to look at trunk to see if it is already fixed or still needs work. Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: http://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.x Reporter: Paul McMahan Assignee: David Jencks Priority: Minor Fix For: 1.2 Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- 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: Geronimo 1.1 JARs in Maven 2 Repo
On Jul 10, 2006, at 3:10 PM, David Jencks wrote: I sure hope we manage to change the groupIds to org.apache.geronimo before anything gets released. I think that this should be done when we are ready to reorganize the 1.2 tree for m2... and probably not before. --jason
[jira] Commented: (GERONIMO-2177) Move the installer portion of assembly out of trunk to sandbox
[ http://issues.apache.org/jira/browse/GERONIMO-2177?page=comments#action_12420179 ] Jason Dillon commented on GERONIMO-2177: I agree. +1 Move the installer portion of assembly out of trunk to sandbox -- Key: GERONIMO-2177 URL: http://issues.apache.org/jira/browse/GERONIMO-2177 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Reporter: Kevan Miller The installer code does not currently work. It's liable to cause build failures as we move into the future. It's also not going to work in an m2 build. I think it's time to move it out of our trunk. -- 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: [M2 build] : Error building application uddi-db on XP
Ug... AntRun always seems to end up causing more problems than it resolves. May need to create a plugin to execute sql to get around this... which is probably a good idea anyways. Luckily I've done that a few times, should be easy to cook up. --jason On Jul 10, 2006, at 5:17 AM, Jacek Laskowski wrote: On 7/10/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Seeing this error on Windows XP only. Unable to recreate it on Linux. I am trying to build the trunk using m2. I began with a clean repo and did a fresh checkout. I executed build.bat and it ran the bootstrap stage. Then I executed build.bat -Dstage=assembly -Dmaven.test.skip=true. It failed while trying to build applications/uddi-db with the following error ... Embedded error: Unable to delete file C:\Apache\geronimo\trunk\applications\uddi-db\target\resources \META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck Got exactly the same error while building Geronimo in svnkmerge/m2migration and was about to write to dev (!) What a coincidence, isn't it? Doing other stuff and haven't looked into it yet. If you know the answer, please speak up. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Assigned: (GERONIMO-2175) etc/explicit_versions.properties should be automatically generated (or made unecessary)
[ http://issues.apache.org/jira/browse/GERONIMO-2175?page=all ] Jason Dillon reassigned GERONIMO-2175: -- Assign To: Jason Dillon etc/explicit_versions.properties should be automatically generated (or made unecessary) --- Key: GERONIMO-2175 URL: http://issues.apache.org/jira/browse/GERONIMO-2175 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.2 explicit_versions.properties is an error prone and fragile mechanism used to insure the appropriate artifacts are loaded during a Geronimo build. It should be possible to automatically generate the file (or dynamically calculate as resources are loaded). -- 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-2175) etc/explicit_versions.properties should be automatically generated (or made unecessary)
[ http://issues.apache.org/jira/browse/GERONIMO-2175?page=all ] Jason Dillon updated GERONIMO-2175: --- Fix Version: 1.2 (was: Wish List) etc/explicit_versions.properties should be automatically generated (or made unecessary) --- Key: GERONIMO-2175 URL: http://issues.apache.org/jira/browse/GERONIMO-2175 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.2 explicit_versions.properties is an error prone and fragile mechanism used to insure the appropriate artifacts are loaded during a Geronimo build. It should be possible to automatically generate the file (or dynamically calculate as resources are loaded). -- 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-1710) Geronimo timestamp plugin for Maven2
[ http://issues.apache.org/jira/browse/GERONIMO-1710?page=comments#action_12420182 ] Jason Dillon commented on GERONIMO-1710: What is the status of this? I recall seeing some mail about if we needed this plugin or not... but I don't recall the outcome. Geronimo timestamp plugin for Maven2 Key: GERONIMO-1710 URL: http://issues.apache.org/jira/browse/GERONIMO-1710 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Jacek Laskowski Assignee: Anders Hessellund Jensen Priority: Minor This is a contribution of Anders to create the geronimo-version.properties file with timestamp information during Geronimo's build. It should eventually end up as an Maven2 official plugin since there're not much reason to keep it here. -- 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-2175) etc/explicit_versions.properties should be automatically generated (or made unecessary)
[ http://issues.apache.org/jira/browse/GERONIMO-2175?page=comments#action_12420183 ] Jason Dillon commented on GERONIMO-2175: We must implement a solution to this, probably to just have the packaging plugin generate the mapping at runtime from the projects dependencies. Currently using ../../etc/explicit_versions.properties is causing Continuum-based builds to fail, since it will check out a single module and compile... which means that there is no ../../etc etc/explicit_versions.properties should be automatically generated (or made unecessary) --- Key: GERONIMO-2175 URL: http://issues.apache.org/jira/browse/GERONIMO-2175 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.2 explicit_versions.properties is an error prone and fragile mechanism used to insure the appropriate artifacts are loaded during a Geronimo build. It should be possible to automatically generate the file (or dynamically calculate as resources are loaded). -- 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: [M2 build] : Error building application uddi-db on XP
Why are the uddi-* webapp files duplicated in the -server and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate it on Linux.
I am trying to build the trunk using m2. I began with a clean repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-
INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-
INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources\META-
INF\geronimo-uddi-db\var\derby
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources\META-
INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
--
--
[INFO] For more information, run Maven with the -e switch
[INFO]
--
--
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error occurs.
Cheers
Prasad
Re: TCK Dog -- monitoring results
I have been remiss in my TCK duties. I'll reset my TCK e-mail and watch for JIRAs. David Blevins wrote: On Jul 10, 2006, at 11:19 AM, Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. [...] I see the following pieces: 3) Monitoring/advertising test results. You have any ideas on what we can do raise awareness of what is going on with our tck status, or track what's not being worked on? Hey all you committers, any suggestions? Do you actually peek at the results on a regular basis? If not, do you have any suggestions on what would be the best way to communicate TCK status? -David
Re: How were the Geronimo 1.0 and 1.1 artifacts published to a Maven2 Repo?
Doh...I meant the Spec jars. Alan D. Cabrera wrote: Why do we need to do this? M2 can load M1 artifacts from an M1 repo. Regards, Alan Matt Hogstrom wrote: Donald, I had to manually publish these for the M2. At the time the tag was cut the pom.xml did not have updated entries for M2 to properly publish them. The pom is being corrected for 1.2-SNAPSHOT. Donald Woods wrote: Still wondering how this was done Did someone have to run mvn install:install-file ... for every Geronimo 1.0 and 1.1 artifact to get them published to a Maven 2 repo? Since the Eclipse plug-in and any plug-ins we publish to GeronimoPlugins require artifacts from Maven 2, we need this documented somewhere -Donald Donald Woods wrote: For Geronimo 1.1, both of the Eclipse plugin and Daytrader sample require valid Maven2 POM files in order to determine the dependencies/imports when building, so how were these created from the current Maven1 based Geronimo 1.0 and 1.1 builds? Is there a way we can automate this for our local Geronimo 1.1.1-SNAPSHOT builds? -Donald
Re: [M2 build] : Error building application uddi-db on XP
It appears that the uddi-db module should *NOT* have any webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate it on Linux.
I am trying to build the trunk using m2. I began with a clean repo
and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources\META-
INF\geronimo-uddi-db\var\derby
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
-
---
[INFO] For more information, run Maven with the -e switch
[INFO]
-
---
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error occurs.
Cheers
Prasad
Re: [M2 build] : Error building application uddi-db on XP
On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: So, unless someone can shed some light onto why the db module has webapp files in it, I'm going to remove them. I don't know, but there must be a svn command that would help us to find it out, shouldn't there? Wouldn't svn log tell us about their origins? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [M2 build] : Error building application uddi-db on XP
The uddi-db module should be buildable now since #420661
Give it a whirl and let me know if you run into anything else.
--jason
On Jul 10, 2006, at 4:28 PM, Jason Dillon wrote:
It appears that the uddi-db module should *NOT* have any webapp
stuff, but only the derby database files.
So, unless someone can shed some light onto why the db module has
webapp files in it, I'm going to remove them.
--jason
On Jul 10, 2006, at 4:15 PM, Jason Dillon wrote:
Why are the uddi-* webapp files duplicated in the -server and -db
modules?
snip
uddi-db/src
uddi-db/src/sql
uddi-db/src/sql/juddi.sql
uddi-db/src/webapp
uddi-db/src/webapp/happyjuddi.jsp
uddi-db/src/webapp/WEB-INF
uddi-db/src/webapp/WEB-INF/juddi.properties
uddi-db/src/webapp/WEB-INF/web.xml
uddi-server/src
uddi-server/src/webapp
uddi-server/src/webapp/happyjuddi.jsp
uddi-server/src/webapp/WEB-INF
uddi-server/src/webapp/WEB-INF/juddi.properties
uddi-server/src/webapp/WEB-INF/web.xml
/snip
--jason
On Jul 10, 2006, at 5:12 AM, Prasad Kashyap wrote:
Seeing this error on Windows XP only. Unable to recreate it on
Linux.
I am trying to build the trunk using m2. I began with a clean
repo and
did a fresh checkout.
I executed build.bat and it ran the bootstrap stage. Then I executed
build.bat -Dstage=assembly -Dmaven.test.skip=true.
It failed while trying to build applications/uddi-db with the
following error
---
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[mkdir] Created dir:
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby
[sql] Executing file:
C:\Apache\geronimo\trunk\applications\uddi-db\src\sql\juddi.sql
[sql] 87 of 87 SQL statements executed successfully
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Built File: \happyjuddi.jsp
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[delete] Deleting directory
C:\Apache\geronimo\trunk\applications\uddi-db\taget\resources
\META-INF\geronimo-uddi-db\var\derby
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: Unable to delete file
C:\Apache\geronimo\trunk\applications\uddi-db\target\resources
\META-INF\geronimo-uddi-db\var\derby\UddiDatabase\db.lck
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 36 seconds
[INFO] Finished at: Mon Jul 10 07:47:20 EDT 2006
[INFO] Final Memory: 28M/51M
-
It is trying to execute the antrun plugin in the
applications/uddi-db/pom.xml a second time when the error occurs.
Cheers
Prasad
Re: [M2 build] : Error building application uddi-db on XP
As far as I can tell, someone just copied uddi-server to uddi-db and then never removed the webapp bits. Looks like its been like for about a year too. --jason On Jul 10, 2006, at 4:36 PM, Jacek Laskowski wrote: On 7/11/06, Jason Dillon [EMAIL PROTECTED] wrote: So, unless someone can shed some light onto why the db module has webapp files in it, I'm going to remove them. I don't know, but there must be a svn command that would help us to find it out, shouldn't there? Wouldn't svn log tell us about their origins? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: 1.1 Press Release
Susan Wu wrote: From what I understand, the code release has been made available on the Geronimo web site and a general announcement has been made with regards to its availability. Geronimo folks: do you want this also issued as an official press release? Yes please. If so, do you have any customers or partners we could include as part of the announcement? E.g. quotes or complementary announcements? I'll defer to others but I think the Press Release should be heading out straight away. The clock is ticking :) On Sat, 8 Jul 2006, Sally Khudairi wrote: Hello Matt, Thank you for your note. I'm curious -- did this release go out? If so, where was it distributed and via which channels? I didn't see any feedback from the PRC on this, so I'm just double-checking to make sure I haven't missed any emails. Thanks in advance for this. Kind regards, Sally --- Matt Hogstrom [EMAIL PROTECTED] wrote: Here is the press release. I've included Jacek's comments. I am not sure of the City and State so I'll defer to the PRC to update those. Cheers Apache Software Foundation Announces Release of Apache Geronimo Version 1.1 Usability Improvements Simplify Configuration and Deployment of J2EE Applications (City, State) July 05, 2006 -- The Apache Software Foundation is pleased to announce the release of Apache Geronimo Version 1.1, an open source application server from the Apache community. The release continues the J2EE certification path led by the previous version of Geronimo, providing a fully compliant and usable J2EE container suitable for everything from development to enterprise deployments. Apache Geronimo v1.1 introduces several structural changes improving scalability, portability and overall organization, as well as including new features and functionality. Enhancements have been made to the administration console including memory utilization graphics and plugins to improve usability. Also, improvements have been made to the innovative configuration and administration/plug-in architecture. Whereas the previous version offered a full J2EE configuration, v1.1 includes a �Little G� configuration, a smaller footprint web-oriented version of Geronimo that can be scaled up to JMS or full J2EE using plug-ins as users� needs change. The addition of Little G provides an option for those who want to use Geronimo for lightweight applications without the additional installation overhead. One of the main goals of Apache Geronimo is flexibility. Geronimo is flexible enough to include only the capabilities that users want and need. Geronimo already offers a modular architecture that makes it easy to create custom distributions with custom feature sets. With v1.1, we (the Apache Geronimo Team) looked at users� needs and added even more features to benefit those needs, increase functionality, and extend usability. The flexible, easy-to-use, and easy-to-configure application server is built from best-of-breed open source components and is fully licensed under the business-friendly Apache Software License offering multiple benefits to organizations and their development teams. The software is available for download from the Apache Geronimo web site (http://geronimo.apache.org/). About the Apache Software Foundation The Apache Software Foundation provides organizational, legal and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors' potential legal exposure. Through a collaborative and meritocratic development process, Apache projects deliver enterprise-grade, freely available software products that attract large communities of users. The pragmatic Apache License makes it easy for all users, commercial and individual, to deploy Apache products. For more information on The Apache Software Foundation, please visit http://www.apache.org/. Java and J2EE are trademarks or registered trademarks of Sun Microsystems,Inc. in the United States and other countries. All other trademarks or registered trademarks herein are property of their respective owners. mobile +1 617 921 8656 :: fax +1 617 321 4085 siphttp://www.dorsetcafe.com/ trade http://www.haloworldwide.com/ self http://www.khudairi.net/ skype sallykhudairi __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: 1.1 Press Release
On 7/11/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Geronimo folks: do you want this also issued as an official press release? Yes please. +1 If so, do you have any customers or partners we could include as part of the announcement? E.g. quotes or complementary announcements? I'll defer to others but I think the Press Release should be heading out straight away. The clock is ticking :) I have never been familiar with the process of including companies in a press release, so I'll defer it to others, too. I highly urge any company to speak up to be included ;-) +1 for issuing it asap. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
Sachin, I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http:// www.apache.org/dev/release.html#what-must-every-release-contain for more information. We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in... --kevan On Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-deployable-RC4.zip http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-updatesite-RC4.zip Here is my +1. - sachin
Re: How were the Geronimo 1.0 and 1.1 artifacts published to a Maven2 Repo?
Duh, I just re-read the thread. Regards, Alan Matt Hogstrom wrote: Doh...I meant the Spec jars. Alan D. Cabrera wrote: Why do we need to do this? M2 can load M1 artifacts from an M1 repo. Regards, Alan Matt Hogstrom wrote: Donald, I had to manually publish these for the M2. At the time the tag was cut the pom.xml did not have updated entries for M2 to properly publish them. The pom is being corrected for 1.2-SNAPSHOT. Donald Woods wrote: Still wondering how this was done Did someone have to run mvn install:install-file ... for every Geronimo 1.0 and 1.1 artifact to get them published to a Maven 2 repo? Since the Eclipse plug-in and any plug-ins we publish to GeronimoPlugins require artifacts from Maven 2, we need this documented somewhere -Donald Donald Woods wrote: For Geronimo 1.1, both of the Eclipse plugin and Daytrader sample require valid Maven2 POM files in order to determine the dependencies/imports when building, so how were these created from the current Maven1 based Geronimo 1.0 and 1.1 builds? Is there a way we can automate this for our local Geronimo 1.1.1-SNAPSHOT builds? -Donald
war manifest classpath in ear (GERONIMO-2125)
I've finally managed to reproduce the problem in GERONIMO-2125, in which you have an ear, with a war inside, with a manifest classpath, and the stuff on the mcp doesn't work. The problem is pretty much caused by our new configuration for the war, although I think a similar problem would occur for an exploded ejb jar in an ear. ( I suspect the latter doesn't work at all now, since in that case we should manually add the mcp entries to the cp, which we don't) so, we a uri out of the mcp, and try to resolve it against the war config base uri, such as web.war, and add it to the config classpath, so we get e.g. an entry of jar.jar. However, this is relative to the war config, which does not have this jar in it: it's actually in the containing ear config, typically up one directory. e.g. ear config is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty-server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car war config inside it is at /Users/david/geronimo/svn/geronimo/trunk/assemblies/j2ee-jetty-server/ target/geronimo-1.2-SNAPSHOT/repository/default/ear-1.0-SNAPSHOT/ 1152577205326/ear-1.0-SNAPSHOT-1152577205326.car/web.war the mcp entry should be ../jar.jar or we need to copy another copy of the jar.jar into the war configuration. I'm in favor of relativizing the mcp entry to ../jar.jar but I'm a little worried about the consequences. Anyone see any problems with this? thanks david jencks
Re: Geronimo 1.1 JARs in Maven 2 Repo
Aaron Mulder wrote: On 7/10/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Maven 1 repos can be used from Maven 2. I didn't know that. Why would we need to post maven 1 jars into a maven 2 repository? Well, if you're creating a Maven 2 project now, and you use the group ID geronimo, you know this is going to have to change as soon as 1.2 is released. It might be nice to be able to go ahead and use the new Geronimo 1.2/Maven 2 group IDs like org.apache.geronimo.modules for 1.1 as that would stay valid for 1.2 and beyond. So if we put the 1.1 JARs in a Maven 2 repo with the group ID org.apache.geronimo.modules then any Geronimo-using POMs written today could be forward-compatible. I think that it's better to have different group ids for the M1 and M2 jars since their contents, maven wise, are quite different. IIUC, we really shouldn't be putting M1 jars into an M2 repo. Regards, Alan
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
Ok thanks, but a license is not needed for the update site zip as this is handled by the update manager. As far as the deployable plugin the licenses only need to be packaged within the features and not each individual plugin.On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
Forget what I said... I'll add them.On Jul 10, 2006, at 9:41 PM, Sachin Patel wrote:Ok thanks, but a license is not needed for the update site zip as this is handled by the update manager. As far as the deployable plugin the licenses only need to be packaged within the features and not each individual plugin.On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin -sachin
[jira] Commented: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy
[
http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12420192
]
Kevan Miller commented on GERONIMO-2167:
Leonard, thanks much for the test case.
I haven't been able to reproduce on MAC OSX. I'm afraid that this is going to
be a Windows-based file locking gremlin. I suspect that the undeploy cleanup is
not finished before we're starting the deploy phase of a redeploy.
If you have a moment or two, would be interesting to know if the following
works/fails:
1) deploy
2) undeploy (not redeploy)
3) wait 1 minute
4) deploy
Meanwhile, I'll dust off my windoze box and see what I can find...
deployer.jar not cleaning up properly during redeploy and undeploy
--
Key: GERONIMO-2167
URL: http://issues.apache.org/jira/browse/GERONIMO-2167
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: deployment
Versions: 1.1
Environment: Win32/XP SP1
Sun JDK 1.5_06
Reporter: Leonard Wu
Assignee: Kevan Miller
Fix For: 1.1.1
Attachments: dwr-demo.war
deployment using deploy.jar doesn't appear to clean up correctly.
first deploy always works. subsequent re-deploy and un-deploy are problematic.
following illustrates the full sequence of events as i had encountered:
--
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Deployed littleoldme/dwrdemo/1.1/war
Started littleoldme/dwrdemo/1.1/war
Redeployed littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Error: Operation failed:
org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
Configuration already exists: littleoldme/dwrdemo/1.1/war
Configuration already exists: littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
of a module available on the selected server. Perhaps it has already
been stopped or undeployed? If you're trying to specify a
TargetModuleID, use the syntax TargetName|ModuleName instead. If
you're not sure what's running, try the list-modules command.
--
While in this broken state, i'm able to recover by manually removing the
${geronimo}/repository/littleoldme directory and removing the one line in
${geronimo}/var/config/config.xml that says
module load=false name=littleoldme/dwrdemo/1.1/war/
However, this only gets me to a fresh beginning, and then the whole sequence
starts again as I repeat (re/un)deploying.
--
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: [Vote] Geronimo Eclipse Plugin v1.1.0
Fixed. Re-vote.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly)On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin
RE: Geronimo Eclipse Plugin FAQ
Hi Sachin, It is great that you put out the FAQ - we definitely need that! One question I'd like to get answered is: There are two checkboxes in the AG server configuration panel: Enable in-place deployment Run standalone modules directly from workspace. What's the difference between them? I understand the in-place deployment, same as the deploy.bat --inPlace option. I figure that if a user chooses in-Place deployment, the project would stay where they are and won't be deployed to the repo thus the user will run it directly from the eclipse workspace. Doesn't the second checkbox mean the same? Thanks, Lin -Original Message- From: Sachin Patel [mailto:[EMAIL PROTECTED] On Behalf Of Sachin Patel Sent: Sunday, July 09, 2006 8:37 PM To: dev@geronimo.apache.org Subject: Geronimo Eclipse Plugin FAQ I've started a eclipse plugin FAQ at http://cwiki.apache.org/confluence/display/GMOxDOC11/Geronimo+Eclipse +Plugin+FAQ
RE: [Vote] Geronimo Eclipse Plugin v1.1.0
I started to have problems in deploying my second application which I had it running with v1.0's plugin. It is a simple ClassViewer application that has a jsp and a servlet. The jsp calls the servlet when user clicks on the submit button to get the class description. Upon deployment of the application, I got the following CNP exception when the two checkboxes (Enable in-place deployment Run standalone modules directly from workspace) are checked: Caused by: java.lang.ClassNotFoundException: samples.cviewer.ClassViewerServlet in classloader samples/cviewer/1.1/war at java.lang.Throwable.init(Throwable.java:57) at java.lang.Throwable.init(Throwable.java:81) at java.lang.ClassNotFoundException.init(ClassNotFoundException.java:80) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiPare ntClassLoader.java:249) at java.lang.ClassLoader.loadClass(ClassLoader.java:561) at org.apache.geronimo.tomcat.GeronimoStandardContext.addChild(GeronimoStandard Context.java:234) ... 84 more I have gotten this error before (https://bugs.eclipse.org/bugs/show_bug.cgi?id=123803) in v1.0 but I don't think this is the same prob as I had before this time. I noticed that in my project's .classpath file, I have: classpathentry path=build/classes kind=output/ However, I don't have the servlet class in that directory. I tried to update it to the path where the servlet class is located (ImportedClasses /samples/cviewer) but still the same error. I'll look into more of this but I thought I'd let everyone know since it is voting time of the plugin. P.S. Later on I discovered that the sample works fine when I don't have the two checkboxes checked. I can see the servlet and jsp in the good structure in the repo. Lin -Original Message- From: Sachin Patel [mailto:[EMAIL PROTECTED] On Behalf Of Sachin Patel Sent: Sunday, July 09, 2006 4:25 PM To: dev@geronimo.apache.org Subject: [Vote] Geronimo Eclipse Plugin v1.1.0 The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours. http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-deployable-RC4.zip http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse- plugin-1.1-updatesite-RC4.zip Here is my +1. - sachin
Re: [Vote] Geronimo Eclipse Plugin v1.1.0
Sachin,At a minimum, you need to add:OpenEJB, MX4J, and XStream to the root LICENSE fileMX4J, and XMLBeans to the root NOTICE fileDid you investigate Hessian licensing? I didn't find any licensing info (at first). So, took a look at the source. The first source file I looked at contained the following:/* * Copyright (c) 1998-2004 Caucho Technology -- all rights reserved * * This file is part of Resin(R) Open Source * * Each copy or derived work must preserve the copyright notice and this * notice unmodified. * * Resin Open Source is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * Resin Open Source is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, or any warranty * of NON-INFRINGEMENT. See the GNU General Public License for more * details. * * You should have received a copy of the GNU General Public License * along with Resin Open Source; if not, write to the * Free SoftwareFoundation, Inc. * 59 Temple Place, Suite 330 * Boston, MA 02111-1307 USA * * @author Scott Ferguson */I now see the following statement on their wiki:"Caucho Technology has released this Hessian implementation under an open source license (the Apache license). Anyone may freely download, use, and redistribute the Hessian implementation."But that's the strongest source of licensing info, that I've found...--kevanOn Jul 10, 2006, at 10:42 PM, Sachin Patel wrote:Fixed. Re-vote.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC5.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC5.zip (still uploading available shortly)On Jul 10, 2006, at 8:21 PM, Kevan Miller wrote:Sachin,I'm afraid I don't see either a NOTICE or LICENSE files in the plugin zip file, itself, nor any of the embedded jar files. They all must contain both LICENSE and NOTICE files. Afraid this is a hard requirement. And you'll need to create new binaries... See http://www.apache.org/dev/release.html#what-must-every-release-contain for more information.We should be able to reuse some of the license information we generated for G 1.1. I'm happy to help with that. I'm not sure how we're putting the NOTICE and LICENSE info in each of the jar files. Shouldn't be too hard to figure out, but perhaps someone can chime in...--kevanOn Jul 9, 2006, at 4:24 PM, Sachin Patel wrote: The following distributions of the Geronimo Eclipse plugin are ready to be voted on for final release. Since binding votes are needed, each PMC member if possible, please cast your vote within 72 hours.http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-deployable-RC4.ziphttp://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.1-updatesite-RC4.zipHere is my +1.- sachin -sachin
[jira] Commented: (GERONIMO-2175) etc/explicit_versions.properties should be automatically generated (or made unecessary)
[ http://issues.apache.org/jira/browse/GERONIMO-2175?page=comments#action_12420203 ] Jason Dillon commented on GERONIMO-2175: Forgot to add the issue id in the comment. Fix was added in rev #420691 to possibly fix this. Pending resolution that this actually works. etc/explicit_versions.properties should be automatically generated (or made unecessary) --- Key: GERONIMO-2175 URL: http://issues.apache.org/jira/browse/GERONIMO-2175 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem Reporter: Kevan Miller Assignee: Jason Dillon Fix For: 1.2 explicit_versions.properties is an error prone and fragile mechanism used to insure the appropriate artifacts are loaded during a Geronimo build. It should be possible to automatically generate the file (or dynamically calculate as resources are loaded). -- 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-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=comments#action_12420204 ] Bruce Snyder commented on GERONIMO-1786: This means that the console page for the JMS Server contains links to functionality that cannot be fulfilled in Geronimo 1.1. JMS Listeners for protocols activeio, peer and openwire fail to start - Key: GERONIMO-1786 URL: http://issues.apache.org/jira/browse/GERONIMO-1786 Project: Geronimo Type: Bug Security: public(Regular issues) Components: ActiveMQ, console Versions: 1.0, 1.2, 1.1 Environment: Geronimo 1.0.0 Reporter: Donald Woods Fix For: 1.2 Even though addition of JMS Listeners for activeio, peer and openwire protocols is successful, the listeners fail to start with the following exceptions. activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found openwire --- javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory Stack trace of the same. 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found 194: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo rtServerChannelFactory.java:60) 195: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact ory.java:49) 196: at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) 197: at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) 198: at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) 199: at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) 200: at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) 201: at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled Code)) 202: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) 203: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) 204: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) 205: at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) 206: at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) 207: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java :365) 208: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) 209: at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive(generated) 210: at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) 211: at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 216: at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 217: at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 218: at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) 219: at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) 220: at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) 221: at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) 222: at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) 223: at
[jira] Created: (AMQ-808) The DestinationMap removeAll is removing too many nodes out of the map.
The DestinationMap removeAll is removing too many nodes out of the map.
---
Key: AMQ-808
URL: https://issues.apache.org/activemq/browse/AMQ-808
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Hiram Chirino
Assigned to: Hiram Chirino
Fix For: 4.1, 4.0.2
This was initially noticed because at times avisoryies stopped working for some
cases. This is due to the way the Region uses a DestinationMap to find all the
destinations that match a subscription.
A unit test that fails looks like:
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-808) The DestinationMap removeAll is removing too many nodes out of the map.
[ https://issues.apache.org/activemq/browse/AMQ-808?page=all ]
Hiram Chirino updated AMQ-808:
--
Description:
This was initially noticed because at times avisoryies stopped working for some
cases. This is due to the way the Region uses a DestinationMap to find all the
destinations that match a subscription.
A unit test that fails looks like:
{code:java}
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
{code}
was:
This was initially noticed because at times avisoryies stopped working for some
cases. This is due to the way the Region uses a DestinationMap to find all the
destinations that match a subscription.
A unit test that fails looks like:
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
The DestinationMap removeAll is removing too many nodes out of the map.
---
Key: AMQ-808
URL: https://issues.apache.org/activemq/browse/AMQ-808
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
This was initially noticed because at times avisoryies stopped working for
some cases. This is due to the way the Region uses a DestinationMap to find
all the destinations that match a subscription.
A unit test that fails looks like:
{code:java}
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-808) The DestinationMap removeAll is removing too many nodes out of the map.
[ https://issues.apache.org/activemq/browse/AMQ-808?page=all ]
Hiram Chirino resolved AMQ-808:
---
Resolution: Fixed
fixed.
The DestinationMap removeAll is removing too many nodes out of the map.
---
Key: AMQ-808
URL: https://issues.apache.org/activemq/browse/AMQ-808
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 4.1, 4.0.2
This was initially noticed because at times avisoryies stopped working for
some cases. This is due to the way the Region uses a DestinationMap to find
all the destinations that match a subscription.
A unit test that fails looks like:
{code:java}
public void testAddAndRemove() throws Exception {
put(FOO.A, v1);
assertMapValue(FOO., v1);
put(FOO.B, v2);
assertMapValue(FOO., v1, v2);
Set set = map.removeAll(createDestination(FOO.A));
assertMapValue(FOO., v2); // This Fails. nothing is left in FOO.
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (AMQ-809) Make it easier to just enable the command trancing of the TransportLogger.
Make it easier to just enable the command trancing of the TransportLogger. -- Key: AMQ-809 URL: https://issues.apache.org/activemq/browse/AMQ-809 Project: ActiveMQ Type: Improvement Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1, 4.0.2 The log4j category for trace logging of message currently org.apache.activemq.transport.TransportLogger:n this makes it hard to enable the debug logging of just the trace messages since org.apache.activemq.transport is too broad of a category and TransportLogger:n is a variable category name. We should make it org.apache.activemq.transport.TransportLogger.Connection:n so that it's easier to just enable the logging for this one component. Also log usage of the other request methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[xbean] Colossus server
Over the last week I have been working with the xbean code trying to figure out the best way to build up a full server. After a few false starts, I've decided that the best approach is to attempt to build up a large server using just Spring with no modularity (and no kernel) and then once it is working it should be easy to experiment with different ways to divide up the server. You can find my experimental branch here https://svn.apache.org/repos/ asf/geronimo/xbean/branches/colossus and assuming I didn't mess anything up you should just need to do the following to test the server: $ mvn install $ xbean-colossus/target/xbean-colossus-2.5-colossus/xbean- colossus-2.5-colossus/bin/xbean.sh I don't do windows, so if you are on that you'll have to use a java - jar execution (or double click on the bootstrap jar): $ java -jar xbean-colossus/target/xbean-colossus-2.5-colossus/xbean- colossus-2.5-colossus/bin/xbean-bootstrap-2.5-colossus.jar Currently there is only one service created, but the idea is to build up the services created using OpenEJB 3, AMQ 4, Jetty 6 and/or Tomcat (haven't decided yet), Jencks and some Geronimo services. I'm not sure how far down this path I'll get before I get bored and start working on some modularity code, but that the current plan. The one new thing I have in the colossus branch is a bootstrap system which can cleanly launch a vm without needing any command line class path or manifest class path entries. Instead it uses a some properties files, ant style globing and some finder code to build the initial class loader and locate the real main class. It still needs work but I have a few pages of notes on it I'll post to the wiki tomorrow or the next day. -dain
Re: Change in RTC process to base an approval on 3 committers
Matt Did you get any feedback on this?On 7/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I understand the point of confusion about the binding votes and PMC membership.It was pointed out that we have a disparity in PMC / committer populations.I think it would bebeneficial to the project to adjust the process such that 3 +1's from a committer (PMC or not) is acceptable.Perhaps the PMC membership could vote on and allow this process change for Geronimo so that we canmove the community forward.Overall I see the community working to work with RTC.It has significantly improved communication and awareness which is what I understood the goal to be.Thanks for considering this change.-- Regards,HiramBlog: http://hiramchirino.com
