Once again agreed. +1 A way to bootstrap and pass in some minimal configuration is enough.
My opinion on config is a map is good enough; if String[] is good enough for `public static void main` we should be able to be able to get by with a map.
This would allow vendors to focus on the base requirement of operating embedded. We could get fancier later after some collective market experience. Meanwhile our addition of more standard annotations will eat away at vendor config and continue to solve that problem from another angle; more and more config is going into the app itself, thus reducing the need for bootstrap APIs to be that fancy.
But for the moment, we've already proven we can bootstrap a JPA provider, EJB container via a Map.
It's enough for us to move forward without going too far.
My $0.02
I will also stress that the microservices space is now the primary space fueling the "build your own not-javaee javaee server" attitude. Just like with the Tomcat crowd, people are taking our parts and putting them together with only slight variation, but using that as complete justification that "Java EE is bad". Just because you can boot it from `public static void main()` doesn't mean that something with Servlets, JAX-RS, JAXB, JSONP, JPA, CDI, Connection Pooling, Transactions and more isn't a Java EE platform.
Same story, different spin. Meanwhile most of us vendors have embedded versions of our servers already (thank you EJBContainer API for giving us a shove down that path).
-David
On May 6, 2015, at 1:27 AM, Antonio Goncalves <antonio.goncalves_at_GMAIL.COM> wrote:
> embedded boot + the config is more than enough
>
> +1
>
> On Wed, May 6, 2015 at 10:08 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
> if you want to standardize the embedded boot + the config I'm +1, if you want to let a user aggregate all implementations he wants I'm -0 cause I'm sure it will lead to more issues than advantages in practise and it will make EE loosing one of its main benefit: works out of the box.
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>
> 2015-05-06 9:58 GMT+02:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
> Romain, most of the implementations have been doing "more or less the same" for years ! That's why I'm in favor of standardizing the parts that could be standardized.
>
> On Wed, May 6, 2015 at 9:33 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com> wrote:
> Hello Antonio,
>
> More or less the same API exist in TomEE for years (and actually in more flavors but I'll detail only 2 which I think are linked to this topic):
> - tomee-embedded: very close to swarm and payara micro (both features) even if configuration is a bit different
> - ApplicationComposer: coming from testing the idea is to replace the EE model part by user code (ie to get a persistence.xml you return a Persistence in a method declared as a @Module and you build it with something like new Persistence().version("2.0").addUnit(...)). This replaces the persistence.xml typically. There is API for all part of EE. This case is interesting because you control of your application programmatically which is unnatural with EE which is mainly about discovery.
>
> Now there is something different between your original idea and this: you register configurations not implementations (not another container in the meta container). However I think it matches better the way a user need to write an application using EE.
>
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Github | LinkedIn | Tomitriber
>
> 2015-05-06 9:21 GMT+02:00 Antonio Goncalves <antonio.goncalves_at_gmail.com>:
> Looks like RedHat has been one step forward with Swarm : http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/
>
> public class Main
> {
>
>
> public static void main(String[] args) throws Exception
> {
>
> Container container = new Container
> ();
>
> container.subsystem(
> new
> MessagingFraction()
> .server(
>
> new
> MessagingServer()
> .enableInVmConnector()
> .topic(
> "my-topic"
> )
> .queue(
> "my-queue"
> )
> )
> );
>
>
> // Start the container
>
> container.start();
>
>
> Antonio
>
> On Mon, Dec 22, 2014 at 9: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
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France