[jira] Assigned: (AMQ-755) possible bug with temporary queues and networks?
[ https://issues.apache.org/activemq/browse/AMQ-755?page=all ]
Rob Davies reassigned AMQ-755:
--
Assign To: Rob Davies
possible bug with temporary queues and networks?
Key: AMQ-755
URL: https://issues.apache.org/activemq/browse/AMQ-755
Project: ActiveMQ
Type: Bug
Versions: 4.0
Reporter: james strachan
Assignee: Rob Davies
We have been experiencing some fairly serious problems with timeouts using
Spring, Lingo and a network of ActiveMQ brokers.
As I understand it, lingo creates temporary queues to transport the remote
procedure calls across JMS.
We are suspicious that the messaging roundtrip gets interrupted or lost when
using broker networks.
We integrated ActiveMQ 4.0 into our project this week and ran the JMX
jconsole to look at our broker network.
We see temporary queues come and go, and what we are expecting is complete
replication of the queues on each broker. Is this expectation correct?
This is not what we are seeing.
We believe that two things are happening:
1) Temporary queues are not being cleaned up properly on all brokers.
2) Temporary queues are not being created on a new broker when it is taken
down and then restarted.
Your feedback on these apparent issues would be appreciated.
To substantiate our theory we created a couple of JUnit tests. (Our test
cases do not include Lingo - just ActiveMQ client to broker.)
TEST 1
We create a network of brokers, create a message queue, send a message and
then take a broker down. We are expecting that the temporary message queue
created will be removed from both brokers. It is not.
The test fails on the last assert with:
junit.framework.AssertionFailedError: No queues on broker 3 expected:1 but
was:0
Source code follows:
public void testTempQueueCleanup() throws Exception {
ActiveMQConnectionFactory cf;
Connection conn = null;
Session sess = null;
try {
cf = new ActiveMQConnectionFactory(
failover:(tcp://localhost:61626%3FsoTimeout=5000,tcp://localhost:61627%3FsoTimeout=5000)?maximumRetries=0amp;establishConnectionTimeout=21000amp;keepAliveTimeout=30);
conn = cf.createConnection();
sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
TemporaryQueue q = sess.createTemporaryQueue();
BrokerService broker2 = createBroker(broken2,
tcp://localhost:61627, static:(tcp://localhost:61626));
Thread.sleep(5000);
assertEquals(No queues on broker 1, 1,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(No queues on broker 2, 1,
broker2.getAdminView().getTemporaryQueues().length);
q.delete();
assertEquals(Temp queue left behind on broker 1, 0,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(Temp queue left behind on broker 2, 0,
broker2.getAdminView().getTemporaryQueues().length);
broker2.stop();
} finally {
if (sess!=null)
sess.close();
if (conn!=null)
conn.close();
}
}
TEST 2
When stopping a broker and then restarting it, we expect to see all queues
replicated on the new broker.
This test fails with:
junit.framework.AssertionFailedError: No queues on broker 3 expected:1 but
was:0
Source code:
public void testTempQueueRecovery() throws Exception {
ActiveMQConnectionFactory cf;
Connection conn = null;
Session sess = null;
try {
cf = new ActiveMQConnectionFactory(
failover:(tcp://localhost:61626%3FsoTimeout=5000,tcp://localhost:61627%3FsoTimeout=5000)?maximumRetries=0amp;establishConnectionTimeout=21000amp;keepAliveTimeout=30);
conn = cf.createConnection();
sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
TemporaryQueue q = sess.createTemporaryQueue();
BrokerService broker2 = createBroker(broken2,
tcp://localhost:61627,
static:(tcp://localhost:61626,tcp://localhost:61628));
Thread.sleep(5000);
assertEquals(No queues on broker 1, 1,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(No queues on broker 2, 1,
broker2.getAdminView().getTemporaryQueues().length);
BrokerService broker3 = createBroker(broken3,
tcp://localhost:61628,
static:(tcp://localhost:61626,tcp://localhost:61627));
assertEquals(No queues on broker 3, 1,
broker3.getAdminView().getTemporaryQueues().length);
Thread.sleep(5000);
q.delete();
Thread.sleep(5000);
assertEquals(Temp queue left behind on broker 1, 0,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(Temp queue left behind on broker 2, 0,
broker2.getAdminView().getTemporaryQueues().length);
assertEquals(Temp queue left behind on broker 3, 0,
broker3.getAdminView().getTemporaryQueues().length);
broker3.stop();
broker2.stop();
} finally {
if (sess!=null)
sess.close();
if (conn!=null)
Which Open Source MOM to opt for
HI, I am in the hunt of an Open source MOM ... I am not sure which one is widely popular and best. Kindly suggest a location which could give me a comparison for the various open source MQ options available. It should have C++ support. Can anybody tell me why we should use ActiveMQ ... what are the prime benefits of this MOM please. Thanks in advance Lalit ... -- View this message in context: http://www.nabble.com/Which-Open-Source-MOM-to-opt-for-t1822112.html#a4968969 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: AMQP
+1 ! BTW IMO the spec is still fuzzy. I think they need to clarify it a bit more. But I think it's something we should be able to implement really easy. On 6/20/06, Brian McCallister [EMAIL PROTECTED] wrote: FYI: http://www.infoq.com/news/amq AMQP looks to be an attempt at wire protocol specification like openwire or stomp. Probably good for us to look at, though the licensing probably needs to bounce through [EMAIL PROTECTED] before we do much as it is not immediately clear if it is okay. I probably is, but I'd love to get Cliff's opinion. -Brian -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Re-Release XBean 2.4
On 6/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have pushed new XBean 2.4 binaries in a private repo for review. They are available at http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean http://people.apache.org/~gnodet/xbean-2.4/m2/org/apache/xbean http://people.apache.org/~gnodet/xbean-2.4/site/ If no one objects I will put the binaries in their official distribution repositories by the end of the week +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Derby library does not have line number debug information
+1 John Sisson wrote: The Derby library we are using in Geronimo does not have line number debug information, which is useful in stack traces. This has been addressed in the upcoming Derby 10.1.3 release by providing a lib-debug distribution ( http://issues.apache.org/jira/browse/DERBY-178 ) . I'll raise a JIRA if people think it would be a good idea to use the debug version. Comments? Thanks, John
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
John Sisson wrote: Matt Hogstrom wrote: The corrections applied due to license files are first in this list. Thanks to John for dogging this. The distributions and builds were not affected. Based on previous feedback the vote continues. Thanks for your feedback. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.zip John noted that the source zip had a META-INF. I've created a script to use in the future because with so many changes forgetting to use zip and typing jar is not acceptable. Also, note that the build itself has the LICENSE and NOTICES in two different places. The are located in modules/scripts/src/main/resources/ which put the right files in the distributions however they werenot correctly specified for source as the LICENSE and NOTICES are part of the source tree. After this release we need to address this issue so as to avoid manual problems like this. Thanks for creating the script, it will be helpful to others who may build releases in the future. *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.zip Corrected LICENSE and NOTICES files. Use zip rather than jar to create zip. *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.1.ear Corrected LICENSE and NOTICE files in ear. John, whats the correct command to set the properties? Or, would you like to address these? FYI.. The svn propset command is used to set the properties. If you need to set properties on a single existing file, look at the commands for the appropriate file extension that are used in https://svn.apache.org/repos/asf/geronimo/gbuild/trunk/svnpropset.sh I noticed there are a few files in daytrader without the correct properties (e.g. pom.xml and README.jboss). I can fix this up after the release is out if you like, but I will have to do it to the DT trunk and branches so there aren't problems merging changes. What are the plans for the m2standard branch in Daytrader? If you wouldn't mind that would be most helpful. Thanks. Thanks, John No changes to the below files. *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 now the alterations suggested by John have been completed. David Blevins wrote: +1 On Jun 19, 2006, at 8:33 AM, Matt Hogstrom wrote: Here are the latest binaries built from http://svn.apache.org/repos/asf/geronimo/branches/1.1.0, http://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and http://svn.apache.org/repos/asf/geronimo/daytrader/branches/1.1.0. I believe this will start a new vote for this binary. All issues that I'm aware of have been addressed that needed to be for this release. RELEASE-NOTES-1.1.txt were updated with issues that will be addressed in 1.1.1. *Previous Votes are invalidated...please re-vote* The console has been updated to reflect issues related to bad links. Consensus appears to favor defering the LICENSE issue in the console to 1.1.1 as the correct LICENSE and NOTICES files are included in the builds. DayTrader sources are included with updated README to instruct the user how to build and install DayTrader on Geronimo. Please cast your votes and remember that only PMC member votes are binding. However, I am confident that commiter votes will help to inform the PMC of the quality of this release candidate. Thanks to all that have been checking this out. John Sisson especially has been burning the midnight oil and finding the remaining issues that have helped to improve the quality of this release. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.zip *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.ear Note: to build Geronimo the above ear needs to be placed into your repo as $MAVEN_HOME/repository/geronimo/ears/daytrader-ear-1.1.ear
Update on 1.1 Final2 Voting Status - Tally so far
Here is the current status of voting. I know we've had several issues we had to work through wrt to licenses and other issues that have caused some respins. At this point I think we're green for the release. Please take a few minutes to cast your vote and we can get this release wrapped up, 1.1.1 started and move on. +1 from PMC Members Davanum Srinivas Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Gianny D'Amour Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers David Blevins Alan Cabrera Hernan Cunico Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico Hiram R. Chirino James Strachan Jason Dillon Jeff Genender Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera
Re: Update on 1.1 Final2 Voting Status - Tally so far
Whoops...sorry I am late in the game (baby on way)...have not been checking the lists... +1 Matt Hogstrom wrote: Here is the current status of voting. I know we've had several issues we had to work through wrt to licenses and other issues that have caused some respins. At this point I think we're green for the release. Please take a few minutes to cast your vote and we can get this release wrapped up, 1.1.1 started and move on. +1 from PMC Members Davanum Srinivas Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Gianny D'Amour Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers David Blevins Alan Cabrera Hernan Cunico Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico Hiram R. Chirino James Strachan Jason Dillon Jeff Genender Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera
[jira] Resolved: (AMQ-739) STOMP transport handles JMS type improperly
[ https://issues.apache.org/activemq/browse/AMQ-739?page=all ] Nathan Mittler resolved AMQ-739: Fix Version: (was: 4.1) Resolution: Won't Fix Since ActiveMQ already correctly identifies TextMessages and BytesMessages based on content-length, no action is necessary. The documenation was updated on the wiki to make it clear how to create Text/Bytes messages from Stomp: http://www.activemq.org/site/stomp.html STOMP transport handles JMS type improperly --- Key: AMQ-739 URL: https://issues.apache.org/activemq/browse/AMQ-739 Project: ActiveMQ Type: Bug Components: Transport Versions: 4.0.1, 4.0 Environment: sending from STOMP to JMS Reporter: Nathan Mittler Assignee: Nathan Mittler Priority: Minor Original Estimate: 1 week Remaining: 1 week Sending a text message from a stomp client with a content-length results in a bytes message on JMS. Suggest doing the following ... 1) The stomp transport should always add the content-length header to out-going messages, regardless of content-type or whether or not a content-length was provided on the incoming message. 2) The stomp transport should handle in-coming messages with a content-type header, and should pass that through. 3) If a message comes in without a content-length or a content-type, it should just be assumed a TextMessage. This way we can use the terminating null character as the delimiter. -- 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-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: modules.patch Thanks to Brett Porter! The latest release of maven-war-plugin and maven-rar-plugin allows excluding pom.xml and pom.properties from the generated war/rar. This patch excludes pom.properties and pom.xml files from ge-activemq-rar. This solves the problem described in Example 3 : http://www.nabble.com/M2-%3A-build-on-Windows-t1803375.html#a4914787 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.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, etc.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 Gianny Matt Hogstrom wrote: The corrections applied due to license files are first in this list. Thanks to John for dogging this. The distributions and builds were not affected. Based on previous feedback the vote continues. Thanks for your feedback. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.zip John noted that the source zip had a META-INF. I've created a script to use in the future because with so many changes forgetting to use zip and typing jar is not acceptable. Also, note that the build itself has the LICENSE and NOTICES in two different places. The are located in modules/scripts/src/main/resources/ which put the right files in the distributions however they werenot correctly specified for source as the LICENSE and NOTICES are part of the source tree. After this release we need to address this issue so as to avoid manual problems like this. *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.zip Corrected LICENSE and NOTICES files. Use zip rather than jar to create zip. *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.1.ear Corrected LICENSE and NOTICE files in ear. John, whats the correct command to set the properties? Or, would you like to address these? No changes to the below files. *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip
[jira] Created: (XBEAN-22) Support for inverse class loading, exclusions and non overridable classes
Support for inverse class loading, exclusions and non overridable classes - Key: XBEAN-22 URL: http://issues.apache.org/jira/browse/XBEAN-22 Project: XBean Type: New Feature Components: server Versions: 2.3 Reporter: Guillaume Nodet Fix For: 2.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 Build Instructions on wiki (M2 : Build Instruction)
Jason Dillon wrote: I don't think we should keep creating so many spaces. The idea behind having multiple spaces was to allow easier management of the documentation as we deliver new releases of Geronimo. I do not think we should limit the number of spaces... If a sub-project warrants its own space, then lets give it one. Spaces are just like top-level directories in a 2-level file system. If it was more than 2-levels, then I would agree, but since it is not, then I think that adding new spaces where appropriate is the way to go. D. Blevins, if gbuild and vmbuild are part of the Geronimo project, would you consider moving them into the Apache Geronimo SandBox? IMO, GBuild/vmbuild should have a separate space. Again, we need to change that name soon, I couldn't come up with anything better at that time. Any proposal anyone? Just change it to Apache Geronimo, GMO. The root space. All other spaces are GMOxYYY how about renaming it to Apache Geronimo wiki (GMOxWIKI)to use a more known/friendly name? Cheers! Hernan --jason
[jira] Updated: (XBEAN-21) org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work
[ http://issues.apache.org/jira/browse/XBEAN-21?page=all ] Guillaume Nodet updated XBEAN-21: - Attachment: XBEAN-21.patch org\apache\xbean\spring\context\XmlWebApplicationContext.java does not work --- Key: XBEAN-21 URL: http://issues.apache.org/jira/browse/XBEAN-21 Project: XBean Type: Bug Components: spring Versions: 2.4 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.5 Attachments: XBEAN-21.patch -- 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: (XBEAN-22) Support for inverse class loading, exclusions and non overridable classes
[ http://issues.apache.org/jira/browse/XBEAN-22?page=all ] Guillaume Nodet updated XBEAN-22: - Attachment: XBEAN-22.patch Merge from Dain's work on Geronimo classloaders Support for inverse class loading, exclusions and non overridable classes - Key: XBEAN-22 URL: http://issues.apache.org/jira/browse/XBEAN-22 Project: XBean Type: New Feature Components: server Versions: 2.3 Reporter: Guillaume Nodet Fix For: 2.5 Attachments: XBEAN-22.patch -- 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: (SM-465) Improve support for shared libraries
Improve support for shared libraries Key: SM-465 URL: https://issues.apache.org/activemq/browse/SM-465 Project: ServiceMix Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet Fix For: 3.0 -- 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
[RTC] GERONIMO-2135
I noticed that my mail filters put this in my geronimo-jira folder.. I'm hoping that's why no one replied to the RTC. Going to change the subject like a little in hopes that it gets filtered correctly and get folks to +1 it. On 6/19/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi folks, Looking for 3 +1s for the patch attached to http://issues.apache.org/jira/browse/GERONIMO-2135. This patch addresses previous concerns raised by David Jencks. Items not addressed by the patch are: #4: yes. I agree, but since these GBeans are just meant to be a simple integration between Geronimo and ActiveMQ, we are taking some short cuts. In general ActiveMQ allows you to configure many more options than what the current GBeans allows you to do. #5, I also agree, but I don't have a programmatic way of listing all protocols since they are loaded by searching the classpath for META-INF resources. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Update on 1.1 Final2 Voting Status - Tally so far
+1 On 6/21/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here is the current status of voting. I know we've had several issues we had to work through wrt to licenses and other issues that have caused some respins. At this point I think we're green for the release. Please take a few minutes to cast your vote and we can get this release wrapped up, 1.1.1 started and move on. +1 from PMC Members Davanum Srinivas Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Gianny D'Amour Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers David Blevins Alan Cabrera Hernan Cunico Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico Hiram R. Chirino James Strachan Jason Dillon Jeff Genender Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Re-Release XBean 2.4
Thanks to all who voted.The release is available at http://geronimo.apache.org/xbean/dist/xbean-2.4/and has been mirrored on public repos http://www.ibiblio.org/maven2/org/apache/xbean/xbean-spring/2.4/ (for example)I have already some patches pending, so I hope we will release a 2.5 soon.Do you have any wishes for next release ?Cheers, Guillaume NodetOn 6/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have pushed new XBean 2.4 binaries in a private repo for review.They are available at http://people.apache.org/~gnodet/xbean-2.4/m1/org.apache.xbean http://people.apache.org/~gnodet/ xbean-2.4/m2/org/apache/xbean http://people.apache.org/~gnodet/xbean-2.4/site/ If no one objects I will put the binaries in their official distribution repositories by the end of the weekHere is my non binding +1 Cheers, Guillaume Nodet
Re: Derby library does not have line number debug information
+1 (I assume we are all voting to raise the jira and proceed to change versions in 1.1.1 and 1.2 without an additional vote) david jencks On Jun 21, 2006, at 2:38 AM, John Sisson wrote: The Derby library we are using in Geronimo does not have line number debug information, which is useful in stack traces. This has been addressed in the upcoming Derby 10.1.3 release by providing a lib-debug distribution ( http://issues.apache.org/jira/ browse/DERBY-178 ) . I'll raise a JIRA if people think it would be a good idea to use the debug version. Comments? Thanks, John
Re: [announce] Apache Geronimo welcomes Joe Bohn as our newest committer
Congratulations Joe and welcome! david jencks On Jun 20, 2006, at 4:47 PM, Sachin Patel wrote: In recognition of his contributions to the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Joe Bohn. Joe has contributed in many areas, including the console and as of recent, the work on our minimal distributions. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. We look forward to his continued involvement as a committer. Please join us in congratulating Joe. The Apache Geronimo PMC
Re: Namespace-driven builders and the UPA rule
On Jun 18, 2006, at 1:55 PM, Gianny Damour wrote: Hi, Is there a way to do this substitution of JACC implementation by providing a substitutionGroup attribute to the security element? giant snip I think this is the best solution, although there are some problems. It appears that substitution groups may not really be intended to provide runtime-extensible element support, at least xmlbeans doesn't work that way. I think I have a solution. Xmlbeans' ideas about substitution groups are that it only recognizes the substitutions that are in the set of schemas compiled at the same time as the element being substituted for. Later schemas compile just fine but the list of substitute qnames is hardcoded in the generated code for the substitutable element and also in the binary xsb encoding of the schema. It might be possible to add more qnames into the object model the xsb is deserialized into, but I don't see a reasonable way to modify the hardcoded list in the generated code. What I've come up with that appears to work is: - use substitution groups in the schemas. This makes it plausible to see what is intended, unlike with the use of any. - track substitution group elements ourselves, so we can dynamically change recognized substitution groups as builders are added. I'm less sure about tracking removing builders. In this case the elements wouldn't get deployed but we wouldn't get an error. - modify our response to validation failures to ignore those caused by unrecognized substitution group elements - use the XmlObject.selectChildren(QNameSet) method to get the substitution group elements based on our tracking of the QNames in the substitution group. I hope to iron out the remaining wrinkles shortly and submit an updated patch for review. thanks david jencks
Wiki Confussion
What's our strategy for the 2 active Wikis we now have? http://wiki.apache.org/geronimo/ http://cwiki.apache.org/geronimo/ Are we moving everything from wiki over to cwiki and all new architecture content (like building Geronimo/Devtools and the new Plug-in architecture) should go in cwiki? -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: Wiki Confussion
Yes, that is the plan. Some time ago we voted to use confluence and now we are migrating the content over cwiki. We will drop (eventually) MoinMoin once we have all the content consolidated. Cheers! Hernan Donald Woods wrote: What's our strategy for the 2 active Wikis we now have? http://wiki.apache.org/geronimo/ http://cwiki.apache.org/geronimo/ Are we moving everything from wiki over to cwiki and all new architecture content (like building Geronimo/Devtools and the new Plug-in architecture) should go in cwiki? -Donald
[jira] Created: (AMQ-769) Expose MessageGroupMap implementation to be configurable via BrokerService property
Expose MessageGroupMap implementation to be configurable via BrokerService
property
---
Key: AMQ-769
URL: https://issues.apache.org/activemq/browse/AMQ-769
Project: ActiveMQ
Type: Improvement
Components: Broker
Versions: 4.0
Environment: Active MQ 4.0
Reporter: Sanjiv Jivan
I need to use the SimpleMessageGroupMap implmentation of MessageGroupMap instad
of the default MessageGroupHashBucket implmentation. Presently there's no easy
way to do this. Additionally the member messageGroupOwners in
org.apache.activemq.broker.region.Queue is private, with no setter and the
getter has
public MessageGroupMap getMessageGroupOwners() {
if (messageGroupOwners == null) {
messageGroupOwners = new
MessageGroupHashBucket(messageGroupHashBucketCount);
}
return messageGroupOwners;
}
So basically there's no easy way to use another implmentation of
MessageGroupMap in this class. (This lazy create method is also not threadsafe.
Might be better to default initialize messageGroupOwners )
I had to jump through a bunh of hoops, starting with subclassing BrokerService
exposing the messageGroupOwners class, followed by overriding
createRegionBroker() where it creates an annonymous subclass of RegionBroker ,
overriding createQueueRegion and createTempQueueRegion where I create
subclasses of QueueRegion and TempQueueRegion respectively to have them be
configured to use the configured MessageGroupMap.
--
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: Web site update
Hernan, Can you paste the command that you are trying to use? Merging is the proper approach for this type of thing. With the merge command, you can create a patch using the unified-diff output and piping it to a file. If I can see your command, I can hook you up. Take care,JeremyOn 6/20/06, Hernan Cunico [EMAIL PROTECTED] wrote: Merging isn't working, I don't see anything being updated into trunk.How do I create a patch if my local working copy is fully in sync with the branch, not the trunk.Is there a way to copy/move the content of the branch and overwrite the trunk? ThanksHernanDavid Blevins wrote: On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote: Hi All, I'm a bit lost with the two branches we have now to manage the web site.I have the .../site/branches/may2006 branch updated andready to go live, it already includes that last two changes(updated events and added book to documentation). What would be the next step? replacing the content of .../site/ trunk and then commit to the live site from the updated trunk? howdo I replace it the content in .../site/trunk with the may2006 branch? Typically, you'd merge over your changes.Could use the 'svn merge' command.Or you could create a patch file and apply it to trunk.I like to use the graphical diff tool in Visual SlickEdit, but that'snot free. -David
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Anita Kulshreshtha updated GERONIMO-2067: - Attachment: applications.patch configs.patch 1. applications.patch - excludes pom.xml and pom.properties from war files. 2. configs.patch - the daytrader-derby-* configs are not enabled. They can be built on unix as is. To build on windows uncomment the shorter artifactId. Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, etc.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Group membership protocol ...
Hi, Is any group membership protocol implemented as part of ActiveMQ ? (I have seen references to ActiveCluster, and would like to know if AMQ uses it for any of the configurations). Thanks Regards - Sridhar ps: I will try delete it from the Users group -- View this message in context: http://www.nabble.com/Group-membership-protocol-...-t1825489.html#a4979496 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Web site update
Hi Jeremy, I was using a graphical tool to do the merge. The dry run would show all the files that would be updated but when I ran it for real nothing really changed on my working, local trunk, copy. I did an svn stat and saw no changes, did an svn up and it failed. Can't remember exactly the error msg but was something about not a working directory or can not run from the same directory. I ended up doing a new svn co from the trunk, updated the project files and xdocs, rebuilding and committing. I couldn't find any other way to do it, then I updated the web site from the trunk. What would the svn command line way be for merging the branch into the trunk? Thanks Cheers! Hernan Jeremy Whitlock wrote: Hernan, Can you paste the command that you are trying to use? Merging is the proper approach for this type of thing. With the merge command, you can create a patch using the unified-diff output and piping it to a file. If I can see your command, I can hook you up. Take care, Jeremy On 6/20/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Merging isn't working, I don't see anything being updated into trunk. How do I create a patch if my local working copy is fully in sync with the branch, not the trunk. Is there a way to copy/move the content of the branch and overwrite the trunk? Thanks Hernan David Blevins wrote: On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote: Hi All, I'm a bit lost with the two branches we have now to manage the web site. I have the .../site/branches/may2006 branch updated and ready to go live, it already includes that last two changes (updated events and added book to documentation). What would be the next step? replacing the content of .../site/ trunk and then commit to the live site from the updated trunk? how do I replace it the content in .../site/trunk with the may2006 branch? Typically, you'd merge over your changes. Could use the 'svn merge' command. Or you could create a patch file and apply it to trunk. I like to use the graphical diff tool in Visual SlickEdit, but that's not free. -David
liferay
Liferay is an open source portal made available under the MIT license. They provide a geronimo+liferay distribution from their website, which is basically a zipped up geronimo/tomcat server with liferay already deployed. I had some problems starting a fresh install of this distribution due to hsql database driver issues. Hopefully new users who experience this same problem will find the entry I posted in liferay's support forum about how to get it working: http://forums.liferay.com/index.php?showtopic=5348 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which has the new versioning functionality but as you can imagine is missing several important bug fixes and schema changes. I got their WAR working in geronimo 1.1 after making some adjustments to its geronimo-web.xml. When geronimo 1.1 is officially released I'll offer my assistance to help them upgrade to it. I also think and have heard others mention that liferay is a great candidate for a geronimo plugin. Adding the necessary plugin files to the liferay WAR is straightforward. But there are a couple of interesting challenges where I would like to get your input. First is that the plugin prereqs a database pool. Some expert users will want to manually create and populate the database and then use the console to point a db pool at it before installing the liferay plugin. But I imagine that some developers and more casual users would like for geronimo to automatically create a database pool for them as part of the liferay plugin install process. That way they could add a working portal server to their geronimo server with only a few clicks in the console (remember Joe's mom? ;-) For this latter class of users geronimo could provide a plugin that defines a derby datasource and automatically populates the database when the plugin is installed. Does this sound like a reasonable idea? I thought geronimo might already provide some facility to populate the database and I found this dev thread from last year where its proposed but (I assume) not implemented yet : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] This idea sounds right on to me. Are others still in favor of it? If so then I would like to work on an implementation. By the way, liferay currently does not support derby but I have it (mostly) working via a patch that I'll submit to them later. The second interesting aspect of creating liferay plugin is that liferay wants to use '/' for its context root. The problem is that the geronimo welcome app is already installed in the '/' context root and this prevents liferay from starting. I tried moving it to a different context root but then hard-coded references to scripts and images in their html started breaking. Is there a way to make geronimo override a context root such that last in wins? Or could the plugin metadata specify the required context root so that the console can warn the user about potential conflicts before installing the plugin? Any ideas? Looking forward to your feedback. Best wishes, Paul
[jira] Created: (SM-466) Classpath modifications by bootstrap are not handled
Classpath modifications by bootstrap are not handled Key: SM-466 URL: https://issues.apache.org/activemq/browse/SM-466 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M2 Reporter: Guillaume Nodet Fix For: 3.0 -- 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: Web site update
Hernan, Glad to hear you got it working. As for the command-line way:svn merge [EMAIL PROTECTED] [EMAIL PROTECTED] PATH_TO_WORKING_COPY_YOU_WISH_TO_MERGE_CHANGES_INTO Sorry for the weird looking command but I tried to put some useful tidbits into the command. ;)Take care,JeremyOn 6/21/06, Hernan Cunico [EMAIL PROTECTED] wrote:Hi Jeremy, I was using a graphical tool to do the merge. The dry run would show all the files that would beupdated but when I ran it for real nothing really changed on my working, local trunk, copy.I did an svn stat and saw no changes, did an svn up and it failed. Can't remember exactly the error msg but was something about not a working directory or can not run from the same directory.I ended up doing a new svn co from the trunk, updated the project files and xdocs, rebuilding andcommitting. I couldn't find any other way to do it, then I updated the web site from the trunk. What would the svn command line way be for merging the branch into the trunk?ThanksCheers!HernanJeremy Whitlock wrote: Hernan, Can you paste the command that you are trying to use?Merging is the proper approach for this type of thing.With the merge command, you can create a patch using the unified-diff output and piping it to a file.If I can see your command, I can hook you up. Take care, Jeremy On 6/20/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Merging isn't working, I don't see anything being updated into trunk. How do I create a patch if my local working copy is fully in sync with the branch, not the trunk. Is there a way to copy/move the content of the branch and overwrite the trunk? Thanks Hernan David Blevins wrote: On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote: Hi All, I'm a bit lost with the two branches we have now to manage the web site.I have the .../site/branches/may2006 branch updated andready to go live, it already includes that last two changes(updated events and added book to documentation). What would be the next step? replacing the content of .../site/ trunk and then commit to the live site from the updated trunk? howdo I replace it the content in .../site/trunk with the may2006 branch? Typically, you'd merge over your changes.Could use the 'svn merge' command.Or you could create a patch file and apply it to trunk.I like to use the graphical diff tool in Visual SlickEdit, but that'snot free. -David
[jira] Created: (SM-467) Classpath modifications at installation time should be persisted somehow
Classpath modifications at installation time should be persisted somehow Key: SM-467 URL: https://issues.apache.org/activemq/browse/SM-467 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M2 Reporter: Guillaume Nodet -- 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-466) Classpath modifications by bootstrap are not handled
[ https://issues.apache.org/activemq/browse/SM-466?page=all ] Guillaume Nodet resolved SM-466: Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Wed Jun 21 12:16:31 2006 New Revision: 416076 URL: http://svn.apache.org/viewvc?rev=416076view=rev Log: SM-466: Classpath modifications by bootstrap are not handled Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/InstallationContextImpl.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/InstallationService.java incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/InstallerMBeanImpl.java incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/framework/ComponentRegistryTest.java incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/loaders/ClassLoaderTest.java Classpath modifications by bootstrap are not handled Key: SM-466 URL: https://issues.apache.org/activemq/browse/SM-466 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M2 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0 -- 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: [announce] Apache Geronimo welcomes Joe Bohn as our newest committer
On Tue, Jun 20, 2006 at 10:47:50AM -0400, Sachin Patel wrote: In recognition of his contributions to the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Joe Bohn. Joe has contributed in many areas, including the console and as of recent, the work on our minimal distributions. The minimal distributions are very handy. Thanks Joe!
RE: liferay
I don't like the idea of having multiple apps mapped to the same context path/root. It sounds like liferay needs to be modified to properly path to resources. This may be a major development, but any production level site should really support whatever context path the user wants to select, rather than hard coding. Remember all those annoying programs that install to C:\foo? Don't be that program. BAL From: Paul McMahan [EMAIL PROTECTED] Reply-To: dev@geronimo.apache.org To: dev dev@geronimo.apache.org Subject: liferay Date: Wed, 21 Jun 2006 14:40:25 -0400 Liferay is an open source portal made available under the MIT license. They provide a geronimo+liferay distribution from their website, which is basically a zipped up geronimo/tomcat server with liferay already deployed. I had some problems starting a fresh install of this distribution due to hsql database driver issues. Hopefully new users who experience this same problem will find the entry I posted in liferay's support forum about how to get it working: http://forums.liferay.com/index.php?showtopic=5348 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which has the new versioning functionality but as you can imagine is missing several important bug fixes and schema changes. I got their WAR working in geronimo 1.1 after making some adjustments to its geronimo-web.xml. When geronimo 1.1 is officially released I'll offer my assistance to help them upgrade to it. I also think and have heard others mention that liferay is a great candidate for a geronimo plugin. Adding the necessary plugin files to the liferay WAR is straightforward. But there are a couple of interesting challenges where I would like to get your input. First is that the plugin prereqs a database pool. Some expert users will want to manually create and populate the database and then use the console to point a db pool at it before installing the liferay plugin. But I imagine that some developers and more casual users would like for geronimo to automatically create a database pool for them as part of the liferay plugin install process. That way they could add a working portal server to their geronimo server with only a few clicks in the console (remember Joe's mom? ;-) For this latter class of users geronimo could provide a plugin that defines a derby datasource and automatically populates the database when the plugin is installed. Does this sound like a reasonable idea? I thought geronimo might already provide some facility to populate the database and I found this dev thread from last year where its proposed but (I assume) not implemented yet : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] This idea sounds right on to me. Are others still in favor of it? If so then I would like to work on an implementation. By the way, liferay currently does not support derby but I have it (mostly) working via a patch that I'll submit to them later. The second interesting aspect of creating liferay plugin is that liferay wants to use '/' for its context root. The problem is that the geronimo welcome app is already installed in the '/' context root and this prevents liferay from starting. I tried moving it to a different context root but then hard-coded references to scripts and images in their html started breaking. Is there a way to make geronimo override a context root such that last in wins? Or could the plugin metadata specify the required context root so that the console can warn the user about potential conflicts before installing the plugin? Any ideas? Looking forward to your feedback. Best wishes, Paul
[jira] Closed: (AMQ-764) Getting OutofMemoryException after sending 2200 messages (JBoss 4.0/ActiveMQ 4.0)
[ https://issues.apache.org/activemq/browse/AMQ-764?page=all ] shahzad bhatti closed AMQ-764: -- Resolution: Fixed I tried 4.0.1 and am no longer see out-of-memory. Can you explain what was changed between 4.0-RC2 and 4.0.1 to fix this. Getting OutofMemoryException after sending 2200 messages (JBoss 4.0/ActiveMQ 4.0) - Key: AMQ-764 URL: https://issues.apache.org/activemq/browse/AMQ-764 Project: ActiveMQ Type: Bug Components: JCA Container Versions: 4.0 RC3 Environment: REDHAT 3.0 JBoss 4.04-GA ActiveMQ-4.0-RC2 Reporter: shahzad bhatti Fix For: 4.0.2 Attachments: activemq_jboss.zip I am testing ActiveMQ 4.0 with JBoss 4.0 where I am using ActiveMQ's .rar file within JBoss. I have a test applicacation that consists of following components: -Message driven bean listens to queue within JBoss. It receives message and invokes stateless session bean, which invokes entity bean and the message is added to the databsae (mysql). After adding message, it replies back the response to the client. -JBoss stateless session bean -- uses entity bean to add message to the database -JBoss entity bean that uses CMP to add message to the database. -Publisher client - uses ActiveMQ APIs to publish message to the queue and listens for response I find that after about 2200 messages, I get OutOfMemory exception in ActiveMQ and my application hangs. I am also attaching source code minus jar files. You will also need mysql database. -- 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: liferay
Paul McMahan wrote: Liferay is an open source portal made available under the MIT license. They provide a geronimo+liferay distribution from their website, which is basically a zipped up geronimo/tomcat server with liferay already deployed. I had some problems starting a fresh install of this distribution due to hsql database driver issues. Hopefully new users who experience this same problem will find the entry I posted in liferay's support forum about how to get it working: http://forums.liferay.com/index.php?showtopic=5348 I was the one who helped get the Liferay implementation running with the Liferay guys. I personally got it running fine on MySQL. Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which has the new versioning functionality but as you can imagine is missing several important bug fixes and schema changes. I got their WAR working in geronimo 1.1 after making some adjustments to its geronimo-web.xml. When geronimo 1.1 is officially released I'll offer my assistance to help them upgrade to it. Yes...we used 1.1 SNAPSHOT because it was the best available to move forward with. I am currently working with them to get the Enterprise version working...hopefully next week. If you want to join in...by all means please do ;-) I also think and have heard others mention that liferay is a great candidate for a geronimo plugin. Adding the necessary plugin files to the liferay WAR is straightforward. But there are a couple of interesting challenges where I would like to get your input. First is that the plugin prereqs a database pool. Some expert users will want to manually create and populate the database and then use the console to point a db pool at it before installing the liferay plugin. But I imagine that some developers and more casual users would like for geronimo to automatically create a database pool for them as part of the liferay plugin install process. That way they could add a working portal server to their geronimo server with only a few clicks in the console (remember Joe's mom? ;-) When I did the professional version I placed an automagically created DB pool...but with MySQL. But it was proof of concept since who knows if someone is going to be using MySQL or not or where the database would even live. But to offer a plugin for Derby would be great IMHO for people to try it out...since Derby will likely live with Geronimo. But obviously when using an enterprise class database, it made no sense to include it since the locations may be anywhere. It would be difficult to provide plugins for this. For this latter class of users geronimo could provide a plugin that defines a derby datasource and automatically populates the database when the plugin is installed. Does this sound like a reasonable idea? I thought geronimo might already provide some facility to populate the database and I found this dev thread from last year where its proposed but (I assume) not implemented yet : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] This idea sounds right on to me. Are others still in favor of it? If so then I would like to work on an implementation. By the way, liferay currently does not support derby but I have it (mostly) working via a patch that I'll submit to them later. For Derby...absolutely! The second interesting aspect of creating liferay plugin is that liferay wants to use '/' for its context root. The problem is that the geronimo welcome app is already installed in the '/' context root and this prevents liferay from starting. I tried moving it to a different context root but then hard-coded references to scripts and images in their html started breaking. Is there a way to make geronimo override a context root such that last in wins? Or could the plugin metadata specify the required context root so that the console can warn the user about potential conflicts before installing the plugin? Any ideas? According to their documentation for the other appservers, they have you remove ROOT context. This seems to be the way they do it. Looking forward to your feedback. Best wishes, Paul
Re: liferay
Paul, David Jencks wrote a GBean to do mostly what your looking for. If you look in applications/daytrader/derby you'll find how the database is predefined for derby. In the DayTrader plan built in configs/daytrader/src/plan/target/plan.xml you'll find an entry in the deployment plan the copies the pre-built database into the Geronimo var directory. Here is the XML part of the deployment plan. gbean name=DaytraderResources class=org.apache.geronimo.system.util.DirectoryInitializationGBean !--copies daytrader derby db files into specified location-- attribute name=prefixMETA-INF/geronimo-daytrader-derby-db/attribute attribute name=pathvar/derby/attribute reference name=ServerInfo nameServerInfo/name /reference I think this is what your are looking for. Does this help? Paul McMahan wrote: Liferay is an open source portal made available under the MIT license. They provide a geronimo+liferay distribution from their website, which is basically a zipped up geronimo/tomcat server with liferay already deployed. I had some problems starting a fresh install of this distribution due to hsql database driver issues. Hopefully new users who experience this same problem will find the entry I posted in liferay's support forum about how to get it working: http://forums.liferay.com/index.php?showtopic=5348 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which has the new versioning functionality but as you can imagine is missing several important bug fixes and schema changes. I got their WAR working in geronimo 1.1 after making some adjustments to its geronimo-web.xml. When geronimo 1.1 is officially released I'll offer my assistance to help them upgrade to it. I also think and have heard others mention that liferay is a great candidate for a geronimo plugin. Adding the necessary plugin files to the liferay WAR is straightforward. But there are a couple of interesting challenges where I would like to get your input. First is that the plugin prereqs a database pool. Some expert users will want to manually create and populate the database and then use the console to point a db pool at it before installing the liferay plugin. But I imagine that some developers and more casual users would like for geronimo to automatically create a database pool for them as part of the liferay plugin install process. That way they could add a working portal server to their geronimo server with only a few clicks in the console (remember Joe's mom? ;-) For this latter class of users geronimo could provide a plugin that defines a derby datasource and automatically populates the database when the plugin is installed. Does this sound like a reasonable idea? I thought geronimo might already provide some facility to populate the database and I found this dev thread from last year where its proposed but (I assume) not implemented yet : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] This idea sounds right on to me. Are others still in favor of it? If so then I would like to work on an implementation. By the way, liferay currently does not support derby but I have it (mostly) working via a patch that I'll submit to them later. The second interesting aspect of creating liferay plugin is that liferay wants to use '/' for its context root. The problem is that the geronimo welcome app is already installed in the '/' context root and this prevents liferay from starting. I tried moving it to a different context root but then hard-coded references to scripts and images in their html started breaking. Is there a way to make geronimo override a context root such that last in wins? Or could the plugin metadata specify the required context root so that the console can warn the user about potential conflicts before installing the plugin? Any ideas? Looking forward to your feedback. Best wishes, Paul
Re: liferay
There are two options you should be aware of for a plugin. One is that you can declare a database pool dependency named LiferayDatabase or whatever. Then provide a Derby database pool plugin with that name. If the user creates a custom database pool named LiferayDatabase then the Liferay plugin will map to that, whatever it is. If not, it will download and install the Derby database pool. (This only works for embedded databases like Derby where there's no need to point it to a specific DB server, etc.) The simple alternative is to make the database pool a prerequisite instead of a dependency, which would mean the user would have to create a pool with the right name by hand before the plugin would install. As a side note, we're certainly open to more customized handling of database pool dependencies, but it's not there in 1.1. The other option is that a plugin can obsolete other modules or plugins. So the Liferay can obsolete the welcome app, meaning the welcome app will be uninstalled when the Liferay plugin is installed. It's kind of heavy-handed, but probably better than having it install and immediately fail due to the context root conflict. As far as populating the database, you can provide a GBean that runs whenever a flag like initialized is false. Every time it starts it can check the flag and abort if it's set. If it's not set, it can do its work, and then set the flag on itself (via a roundabout kernel call), so it will never execute the initialization again. Or, of course, just connect to the DB and only execute the initialization if some known Liferay table is not present. Thanks, Aaron On 6/21/06, Paul McMahan [EMAIL PROTECTED] wrote: Liferay is an open source portal made available under the MIT license. They provide a geronimo+liferay distribution from their website, which is basically a zipped up geronimo/tomcat server with liferay already deployed. I had some problems starting a fresh install of this distribution due to hsql database driver issues. Hopefully new users who experience this same problem will find the entry I posted in liferay's support forum about how to get it working: http://forums.liferay.com/index.php?showtopic=5348 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which has the new versioning functionality but as you can imagine is missing several important bug fixes and schema changes. I got their WAR working in geronimo 1.1 after making some adjustments to its geronimo-web.xml. When geronimo 1.1 is officially released I'll offer my assistance to help them upgrade to it. I also think and have heard others mention that liferay is a great candidate for a geronimo plugin. Adding the necessary plugin files to the liferay WAR is straightforward. But there are a couple of interesting challenges where I would like to get your input. First is that the plugin prereqs a database pool. Some expert users will want to manually create and populate the database and then use the console to point a db pool at it before installing the liferay plugin. But I imagine that some developers and more casual users would like for geronimo to automatically create a database pool for them as part of the liferay plugin install process. That way they could add a working portal server to their geronimo server with only a few clicks in the console (remember Joe's mom? ;-) For this latter class of users geronimo could provide a plugin that defines a derby datasource and automatically populates the database when the plugin is installed. Does this sound like a reasonable idea? I thought geronimo might already provide some facility to populate the database and I found this dev thread from last year where its proposed but (I assume) not implemented yet : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] This idea sounds right on to me. Are others still in favor of it? If so then I would like to work on an implementation. By the way, liferay currently does not support derby but I have it (mostly) working via a patch that I'll submit to them later. The second interesting aspect of creating liferay plugin is that liferay wants to use '/' for its context root. The problem is that the geronimo welcome app is already installed in the '/' context root and this prevents liferay from starting. I tried moving it to a different context root but then hard-coded references to scripts and images in their html started breaking. Is there a way to make geronimo override a context root such that last in wins? Or could the plugin metadata specify the required context root so that the console can warn the user about potential conflicts before installing the plugin? Any ideas? Looking forward to your feedback. Best wishes, Paul
Re: Wiki Confussion
On Jun 21, 2006, at 10:47 AM, Donald Woods wrote: What's our strategy for the 2 active Wikis we now have? http://wiki.apache.org/geronimo/ http://cwiki.apache.org/geronimo/ Are we moving everything from wiki over to cwiki and all new architecture content (like building Geronimo/Devtools and the new Plug-in architecture) should go in cwiki? Right. -David
Re: Web site update
I think this is complicated by the fact that we split out the trunk and branch after the fact (basically moved trunk to branch and recreated trunk by copying from a previous revision. I think the way to do the merge would be to generate a diff between the revision we copied to trunk (I forget which but it said in the commit message when I did it) and the tip of the branch. I think it would be important to use that exact revision number as the before point in generating the diff or doing the merge. Thanks, Aaron On 6/21/06, Jeremy Whitlock [EMAIL PROTECTED] wrote: Hernan, Glad to hear you got it working. As for the command-line way: svn merge [EMAIL PROTECTED] [EMAIL PROTECTED] PATH_TO_WORKING_COPY_YOU_WISH_TO_MERGE_CHANGES_INTO Sorry for the weird looking command but I tried to put some useful tidbits into the command. ;) Take care, Jeremy On 6/21/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi Jeremy, I was using a graphical tool to do the merge. The dry run would show all the files that would be updated but when I ran it for real nothing really changed on my working, local trunk, copy. I did an svn stat and saw no changes, did an svn up and it failed. Can't remember exactly the error msg but was something about not a working directory or can not run from the same directory. I ended up doing a new svn co from the trunk, updated the project files and xdocs, rebuilding and committing. I couldn't find any other way to do it, then I updated the web site from the trunk. What would the svn command line way be for merging the branch into the trunk? Thanks Cheers! Hernan Jeremy Whitlock wrote: Hernan, Can you paste the command that you are trying to use? Merging is the proper approach for this type of thing. With the merge command, you can create a patch using the unified-diff output and piping it to a file. If I can see your command, I can hook you up. Take care, Jeremy On 6/20/06, *Hernan Cunico* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Merging isn't working, I don't see anything being updated into trunk. How do I create a patch if my local working copy is fully in sync with the branch, not the trunk. Is there a way to copy/move the content of the branch and overwrite the trunk? Thanks Hernan David Blevins wrote: On Jun 19, 2006, at 12:11 PM, Hernan Cunico wrote: Hi All, I'm a bit lost with the two branches we have now to manage the web site. I have the .../site/branches/may2006 branch updated and ready to go live, it already includes that last two changes (updated events and added book to documentation). What would be the next step? replacing the content of .../site/ trunk and then commit to the live site from the updated trunk? how do I replace it the content in .../site/trunk with the may2006 branch? Typically, you'd merge over your changes. Could use the 'svn merge' command. Or you could create a patch file and apply it to trunk. I like to use the graphical diff tool in Visual SlickEdit, but that's not free. -David
Re: migrating MoinMoin to Confluence
Following up off-list to track down the tool. Thanks, Aaron On 6/21/06, Hernan Cunico [EMAIL PROTECTED] wrote: Aaron, IIRC some time ago you mentioned a tool for migrating MoinMoin to Confluence, do you have it available for download somewhere? I think it would be better to migrate the entire MoinMoin wiki into a separate Confluence space and do the cleaning directly from Confluence. Cheers! Hernan
Re: migrating MoinMoin to Confluence
FYI: http://confluence.atlassian.com/display/CONFEXT/MoinMoin+importer There is also: http://confluence.atlassian.com/display/CONFEXT/Universal+Wiki +Converter Not sure well either work though. --jason On Jun 21, 2006, at 3:24 PM, Hernan Cunico wrote: Aaron, IIRC some time ago you mentioned a tool for migrating MoinMoin to Confluence, do you have it available for download somewhere? I think it would be better to migrate the entire MoinMoin wiki into a separate Confluence space and do the cleaning directly from Confluence. Cheers! Hernan
Update on 1.1 Final2 Voting Status - Tally so far - Approximately 12 hours left
Here is the current status of voting ... only 12 hours left. +1 from PMC Members Davanum Srinivas Gianny D'Amour Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers Alan Cabrera David Blevins Hernan Cunico Hiram R. Chirino Jeff Genender Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico James Strachan Jason Dillon Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera
Re: Update on 1.1 Final2 Voting Status - Tally so far
+1 to release. John Matt Hogstrom wrote: Here is the current status of voting. I know we've had several issues we had to work through wrt to licenses and other issues that have caused some respins. At this point I think we're green for the release. Please take a few minutes to cast your vote and we can get this release wrapped up, 1.1.1 started and move on. +1 from PMC Members Davanum Srinivas Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Gianny D'Amour Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers David Blevins Alan Cabrera Hernan Cunico Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico Hiram R. Chirino James Strachan Jason Dillon Jeff Genender Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera
Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 --kevan On Jun 20, 2006, at 6:15 PM, Matt Hogstrom wrote: The corrections applied due to license files are first in this list. Thanks to John for dogging this. The distributions and builds were not affected. Based on previous feedback the vote continues. Thanks for your feedback. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1- final-2.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1- final-2.1_src.zip John noted that the source zip had a META-INF. I've created a script to use in the future because with so many changes forgetting to use zip and typing jar is not acceptable. Also, note that the build itself has the LICENSE and NOTICES in two different places. The are located in modules/scripts/src/main/resources/ which put the right files in the distributions however they werenot correctly specified for source as the LICENSE and NOTICES are part of the source tree. After this release we need to address this issue so as to avoid manual problems like this. *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/ daytrader_src-1.1-final-2.1.tar.gz http://people.apache.org/~hogstrom/1.1-final2/ daytrader_src-1.1-final-2.1.zip Corrected LICENSE and NOTICES files. Use zip rather than jar to create zip. *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader- ear-1.1-final-2.1.ear Corrected LICENSE and NOTICE files in ear. John, whats the correct command to set the properties? Or, would you like to address these? No changes to the below files. *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty- minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat- minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/ org.apache.geronimo.specs-1.1-final-2.zip
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt The whole point in having a 1.1.1 branch was to busily put in patches while 1.1.0 goes out the door. Since nothing was done on that branch, I don't see why we don't use branches/1.1 as the trunk for 1.1.x patches. Regards, Alan
Re: Update on 1.1 Final2 Voting Status - Tally so far - Approximately 12 hours left
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +0 - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRJnZ/prNPMCpn3XdAQL2wQP/YwHnGB4lGe3pmW2+2nK/mtaMxRVfI4R2 IbT7jp9gOK2D3I7q13Kj8587bwyFHpvLHggqQOTBGusUaKhKhLbid6RlSmkGFtN1 4UF3GtW4SGsMFEnrKwLpTpmokokN2LIsV86i/jRccMAdSsSX908pGyGpgZmsc3BI V2NXoc0QM4I= =mpnf -END PGP SIGNATURE-
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Why would a branch get moved to a tag? Why do we need branches for revisions? Why are we deleting branches? IMO, we should have a branch for each Major.Minor, where all of the Major.Minor.Revision work happens. So branches/1.1 would hold the active work for 1.1.x. When it is time to make a release, then svn cp from branches/1.1 to tags/1.1.1, and then keep working on 1.1.2 on branches/1.1 IMO, branches should never become tags. Tags only get copied to new branches when we need to apply critical fix to a specific release, otherwise we should just roll up the change into the next release of the series. I recommend minimizing branching where possible, so I don't think that branches for 1.1.1 or 1.1.1.0 are a good idea. SVN is not that good at merging, and making it simple (like Perforce), so lets try not to set ourselves up for icky merges by making branches for each release. --jason On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: Update on 1.1 Final2 Voting Status - Tally so far
+0 I have not had time to play with the release, but I am not against getting the release out. So for those that have reviewed and gave a +1 I trust them. --jason On Jun 21, 2006, at 2:20 AM, Matt Hogstrom wrote: Here is the current status of voting. I know we've had several issues we had to work through wrt to licenses and other issues that have caused some respins. At this point I think we're green for the release. Please take a few minutes to cast your vote and we can get this release wrapped up, 1.1.1 started and move on. +1 from PMC Members Davanum Srinivas Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Gianny D'Amour Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers David Blevins Alan Cabrera Hernan Cunico Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico Hiram R. Chirino James Strachan Jason Dillon Jeff Genender Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
On 6/21/06, Jason Dillon [EMAIL PROTECTED] wrote: Why would a branch get moved to a tag? Why do we need branches for revisions? Why are we deleting branches? IMO, we should have a branch for each Major.Minor, where all of the Major.Minor.Revision work happens. So branches/1.1 would hold the active work for 1.1.x. When it is time to make a release, then svn cp from branches/1.1 to tags/1.1.1, and then keep working on 1.1.2 on branches/1.1 IMO, branches should never become tags. Tags only get copied to new branches when we need to apply critical fix to a specific release, otherwise we should just roll up the change into the next release of the series. I recommend minimizing branching where possible, so I don't think that branches for 1.1.1 or 1.1.1.0 are a good idea. SVN is not that good at merging, and making it simple (like Perforce), so lets try not to set ourselves up for icky merges by making branches for each release. Hi Jason, I agree that we should avoid branching. But I do agree with the 1.1.1 branch. It's a dead-end branch in that it's only used to prepare he release. Applying last minute fixes and changing version numbers. Since it's a dead-end branch, once the release if approved moving/deleting it makes sense. --jason On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt -- Regards, Hiram Blog: http://hiramchirino.com
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Hi Jason, I agree that we should avoid branching. But I do agree with the 1.1.1 branch. It's a dead-end branch in that it's only used to prepare he release. Applying last minute fixes and changing version numbers. Since it's a dead-end branch, once the release if approved moving/deleting it makes sense. I would make those changes on the 1.1 branch (or trunk if we were using that codebase), then release and let Maven make the tag and then update the versions to the next SNAP. When moving to m2 we really need to follow the m2 release system, else the number of changes to poms is going to get out of control and will be very error prone. --jason
Re: liferay
Aaron Mulder wrote: One is that you can declare a database pool dependency named LiferayDatabase or whatever. Then provide a Derby database pool plugin with that name. If the user creates a custom database pool named LiferayDatabase then the Liferay plugin will map to that, whatever it is. If not, it will download and install the Derby database pool. (This only works for embedded databases like Derby where there's no need to point it to a specific DB server, etc.) This sounds like the right option for Liferay. The other option is that a plugin can obsolete other modules or plugins. So the Liferay can obsolete the welcome app, meaning the welcome app will be uninstalled when the Liferay plugin is installed. It's kind of heavy-handed, but probably better than having it install and immediately fail due to the context root conflict. Personal preference...but I think its better throwing an error. Is obsoleting a settable option? I am not so sure I like obsoleting by default...this could be ugly since it may be another app other than the Welcome app that gets obsoleted. As far as populating the database, you can provide a GBean that runs whenever a flag like initialized is false. Every time it starts it can check the flag and abort if it's set. If it's not set, it can do its work, and then set the flag on itself (via a roundabout kernel call), so it will never execute the initialization again. Or, of course, just connect to the DB and only execute the initialization if some known Liferay table is not present. Thanks, Aaron On 6/21/06, Paul McMahan [EMAIL PROTECTED] wrote: Liferay is an open source portal made available under the MIT license. They provide a geronimo+liferay distribution from their website, which is basically a zipped up geronimo/tomcat server with liferay already deployed. I had some problems starting a fresh install of this distribution due to hsql database driver issues. Hopefully new users who experience this same problem will find the entry I posted in liferay's support forum about how to get it working: http://forums.liferay.com/index.php?showtopic=5348 Liferay currently uses a snapshot of geronimo 1.1 from 5/3/2006 which has the new versioning functionality but as you can imagine is missing several important bug fixes and schema changes. I got their WAR working in geronimo 1.1 after making some adjustments to its geronimo-web.xml. When geronimo 1.1 is officially released I'll offer my assistance to help them upgrade to it. I also think and have heard others mention that liferay is a great candidate for a geronimo plugin. Adding the necessary plugin files to the liferay WAR is straightforward. But there are a couple of interesting challenges where I would like to get your input. First is that the plugin prereqs a database pool. Some expert users will want to manually create and populate the database and then use the console to point a db pool at it before installing the liferay plugin. But I imagine that some developers and more casual users would like for geronimo to automatically create a database pool for them as part of the liferay plugin install process. That way they could add a working portal server to their geronimo server with only a few clicks in the console (remember Joe's mom? ;-) For this latter class of users geronimo could provide a plugin that defines a derby datasource and automatically populates the database when the plugin is installed. Does this sound like a reasonable idea? I thought geronimo might already provide some facility to populate the database and I found this dev thread from last year where its proposed but (I assume) not implemented yet : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] This idea sounds right on to me. Are others still in favor of it? If so then I would like to work on an implementation. By the way, liferay currently does not support derby but I have it (mostly) working via a patch that I'll submit to them later. The second interesting aspect of creating liferay plugin is that liferay wants to use '/' for its context root. The problem is that the geronimo welcome app is already installed in the '/' context root and this prevents liferay from starting. I tried moving it to a different context root but then hard-coded references to scripts and images in their html started breaking. Is there a way to make geronimo override a context root such that last in wins? Or could the plugin metadata specify the required context root so that the console can warn the user about potential conflicts before installing the plugin? Any ideas? Looking forward to your feedback. Best wishes, Paul
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
I think your right if nothing needs to change. IIUC there is a general preference for tags being pristine with no modifications. So, if a release can go from being worked to a good release then the Maven system is great. I think the reality is that there will generally be the time required to wait for a release to bake. If changes are needed then they either need to be applied to the tagged version or copied and re-tagged (which IMHO is really undesireable). I think the idea of no changes to tags makes sense. If Maven could handle the process and take into account the timing and possible re-work that would be awesome. Right now the 1.1.0 release has been there for the better part of two weeks. I don't think we want to stall development like this in the future. If there is a way to address this with m2 that would be great. Jason Dillon wrote: Hi Jason, I agree that we should avoid branching. But I do agree with the 1.1.1 branch. It's a dead-end branch in that it's only used to prepare he release. Applying last minute fixes and changing version numbers. Since it's a dead-end branch, once the release if approved moving/deleting it makes sense. I would make those changes on the 1.1 branch (or trunk if we were using that codebase), then release and let Maven make the tag and then update the versions to the next SNAP. When moving to m2 we really need to follow the m2 release system, else the number of changes to poms is going to get out of control and will be very error prone. --jason
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Hi Jason, The problem is that it can take weeks to do a geronimo release since stuff like CTS testing is involved. So the release work (putting the finishing touches) needs to be done in a branch so that work can continue on the next release. Perhaps m2 has a way of dealing with those issues along with re-cutting releases and such. But since I have not done a m2 based release yet, I'm not sure what's involved. Could you clarify it a bit for me? On 6/21/06, Jason Dillon [EMAIL PROTECTED] wrote: Hi Jason, I agree that we should avoid branching. But I do agree with the 1.1.1 branch. It's a dead-end branch in that it's only used to prepare he release. Applying last minute fixes and changing version numbers. Since it's a dead-end branch, once the release if approved moving/deleting it makes sense. I would make those changes on the 1.1 branch (or trunk if we were using that codebase), then release and let Maven make the tag and then update the versions to the next SNAP. When moving to m2 we really need to follow the m2 release system, else the number of changes to poms is going to get out of control and will be very error prone. --jason -- Regards, Hiram Blog: http://hiramchirino.com
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Hi Jason, Hiya :-) The problem is that it can take weeks to do a geronimo release since stuff like CTS testing is involved. So the release work (putting the finishing touches) needs to be done in a branch so that work can continue on the next release. I would hope that most if not all of the issues should be resolved wrt/CTS/TCK before making a release... But, if this branch exists only for the reason of facilitating this time consuming process, and no merging is to be done, then I think it will work. I think that all development should be done on the 1.1 (or trunk) or M.m branch, and only release work on any M.m.r branches, and at the end of the release that branch is moved to a tag and never modified again. Future modifications will copy from the tag to a branch, and the cycle continues. Perhaps m2 has a way of dealing with those issues along with re-cutting releases and such. But since I have not done a m2 based release yet, I'm not sure what's involved. Could you clarify it a bit for me? I'm actually still sorting that out. I'm going to use m2 for GShell releases and I want to get a 0.0.1 out soonish to test it all out. I've got a little experence with it, and it does make it much easier, since for m2 every pom.xml needs to change when a version is changed :-( --jason
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
I think your right if nothing needs to change. IIUC there is a general preference for tags being pristine with no modifications. Generally I agree with this. So, if a release can go from being worked to a good release then the Maven system is great. I think the reality is that there will generally be the time required to wait for a release to bake. If changes are needed then they either need to be applied to the tagged version or copied and re-tagged (which IMHO is really undesireable). What kind of release backing are we talking about? I think the idea of no changes to tags makes sense. If Maven could handle the process and take into account the timing and possible re- work that would be awesome. Right now the 1.1.0 release has been there for the better part of two weeks. I don't think we want to stall development like this in the future. Agreed. Maven should be able to help... m2 that is, not sure about m1. I'm going to experiment with a GShell release, but from what I understand, the release plugin should automate most of the details. We'll see. --jason
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
According to the maven guys, the release process is: * deploy snapshot * vote on snapshot * build and deploy a release Currently the m2 release process (if you use the release plugin is): * change all versions in poms and commit * create a tag * release and deploy from tag * revert to snapshots and commitAFAIK, this can be done from trunk or branch. The only problem i see is that you have currently no way to: * deploy to a private repo without changing the pom * promote a build to a release, so once a build has been voted, the release must be rebuild and redeployed (the binaries are different) Cheers,Guillaume NodetOn 6/22/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi Jason,The problem is that it can take weeks to do a geronimo release sincestuff like CTS testing is involved.So the release work (putting the finishing touches) needs to be done in a branch so that work cancontinue on the next release.Perhaps m2 has a way of dealing with those issues along withre-cutting releases and such.But since I have not done a m2 based release yet, I'm not sure what's involved.Could you clarify it a bitfor me?On 6/21/06, Jason Dillon [EMAIL PROTECTED] wrote: Hi Jason, I agree that we should avoid branching.But I do agree with the 1.1.1 branch.It's a dead-end branch in that it's only used to prepare he release.Applying last minute fixes and changing version numbers. Since it's a dead-end branch, once the release if approved moving/deleting it makes sense. I would make those changes on the 1.1 branch (or trunk if we were using that codebase), then release and let Maven make the tag and then update the versions to the next SNAP. When moving to m2 we really need to follow the m2 release system, else the number of changes to poms is going to get out of control and will be very error prone. --jason--Regards,HiramBlog: http://hiramchirino.com
Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
On Jun 21, 2006, at 5:18 PM, Jason Dillon wrote:
Hi Jason,
I agree that we should avoid branching. But I do agree with the
1.1.1
branch. It's a dead-end branch in that it's only used to prepare he
release. Applying last minute fixes and changing version numbers.
Since it's a dead-end branch, once the release if approved
moving/deleting it makes sense.
I would make those changes on the 1.1 branch (or trunk if we were
using that codebase), then release and let Maven make the tag and
then update the versions to the next SNAP.
When moving to m2 we really need to follow the m2 release system,
else the number of changes to poms is going to get out of control
and will be very error prone.
s/is going to get out of control/has gotten out of control/
It's already a problem, hence the strong need for a frozen branch
in which to switch the version numbers over.
For the weekly builds with the svn revision number instead of
snaphsot, I use these commands to switch the version.
perl -i.orig -pe 's,(-SNAPSHOT)?$,-$ENV{SVN_VERSION}, if /^
(geronimo.packaging.)?geronimo_?(.*?plugin_)?[Vv]ersion=/' etc/
project.properties plugins/*/*.properties
perl -i.orig -pe '
s,(/currentVersion),-$ENV{SVN_VERSION}$1, unless /SNAPSHOT/;
s,-SNAPSHOT(/currentVersion),-$ENV{SVN_VERSION}$1,;
s,-SNAPSHOT(/(dep:)?version),-$ENV{SVN_VERSION}$1, if $p2 =~ /
(dep:)?groupIdgeronimo/;
$p2=$p1; $p1=$_;
' plugins/*/project.xml plugins/geronimo-packaging-plugin/src/test-
resources/*.xml
perl -i.orig -pe 's,(-SNAPSHOT)?$,-$ENV{SVN_VERSION}, if /
^geronimo...=/' etc/explicit_versions.properties
Maven can't handle that.
-David
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 Joe Matt Hogstrom wrote: The corrections applied due to license files are first in this list. Thanks to John for dogging this. The distributions and builds were not affected. Based on previous feedback the vote continues. Thanks for your feedback. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.zip John noted that the source zip had a META-INF. I've created a script to use in the future because with so many changes forgetting to use zip and typing jar is not acceptable. Also, note that the build itself has the LICENSE and NOTICES in two different places. The are located in modules/scripts/src/main/resources/ which put the right files in the distributions however they werenot correctly specified for source as the LICENSE and NOTICES are part of the source tree. After this release we need to address this issue so as to avoid manual problems like this. *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.zip Corrected LICENSE and NOTICES files. Use zip rather than jar to create zip. *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.1.ear Corrected LICENSE and NOTICE files in ear. John, whats the correct command to set the properties? Or, would you like to address these? No changes to the below files. *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
XBean root POM
IIUC, version specific information has snuck into elements that should be version free, e.g. scm. Here is a list of elements that should have version information removed: scm build...remoteRepositoryUrl distributionManagment Regards, Alan
[VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: XBean root POM
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:
IIUC, version specific information has snuck into elements that
should be version free, e.g. scm. Here is a list of elements
that should have version information removed:
scm
build...remoteRepositoryUrl
distributionManagment
Not sure how this got there, it should point to trunk
scm
connectionscm:svn:http://svn.apache.org/repos/asf/geronimo/
xbean/tags/xbean-2.4/connection
developerConnectionscm:svn:https://${maven.username}
@svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/
developerConnection
urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/
xbean-2.4/url
/scm
No wonder Continuum is very unhappy with XBean...
http://ci.gbuild.org/continuum/servlet/continuum
... it will check the code out from *exactly* where you point it to.
-David
Re: XBean root POM
David Blevins wrote: On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote: IIUC, version specific information has snuck into elements that should be version free, e.g. scm. Here is a list of elements that should have version information removed: scm build...remoteRepositoryUrl distributionManagment Not sure how this got there, it should point to trunk scm connectionscm:svn:http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/connection developerConnectionscm:svn:https://[EMAIL PROTECTED]/repos/asf/geronimo/xbean/tags/xbean-2.4/developerConnection urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/url /scm No wonder Continuum is very unhappy with XBean... http://ci.gbuild.org/continuum/servlet/continuum ... it will check the code out from *exactly* where you point it to. -David How odd. I would think that continuum would take its cue from something more continuum specific, not the project SCM url. Regards, Alan
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 I think that we should mention that patches that go into x.y.z also go into x.y and trunk x.y also go into trunk Last time we neglected to apply patches evenly across the board when fixes were checked into one branch. This is one reason why the versions drifted so wildly apart. Regards, Alan David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: [RTC] ?? Review requested on intermediate patches for pluggable JACC
Dain Sundstrom wrote: On Jun 16, 2006, at 2:35 PM, David Jencks wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: I have two thoughts: 1) we have an automated tool to track patches and it can track votes and send out these reports. I'm not convinced automating this will work all that well. I do think that all +1 and suggestions should be made as comments on the jira issue. I think it can be up to the proposer to kick people on the dev list if it's getting ignored. If someone can really figure out how to do +1's in jira automatically, fine i'm not a jira expert and don't know how much this would conflict with the current meaning of voting. I don't know much about the voting, but I definitely think we should have some sort of review-required status. I think someone should have to have commit privileges to put something in that status, and by putting something in that status you are saying you want to commit it. Since this category would only contain the red-hot ready-to-commit patches, I say we send a daily (yes daily) email listing to kick the project accept or reject the commit. -dain The review-required status and the reports sound like good ideas to me. I also agree that all votes and suggestions should be made in JIRA comments so people don't have to spend a lot of time finding them in emails. John
Re: XBean root POM
On Jun 21, 2006, at 7:05 PM, Alan D. Cabrera wrote:
David Blevins wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote:
IIUC, version specific information has snuck into elements that
should be version free, e.g. scm. Here is a list of elements
that should have version information removed:
scm
build...remoteRepositoryUrl
distributionManagment
Not sure how this got there, it should point to trunk
scm
connectionscm:svn:http://svn.apache.org/repos/asf/geronimo/
xbean/tags/xbean-2.4/connection
developerConnectionscm:svn:https://${maven.username}
@svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-2.4/
developerConnection
urlhttp://svn.apache.org/repos/asf/geronimo/xbean/tags/
xbean-2.4/url
/scm
No wonder Continuum is very unhappy with XBean...
http://ci.gbuild.org/continuum/servlet/continuum
... it will check the code out from *exactly* where you point it to.
-David
How odd. I would think that continuum would take its cue from
something more continuum specific, not the project SCM url.
Yea, you can install an entire set of projects by just pointing
continuum at the parent pom file or uploading it via browser.
-David
[jira] Commented: (GERONIMO-1563) Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417233 ] David Jencks commented on GERONIMO-1563: sorry for the delay. Can you be more specific about the problems you find? I regard this as a fairly small feature and think that if we can't make patch review work for something this size we need a different development process. I'm hoping to finish the namespace-driven-builder stuff in the next day or two and provide a possible final patch candidate. Make the JACC implementation pluggable -- Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Attachments: GERONIMO-1563-step2.1-v1-openejb.diff, GERONIMO-1563-step2.1-v1.diff, GERONIMO-1563-step2.1-v2-openejb.diff, GERONIMO-1563-step2.1-v2.diff Currently we are hardcoded into using our JACC implementation. This means we can't use third party authorization/security servers such as Tivoli AM. The runtime hardcoding is that the installation of the spec permissions into the policy configuration is mixed in with pushing our proprietary principal-role mapping into the policy configuration. The build time hardcoding is that the only proprietary security configuration we accept is our own xml for principal-role mapping, and we insist on it being present. Some steps for this: 1. make separate gbeans for the spec and proprietary access to the policy configuration. These should be connected by an interface, and the spec gbean should control the proprietary gbean and pass it the contextIds in the current application. 2. The security builder should be partly namespace driven, with the proprietary xml interpretation driven by the namespace. 2.a the base security builder should construct the ApplicationPolicyConfigurationGBean and hand off to the namespace-selected gbean for the proprietary stuff. 2.b the proprietary-xml builder should install the role-mapper gbean with the info needed for e.g. principal-role mapping. When we're done with this we should be able to support e.g. IBM pluggable JACC implementations that support their role-mapping capabilities by just writing an xml format and a gbean that pushes role mapping info into their interfaces. The ibm interfaces are explained here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html If anyone knows how other app servers configure the non-spec part of JACC references would be very much appreciated. -- 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: (GERONIMODEVTOOLS-83) Build fails for plugin org.apache.geronimo.st.v11.ui
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Donald Woods updated GERONIMODEVTOOLS-83:
-
Summary: Build fails for plugin org.apache.geronimo.st.v11.ui (was:
Build fails for plugin org.apache.geronimo.st.v1.core)
Environment: WinXP, Sun Java 1.4.2_12, Maven 2.0.4 (was: WinXP, Sun Java
1.4.2_08, Maven 2.0.4)
Priority: Blocker (was: Major)
Build is still failing, but in a later module, with the latest Rev414960 from
6/16/06 -
[INFO]
[INFO] Building org.apache.geronimo.st.v11.ui
[INFO]task-segment: [install]
[INFO]
[INFO] [geronimodevtools:download {execution: create-eclipse-image}]
[INFO] emf-sdo-xsd-SDK-I20060615.zip already exists in local repository
[INFO] JEM-SDK-1.2RC2.zip already exists in local repository
[INFO] GEF-SDK-3.2RC4.zip already exists in local repository
[INFO] wtp-sdk-S-1.5RC4-200605310507.zip already exists in local repository
[INFO] eclipse-SDK-3.2RC7-win32.zip already exists in local repository
[INFO] [geronimodevtools:download {execution: install-dependencies}]
[INFO] emf-sdo-xsd-SDK-I20060615.zip already exists in local repository
[INFO] JEM-SDK-1.2RC2.zip already exists in local repository
[INFO] GEF-SDK-3.2RC4.zip already exists in local repository
[INFO] wtp-sdk-S-1.5RC4-200605310507.zip already exists in local repository
[INFO] eclipse-SDK-3.2RC7-win32.zip already exists in local repository
[INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
[INFO] [geronimodevtools:install {execution: install-dependencies}]
[INFO] org.eclipse.wst.server.ui : 1.0.102.v20060530 already exists in local
repository.
[INFO] org.eclipse.swt.win32.win32.x86 : 3.2.0.v3232l already exists in local
repository.
[INFO] org.eclipse.swt : 3.2.0.v3232l already exists in local repository.
[INFO] org.eclipse.emf.common : 2.2.0.v20060615 already exists in local
repository.
[INFO] org.eclipse.core.contenttype : 3.2.0.v20060601a already exists in local
repository.
[INFO] org.eclipse.ui.workbench : 3.2.0.I20060602-0010 already exists in local
repository.
[INFO] org.eclipse.emf.edit : 2.2.0.v20060615 already exists in local
repository.
[INFO] org.eclipse.wst.server.core : 1.0.102.v20060530 already exists in local
repository.
[INFO] org.eclipse.core.runtime : 3.2.0.v20060601b already exists in local
repository.
[INFO] org.eclipse.jst.server.generic.ui : 1.0.100.v20060516d already exists in
local repository.
[INFO] org.eclipse.emf.ecore : 2.2.0.v20060615 already exists in local
repository.
[INFO] org.eclipse.equinox.registry : 3.2.0.v20060601 already exists in local
repository.
[INFO] org.eclipse.jdt.launching : 3.2.0.v20060525 already exists in local
repository.
[INFO] org.eclipse.jface : 3.2.0.I20060602-0010 already exists in local
repository.
[INFO] org.eclipse.core.resources : 3.2.0.v20060601a already exists in local
repository.
[INFO] org.eclipse.equinox.preferences : 3.2.0.v20060601 already exists in
local repository.
[INFO] org.eclipse.ui : 3.2.0.I20060602-0010 already exists in local repository.
[INFO] org.eclipse.core.jobs : 3.2.0.v20060601a already exists in local
repository.
[INFO] org.eclipse.jst.server.core : 1.0.102.v20060530 already exists in local
repository.
[INFO] org.eclipse.jst.server.generic.core : 1.0.100.v20060530 already exists
in local repository.
[INFO] org.eclipse.wst.common.modulecore : 1.0.100.v200605262006 already exists
in local repository.
[INFO] org.eclipse.osgi : 3.2.0.v20060601 already exists in local repository.
[INFO] org.eclipse.equinox.common : 3.2.0.v20060601a already exists in local
repository.
[INFO] org.eclipse.ui.forms : 3.2.0.v20060530 already exists in local
repository.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING] POM for 'geronimo:geronimo-system:pom:1.1-SNAPSHOT:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'geronimo:geronimo-deploy-jsr88:pom:1.1-SNAPSHOT:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'openejb:openejb-builder:pom:2.1:compile' is invalid. It will
be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[WARNING] POM for 'geronimo:geronimo-kernel:pom:1.1-SNAPSHOT:compile' is
invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM.
[INFO] [compiler:compile]
Compiling 22 source files to
E:\working\eclipse\plugins\org.apache.geronimo.st.v11.ui\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
[jira] Commented: (GERONIMO-1563) Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12417235 ] Alan Cabrera commented on GERONIMO-1563: I did a fresh checkout of Geronimo and OpenEJB trunk/openej2 and fed the patches in and got errors. I also see in your comment that I need to apply MXMLBEANS-20 as well? Make the JACC implementation pluggable -- Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Attachments: GERONIMO-1563-step2.1-v1-openejb.diff, GERONIMO-1563-step2.1-v1.diff, GERONIMO-1563-step2.1-v2-openejb.diff, GERONIMO-1563-step2.1-v2.diff Currently we are hardcoded into using our JACC implementation. This means we can't use third party authorization/security servers such as Tivoli AM. The runtime hardcoding is that the installation of the spec permissions into the policy configuration is mixed in with pushing our proprietary principal-role mapping into the policy configuration. The build time hardcoding is that the only proprietary security configuration we accept is our own xml for principal-role mapping, and we insist on it being present. Some steps for this: 1. make separate gbeans for the spec and proprietary access to the policy configuration. These should be connected by an interface, and the spec gbean should control the proprietary gbean and pass it the contextIds in the current application. 2. The security builder should be partly namespace driven, with the proprietary xml interpretation driven by the namespace. 2.a the base security builder should construct the ApplicationPolicyConfigurationGBean and hand off to the namespace-selected gbean for the proprietary stuff. 2.b the proprietary-xml builder should install the role-mapper gbean with the info needed for e.g. principal-role mapping. When we're done with this we should be able to support e.g. IBM pluggable JACC implementations that support their role-mapping capabilities by just writing an xml format and a gbean that pushes role mapping info into their interfaces. The ibm interfaces are explained here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html If anyone knows how other app servers configure the non-spec part of JACC references would be very much appreciated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 -dain On Jun 21, 2006, at 7:06 PM, Alan D. Cabrera wrote: +1 I think that we should mention that patches that go into x.y.z also go into x.y and trunk x.y also go into trunk Last time we neglected to apply patches evenly across the board when fixes were checked into one branch. This is one reason why the versions drifted so wildly apart. Regards, Alan David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 On 6/21/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: +1 I think that we should mention that patches that go into x.y.z also go into x.y and trunk x.y also go into trunk Last time we neglected to apply patches evenly across the board when fixes were checked into one branch. This is one reason why the versions drifted so wildly apart. Regards, Alan David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (GERONIMO-2135) Improve the ActiveMQ GBeans
[
http://issues.apache.org/jira/browse/GERONIMO-2135?page=comments#action_12417237
]
Gianny Damour commented on GERONIMO-2135:
-
I had a look to the patch and vote +1 for it. Some more details:
1. is fixed.
2. is not fixed.
3. is partially fixed
4. is not fixed
5., 6. and 7. do not know
8. is fixed. Also, it seems that we also avoid abstract from methods in
interfaces (one occurence in BrokerServiceGBean).
Improve the ActiveMQ GBeans
---
Key: GERONIMO-2135
URL: http://issues.apache.org/jira/browse/GERONIMO-2135
Project: Geronimo
Type: Improvement
Security: public(Regular issues)
Components: ActiveMQ
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Fix For: 1.2
Attachments: GERONIMO-2135.patch
Suggestions by David Jencks:
I think that this gbean adaptation code should be in geronimo rather
than amq. I'm OK with applying it as is but would prefer some issues
to be addressed first or, even better, immediately after the
transfer (assuming it is done with svn mv).
1. DataSourceReference should be replaced by the geronimo class that
does the same thing, ConnectionFactorySource.
2. I think it would be preferable to get the module/configuration
classloader in the constructor as a magic attribute and use it in
BrokerServiceGBeanImpl.doStart rather than the classloader of
BrokerServiceGBeanImpl.
3. Same for TransportConnectorGBeanImpl.
4. This is a question, not really an issue, about this code:
+protected TransportConnector createBrokerConnector(String url)
throws Exception {
+return brokerService.getBrokerContainer().addConnector(url);
+}
To me it seems like this code is combining the functions of factory
object and container. Is this necessary and appropriate? I'd be
more comfortable with
Connector connector = ConnectorFactory.createConnector(url);
brokerService.getBrokerContainer().addConnector(connector);
I find that the combination style typically creates problems whenever
trying to extend stuff, say by wrapping the connector. What do you
think?
5. hardcoding the protocols in ActiveMQManagerGBean seems like a
temporary expedient at best.
6. javadoc on public JMSConnector addConnector( ... in the manager
gbean seems wrong... does not appear to return an object name.
7. Typo and innaccuracies in the first package.html... this stuff is
only going to work in geronimo, jsr77/88 is not enough.
8. I'm not sure exactly what our official policy is but I prefer to
remove public from methods in interfaces since it is the only
choice and implied.
--
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: Update on 1.1 Final2 Voting Status - Tally so far
+1 Look great! I tried it out all 4 binaries in a path containing spaces, and installed a few plugins from the cli, console and examples. Sorry it took me so long, -dain On Jun 21, 2006, at 2:20 AM, Matt Hogstrom wrote: Here is the current status of voting. I know we've had several issues we had to work through wrt to licenses and other issues that have caused some respins. At this point I think we're green for the release. Please take a few minutes to cast your vote and we can get this release wrapped up, 1.1.1 started and move on. +1 from PMC Members Davanum Srinivas Sachin P. Patel *PMC Members who have not voted:* Geir Magnusson Jr. Gianny D'Amour Greg Wilkins Jacek Laskowski Jan Bartel John R. Sisson (I believe your +1 in the thread was to keep the vote going and not a vote for the release) Jules Gosnell Ken Coar +1 from Committers David Blevins Alan Cabrera Hernan Cunico Matt Hogstrom Rick McGuire *Commiters who have not voted:* Aaron Mulder Bruce Snyder Dain Sundstrom David Jencks Hernan Cunico Hiram R. Chirino James Strachan Jason Dillon Jeff Genender Jeremy Boynes Kevan Miller Mark DeLaFranier Simone Bordot Srinath Perera
Re: [VOTE] 1.1 Release
I did a sniff test of the installed product and I think we are good to go. +1 from me. I shall grill it some more tomorrow. Cheers Prasad On 6/19/06, Hernan Cunico [EMAIL PROTECTED] wrote: John Sisson wrote: Some notes in relation to documentation: * Clicking on the the Geronimo Documentation link on http://myhost:8080/ takes me to http://geronimo.apache.org/documentation.html which doesn't currently have any 1.1 documentation. What are the plans for the 1.1 documentation? I'm planning to update the web site today so it will point to the new cwiki with the 1.0 and 1.1 (inprogress) documentation * Clicking on the Additional Documentation link on http://myhost:8080/ takes me to http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Home which contains a warning that the documentation has moved to http://cwiki.apache.org/geronimo . Are we planning on changing this to take users directly to http://cwiki.apache.org/geronimo ? Additional Documentation is using a redirect (http://geronimo.apache.org/redirects/additionalDocumentation.html) to point to the Atlassian confluence. Fixing this redirect is part of the web site update. I just froze (for edit) the confluence installation at Atlassian so we will not have more adds there (wanted or unwanted). I've been adding labels to some pages on that installation to point to the new cwiki.apache.org/geronimo. As far as I know, we can not add an automatic redirect directly from a confluence page. Cheers! Hernan Other comments in-line below.. I'm still kicking the tires.. John Matt Hogstrom wrote: All, I have created what I hope is the final release of Geronimo 1.1. There has been a lot of work that has gone into this release (please review the RELEASE-NOTES). Here are the final release candidates for your review. *DayTrader Application* http://people.apache.org/~hogstrom/1.1-final/daytrader-ear-1.1.ear I'm working on a website and documentation to help folks out but the deliverable is the ear above. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-1.1_src.zip *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-j2ee-1.1.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-jetty-minimal-1.1.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-j2ee-1.1.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.tar.gz http://people.apache.org/~hogstrom/1.1-final/geronimo-tomcat-minimal-1.1.zip *Geronimo 1.1 Source Code* FYI (in case you re-use this mail) the line above should read *Geronimo 1.1 Specs* http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.tar.gz http://people.apache.org/~hogstrom/1.1-final/org.apache.geronimo.specs.zip Is there are reason why the specs distributions don't have a version in their file name? Shouldn't it be 1.0.1? Please remember that only PMC votes are binding but they will ultimately make their decision based on your feedback. Thanks to everyone who has spent long hours working on this. A special thanks to Jencks, Sisson and Miller who spent long days working on getting the final release right with License issues, last minute release note changes, etc. I look forward to a positive outcome and a unanimous vote by Sunday. Assuming all goes well by Sunday night I will propogate the jars to the mirrors on Sunday and declare the release official on Tuesday. Cross your fingers, grab your beverage of choice and let's close this release out. Matt
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
David, Thanks for that excellent recap. +1 from me. +1 to Alan's comment that all patches to branches should also be applied to the trunk. Any future x.(y+1) branch should come from the trunk and not from the recently frozen x.y.z branch. Cheers Prasad On 6/21/06, Hiram Chirino [EMAIL PROTECTED] wrote: +1 On 6/21/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: +1 I think that we should mention that patches that go into x.y.z also go into x.y and trunk x.y also go into trunk Last time we neglected to apply patches evenly across the board when fixes were checked into one branch. This is one reason why the versions drifted so wildly apart. Regards, Alan David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Liferay Plugin for G
Hi everyone, It's great to see the traction going on in the Geronimo world. Just signed up for the dev list so I'm happy to participate. In our next release of Liferay 4.1.0, we'll: 1.) Upgrade to the latest Geronimo 1.1 (even if it's just a pre zip until 1.1 gets voted final). 2.) Use Derby instead of HSQL. (Thanks to Paul!) Liferay, by default (because our users are now used to it), deploys itself to / That isn't mandatory though. So for our plugin, we just have to make it map to something like /portal or /liferay instead. It requires one xml change and one property change. I'm also working with Jeff Genender to also get the EJB version out soon too. Thanks all. -- Brian Chan Chief Executive Officer Liferay, LLC Enterprise. Open Source. For Life.
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
David Blevins wrote: The only thing done in a branches/x.y.z made from branches/x.y is the release process itself. I don't quite understand what this means. Sorry. When we agree we look good enough to cut and run, we freeze, make the branch and put together a release candidate. At the point of the freeze the release manager owns the branches/x.y.z till the vote passes. That's the ideal scenario anyway. -David On Jun 21, 2006, at 9:40 PM, Jason Dillon wrote: Does this mean that the bulk of changes will be done on M.m branches and only release + minor changes done on M.m.r branches? --jason On Jun 21, 2006, at 6:52 PM, David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
Re: [announce] Apache Geronimo welcomes Joe Bohn as our newest committer
Sachin Patel wrote: In recognition of his contributions to the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Joe Bohn. Joe has contributed in many areas, including the console and as of recent, the work on our minimal distributions. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. We look forward to his continued involvement as a committer. Please join us in congratulating Joe. The Apache Geronimo PMC Welcome aboard! Regards, Alan
