Website Up!
http://activemq.apache.org/ is live :-) No we need to remove the Incubator stuff from it :-) -Brian
Re: Are we graduated yet?
Doh! I have been so pre-occupied with work I didn't mention. Bad me! We graduated! Now to start pestering infra... ;-) -Brian On Jan 22, 2007, at 3:34 PM, Guillaume Nodet wrote: Yeah, I was expecting the board resolution to be voted, as I'm not sure it is yet ... In all cases, I guess the next steps are to move all the resources to their final destination (activemq.apache.org), this includes mailing lists, svn repo and web site (did I miss something ?) On 1/22/07, Hiram Chirino [EMAIL PROTECTED] wrote: From some of the posts in the incubator lists, it sounds like were have now graduated. If this is so, what are the next steps? -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet Architect, LogicBlaze (http://www.logicblaze.com/) Blog: http://gnodet.blogspot.com/
Re: Release schedule
4.1 has been released. -Brian On Dec 18, 2006, at 11:40 AM, sileshi wrote: Is 4.1 released? If not, what is rlelease plans? -Sileshi Hiram Chirino wrote: On 10/4/06, yaussy [EMAIL PROTECTED] wrote: Sorry about that. I'd forgotten about the wireformat stuff. Looks like you can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ 4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together). This gives me the rollout path we need. Since 4.0.2 has not been officially released, which 4.0.2 versin are you using? RC4 ? I think 4.0.2 RC 4 should be able to connecto the 4.1 without any config changes. A small bug in 4.0 was fixed in 4.0.2 that fixes auto wirefomat versin negociation. Two things though: 1) I could not get multiple connection properties on the TCP connectors, such as tcp://perfgc1a::5112? minmumWireFormatVersion=1connectionTimeout=5000. The XML parser complained. How should this look?? in XML you need replace all the '' with 'amp;' 2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect using their newer v2 format? Hum they should. Sees odd that the default is not 1... it should be 1. I'll double check. Thanks for testing this stuff out! yaussy wrote: I put a post in the user forum for this, but thought I'd add something to this thread. I'm concerned about backward compatibility. I've got a test environment with all brokers at 4.0.1, except one I'm upgrading to 4.1. This would be how our production environment would be upgraded - a machine or so at a time. However, the 4.0.1 brokers will not connect to the 4.1 broker, giving the following exception: Exception in thread ActiveMQ Transport: tcp:/// 170.137.15.160:34695 java.lang.IllegalArgumentException: Invalid version: 2, could not l oad org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.openwire.OpenWireFormat.setVersion (OpenWireFormat.java:329) at org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat (OpenWireFormat.java:569) at org.apache.activemq.transport.WireFormatNegotiator.onCommand (WireFormatNegotiator.java:100) at org.apache.activemq.transport.InactivityMonitor.onCommand (InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume (TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run (TcpTransport.java:143) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.activemq.openwire.v2.MarshallerFactory at org.apache.activemq.util.ClassLoading.loadClass (ClassLoading.java:104) at org.apache.activemq.openwire.OpenWireFormat.setVersion (OpenWireFormat.java:327) ... 6 more There must be an upgrade path for 4.1. If that means I have to go to 4.0.2 (which I did not try yet), that is OK. But, I can't possibly tell my management that I have to upgrade the AMQ version on all 50 or so machines we have in production. Hiram Chirino wrote: I'm starting to work on the first release candidate for 4.1.. please let me know if I should hold off! On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: Hi James, It looks like this is changed now with 4.0.3. Any idea when 4.1 is going to be out? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6630219 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a6647640 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com -- View this message in context: http://www.nabble.com/Release- schedule-tf2124265.html#a7935126 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Latest official release
4.1.0 has been officially released :-) -Brian On Dec 6, 2006, at 2:40 PM, bluedolphin wrote: Sorry, i get confused. Currently yes. The 4.1 release is still in voting?. Is it mean that 4.1 still unofficially released? Thanks James.Strachan wrote: On 11/28/06, nabble615 [EMAIL PROTECTED] wrote: Hi, may I know whether the latest official activemq release is 4.0.2? Currently yes. The 4.1 release is still in voting; its looking good so hopefully should pass in the next day or so May I know when is the released date of it as well? Thanks It was released a few weeks ago http://www.nabble.com/-ANN--Apache-ActiveMQ-4.0.2-released%21- tf2627759.html -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/Latest-official- release-tf2717760.html#a7729594 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release Apache ActiveMQ 4.1.0 (RC 2)
+1 -Brian On Nov 21, 2006, at 8:43 AM, Adrian Co wrote: +1 :) Hiram Chirino wrote: Howdy ActiveMQ Mentors... This is just a gentle reminder that this vote is still open and looking for at least 1 more incubator PMC binding vote to make it official. Please take a moment and review the release. Thanks! On 11/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hey folks, I was able to finally get around to doing a binary release candidate from the 4.1 branch. it's available here: http://people.apache.org/~chirino/incubator-activemq-4.1.0-RC2/m2- incubating-repository/org/apache/activemq/apache-activemq/4.1.0- incubator/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.1.0-RC2 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-410-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.1.0 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switching to ActiveMQ 4.2 to Java 5???
I am all for it, personally, with 1.6 due out any week now. -Brian On Nov 15, 2006, at 8:48 AM, Hiram Chirino wrote: Hi folks, How do you guys feel about switching the minimum run time requirement for ActiveMQ 4.2 to be Java 5?? I'm itching to do this since Java 5 has a much better set of concurrent implementation. We can keep the 4.1.x branch alive as the Java 1.4 compatible version. Also I have a feeling that once we switch to Java 5, someone will figure out how to use retrotranslator to make our Java 5 binaries also run on Java 1.4. But I doubt anybody will make any efforts to look into that until we actually jump to Java 5. So what do you say? Shall we switch ?? -- Regards, Hiram Blog: http://hiramchirino.com
Re: Now that 4.0.2 is release should we start the Graduation ball rolling?
Yes! We should present a fully formed resolution, based on the OFBiz thread. -Brian On Nov 15, 2006, at 10:52 AM, Hiram Chirino wrote: I think this project is like the 40 year old virgin still living at home with his parents. lol! Don't you think it's about time we get the ball rolling on graduating our of the incubator? -- Regards, Hiram Blog: http://hiramchirino.com
Re: Now that 4.0.2 is release should we start the Graduation ball rolling?
On Nov 15, 2006, at 12:14 PM, Hiram Chirino wrote: Want to take the lead on that? :) please! Sure. Any nominations for proposed PMC Chair? -Brian On 11/15/06, Brian McCallister [EMAIL PROTECTED] wrote: Yes! We should present a fully formed resolution, based on the OFBiz thread. -Brian On Nov 15, 2006, at 10:52 AM, Hiram Chirino wrote: I think this project is like the 40 year old virgin still living at home with his parents. lol! Don't you think it's about time we get the ball rolling on graduating our of the incubator? -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 6)
+1 -Brian On Oct 29, 2006, at 6:53 PM, Hiram Chirino wrote: Some last minute NOTICE issues were still present in the 5th release candidate of the 4.0.2 build. We have also received confirmation from Apache legal discuss that it's ok to include work covered by the Creative Commons Attribution license. I have cut and RC 6 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC6/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC6 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-402-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 5)
+1 -Brian On Oct 19, 2006, at 10:13 AM, Hiram Chirino wrote: Some copyright header/licence/notice issues were found in the 4th release candidate of the 4.0.2 build. I have cut and RC 5 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC5 Here's the wiki page for the release notes: http://incubator.apache.org/activemq/activemq-402-release.html Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) This vote is being cross posted to the general incubator mailing list also to expedite the voting process. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Re: who's going to ApacheCon Austin?
I'll be there! -Brian On Oct 7, 2006, at 9:24 AM, Nathan Mittler wrote: Hey everyone, Just wondering who was going from the ActiveMQ crowd. Tim Bish and I received the approval to take a company-sponsored boondoggle for our first ApacheCon :) ... should be a good opportunity to put names with faces. Nate
Re: Pluggable Stomp/AMQ translation
I've applied Dejan's patch locally, but it needs some changes to preserve the current behavior. I'll make them and check it in within a couple days. -Brian On Oct 6, 2006, at 7:56 AM, Brian McCallister wrote: D'oh, I did miss it, and it is a better solution :-) I'll roll back my change later this morning and apply yours. Apparently, we think alike, we have the exact same interfaces, you have a much better way of selecting mappings though! -Brian On Oct 6, 2006, at 12:22 AM, Dejan Bosanac wrote: Hi Brian, did you check my patch with similar functionality ( https://issues.apache.org/activemq/browse/AMQ-943). I've implemented Hiram's idea: Translator (Mapper in that patch's terminology) is selected when the client sends a CONNECT message, according to the value of the protocol- mapping header. For example, protocol-mapping: byte will mark that client expects byte messages. In that moment it uses a FactoryFinder to look up for the appropriate transalator. FactoryFinder searches through all META-INF/services/org/apache/activemq/transport/mapping/ folders (we can change this name if necessary) in all classpath JARs. If it finds a byte file (for example) it will read a class name that implements the byte messages translation ( org.apache.activemq.transport.stomp.ByteProtocolMapping in this case) and use it to translate messages. If desired mapper is not found (or not specified in the first place) the default mapper (translator) will be used. In this way there is no need for any external configuration for the framework. You simply provide the JAR with the appropriate META- INF content and the translator is automatically registered. Maybe you can use some of these ideas for your solution or we can merge them in one. Regards, Dejan On 10/6/06, Brian McCallister [EMAIL PROTECTED] wrote: Just checked in a first take on pluggable stomp to amq translation. Right now there is one interface defined for doing both message conversions and destination name conversions. The behavior for the legacy conversion scheme is identical, I just moved the code around so that those four functions could be varied. Right now it takes the FrameTranslator instance off the transport factory. This probably isn't ideal, but I wanted to talk about the best way to do it here before trying to muck around with xbean. -Brian ps: Speaking of xbean, has anyone considered making a less sysadmin- hostile configuration scheme than java class names mapped not-quite- obviously into XML?
[jira] Assigned: (AMQ-943) Pluggable Stomp Message Mapping
[ https://issues.apache.org/activemq/browse/AMQ-943?page=all ] Brian McCallister reassigned AMQ-943: - Assignee: Brian McCallister Pluggable Stomp Message Mapping --- Key: AMQ-943 URL: https://issues.apache.org/activemq/browse/AMQ-943 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 4.1 Reporter: Dejan Bosanac Assigned To: Brian McCallister Fix For: 4.1 Attachments: protocol-mapping.patch I have finally found time to finish this. Here's the draft version of the Pluggable Stomp Message Mapping implementation. Few notes: - New interface has been defined: ProtocolMapping (I wanted to use the same name as the message header that we check) - There are two implementations of this interface: DefaultProtocolMapping and ByteProtocolMapping - I used FactoryFinder to create appropriate mapper. The finder use the following path to find keys: META-INF/services/org/apache/activemq/transport/mapping/ (we can change this if you want) - The appropriate mapper is used according to the protocol-mapping header in the CONNECT message. For example protocol-mapping:byte for ByteProtocolMapping handler. - Currently I have implemented only the mapper for BytesMessage since I wasn't sure whether you want to integrate JSON mapper for MapMessages or distribute it in a separate library. - I have changed the test case that tests subscription for byte messages - This solution is not compatible with current mapping for byte messages. If you want backward compatibility, I can hard-code it in a ProtocolConverter class (as it was) since it could not be implemented through this mechanism. TODO: - test it more (create more unit test cases and test it more in a real environment) - create a proper documentation so others can create their handlers. - create a proper JavaDoc documentation for key interfaces and classes - create JSON mapper (integrated or external) - fix STOMP client(s) Give it a try and let me know your impressions Dejan Bosanac -- 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: Pluggable Stomp/AMQ translation
D'oh, I did miss it, and it is a better solution :-) I'll roll back my change later this morning and apply yours. Apparently, we think alike, we have the exact same interfaces, you have a much better way of selecting mappings though! -Brian On Oct 6, 2006, at 12:22 AM, Dejan Bosanac wrote: Hi Brian, did you check my patch with similar functionality ( https://issues.apache.org/activemq/browse/AMQ-943). I've implemented Hiram's idea: Translator (Mapper in that patch's terminology) is selected when the client sends a CONNECT message, according to the value of the protocol- mapping header. For example, protocol-mapping: byte will mark that client expects byte messages. In that moment it uses a FactoryFinder to look up for the appropriate transalator. FactoryFinder searches through all META-INF/services/org/apache/activemq/transport/mapping/ folders (we can change this name if necessary) in all classpath JARs. If it finds a byte file (for example) it will read a class name that implements the byte messages translation ( org.apache.activemq.transport.stomp.ByteProtocolMapping in this case) and use it to translate messages. If desired mapper is not found (or not specified in the first place) the default mapper (translator) will be used. In this way there is no need for any external configuration for the framework. You simply provide the JAR with the appropriate META-INF content and the translator is automatically registered. Maybe you can use some of these ideas for your solution or we can merge them in one. Regards, Dejan On 10/6/06, Brian McCallister [EMAIL PROTECTED] wrote: Just checked in a first take on pluggable stomp to amq translation. Right now there is one interface defined for doing both message conversions and destination name conversions. The behavior for the legacy conversion scheme is identical, I just moved the code around so that those four functions could be varied. Right now it takes the FrameTranslator instance off the transport factory. This probably isn't ideal, but I wanted to talk about the best way to do it here before trying to muck around with xbean. -Brian ps: Speaking of xbean, has anyone considered making a less sysadmin- hostile configuration scheme than java class names mapped not-quite- obviously into XML?
Pluggable Stomp/AMQ translation
Just checked in a first take on pluggable stomp to amq translation. Right now there is one interface defined for doing both message conversions and destination name conversions. The behavior for the legacy conversion scheme is identical, I just moved the code around so that those four functions could be varied. Right now it takes the FrameTranslator instance off the transport factory. This probably isn't ideal, but I wanted to talk about the best way to do it here before trying to muck around with xbean. -Brian ps: Speaking of xbean, has anyone considered making a less sysadmin- hostile configuration scheme than java class names mapped not-quite- obviously into XML?
Pluggable Stomp Message Mapping (was: [stomp-dev] PHP Stomp Client)
(Replying at top as it is a long message :-) The mapping be configured by naming a converter of some kind in the activemq.xml This is a bit tricksier than it might be because the activemq.xml is just a specialized spring config which reads a lot of stuff from a URL syntax, and adding Java classnames in a URL is the ick. I've started poking around and my current plan is to pull the AMQ message creating and Stomp message creation bits out of the protocol converter and use an implementation of some mapping interface to do the conversion. Exactly what the interface needs to look like I am not sure yet. In order to handle largish messages, it should probably deal with DataInput (AMQ's stream/buffer+channel hiding thing) instances, but we'll have had to already parse the type to get this far, so it may be a case of doing some parsing of the headers, and passing the data input in to be munged, or it may fall out that something else is more useful. For encoding AMQ to stomp, we are faced with something similar -- we pass in the JMS message, which might be a stream message with a large body, we probably want to be able to chunk it out, that means either making a stomp frame abstraction which can read from a stream and is returned by the converter, or having the converter actually send the message on the wire. Not sure which I like more. Thoughts? -Brian On Sep 18, 2006, at 7:45 AM, Dejan Bosanac wrote: Thanks James. We've a Stomp transport for ActiveMQ which is here... http://incubator.apache.org/activemq/maven/activemq-core/xref/org/ apache/activemq/transport/stomp/package-summary.html which can currently deal with all the stomp messages nicely. Maybe you mean to extend that? Or did you have something else in mind? In one of his comments Brian said that he plans to create pluggable handling framework for stomp messages for ActiveMQ 4.1. Following that idea, I have even found a discussion on this topic http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/ 200606.mbox/% [EMAIL PROTECTED] which is related to handling of ByteMessages. I thought that this is exactly what I would like to have for handling of this kind of map messages. As I see it, it would be the best to extend functionality of the public ActiveMQMessage convertMessage(StompFrame command) method in the org.apache.activemq.transport.stomp.ProtocolConverter class I can add hard-coded mapping for this special case, or as Brian said, introduce some additional flexibility by allowing developers to submit their own converter classes at this point. Who knows what other protocol on top of Stomp someone would be interesting to create in the future (or what kind of object serialization/deserialization to perform). The only thing that I'm not sure of is how these plugins would be configured. In any case, I won't start doing any work on this before we agree on how this functionality should look like, or whether it is necessary to make any changes at all. Dejan - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
Re: Stomp durable topics - implementation
Hmm, I can look into this but won't have a good opportunity to until after September 9 (a week and half from now). If you dig into the stomp transport stuff, it shouldn't be terribly difficult to put in, but... that is a guesstimate. If it hasn't been done by Sept 9 I can dig through, but cannot promise to before then :-( -Brian On Aug 29, 2006, at 1:11 PM, Sandeep Chayapathi wrote: apologies for cross posting this. I think this is a bug and hence Im posting the same in the dev mailing list: Hi all, This is regarding my last query (http://www.nabble.com/forum/ViewPost.jtp?post=6040430framed=y http://www.nabble.com/forum/ViewPost.jtp?post=6040430framed=y). I was grokking the source code, vis-a-vis Stomp and durable topic, looks like the documentation regarding the custom headers, is not in sync with the source code, i.e nohwere in the source code could I find a reference to the following custom headers: activemq.subscriptionName and subscriberName. Any idea on how much effort is required to implement these ? I might be wrong, it would help if anyone can point me in the right direction. Thanks. - Sandeep
Removing snapshots from dist directory
Hey folks, I want to go remove the snapshots and RC's from our dist directory. They realy shouldn't be there. Any objections? -Brian
Re: Coding style, specifically 80 characters
I generally do 120 as well :-) -Brian On Aug 24, 2006, at 2:20 PM, Guillaume Nodet wrote: Agreed. 120 is much more useful :) On 8/24/06, Jason Dillon [EMAIL PROTECTED] wrote: I think the 80 char limit is antiquated... now that most folks have displays that can quite easily display more than 80 columns. Limiting lines to 80 tends to force folks to artificially reformat code which just uglies things up. --jason On Aug 24, 2006, at 1:56 PM, Sepand M wrote: Hi guys, Do you have a coding style that I should go by? Specifically, do you use the 80 chars/line limit? I see a lot of code that doesn't, so I haven't, but it's bugging me more and more by the second. Regards, Sepand -- Cheers, Guillaume Nodet
Fwd: [stomp-dev] messages are not redelivered in activemq-4.0.2
Begin forwarded message: From: Jeff Tupholme [EMAIL PROTECTED] Date: August 18, 2006 9:17:17 AM PDT To: [EMAIL PROTECTED] Subject: [stomp-dev] messages are not redelivered in activemq-4.0.2 Reply-To: [EMAIL PROTECTED] Hoping for some help in understanding STOMP semantics. incubator-activemq-4.0.2 My test application sends two messages to queueA, starts a new connection which subscribes to queueA, then processes each message in its own transaction. When a transaction is aborted I expected its message to be redelivered but this doesn't happen. Opening a new connection and resubscribing picks up the aborted message but it is not marked as being redelivered. In the Java test code for ActiveMQ it appears that a message within a rolled-back transaction is redelivered to the session almost immediately (./incubator-activemq-4.0.2/src/test/java/org/apache/ activemq/usecases/Trans actionRollbackOrderTest.java). I noticed that each time my program sends a message ACK ActiveMQ throws NullPointerException (see below). At this point I'm not sure how much functionality STOMP is intended to offer so I might be wrong to report this as a bug. Before I report another bug - Is it supposed to be possible to interleave transactions on a single connection? Thanks! Pseudo-code msg1 = receiver.NextMsg() msg1.Begin() -- begin transaction and acknowledge the message msg1.Abort() -- abort transaction msg2 = receiver.NextMsg() msg2.Begin() -- begin transaction and acknowledge the message msg2.Commit() msg3 = receiver.NextMsg() -- expecting msg1 to be redelivered STOMP Protocol Trace CONNECT user: usr passcode: password . CONNECTED session:ID:ubuntu-32784-1155902931062-3:163 . SUBSCRIBE destination: /queue/queueA ack: client . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641587 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:1 0 . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641795 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:2 1 . BEGIN transaction: ba0c02205582f84dfffa90cf75fd2395 . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:1 transaction: ba0c02205582f84dfffa90cf75fd2395 . ABORT transaction: ba0c02205582f84dfffa90cf75fd2395 . BEGIN transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:2 transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . COMMIT transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . CONNECT user: usr passcode: password . CONNECTED session:ID:ubuntu-32784-1155902931062-3:163 . SUBSCRIBE destination: /queue/queueA ack: client . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641587 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:1 0 . MESSAGE destination:/queue/queueA type:null reply-to:null timestamp:1155915641795 priority:0 expires:0 correlation-id:null message-id:ID:ubuntu-32784-1155902931062-3:160:-1:1:2 1 . BEGIN transaction: ba0c02205582f84dfffa90cf75fd2395 . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:1 transaction: ba0c02205582f84dfffa90cf75fd2395 . ABORT transaction: ba0c02205582f84dfffa90cf75fd2395 . BEGIN transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . ACK message-id: ID:ubuntu-32784-1155902931062-3:160:-1:1:2 transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . COMMIT transaction: 3d4bf8b18ca395e9aaa63a7853f3d3af . Java Exception stack trace -- Async error occurred: java.lang.NullPointerException java.lang.NullPointerException at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge (PrefetchS ubscription.java:122) at org.apache.activemq.broker.region.AbstractRegion.acknowledge (AbstractRegion. java:233) at org.apache.activemq.broker.region.RegionBroker.acknowledge (RegionBroker.java :362) at org.apache.activemq.broker.TransactionBroker.acknowledge (TransactionBroker.j ava:176) at org.apache.activemq.broker.BrokerFilter.acknowledge (BrokerFilter.java:65) at org.apache.activemq.broker.BrokerFilter.acknowledge (BrokerFilter.java:65) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge (MutableBrokerFilt er.java:78) at org.apache.activemq.broker.AbstractConnection.processMessageAck (AbstractConn ection.java:382) at org.apache.activemq.command.MessageAck.visit (MessageAck.java:178) at org.apache.activemq.broker.AbstractConnection.service (AbstractConnection.jav a:226) at org.apache.activemq.broker.TransportConnection$1.onCommand (TransportConnecti on.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand (ResponseCorrelato r.java:91) at org.apache.activemq.transport.TransportFilter.onCommand (TransportFilter.java :63) at org.apache.activemq.transport.InactivityMonitor.onCommand (InactivityMonitor. java:122) at
Re: Forming an ActiveMQ PPMC
On Aug 16, 2006, at 12:32 AM, James Strachan wrote: On 8/16/06, Brian McCallister [EMAIL PROTECTED] wrote: The ActiveMQ committers have decided to aim for TLP status (1), as such we need to get a PPMC in place. Thus far we have been working under a committer votes all count style (really, everyone's vote counts, it is on a public list without any of the mine is binding stuff that has become popular), so I would like to open the discussion of formalizing the PPMC as all current committers on ActiveMQ. FWIW we've had a PPMC in place for some time ;) which was mostly the committers plus anyone from Incubator/Geronimo PMCs who wanted to help too. (Brian search your mailbox for activemq-ppmc or activemq-private which is the latest name of the mailing list - I've seen at least 2 posts from you :) Hah, you are right! Okay, I feel stupid. /me is going to find a *lot* more coffee :-)
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 3)
+1 -Brian On Aug 8, 2006, at 1:35 PM, Hiram Chirino wrote: Some NOTICE file issues were found in the 2nd release candidate of the 4.0.2 build. I have cut and RC 3 of the 4.0.2 build with the fixes and it's available here: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3 Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com
Re: Graduate to a TLP?
+1 from me :-) On Aug 1, 2006, at 9:14 AM, Brian McCallister wrote: I'd like to start the ball rolling to have ActiveMQ graduate to a top level project at Apache. The original intent was to become a sub-project of Geronimo, but I think that this would be a disservice to ActiveMQ, which is quite capable of standing on it's own, and therefore, should be a project in itsef rather than expanding the G umbrella. Looking over the incubator checklist, everything seems to have been completed, we have been making releases (a good sign that a project has it together) and I do believe it is time :-) Thoughts? -Brian
Graduate to a TLP?
I'd like to start the ball rolling to have ActiveMQ graduate to a top level project at Apache. The original intent was to become a sub-project of Geronimo, but I think that this would be a disservice to ActiveMQ, which is quite capable of standing on it's own, and therefore, should be a project in itsef rather than expanding the G umbrella. Looking over the incubator checklist, everything seems to have been completed, we have been making releases (a good sign that a project has it together) and I do believe it is time :-) Thoughts? -Brian
Re: [VOTE] Release Apache ActiveMQ 4.0.2
Are you making this change for 4.0.2? -Brian On Jul 28, 2006, at 12:24 AM, James Strachan wrote: Looks good to me. Thanks for sorting this out Hiram. On 7/27/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hey.. I opened issue http://issues.apache.org/activemq/browse/ AMQ-848 to track. Folks please check the new LICENSE https://svn.apache.org/repos/asf/incubator/activemq/branches/ activemq-4.0.2/assembly/src/release/LICENSE.txt It seems to me that both jetty and spring also use the Apache license. I would think it's ok if I remove those copies of the LICENSE right? On 7/27/06, Kevan Miller [EMAIL PROTECTED] wrote: Looks like your base LICENSE and NOTICE files contain only AL 2.0 license information. Since you're releasing code under multiple licenses, according to http://www.apache.org/dev/release.html , all license/notice information needs to be placed there. --kevan On Jul 26, 2006, at 1:26 AM, Hiram Chirino wrote: Since it was brought up, and folks concurred that it's about time to put out a bug fix release for ActiveMQ, I've put together a binary release of ActiveMQ 4.0.2: http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC1/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.2-RC1/ maven1/incubator-activemq/distributions/ http://people.apache.org/%7Echirino/incubator-activemq-4.0.1- RC1/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.2- RC1http://people.apache.org/%7Echirino/incubator-activemq-4.0.2-RC1 http://people.apache.org/%7Echirino/incubator-activemq-4.0.1- RC1/ Here's the wiki page for the release notes (they should soon get mirrored to the activemq static website) : http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2 +Release http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.1 +Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.2 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1 -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: Server 2003 Test Results
Yum, most of the errors seem to be of the form: Caused by: java.lang.RuntimeException: java.net.URISyntaxException: Illegal character in path at index 18: file:/C:/Documents and Settings/administrator/Desktop/incubator-activemq-4.0.1/activemq-core/ target/test-classes/org/apache/activemq/openwire/ DataFileGeneratorTestSupport.class Anyone know what file uri's are supposed to look like on Windows? -Brian On Jul 20, 2006, at 2:46 PM, Rodriguez, Adrian wrote: Here are the results from our test run. Is there anything else we can do to help? thanx =) adrian / activemq_test.txt
Re: Server 2003 Support
Adrian, ActiveMQ is not officially certified on any platform, though we (ActiveMQ developers, or at least me) will certainly try to help you out on pretty much any platform we can. The best thing to do is to download the source distribution and run the test suite. It is pretty comprehensive. If any of the tests fail, or things go haywire, then please let us know and we'll definitely fix it. * Install Maven 2 ( http://maven.apache.org/ ) * Download the source distribution for the version you want to use (I suggest the most recent, 4.0.1 at this time) and unpack it. * Run mvn test in the source directory just unpacked. * Watch test results scroll by for a while (it is a pretty extensive suite, it can take some time). * If anything fails, let us know! :-) On Jul 17, 2006, at 11:41 AM, Rodriguez, Adrian wrote: Hi. I sent this message to the activemq user list but I havne't received a response. I was hoping that some devs might answer my question and give some feedback. We want to know why activemq is not officially supported on Server 2003. If it's just a matter of time (haven't gotten around to validating it on server 2003), we might be able to help out a bit. How do you guys verify that some OS is officially supported? Do you have a test suite that needs to pass? If you have a procedure that we can follow and verify that activemq works correctly on server 2003, we could give the results back to activemq if it would help the project. Thanx =) adrian /
AMQP
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
Re: [VOTE] Release Apache ActiveMQ 4.0.1
+1 Releasing every couple weeks may be a BIT fast though. Perhaps if we have that many outstanding bugs we should rethink how we do release stabilisation? On Jun 16, 2006, at 9:03 PM, Adrian Co wrote: +1 Release ActiveMQ 4.0.1 Regards, Adrian Co Hiram Chirino wrote: Since the 4.0 release a bunch of small bug have been fixed and we felt it better to release early and often, so here are the release binarys for the 4.0.1 version of activemq: http://people.apache.org/~chirino/incubator-activemq-4.0.1-RC1/ maven1/incubator-activemq/distributions/ Maven 1 and Maven 2 repos for this release can be found at: http://people.apache.org/~chirino/incubator-activemq-4.0.1-RC1/ The release notes will show up here as soon as the mirrors catch up... http://incubator.apache.org/activemq/activemq-401-release.html if you are impatient, here's the wiki page for the release notes: http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.1+Release Please vote to approve this release binary [ ] +1 Release the binary as Apache ActiveMQ 4.0.1 [ ] -1 Veto the release (provide specific comments) If this vote passes, then we will then ask the Incubator PMC for their blessing to ship this release officially. Here's my +1
Re: 4.0.1 Release
+1 -Brian On Jun 14, 2006, at 11:44 AM, Hiram Chirino wrote: I'd like ActiveMQ to have follow the release early and release often mantra. So what do you guys think about getting a 4.0.1 release done by early next week? We have already done quite a few bug fixes in the 4.0 branch and I don't think we should hold those back any longer than necessary. -- Regards, Hiram
Re: Graduation
On Jun 15, 2006, at 1:06 PM, Alan D. Cabrera wrote: I wonder if we're big enough to be a TLP. Thoughts? (very big) +1 to TLP. We have plenty of folks to provide oversight, and the scope is too big to fit well in any umbrella. -Brian
Re: STOMP and JMSType
On Jun 13, 2006, at 3:06 PM, Nathan Mittler wrote: So it sounds like we're all in agreement on the content-type header. For text, it would be something like text and for bytes it would be application/octet-stream. So this would not be an application-level header, but would be used by my stomp client code to determine which message type to create. Content-type is application level. I was suggesting it for your use case where you want to know what to convert a bytes message into in your C++ library =) If we're all in agreement with that, then it seems to make sense that the default functionality of the broker be modified to handle content- type in this way. No. activemq-transformer would provide the JMS type mapping to override the default. I suggested that you use content-type (not required by stomp) to decide if something is text or a byte stream. Transfer-encoding is also useful for this. :-) And if that's true, then it seems like this particular issue is resolved. This way, we get it into the 4.1 release with no problems. We can create another issue to do the refactoring as you've suggested ... which will probably take a little more time and several conversations to get right. How does this sound? Nate On 6/13/06, Brian McCallister [EMAIL PROTECTED] wrote: On Jun 13, 2006, at 1:50 PM, Nathan Mittler wrote: Could you guys point me to a place in AMQ where this sort of thing is being done? That would save me a lot of searching =) I'm viewing this problem from the client side - the Stomp C++ client that Tim Bish and I are writing currently supports text and bytes messages. Within a general Stomp client, I would suggest that switching on JMS message types is not a productive goal. Using Content-type here makes a lot more sense, I think. . It would make a lot of sense to set it for text messages going out to Stomp if there is not one already supplied. Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a specific server implementation is probably not a general solution (though is fine if it is specifically an activemq client which happens to use stomp for transport). So when I get a stomp frame in, I need to map it back to a text or bytes message. We chose to do this for a couple of reasons: 1) to give JMS users a familiar interface and 2) to provide a simple interface for reading and writing text messages (e.g. xml). Content-type: text/xml -- Content-type: application/octet-stream With that said, I'm not seeing how I can do that mapping if the transformer is provided only in the SUBSCRIBE. A client could potentially get a variety of message types from a single subscription. I think it would have to be part of the MESSAGE frame, rather than the SUBSCRIBE. SUBSCRIBE activemq-transformer: com.example.ContentTypeMapper Here are the use cases I see: s/transformer/activemq-transformer/g I like the namespace. Client-Server 1) SEND\n...\ntransformer:text (client tells server it's a text message) +1 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message) +1 3) SEND\n...\ntransformer:default (client tells server to use content-length to make determination) -1 Give it a descriptive name so that we can change the default without breaking these. 4) SEND\n...\n (no transformer specified - same as #3) +1 5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use default) Return an error -- do not quietly swallow this. Server-Client 1) MESSAGE\n...\ntransformer:text (server tells client it's a text message) +1 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes message) +1 3) MESSAGE\n...\ntransformer:default (server tells client to use content-length to make determination) -1 same as #3 above 4) MESSAGE\n...\n (no transformer specified - same as #3) +1 5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown transformer - use default) -1 same as #5 above This does highlight that we have two real transform cases, send and receive if we support CONNECT or SUBSCRIBE level transformers. We can infer the correct direct on MESSAGE and SEND, but not the others. As this would make the interface have all of two methods, I am quite happy combining it. Alternately we can have different headers on SUBSCRIBE and CONNECT -Brian
Re: STOMP and JMSType
On Jun 14, 2006, at 10:21 AM, Mittler, Nathan wrote: Ok, so application-level is referring to the C++ library, not the user of the library? If so that eliminates the need for another header like amq-msg-type. We still want the transform header for the stomp adaptor though, in order to allow people to migrate to 5.0 style (all bytes byt default) mapping. How do we make this become part of the stomp spec? When we do, we should define the list of valid values for it (e.g. text and bytes). We don't. It is how we map it in ActiveMQ, it is not part of the protocol itself. I think that having an appendix with recommended mapping is a good thing, though. Ditto an appendix on making good use of it -- Stomp Layer 2 =) So I'm starting to think there are 2 main use cases: 1) I want to have portable STOMP client that work on other providers. Then you accept that you can not tightly integrate with an existing JMS network in a portable way. For example they would not be able to send and receive JMS Map messages. Since stomp does not specify what those messages would look like on the wire. This means that STOMP needs to define how a portable mapping of JMS ByteMessage and TextMessage to STOMP Messages. I think what we have today is very close to this. We may just need to formalize it a little more in a document so that other providers could implement the same STOMP to JMS mapping. Of course, this mapping has to stay simple. Simple is good -- ask, What would Alan Kay do? =) [snip-and-rearrange] So right now, I'm just concerned with #1. I'd like to make the first crack at our client as STOMP vendor independent as possible ... and we're only doing text and bytes messages for the first cut. If you think it is important to have something specifically for text messages in the C++ client, I would switch on content-type using mime type stuff a la SMTP and HTTP. This, though, is like the magic handling of www-url-encoded form stuff in servlets -- it is a common case made more convenient in the API (which is a good thing). 2) You have a STOMP client that does not mind intimately knowing about ActiveMQ. Then it can request transformation on the the send and receives. That transformation could totally change all the STOMP rules about the headers for for the messages coming in and out. It might use the content-type to hold the JMS message type: bytes, text, object, map, etc. and other headers like jms.Type to hold the JMSType headers. Also the payload encoding could be fancier. Yes. So by default, I think it should work like case #1, if you want to use case#2, then you use the transform header options. This gives us backward compatibility but for your C++ stomp client that exposes a JMS like API use case, I would think it falls under use case #2. If we're in agreement that the two use cases you've identified are two separate JIRA issues, then we can just create a second JIRA for #2, and I can go off and implement #1 in the broker. Not sure we are all talking the same thing yet, but we are definitely getting close. -Brian
Re: Graduation
Let's run down the checklist and make sure our ducks are all in a row. I have a good feeling about it =) -Brian On Jun 14, 2006, at 11:47 AM, Hiram Chirino wrote: Hi Folks, especially you ActiveMQ Mentors out there... I feel that ActiveMQ is ready if incubator graduation. For the looks of the Status report and the health of our community I think we are overdue! Mentors, do you think we are ready to petition the incubator for graduation and what's to process to get that done? -- Regards, Hiram
Re: STOMP and JMSType
On Jun 13, 2006, at 1:50 PM, Nathan Mittler wrote: Could you guys point me to a place in AMQ where this sort of thing is being done? That would save me a lot of searching =) I'm viewing this problem from the client side - the Stomp C++ client that Tim Bish and I are writing currently supports text and bytes messages. Within a general Stomp client, I would suggest that switching on JMS message types is not a productive goal. Using Content-type here makes a lot more sense, I think. . It would make a lot of sense to set it for text messages going out to Stomp if there is not one already supplied. Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a specific server implementation is probably not a general solution (though is fine if it is specifically an activemq client which happens to use stomp for transport). So when I get a stomp frame in, I need to map it back to a text or bytes message. We chose to do this for a couple of reasons: 1) to give JMS users a familiar interface and 2) to provide a simple interface for reading and writing text messages (e.g. xml). Content-type: text/xml -- Content-type: application/octet-stream With that said, I'm not seeing how I can do that mapping if the transformer is provided only in the SUBSCRIBE. A client could potentially get a variety of message types from a single subscription. I think it would have to be part of the MESSAGE frame, rather than the SUBSCRIBE. SUBSCRIBE activemq-transformer: com.example.ContentTypeMapper Here are the use cases I see: s/transformer/activemq-transformer/g I like the namespace. Client-Server 1) SEND\n...\ntransformer:text (client tells server it's a text message) +1 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message) +1 3) SEND\n...\ntransformer:default (client tells server to use content-length to make determination) -1 Give it a descriptive name so that we can change the default without breaking these. 4) SEND\n...\n (no transformer specified - same as #3) +1 5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use default) Return an error -- do not quietly swallow this. Server-Client 1) MESSAGE\n...\ntransformer:text (server tells client it's a text message) +1 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes message) +1 3) MESSAGE\n...\ntransformer:default (server tells client to use content-length to make determination) -1 same as #3 above 4) MESSAGE\n...\n (no transformer specified - same as #3) +1 5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown transformer - use default) -1 same as #5 above This does highlight that we have two real transform cases, send and receive if we support CONNECT or SUBSCRIBE level transformers. We can infer the correct direct on MESSAGE and SEND, but not the others. As this would make the interface have all of two methods, I am quite happy combining it. Alternately we can have different headers on SUBSCRIBE and CONNECT -Brian
Re: STOMP and JMSType
JMSType is a reserved header in JMS, for use at the application
level. I think what you are proposing is more accurately an ActiveMQ
specific transform header. I think this type of transform should
either be a real, arbitrary, pluggable, transform mechanism, or
should not be done.
I would much prefer to *always* use a bytes message, but this is
backwards incompatible so cannot be done in 4.X.
I would propose that instead of overloading JMSType, if we think we
need to have a transform/mapping mechanism we base it on an active-mq
specific header, and make it something like:
STOMPMessageTransformer {
public ActiveMQMessage transform
(SomeRepresentationOfTheSendFrameIncludingHeaders frame) {
...
}
}
I am not convinced we need this, but I much prefer it to a hardcoded
transform, as this would allow for much more useful transforms (ie,
aplication-aware).
I think that, properly, this should be done by a service on the
messaging bus though, NOT in a protocol handler.
-Brian
On Jun 12, 2006, at 12:59 PM, Mittler, Nathan wrote:
I'm working on fixing the way the STOMP transport determines Text and
Bytes messages for issue AMQ-739. Previously we keyed off of the
content-length header - if it was there, it's a bytes message, and
otherwise it's a text message.
Since all STOMP messages can have content-length, we need to use
JMSType
to distinguish in these cases. To do this, we need to define standard
JMSType values for Text and Bytes messages. I have a build that uses
text and bytes as the standard values for the type header.
On the
broker side, the logic in Send.java looks like this ...
** BEGIN CODE **
// Assume the message is a bytes message.
Boolean isBytesMessage = true;
// If the message does not contain a content length,
// we have to assume it's a text message - first zero
// we encounter denotes the end of the frame.
If( !headers.containsKey(Stomp.Headers.CONTENT_LENGTH) ){
isBytesMessage = false;
}
// There is a content length specified,
// now use JMSType to determine the message type (default to bytes if
none specified)
else if( headers.containsKey( Stomp.Headers.Send.TYPE ) ){
isBytesMessage =
(headers.getProperty(Stomp.Headers.Send.TYPE) ==
Stomp.Headers.TypeValues.BYTES);
}
if( isBytesMessage ){
// create a bytes message.
}else{
// create a text message.
}
** END CODE ***
Any objections?
Regards,
Nate
Re: STOMP and JMSType
On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote: Agreed ... using the type header is not an option. --- From the bug report --- It isn't possible to reuse the type header (JMSType) for the purpose of sending through the information as to what type of message it is (text or bytes). So this means that we need to add another activemq extension header. I propose amq-msg-type. --- / From the bug report -- I like this a lot better, and think it would be a reasonable default rule for mapping in 4.X. I am not convinced we need this, but I much prefer it to a hardcoded transform, as this would allow for much more useful transforms (ie, aplication-aware). Although I agree conceptually, I'm thinking this might be a bit of an overkill for the task at hand. Agreed. I just hate to layer on another backwards compatibility issue beyond what we already have. By designing it to be forward compatible with an arbitrary mapping we can grow into a future solution more easily. Once we add this header we will need to support it ~forever. Right now the STOMP transport only works with bytes and text messages, and creating this transform model won't change that. I think if we one day decide to refactor the transport to accept other message types - that would be the time to make this sort of change. What if I want to switch on Content-type to decide between text or bytes? It is a common header to use, but is not part of the spec (as stomp doesn;t care, but is happy to pass it along). This makes more sense to me in terms of mapping between Stomp and JMS, but it is not compatible with switching on a specific content header. The mapping between Stomp and JMS is actually rather important to get right as it is the low level interop mapping between various platforms and Java. As such, I want to make sure we are building towards a correct solution. Aside from all this, controlling the protocol -- (semi-)protocol mapping should be a configuration thing, not a flag the client must put on every message it sends. The end goal for me is to have all messages coming in from the Stomp adaptor be bytes messages, unless someone has an overriding need for something else (quote possible). The current behavior is pretty bad as a default, but we just released 4.0 with it, so we are stuck until we make another backwards incompatible release (5.0). In 4.1 we can add the amq-msg-type header to allow people to force things to bytes (or text) but for the 5.0 end game we will need to make the mapping pluggable in order to make the upgrade path as easy as possible. if we are going to need pluggable eventually, why not do it now in order to allow people to fix the bytes/text mistake (I can say it is a mistake, I wrote it =) at the server level instead of having to add a header to every message. We have, then, three configurations which people are likely to want: 1) Current (3.2 and 4.0 compatible) one which is made more palatable by letting the client specify via the amq-msg-type. 2) Map everything to bytes, which I would like to make the default in 5.0. 3) Map everything to Text (which is what I would actually use if we had it as I convert all the bytes ones I send now into strings anyway). If we are going to have it be sufficiently pluggable to support these three, we should consider letting users provide their own. -Brian
Release Plan Discussion
Hi folks, wanted to have a quick discussion about release plans and making releases go more smoothly based on how 4.0 has gone so far =) Proposed release process: 1) Someone decides we need a release. They cut a release candidate, using the planned version number, and post it to their home directory somewhere (presumably on people.apache.org). Sign everything, make all the artifacts look like they are a release, etc. 2) Call for a vote on the release, pointing people to the release candidate. While in incubation this will be a two-phased vote, first on the -dev list (binding votes by ppmc members), second on the incubator list (bcc the incubator pmc list to let them know about the vote) where binding votes are by incubator pmc members. 3) If vote passes, push over the same release artifacts as we voted on, to the distribution system and update the site to reflect the new release. Tell folks on -dev. 4) When it has been picked up by mirrors make other appropriate announcements ([EMAIL PROTECTED], -users, general@, etc). Thoughts? -Brian
Re: 4.0 release comments
On May 17, 2006, at 10:03 AM, Hiram Chirino wrote: from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://cvs.apache.org/maven-snapshot-repository), codehaus-snapshot (http://snapshots.maven.codehaus.org/maven2), apache-maven1-snapshot (http://cvs.apache.org/repository), maven-csharp (http://maven-csharp.javaforge.com/repo) Perhaps one of the repositories is down. You could always manually download and install the dependency. :( Codehaus has been down for a while. Yea, rolling open source outages :( -Brian
Re: Stomp and Message Types
On Apr 23, 2006, at 7:17 PM, Hiram Chirino wrote: How about we make that an optional extensible header that defaults to binary if not set. All stomp implementations should at least support text and binary. Something like: message-type:text We can do server-specific headers now, and can actually cover this via selecting a message type by inspecting the Content-type header. What I am trying to avoid is the situation where a receiver doesn't know what kind of message to expect, and needs to detect if it is a byte or text message =/ And activemq would also support some other types such as: activemq-map, activemq-stream, and activemq-object where ActiveMQ would define the expected body encoding for those types. Regards, Hiram On 4/23/06, Brian McCallister [EMAIL PROTECTED] wrote: I want to correct a design wart in ActiveMQ's Stomp implementation -- originally Stomp only supported text and I implemented messages as text messages. Later I caved and changed stomp to handle arbitrary byte bodies, and used byte messages to handle this. The difference, according to ActiveMQ, is whether the content-length header is specified (if it is not, it goes into text mode and scans for a null byte). I'd like to change activemq to *always* use byte messages. -Brian -- Regards, Hiram
Re: Release and Version Philosophy [Discussion]
APR's versioning guidelines are an awfully good practice, in my experience. http://apr.apache.org/versioning.html -Brian On Jan 15, 2006, at 10:42 AM, Alan D. Cabrera wrote: Matt Hogstrom wrote, On 1/14/2006 9:02 PM: I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0 etc. lately and I think its great that we're having these discussions. I'd like to use this thread to aggregate people's thoughts about this topic in a single thread for reference and clarification as we make forward progress. So I'd like to clarify some terminology (at least post what the terms mean to me) so we can make some meaningful plans for our various efforts going forward. This is a strawman so don't get too revved up. I think we need to balance between structure and fluidity and I'm not sure exactly how to do that; input welcome. First, I see there is a structure for versioning like: v.r.m[.f] where: v = Version r = Release m = modification f = fix (optional) Version --- - Represents a significant set of improvements in Geronimo and a definite milestone for our users. - New features are introduced that may break compatibility and require users to have to modify their existing applications that ran on previous Versions. (Although we should strive to not force them to change immediately but rather provide something like a V-1 or -2 compatibility story. -2 Would be excellent but that might be too optimistic given the rate of change. - Things like JEE 5 would be found in a version change. - Goes through a formal Release Candidate process for user feedback and has broad coverage in terms of announcement. (Not just the Dev List) - Release Candidates look something like Geronimo-2.0-RC1/2/3 etc. Release --- - Can include significant new features / improvements. - Should not break existing applications (lot's of traffic from users saying something worked on M5 but doesn't on 1.0) - Includes bug fixes and the like. - It would be hard to justify moving to JEE 5 based on a release change. - Has broad announcement - Does not go through formal Release Candidate Process but does make interim release attempts based on a dated binary release (ala Geronimo-jetty-1.1-rc20060315) Modification - Incremental release that builds on the goals of the V.R its based on. - Can include new features - Cannot disrupt existing application deployments - Includes multiple bug fixes Fix --- - Focused release that addresses a specific critical bug. - We're no where near this now but it would be nice to release specific bug fixes and not whole server releases. - An example of this would be something like a fix to the recent problem Jetty uncovered related to security. A fix in this context would be a simple packaging change to get the new Jetty Jar into the build and wouldn't require a whole new server to be spun off. Thoughts? I see this as a two dimensional problem. How do we communicate to our end users what can be expected and how we go about fulfilling those expectations during our engineering effort. The initial touch point is version numbers. I think that end users are only concerned with how things are compatible when they look at version numbers, not the process that was used to meet those compatibility expectations. I think that you've mixed the two together, which is why you have a Release and Modification. I'm thinking: - merge R and M, having that granularity seems confusing and I cannot think of a compelling scenario that we would need to support to justify it. - remove the last statement of Release; *all* code released, be it V, R, M, or F, by Geronimo needs to go through a formal release candidates. The nomenclature that I would use would be: Major.Minor.Patch(-RC#)+ I'm fleshing out my ideas at http://opensource.atlassian.com/confluence/oss/x/Wgs Regards, Alan
Re: [Vote] Installer: Default Web Container Selection
+1 for Jetty -Brian On Dec 8, 2005, at 6:10 PM, Jeff Genender wrote: Ok then based on this... I hope that this group takes into the account of all votes, including those that use the app server, our community and users. If we cannot be neutral, then minimally we should let the users decide what they want as a default container. If everyone wants Jetty as a default, then I am behind it. But if a majority want Tomcat, lets give the community what they want. A vote was put out...lets see what our users want. Jeff John Sisson wrote: I have changed my mind, please ignore my previous vote. My vote is now: [ X ] Make Jetty the default Web Container install selection My initial concerns were with users not familiar with Jetty (e.g. Tomcat users) and the lack of Geronimo documentation on Jetty. I chatted to Greg W on IRC and he said he will improve the documentation. I have raised JIRAs GERONIMO-1314 and GERONIMO-1315. Thinking about it more, those who already use Tomcat in other projects are probably going to click Tomcat if they don't go to the trouble of looking into Jetty. I agree with Aaron that we should make it clear in the documentation that it is only a default to simplify the install process and either container can be used and both are supported. John Erik Daughtrey wrote: The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though.
Re: [VOTE] sponsor ActiveMQ ServiceMix to become sub-projects of Geronimo
[ ] +1 = I support the move to sponsor ActiveMQ ServiceMix during incubation as sub-projects of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ +1
