Hi
Thanks David for eventually chiming in with your strong support and opinion.
On 19 February 2015 at 00:36, David Blevins <dblevins_at_tomitribe.com> wrote:
> Late to the game, but wanted to voice my strong support for this concept.
> No surprise as someone who was an instigator of the EJBContainer API and
> vocal supporter of this when we talked about it in EE 7.
>
> I'd caution against lumping the concept of an Embedded Container in with
> Modularity.
>
> I see how one could be tempted by the promise, but I'm personally not a
> fan of the concept in practice. Geronimo was written as a strictly modular
> system first using its own design for v1 and v2, then again using OSGi for
> v3. By sheer brute force we got everything integrated in a way that was
> considered "pluggable", but in practice there was very little true
> modularity and things were now twice as hard to integrate having to be
> continuously abstracted from each other and their inherently coupled nature
> hidden behind an explosion of false interfaces and overly generic "package
> neutral" data objects.
>
> Meanwhile, the reality of our industry is that there are on average only
> two implementations of all the major components. Nearly all of them can be
> used in some sort of plain Java SE mode. To allow people to use them all
> at once in a plain Java SE VM, we don't need Modularity, we just need to
> keep increasing the requirements and vendors will make progress.
>
> To me, the bottom line is that; progress. While I would love for us to
> have everything be embeddable, I'd settle for just a stack of EJB, CDI, JPA
> and JAX-RS.
>
> The opportunity in front of us as an EG at this moment in time is that
> things like "microservices" are quite hot. These are just Embedded
> Containers with better marketing. In fact there are handfuls of people
> using embedded Glassfish, Wildfy, TomEE, etc for the task. We are capable,
> just none of that is standard. More often I hear people say "I can't use
> Java EE because I need Microservices".
>
> To be clear I'm not saying we should do this because its trendy. I'm
> saying we've always needed to do this, and now its trendy. It's good for
> Java EE and good for Java EE adoption.
>
> If we could get an API like the EJBContainer API, but for "Container", we
> could require just a couple things in it and add more later. We could
> start with EJB, CDI, JPA and JAX-RS and keep it open to more in the future.
>
> We successfully made a huge step in Java EE 6 with Embedded EJBContainer,
> paused for Java EE 7, now it's time to take another step in Java EE 8.
>
> I'm less confident, given where we are at, we could ever get 100% Embedded
> a single specification round. I think we just need another foot forward.
>
>
>
> -David
>
> On Dec 22, 2014, at 12:28 PM, Antonio Goncalves <
> antonio.goncalves_at_GMAIL.COM> wrote:
>
> > Hi all,
> >
> > We've talked about this topic in EE 7... and I'm bringing it back to EE
> 8.
> >
> > At the moment, the Java EE spec defines several containers (EE.2.4 -
> Containers) : Web Container, EJB Container, Application Client Container
> and Applet Container. Each having its own set of services (EE.2.7 - Java EE
> Standard Services) such as JTA, Validation, CDI... The spec also defines
> SPIs (EE.2.12.2 - Java EE Service Provider Interfaces) as "the contract
> between the Java EE platform and service providers that may be plugged into
> a Java EE product". But these SPIs are not really mandatory (only a few
> specs have SPIs).
> >
> > Why not go further and say "There is a single Java EE container, and
> each service can then be plugged in through a SPI" ?
> >
> > Let me take an example. If we want to persist a Book Entity in Java SE
> we go :
> >
> > EntityManagerFactory emf =
> Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
> > EntityManager em = emf.createEntityManager();
> > EntityTransaction tx em.getTransaction();
> >
> > tx.begin();
> > Book book = service.createBook(new Book("H2G2"));
> > tx.commit();
> >
> > em.close();
> > emf.close();
> >
> >
> > That's fine because the JPA service does persistence. But if the Book
> Entity has a Listener with a CDI @Inject, this doesn't work anymore : you
> need an extra injection services that comes from another spec (CDI in this
> case). The idea behind the EJBContainer API was to aggregate several
> services (i.e. the services given to an EJB component). So, to have JPA and
> CDI working in Java SE we would go :
> >
> > Map<String, Object> properties = new HashMap<>();
> > properties.put(EJBContainer.MODULES, new File("target/classes"));
> > EJBContainer ec = EJBContainer.createEJBContainer(properties);
> > Context ctx = ec.getContext();
> >
> > BookEJB bookEJB = (BookEJB) ctx.lookup("java:global/classes/BookEJB");
> >
> > ec.close();
> >
> >
> > But if the EJB spec is not updated, then the EJBContainer will not
> include the new services (such has the new Security spec, and so on).
> >
> > So what if the Java EE spec would define a single container API ?
> Something like this would trigger a full Java EE container with *all* the
> services :
> >
> > Container eec = Container.createContainer();
> >
> > EntityManagerFactory emf =
> eec.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
> > EntityManager em = emf.createEntityManager();
> > EntityTransaction tx em.getTransaction();
> >
> > tx.begin();
> > Book book = service.createBook(new Book("H2G2"));
> > tx.commit();
> >
> > em.close();
> > emf.close();
> >
> > eec.close();
> >
> >
> > Or if we just need the JPA + BeanValidation + CDI providers, we would go
> :
> >
> > List<Container.PROVIDER> properties = new ArrayList<>();
> > properties.put(PROVIDER.JPA);
> > properties.put(PROVIDER.BEAN_VALIDATION);
> > properties.put(PROVIDER.CDI);
> > Container eec = Container.createContainer(properties);
> > //...
> > eec.close();
> >
> >
> > To have a Web Profile we could go :
> >
> > List<Container.PROVIDER> properties = new ArrayList<>();
> > properties.put(PROVIDER.WEB_PROFILE);
> > Container ec = Container.createContainer(properties);
> > //...
> > ec.close();
> >
> >
> > And the Container API would become a facade to create any Java EE
> provider :
> >
> > EntityManagerFactory emf =
> Container.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
> > CacheManager cache = Container.createCacheManager();
> > WebManager web = Container.createWebManager();
> > BeanManager bm = Container.createBeanManager();
> >
> >
> > This would bring real modularity (even before Java EE 9) and, finally,
> would ease Java SE execution and testing.
> >
> > Any thoughts ?
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
--
Best wishes
Peter Pilgrim,
Java Champion
++++ Scala and Java EE Software Development / Design / Architect for
`BlueChip' enterprises, London, UK ++++
I am the author of ``The Java EE 7 Developer Handbook'' Packt Pub
(September 2013)
http://www.packtpub.com/java-ee-7-developer-handbook/book
I am currently writing ``Digital Java EE 7 Development'' Packt Pub (May
2015)
++++ Digital ++ Finance ++ Adaptation ++ Transformation ++ Software ++++
:: http://www.xenonique.co.uk/blog/ ::
:: http://twitter.com/peter_pilgrim ::
:: http://java-champions.java.net/ ::
:: Skype Call peter_pilgrim ::
:: http://audio.fm/profile/peter_pilgrim ::