Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread Philip Dodds
James, I like the idea of sticking to the JSR's where possible - and in fact I'll run over JSR-250 to see what we can use. Also I agree that the EJB3/SCA style resource injection might be better - one of the reasons for the more "verbal" example was just to make it clear a little more clear what

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread James Strachan
On 8/21/06, Philip Dodds <[EMAIL PROTECTED]> wrote: James, I like the idea of sticking to the JSR's where possible - and in fact I'll run over JSR-250 to see what we can use. Also I agree that the EJB3/SCA style resource injection might be better - one of the reasons for the more "verbal" examp

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread Guillaume Nodet
While I fully agree to simplify the annotations used, if you begin to map parameters to properties or xml content, you end up to jsr181 component. I have already planned to add annotations a la jaxws to allow properties to be mapped to parameters in jsr181. A kind of JBI annotations set for jaxw

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread James Strachan
Brainstorming again - here's some thoughts on some sensible defaults we could use for MEPs to keep things as simple as possible... By default methods which are void are InOnly and methods that are non-void are InOut unless there is a typesafe MessageExchange parameter or an annotation used to ove

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread Philip Dodds
Guillaume, I agree that we need to define the difference between components more clearly - I suppose in my mind the JBI component under discussion here is basically a mechanism when you are focussing on XML messaging in a format that can not be changed or where you want to interact with the JBI m

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread Philip Dodds
I like the logic - also I like the idea that a service could annotate two methods and thus end up with the ability to process an InOut and a InOnly via two different methods on the same class. The only question I suppose it what happens if you want to be able to provide both from the same method

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread James Strachan
On 8/21/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: While I fully agree to simplify the annotations used, if you begin to map parameters to properties or xml content, you end up to jsr181 component. Yeah :) I guess thinking of how to enrich ServiceMix's JSR 181 component to fully support all

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread Guillaume Nodet
I would love that, but such annotations are forbidden :( Only primitive types, string, class, enums, annotations (or arrays of these) can be used as annotations attributes. On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote: Interesting! I really love the @Destination injection BTW :) I wonde

Re: Thoughts on a JBI POJO Engine

2006-08-21 Thread James Strachan
On 8/21/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: I would love that, but such annotations are forbidden :( Only primitive types, string, class, enums, annotations (or arrays of these) can be used as annotations attributes. Yeah - we could use the String names of fields/properties which are

Exceptions in servicemix-jms with WebSphereMQ

2006-08-21 Thread Klaus Alfert
Hi Folks, I have a problem connecting service mix via the servicemix-jms component to a WebSphereMQ Queue. My provider configuration is as follows: The message sent is as follows: here is some testdata I get the following exception: javax.jms.MessageFormatException: M