It looks to me that you are mostly just having a shared code issue rather than per se an EJB issue or an EAR issue. If I am understanding correctly the root issue here is that you are sharing EJBs across WAR files? If that's the case, what do you expect to do other than having shared jar file of some sort? Does it really matter that the container knows a bit more about what's in that shared jar and treats it as an EJB module?
If you are after doing microservices, you should be advised that sharing code like this defeats the purpose of having independently deployable units. I think the best way forward is to try to avoid shared code across independent microservices units in the first place. That may actually some times mean your microservices really need to be bigger than you think to avoid complexity.
Independent of all of this, I would recommend moving to a Java EE 7 version of JBoss. A Java EE 5 vintage version of JBoss really is quite antiquated at this stage. That's also a big part of the problem you are having. I don't even think a server of that vintage supports independent war deployments outside an EAR, let alone EJBs embedded in a war.
Anyway, I'd say this discussion is probably off topic here at this stage and perhaps belongs in a more genetic Java EE user forum, perhaps specific to JBoss in case they have vendor specific features folks here don't know about.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: hnfn68_at_gmail.com Date: 1/20/17 6:51 AM (GMT-05:00) To: users_at_javaee-spec.java.net Subject: [javaee-spec users] Re: EJB-modules in EAR
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