Hello Hakan,
Valid comment, but with the continued focus on CDI managed beans, not sure
how much interest there is in enhancing EJBs in this regard. You might
want to consider bringing your question up with the EJB expert group?
https://jcp.org/en/jsr/detail?id=345
---------------------------------------------------
Kevin Sutter
Håkan Fransson <hnfn68_at_gmail.com> wrote on 01/17/2017 10:42:06 AM:
> From: Håkan Fransson <hnfn68_at_gmail.com>
> To: users_at_javaee-spec.java.net
> Date: 01/17/2017 10:42 AM
> Subject: [javaee-spec users] EJB-modules in EAR
>
> Hello!
>
> Just started to follow the community and I dont know if this is the
> right place to make questions but I take a chance.
>
> My question is why do we still need to define an EJB module in an EAR?
>
> You read everywhere of the classic composition of a Java EE
> application, to have your business logic in an EJB-module and other
> stuff in a utility jar. I think this concept is a little bit out of date
now.
> Recently I'm starting to restructure a classic JavaEE application,
> using EJB, CDI, JMS and Servlet API. It's built up of several web
> applications and also a RMI-interface, backed by EJB and CDI. Now
> imagine splitting up the backend mud from 30 projects to ~300 in
> order to take control over the code base. Getting rid of circular
> dependencies and carving out a start for DDD. I do imagine a future
> where any of the projects could contain EJB and/or CDI
> functionality. Refactoring EJB functionality from one project to
> another make an impact to deployment of EAR. I need to manually
> control that the application.xml is correctly generated. I just want
> to structure my application in any way without always check that the
> EAR is correct.
> Just compare to CDI. I dont have to tell EAR where my CDI-beans are.
> My point is, EJB has great services I want to use but should not
> have an impact on an application structure/architecture.
>
> Best Regards, Hakan Fransson