Subject: Thoughts on future of the Java ecosystem


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
coexist.

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

     CDI.current().select(...)

mechanism. And if its the other way around I use

IsisContext.getSessionFactory().getServicesInjector().lookupService(...).

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
Thread.currentThread().getContextClassLoader().loadClass(...)).
Unfortunately this applies also to DataNucleus. So I had to patch their
class loading mechanism. (Sounds dramatic, but was just a single line of
code.)

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
totally sane.

So with this concept and some documentation, we might already provide a
JEE solution. It's not perfect but better than having none.

Cheers, Andi

On 11.10.2017 13:50, Dan Haywood wrote: