SecurityPhaseListener deployed without Seam Security causes exception

[fastroller]

I upgraded to JBoss 7.1 FInal and with a bit of tinkering everything is running. However I get an error at startup that I never used to get before. The SecurityPhaseListener has a hard dependency on Seam Security. I have never used Seam Security and yet this error is only now appearing. Has there been a patch to Seam Faces 3.1 or is weld deploying this bean when it shouldn't ? Luckily it is not a show stopper.

19:38:36,419 INFO  [org.jboss.weld.ClassLoading] (MSC service thread 1-3) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class org.jboss.seam.faces.security.SecurityPhaseListener

          at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]

          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.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_20]

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

          at java.lang.Thread.run(Thread.java:636) [rt.jar:1.6.0_20]

Caused by: java.lang.NoClassDefFoundError: Lorg/jboss/seam/security/Identity;

          at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_20]

          at java.lang.Class.privateGetDeclaredFields(Class.java:2308) [rt.jar:1.6.0_20]

          at java.lang.Class.getDeclaredFields(Class.java:1760) [rt.jar:1.6.0_20]

          at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:153) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355) [guava-10.0.1.jar:]

          at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184) [guava-10.0.1.jar:]

          at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153) [guava-10.0.1.jar:]

          at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69) [guava-10.0.1.jar:]

          at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393) [guava-10.0.1.jar:]

          at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

[lightguard]

There are similar issues like this. You'll notice it's only a warning. It happens when weld loads the class. Sorry for the extra logging which looks like an exception.

[cvarga]

Hi Jason

As you may know, this is not an isolated problem

I've seen some of this issues classNotFoundException :

Seam Rest:       freemarker.template.ObjectWrapper, org.apache.velocity.context.Context

Seam Security: org.hibernate.Session, org.hibernate.SessionFactory

Seam Faces:    org.jboss.seam.security.Identity

I know this is not an exception, but it's not pretty and confuses a lot of devs.

How can i help ?

And thanks for the suport

[cvarga]

Hi Andrew

If you want to ignore the information about weld class loading infos ,

you should insert the following lines inside your

standalone.xml or domain.xml

<subsystem xmlns="urn:jboss:domain:logging:1.1">

...

   <!-- This makes CDI class loading problems visible-->

   <logger category="org.jboss.weld.ClassLoading">

       <level name="WARN"/>

   </logger>

...

</subsystem>

[lightguard]

What really needs to happen is we need separate jars for these different configurations. A jar (appropriately named) with the extra dependencies and one without (also appropriately named). I would also want this to be done in one step if possible in the build. I think the shade plugin could help here, but I'm not a maven guru.

[zeeman]

yes, this issue causes lots of conusions for my developers. I had to set logger settings as Calebe suggested to avoid seeing unrelated exceptions.