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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo
