Subject: Thoughts on future of the Java ecosystem

  Andi Huber 2017-10-10, 12:11
  Andi Huber 2017-10-11, 09:25
  Óscar Bou 2017-10-11, 11:04
  Andi Huber 2017-10-11, 11:23
  Óscar Bou - GOVERTIS 2017-10-11, 11:31
  Dan Haywood 2017-10-11, 11:51
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
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: