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 was going on :)
As for the exchange processor mapping I think that the second option,
with annotated parameters looks sweet, and would also give us a
little room for doing some neat mapping stuff like -
@ExchangeProcessor
public void foo(@MessageContentXPath("\customer\name") String name)
{
}
This this would allow "mapping" of a payload to a method, however
when if comes to JAXB2 type mappings and the SomeResponse/SomeRequest
example you put in - I'm not sure that this isn't stepping on the toes
of the SCA/JSR-181 Service Engines? I suppose one of the things here
was providing:
a) a clean mechanism for writing POJO's that what to interact with the
JBI infrastructure and have been specifically implemented to do so
b) POJO's that what to interact with messaging (not XML-RPC) but more
akin to legacy messaging structures that are being passed around and
allowing you to persist them.
However, I can see that the JAXB example would be interesting since
you could generate any structure. Also in the second example when you
use the mapping approach - how do you know which MEP's the POJO can
handle?
P
On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
Just a bit of brainstorming of ideas here.
I was looking at this example
@ExchangeProcessor(patterns = { MessageExchangePattern.INOUT },
parameterMappings = { ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOutProcessor(MessageExchange me) {
// Do something here
}
@ExchangeProcessor(patterns = { MessageExchangePattern.INONLY,
MessageExchangePattern.ROBUSTINOULY },
parameterMappings = {
ParameterMapping.IN_MESSAGE_CONTENT })
public void myInOnlyProcessor(Source payload) {
// Do something here
}
and wondering how to simplify a little.
My first thought was to use an annotation for each kind of exchange to
be supported...
@InOnlyExchange @RobustInOnlyExchange
public void foo(MessageExchange exchange) {
}
(I realised we'd get class name clashes so added the 'Exchange'
postfix to the annotation names. Then I figured it might be simpler to
just use a typesafe API...
@ExchangeProcessor
public void foo(InOnly exchange) {
}
@ExchangeProcessor
public void bar(RobustInOnly exchange) {
}
I guess sometimes folks might not want to see/use the exchange or
might wish to support multiple patterns for one method so some kinda
annotation to indicate the exchange pattern is still useful.
Also how about annotating parameters as being bound to the exchange...
@ExchangeProcessor
public void foo(@MessageProperty('cheese') String foo,
@ExchangeProperty("beer") Integer bar, @MessageContent Source payload)
{
}
While the @MessageContent may at first not appear that useful, we
could allow some automatic tranformations from common types to message
contents such as DOM or JAXB marshalling etc
e.g.
@ExchangeProcessor
public SomeResponse doSomething(@MessageBody SomeRequest foo) { ... }
where SomeRequest and SomeResponse could be marshalled to/from Source via JAXB2.
This would allow folks to process exchanges without using any of the
JBI APIs if they wish - or inject a MessageExchange or
NormalizedMessage into a parameter if required.
On 8/21/06, James Strachan <[EMAIL PROTECTED]> wrote:
> Great stuff Philip!
>
> More feedback as I start digesting this fully and reading this whole
> thread but my first reaction is could we try to stick to standard
> annotations where possible - such as those defined in JSR 250? e.g.
>
> http://geronimo.apache.org/xbean/annotation-based-dependency-injection.html
>
> so
>
> @ServiceStartup -> @PostConstruct
>
> @ServiceShutdown -> @PreDestroy
>
> am also wondering how many of the other annotations are really
> required on injected fields - could we just use @Resource to indicate
> stuff that is mandatory to be dependency injected (like EJB3s). I'm
> sure some of the annotations are required though; am just wondering
> how many of them are
>
>
> On 8/18/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
> > I have knocked up some thoughts on a JBI POJO engine that could be
> > used to provide a mechanism for annotating POJO specifically for more
> > messaging level operations that the JSR181 service engine is aimed
> > for.
> >
> > The idea is to provide a simple framework to replace the Spring Client
> > Toolkit that is now defunt.
> >
> > Have a look at the idea -
> > http://goopen.org/confluence/display/SM/JBI+Pojo+Service+Engine
> >
> > And all comments/thoughts are welcome!!
> >
> > P
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
James
-------
http://radio.weblogs.com/0112098/
