On 10/20/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 10/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> I have checked in some new code in servicemix-bean to be
> able to handle InOut exchanges and acting as a consumer.
Sounds cool!
BTW I've also added the ability for the BeanComponent to auto-discover
POJOs on the classpath by the user specifying package names to search
through, then any bean with an @Endpoint annotation will be
auto-exposed. We can use the same technique to auto-expose regular JSR
181 POJOs with servicemix-jsr181 too.
Agreed, and we could also inject stuff using annotations
(jndi resources, proxies, jbi context, etc ...). We may also want
to handle transaction annotations. Still not sure if we should reuse
Pitchfork or not ... need to try defining a new scope bean and see
how it goes...
> However there are a few things that do not work yet and
> some things I did not find a clean way to handle.
>
> We can now inject several stuff using @Resource annotation
> (not yet JNDI references), mainly a ComponentContext and
> a DeliveryChannel.
> @PostConstruct is also supported,
Great!
> but I think we need to
> have scoped beans and create new beans for each request
> received (or maybe pool them).
Agreed. If we are creating and injecting POJOs each time, there's
really no need to pool (as we can just inject anything which needs to
be pooled, like JDBC/JMS connections et al)
While auto-discovering pojos is really nice, people may
need to wire some pojos together. Or maybe just use annotations
and inject these beans. It sounds a bit like SCA ... Maybe we
should support the SCA annotations ...
> There is a Callback annotation which has a condition expression
> evaluated using jexl each time an consumer exchange is received
> (i.e. a response to an InOut or a DONE status of an InOnly exchange
> that the bean has created and sent). The condition is evaluated
> using jexl. But we need to find a way to not call the same
> condition several times (maybe keep the old evaluation result and
> only call the callback when the value changes from false to true).
>
> Last, I haven't coded yet how to return the response when using
> an InOut request. And we also need a way to receive / throw
> faults.
Yeah.
Was thinking, if the method returns an object value, we use some kinda
marshaller (which could be specified explicitly via an annotation or
we could use smart defaults) - to turn it into a message body.
Yeah, I think for simple stuff it should quite easy. I was wondering
how to receive faults, errors, etc ...
And the @Callback has some problems, because it is either:
* evaluated each time an exchange is received
* or maybe called just once (it is not evaluated anymore when
a call has already been performed).
Currently, I have implemented the second way, but ...
I was wondering if we should give a callback object when sending the
exchange instead. You would have more fine grained control.
I had also thought about using continuations (as we could control the
environment if we create the beans and wire stuff). And this lead me
to think that it would sounds a bit like bpmscript...
--
James
-------
http://radio.weblogs.com/0112098/
--
Cheers,
Guillaume Nodet
