Prevent EJB deployment with sar

[falcor1]

Hi,

I have a jar file, lets call it ejb.jar, that contains both the interface and implementation of several stateless session beans. I typically deploy ejb.jar and one other jar containing stateless session beans in an ear. I am now working on a sar file that contains a single MBean, this MBean makes use of some of the stateless session beans in the ejb.jar. The sar that deploys my MBean can't be bundled in the ear with ejb.jar because it has to be flexible so that it can use the stateless session beans locally or talk to them remotely if they are deployed in a separate JBoss instance.

Since the sar may be running on a separate machine, it at least needs to have the interfaces for my EJBs on the classpath, so it has ejb.jar in the root of the sar. My problem is that when trying to deploy the sar, JBoss wants to deploy the EJBs also but fails because there is no persistence unit definition (it's usually found in the ear's META-INF). So is there a way to tell JBoss not to deploy the stateless session beans that it is finding in the sar? If not then I guess my next alternative would be to deploy this as a war, but that's not ideal in this case.

Thanks

[jaikiran]

So is there a way to tell JBoss not to deploy the stateless session beans that it is finding in the sar?

Are you even packaging the bean implementation classes (which have the @Stateless annotation) in the .sar? If you are packaging only the interfaces (which is the right thing), then i don't see any issue.

[falcor1]

The sar contains the class files for the MBean interface and implementation, it also contains a jar file that has the stateless bean interfaces and the implementations with @Stateless annotation.

I do realize that I could produce 2 separate jars, one with interfaces only and one with implementation. That seems like a bit of a maintenance hassle though and complicates the build process. Another downside is that @Stateless defaults the mapped name attribute to the implementation class, so the clients of my stateless session beans look them up by using

Implementation.class.getSimpleName() + "/remote"

I guess I could explicitly set the mapped name to the interface, but again thats more work and more maintenance.

[jaikiran]

"Falcor1" wrote:


I do realize that I could produce 2 separate jars, one with interfaces only and one with implementation.

That seems like a bit of a maintenance hassle though and complicates the build process.

It's not about a maintenance hassle, it's actually the right way to do it. The .sar is a client of the EJB and hence should only have the bean interfaces and not the implementation class. Including the implementation class is equivalent to deploying a new bean.

"Falcor1" wrote:

Another downside is that @Stateless defaults the mapped name attribute to the implementation class, so the clients of my stateless session beans look them up by using

Implementation.class.getSimpleName() + "/remote"

I guess I could explicitly set the mapped name to the interface, but again thats more work and more maintenance.

Yes, that's the default.