[jira] Commented: (AMQ-735) Possible 4.0 consumer client memory leak?
[ https://issues.apache.org/activemq/browse/AMQ-735?page=comments#action_36255 ] james strachan commented on AMQ-735: I'm not sure I understand those pictures. Is the number after the types the number of instances created? If so from those pictures it seems like you've got tons of JMS Session objects (124596 of them!). Why so many JMS sessions? Those are objects your code creates and manages; so I suspect its your code not closing them down and letting them garbage collect? Whic one of the 2 programs is it you ran the profiler on? Possible 4.0 consumer client memory leak? - Key: AMQ-735 URL: https://issues.apache.org/activemq/browse/AMQ-735 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: windows xp pro, jdk 1.5, AMQ 4.0 (incubator) Reporter: Karthik Sethuraman Priority: Critical Attachments: activemq_735.zip, jmsmon.zip On running the attached test programs (one producer on a topic, one consumer on a topic), the consumer eventually encounters OutOfMemoryError after receiving around 64 MB of messages). Default JVM heap size is used (64 MB). The problem does not happen with RC2 build. The test programs allows specification of message payloads of different sizes and different message rates, as well number of producer/consumer threads/instances., topics and topic connection factories, via user environment variables. http://www.nabble.com/4.0+Consumer+OutOfMemoryError+bug--t1707655.html#a4660556 -- 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-735) Possible 4.0 consumer client memory leak?
[ https://issues.apache.org/activemq/browse/AMQ-735?page=comments#action_36256 ] james strachan commented on AMQ-735: BTW if those numbers are not the number of instances in the JVM - which could be true (they might be hashcodes rather than instance counts) - then the pictures are not helpful - we need to know how many instances of each type there are - i.e. to find a memory leak we need to know what objects are using up all the RAM Possible 4.0 consumer client memory leak? - Key: AMQ-735 URL: https://issues.apache.org/activemq/browse/AMQ-735 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: windows xp pro, jdk 1.5, AMQ 4.0 (incubator) Reporter: Karthik Sethuraman Priority: Critical Attachments: activemq_735.zip, jmsmon.zip On running the attached test programs (one producer on a topic, one consumer on a topic), the consumer eventually encounters OutOfMemoryError after receiving around 64 MB of messages). Default JVM heap size is used (64 MB). The problem does not happen with RC2 build. The test programs allows specification of message payloads of different sizes and different message rates, as well number of producer/consumer threads/instances., topics and topic connection factories, via user environment variables. http://www.nabble.com/4.0+Consumer+OutOfMemoryError+bug--t1707655.html#a4660556 -- 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-732) Infinite recovery loop.
[
https://issues.apache.org/activemq/browse/AMQ-732?page=comments#action_36258 ]
james strachan commented on AMQ-732:
BTW you should be able to attach a zipped up tarball of the activemq-data
directory for a broker which can't recover and we can get it working
Infinite recovery loop.
---
Key: AMQ-732
URL: https://issues.apache.org/activemq/browse/AMQ-732
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: Linux RHEL 3
Reporter: Maxim Fateev
Assignee: Hiram Chirino
The simplest way to reproduce the problem:
1. Remove storage directory.
2. Start broker using the following code:
public static void main(String[] args) throws Exception {
BrokerService broker = new BrokerService();
broker.setPersistent(true);
DefaultPersistenceAdapterFactory pFactory = new
DefaultPersistenceAdapterFactory();
pFactory.setJournalLogFiles(1);
pFactory.setJournalLogFileSize(2048);
broker.setPersistenceFactory(pFactory);
broker.setUseJmx(false);
broker.addConnector(tcp://localhost:61616);
broker.start();
Thread.sleep(1l);
}
3. Shutdown the broker.
4. Start broker.
It enters infinite loop
[ main] BrokerService INFO
ActiveMQ null JMS Message Broker (localhost) is starting
[ main] BrokerService INFO For
help or more information please see: http://incubator.apache.org/activemq/
[ main] JDBCPersistenceAdapter INFO
Database driver recognized: [apache_derby_embedded_jdbc_driver]
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER
VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT,
MSG BLOB, PRIMARY KEY ( ID ) )
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250),
MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB,
PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in
Schema 'APP'. SQLState: X0Y32 Vendor code: 2
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS
(MSGID_PROD,MSGID_SEQ)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL,
CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR
VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID,
SUB_NAME))
[ main] DefaultJDBCAdapter DEBUG Could
not create JDBC tables; The message table already existed. Failure was:
CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID
VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250),
LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME))
Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState:
X0Y32 Vendor code: 2
[ main] JDBCPersistenceAdapter DEBUG
Cleaning up old messages.
[ main] DefaultJDBCAdapter DEBUG
Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION0 AND
EXPIRATION?) OR ID = ( SELECT min(ACTIVEMQ_ACKS.LAST_ACKED_ID) FROM
ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
[ main] DefaultJDBCAdapter DEBUG Deleted
0 old message(s).
[ main] JDBCPersistenceAdapter DEBUG Cleanup
done.
[ main] JournalPersistenceAdapter INFO Journal
Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at:
/workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
[ main] JournalPersistenceAdapter DEBUG TRACE
Entry: RECOVERED
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=53
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation offset=97
[Journal Writer] LogFileManager DEBUG
getNextDataRecordLocation overflowing into next logFile=0
[
[jira] Resolved: (AMQ-741) Remove the onSendPrepareMessageBody property on the ActiveMQ Connection and ConnectionFactory
[ https://issues.apache.org/activemq/browse/AMQ-741?page=all ] Hiram Chirino resolved AMQ-741: --- Resolution: Fixed commited to both branches. Remove the onSendPrepareMessageBody property on the ActiveMQ Connection and ConnectionFactory - Key: AMQ-741 URL: https://issues.apache.org/activemq/browse/AMQ-741 Project: ActiveMQ Type: Improvement Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 They are not used for anyting. Could confuse users to see that that property is available. -- 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: (SM-279) provide a way to configure ws-addressing engagement on a per endpoint basis
[ https://issues.apache.org/activemq/browse/SM-279?page=all ] Guillaume Nodet resolved SM-279: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Thu Jun 8 05:10:23 2006 New Revision: 412730 URL: http://svn.apache.org/viewvc?rev=412730view=rev Log: SM-447, SM-279: support for ws-sec inbound authentication using UsernamePassword token Added: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/addressing/ incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/addressing/AddressingHandler.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/ incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/BaseSecurityCallbackHandler.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/security/WSSecurityHandler.java incubator/servicemix/trunk/servicemix-soap/src/test/java/org/apache/servicemix/soap/handlers/ incubator/servicemix/trunk/servicemix-soap/src/test/java/org/apache/servicemix/soap/handlers/WSSecurityHandlerTest.java incubator/servicemix/trunk/servicemix-soap/src/test/resources/org/apache/servicemix/soap/handlers/ incubator/servicemix/trunk/servicemix-soap/src/test/resources/org/apache/servicemix/soap/handlers/sample-wsse-request.xml Removed: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/AddressingHandler.java Modified: incubator/servicemix/trunk/pom.xml incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpEndpoint.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ConsumerProcessor.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ProviderProcessor.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpWsdlTest.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/security/HttpSecurityTest.java incubator/servicemix/trunk/servicemix-http/src/test/resources/org/apache/servicemix/http/security/secure.xml incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/JmsComponent.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingConsumerProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingProviderProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/standard/StandardConsumerProcessor.java incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/standard/StandardProviderProcessor.java incubator/servicemix/trunk/servicemix-soap/pom.xml incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/Handler.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/SoapEndpoint.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/SoapHelper.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/AbstractHandler.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/marshalers/SoapWriter.java provide a way to configure ws-addressing engagement on a per endpoint basis --- Key: SM-279 URL: https://issues.apache.org/activemq/browse/SM-279 Project: ServiceMix Type: Improvement Components: servicemix-http Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M2 -- 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: 1.1 Candidate releases available
Aaron, I haven't found any JIRA or changes that mentions this problem explicitly. Is this still to be fixed? John Guillaume Nodet wrote: In addition i have the following errors in the console 13:14:46,546 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless this is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) and the plugins portlet does not display hyperlinks, so plugins can not be installed... I guess I should raise jiras for these problems. Cheers, Guillaume Nodet Guillaume Nodet wrote: Shouldn't they include at least the ASF license, a NOTICE file and maybe third party licenses ? Cheers, Guillaume Nodet Jacek Laskowski wrote: On 6/7/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Where can I find this RC ? Pick your favorite one at http://people.apache.org/~hogstrom/20060607/ Guillaume Nodet Jacek
[jira] Closed: (GERONIMO-1434) Allow GBeans to be bound into a component's java:comp/env namespace
[ http://issues.apache.org/jira/browse/GERONIMO-1434?page=all ] David Jencks closed GERONIMO-1434: -- Fix Version: 1.2 Resolution: Fixed Assign To: David Jencks (was: Aaron Mulder) Kevan applied the openejb patch for me in openejb rev r2655 Allow GBeans to be bound into a component's java:comp/env namespace --- Key: GERONIMO-1434 URL: http://issues.apache.org/jira/browse/GERONIMO-1434 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel, naming Versions: 1.0 Reporter: Aaron Mulder Assignee: David Jencks Priority: Critical Fix For: 1.1, 1.2 Attachments: 1434_openejb.diff, 1434_sample.diff Would be nice if proxies to GBeans could be placed in a component's private JNDI space. The 1.0 release includes a gbean-ref element in the jndiEnvironmentRefsGroup that appears to hold the required settings. David J notes that some code is present in the class is GBeanProxyReference and there's some code that doesn't work in ComponentContextBuilder -- we just need to add some stuff to ENCConfigBuilder for these and bind them directly. -- 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: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con
On Jun 7, 2006, at 9:23 PM, Aaron Mulder wrote: On 6/7/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Its been a long day and I've caught up on the JIRAs you created. I think I'm ok with your fixes given the JIRA entries I read through. OK I'm OK with these bug fixes too. I think the PluginRepositoryExporter.java should not be hardcoding values in it. Can you look at moving this to a property file in the future? Geronimo has way too many configuration items hard coded in the server (or requires a server rebuild to make changes). I would prefer not to see any other changes in this area for 1.1. Yes, it was just going to be a bigger change to put in a properties file and get it to read from that. Are there any other bugs that you are aware of that we need to be tracking? http://issues.apache.org/jira/browse/GERONIMO-1434 There's an OpenEJB patch listed as pending. I think this was the one that caused all the problems when the repo was down and has now been applied, but I'm not sure. David J, can you confirm? Kevan applied the patch for me, I've closed this one. http://issues.apache.org/jira/browse/GERONIMO-1451 There's an ActiveMQ patch that hasn't been applied because it needs to be done against the *-g1_1 module not the 1.0 module. Perhaps not tremendously important, but if it fixes the problem it would be nice to put into ActiveMQ 3.2.4 instead of immediately going to a new ActiveMQ SNAPSHOT. http://issues.apache.org/jira/browse/GERONIMO-1884 Should change the terminology on the plugin screen in the console to be consistent (there's a patch for this in http://issues.apache.org/jira/browse/GERONIMO-1938), and perhaps add a few words about removing plugins. I don't think we need to do anything else for this issue. http://issues.apache.org/jira/browse/GERONIMO-1791 http://issues.apache.org/jira/browse/GERONIMO-1817 Trivial patches to avoid NPEs in the LDAP realm. http://issues.apache.org/jira/browse/GERONIMO-1781 Reportedly, the repository blows up on a module like foo-1.jar NO URL There's no Jira for this, but we should remove the old keystore portlet from the console for the 1.1 release (but leave it there for 1.1.1, until all the functionality is replaced). http://issues.apache.org/jira/browse/GERONIMO-1887 The console has 1.7 MB of (potentially) unnecessary JARs. http://issues.apache.org/jira/browse/GERONIMO-2083 Should we upgrade to the current HOWL? no, we'd need an upload to ibiblio for this. I got a nice m2 build for howl working and created an m2 compliant upload request, but maven is not accepting them until it gets a new piece of hardware set up. thanks for looking through all of these! david jencks http://issues.apache.org/jira/browse/GERONIMO-1922 Would be nice to force a plugin export to fail if you've used the SharedLib dependency. I thought we had done this, but I don't see the code. So for now it's a training issue. I can look at most of these before noon on 6/8 if you are OK with that. Anything that you don't want to see go in? Also, if you could take a whack at the JIRAs you moved into 1.1 and move them out that would be really helpful. Hmm... thought you were going to do that. :) Thanks, Aaron Matt Hogstrom wrote: Aaron, We are in the process of releasing 1.1. In the release note I requested that people please let me know before commiting changes to 1.1. The number of changes you've made below are significant changes. Can you please revert this change as well as 412621 and hold them for 1.1 please. For specific issues with 1.1 please post a note about the change so we can discuss the content of hte change before applying it to the build. If you would like to bring these issues forward for discussion that would be fine but I'm inclinced to get 1.1 out and have these in 1.1.1. Thanks. Matt [EMAIL PROTECTED] wrote: Author: ammulder Date: Wed Jun 7 15:56:52 2006 New Revision: 412604 URL: http://svn.apache.org/viewvc?rev=412604view=rev Log: Fixes to config.xml, plugins, plugin repo list, plugin installer - Plugin exporter can map current version to a set of supported versions to help with problems caused by plugins not running on new test builds of Geronimo - config.xml has placeholder for user-added plugin repositories GERONIMO-2076 - Removed Apache directory content from config.xml for 4 main assemblies - Added directory config.xml content to directory plugin metadata - Plugin installer writes correct elements for config.xml content GERONIMO-2088 - Plugin exporter includes file copy and config.xml content GERONIMO-2089 - Plugin repository list points to a version-specific file (so 1.1 and 1.2 can point to different repositories) - Trim entries in plugin repository list, just in case - Remove some extraneous logging during console plugin download Modified:
Re: [RTC] move geronimo/site to a trunk branch
+1 John Aaron Mulder wrote: Currently, the code checked in to the geronimo/site repo does not (and should not) correspond to our live web site. My understanding is that Hernan has a newer revision that he has not checked in (but it can be seen at http://people.apache.org/~hcunico/newsite/) I want to update the news and events on the current site to move the expired events, add some 1.1 information, etc. I want to do that to the site as it exists on geronimo.apache.org site today, until we're in agreement about what it should look like next. Currently I can't do that unless I edit the HTML on minotaur directly and lose any Subversion history (I believe the content on minotaur is as of just-before-rev-411192). I propose we: - move geronimo/site to geronimo/site/branches/may2006 - copy geronimo/site revision 411191 to geronimo/site/trunk - update the site sync script on minotaur to pull from geronimo/site/trunk Then Hernan can check his pending changes into the new branch and I can check my news and event updates into both the branch and trunk and sync minotaur from trunk. When we're all agreed that the branch content is what we want, we can either merge it to trunk or move trunk away and move the branch to be the new trunk. I'm taking the slightly unusual step of not attaching a patch since I think the description above is much more meaningful than the equivalent tremendously large patch. Here's my +1, can I get 3 more? Thanks, Aaron
Re: cwiki.apache.org [longish]
Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo) Apache Geronimo Project Management (GMOxPMGT) Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10) Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10) Cayenne Documentation (cayenne) Demonstration Space (ds) Test Space (test) Cheers, Erin
[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12415290 ] David Jencks commented on GERONIMO-2071: rev 412684 added more configs poms and modified dependencies so modules and configs build. In particular list all configs in the dependency-management section of the root pom. configs builds for me although I don't think it includes all the modules. rev 412688 add 2 missing src geronimo-dependency.xml files as pointed out by anita. This leaves only the openejb ones to add. rev 412690 go back to released xmlbeans plugin. Change was accidentally committed, I am maintaining the build against the fixed plugin. I think this completes the existing work in patches except for openejb. I plan to apply that when it is clear which branch to apply to. This jira and in particular its patch list has gotten very long, I suggest we start a new one for further patches and comments. Move Geronimo build to M2 (new 1.2 trunk) - Key: GERONIMO-2071 URL: http://issues.apache.org/jira/browse/GERONIMO-2071 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: buildsystem Versions: 1.2 Reporter: Prasad Kashyap Assignee: Jacek Laskowski Fix For: 1.2 Attachments: applications.patch, applications.patch.zip, configs.log, configs.log, configs.patch, configs.patch, deploy-tool.patch, deploy-tool.patch, deployment-plugin.patch, deployment-plugin.patch, geronimo-deployment-plugin-RTC-VOTE.2.patch, geronimo-deployment-plugin-RTC-VOTE.patch, geronimo.patch, geronimo.patch, geronimo.patch, m2-plugins.patch, modules.patch, modules.patch, mvn.log, openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, openejb.patch, openejb.patch, pom.xml, pom.xml A lot of work for moving Geronimo build to M2 was done under G-851. (http://issues.apache.org/jira/browse/GERONIMO-851) The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and hence the migration work needs to be done here again. This JIRA will seek to consolidate the work that was done under G-851 and all it's subtasks. The patch(es) here will be submitted under the RTC guidelines. Future patches for migration will have to be applied on top of this one. This patch will contain the parent pom, modules, openejb, configs, m2-plugins Any issues/concerns about migrating some pieces are well documented in G-851 with links to dev list archives. -- 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: [RTC] move geronimo/site to a trunk branch
+1 thanks david jencks On Jun 7, 2006, at 5:38 PM, Aaron Mulder wrote: Currently, the code checked in to the geronimo/site repo does not (and should not) correspond to our live web site. My understanding is that Hernan has a newer revision that he has not checked in (but it can be seen at http://people.apache.org/~hcunico/newsite/) I want to update the news and events on the current site to move the expired events, add some 1.1 information, etc. I want to do that to the site as it exists on geronimo.apache.org site today, until we're in agreement about what it should look like next. Currently I can't do that unless I edit the HTML on minotaur directly and lose any Subversion history (I believe the content on minotaur is as of just-before-rev-411192). I propose we: - move geronimo/site to geronimo/site/branches/may2006 - copy geronimo/site revision 411191 to geronimo/site/trunk - update the site sync script on minotaur to pull from geronimo/ site/trunk Then Hernan can check his pending changes into the new branch and I can check my news and event updates into both the branch and trunk and sync minotaur from trunk. When we're all agreed that the branch content is what we want, we can either merge it to trunk or move trunk away and move the branch to be the new trunk. I'm taking the slightly unusual step of not attaching a patch since I think the description above is much more meaningful than the equivalent tremendously large patch. Here's my +1, can I get 3 more? Thanks, Aaron
[jira] Resolved: (GERONIMO-2091) MimeBodyPart.getFileName() not retrieving name from the Content-Disposition header
[ http://issues.apache.org/jira/browse/GERONIMO-2091?page=all ] Rick McGuire resolved GERONIMO-2091: Resolution: Fixed Committed revision 412720. MimeBodyPart.getFileName() not retrieving name from the Content-Disposition header -- Key: GERONIMO-2091 URL: http://issues.apache.org/jira/browse/GERONIMO-2091 Project: Geronimo Type: Bug Security: public(Regular issues) Components: mail Versions: 1.1 Reporter: Rick McGuire Assignee: Rick McGuire Priority: Minor Fix For: 1.1.1 The MimeBodyPart.getFileName() method is supposed to first check for a filename parameter on the Content-Disposition header, and if not found, fall back to looking for a name parameter on the Content-Type header. Because of an error retrieving the Content-Disposition header, the first test will always fail. -- 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: Plugin versioning problems
What I meant by 1.1.* was the Maven behavior of private builds like 1.1-1 being taken as newer than 1.1. Also, being able to use the behavior of 1.1-starting with any alpha is less than 1.1. Basically, I should be able to specify 1.1 in the plugin and have it work on 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1, then I'd argue that we broke something in 1.1.1, given it should only be a maintenance release and app/plan breaking changes should only go into 1.2. BTW - How can we add new Plugins to the geronimoplugins website? Are we going to setup a Geronimo subproject (like Daytrader) with the site framework checked into svn, along with any scripts needed to build the plugins? It seems convoluted to have samples and plugin builds in the main Geronimo tree, which are not shipped with the server or automatically pushed to geronimoplugins. Wouldn't it be easier to maintain if we moved all the samples out to /trunk/samples/modules and all the equivalent plugin configs to /trunk/samples/plugins? That way, the Samples and plugins can be built, published and enhanced separate from the server development -Donald Aaron Mulder wrote: On 6/7/06, Donald Woods [EMAIL PROTECTED] wrote: Why shouldn't the Plugin support be as robust as module dependencies and allow the user providing the plugin to decide if they can support geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to me and doesn't follow previous email threads about not deviating from Maven2 versioning behavior... But what you've said here is why shouldn't the plugin support be as robust as A and allow B where A != B. Module dependencies let you specify an exact version or no version. Plugin dependencies also let you specify an exact version or no version. Neither of these support 1.* or 1.1*. Just as with the Tomcat JSP/Servlet Examples, you could easily provide a Plugin which should work on all 1.x releases My preference it to opt-in supported version, not opt-out unsupported versions. So I'd like the plugin developer to try a plugin on a Geronimo version and if it works, list that version as supported. The alternative will most likely lead to Geronimo being willing to install a plugin but the plugin not working. If we get fancier version dependencies we can consider things like 1.1.* but I'm not sure I like that. I'm willing to be convinced, but I'd want to hear from more plugin developers/maintainers. Thanks, Aaron smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Rick,
If you're updating javamail, you need to update the version number
for the javamail spec.
--kevan
On Jun 7, 2006, at 11:21 AM, [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Wed Jun 7 08:21:46 2006
New Revision: 412426
URL: http://svn.apache.org/viewvc?rev=412426view=rev
Log:
GERONIMO-2087 MimeUtility.encodeWord()/encodeText() have some errors.
Modified:
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/
mail/internet/MimeUtility.java
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/
apache/geronimo/mail/util/Base64Encoder.java
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/
apache/geronimo/mail/util/RFC2231Encoder.java
geronimo/specs/trunk/geronimo-spec-javamail/src/test/java/javax/
mail/internet/MimeUtilityTest.java
Modified: geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/
javax/mail/internet/MimeUtility.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-javamail/src/main/java/javax/mail/internet/MimeUtility.java?
rev=412426r1=412425r2=412426view=diff
==
--- geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/
mail/internet/MimeUtility.java (original)
+++ geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/
mail/internet/MimeUtility.java Wed Jun 7 08:21:46 2006
@@ -554,7 +554,7 @@
if (encoding.equalsIgnoreCase(B)) {
encoder = base64;
}
-else if (encoding.equalsIgnoreCase(G)) {
+else if (encoding.equalsIgnoreCase(Q)) {
encoder = quoted-printable;
}
else {
Modified: geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/
org/apache/geronimo/mail/util/Base64Encoder.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-javamail/src/main/java/org/apache/geronimo/mail/util/
Base64Encoder.java?rev=412426r1=412425r2=412426view=diff
==
--- geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/
apache/geronimo/mail/util/Base64Encoder.java (original)
+++ geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/
apache/geronimo/mail/util/Base64Encoder.java Wed Jun 7 08:21:46 2006
@@ -515,21 +515,22 @@
int readCount = in.read(inBuffer);
// did we get a full triplet? that's an easy encoding.
if (readCount == 3) {
-byte a1 = (byte)(inBuffer[0] 0xff);
-byte a2 = (byte)(inBuffer[1] 0xff);
-byte a3 = (byte)(inBuffer[2] 0xff);
+int a1 = inBuffer[0] 0xff;
+int a2 = inBuffer[1] 0xff;
+int a3 = inBuffer[2] 0xff;
out.append((char)encodingTable[(a1 2) 0x3f]);
out.append((char)encodingTable[((a1 4) | (a2
4)) 0x3f]);
out.append((char)encodingTable[((a2 2) | (a3
6)) 0x3f]);
out.append((char)encodingTable[a3 0x3f]);
+
}
else if (readCount = 0) {
// eof condition, don'e entirely.
return;
}
else if (readCount == 1) {
-byte a1 = (byte)(inBuffer[0] 0xff);
+int a1 = inBuffer[0] 0xff;
out.append((char)encodingTable[(a1 2) 0x3f]);
out.append((char)encodingTable[(a1 4) 0x3f]);
out.append((char)padding);
@@ -537,8 +538,8 @@
return;
}
else if (readCount == 2) {
-byte a1 = (byte)(inBuffer[0] 0xff);
-byte a2 = (byte)(inBuffer[1] 0xff);
+int a1 = inBuffer[0] 0xff;
+int a2 = inBuffer[1] 0xff;
out.append((char)encodingTable[(a1 2) 0x3f]);
out.append((char)encodingTable[((a1 4) | (a2
4)) 0x3f]);
Modified: geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/
org/apache/geronimo/mail/util/RFC2231Encoder.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
spec-javamail/src/main/java/org/apache/geronimo/mail/util/
RFC2231Encoder.java?rev=412426r1=412425r2=412426view=diff
==
--- geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/
apache/geronimo/mail/util/RFC2231Encoder.java (original)
+++ geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/
apache/geronimo/mail/util/RFC2231Encoder.java Wed Jun 7 08:21:46 2006
@@ -52,7 +52,7 @@
(byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C',
(byte)'D', (byte)'E', (byte)'F'
};
-protected String DEFAULT_SPECIALS = *\\%;
+protected String DEFAULT_SPECIALS = *'%;
protected String specials = DEFAULT_SPECIALS;
/*
@@ -92,11 +92,11 @@
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Kevan Miller wrote:
Rick,
If you're updating javamail, you need to update the version number for
the javamail spec.
--kevan
I was sort of wondering if anything needed to be done there. I assume
it should be changed from 1.1 to 1.1.1?
Rick
On Jun 7, 2006, at 11:21 AM, [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Wed Jun 7 08:21:46 2006
New Revision: 412426
URL: http://svn.apache.org/viewvc?rev=412426view=rev
Log:
GERONIMO-2087 MimeUtility.encodeWord()/encodeText() have some errors.
Modified:
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail/internet/MimeUtility.java
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/Base64Encoder.java
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/RFC2231Encoder.java
geronimo/specs/trunk/geronimo-spec-javamail/src/test/java/javax/mail/internet/MimeUtilityTest.java
Modified:
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail/internet/MimeUtility.java
URL:
http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail/internet/MimeUtility.java?rev=412426r1=412425r2=412426view=diff
==
---
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail/internet/MimeUtility.java
(original)
+++
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/javax/mail/internet/MimeUtility.java
Wed Jun 7 08:21:46 2006
@@ -554,7 +554,7 @@
if (encoding.equalsIgnoreCase(B)) {
encoder = base64;
}
-else if (encoding.equalsIgnoreCase(G)) {
+else if (encoding.equalsIgnoreCase(Q)) {
encoder = quoted-printable;
}
else {
Modified:
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/Base64Encoder.java
URL:
http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/Base64Encoder.java?rev=412426r1=412425r2=412426view=diff
==
---
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/Base64Encoder.java
(original)
+++
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/Base64Encoder.java
Wed Jun 7 08:21:46 2006
@@ -515,21 +515,22 @@
int readCount = in.read(inBuffer);
// did we get a full triplet? that's an easy encoding.
if (readCount == 3) {
-byte a1 = (byte)(inBuffer[0] 0xff);
-byte a2 = (byte)(inBuffer[1] 0xff);
-byte a3 = (byte)(inBuffer[2] 0xff);
+int a1 = inBuffer[0] 0xff;
+int a2 = inBuffer[1] 0xff;
+int a3 = inBuffer[2] 0xff;
out.append((char)encodingTable[(a1 2) 0x3f]);
out.append((char)encodingTable[((a1 4) | (a2
4)) 0x3f]);
out.append((char)encodingTable[((a2 2) | (a3
6)) 0x3f]);
out.append((char)encodingTable[a3 0x3f]);
+
}
else if (readCount = 0) {
// eof condition, don'e entirely.
return;
}
else if (readCount == 1) {
-byte a1 = (byte)(inBuffer[0] 0xff);
+int a1 = inBuffer[0] 0xff;
out.append((char)encodingTable[(a1 2) 0x3f]);
out.append((char)encodingTable[(a1 4) 0x3f]);
out.append((char)padding);
@@ -537,8 +538,8 @@
return;
}
else if (readCount == 2) {
-byte a1 = (byte)(inBuffer[0] 0xff);
-byte a2 = (byte)(inBuffer[1] 0xff);
+int a1 = inBuffer[0] 0xff;
+int a2 = inBuffer[1] 0xff;
out.append((char)encodingTable[(a1 2) 0x3f]);
out.append((char)encodingTable[((a1 4) | (a2
4)) 0x3f]);
Modified:
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/RFC2231Encoder.java
URL:
http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/RFC2231Encoder.java?rev=412426r1=412425r2=412426view=diff
==
---
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/RFC2231Encoder.java
(original)
+++
geronimo/specs/trunk/geronimo-spec-javamail/src/main/java/org/apache/geronimo/mail/util/RFC2231Encoder.java
Wed Jun 7 08:21:46 2006
@@ -52,7 +52,7 @@
(byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C',
(byte)'D', (byte)'E', (byte)'F'
};
-protected String DEFAULT_SPECIALS =
Re: Plugin versioning problems
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote: What I meant by 1.1.* was the Maven behavior of private builds like 1.1-1 being taken as newer than 1.1. Also, being able to use the behavior of 1.1-starting with any alpha is less than 1.1. Basically, I should be able to specify 1.1 in the plugin and have it work on 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1, then I'd argue that we broke something in 1.1.1, given it should only be a maintenance release and app/plan breaking changes should only go into 1.2. +1 This approach is similar to how eclipse plugin versioning works. From http://www.eclipse.org/equinox/documents/plugin-versioning.html : How to specify plug-in requirements Plug-ins that require other plug-ins must qualify their requirements with a version range since the absence of a version range means that any version can satisfy the dependency. Given that all the changes between the version x.0.0 and the version x+1.0.0 excluded must be compatible (given the previous guidelines); the recommended range includes the minimal required version up-to but not including the next major release. IMHO geronimo should adopt eclipse's strategy for plugin versioning where possible since the two sets of base requirements are quite similar and eclipse is a few years ahead in this area. The document referenced above spells out their strategy in detail. Best wishes, Paul
[jira] Created: (GERONIMO-2092) Modules migration to M2
Modules migration to M2 --- Key: GERONIMO-2092 URL: http://issues.apache.org/jira/browse/GERONIMO-2092 Project: Geronimo Type: Improvement Security: public (Regular issues) Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Fix For: 1.2 The work done by Jacek Laskowski, Prasad Kashyap, Anita Kulshreshtha, reghuram rajakumar vasanthakumari, Anders Hessellund Jensen, and Andrew Steeley under GERONIMO-851 has been committed to the new trunk. This issue is to keep up with the changes to M1 build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2093) Console database pool always gets NPE on deploy
Console database pool always gets NPE on deploy --- Key: GERONIMO-2093 URL: http://issues.apache.org/jira/browse/GERONIMO-2093 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Environment: Release Candidate 6/7/2006 Reporter: Aaron Mulder Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.1 Reported on the user mailing list: 09:40:40,375 ERROR [DatabasePoolPortlet] Unable to save connection pool java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:876) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338) ... Looks like perhaps rarFile is null? -- 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: cwiki.apache.org [longish]
All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX)Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
Re: Plugin versioning problems
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote: BTW - How can we add new Plugins to the geronimoplugins website? Are we going to setup a Geronimo subproject (like Daytrader) with the site framework checked into svn, along with any scripts needed to build the plugins? It seems convoluted to have samples and plugin builds in the main Geronimo tree, which are not shipped with the server or automatically pushed to geronimoplugins. Wouldn't it be easier to maintain if we moved all the samples out to /trunk/samples/modules and all the equivalent plugin configs to /trunk/samples/plugins? That way, the Samples and plugins can be built, published and enhanced separate from the server development Currently, to get a plugin added to the web site, you can mail it to me. If you want to help out there, it would be great to have a script that read the plugin.xml files and emitted the various PHP files with all the plugin info! Currently it's a little more manual. :) We should definitely have a separate are in the SVN tree for the samples. There's no reason they should be tied to the Geronimo release schedule. We also need a non-Apache space where we can write the plugin wrappers for various interesting LGPL projects. Thanks, Aaron Aaron Mulder wrote: On 6/7/06, Donald Woods [EMAIL PROTECTED] wrote: Why shouldn't the Plugin support be as robust as module dependencies and allow the user providing the plugin to decide if they can support geronimo_version=*, 1.* or 1.1* ? Limiting the plugins to only support predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to me and doesn't follow previous email threads about not deviating from Maven2 versioning behavior... But what you've said here is why shouldn't the plugin support be as robust as A and allow B where A != B. Module dependencies let you specify an exact version or no version. Plugin dependencies also let you specify an exact version or no version. Neither of these support 1.* or 1.1*. Just as with the Tomcat JSP/Servlet Examples, you could easily provide a Plugin which should work on all 1.x releases My preference it to opt-in supported version, not opt-out unsupported versions. So I'd like the plugin developer to try a plugin on a Geronimo version and if it works, list that version as supported. The alternative will most likely lead to Geronimo being willing to install a plugin but the plugin not working. If we get fancier version dependencies we can consider things like 1.1.* but I'm not sure I like that. I'm willing to be convinced, but I'd want to hear from more plugin developers/maintainers. Thanks, Aaron
Re: Reorganizing javamai (revisited)
Looks good.
+1
thanks
david jencks
On Jun 7, 2006, at 5:46 AM, Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached
a consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that
the javamail code needed to be reorganized so that the javamail-
transport jar (which is currently part of the Geronimo build) is
separated from Geronimo and available with the geronimo-javamail-
spec jar. The consensus seemed to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the
tck signature tests. It looks like the best approach here would be
to rename the existing javamail spec module to geronimo-javamail-
spec-1.3 and introduce a new geronimo-javamail-spec-1.4 module
to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to geronimo-spec-
javamail-1.3. This already builds a geronimo-javamail_1.3.1_spec-$
{geronimoSpecsJavamailVersion} jar file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it
doesn't really fit). This will have two modules for the 1.3 and
1.4 versions of the providers, and will build geronimo-
javamail_1.3.1_provider-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two uber-
jars containing the specs and providers combined: geronimo-
javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and geronimo-
javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
[jira] Commented: (AMQ-735) Possible 4.0 consumer client memory leak?
[ https://issues.apache.org/activemq/browse/AMQ-735?page=comments#action_36261 ] Feng Wang commented on AMQ-735: --- I profiled DumpDumpJMSMsg.java because that is the one will throw out of memory error very quickly. I have attached the image for the instance count (instance.png). As you can see, byte array took the most of memory. But the counts of MessageDispatch, ActiveMQObjectMessage and MessageId keep increasing. In the previouslyploaded pictures, there was a loop in MessageDispatch reference graph. Usually it is a sign of memory leak. I guess that in Release 4 you start to use concurrent packge from emory universiy (but not RC2 build). CopyOnWriteArrayList is from concurrent package and take a look at middle.png. CopyOnWriteArrayList has a reference to object[1]. Since I am quite new to ActiveMQ and emory concurrent package (only 2 days), I am not sure where the problem is. Possible 4.0 consumer client memory leak? - Key: AMQ-735 URL: https://issues.apache.org/activemq/browse/AMQ-735 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: windows xp pro, jdk 1.5, AMQ 4.0 (incubator) Reporter: Karthik Sethuraman Priority: Critical Attachments: activemq_735.zip, jmsmon.zip On running the attached test programs (one producer on a topic, one consumer on a topic), the consumer eventually encounters OutOfMemoryError after receiving around 64 MB of messages). Default JVM heap size is used (64 MB). The problem does not happen with RC2 build. The test programs allows specification of message payloads of different sizes and different message rates, as well number of producer/consumer threads/instances., topics and topic connection factories, via user environment variables. http://www.nabble.com/4.0+Consumer+OutOfMemoryError+bug--t1707655.html#a4660556 -- 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-735) Possible 4.0 consumer client memory leak?
[ https://issues.apache.org/activemq/browse/AMQ-735?page=all ] Feng Wang updated AMQ-735: -- Attachment: instance.zip Possible 4.0 consumer client memory leak? - Key: AMQ-735 URL: https://issues.apache.org/activemq/browse/AMQ-735 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 Environment: windows xp pro, jdk 1.5, AMQ 4.0 (incubator) Reporter: Karthik Sethuraman Priority: Critical Attachments: activemq_735.zip, instance.zip, jmsmon.zip On running the attached test programs (one producer on a topic, one consumer on a topic), the consumer eventually encounters OutOfMemoryError after receiving around 64 MB of messages). Default JVM heap size is used (64 MB). The problem does not happen with RC2 build. The test programs allows specification of message payloads of different sizes and different message rates, as well number of producer/consumer threads/instances., topics and topic connection factories, via user environment variables. http://www.nabble.com/4.0+Consumer+OutOfMemoryError+bug--t1707655.html#a4660556 -- 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: Plugin versioning problems
OSGI does version ranges :) Aaron Mulder wrote: Perhaps I was unclear; I didn't mean to say this was a bad idea, only that our code doesn't currently support it. I expect version ranges are on the road map, but if you want to work on them, you're more than welcome to. :) I don't think this is a G 1.1.x discussion, since AFAIK it would require kernel changes. Thanks, Aaron On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote: On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote: What I meant by 1.1.* was the Maven behavior of private builds like 1.1-1 being taken as newer than 1.1. Also, being able to use the behavior of 1.1-starting with any alpha is less than 1.1. Basically, I should be able to specify 1.1 in the plugin and have it work on 1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1, then I'd argue that we broke something in 1.1.1, given it should only be a maintenance release and app/plan breaking changes should only go into 1.2. +1 This approach is similar to how eclipse plugin versioning works. From http://www.eclipse.org/equinox/documents/plugin-versioning.html : How to specify plug-in requirements Plug-ins that require other plug-ins must qualify their requirements with a version range since the absence of a version range means that any version can satisfy the dependency. Given that all the changes between the version x.0.0 and the version x+1.0.0 excluded must be compatible (given the previous guidelines); the recommended range includes the minimal required version up-to but not including the next major release. IMHO geronimo should adopt eclipse's strategy for plugin versioning where possible since the two sets of base requirements are quite similar and eclipse is a few years ahead in this area. The document referenced above spells out their strategy in detail. Best wishes, Paul
Re: [RTC] ActiveMQ GBean modules
So in terms the of the RTC process, is this RTC patch dead since it did not get the 3 +1's I kinda would have preferred to get some -1's instead of not getting any comments on the patch. Is it that there are not enough folks that are interested in the activemq integration aspects of geronimo? Regards, Hiram On 6/6/06, Hiram Chirino [EMAIL PROTECTED] wrote: m2 poms are included in the patch. But for some reason the current m2 build does not seem to let you run mvn from a submodule, some dependency variables do not get evaluated. weird. On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote: Howdy folks, Here's a patch that brings in the activemq gbean modules into geronimo. It's partly what was in activemq 4.x and integrated into geronimo 1.2-dead merged with the changes in the 3.x branch. It compiles at least and looks like a reasonable start. Once further integration work gets done we may need to tweak a little more. here's my +1 got get this committed. I guess I just need 3 more. I'd find it a lot easier to review, apply, and test this patch if you attached it to a jira entry. Is there any chance of you coming up with a pom.xml for the m2 build? thanks david jencks -- Regards, Hiram -- Regards, Hiram
RE: cwiki.apache.org [longish]
Hernan, Thank you alot for your great work on new G wiki! But oops, I was trying to copy my doc from the old location at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp Server2004 to the new location at: http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004 I copied the wiki content and got a successful preview, but when I press Save, I get a System Error: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters()V(Unknown Source) I see that my doc is rather big, but it worked fine on the old Confluence at opensource.atlassian.com. Is it some new feature of Confluence 2.1.5a? :) Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:30 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
Re: [RTC] ActiveMQ GBean modules
+1, looks fine to me. The sooner Geronimo moves to Apache ActiveMQ the better IMHO On 6/8/06, Hiram Chirino [EMAIL PROTECTED] wrote: So in terms the of the RTC process, is this RTC patch dead since it did not get the 3 +1's I kinda would have preferred to get some -1's instead of not getting any comments on the patch. Is it that there are not enough folks that are interested in the activemq integration aspects of geronimo? Regards, Hiram On 6/6/06, Hiram Chirino [EMAIL PROTECTED] wrote: m2 poms are included in the patch. But for some reason the current m2 build does not seem to let you run mvn from a submodule, some dependency variables do not get evaluated. weird. On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote: Howdy folks, Here's a patch that brings in the activemq gbean modules into geronimo. It's partly what was in activemq 4.x and integrated into geronimo 1.2-dead merged with the changes in the 3.x branch. It compiles at least and looks like a reasonable start. Once further integration work gets done we may need to tweak a little more. here's my +1 got get this committed. I guess I just need 3 more. I'd find it a lot easier to review, apply, and test this patch if you attached it to a jira entry. Is there any chance of you coming up with a pom.xml for the m2 build? thanks david jencks -- Regards, Hiram -- Regards, Hiram -- James --- http://radio.weblogs.com/0112098/
Re: [RTC] ActiveMQ GBean modules
The spirit of the patch is great. I haven't had the time to review it in detail. So I think that's a +0? Thanks, Aaron On 6/8/06, Hiram Chirino [EMAIL PROTECTED] wrote: So in terms the of the RTC process, is this RTC patch dead since it did not get the 3 +1's I kinda would have preferred to get some -1's instead of not getting any comments on the patch. Is it that there are not enough folks that are interested in the activemq integration aspects of geronimo? Regards, Hiram On 6/6/06, Hiram Chirino [EMAIL PROTECTED] wrote: m2 poms are included in the patch. But for some reason the current m2 build does not seem to let you run mvn from a submodule, some dependency variables do not get evaluated. weird. On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote: Howdy folks, Here's a patch that brings in the activemq gbean modules into geronimo. It's partly what was in activemq 4.x and integrated into geronimo 1.2-dead merged with the changes in the 3.x branch. It compiles at least and looks like a reasonable start. Once further integration work gets done we may need to tweak a little more. here's my +1 got get this committed. I guess I just need 3 more. I'd find it a lot easier to review, apply, and test this patch if you attached it to a jira entry. Is there any chance of you coming up with a pom.xml for the m2 build? thanks david jencks -- Regards, Hiram -- Regards, Hiram
Re: cwiki.apache.org [longish]
Hi Vasily, I just reported this issue to Atlassian (https://support.atlassian.com/browse/CSP-4236). Not sure why confluence is complaining, that page is not that big and I was able to migrate it from the other installation. It actually is failing to save any changes, there might be some confluence code in the doc that this new version is not too happy with. I'll review the page markup as soon as I have a min, if I can't find anything suspicious I could re-import it from an XML (a new one from the Atlassian install) while we still look for the final solution. Cheers! Hernan Zakharov, Vasily M wrote: Hernan, Thank you alot for your great work on new G wiki! But oops, I was trying to copy my doc from the old location at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp Server2004 to the new location at: http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004 I copied the wiki content and got a successful preview, but when I press Save, I get a System Error: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters()V(Unknown Source) I see that my doc is rather big, but it worked fine on the old Confluence at opensource.atlassian.com. Is it some new feature of Confluence 2.1.5a? :) Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:30 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
Re: Plugin versioning problems
I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x. I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
geronimo-version1.1/geronimo-version then it can be installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index:
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
===
---
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(revision
412744)
+++
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals()) {
throw new IllegalStateException(geronimo-version
should not be empty!);
}
-if(gerVersion.equals(version)) {
+if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Perhaps I was unclear; I didn't mean to say this was a bad idea, only
that our code doesn't currently support it. I expect version ranges
are on the road map, but if you want to work on them, you're more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
What I meant by 1.1.* was the Maven behavior of private builds like
1.1-1 being taken as newer than 1.1. Also, being able to use the
behavior of 1.1-starting with any alpha is less than 1.1. Basically,
I should be able to specify 1.1 in the plugin and have it work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
then I'd argue that we broke something in 1.1.1, given it should only be
a maintenance release and app/plan breaking changes should only go into 1.2.
+1 This approach is similar to how eclipse plugin versioning works.
From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their requirements
with a version range since the absence of a version range means that
any version can satisfy the dependency. Given that all the changes
between the version x.0.0 and the version x+1.0.0 excluded must be
compatible (given the previous guidelines); the recommended range
includes the minimal required version up-to but not including the next
major release.
IMHO geronimo should adopt eclipse's strategy for plugin versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The document
referenced above spells out their strategy in detail.
Best wishes,
Paul
Re: Plugin versioning problems
Well, if you're going to submit that patch, you need to include a
change in the annotation in the plugin schema along with it -- it
specifically says that field is an exact match.
I'm still not sure I'm on board with this, though. I don't feel like
we can say with confidence that a plugin that works in 1.1 will work
in all 1.1.x releases. Perhaps if we can articulate the rules for
what changes are acceptable for 1.1, and that implies that plugins
shouldn't break, then I'd feel more comfortable with this. We'd also
have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
the initial 1.1 release, you could.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x. I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
geronimo-version1.1/geronimo-version then it can be installed into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index:
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
===
---
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(revision
412744)
+++
modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
(working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals()) {
throw new IllegalStateException(geronimo-version
should not be empty!);
}
-if(gerVersion.equals(version)) {
+if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Perhaps I was unclear; I didn't mean to say this was a bad idea, only
that our code doesn't currently support it. I expect version ranges
are on the road map, but if you want to work on them, you're more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
What I meant by 1.1.* was the Maven behavior of private builds like
1.1-1 being taken as newer than 1.1. Also, being able to use the
behavior of 1.1-starting with any alpha is less than 1.1. Basically,
I should be able to specify 1.1 in the plugin and have it work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but doesn't on 1.1.1,
then I'd argue that we broke something in 1.1.1, given it should only be
a maintenance release and app/plan breaking changes should only go into
1.2.
+1 This approach is similar to how eclipse plugin versioning works.
From http://www.eclipse.org/equinox/documents/plugin-versioning.html :
How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their requirements
with a version range since the absence of a version range means that
any version can satisfy the dependency. Given that all the changes
between the version x.0.0 and the version x+1.0.0 excluded must be
compatible (given the previous guidelines); the recommended range
includes the minimal required version up-to but not including the next
major release.
IMHO geronimo should adopt eclipse's strategy for plugin versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The document
referenced above spells out their strategy in detail.
Best wishes,
Paul
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Rick McGuire wrote: Kevan Miller wrote: Rick, If you're updating javamail, you need to update the version number for the javamail spec. --kevan I was sort of wondering if anything needed to be done there. I assume it should be changed from 1.1 to 1.1.1? 1.2-SNAPSHOT please. Regards, Alan
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Alan D. Cabrera wrote: Rick McGuire wrote: Kevan Miller wrote: Rick, If you're updating javamail, you need to update the version number for the javamail spec. --kevan I was sort of wondering if anything needed to be done there. I assume it should be changed from 1.1 to 1.1.1? 1.2-SNAPSHOT please. I don't have a problem with changing it to 1.2-SNAPSHOT, but I'd like to understand the rationale behind the choice in case it comes up in the future. Rick Regards, Alan
Re: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con
I see some gold plating sneaking into a feature frozen branch. Since
I am not doing any heavy lifting, I'll leave my comment at that.
Regards,
Alan
Matt Hogstrom wrote:
Aaron,
Its been a long day and I've caught up on the JIRAs you created. I
think I'm ok with your fixes given the JIRA entries I read through.
I think the PluginRepositoryExporter.java should not be hardcoding
values in it. Can you look at moving this to a property file in the
future? Geronimo has way too many configuration items hard coded in
the server (or requires a server rebuild to make changes). I would
prefer not to see any other changes in this area for 1.1.
Are there any other bugs that you are aware of that we need to be
tracking?
Also, if you could take a whack at the JIRAs you moved into 1.1 and
move them out that would be really helpful.
Thanks
Matt
Matt Hogstrom wrote:
Aaron,
We are in the process of releasing 1.1. In the release note I
requested that people please let me know before commiting changes to
1.1. The number of changes you've made below are significant
changes. Can you please revert this change as well as 412621 and
hold them for 1.1 please.
For specific issues with 1.1 please post a note about the change so
we can discuss the content of hte change before applying it to the
build.
If you would like to bring these issues forward for discussion that
would be fine but I'm inclinced to get 1.1 out and have these in 1.1.1.
Thanks.
Matt
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Wed Jun 7 15:56:52 2006
New Revision: 412604
URL: http://svn.apache.org/viewvc?rev=412604view=rev
Log:
Fixes to config.xml, plugins, plugin repo list, plugin installer
- Plugin exporter can map current version to a set of supported
versions
to help with problems caused by plugins not running on new test
builds
of Geronimo
- config.xml has placeholder for user-added plugin repositories
GERONIMO-2076
- Removed Apache directory content from config.xml for 4 main
assemblies
- Added directory config.xml content to directory plugin metadata
- Plugin installer writes correct elements for config.xml content
GERONIMO-2088
- Plugin exporter includes file copy and config.xml content
GERONIMO-2089
- Plugin repository list points to a version-specific file (so 1.1 and
1.2 can point to different repositories)
- Trim entries in plugin repository list, just in case
- Remove some extraneous logging during console plugin download
Modified:
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
geronimo/branches/1.1/assemblies/j2ee-jetty-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/j2ee-tomcat-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/minimal-jetty-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/minimal-tomcat-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/j2ee-installer/src/var/config/config.xml
geronimo/branches/1.1/configs/directory/src/conf/geronimo-plugin.xml
geronimo/branches/1.1/modules/common/src/test/org/apache/geronimo/common/propertyeditor/AbstractCollectionEditorTest.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
Modified:
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java?rev=412604r1=412603r2=412604view=diff
==
---
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
(original)
+++
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
Wed Jun 7 15:56:52 2006
@@ -152,9 +152,9 @@
progressInfo.setMainMessage(results.getCurrentMessage());
progressInfo.setProgressPercent(results.getCurrentFilePercent());
progressInfo.setFinished(results.isFinished());
-log.info(progressInfo.getMainMessage());
+log.debug(progressInfo.getMainMessage());
if (results.isFinished()) {
-log.info(Installation finished);
+log.debug(Installation finished);
session.setAttribute(DOWNLOAD_RESULTS_SESSION_KEY, results);
break;
} else {
Modified:
Re: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con
P.S. :) You guys rock, BTW!
Alan D. Cabrera wrote:
I see some gold plating sneaking into a feature frozen branch.
Since I am not doing any heavy lifting, I'll leave my comment at that.
Regards,
Alan
Matt Hogstrom wrote:
Aaron,
Its been a long day and I've caught up on the JIRAs you created. I
think I'm ok with your fixes given the JIRA entries I read through.
I think the PluginRepositoryExporter.java should not be hardcoding
values in it. Can you look at moving this to a property file in the
future? Geronimo has way too many configuration items hard coded in
the server (or requires a server rebuild to make changes). I would
prefer not to see any other changes in this area for 1.1.
Are there any other bugs that you are aware of that we need to be
tracking?
Also, if you could take a whack at the JIRAs you moved into 1.1 and
move them out that would be really helpful.
Thanks
Matt
Matt Hogstrom wrote:
Aaron,
We are in the process of releasing 1.1. In the release note I
requested that people please let me know before commiting changes to
1.1. The number of changes you've made below are significant
changes. Can you please revert this change as well as 412621 and
hold them for 1.1 please.
For specific issues with 1.1 please post a note about the change so
we can discuss the content of hte change before applying it to the
build.
If you would like to bring these issues forward for discussion that
would be fine but I'm inclinced to get 1.1 out and have these in 1.1.1.
Thanks.
Matt
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Wed Jun 7 15:56:52 2006
New Revision: 412604
URL: http://svn.apache.org/viewvc?rev=412604view=rev
Log:
Fixes to config.xml, plugins, plugin repo list, plugin installer
- Plugin exporter can map current version to a set of supported
versions
to help with problems caused by plugins not running on new test
builds
of Geronimo
- config.xml has placeholder for user-added plugin repositories
GERONIMO-2076
- Removed Apache directory content from config.xml for 4 main
assemblies
- Added directory config.xml content to directory plugin metadata
- Plugin installer writes correct elements for config.xml content
GERONIMO-2088
- Plugin exporter includes file copy and config.xml content
GERONIMO-2089
- Plugin repository list points to a version-specific file (so 1.1
and
1.2 can point to different repositories)
- Trim entries in plugin repository list, just in case
- Remove some extraneous logging during console plugin download
Modified:
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
geronimo/branches/1.1/assemblies/j2ee-jetty-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/j2ee-tomcat-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/minimal-jetty-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/minimal-tomcat-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/j2ee-installer/src/var/config/config.xml
geronimo/branches/1.1/configs/directory/src/conf/geronimo-plugin.xml
geronimo/branches/1.1/modules/common/src/test/org/apache/geronimo/common/propertyeditor/AbstractCollectionEditorTest.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
Modified:
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java?rev=412604r1=412603r2=412604view=diff
==
---
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
(original)
+++
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
Wed Jun 7 15:56:52 2006
@@ -152,9 +152,9 @@
progressInfo.setMainMessage(results.getCurrentMessage());
progressInfo.setProgressPercent(results.getCurrentFilePercent());
progressInfo.setFinished(results.isFinished());
-log.info(progressInfo.getMainMessage());
+log.debug(progressInfo.getMainMessage());
if (results.isFinished()) {
-log.info(Installation finished);
+log.debug(Installation finished);
session.setAttribute(DOWNLOAD_RESULTS_SESSION_KEY, results);
break;
Re: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con
On 6/8/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I see some gold plating sneaking into a feature frozen branch. Since
I am not doing any heavy lifting, I'll leave my comment at that.
I've volunteered to be release manager for 1.2. Want to join me? A
little counterweight? :)
Thanks,
Aaron
Matt Hogstrom wrote:
Aaron,
Its been a long day and I've caught up on the JIRAs you created. I
think I'm ok with your fixes given the JIRA entries I read through.
I think the PluginRepositoryExporter.java should not be hardcoding
values in it. Can you look at moving this to a property file in the
future? Geronimo has way too many configuration items hard coded in
the server (or requires a server rebuild to make changes). I would
prefer not to see any other changes in this area for 1.1.
Are there any other bugs that you are aware of that we need to be
tracking?
Also, if you could take a whack at the JIRAs you moved into 1.1 and
move them out that would be really helpful.
Thanks
Matt
Matt Hogstrom wrote:
Aaron,
We are in the process of releasing 1.1. In the release note I
requested that people please let me know before commiting changes to
1.1. The number of changes you've made below are significant
changes. Can you please revert this change as well as 412621 and
hold them for 1.1 please.
For specific issues with 1.1 please post a note about the change so
we can discuss the content of hte change before applying it to the
build.
If you would like to bring these issues forward for discussion that
would be fine but I'm inclinced to get 1.1 out and have these in 1.1.1.
Thanks.
Matt
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Wed Jun 7 15:56:52 2006
New Revision: 412604
URL: http://svn.apache.org/viewvc?rev=412604view=rev
Log:
Fixes to config.xml, plugins, plugin repo list, plugin installer
- Plugin exporter can map current version to a set of supported
versions
to help with problems caused by plugins not running on new test
builds
of Geronimo
- config.xml has placeholder for user-added plugin repositories
GERONIMO-2076
- Removed Apache directory content from config.xml for 4 main
assemblies
- Added directory config.xml content to directory plugin metadata
- Plugin installer writes correct elements for config.xml content
GERONIMO-2088
- Plugin exporter includes file copy and config.xml content
GERONIMO-2089
- Plugin repository list points to a version-specific file (so 1.1 and
1.2 can point to different repositories)
- Trim entries in plugin repository list, just in case
- Remove some extraneous logging during console plugin download
Modified:
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
geronimo/branches/1.1/assemblies/j2ee-jetty-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/j2ee-tomcat-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/minimal-jetty-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/minimal-tomcat-server/src/var/config/config.xml
geronimo/branches/1.1/assemblies/j2ee-installer/src/var/config/config.xml
geronimo/branches/1.1/configs/directory/src/conf/geronimo-plugin.xml
geronimo/branches/1.1/modules/common/src/test/org/apache/geronimo/common/propertyeditor/AbstractCollectionEditorTest.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginInstallerGBean.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
Modified:
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
URL:
http://svn.apache.org/viewvc/geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java?rev=412604r1=412603r2=412604view=diff
==
---
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
(original)
+++
geronimo/branches/1.1/applications/console-standard/src/java/org/apache/geronimo/console/car/DownloadCARHandler.java
Wed Jun 7 15:56:52 2006
@@ -152,9 +152,9 @@
progressInfo.setMainMessage(results.getCurrentMessage());
progressInfo.setProgressPercent(results.getCurrentFilePercent());
progressInfo.setFinished(results.isFinished());
-log.info(progressInfo.getMainMessage());
+log.debug(progressInfo.getMainMessage());
if (results.isFinished()) {
-log.info(Installation finished);
+log.debug(Installation finished);
session.setAttribute(DOWNLOAD_RESULTS_SESSION_KEY,
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
for a SPEC change (unless there was a bug) it makes more sense for a full point release change and not a dot release. Dot releases should be limited to bug, stability and performance related improvements. Rick McGuire wrote: Alan D. Cabrera wrote: Rick McGuire wrote: Kevan Miller wrote: Rick, If you're updating javamail, you need to update the version number for the javamail spec. --kevan I was sort of wondering if anything needed to be done there. I assume it should be changed from 1.1 to 1.1.1? 1.2-SNAPSHOT please. I don't have a problem with changing it to 1.2-SNAPSHOT, but I'd like to understand the rationale behind the choice in case it comes up in the future. Rick Regards, Alan
[jira] Created: (AMQ-742) Allow standby broker to be started and have it wait for the master to fail before taking over it's data files.
Allow standby broker to be started and have it wait for the master to fail before taking over it's data files. -- Key: AMQ-742 URL: https://issues.apache.org/activemq/browse/AMQ-742 Project: ActiveMQ Type: New Feature Components: Broker Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1 Currently if you try to start a broker that uses the same datafiles as a broker that is allready running, the broker will not start up. -- 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: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Matt Hogstrom wrote: for a SPEC change (unless there was a bug) it makes more sense for a full point release change and not a dot release. Dot releases should be limited to bug, stability and performance related improvements. Which is why I chose to go with 1.1.1. The changes I just checked in are merely bug fixes (and some unit test improvements). Rick Rick McGuire wrote: Alan D. Cabrera wrote: Rick McGuire wrote: Kevan Miller wrote: Rick, If you're updating javamail, you need to update the version number for the javamail spec. --kevan I was sort of wondering if anything needed to be done there. I assume it should be changed from 1.1 to 1.1.1? 1.2-SNAPSHOT please. I don't have a problem with changing it to 1.2-SNAPSHOT, but I'd like to understand the rationale behind the choice in case it comes up in the future. Rick Regards, Alan
Re: Reorganizing javamai (revisited)
+1
Great idea.
-dain
On Jun 7, 2006, at 5:46 AM, Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached
a consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that
the javamail code needed to be reorganized so that the javamail-
transport jar (which is currently part of the Geronimo build) is
separated from Geronimo and available with the geronimo-javamail-
spec jar. The consensus seemed to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the
tck signature tests. It looks like the best approach here would be
to rename the existing javamail spec module to geronimo-javamail-
spec-1.3 and introduce a new geronimo-javamail-spec-1.4 module
to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to geronimo-spec-
javamail-1.3. This already builds a geronimo-javamail_1.3.1_spec-$
{geronimoSpecsJavamailVersion} jar file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it
doesn't really fit). This will have two modules for the 1.3 and
1.4 versions of the providers, and will build geronimo-
javamail_1.3.1_provider-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two uber-
jars containing the specs and providers combined: geronimo-
javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and geronimo-
javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
Re: [RTC] ActiveMQ GBean modules
I was going to defer to others that had time. Personally I'd like to get 1.1 out :) Hiram Chirino wrote: So in terms the of the RTC process, is this RTC patch dead since it did not get the 3 +1's I kinda would have preferred to get some -1's instead of not getting any comments on the patch. Is it that there are not enough folks that are interested in the activemq integration aspects of geronimo? Regards, Hiram On 6/6/06, Hiram Chirino [EMAIL PROTECTED] wrote: m2 poms are included in the patch. But for some reason the current m2 build does not seem to let you run mvn from a submodule, some dependency variables do not get evaluated. weird. On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote: Howdy folks, Here's a patch that brings in the activemq gbean modules into geronimo. It's partly what was in activemq 4.x and integrated into geronimo 1.2-dead merged with the changes in the 3.x branch. It compiles at least and looks like a reasonable start. Once further integration work gets done we may need to tweak a little more. here's my +1 got get this committed. I guess I just need 3 more. I'd find it a lot easier to review, apply, and test this patch if you attached it to a jira entry. Is there any chance of you coming up with a pom.xml for the m2 build? thanks david jencks -- Regards, Hiram
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
I guess it should be 1.1.1-SNAPSHOT then ;) Cheers, Guillaume Nodet Rick McGuire wrote: Matt Hogstrom wrote: for a SPEC change (unless there was a bug) it makes more sense for a full point release change and not a dot release. Dot releases should be limited to bug, stability and performance related improvements. Which is why I chose to go with 1.1.1. The changes I just checked in are merely bug fixes (and some unit test improvements). Rick Rick McGuire wrote: Alan D. Cabrera wrote: Rick McGuire wrote: Kevan Miller wrote: Rick, If you're updating javamail, you need to update the version number for the javamail spec. --kevan I was sort of wondering if anything needed to be done there. I assume it should be changed from 1.1 to 1.1.1? 1.2-SNAPSHOT please. I don't have a problem with changing it to 1.2-SNAPSHOT, but I'd like to understand the rationale behind the choice in case it comes up in the future. Rick Regards, Alan
[jira] Updated: (AMQ-714) Wildcard support for policy entries produces unexpected results
[ https://issues.apache.org/activemq/browse/AMQ-714?page=all ] Hiram Chirino updated AMQ-714: -- Fix Version: 4.0.1 4.1 (was: 4.0) Wildcard support for policy entries produces unexpected results --- Key: AMQ-714 URL: https://issues.apache.org/activemq/browse/AMQ-714 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0, 4.0 RC3 Environment: linux ibm jdk 1.4.2 sun jdk 1.5 Reporter: Kyle Himmerick Fix For: 4.1, 4.0.1 Attachments: issue.zip Original Estimate: 2 minutes Remaining: 2 minutes When you define a policy Entry using a wildcard (eg. FOO.) in the xml configuration it is not applied as expected. Specifically I was attempting to use a lastImageSubscriptionRecoveryPolicy on all subtopics of FOO. If I publish three messages to each of FOO.a, FOO.b and FOO.c and then setup a consumer (retroactive = true) to each of the topics FOO.a, FOO.b and FOO.c I receive three copies of the last message sent to any of the topics In this case the third message sent to FOO.c. Expected behaviour would be to receive the last message from each topic that is message three from FOO.a, FOO.b and FOO.c More troubling is if I setup a new session with a consumer only to FOO.a and FOO.b I receive two copied of the third message sent to FOO.c. Even though this session is not subscribed to FOO.c, presumably this is because the policy is only keeping the last message that matches the destination and returning it as the last image, regardless of if the topic matches the subscription. With explicit policy entries for each topic (FOO.a, FOO.b) the broker returns the correct messages, so I believe the problem is with wildcard handling. I need wildcard support here because I do not know my topic names upfront. I would think that this would be a common scenario (like setting a last image recovery policy on all stock quotes Stock. ) -- 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
RELEASE-NOTES-1.1
Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan
[jira] Resolved: (GERONIMO-1883) Make sure all documentation is clearly marked as G 1.0 or G 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1883?page=all ] Hernan Cunico resolved GERONIMO-1883: - Resolution: Fixed All the documentation has been reorganized and migrated over the new wiki cwiki.apache.org From now on there should be one new space for each new major release of Geronimo Make sure all documentation is clearly marked as G 1.0 or G 1.1 --- Key: GERONIMO-1883 URL: http://issues.apache.org/jira/browse/GERONIMO-1883 Project: Geronimo Type: Bug Security: public(Regular issues) Components: documentation Versions: 1.0 Reporter: Aaron Mulder Assignee: Hernan Cunico Priority: Critical Fix For: 1.1 As we roll out 1.1, with different deployment plan syntax, it'll be extremely import that *all* documentation clearly states (e.g. in big bold text at the top) which Geronimo version it applies to. We can go ahead and mark all the 1.0 content as 1.0 now, and just update the marker as the content itself is updated to 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-1386) Docs produced by Confluence contain spaces in file names
[ http://issues.apache.org/jira/browse/GERONIMO-1386?page=comments#action_12415380 ] Hernan Cunico commented on GERONIMO-1386: - The HTML autoexported spaces provide an alternative fix to this issue and it is currently in use at cwiki.apache.org/geronimo. Working on alternative to zip/tar those directories and make them available for download directly from geronimo.apache.org Docs produced by Confluence contain spaces in file names Key: GERONIMO-1386 URL: http://issues.apache.org/jira/browse/GERONIMO-1386 Project: Geronimo Type: Bug Security: public(Regular issues) Components: documentation Versions: 1.0 Reporter: John Sisson Assignee: Hernan Cunico Fix For: 1.2 This was reported to the dev list in: http://www.mail-archive.com/dev%40geronimo.apache.org/msg14471.html -- 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: [Build error] - I can not build a freash copy of r411545
Hi Matt... I did whatyou told me to do, I ceched out the specs, built them using maven install command, tryied to build G again but failed with the same error of ClassNotFoundException. I am trying to trace this error, but anybody knows about the solution of this problem please help? I would like to mention that I am using: WindowsXP, Java 1.4.2_11, Maven 1.1b2 ---Never give up, Never...---Thanks and best regardsMohammad Nour El-Din On 6/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Mohammed,You need to checkout the spec independent of Geronimo.Do ansvn co http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1cd to that directory and execute:mvn installThis will update your specs and you should be good to go.MattMohammed Nour wrote: Hi All... I failed again to build a brand new fresh copy og *G,* and here is the link of the build error http://rifers.org/paste/show/886 -- Never give up, Never... -- *Thanks and best regards...* *Mohammad Nour El-Din* On 6/5/06, Bryan Noll [EMAIL PROTECTED] wrote:Mohammad, I was having the same issue you were just the other day.I got it to work by doing the following: maven -Dmaven.test.skip -Dmaven.itest.skip David Jencks wrote: On Jun 4, 2006, at 6:58 AM, Mohammed Nour wrote:Hi All... I've been struggling too long trying to building G, but all my tries failed. I got a fresh copy of r411545 and got the following error while trying to build it http://rifers.org/paste/show/877 I talked with djencks on IRC and he ask me to try building TrnaQl and OEJB separatly and then try to build G again, but while I am trying to build OEJB I got the following error http://rifers.org/paste/show/878 All the parts of openejb that are known to build, built for you.We are currently only using core, openejb-builder, and pkgen-builder.I'm afraid that I am so used to how I build openejb from within geronimo I forget that there are other ways. What I do is check out openejb inside geronimo using maven m:co which checks out the correct version (2.1-SNAPSHOT at the moment) and build it using maven new2 What command did you use? In any case you should be able to proceed with your geronimo build now. Hope this helps, david jencks so please help. --- Never give up, Never... --- *Thanks and best regards* *Mohammad Nour El-Din*
Re: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Rick McGuire wrote: Matt Hogstrom wrote: for a SPEC change (unless there was a bug) it makes more sense for a full point release change and not a dot release. Dot releases should be limited to bug, stability and performance related improvements. Which is why I chose to go with 1.1.1. The changes I just checked in are merely bug fixes (and some unit test improvements). This should also mirror the repo organization. Technically, the 1.0.1 versions that came from trunk should have been labeled 1.1.0. If you intend to release a patch, you should branch the 1_2 tag and put your patches in there. Since this is trunk, it should be labled 1.20-SNAPSHOT. Regards, Alan
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: I updated the release notes and it is ready for your review Looks good! A few comments: 1) Under system requirements, I think it should mention that Geronimo will run fine on Java 5 out of the box, and offer the caveats that it is only J2EE-certified on 1.4 and that in particular, you will need to run under 1.4 if you enable CORBA support. 2) Under Administration Console Security Configuration, it should mention that the username/password can be changed within the console itself. e.g. This can be changed through the console (in the Security - Console Realm section) or by editing geronimo_home/var.. 3) Looks like there's a typo in the Deploying Applications section. It says geronimo_home/bin/java -jar. instead of just java -jar. 4) In that same section, perhaps worth mentioning that you can run the login command in the deployer tool and not have to enter the password over and over. It's kind of a minor detail, but constant retyping of passwords could ruin the deployment experience for people. 5) Under Choice of Web container, it sounds a little open-ended to say Please download the binary appropriate for your environment. People will wonder what it is that makes one or the other appropriate for their environment. Not sure how to say it better, but perhaps indicate that choosing one at random is fine if you or your company don't already have a preference? Cheers, Erin
[jira] Updated: (GERONIMO-1196) Keystore portlet: Viewing trusted certificate results in an error
[ http://issues.apache.org/jira/browse/GERONIMO-1196?page=all ] Matt Hogstrom updated GERONIMO-1196: Fix Version: Verification Required (was: 1.1) Keystore portlet: Viewing trusted certificate results in an error - Key: GERONIMO-1196 URL: http://issues.apache.org/jira/browse/GERONIMO-1196 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0, 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Priority: Critical Fix For: Verification Required Attachments: GERONIMO-1196-2.patch, GERONIMO-1196.patch Viewing a trusted certificate results in an error. The following exception is logged to geronimo.log 12:04:01,806 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.certmanager.actions.ViewKeyStoreEntryDetail.render(ViewKeyStoreEntryDetail.java:69) at org.apache.geronimo.console.certmanager.CertManagerPortlet.doView(CertManagerPortlet.java:134) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) ... Caused by: java.lang.NullPointerException at sun.security.provider.JavaKeyStore$JKS.convertAlias(JavaKeyStore.java:40) at sun.security.provider.JavaKeyStore.engineIsCertificateEntry(JavaKeyStore.java:409) at java.security.KeyStore.isCertificateEntry(KeyStore.java:567) at org.apache.geronimo.console.core.keystore.KeyStoreGBean.getKeyEntryInfo(KeyStoreGBean.java:179) ... -- 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-1271) Delete network listener action should ask for confirmation
[ http://issues.apache.org/jira/browse/GERONIMO-1271?page=all ] Matt Hogstrom updated GERONIMO-1271: Fix Version: Wish List (was: 1.1) Delete network listener action should ask for confirmation -- Key: GERONIMO-1271 URL: http://issues.apache.org/jira/browse/GERONIMO-1271 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Rick McGuire Assignee: Aaron Mulder Priority: Minor Fix For: Wish List The Delete operation of the Web Server-Network Listeners should ask for confirmation before deleting. It is real easy to accidentally click on delete instead of edit and accidentally delete needed listenersfor example, the listener required by the console itself (ask me how I know :-)). -- 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-1273) JMS Network Listener add dialogs should give some context information on the protocol.
[ http://issues.apache.org/jira/browse/GERONIMO-1273?page=all ] Matt Hogstrom updated GERONIMO-1273: Fix Version: Wish List (was: 1.1) JMS Network Listener add dialogs should give some context information on the protocol. -- Key: GERONIMO-1273 URL: http://issues.apache.org/jira/browse/GERONIMO-1273 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Rick McGuire Assignee: Aaron Mulder Priority: Minor Fix For: Wish List Attachments: 1273-jms-listener-add-dialog.patch The JMS Network Listener add dialogs (add activieio listener, etc) should give some kind of context information rather than presenting the exact dialog for all listener types. This causes a bit of uncertainty on the user's part that the correct operation is being performed. -- 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: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Alan D. Cabrera wrote: Rick McGuire wrote: Matt Hogstrom wrote: for a SPEC change (unless there was a bug) it makes more sense for a full point release change and not a dot release. Dot releases should be limited to bug, stability and performance related improvements. Which is why I chose to go with 1.1.1. The changes I just checked in are merely bug fixes (and some unit test improvements). This should also mirror the repo organization. Technically, the 1.0.1 versions that came from trunk should have been labeled 1.1.0. If you intend to release a patch, you should branch the 1_2 tag and put your patches in there. Since this is trunk, it should be labled 1.20-SNAPSHOT. Ok, I'll change it to 1.2. All of the 1.0.1 versions in the repo certainly pushed me to the conclusion that 1.1.1 was the correct way to go. Rick Regards, Alan
[jira] Updated: (GERONIMO-1285) Deployer does not list all modules that have been stopped
[ http://issues.apache.org/jira/browse/GERONIMO-1285?page=all ] Matt Hogstrom updated GERONIMO-1285: Fix Version: Verification Required (was: 1.1) Deployer does not list all modules that have been stopped - Key: GERONIMO-1285 URL: http://issues.apache.org/jira/browse/GERONIMO-1285 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: Verification Required When you, for example, stop the tomcat configuration, all the web apps deployed to Tomcat are stopped too. However, the deployer does not let you know this. It should list all modules that were stopped, just like it does when starting. -- 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-1367) Shutdown JAR should use deployer stored username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1367?page=all ] Matt Hogstrom updated GERONIMO-1367: Fix Version: Wish List (was: 1.1) Shutdown JAR should use deployer stored username/password - Key: GERONIMO-1367 URL: http://issues.apache.org/jira/browse/GERONIMO-1367 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: startup/shutdown, usability Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: Wish List It would be nice if the shutdown script used the username and password saved by the deployer so you didn't need to specify them or re-enter them. -- 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-1368) Remote deployment probably doesn't handle exploded JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1368?page=all ] Matt Hogstrom updated GERONIMO-1368: Fix Version: Wish List (was: 1.1) Remote deployment probably doesn't handle exploded JARs --- Key: GERONIMO-1368 URL: http://issues.apache.org/jira/browse/GERONIMO-1368 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: Wish List If you pass an exploded JAR to the deploy tool when running on a remote machine, it should zip it on the fly when uploading to the server. -- 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-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] Matt Hogstrom updated GERONIMO-1384: Fix Version: 1.1.1 (was: 1.1) Web app with no Geronimo plan makes all secure pages insecure - Key: GERONIMO-1384 URL: http://issues.apache.org/jira/browse/GERONIMO-1384 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, security Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Trivial Fix For: 1.1.1 Attachments: security-reject.patch If you deploy a web application with certain pages/URLs protected by a login, but you don't include a Geronimo deployment plan, all those pages/URLs are unprotected. To replicate: Deploy this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and click the links to secure and forbidden. Both links work, with no login prompt. Instead, you should get a login prompt and (since no realm was configured) all logins should fail. The web.xml in this case contains: security-constraint web-resource-collection web-resource-nameAdmin Role/web-resource-name url-pattern/protect/*/url-pattern /web-resource-collection auth-constraint role-namecontent-administrator/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint login-config auth-methodFORM/auth-method realm-nameMYREALM/realm-name form-login-config form-login-page/auth/logon.html?param=test/form-login-page form-error-page/auth/logonError.html?param=test/form-error-page /form-login-config /login-config security-role role-namecontent-administrator/role-name /security-role -- 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-1431) Make deploy tool and hot deploy directory work better together
[ http://issues.apache.org/jira/browse/GERONIMO-1431?page=all ] Matt Hogstrom updated GERONIMO-1431: Fix Version: 1.1.1 (was: 1.1) Make deploy tool and hot deploy directory work better together -- Key: GERONIMO-1431 URL: http://issues.apache.org/jira/browse/GERONIMO-1431 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, Hot Deploy Dir Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1.1 Right now if you deploy something with the deploy tool and then drop an update in the hot deploy directory, it doesn't work. The hot deploy dir expects you to only use the hot dpeloy dir for that module. Likewise, if you deploy something with the hot deploy dir and then undeploy it with the deploy tool, it is not deleted from the hot deploy dir. Both of those can be fixed. -- 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-1445) Allow deployment and use of exploded EAR modules
[ http://issues.apache.org/jira/browse/GERONIMO-1445?page=all ] Matt Hogstrom updated GERONIMO-1445: Fix Version: 1.1.1 (was: 1.1) Allow deployment and use of exploded EAR modules Key: GERONIMO-1445 URL: http://issues.apache.org/jira/browse/GERONIMO-1445 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, Hot Deploy Dir Versions: 1.0 Environment: Windows XP Reporter: Todd Williams Assignee: Aaron Mulder Priority: Critical Fix For: 1.1.1 Attachments: GeronimoTestEar.ear.zip Using the Geronimo 1.0 / Tomcat bundle, placing an exploded WAR into the deploy directory causes it to be picked up and deployed by the hot deployer as expected. However, if I wrap the exploded war with an exploded EAR, Geronimo fails to deploy with the error message : 17:00:50,282 INFO [Hot Deployer] Deploying GeronimoTestEar.ear 17:00:51,494 ERROR [Hot Deployer] Unable to deploy: Module was not a war: GeronimoTestWeb.war org.apache.geronimo.common.DeploymentException: Module was not a war: GeronimoTestWeb.war at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:544) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:226) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:122) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$1c79c440.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:219) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:534) I'll attached a zip that when unzipped contains the exploded hierarchy for the EAR. The application is small, but valid, as it deploys just fine when created as an archived EAR. -- 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: svn commit: r412426 - in /geronimo/specs/trunk/geronimo-spec-javamail/src: main/java/javax/mail/internet/ main/java/org/apache/geronimo/mail/util/ test/java/javax/mail/internet/
Rick McGuire wrote: Alan D. Cabrera wrote: Rick McGuire wrote: Matt Hogstrom wrote: for a SPEC change (unless there was a bug) it makes more sense for a full point release change and not a dot release. Dot releases should be limited to bug, stability and performance related improvements. Which is why I chose to go with 1.1.1. The changes I just checked in are merely bug fixes (and some unit test improvements). This should also mirror the repo organization. Technically, the 1.0.1 versions that came from trunk should have been labeled 1.1.0. If you intend to release a patch, you should branch the 1_2 tag and put your patches in there. Since this is trunk, it should be labled 1.20-SNAPSHOT. Ok, I'll change it to 1.2. All of the 1.0.1 versions in the repo certainly pushed me to the conclusion that 1.1.1 was the correct way to go. That's understandable. It set a bad precedent. Regards, Alan
[jira] Updated: (GERONIMO-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Matt Hogstrom updated GERONIMO-1524: Fix Version: 1.1.1 (was: 1.1) DB pool portlet should let you select multiple driver JARs -- Key: GERONIMO-1524 URL: http://issues.apache.org/jira/browse/GERONIMO-1524 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-1524.patch Currently the database pool portlet can handle a driver requiring multiple JARs, but the UI doesn't actually let you select more than one. Some drivers known to need more include DB/2 and MS SQL Server. Perhaps the screen should have a checkbox to reveal another 2 driver selection pick lists (the security realm portlet advanced config screen has an example of revealing extra fields if you check a particular checkbox). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: OpenEJB build fails (CORBA)
This built for me. Are you guys still having problems?
Regards,
Alan
Matt Hogstrom wrote:
Ug,
I'm building now but expect my fate won't be any better. If I
remember this correctly there was lots of confusion about OpenOrb and
JacOrb at the 1.0 release. I don't recall which is which but the
compile errors below are familiar.
Alan, comments?
Matt
Aaron Mulder wrote:
I just built the 1.1 specs tag and copied all the specs from my Maven
2 repo to my Maven 1 repo. I've updated Geronimo and OpenEJB.
When I build, I get the error below.
Thanks,
Aaron
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/data/cvs/geronimo-1.1/openejb/modules/core/target/classes/depend
[echo] Compiling to
/data/cvs/geronimo-1.1/openejb/modules/core/target/classes
[javac] Compiling 605 source files to
/data/cvs/geronimo-1.1/openejb/modules/core/target/classes
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSConfig.java:55:
package org.omg.CSI does not exist
[javac] import org.omg.CSI.EstablishContext;
[javac]^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSTransportMechConfig.java:57:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.TAG_NULL_TAG;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSTransportMechConfig.java:58:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.TAG_SECIOP_SEC_TRANS;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSTransportMechConfig.java:59:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.TAG_TLS_SEC_TRANS;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechListConfig.java:56:
package org.omg.CSI does not exist
[javac] import org.omg.CSI.EstablishContext;
[javac]^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechListConfig.java:57:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.CompoundSecMech;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechListConfig.java:58:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.CompoundSecMechList;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechListConfig.java:59:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.CompoundSecMechListHelper;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechListConfig.java:60:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.TAG_CSI_SEC_MECH_LIST;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSConfig.java:106:
cannot resolve symbol
[javac] symbol : class EstablishContext
[javac] location: class
org.openejb.corba.security.config.tss.TSSConfig
[javac] public Subject check(SSLSession session,
EstablishContext msg) throws SASException {
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechConfig.java:54:
package org.omg.CSI does not exist
[javac] import org.omg.CSI.EstablishContext;
[javac]^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechConfig.java:55:
package org.omg.CSIIOP does not exist
[javac] import org.omg.CSIIOP.CompoundSecMech;
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/tss/TSSCompoundSecMechListConfig.java:126:
cannot resolve symbol
[javac] symbol : class EstablishContext
[javac] location: class
org.openejb.corba.security.config.tss.TSSCompoundSecMechListConfig
[javac] public Subject check(EstablishContext msg) throws
SASException {
[javac] ^
[javac]
/data/cvs/geronimo-1.1/openejb/modules/core/src/java/org/openejb/corba/security/config/css/CSSCompoundSecMechConfig.java:56:
package org.omg.CSI does not exist
[javac] import org.omg.CSI.EstablishContext;
[javac]^
[javac]
RE: cwiki.apache.org [longish]
Hernan, Thank you very much! Vasily -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 7:56 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] Hi Vasily, I just reported this issue to Atlassian (https://support.atlassian.com/browse/CSP-4236). Not sure why confluence is complaining, that page is not that big and I was able to migrate it from the other installation. It actually is failing to save any changes, there might be some confluence code in the doc that this new version is not too happy with. I'll review the page markup as soon as I have a min, if I can't find anything suspicious I could re-import it from an XML (a new one from the Atlassian install) while we still look for the final solution. Cheers! Hernan Zakharov, Vasily M wrote: Hernan, Thank you alot for your great work on new G wiki! But oops, I was trying to copy my doc from the old location at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/SPECjApp Server2004 to the new location at: http://cwiki.apache.org/confluence/display/GMOxDOC10/SPECjAppServer2004 I copied the wiki content and got a successful preview, but when I press Save, I get a System Error: java.lang.IllegalStateException: Form too large at org.mortbay.http.HttpRequest.extractParameters()V(Unknown Source) I see that my doc is rather big, but it worked fine on the old Confluence at opensource.atlassian.com. Is it some new feature of Confluence 2.1.5a? :) Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 5:30 PM To: dev@geronimo.apache.org Subject: Re: cwiki.apache.org [longish] All the groups have been updated, you all should have edit permissions. Cheers! Hernan John Sisson wrote: Who has access to fix this? John Jason Dillon wrote: It appears that the other spaces need their permissions updated. --jason On Jun 7, 2006, at 2:39 PM, Erin Mulder wrote: Hernan Cunico wrote: Hi All, I have enabled public signup so now you can register and contribute directly to the documentation. Thanks for setting this up! I just signed up, but once I was logged in, I could no longer see most of the Geronimo spaces. Is it possible that permissions have been set for Anonymous, but not for confluence-users (or whatever the equivalent role is in this installation)? When I'm logged out, I see: Apache Geronimo Documentation (geronimo)Apache Geronimo Project Management (GMOxPMGT)Apache Geronimo SandBox (GMOxSBOX) Apache Geronimo v1.0 (GMOxDOC10)Apache Geronimo v1.1 (GMOxDOC11) When I'm logged in, I see: Apache Geronimo v1.0 (GMOxDOC10)Cayenne Documentation (cayenne)Demonstration Space (ds)Test Space (test) Cheers, Erin
[jira] Updated: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Matt Hogstrom updated GERONIMO-1531: Fix Version: 1.1.1 (was: 1.1) KeyStore portlet should support deletion of certificates and private keys - Key: GERONIMO-1531 URL: http://issues.apache.org/jira/browse/GERONIMO-1531 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1531.patch KeyStore portlet currently supports generation of keypairs, adding trusted certificates to keystore and importing certificate issued by CA. It does not address deletion of any of these from the keystore. -- 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] Closed: (GERONIMO-1532) NullPointerException when a badly named jar is put into repository directory
[ http://issues.apache.org/jira/browse/GERONIMO-1532?page=all ] Matt Hogstrom closed GERONIMO-1532: --- Resolution: Fixed Closing per Paul's comments NullPointerException when a badly named jar is put into repository directory Key: GERONIMO-1532 URL: http://issues.apache.org/jira/browse/GERONIMO-1532 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Heikki Linnakangas Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: listURIs.diff I copied a JDBC driver jar to geronimo/repository-directory, thinking that geronimo would pick it up from there. What I didn't know, is that jars in the repository need to be named in a particular way. I then tried to add a Database pool using the wizard. I filled the name and type in step 1, and clicked next. Instead of step 2, I got a blank screen, and this stack trace in the log: 14:30:33,322 ERROR [DatabasePoolPortlet] Unable to render portlet java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderBasicParams(DatabasePoolPortlet.java:721) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:625) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) ... The culprit seems to be the FileSystemRepository.listURIs-method, that doesn't handle invalid filenames properly, but returns nulls in the array it returns instead. -- 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: (AMQ-738) Broker does not recognize failed broker upon reconnect
[
https://issues.apache.org/activemq/browse/AMQ-738?page=comments#action_36265 ]
james strachan commented on AMQ-738:
Just out of interest - how had you created this network?
Broker does not recognize failed broker upon reconnect
--
Key: AMQ-738
URL: https://issues.apache.org/activemq/browse/AMQ-738
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Christopher G. Stach II
After normal shutdown of a broker and bring it back up, the first broker
reports this error:
[11:07:15.162] Establishing network connection between from
vm://app1-test?network=true to tcp://10.xxx:49995
[11:07:15.165] Starting a network connection between vm://app1-test#20 and
tcp://null:0 has been established.
[11:07:15.294] Async error occurred: javax.jms.InvalidClientIDException:
Broker: app1-test - Client: NC_app2-test_inboundapp1-test already connected
[11:07:15.294] javax.jms.InvalidClientIDException: Broker: app1-test -
Client: NC_app2-test_inboundapp1-test already connected
[11:07:15.294] at
org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:176)
[11:07:15.294] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:69)
[11:07:15.294] at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:69)
[11:07:15.294] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:69)
[11:07:15.294] at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:82)
[11:07:15.294] at
org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:507)
[11:07:15.294] at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:118)
[11:07:15.294] at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
[11:07:15.294] at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
[11:07:15.294] at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
[11:07:15.294] at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
[11:07:15.294] at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
[11:07:15.294] at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
[11:07:15.294] at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
[11:07:15.294] at
org.apache.activemq.network.DemandForwardingBridgeSupport.startLocalBridge(DemandForwardingBridgeSupport.java:192)
[11:07:15.294] at
org.apache.activemq.network.DemandForwardingBridgeSupport$3.run(DemandForwardingBridgeSupport.java:162)
[11:07:15.327] Network connection between vm://app1-test#20 and
tcp://app2.xxx/10.xxx:49995(app2-test) has been established.
[11:07:15.347] Unexpected local command: ConnectionError {commandId = 2,
responseRequired = false, connectionId = null, exception =
javax.jms.InvalidClientIDException: Broker: app1-test - Client:
NC_app2-test_inboundapp1-test already connected}
--
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-1567) Plan XML files aren't included in Geronimo distributions (was included in M5 release)
[ http://issues.apache.org/jira/browse/GERONIMO-1567?page=all ] Matt Hogstrom updated GERONIMO-1567: Fix Version: Wish List (was: 1.1) (was: 1.2) Plan XML files aren't included in Geronimo distributions (was included in M5 release) - Key: GERONIMO-1567 URL: http://issues.apache.org/jira/browse/GERONIMO-1567 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem, usability Versions: 1.0 Reporter: John Sisson Fix For: Wish List It was a combination of an oversight and the idea that being able to add gbeans using config.xml could replace the need to modify and redeploy the plans we supply. -- 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-1579) NPE while deploying EJB as Web Service
[ http://issues.apache.org/jira/browse/GERONIMO-1579?page=all ] Matt Hogstrom updated GERONIMO-1579: Fix Version: 1.1.1 (was: 1.1) NPE while deploying EJB as Web Service -- Key: GERONIMO-1579 URL: http://issues.apache.org/jira/browse/GERONIMO-1579 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1.1 Surely caused by a coding/configuration error, but it would really be preferable to produce a better error message. 10:23:37,328 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.openejb.deployment.SessionBuilder.addWSContainerGBean(SessionBuilder.java:208) at org.openejb.deployment.SessionBuilder.buildBeans(SessionBuilder.java:187) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:527) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor265.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at
[jira] Updated: (GERONIMO-1580) Better error message for missing WSDL file for EJB web service
[ http://issues.apache.org/jira/browse/GERONIMO-1580?page=all ] Matt Hogstrom updated GERONIMO-1580: Fix Version: 1.1.1 (was: 1.1) Better error message for missing WSDL file for EJB web service -- Key: GERONIMO-1580 URL: http://issues.apache.org/jira/browse/GERONIMO-1580 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1.1 If your webservices.xml file for a stateless session bean web service refers to a WSDL file that is not there, the error produced is java.lang.RuntimeException: Could not open stream to wsdl file It would be better if it produced a DeploymentException with a message something like: webservices.xml file for EJB JAR points to non-existant WSDL file 'META-INF/foo.wsdl' for service 'MyEJBWebService' The stack trace is 10:56:24,259 ERROR [Deployer] Deployment failed due to java.lang.RuntimeException: Could not open stream to wsdl file at org.apache.geronimo.axis.builder.SchemaInfoBuilder$JarWSDLLocator.getBaseInputSource(SchemaInfoBuilder.java:652) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.readWsdl(SchemaInfoBuilder.java:555) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.init(SchemaInfoBuilder.java:141) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.init(SchemaInfoBuilder.java:125) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:312) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at
[jira] Updated: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ http://issues.apache.org/jira/browse/GERONIMO-1581?page=all ] Matt Hogstrom updated GERONIMO-1581: Fix Version: Verification Required (was: 1.1) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: http://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: Verification Required It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- 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-1582) NPE for EJB webservices.xml with bad jaxrpc-mapping-file
[ http://issues.apache.org/jira/browse/GERONIMO-1582?page=all ] Matt Hogstrom updated GERONIMO-1582: Fix Version: 1.1.1 (was: 1.1) NPE for EJB webservices.xml with bad jaxrpc-mapping-file -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1.1 If the jaxrpc-mapping-file points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
Re: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con
OK, fixed: - http://issues.apache.org/jira/browse/GERONIMO-1434 - http://issues.apache.org/jira/browse/GERONIMO-1884 - http://issues.apache.org/jira/browse/GERONIMO-1938 - http://issues.apache.org/jira/browse/GERONIMO-1791 - http://issues.apache.org/jira/browse/GERONIMO-1817 - http://issues.apache.org/jira/browse/GERONIMO-1887 - http://issues.apache.org/jira/browse/GERONIMO-2093 Won't fix - http://issues.apache.org/jira/browse/GERONIMO-2083 Maybe someone else could look at: - http://issues.apache.org/jira/browse/GERONIMO-1451 - http://issues.apache.org/jira/browse/GERONIMO-1781 Thanks, Aaron On 6/8/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 7, 2006, at 9:23 PM, Aaron Mulder wrote: On 6/7/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Its been a long day and I've caught up on the JIRAs you created. I think I'm ok with your fixes given the JIRA entries I read through. OK I'm OK with these bug fixes too. I think the PluginRepositoryExporter.java should not be hardcoding values in it. Can you look at moving this to a property file in the future? Geronimo has way too many configuration items hard coded in the server (or requires a server rebuild to make changes). I would prefer not to see any other changes in this area for 1.1. Yes, it was just going to be a bigger change to put in a properties file and get it to read from that. Are there any other bugs that you are aware of that we need to be tracking? http://issues.apache.org/jira/browse/GERONIMO-1434 There's an OpenEJB patch listed as pending. I think this was the one that caused all the problems when the repo was down and has now been applied, but I'm not sure. David J, can you confirm? Kevan applied the patch for me, I've closed this one. http://issues.apache.org/jira/browse/GERONIMO-1451 There's an ActiveMQ patch that hasn't been applied because it needs to be done against the *-g1_1 module not the 1.0 module. Perhaps not tremendously important, but if it fixes the problem it would be nice to put into ActiveMQ 3.2.4 instead of immediately going to a new ActiveMQ SNAPSHOT. http://issues.apache.org/jira/browse/GERONIMO-1884 Should change the terminology on the plugin screen in the console to be consistent (there's a patch for this in http://issues.apache.org/jira/browse/GERONIMO-1938), and perhaps add a few words about removing plugins. I don't think we need to do anything else for this issue. http://issues.apache.org/jira/browse/GERONIMO-1791 http://issues.apache.org/jira/browse/GERONIMO-1817 Trivial patches to avoid NPEs in the LDAP realm. http://issues.apache.org/jira/browse/GERONIMO-1781 Reportedly, the repository blows up on a module like foo-1.jar NO URL There's no Jira for this, but we should remove the old keystore portlet from the console for the 1.1 release (but leave it there for 1.1.1, until all the functionality is replaced). http://issues.apache.org/jira/browse/GERONIMO-1887 The console has 1.7 MB of (potentially) unnecessary JARs. http://issues.apache.org/jira/browse/GERONIMO-2083 Should we upgrade to the current HOWL? no, we'd need an upload to ibiblio for this. I got a nice m2 build for howl working and created an m2 compliant upload request, but maven is not accepting them until it gets a new piece of hardware set up. thanks for looking through all of these! david jencks http://issues.apache.org/jira/browse/GERONIMO-1922 Would be nice to force a plugin export to fail if you've used the SharedLib dependency. I thought we had done this, but I don't see the code. So for now it's a training issue. I can look at most of these before noon on 6/8 if you are OK with that. Anything that you don't want to see go in? Also, if you could take a whack at the JIRAs you moved into 1.1 and move them out that would be really helpful. Hmm... thought you were going to do that. :) Thanks, Aaron Matt Hogstrom wrote: Aaron, We are in the process of releasing 1.1. In the release note I requested that people please let me know before commiting changes to 1.1. The number of changes you've made below are significant changes. Can you please revert this change as well as 412621 and hold them for 1.1 please. For specific issues with 1.1 please post a note about the change so we can discuss the content of hte change before applying it to the build. If you would like to bring these issues forward for discussion that would be fine but I'm inclinced to get 1.1 out and have these in 1.1.1. Thanks. Matt [EMAIL PROTECTED] wrote: Author: ammulder Date: Wed Jun 7 15:56:52 2006 New Revision: 412604 URL: http://svn.apache.org/viewvc?rev=412604view=rev Log: Fixes to config.xml, plugins, plugin repo list, plugin installer - Plugin exporter can map current version to a set of supported versions to help with problems caused by plugins not running on new test builds of Geronimo -
[jira] Assigned: (AMQ-716) message is read from queue but not removed
[ https://issues.apache.org/activemq/browse/AMQ-716?page=all ] Rob Davies reassigned AMQ-716: -- Assign To: Rob Davies message is read from queue but not removed -- Key: AMQ-716 URL: https://issues.apache.org/activemq/browse/AMQ-716 Project: ActiveMQ Type: Bug Components: Message Store Versions: 4.0 Environment: ActiveMQ Release (08.05.2006) BM Blade JS20 AIX 5.3 DB2 DataBase 8.2 Driver 2.5.33 Configuration: jdbcPersistenceAdapter class=org.activemq.store.jdbc.adapter.DefaultJDBCAdapter dataSource= #db2-ds/ bean id=db2datasource class=org.apache.commons.dbcp.BasicDataSource property name=driverClassName value=com.ibm.db2.jcc.DB2Driver/ property name=url value=URL/ property name=username value=USER/ property name=password value=PASS/ /bean Reporter: klaus terjung Assignee: Rob Davies Producer send a message with a non transacted Session Testing a Consumer with a non transacted Session to receive Messages the Message is read but not removed. Testing a Consumer with a transacted Session and commit the Message is read and not removed. -- 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: Daily post of IRC log to dev?
Sorry about the tardy reply. I do not think that this is a good idea. It's just noise and I think that people should give appropriate summaries as to what was discussed. Having IRC logs posted to this group is like listening to a recording of a crowded rook w/ multiple conversations going on at the same time. Regards, Alan Jason Dillon wrote: Okay, well so far no one objected... so I am going to look into how we can get this setup. --jason On 5/31/06, Jason Dillon [EMAIL PROTECTED] wrote: Since Apache tends to prefer mailing lists... but IRC is so convent for effective communication. Maybe we should have a daily post of the last days IRC log to the dev list. That was the list can still be used for oversight of stuff that goes on in #geronimo that may have some impact on the project and its health. Just a thought... --jason
[jira] Commented: (AMQ-630) After broker has shutdown, cannot shutdown a client application
[ https://issues.apache.org/activemq/browse/AMQ-630?page=comments#action_36266 ] james strachan commented on AMQ-630: BTW have you tried setting a fairly aggresive closeTimeout value? (e.g. like 500 milliseconds) http://activemq.org/site/connection-configuration-uri.html After broker has shutdown, cannot shutdown a client application --- Key: AMQ-630 URL: https://issues.apache.org/activemq/browse/AMQ-630 Project: ActiveMQ Type: Bug Versions: 4.0 M4 Reporter: Kieran Murphy Assignee: Hiram Chirino Fix For: 4.1 1. Bring up a broker 2. Bring up a client application which connects to the broker 3. Stop the broker. 4. Now try to stop the client app -- it will not shutdown until the broker is restarted. Using failover:tcp to connect to 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
Frozen Branch 24-hour notice
I've been contacted that my communication skills are lacking on the 1.1 release have been negligent so this note is intended to rectify that observation. Consider this note a 24-hour branch freeze notification. As of now NO NEW FEATURES NO COSMETIC CHANGES BUG FIXES RELATED TO JIRA ENTRIES...if you find a bug...open a JIRA Any changes made to branches 1.1 after 24-hours can be reverted without notice. I will cut a build candidate tomorrow after the 24-hour notice which will incorporate the changes documented about the 1.1 release. If you are confused, have comments or would like clarification please post to the dev list and not my private e-mail. Thanks. Matt
Re: Reorganizing javamai (revisited)
Alan D. Cabrera wrote:
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached a
consensus on what should be done but the work was put off until after
1.1 shipped. Since then, I have a new factor to introduce into this
discussion, so I want to make sure we've got good agreement on what
needs to be done. To refresh, I proposed that the javamail code
needed to be reorganized so that the javamail-transport jar (which is
currently part of the Geronimo build) is separated from Geronimo and
available with the geronimo-javamail-spec jar. The consensus seemed
to lean toward the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is going
to need to be kept around, since it's required to pass the tck. The
javamail 1.4 jar can't be used, since it will fail the tck signature
tests. It looks like the best approach here would be to rename the
existing javamail spec module to geronimo-javamail-spec-1.3 and
introduce a new geronimo-javamail-spec-1.4 module to create the
other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4 versions
of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
So, in light of the other conversation going on with the 1.3.1 spec jar
version, can I assume the version number for the 1.4 spec jar should be
1.2-SNAPSHOT also, and the provider jars (and the uber jars), because
they're in a new repo should start out at 1.0-SNAPSHOT?
Rick
Regards,
Alan
[jira] Commented: (AMQ-738) Broker does not recognize failed broker upon reconnect
[
https://issues.apache.org/activemq/browse/AMQ-738?page=comments#action_36267 ]
Christopher G. Stach II commented on AMQ-738:
-
Here's the broker config:
?xml version=1.0 encoding=UTF-8?
beans xmlns:amq=http://activemq.org/config/1.0;
bean
class=org.springframework.beans.factory.config.PropertyPlaceholderConfigurer
property name=location
valueclasspath:/application.properties/value
/property
property name=systemPropertiesModeName
valueSYSTEM_PROPERTIES_MODE_OVERRIDE/value
/property
/bean
amq:broker brokerName=${amq.brokerName} useJmx=false
amq:networkConnectors
amq:networkConnector
urimulticast://${amq.serviceName}/uri
/amq:networkConnector
/amq:networkConnectors
amq:persistenceAdapter
amq:journaledJDBC
dataDirectory${java.io.tmpdir}/${amq.dataDir}/dataDirectory
journalLogFiles2/journalLogFiles
/amq:journaledJDBC
/amq:persistenceAdapter
amq:transportConnectors
amq:transportConnector
urivm://${amq.brokerName}/uri
/amq:transportConnector
amq:transportConnector
discoveryUrimulticast://${amq.serviceName}/discoveryUri
uritcp://${amq.bindAddress}:${amq.bindPort}/uri
/amq:transportConnector
/amq:transportConnectors
/amq:broker
/beans
Broker does not recognize failed broker upon reconnect
--
Key: AMQ-738
URL: https://issues.apache.org/activemq/browse/AMQ-738
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Reporter: Christopher G. Stach II
After normal shutdown of a broker and bring it back up, the first broker
reports this error:
[11:07:15.162] Establishing network connection between from
vm://app1-test?network=true to tcp://10.xxx:49995
[11:07:15.165] Starting a network connection between vm://app1-test#20 and
tcp://null:0 has been established.
[11:07:15.294] Async error occurred: javax.jms.InvalidClientIDException:
Broker: app1-test - Client: NC_app2-test_inboundapp1-test already connected
[11:07:15.294] javax.jms.InvalidClientIDException: Broker: app1-test -
Client: NC_app2-test_inboundapp1-test already connected
[11:07:15.294] at
org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:176)
[11:07:15.294] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:69)
[11:07:15.294] at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:69)
[11:07:15.294] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:69)
[11:07:15.294] at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:82)
[11:07:15.294] at
org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:507)
[11:07:15.294] at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:118)
[11:07:15.294] at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:201)
[11:07:15.294] at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
[11:07:15.294] at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:97)
[11:07:15.294] at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:63)
[11:07:15.294] at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:76)
[11:07:15.294] at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44)
[11:07:15.294] at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
[11:07:15.294] at
org.apache.activemq.network.DemandForwardingBridgeSupport.startLocalBridge(DemandForwardingBridgeSupport.java:192)
[11:07:15.294] at
org.apache.activemq.network.DemandForwardingBridgeSupport$3.run(DemandForwardingBridgeSupport.java:162)
[11:07:15.327] Network connection between vm://app1-test#20 and
tcp://app2.xxx/10.xxx:49995(app2-test) has been established.
[11:07:15.347] Unexpected local command: ConnectionError {commandId = 2,
responseRequired = false, connectionId = null, exception =
javax.jms.InvalidClientIDException: Broker: app1-test - Client:
NC_app2-test_inboundapp1-test already connected}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
DayTrader: Dynamic Ajax-based Web frontend --- update
Hey, I just wanted to send a quick follow up on previous note I sent out about adding a dynamic Web 2.0 interface to DayTrader. Progress has been slow due to other emergencies, but I should have some demo-able code to offer within a couple of weeks. The stock trading theme of DayTrader is perfect for a rich, asynchronous, AJAX based front end. The idea got good support before and I think this will add alot to Geronimo as a sample application. I'm specifically interested in doing some performance analysis to compare the overhead of Web 2.0 over standard request/response style. The original note with the basic design is below. Again, I hope to have some code soon. Stan. J. Stan Cox [EMAIL PROTECTED] Original note: -- Geronimos, I'm one of the original developers of the benchmark Trade that has been donated to Geronimo and is now known as DayTrader. It's amazing what this benchmark has been able to achieve over the last few years and we are very much looking forward to seeing it grow and flourish in the Open Source Geronimo environment. We think it can become a real showcase for Geronimo's performance and capabilities. We are interested in adding a rich, AJAX based Web interface for the DayTrader stock trading services. DayTrader is a perfect type of application to leverage AJAX capablities. We plan to collapse all of the current web pages into a single rich page with dynamic and asynchronous updates of stock prices, user holdings, buys/sells, etc. We would leverage the DoJo AJAX toolkit which is being pulled into Apache MyFaces. So, the basic architecture would look like: browser--- REST--- DayTrader---SOAP--- DayTrader--- Java--- DayTrader (dojo libs, proxy servlet Web services J2EE App javascript) soap/rest transform |--GERONIMO ---| Stan. J. Stan Cox [EMAIL PROTECTED]
[jira] Updated: (GERONIMO-1583) Servlet web service is created once and destroyed many times
[ http://issues.apache.org/jira/browse/GERONIMO-1583?page=all ] Matt Hogstrom updated GERONIMO-1583: Fix Version: 1.1.1 (was: 1.1) (was: 1.2) Servlet web service is created once and destroyed many times Key: GERONIMO-1583 URL: http://issues.apache.org/jira/browse/GERONIMO-1583 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1.1 I deployed a servlet-based web service that implements ServiceLifecycle. I called another servlet that invoked the web service three times (calling one method once and a different method twice). I put printlns in the init and destroy methods and got: Web Services Servlet initialized Web Services Servlet destroyed Web Services Servlet destroyed Web Services Servlet destroyed I don't know if it was the same instance or different instances, but I assume it should not be destroyed more often than it is initialized. -- 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: Plugin versioning problems
On Jun 8, 2006, at 9:12 AM, Aaron Mulder wrote:
Well, if you're going to submit that patch, you need to include a
change in the annotation in the plugin schema along with it -- it
specifically says that field is an exact match.
I'm still not sure I'm on board with this, though. I don't feel like
we can say with confidence that a plugin that works in 1.1 will work
in all 1.1.x releases. Perhaps if we can articulate the rules for
what changes are acceptable for 1.1, and that implies that plugins
shouldn't break, then I'd feel more comfortable with this. We'd also
have to release 1.1 as 1.1.0 so that if you *wanted* to limit it to
the initial 1.1 release, you could.
I'm not sure I'm on board with the plugins claiming knowledge of who
can use it and what versions they are -- seems backwards to me. I'd
rather see each new Geronimo or Geronimo-based platform version
maintain a list of plugins and their versions known to work (and that
list should be updatable post-release). In other words, why not have
the platform track the compatiable plugins rather than the plugins
tracking the compatible platforms?
In either case, a user should be able to say I don't care, just do
it if versions don't match up.
It's somewhat a half a dozen of one or six of the other type of
problem, but in the end i'd opt for making things as easy as possible
for plugin developers even if it makes things more complicated for
us. Ideally, users would make plugins out of everything and go
plugin crazy.
For now, I'd be fine with non-exact matching in the manner proposed.
Maybe with the addition of a wiki page for each plugin where people
can document known compatibility issues.
My $0.02
-David
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
I definitely agree that a full fledged solution for version ranges is
out of scope for G 1.1.x. I was thinking that a minor change to the
plugin installer's version checking could at least partially address
Donald's concerns and also avoid the version mismatch problem Dave C.
found in the candidate build. Here's a patch that makes the plugin
installer only check the digits of geronimo's version that the
plugin's xml specifies. So if the plugin specifies
geronimo-version1.1/geronimo-version then it can be installed
into
1.1, 1.1-SNAPSHOT, 1.1-rc1, etc...
Best wishes,
Paul
Index: modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java
===
--- modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java (revision
412744)
+++ modules/system/src/java/org/apache/geronimo/system/plugin/
PluginInstallerGBean.java (working
copy)
@@ -1409,7 +1409,7 @@
if(gerVersion == null || gerVersion.equals()) {
throw new IllegalStateException(geronimo-version
should not be empty!);
}
-if(gerVersion.equals(version)) {
+if(version.startsWith(gerVersion)) {
match = true;
break;
}
On 6/8/06, Aaron Mulder [EMAIL PROTECTED] wrote:
Perhaps I was unclear; I didn't mean to say this was a bad idea,
only
that our code doesn't currently support it. I expect version
ranges
are on the road map, but if you want to work on them, you're
more than
welcome to. :)
I don't think this is a G 1.1.x discussion, since AFAIK it would
require kernel changes.
Thanks,
Aaron
On 6/8/06, Paul McMahan [EMAIL PROTECTED] wrote:
On 6/8/06, Donald Woods [EMAIL PROTECTED] wrote:
What I meant by 1.1.* was the Maven behavior of private
builds like
1.1-1 being taken as newer than 1.1. Also, being able to
use the
behavior of 1.1-starting with any alpha is less than 1.1.
Basically,
I should be able to specify 1.1 in the plugin and have it
work on
1.1-SNAPSHOT and 1.1.1. If a plugin worked on 1.1 but
doesn't on 1.1.1,
then I'd argue that we broke something in 1.1.1, given it
should only be
a maintenance release and app/plan breaking changes should
only go into 1.2.
+1 This approach is similar to how eclipse plugin versioning
works.
From http://www.eclipse.org/equinox/documents/plugin-
versioning.html :
How to specify plug-in requirements
Plug-ins that require other plug-ins must qualify their
requirements
with a version range since the absence of a version range
means that
any version can satisfy the dependency. Given that all the
changes
between the version x.0.0 and the version x+1.0.0 excluded
must be
compatible (given the previous guidelines); the recommended range
includes the minimal required version up-to but not including
the next
major release.
IMHO geronimo should adopt eclipse's strategy for plugin
versioning
where possible since the two sets of base requirements are quite
similar and eclipse is a few years ahead in this area. The
[jira] Updated: (GERONIMO-1584) Servlet web service WSDL mangling has http://host:port//path
[ http://issues.apache.org/jira/browse/GERONIMO-1584?page=all ] Matt Hogstrom updated GERONIMO-1584: Fix Version: 1.1.1 (was: 1.1) (was: 1.2) Servlet web service WSDL mangling has http://host:port//path Key: GERONIMO-1584 URL: http://issues.apache.org/jira/browse/GERONIMO-1584 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1.1 The URL specified in a WSDL service is totally ignored for a servlet-based web service, which is fine. Further, the WSDL is mangled so that when access at (service URL)?wsdl the correct URL to the service is provided. However, when this is done, an additional slash is inserted into the URL: wsdlsoap:address location=http://localhost:8080//context/path-to-service/ There should only be one slash after the port. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2094) All geronimo jars and distributions should include at least the required LICENSE and NOTICE files
All geronimo jars and distributions should include at least the required LICENSE and NOTICE files - Key: GERONIMO-2094 URL: http://issues.apache.org/jira/browse/GERONIMO-2094 Project: Geronimo Type: Task Security: public (Regular issues) Components: general Versions: 1.0 Reporter: Guillaume Nodet Priority: Critical Fix For: 1.1 The presence of the LICENSE and NOTICE files are a legal requirements for all ASF software published. For distributions, they must be in the root folder. For jars publicly available (via maven repos), they should be in the META-INF dir. Also, the distributions should include third party licenses for included jars. -- 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: Reorganizing javamai (revisited)
Rick McGuire wrote:
Alan D. Cabrera wrote:
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached a
consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that the
javamail code needed to be reorganized so that the
javamail-transport jar (which is currently part of the Geronimo
build) is separated from Geronimo and available with the
geronimo-javamail-spec jar. The consensus seemed to lean toward the
following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the tck
signature tests. It looks like the best approach here would be to
rename the existing javamail spec module to
geronimo-javamail-spec-1.3 and introduce a new
geronimo-javamail-spec-1.4 module to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4
versions of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
So, in light of the other conversation going on with the 1.3.1 spec
jar version, can I assume the version number for the 1.4 spec jar
should be 1.2-SNAPSHOT also, and the provider jars (and the uber
jars), because they're in a new repo should start out at 1.0-SNAPSHOT?
I'm not sure why we would tie the spec jars and the provider jar
versions together. I just reread your proposal w/ a more careful
attention to the version macros. We might want to restate the proposal:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamail13Version} jar file,
which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamail14Version} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only contained
smtp, but now that it also has Store providers, it doesn't really fit).
This will have two modules for the 1.3 and 1.4 versions of the
providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamail13Version}
and geronimo-javamail_1.4_provider-${geronimoProviderJavamail14Version}
jar files.
4) Additionally, the javamail-provider build will create two uber-jars
containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamail13Version} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamail14Version}
geronimoSpecsJavamail13Version=1.2-SNAPSHOT
geronimoSpecsJavamail14Version=1.0-SNAPSHOT
geronimoProviderJavamail13Version=1.0-SNAPSHOT
geronimoProviderJavamail14Version=1.0-SNAPSHOT
Thoughts?
Regards,
Alan
[jira] Created: (GERONIMO-2095) Problem with attribute manager
Problem with attribute manager -- Key: GERONIMO-2095 URL: http://issues.apache.org/jira/browse/GERONIMO-2095 Project: Geronimo Type: Bug Security: public (Regular issues) Components: core Environment: http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz Windows XP, cygwin Command line: java -jar bin/server.jar Free disk space: 3 Gb Reporter: Guillaume Nodet Priority: Critical Fix For: 1.1 [EMAIL PROTECTED] /cygdrive/c/tmp/geronimo-1.1-20060607 $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.5.0_06)... Starting Geronimo Application Server v1.1-20060607 [** ] 30% 21s Starting geronimo/system-database...20:32:49,484 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [** ] 84% 39s Starting geronimo/webconsole-jett...20:33:07,890 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [**] 100% 45s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-20060607/car RAR: geronimo/activemq/1.1-20060607/car RAR: geronimo/system-database/1.1-20060607/car WAR: geronimo/remote-deploy-jetty/1.1-20060607/car WAR: geronimo/welcome-jetty/1.1-20060607/car Web Applications: http://guillaumes:8080/ http://guillaumes:8080/console http://guillaumes:8080/console-standard http://guillaumes:8080/remote-deploy Geronimo Application Server started 20:33:18,718 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) -- 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-2095) Problem with attribute manager
[ http://issues.apache.org/jira/browse/GERONIMO-2095?page=comments#action_12415401 ] Guillaume Nodet commented on GERONIMO-2095: --- Content of var/config dir when boot is finished: [EMAIL PROTECTED] /cygdrive/c/tmp/geronimo-1.1-20060607/var/config $ ll total 21K -rwx--+ 1 gnodet None 1.2K Jun 7 09:20 README.txt* -rwx--+ 1 gnodet None 5.4K Jun 7 09:20 config.xml.original* -rwxrwxrwx 1 gnodet None 4.5K Jun 8 20:34 config.xml.working* -rwx--+ 1 gnodet None 240 Jun 7 09:20 offline-deployer-list* Problem with attribute manager -- Key: GERONIMO-2095 URL: http://issues.apache.org/jira/browse/GERONIMO-2095 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core Environment: http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz Windows XP, cygwin Command line: java -jar bin/server.jar Free disk space: 3 Gb Reporter: Guillaume Nodet Priority: Critical Fix For: 1.1 [EMAIL PROTECTED] /cygdrive/c/tmp/geronimo-1.1-20060607 $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.5.0_06)... Starting Geronimo Application Server v1.1-20060607 [** ] 30% 21s Starting geronimo/system-database...20:32:49,484 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [** ] 84% 39s Starting geronimo/webconsole-jett...20:33:07,890 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [**] 100% 45s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-20060607/car RAR: geronimo/activemq/1.1-20060607/car RAR: geronimo/system-database/1.1-20060607/car WAR: geronimo/remote-deploy-jetty/1.1-20060607/car WAR: geronimo/welcome-jetty/1.1-20060607/car Web Applications: http://guillaumes:8080/ http://guillaumes:8080/console http://guillaumes:8080/console-standard http://guillaumes:8080/remote-deploy Geronimo Application Server started 20:33:18,718 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) -- 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: Reorganizing javamai (revisited)
Alan D. Cabrera wrote:
Rick McGuire wrote:
Alan D. Cabrera wrote:
Rick McGuire wrote:
I brought this up a couple of months ago, and I believe we reached
a consensus on what should be done but the work was put off until
after 1.1 shipped. Since then, I have a new factor to introduce
into this discussion, so I want to make sure we've got good
agreement on what needs to be done. To refresh, I proposed that
the javamail code needed to be reorganized so that the
javamail-transport jar (which is currently part of the Geronimo
build) is separated from Geronimo and available with the
geronimo-javamail-spec jar. The consensus seemed to lean toward
the following approach:
1) keep the javamail spec jar/build the way it is.
2) create a separate repository for the javamail-transport module
and continue to build a javamail-transport jar file.
3) as part of the javamail-transport build, also build an uber-jar
that combines the spec jar and the transport jar.
I think this will work ok, but I think a slight modification is
required. Over the last couple of days, I created a javamail 1.4
version of the spec jar, with the intent that this version could be
made an optional plugin. However, the javamail 1.3 spec jar is
going to need to be kept around, since it's required to pass the
tck. The javamail 1.4 jar can't be used, since it will fail the
tck signature tests. It looks like the best approach here would be
to rename the existing javamail spec module to
geronimo-javamail-spec-1.3 and introduce a new
geronimo-javamail-spec-1.4 module to create the other version.
In lock-step with that, there are some dependencies between the
transport jar file and the corresponding spec version. So the
transport repository will also need modules to build the matching
provider jar.
So, given all that, here's what I think should be done:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build
a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it
doesn't really fit). This will have two modules for the 1.3 and
1.4 versions of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion}
and
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
Rick
+1 Sounds good!
So, in light of the other conversation going on with the 1.3.1 spec
jar version, can I assume the version number for the 1.4 spec jar
should be 1.2-SNAPSHOT also, and the provider jars (and the uber
jars), because they're in a new repo should start out at 1.0-SNAPSHOT?
I'm not sure why we would tie the spec jars and the provider jar
versions together. I just reread your proposal w/ a more careful
attention to the version macros. We might want to restate the proposal:
1) rename the geronimo-spec-javamail module to
geronimo-spec-javamail-1.3. This already builds a
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamail13Version} jar
file, which is what we want.
2) create a new geronimo-spec-javamail-1.4 module, which will build a
geronimo-javamail_1.4_spec-${geronimoSpecsJavamail14Version} jar file.
3) create a new javamail-provider repository (note the name
change...javamail-transport might have made sense when it only
contained smtp, but now that it also has Store providers, it doesn't
really fit). This will have two modules for the 1.3 and 1.4 versions
of the providers, and will build
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamail13Version}
and
geronimo-javamail_1.4_provider-${geronimoProviderJavamail14Version}
jar files.
4) Additionally, the javamail-provider build will create two
uber-jars containing the specs and providers combined:
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamail13Version} and
geronimo-javamail_1.4_mail-${geronimoProviderJavamail14Version}
geronimoSpecsJavamail13Version=1.2-SNAPSHOT
geronimoSpecsJavamail14Version=1.0-SNAPSHOT
geronimoProviderJavamail13Version=1.0-SNAPSHOT
geronimoProviderJavamail14Version=1.0-SNAPSHOT
Thoughts?
I'm pretty much in agreement, except possibly for the value of
geronimoSpecsJavamail14Version. I thought the reason why you wanted my
recent changes labeled 1.2-SNAPSHOT was to tie it to the repos version.
That would sort of suggest that geronimoSpecsJavamail14Version should
start out with 1.2 to tie to
Re: RELEASE-NOTES-1.1
Hernan Cunico wrote: Hi All, I updated the release notes and it is ready for your review and comments, here is the link http://cwiki.apache.org/GMOxDOC11/release-notes-11txt.html Cheers! Hernan Thanks Hernan! A few comments: 1) In section Installing and Starting Geronimo Suspect the geronimo.sh reference should be ./geronimo.sh 2) In section Significant Changes -Shared Library Support -Statement Cache for JDBC drivers -Dynamic Plugin support -In-place deployment of exploded applications -Dependent Package Upgrades (Tomcat, Jetty, etc.) 3)Also, probably want a new section on Migrating applications from previous releases that references the existence of the Upgrade tool that David J has created (and Lin is documenting) and any other major differences that existing users will need to know. It should link to any other migration documentation that we have. Thanks -Dave-
Re: [Build error] - I can not build a freash copy of r411545
Hello Mohammed, The Specs are built using Maven 2. The command is mvn install. Unfortunately we're using two versions of Maven right now. The conversion from Maven 1 to Maven 2 is ongoing in Geronimo right now. Mohammed Nour wrote: Hi Matt... I did what you told me to do, I ceched out the specs, built them using *maven install* command, tryied to build G again but failed with the same error of ClassNotFoundException. I am trying to trace this error, but anybody knows about the solution of this problem please help? I would like to mention that I am using: WindowsXP, Java 1.4.2_11, Maven 1.1b2 --- Never give up, Never... --- *Thanks and best regards Mohammad Nour El-Din * On 6/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Mohammed, You need to checkout the spec independent of Geronimo. Do an svn co http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 cd to that directory and execute: mvn install This will update your specs and you should be good to go. Matt Mohammed Nour wrote: Hi All... I failed again to build a brand new fresh copy og *G,* and here is the link of the build error http://rifers.org/paste/show/886 -- Never give up, Never... -- *Thanks and best regards...* *Mohammad Nour El-Din* On 6/5/06, Bryan Noll [EMAIL PROTECTED] wrote: Mohammad, I was having the same issue you were just the other day. I got it to work by doing the following: maven -Dmaven.test.skip -Dmaven.itest.skip David Jencks wrote: On Jun 4, 2006, at 6:58 AM, Mohammed Nour wrote: Hi All... I've been struggling too long trying to building G, but all my tries failed. I got a fresh copy of r411545 and got the following error while trying to build it http://rifers.org/paste/show/877 I talked with djencks on IRC and he ask me to try building TrnaQl and OEJB separatly and then try to build G again, but while I am trying to build OEJB I got the following error http://rifers.org/paste/show/878 All the parts of openejb that are known to build, built for you. We are currently only using core, openejb-builder, and pkgen-builder. I'm afraid that I am so used to how I build openejb from within geronimo I forget that there are other ways. What I do is check out openejb inside geronimo using maven m:co which checks out the correct version (2.1-SNAPSHOT at the moment) and build it using maven new2 What command did you use? In any case you should be able to proceed with your geronimo build now. Hope this helps, david jencks so please help. --- Never give up, Never... --- *Thanks and best regards* *Mohammad Nour El-Din*
Re: [Build error] - I can not build a freash copy of r411545
Hi All... I succeeded to pass the point of build error bybypassing building both daytrader and servlet-examples projects. But I got another error in the assembly phase because of path is too long, which is a Windows problem. Is there any work-around to overcome this problem other than making another copy of G source to be more shalow on the dir heirarchy of Windows directories ??? ---Never give up, Never...---Thanks and best regardsMohammad Nour El-Din On 6/8/06, Mohammed Nour [EMAIL PROTECTED] wrote: Hi Matt... I did whatyou told me to do, I ceched out the specs, built them using maven install command, tryied to build G again but failed with the same error of ClassNotFoundException. I am trying to trace this error, but anybody knows about the solution of this problem please help? I would like to mention that I am using: WindowsXP, Java 1.4.2_11, Maven 1.1b2 ---Never give up, Never...---Thanks and best regardsMohammad Nour El-Din On 6/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Mohammed,You need to checkout the spec independent of Geronimo.Do ansvn co http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1cd to that directory and execute:mvn installThis will update your specs and you should be good to go.MattMohammed Nour wrote: Hi All... I failed again to build a brand new fresh copy og *G,* and here is the link of the build error http://rifers.org/paste/show/886 -- Never give up, Never... -- *Thanks and best regards...* *Mohammad Nour El-Din* On 6/5/06, Bryan Noll [EMAIL PROTECTED] wrote: Mohammad, I was having the same issue you were just the other day.I got it to work by doing the following: maven -Dmaven.test.skip -Dmaven.itest.skip David Jencks wrote: On Jun 4, 2006, at 6:58 AM, Mohammed Nour wrote:Hi All... I've been struggling too long trying to building G, but all my tries failed. I got a fresh copy of r411545 and got the following error while trying to build it http://rifers.org/paste/show/877 I talked with djencks on IRC and he ask me to try building TrnaQl and OEJB separatly and then try to build G again, but while I am trying to build OEJB I got the following error http://rifers.org/paste/show/878 All the parts of openejb that are known to build, built for you.We are currently only using core, openejb-builder, and pkgen-builder.I'm afraid that I am so used to how I build openejb from within geronimo I forget that there are other ways. What I do is check out openejb inside geronimo using maven m:co which checks out the correct version (2.1-SNAPSHOT at the moment) and build it using maven new2 What command did you use? In any case you should be able to proceed with your geronimo build now. Hope this helps, david jencks so please help. --- Never give up, Never... --- *Thanks and best regards* *Mohammad Nour El-Din*
Re: Deploy ServiceMix 3.0 on JBoss
The jboss deployer for servicemix 3.0 is available at Codehaus. See http://servicemix.goopen.org/site/source.html to access the sources. We do not have binaries available, so you will have to compile it (using maven 1). Cheers, Guillaume Nodet On 6/8/06, OscarGhersi [EMAIL PROTECTED] wrote: Hi, I'm new to ServiceMix and I'm trying to use it in 3.0 version on JBoss 4.0.3, but I've found some problems. I've tried to follow the instructions on http://servicemix.org/site/jboss-deployer.html, but I couldn't succeed to install the maven-sar-plugin (I'm using Maven version 2.0.4). Then I've took the 2.0 version of the JBoss Deployer to see what files are in it, to build a similar .sar with 3.0 version of ServiceMix, but the jars (and the classes too) are very different from 2.0 version. Anyone can give me some infos how to solve my problem or where I can find some tips? Thanks in advance. -- View this message in context: http://www.nabble.com/Deploy-ServiceMix-3.0-on-JBoss-t1754562.html#a4770650 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: [RTC] ActiveMQ GBean modules
On Jun 8, 2006, at 8:17 AM, Hiram Chirino wrote: So in terms the of the RTC process, is this RTC patch dead since it did not get the 3 +1's I'll say it again, please attach the patch to a jira and I will be happy to review it. I don't think changes of this size should occur without a jira for tracking purposes. thanks david jencks I kinda would have preferred to get some -1's instead of not getting any comments on the patch. Is it that there are not enough folks that are interested in the activemq integration aspects of geronimo? Regards, Hiram On 6/6/06, Hiram Chirino [EMAIL PROTECTED] wrote: m2 poms are included in the patch. But for some reason the current m2 build does not seem to let you run mvn from a submodule, some dependency variables do not get evaluated. weird. On 6/5/06, David Jencks [EMAIL PROTECTED] wrote: On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote: Howdy folks, Here's a patch that brings in the activemq gbean modules into geronimo. It's partly what was in activemq 4.x and integrated into geronimo 1.2-dead merged with the changes in the 3.x branch. It compiles at least and looks like a reasonable start. Once further integration work gets done we may need to tweak a little more. here's my +1 got get this committed. I guess I just need 3 more. I'd find it a lot easier to review, apply, and test this patch if you attached it to a jira entry. Is there any chance of you coming up with a pom.xml for the m2 build? thanks david jencks -- Regards, Hiram -- Regards, Hiram
Questions about specs builds and versions
I have some questions and concerns about the specs modules. I hope these concerns are caused by my not knowing where to look and what to look at. 1. IIUC we just released some specs out of tags/1.1 that have versions 1.0.1.How did this happen, why, and does anyone think it is a good idea? As you may be able to tell I think its a really bad idea. How can we release a 1.1 version of these specs in the future? Is there anything we can do about this? 2. Are these specs actually released? Did we vote on them? Are they in an accessible m2 repo somewhere? The m2 build of geronimo trunk (1.2-SNAPSHOT, currently) doesn't work reliably because it can't download the poms for the specs in their new versions. Thanks david jencks
Re: RELEASE-NOTES-1.1
Erin Mulder wrote: Hernan Cunico wrote: I updated the release notes and it is ready for your review Looks good! A few comments: 1) Under system requirements, I think it should mention that Geronimo will run fine on Java 5 out of the box, and offer the caveats that it is only J2EE-certified on 1.4 and that in particular, you will need to run under 1.4 if you enable CORBA support. Could you work on a line or two to reword this section? Not too sure how to word it as we are telling we certified for 1.4 but it works fine with Java 5 2) Under Administration Console Security Configuration, it should mention that the username/password can be changed within the console itself. e.g. This can be changed through the console (in the Security - Console Realm section) or by editing geronimo_home/var.. DONE 3) Looks like there's a typo in the Deploying Applications section. It says geronimo_home/bin/java -jar. instead of just java -jar. Where is the typo? you mean we should not mention the directory here? 4) In that same section, perhaps worth mentioning that you can run the login command in the deployer tool and not have to enter the password over and over. It's kind of a minor detail, but constant retyping of passwords could ruin the deployment experience for people. DONE. Login is a nice feature while testing although for production users may want to keep more control on the actual user deploying the apps. 5) Under Choice of Web container, it sounds a little open-ended to say Please download the binary appropriate for your environment. People will wonder what it is that makes one or the other appropriate for their environment. Not sure how to say it better, but perhaps indicate that choosing one at random is fine if you or your company don't already have a preference? This is pretty much untouched from the previous release notes. I rephrased it a little bit but still is lacking of a good speech for choosing one container over the other. We have the same problem in the documentation, any ideas on how to better articulate the pros and cons? Cheers, Erin Thanks for the comments. Cheers! Hernan
[jira] Commented: (GERONIMO-2095) Problem with attribute manager
[ http://issues.apache.org/jira/browse/GERONIMO-2095?page=comments#action_12415417 ] Paul McMahan commented on GERONIMO-2095: The problem must be environmental because I'm not able to recreate it on linux using JDK 1.4.2. As a test I changed a property of the SystemDatasource pool in the db portlet, restarted G, and verified that my changes had been persisted. After the restart here's what I see: [EMAIL PROTECTED]:~/tmp/geronimo-1.1-20060607$ ls -l var/config/ total 32 -rw-r--r-- 1 pmcmahan pmcmahan 6712 2006-06-08 15:54 config.xml -rw-r--r-- 1 pmcmahan pmcmahan 6435 2006-06-08 15:51 config.xml.bak -rw-r--r-- 1 pmcmahan pmcmahan 5494 2006-06-07 03:20 config.xml.original -rw-r--r-- 1 pmcmahan pmcmahan 240 2006-06-07 03:20 offline-deployer-list -rw-r--r-- 1 pmcmahan pmcmahan 1157 2006-06-07 03:20 README.txt [EMAIL PROTECTED]:~/tmp/geronimo-1.1-20060607$ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1-20060607 [**] 100% 62s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-20060607/car RAR: geronimo/activemq/1.1-20060607/car RAR: geronimo/system-database/1.1-20060607/car WAR: geronimo/remote-deploy-jetty/1.1-20060607/car WAR: geronimo/welcome-jetty/1.1-20060607/car Web Applications: http://localhost:8080/ http://localhost:8080/console http://localhost:8080/console-standard http://localhost:8080/remote-deploy Geronimo Application Server started Problem with attribute manager -- Key: GERONIMO-2095 URL: http://issues.apache.org/jira/browse/GERONIMO-2095 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core Environment: http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz Windows XP, cygwin Command line: java -jar bin/server.jar Free disk space: 3 Gb Reporter: Guillaume Nodet Priority: Critical Fix For: 1.1 [EMAIL PROTECTED] /cygdrive/c/tmp/geronimo-1.1-20060607 $ java -jar bin/server.jar Booting Geronimo Kernel (in Java 1.5.0_06)... Starting Geronimo Application Server v1.1-20060607 [** ] 30% 21s Starting geronimo/system-database...20:32:49,484 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [** ] 84% 39s Starting geronimo/webconsole-jett...20:33:07,890 ERROR [LocalAttributeManager] Error saving attributes java.io.IOException: EXTREMELY CRITICAL! Unable to move manageable attributes working file to proper file name! Configuration will revert to defaults unless t his is manually corrected! (could not rename C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to C:\tmp\geronimo-1.1-20060607\var\config\config.xml) at org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449) at org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) [**] 100% 45s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-20060607/car RAR: geronimo/activemq/1.1-20060607/car RAR: geronimo/system-database/1.1-20060607/car WAR: geronimo/remote-deploy-jetty/1.1-20060607/car WAR:
[jira] Closed: (GERONIMO-1425) access to unprotected web resource after login does not use correct Subject
[ http://issues.apache.org/jira/browse/GERONIMO-1425?page=all ] David Jencks closed GERONIMO-1425: -- Fix Version: 1.1 1.2 (was: Verification Required) Resolution: Fixed Merged from dead-1.2 into 1.1/1.2 branches access to unprotected web resource after login does not use correct Subject --- Key: GERONIMO-1425 URL: http://issues.apache.org/jira/browse/GERONIMO-1425 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Tomcat, web Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1, 1.2 This applies to both jetty and tomcat. Currently we are installing the correct authenticated Subject in ContextManager only when you access a protected resource. For any access to unprotected resources, even after logon, we are installing the default Subject in the ContextManager. This appears to violate this from servlet spec 2.4 12.7: A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJBTM container. After logon, the security identity of the user is known, whether or not they are visiting a protected resource. Therefore the default is to use this identity in ejb calls, which for us requires putting the authenticated subject in the ContextManager. Alan Cabrera has some doubts that this spec language actually requires us to implement the default behavior stated here, and I agree that a strict reading does not seem to require this, but IIUC we agree that we should implement this behavior anyway. -- 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: [Build error] - I can not build a freash copy of r411545
Hi Matt... On 6/8/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Hello Mohammed,The Specs are built using Maven 2.The command is mvn install.Unfortunately we're using two versions of Maven right now.The conversion from Maven 1 to Maven 2 is ongoing in Geronimo right now. Yeah I knew that and I built them successfuly using Maven2 version 2.0.4. But I susspect something is wrong, When project.xml file refers to a dependency which is a rar file and this rar file contains a jar file which contains the calss which is needed to compile the code successfuly, how Maven does know which jar of them is the right one to add to the classpath ? Mohammed Nour wrote: Hi Matt... I did what you told me to do, I ceched out the specs, built them using *maven install* command, tryied to build G again but failed with the same error of ClassNotFoundException. I am trying to trace this error, but anybody knows about the solution of this problem please help? I would like to mention that I am using: WindowsXP, Java 1.4.2_11, Maven 1.1b2 --- Never give up, Never... --- *Thanks and best regards Mohammad Nour El-Din * On 6/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Mohammed, You need to checkout the spec independent of Geronimo.Do an svn co http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 cd to that directory and execute: mvn install This will update your specs and you should be good to go. Matt Mohammed Nour wrote: Hi All... I failed again to build a brand new fresh copy og *G,* and here is the link of the build error http://rifers.org/paste/show/886 -- Never give up, Never... -- *Thanks and best regards...* *Mohammad Nour El-Din* On 6/5/06, Bryan Noll [EMAIL PROTECTED] wrote: Mohammad, I was having the same issue you were just the other day.I got it to work by doing the following: maven -Dmaven.test.skip -Dmaven.itest.skip David Jencks wrote: On Jun 4, 2006, at 6:58 AM, Mohammed Nour wrote: Hi All... I've been struggling too long trying to building G, but all my tries failed. I got a fresh copy of r411545 and got the following error while trying to build it http://rifers.org/paste/show/877 I talked with djencks on IRC and he ask me to try building TrnaQl and OEJB separatly and then try to build G again, but while I am trying to build OEJB I got the following error http://rifers.org/paste/show/878 All the parts of openejb that are known to build, built for you.We are currently only using core, openejb-builder, and pkgen-builder.I'm afraid that I am so used to how I build openejb from within geronimo I forget that there are other ways.What I do is check out openejb inside geronimo using maven m:co which checks out the correct version (2.1-SNAPSHOT at the moment)and build it using maven new2 What command did you use?In any case you should be able to proceed with your geronimo build now.Hope this helps, david jencksso please help. --- Never give up, Never... --- *Thanks and best regards* *Mohammad Nour El-Din*
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: configs.patch pom.patch configs.log The configs.patch attached here adds the following configurations : 1. welcome-jetty 2. jsp-examples-jetty 3. servlets-examples-jetty 4. ldap-demo-jetty The pom.patch is for top level, -- adds tomcat-builder module to the list -- changes build order for applications -- adds maven-war-plugin to pluginManagement section configs.log is the list of configs being built. After all the configuraitons are done, will modify packaging-plugin to take care of conf/geronimo-plugin.xmls. 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: configs.log, configs.patch, newconfigs.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: [Build error] - I can not build a freash copy of r411545
On Jun 8, 2006, at 1:19 PM, Mohammed Nour wrote:Hi Matt... On 6/8/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Hello Mohammed,The Specs are built using Maven 2. The command is mvn install. Unfortunately we're using two versions of Maven right now. The conversion from Maven 1 to Maven 2 is ongoing in Geronimo right now. Yeah I knew that and I built them successfuly using Maven2 version 2.0.4. But I susspect something is wrong, When project.xml file refers to a dependency which is a rar file and this rar file contains a jar file which contains the calss which is needed to compile the code successfuly, how Maven does know which jar of them is the right one to add to the classpath ? Is there an error that makes you suspect this?Basically, there is no magic like what you are asking about. A maven dependency on a rar (or war or ear) file can't get anything into any classpath by itself, it just assures that maven will check that the artifact is in your local repo (and maybe fetch it, if you are lucky). The only way to get at the insides of one of these files in geronimo is to deploy it into a module (formerly called configuration) stored in a car file. This contains the jars etc from the rar/war/ear unpacked together with relative path information on how to construct a classloader that can load all the classes. Note that the packaging and assembly plugins run bits of geronimo out of your local maven repository, blurring the distinction between what is done by maven and what by geronimo.Hope this is related to what you were asking :-)thanksdavid jencks
