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:
Hi Andi, Many thanks for raising this. When we've talked about this in the past in the community, the strong preference I think is exactly in the direction that you've indicated ... to make ourselves properly a JEE citizen and leverage its capabilities. In particular, we don't want to take a dependency on Spring (though we do want to remain compatible with Spring, eg in the way that the Incode Platform's quickstart archetype lets a Spring container be instantiated "alongside" Isis in a single webapp. One of the main benefits of JEE is of course CDI support. Now, Isis has its own home-grown dependency injection stuff (ServiceInjector class) and I would love to get rid of it and replace it with CDI throughout. It's possible that vanilla CDI doesn't support all the capabilties we need (eg we support injecting into List<SomeService> as well as just SomeService ... and there's some use of threadlocals deep in the bowels (IsisSessionFactory#currentSession) which may need some attention. But I do know that CDI is extensible, and Apache DeltaSpike provides a bunch of useful extensions also that might do what we need. As Oscar says, we do have some guice in the mix, that's mostly for the wiring up of the Wicket viewer. I think my intention when I introduced that was to replace Isis' implementation, but CDI is the better way to go. The Wicket Viewer will need some attention here, though, because I think it uses wicket-guice in order to do auto-injection of guice-registered components into Wicket components/pages. I think there's also wicket-cdi integration though, so it hopefully will be possible to port this. With respect to other JEE features, some that come to mind are: - maybe we could ditch our depenency on RestEasy if JAX-RS is baked into JEE (is it, I'm not sure) - maybe we could remove our web.xml configuration (though note: this changes the developer "experience") - maybe we can standardize on using JEE datasources rather than using DN's connection pooling. Related, I'd like to do a bit of a purge on our third party dependencies, and to rationalize them. Several reasons here: - it's not a good first impression to seemingly download half the internet - it increases the chances of a "JAR hell" conflict. One dependency that we use a lot is guava, but I've come across blog posts from other open source folks saying they avoid it because it updates often and they fairly aggressively remove deprecated stuff - having lots of dependencies will make supporting Java 9 modules much more difficult. So, I think we're on the same page here. The only reason none of this has happened so far has been down to priorities and time. But I'm looking forward to making Isis leaner! Thx Dan On Wed, 11 Oct 2017 at 12:23 Andi Huber <[email protected]> wrote:Thanks Oscar, I believe I can see some benefits in implementing a custom solution of DI for Apache Isis. And since it works I'm fine with it. Still I'm curious about what you guys think about the relevance of Java EE as a target platform. Is our community likely to grow if we support the EE platform via docs and example artifacts? Or is it not worth the effort ... Cheers, Andi On 11.10.2017 12:44, Óscar Bou wrote:Hi Andy, Completely agree that we should support standards to ease adoption. Regarding Dependency Injection, Dan introduced Guice time ago and if Iremember it well, he argued about the motivation to implement a custom solution (but can’t remember now why).Also I think he also mentioned that current injection behaviour could berefactored to support CDI, but he could better explain.Sorry to not give more detail on this. Cheers, OscarEl 11 oct 2017, a las 11:25, Andi Huber <[email protected]> escribió: On 10.10.2017 14:11, Andi Huber wrote:Hi all! These are very exciting times for the Java enthusiast. As JamesGovernor points out in his JavaOne 2017 keynotes talk:'Things have changed in the Java ecosystem probably more in the past 3weeks, than they have in the previous 13 years.' [1]And since Java EE is going open source [2], Java EE is probably on theupswing again.Also on JavaOne this year, there was this great talk by Adam Bien'Java EE Heavyweigth or Lightweigth -- Mythbusters', where he demonstrated in a very entertaining way, the lack of reason for going 'lightweight'.Personally I'm a fan of Java EE and there are 3 main reasons why: 1) The technology is very mature and production proven. 2) It is a standard technology, and there are good reasons to stickto a standard and anticipate all its best-practice patterns [4].3) You get a bundle of features for free, especially monitoring, whichis interesting for productive use.How does this relate to Apache Isis? I believe we could do better in honoring those, that are potentiallyinterested in using Isis on top of Java EE infrastructure.I think I need to clarify: Apache Isis currently very well runs on Servlet Containers, but it doesnot (out of the box) on (certified) Java EE (full or web-profile) servers.Main problem being dependency injection issues. So if you areinterested in using Java EE's Contexts and Dependency Injection (CDI) or Enterprise JavaBeans (EJBs) within your business logic, you need to overcome some hurdles.I would like to motivate a discussion about what you think regardingthe relevance of Java EE for Apache Isis.Cheers, Andi [1] https://www.youtube.com/watch?v=UNg9lmk60sg?t=47m40s <https://www.youtube.com/watch?v=UNg9lmk60sg?t=47m40s>[2] https://projects.eclipse.org/projects/ee4j/charter <https://projects.eclipse.org/projects/ee4j/charter>[3] https://www.youtube.com/watch?v=LwimkQQDhio <https://www.youtube.com/watch?v=LwimkQQDhio>[4] http://realworldpatterns.com/ <http://realworldpatterns.com/>
