Just another brainstorm; I thought we should split this thread into
two; one for POJOs mapping to JBI/JSR 181/AnDI and another to doing
conversations/orchestration/workflow.
So we've got BeanFlow for writing POJO based workflows; I was
wondering about how we could link that to JBI POJOS
Just on a side note, will try to take a depper look at this mail later.
While I think the beanflow concept is cool and very usefull, I think there
are some design problems.
I have tried to fix http://issues.apache.org/activemq/browse/SM-439
without luck. If you could have a look ;)
I think the
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
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 example
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
, 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
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
] 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
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
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
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
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
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
On 8/21/06, Philip Dodds [EMAIL PROTECTED] wrote:
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
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
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
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
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
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
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
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
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
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
/ response,
each response would call a given method on the pojo, etc ...
Sorry for this long email ;)
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
!
Sorry for this long email ;)
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
25 matches
Mail list logo
