CDI/Weld(1.1.10) does not work inside an EJB Container JBoss6.1.0 & JBoss7.1. [WELD-001414]

[thegroove]

Dear Sirs,

we a running into CDI problems, when deploying our JEE6 application.

It is a batch-processing application, using queue's and by this MDB's

und stateless session beans.

We use a multi-project maven project to build and test our application.

In order to test our application logic we decided to make use of CDI.

By this, we developed a junit test client, that is designed to run

defined test castes outside the EJB container, simply by calling

the calculation engine, that can easily injected into your application

context.

The junit-mass-test runner is running thanks to Apache's delta spike and

weld.

When we wanted to deploy our server, we get the follwing error message:

(line-109) 2013-01-22 09:13:39,340 INFO  [org.jboss.weld.Version] (HDScanner) WELD-000900 1.1.2 (Final)

....

2013-01-22 09:15:16,706 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to Start: name=vfs:///home/cgroove/Projects/asFreelancer/30_Scout24/projekte/02_AbrechnungNeu/devWorkspaceMv/eclipseDir/.metadata/.plugins/org.jboss.ide.eclipse.as.core/jboss-6.1.0.Final/deploy/as24BillingEAR.ear_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [DebitStateServiceIf] with qualifiers [@Default] at injection point [[field] @Inject private de.as24.service.billing.CalculateBillingBean.debitStateSvc]

          at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:270) [:6.1.0.Final]

          at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106) [:6.1.0.Final]

          at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:129) [:6.1.0.Final]

          at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:351) [:6.1.0.Final]

          at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:336) [:6.1.0.Final]

          at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:404) [:6.1.0.Final]

The problem occurs in a stateless session bean, that uses @Inject to initialize a interface

atrribute. The implementation resides in the ejb.jar. The Interface is located in a

servie-jar.

A similar problem was discussed in:  http://stackoverflow.com/questions/7610003/injecting-a-bean-from-a-different-jar-in-weld

We considered also requiredments in the application.xml. The only thing wet did not followed the Qualifer approach, because

there will be only one matching implementation class for a request on a interface.

The strange thing is, when i remove the Inject and assign a null pointer, another inject will fail.

It seems to me, that WELD seems not been initialized or looks like to be unaccessable for my

CDI Injects.

Maybe i do have to do some initialisation in a @PostConstruct methods in my sessionbean ?

Any ideas ?

Thank you for your support

Christian

[luksa]

Try upgrading weld to version 1.1.10.

[thegroove]

Salut Marko,

how ?

Do i have to overwrite the files in the server-deploy directory ?

Or would it be possible to load and package the stuff into

my maven project ?

Thank you

Christian

[thegroove]

Hy,

still trying to upgrade to 1.1.10_final. In order to keep the server config unchanged

i was trying to modiy the pom.xml of the ejb-subproject, like this:

		<!-- WELD update, weld.version is to 1.1.10 -->
		<dependency>
		<groupId>org.jboss.weld</groupId>
		<artifactId>weld-core</artifactId>
		<version>${weld.version}</version>
		</dependency>

		<dependency>
		<groupId>org.jboss.weld</groupId>
		<artifactId>weld-api</artifactId>
		<version>1.1.Final</version>
		</dependency>
		<dependency>
		<groupId>org.jboss.weld</groupId>
		<artifactId>weld-spi</artifactId>
		<version>1.1.Final</version>
		</dependency>

but  jboss still activates the (see log ...)

2013-01-22 15:04:37,102 INFO  [org.jboss.weld.Version] (HDScanner) WELD-000900 1.1.2 (Final)

In order to checj your suggestion shall i now change the weld-config in the

server-deploy directory, or did i have overseen a something in my pom's.

Groovy

[meetoblivion]

Is it necessary to use 6.1?

[thegroove]

Salut John,

i hope your further enquiry does not mean, that my expectations

are not portable ;-(((

What we are building now is a sort of a feasibility studiy, that

will runs later on the commercial version of JBoss-6, since our

customer may wiish to outsorce the update and some system-managements

tasks.

The most recent version of the commercial JBoss-AS is a managed

JBoss-6.1 server. In order to convince our customer to buy JBoss-AS

we should be able to set up a blue-print implementation using all

features like JEE6 with CDI.

So here we are. A workaourund should be fine for me, but we should

be capable to demonstrate, why JBoss-AS with JEE& and CDI is

a perfeact technical groundwork to implement business critical

applications.

[meetoblivion]

Hi Christian,

Just to make sure I understand then, are you planning to use EAP 6.1? If so, EAP 6.1 is based on JBoss AS 7.1.3.  The closest public version is 7.1.1.  AS 6.1 does not have an EAP equivalent.

[thegroove]

Salut John,

thanks for that enlightment! I'll give JBoss-7 a try and hope

that the CDI/Welt implementation is better.

Thank you

[meetoblivion]

It is, but you may still want to upgrade weld based on issues uncovered.

[thegroove]

Hi John,

coming back to a previos question, how do i perform a update of weld.

Shall i consider this in my maven dependencies or shall i patch the

Jboss Home dir with newer weld-jars ?

Do you know a process how to perform this update, iff my custimer

let me wait in the wings for a proefessional EAP with (real) support.

Thank you

Christian

[thegroove]

Salut John,

ok, JBoss-7.1 ... final is using:

[org.jboss.weld.Version] (MSC service thread 1-10) WELD-000900 1.1.5 (AS71)

.. but i learned my lessons, i need WELD 1.1.10. As a consequence i fall into the same

problem a with the JBoss-6.1.-.. final that comes with Weld 1.1.2.

Now that's what i call quite good! JBoss 6.1.0 behaves similar (oh exactly the same)

as JBoss 7.1.0 final. Its called compatbility but for my problem i can not see any progress.

So could you please tell me how i can upgrade the weld part in my JBoss-7.1 ... final

_____________

Final, the most cited word in my posting.

Feeling final after migration to JBoss-7.1.

I have kicked the bucket, hopped the twig

While i am  to be in its final throes

[meetoblivion]

I actually just brought that up recently

https://community.jboss.org/thread/220355?tstart=0

Basically, you need to download weld-core jar (this link should work: https://repository.jboss.org/nexus/content/groups/public/org/jboss/weld/weld-core/1.1.10.Final/weld-core-1.1.10.Final.jar )

That jar will go in to JBOSS_HOME/modules/org/jboss/weld/core/main  then you need to update the module.xml file that is sitting in this directory and point to the new JAR file.

[thegroove]

Salut John,

ok, the upgrade of WELD als successful:

06:27:49,189 INFO  [org.jboss.weld.Version] (MSC service thread 1-12) WELD-000900 1.1.10 (Final)

but:

06:28:20,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC00001: Failed to start service jboss.deployment.unit."as24BillingEAR.ear".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."as24BillingEAR.ear".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name lineItemAccessDao resolves to beans [Managed Bean [class de.as24.billing.persistence.sfdao.LineItemAccessDao] with qualifiers [@Any @Default @Named], Managed Bean [class de.as24.billing.persistence.sfdao.LineItemAccessDao] with qualifiers [@Any @Default @Named]]

          at org.jboss.as.weld.services.WeldService.start(WeldService.java:83)

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_24]

          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.6.0_24]

          at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name lineItemAccessDao resolves to beans [Managed Bean [class de.as24.billing.persistence.sfdao.LineItemAccessDao] with qualifiers [@Any @Default @Named], Managed Bean [class de.as24.billing.persistence.sfdao.LineItemAccessDao] with qualifiers [@Any @Default @Named]]

          at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:476)

          at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:373)

          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)

          ... 5 more

I've seen this weired message before:

class de.as24.billing.persistence.sfdao.LineItemAccessDao and class de.as24.billing.persistence.sfdao.LineItemAccessDao

seem to be ambig, Thats a crappy error message!

[thegroove]

Dear Marko,

the 1.1.10 shows another bug in 1.1.10 WELD-001414. (see aboive)

The error message denotes a ambiguity of two exactly the same

implementations.

That's weired, cause this is not an ambiguity but a redundancy and

by this a problem in WELD .... or spi/api ???

We decided to use CDI in order to test our calculation engine outside

the EJB container. So there are two use cases:

1) production: use of CDI out of a  EJB Container. A MDB delegates

a calculation request through a injected reference (implementation is

in a utility jar located in lib).

Here we have the described WELD Problems.

2) test case: Request is issues by a Junit client mocking all the data.

Here we use delta-spike togehter with weld-1.1.10. This works without

any problems.

It looks like, that weld has problems with the EJB integration and maybe

with the class loaded ?

Shall we also update the api/spi part. Do both integrate WELD into a

EJB container, or where shall i better look for ?

Trusting to hear from you soon

Christian

[luksa]

Christian, are you sure you don't have the LineItemAccessDao class in two different jars in your ear? Are you running this on AS6 or AS7 now?