On 26/01/2008, robomon <[EMAIL PROTECTED]> wrote: > > I am in the process of converting from Orion JMS to ActiveMQ. In Orion we > only use Text Messages. We set a few message properties with names that > have a period in them such as test.message=Test. In Orion we could set the > selector to test.message='Test'. In ActiveMQ this throws an invalid > selector exception. > > By the same token I can receive Text Messages in ActiveMQ with properties > that have periods but if I enumerate over the properties using > getStringProperty() it throws a NullPointer exception in my onMessage() as > soon as I run into one of the names.
Do you have a stack trace by any chance? It might help us patch the code. I think thats due to ActiveMQ supporting nested list/maps as properties. e.g. if you set a property called "test" with a value of a Map containing a key you can navigate that way. > What am I doing wrong? I couldn't find any info on the property name > restrictions that exclude periods in the name so if you could point me in > that direction that would be great so I don't run into this kind of issue > again. In the JMS spec it kinda says that identifiers for headers should be valid Java identifiers... http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html e.g. see the bit that says... An identifier is an unlimited-length sequence of letters and digits, the first of which must be a letter. A letter is any character for which the method Character.isJavaLetter returns true. This includes '_' and '$'. A letter or digit is any character for which the method Character.isJavaLetterOrDigit returns true. So I don't think you're meant to use periods inside header names. (e.g. the standard JMS headers all start with JMS or JMSX). Am sure if you fancy helping out we can patch the code to work in a non-JMS-spec way to work around this restriction http://activemq.apache.org/contributing.html Maybe we could enable the non-identifier rule in selectors or something (though the worry is we might not pass the JMS certification if we're not careful enough). Am sure fixing the get/set property methods to handle dots is gonna be relatively easy (we might need to add a flag to the Connection/ConnectionFactory on whether to support dots in the names or not or something). The selector parsing might be a bit more hairy to get right maybe. To preserve the syntax we could maybe add a function like header("name.with.dots") possibly? -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
