one beans.xml for all subdeployments possible?

[klauskinski]

Hi,

I have one EAR file containing multiple jar files below lib/.

In the past all the jar files in lib/ which are providing beans contained a beans.xml and it worked fine.

Now I need several jar files also for another application which uses Spring and not CDI. Because of that, the beans.xml is now a problem as weld (which is starting automatically during the JBoss deployment) is conflicting with spring.

The plan is now to remove the beans.xml files from each jar file and only have one beans.xml file in the encapsulating ear file for the CDI applications handling the beans creation with Weld of all subdeployments.

But - it is not working.

I placed the beans.xml below META-INF/ of the ear but it looks like no beans are created from the subdeployments:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:weld="http://jboss.org/schema/weld/beans"
    xsi:schemaLocation="
          http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd
          http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
    <interceptors>
        <class>de.poc.jee.CacheInterceptor</class>
    </interceptors>
    <weld:scan>
        <weld:include name="de.poc.**" />
    </weld:scan>
</beans>

The structure is:

EAR/lib/jar1.jar

EAR/lib/jar2.jar

EAR/lib/jarn.jar

EAR/META-INF/maven/...../pom.xml

EAR/META-INF/maven/...../pom.properties

EAR/META-INF/application.xml

EAR/META-INF/beans.xml

EAR/META-INF/jboss-ejb-client.xml

EAR/META-INF/MANIFEST.MF

EAR/plugin.jar

EAR/main.jar

Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ICacheManager] with qualifiers [@Default] at injection point [[field] @Inject private de.poc.whatever.api.handler.AbstractRequestHandler.cacheManager]
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280)
    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143)
    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163)
    at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:382)
    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367)
    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:379)
    at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:83)
    at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

[rhanus]

no it's not possible because ear archive is not a bean archive

read jsr-299 spec chapter 12.1 which archives are the bean archives also I recommend you to read Gavin King explanation

[mkouba]

Radim is right. This is not possible in CDI 1.0.

However in CDI 1.1 there is a concept of implicit bean archive and bean defining annotation that could solve some of the similar problems - see also 12.1. Bean archives, 2.5. Bean defining annotations and 12.4. Bean discovery.

[klauskinski]

I suppose I use CDI 1.1, but I do not know?!

12.1 states:

In an application deployed as an ear, the container searches every bean archive bundled with or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-INF/classes directories.

So - why does it not work? Any idea how to fix this?

[rhanus]

but it only discovers session and scoped beans so that no qualifiers, stereotypes, interceptors and decorators are taken into account

I have no idea when this is helpful

[rhanus]

I suppose I use CDI 1.1, but I do not know?!

only if you run wildfly8 you may use cdi 1.1

[mkouba]

Radim Hanus wrote:

I suppose I use CDI 1.1, but I do not know?!

only if you run wildfly8 you may use cdi 1.1

... and GlassFish 4, and Weld 2.0.x on any supported servlet container

[klauskinski]

Uhm ok - so I guess I'm using CDI 1.0 and even with 1.1 It would not help me as I'm using Interceptors I understood so far.

Any other idea how to solve my initial problem?

- I have several JAR files I'd like to use either with CDI (Deployment target: EAR) or Spring (Deployment target: WAR).

- If I deploy my Spring WAR file with JARs including a beans.xml I get several weld error messages as Spring interferes with Weld.

- If beans.xml is a must-have for my CDI Deployments, is there a possibility to completly disable Weld for my Spring WAR-Deployment Units or to tell JBoss to "ignore" the beans.xml inside the JARs for my deployment Units? Maybe via jboss-deployment-structure.xml?

[mkouba]

So you have an EAR which contains both CDI and Spring components?

[klauskinski]

Nope:

I have an EAR with CDI components containing "stuff1.jar"

Additionally I have a completly different WAR which uses Spring but also contains "stuff1.jar" as my Spring components need the beans there as well.

Because of CDI, "stuff1.jar" must contain a beans.xml as I've learned today, but beans.xml hurts in my Spring WAR.

Without a beans.xml the Spring WAR works perfectly.

With a beans.xml the CDI EAR works perfectly.

[mkouba]

Ok. First CDI 1.1 and implicit bean archives would likely help if you'd enable interceptors globally (using @Priority annotation introduced in Interceptors 1.2, see also 9.4. Interceptor enablement and ordering). In any case I don't quite understand what's the content of "stuff1.jar". If it contains classes that should be either CDI or Spring beans (depending on the context) my guess is you'll run into other incompatibilities sooner or later. Simply said I wouldn't mix these two component models in one application or archive.

[rhanus]

but it only discovers session and scoped beans so that no qualifiers, stereotypes, interceptors and decorators are taken into account

I have no idea when this is helpful

ok that was hot-headed

a pretty sample is to use annotation @Inject exclusively even to inject ejbs (you need not to use @EJB if you don't serve remote ejb clients) and use @Priority annotation to globally enable and order interceptors and decorators

then in CDI 1.1 you may omit beans.xml

back to your case...

I guess you have got inside single jar cdi enabled classes which may be instantiated by spring as well... if so that's not a good pattern obviously

AFAIR in spring's application context should be possibile to enumerate needed config files and ignore any others ?

[klauskinski]

It might not be a good pattern, but this is the only way we can migrate slowly from weld to spring. In the near future we'll only have Spring beans but we can't transit immediatly from Weld to Spring because of the amount of Code.

For the transition phase we have basic software components which work without any problems with Spring the same as with CDI (just delete beans.xml and it works without any modifications) and thats why we have this "requirement" to get a jar which works in both environments.