[javaee-spec users] Re: EJB-modules in EAR

From: Ondrej Mihályi <>
Date: Fri, 20 Jan 2017 13:16:17 +0100

Dear Hakan,

You can use EJB beans in all places, where you can use CDI beans. Jut move
the EJB where you want it and it will be found by the server. I don't see
what is your problem here - you really don't need to use EJB-JAR in your
EARs. EJB-JARs should be only used if you don't want to package your code
into a WAR, which used to require web.xml and all the boiler plate.

Nowadays, WAR doesn't require anything on top of EJB-JAR, in fact it is
even more lightweight than EJB-JAR, because with those you have to define
ejb-jar.xml desciptor, but with WAR in Java EE 7, no descriptors are

Therefore you can safely refactor any EJBs into any WAR file you need. If
you want to share the EJBs, you can split a EJB-JAR file into multiple
EJB-JAR fies (if you have only one).


2017-01-20 12:12 GMT+01:00 Håkan Fransson <>:

> Reza,
> You're probably right, in the future applications would be smaller WAR
> based, but I think it's many EAR based applications still active, and would
> be for a long time.
> The server we are using right now is JBoss EAP 6.4.x.
> We have a large old application with multiple WAR files with lots of
> shared code, both ejb and "utility". Up to this point, EAR has served us
> well with no serious problems at all. But as I said, splitting up the big
> monolith in smaller pieces makes EAR handling a problem regarding to EJB.
> We have not prioritized, or maybe more correctly not seen the need for
> splitting up the application at EAR/WAR level...yet.
> I guess it's two options here. Put everything needed into all WAR files
> and then put it into the EAR. Or splitting up the EAR to several WARs with
> everything needed. I don't know how the server would behave with much
> larger memory footprint and several EJB deployments of same bean. We will
> definitely test both options regarding to build and deployment chain and
> performance of the server.
> I probably doing things wrong but I still believe, with a simplified EAR
> without the need for EJB-module, I could instead have focused on
> refactoring the code base.
> Best Regards, Hakan
> On 19 January 2017 at 17:37, Reza Rahman <> wrote:
>> Hakan,
>> What application server are you using? I believe you could simply place
>> the EJBs inside war files in your ear. There's no actual need to have a
>> separate EJB jar module.
>> The Java EE specification leads should be able to tell us here what the
>> intent of the specification is.
>> Cheers,
>> Reza
>> Disclaimer: I've stopped using ear and EJB jar modules for years now. I
>> just use EJBs in simple war files.
>> > On Jan 17, 2017, at 11:42 AM, Håkan Fransson <> wrote:
>> >
>> > 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