Apologies in advance if this is the wrong forum to post this. I'm posting this here because the error I'm getting seems to be originating from Weld, so this seemed like the most logical place to start.

I have an .ear in a fairly standard configuration that contains a web app in a .war and a library that contains EJB's in a .jar. I am basically trying to add a @Stateless @WebService to an existing .ear, and I'm getting an error that seems to me to indicate that Weld doesn't like the @WebService annotation. Here is the complete layout of the .ear I'm using; in trying to troubleshoot this I have obviously removed alot of the essential components of a useful web application, but I still get the same error no matter what since the error happens on deployment.

Both the .war and the ejb .jar are using CDI, and as such each have an empty beans.xml file in their respective WEB-INF and META_INF subdirectories. The EJB jar contains a two stateless EJBs, one of which is also a web service. The application contains a single @Named managed bean.

17:07:07,740 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///Volumes/Development/Java/jboss-6.1.0.Final/server/epmp/deploy/pmreg.ear_WeldBootstrapBean state=Create: org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413 The bean Managed Bean [test.TestManagedBean] with qualifiers [@Any @Default @Named] declares passivating scope but has non-serializable dependency Managed Bean [class test.session.TestStatelessSessionBean] with qualifiers [@Any @Default]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:328) [:6.1.0.Final]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:290) [: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]
at org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.boot(BootstrapBean.java:92) [:6.1.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_31]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_31]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_31]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_31]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.1.0.Final]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.1.0.Final]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-6]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-6]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_31]

I have found three ways to make this error go away and get my application to deploy, none of which is an acceptable solution, really.

1. Stop referencing TestStatelessSession from the TestManagedBean. Unfortunately, this kind of ruins the utility of CDI for me, but the web service and EJBs deploy without error.

2. Make TestStatelessSessionBean serializable. This seems wrong to me, as it's my understanding that stateless session beans should not be serializable, practically by definition.

3. Remove TestWebService. This is what I find the most confusing. If I leave everything else intact and just remove TestWebService, the ear deploys just fine, even though TestWebService is not being directly referenced by my stub application at all.

I'm not really sure what I'm doing wrong here. To sum up, I have an otherwise functioning enterprise application that refuses to deploy without an error if I include a single @Stateless @WebService. Can someone help me?

You're correct to point that out, but that's more of an error on my part since I was messing around with interfaceless stateless session beans in an attempt to find a working solution and I left that in by accident. I'm 99% sure that's not the cause of this problem because I've tried it out with both standard and interfaceless stateless session beans and I've gotten the error either way. I'll double-check to be sure, of course, but I don't think this is the cause.

It's evident from the error message that Weld is treating TestStatelessSessionBean as a regular CDI managed bean (and not looking up the EJB session bean).

In this case, the error message is correct about TestStatelessSessionBean not being serializable. References to CDI managed beans are passivation capable when the bean is serializable. On the other hand, references to session beans are always passivation capable (the bean itself doesn't need to be serializable, only the reference needs to be - which it is).

I certainly agree with you that Weld is treating TestStatelessSessionBean as a regular CDI managed bean. The question is why? What I find interesting is that I get exactly the same error in either case, which would seem to me to indicate that Weld is actually looking up the session bean.

As I said, one way I can fix this if I make TestStatelessSessionBean explicitly Serializable. But to me, a serializable stateless session bean is an oxymoron. And Weld should be treating this as an EJB anyways, not a regular CDI managed bean.

No, it's definitely creating a CDI managed bean, otherwise the error message would read: "...but has non-serializable dependency Session Bean..." (Well, actually if it were a Session Bean, you wouldn't even get the error).

I've written an Arquillian test with your classes and deployed it to AS7. It works fine if the injected field type is TestStatelessSession, but fails with Unsatisfied dependency when the field type is TestStatelessSessionBean (which is understandable, since TestManagedBean is not in the same bean archive as TestStatelessSessionBean).

I can get the .ear to deploy without error. I'm not sure that this is entirely an acceptable solution, seeing as how there's a thread in the sidebar of this forum that says that @Inject is strongly preferred to @EJB, but I suppose it's not technically incorrect.

Marko, I've verified your results with JBoss 7.1.0CR1b. I actually have an .ear now that deploys fine on JBoss 7.1.0CR1b but will not deploy on JBoss 6.1.0GA without this Weld error. There must be something between Weld 1.1.2 and 1.1.4 that fixes this.

Actually, that doesn't seem to be the case. I've downloaded both Weld Core 1.1.4 and 1.1.6 from here, gone to the jboss-as folder, edited the build.properties to point to my instance of JBoss 6.1.0, and run "mvn -Pupdate-jboss-as" and neither of them have fixed the problem. So it's not a Weld Core issue I would assume.

Moving the @WebService from the ejb bean archive to the web application bean archive also fixes the deployment problem. For me this is probably the most acceptable short-term solution, at least until I move to JBoss 7 and can put it back onto the ejb bean archive where I feel it really belongs.

I'm still no closer to explaining why this doesn't work in the initital configuration I specified. At the very least, I can't come up with a coherent explanation as to why it shouldn't work from a specification standpoint. At this point it seems reasonably clear to me that there is an issue not with Weld Core but with the Weld/JBoss integration layer built into JBoss 6.x. I haven't really been able to home in on which integration component that might be, unfortunately.