I'm looking to do some concurrency work in a well-behaved Java EE
application. Since I can do some--but not all--of what I want using
@Stateless and @Asynchronous, I'm doing what I can there. But I still need
to kick off asynchronous jobs and monitor them in the manner of
java.util.concurrent.ExecutorService.
If CDI does not prove to be my legal escape hatch here, which I suspect it
will not be, then I need to be able to write a resource adapter that will
kick off threads.
I've written an RA before, so I know the general shape.
However, the prior RA that I've written made use--as most do--of connection
pooling facilities. This RA--which is simply a way to spec-compliant...ly
wrap up an ExecutorServie--doesn't need connection management.
Is it legal, using only JCA 1.6 annotations, to simply define a
ResourceAdapter implementation with--basically--nothing else in the module?
The specification indicates in section 19.2 that an outbound resource adapter
(which this would be) must {handwave handwave} make use of the connection
management, transaction management and security management contracts. In
all three cases, I just want to indicate--preferably by /omitting/
annotations and/or code--that I don't support any of them.
Is it sufficient to simply build a POJO that implements ResourceAdapter,
annotate it with @Connector, and go from there? Can I then inject such a
POJO into my EJB using the @Resource annotation?
JCA 1.5 made it seem that the only thing that could be injected was the user
connection factory.
Basically, I'm looking--both for curiosity and necessity--for the simplest
possible 1.6-compliant resource adapter code for a resource adapter that
doesn't care about connection pools, security or transactions (basically a
resource adapter that just wants access to the BootstrapContext so it can
submit Work).
Thanks,
Laird
--
[Message sent by forum member 'ljnelson']
View Post: http://forums.java.net/node/718991