[GLASSFISH-20483] Enable and disable implicit scanning per JAR. Created: 07/May/13  Updated: 17/Dec/15  Resolved: 12/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


beans.xml cannot be added to a third-party JAR. Disabling implicit CDI is one option but but it works at the application level.

This will not work when different third-party JARs make different assumptions about implicit beans. So it would be helpful if GlassFish (or Weld) offered a way to enable or disable implicit scanning per JAR.

Comment by jjsnyder83 [ 07/May/13 ]

According to 12.1 of CDI spec:
"For compatibility with Contexts and Dependency 1.0, products must contain an option to cause an archive to be ignored by the container when no beans.xml is present."

We are probably a little light in our implementation of this as we only allow entire apps to be enabled/disabled for implicit scanning.

Comment by aaronjwhiteside [ 28/May/13 ]

Related to GLASSFISH-20579. It would be good if this was part of the final 4.0.0 release. Perhaps something in glassfish-web.xml?

Comment by aaronjwhiteside [ 28/May/13 ]


This doesn't work as far as I can tell.

Maybe fixing the WELD integration so that this works is the solution?

Comment by aaronjwhiteside [ 29/May/13 ]

I can add a beans.xml as per the CDI 1.1 spec, but that does not appear to work either.

CDI 1.1 Spec, Section 12.1
bean-discovery-mode="none" should disable an archives contents from being considered by CDI.

Comment by phil.zampino [ 10/Jun/13 ]

The cited beans.xml addition should work. If it is being applied correctly, and Glassfish is not honoring it, then that's a bug. Can you provide an application to reproduce this behavior?

Additionally, there is a new deployment property that will disable support for implicit bean archives at the application level. (asadmin deploy --property implicitCdiEnabled=false <archive file>)

Comment by everett_toews [ 07/Oct/14 ]

How exactly was this resolved?

bean-discovery-mode="none" does work for me but this issue is for disabling implicit scanning per JAR.

To disable scanning per JAR I tried the following beans.xml and it didn't work for me. I continue to get WELD errors.

<beans xmlns="http://java.sun.com/xml/ns/javaee" 
          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">
        <weld:exclude name="org.jclouds.**" />

Should this beans.xml work with Glassfish 4.1?

Can someone provide an example of a beans.xml file that excludes per JAR that does work?


Comment by everett_toews [ 07/Oct/14 ]

Just to be clear, I put that beans.xml file in the web app WEB-INF dir.

Comment by reipince [ 17/Dec/15 ]

This is not fixed.

I have jars that contain unimplemented interfaces, and therefore when they're scanned for CDI, they cause an error and I can't deploy my app.

I tried explicitly using an exclude rule in my beans.xml but it seems to take no effect.

My options are:

  • disable implicit cdi at the application level
  • disable cdi scanning at the beans.xml level (using "none" as the bean-discovery-mode).

Both of these options are bad since they require me to explicitly annotate everything that's being injected right now, which is quite a lot of stuff...

Comment by jjsnyder83 [ 17/Dec/15 ]

You have the following choices:
1) Disable implicit CDI for all apps. Use this command:
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

2) Disable CDI for each jar you do not want to participate in CDI. To do this you must add a beans.xml to each individual jar with the following content:


Note that for option 2 you must do this for each individual jar. The beans.xml in WEB-INF only applies to the classes in WEB-INF/classes.

Generated at Sun Jan 22 23:03:34 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.