We had similar case, where we developed a connector to access external WebDav storage, and wanted to use it also from a stand alone application (non-managed).
I do believe that the easiest way is to solve this at the design level, and organize your code in a way that the connector's core logic is JCA-agnostic and can be reused easily. Then you can wrap this with JCA-specific code that exposes the connector to the AS. It could probably even be packaged in two jar -- That's at least the solution we choose (but we packaged all in one .jar).
Otherwise, a JCA connector is the "glue" between the following three parties:
- the Application Server
- the EIS
- the Application Component.
It should be possible to simulate the AS with a lightweight implementation of the necessary classes, and then use the JCA connector directly.
One main job of the AS with respect to a JCA connector is to manage the pooling of connections, and from what I remember, the corresponding interface that you should then implement is ConnectionManager
.
The JCA connector receive a reference to a ConnectionManager
, but the implementation is AS-specific. Writing a lightweight implementation that provides rudimentary pooling (or no pooling at all) sounds feasible.
I had written once a sequence diagram of the connection allocation mechanism. Maybe you will find it useful. Another interface is ResourceAdapter
where you define the startup/shutdown, but that's easy to invoke manually.
(There is probably a bit more than that, and it of course depends on what your JCA connector uses. For instance, if it use Work
and the WorkManager
, then it becomes a lot more complicated to mock. Same remark if the connector is transactional. But it doesn't seem to be your case.)
Otherwise, I think that Spring has some support for JCA, it may be worth having a look how they did it.
From reading the JCA spec, there is
supposedly some support to execute the
code in a non-managed environment
Can you mention the specific part of the spec you are referring about?