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 I > remember 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 be > refactored to support CDI, but he could better explain. > > > > Sorry to not give more detail on this. > > > > Cheers, > > > > Oscar > > > > > > > > > >> El 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 James > Governor points out in his JavaOne 2017 keynotes talk: > >>> > >>> 'Things have changed in the Java ecosystem probably more in the past 3 > weeks, than they have in the previous 13 years.' [1] > >>> > >>> And since Java EE is going open source [2], Java EE is probably on the > upswing 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 stick > to a standard and anticipate all its best-practice patterns [4]. > >>> > >>> 3) You get a bundle of features for free, especially monitoring, which > is interesting for productive use. > >>> > >>> How does this relate to Apache Isis? > >>> > >>> I believe we could do better in honoring those, that are potentially > interested 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 does > not (out of the box) on (certified) Java EE (full or web-profile) servers. > >> Main problem being dependency injection issues. So if you are > interested 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 regarding > the 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/> > > > >
