Dan, great summary of current vision, thanks!
From my experience with Isis on payara (JEE 7) - and I mean just as a
starting point - CDI and the 'home-brew' ServiceInjector can peacefully
My approach: Without modifying Isis, all the DomainService/Object/View
lifecycling is managed by Isis as usual. If I want to access CDI managed
Beans I fetch them from within an Isis managed instance via the
mechanism. And if its the other way around I use
There is only 4 more things to be aware of:
1) Class loading on JEE might not work by simply calling
Class.forName(...), so we need a plug-able class-loading mechanism.
(What worked for me is
Unfortunately this applies also to DataNucleus. So I had to patch their
class loading mechanism. (Sounds dramatic, but was just a single line of
2) During JEE-Application bootstrapping the JEE container identifies a
list of Isis classes it feels responsible for, but does not know how to
instantiate; so errors are thrown. For me it was sufficient to provide a
single stateless JEE bean that states, that it produces all these
classes. As long as you deploy your Isis application including this
dummy-bean, CDI does not complain.
3) The isis-context needs a proper lifecycling, meaning a
deploy/undeploy cycle should properly invalidate any state. (e.g meta
model validation is currently not cleared after an undeploy, in my case
after calling IsisContext.testReset())
4) I use JEE container provided connection pools and bind them to
Isis/JDO via JNDI. I'm not an expert on this, but I believe this works
So with this concept and some documentation, we might already provide a
JEE solution. It's not perfect but better than having none.
On 11.10.2017 13:50, Dan Haywood wrote: