CODEWITHSUNDEEP
javajakarta-eedeploymentejbcdi
ethanfar
ethanfar

Reputation: 3778

Java EE deployment issue

I'm running into some issues in deploying my Java EE application, and could use some advice.
I have 3 components to deploy:

Optimally, I would like to be able to deploy both the integration and application layer JARs in the same Java EE server, but as separate JARs (since I might want to change the hardware configuration later on and separate them into two different servers on two separate machines).
The problem, is that I'm unable to get the CDI injection from the integration layer JAR to the application layer JAR to work. The server says (and probably rightfully so) that it's impossible to resolve the injections.

So far I came up with these possible solutions:

I don't like either of these solutions (especially the last), since they restrict my future deployment options. The second solution does not restrict me, but it might become tedious at some point (when I accumulate a lot of code).

Finally, my question is:
Is there an option I didn't find yet, that would allow me to deploy the two JARs on the same server with the CDI injections working ? Possibly something that would still work if at some point I separate the JARs into different servers ?

Upvotes: 2

Views: 155

Answers (2)

Romain Manni-Bucau
Romain Manni-Bucau

Reputation: 3422

not sure what your goal is but deploying a war is fine, can even be done manually with these commands:

mkdir -p webapps/myapp/WEB-INF/lib
cp myjar*.jar webapps/myapp/WEB-INF/lib/

If your goal is to be able to split them you can use TomEE skinny war feature.

Create a war with a WEB-INF/jars.txt file.

In this jars.txt put one line by dependency/jar. It can be the path to the jar or maven coordinates.

Once setup it will allow you to change jars one by one then simply restart the server. This is great when several teams work on the same binary.

There are some alternative with TomEE but this one has the advantage to be easy to change to a portable one (war).

Upvotes: 0

eis
eis

Reputation: 53502

Yes, there are other options as well.

  1. Use a java EE container that supports OSGi as well, and use OSGi interface for your deployment dependencies. At least Websphere, Glassfish, JBoss (with jbosgi installed), Jonas support deploying OSGi bundles. This means your modules should be converted into OSGi bundles.

  2. Use a container-specific extension that allows modules to communicate between each other. JBoss as jboss-deployment-structure.xml that you can use to have a dependency to another deployment.

  3. Use a server-provided shared classpath for your dependencies. Wouldn't really recommend this.

My vote would go for OSGi.

None of them will work by themselves however if you deploy packages to different servers. A remote technology like remote EJBs, remote JNDI lookups, Spring remoting, HTTP-based api, CORBA or similar is needed between different servers. In Java EE, EJB is the de-facto standard for this, but Spring remoting is not bad either.

Update: you added that you use TomEE servers. Indeed TomEE won't support the first two options I mentioned. I would use EJB in that case - the fact that you're using EJBs can be abstracted away from the business layer using an EJB delegate, and you could use EJB (stateless session bean) only for the interface part, leaving your DAOs as POJOs.

Upvotes: 2

Related Questions