guava 14.0.1 cannot be deployed in a JEE7 Container

[GoogleCodeExporter]

In JEE7 CDI (CDI 2.0) is enabled by default (without a beans.xml needing to be 
present), with no standardized way of disable it.

com.google.common.util.concurrent.ServiceManager is annotated with @Singleton 
and has a constructor...

  @Inject ServiceManager(Set<Service> services) {
    this((Iterable<Service>) services);
  }

So any war or ear that contains a guava 14.0.1 jar suffers from CDI seeing this 
and trying to create the bean but failing and thus failing the entire war from 
loading.

This error is from Glassfish 4.0

[2013-05-23T15:08:35.664-0700] [glassfish 4.0] [SEVERE] [] 
[javax.enterprise.system.core] [tid: _ThreadID=34 
_ThreadName=admin-listener(2)] [timeMillis: 1369346915664] [levelValue: 1000] [[
  Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied 
dependencies for type [Set<Service>] with qualifiers [@Default] at injection 
point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] 
@Inject com.google.common.util.concurrent.ServiceManager(Set<Service>)]

The same WAR also fails to deploy on Firefly 8.0 with a similar error.

Can guava be modified to not use the @Singleton and @Inject annotations?

Original issue reported on code.google.com by AaronJWh...@gmail.com on 28 May 2013 at 9:34

[GoogleCodeExporter]

Original comment by kurt.kluever on 28 May 2013 at 9:36

• Added labels: Type-Dev

[GoogleCodeExporter]

Oi. The problem here is that (as I understood it) @Inject was added to make it 
an injectable class in both Guice and Dagger, to avoid having to manually 
create them in a module.  In both systems, this would not be created early 
(with some notable exceptions).  But certainly not just because it is in the 
classpath and annotated.

I don't know that much about CDI except from very ancient memory, but it seems 
to me that CDI is interpreting JSR-330 in a particular way that is not 
consistent with the intentions of the reference implementation that spawned it 
- guice.  It's making the (unwarranted) assumption that if it's annotated and 
on the classpath you want to create it up-front.  

That is unfortunate, but I'm not sure we should un-annotate ServiceManager to 
cater to that assumption.  Doing so requires additional boilerplate modules for 
Dagger or Guice users in preference to the CDI users.  

A simple workaround is to simply configure an empty Set<Service>.  I don't know 
if there is a way to configure glassfish or others to exclude classes/packages 
from this assumption.  It's a bit of a mind-blowing assumption to make. :/

Another possibility is to proguard the ServiceManager away entirely.  

Argh. 

Original comment by cgruber@google.com on 28 May 2013 at 9:56

[GoogleCodeExporter]

Another workaround, have a relevant class implement

@Produces Set<Service> dummyServices() {
    throw new AssertionError(); 
}

This should pass validation (structurally satisfies the dependency), but if 
it's ever actually called, it will throw, so should ensure that you're not 
actually creating any ServiceManagers in production.   If you are, and this 
approach doesn't work, just return an empty Set<Service> per above. 

Original comment by cgruber@google.com on 28 May 2013 at 10:10

[GoogleCodeExporter]

CDI 1.1 (not 2.0 my mistake) will scan all classes in the war and try and 
instantiate them at deployment time. So the dummyServices() method will be 
invoked and throw the AssertionError().

JSR-346 governs the behavior of CDI 1.1: http://www.jcp.org/en/jsr/detail?id=346

Perhaps you have more clout than a lot of other poeple/at least myself and 
could pursue someone on the expert group for JSR-346 with this matter?

I understand your frustration but if you include classes with any JSR-330 
annotations they will be treated differently in JEE7 containers, currently 
Firefly 8 and Glassfish4, soon to follow Tomcat.. and various others..

On the other note what does it matter if it requires a little more boilerplate 
code to make it compatible with the next generation of application server 
containers? Right now the preference is with Guide and Dagger users to the 
exclusion of users of JEE7 containers (not specifically CDI - I don't use it 
myself). Shouldn't a library such as guava try to be compatible with the 
majority of technology it will be used in (hint hint JEE)?

BTW I do love Guice, and we have a few products here that use it extensively. 
But they are still deployed as WARs in JEE containers..

Original comment by AaronJWh...@gmail.com on 28 May 2013 at 11:49

[GoogleCodeExporter]

What would be the 'little more boilerplate' that we could add to support CDI 
1.1? 

another solution would be to add a beans.xml that simply excludes this class 
from auto discovery, though as you have mentioned this will still be a 
stumbling block for anyone trying to use the class in a JEE 7 container.

Original comment by lu...@google.com on 29 May 2013 at 1:59

[GoogleCodeExporter]

A pre-made Guice Module? But I expect that will put a dependency directly on 
Guice which you probably don't want. I was thinking more alone the lines of a 
wiki page for users explaining how to bind what to where... *shrug*?

beans.xml does not officially support a method to exclude classes from auto 
discovery. Although WELD does support this via an extension it does not seem to 
work in Glassfish, only JBoss.. and is non-portable between CDI 
implementations, not that there are many.

Original comment by AaronJWh...@gmail.com on 29 May 2013 at 2:21

[GoogleCodeExporter]

Not sure if this applies, but you could annotate specific classes with 
@Alternative, this would make CDI treat the bean as "disabled" by default.

http://relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI

But I suspect you'll then have a dependency on:

<dependency>
    <groupId>javax.enterprise</groupId>
    <artifactId>cdi-api</artifactId>
    <version>1.1</version>
</dependency>

But then you could always mark that dependency as optional, so you would need 
it for compile time but no one else will pick it up as a transitive dependency. 
And would still behave nicely in CDI.. or at least make it explicitly configure 
it.. ?

Original comment by AaronJWh...@gmail.com on 29 May 2013 at 2:25

[GoogleCodeExporter]

*or at least until you explicitly configure it...?

Original comment by AaronJWh...@gmail.com on 29 May 2013 at 2:26

[GoogleCodeExporter]

wouldn't this do it

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
<scan>
<exclude name="com.google.common.util.concurrent.ServiceManager" />
</scan>
</beans>

this is based on reading section 12.4 of the CDI 1.1 spec

Original comment by lu...@google.com on 29 May 2013 at 3:02

[GoogleCodeExporter]

So, I poked around in the spec a bit and there's a interesting part of the spec 
for managed beans: "It is not annotated @Vetoed or in a package annotated 
@Vetoed."  If JEE7 is really going to be a concern, it might not be a bad idea 
to toss that annotation on all of our packages because we'll never want Guava 
classes to be managed beans.  Since annotations aren't runtime deps, it'll make 
no difference for most people.

That said, we lukes@ has created a ServiceModule for Guice that is often easier 
to use and has more configuration options than the @Inject constructor, so it 
might be worth just removing that annotation and open-sourcing the module 
(someplace else)…

Original comment by gak@google.com on 29 May 2013 at 4:09

[GoogleCodeExporter]

I tried that it doesn't work.

I think you're right this isn't an issue with Guava, looks like an issue with 
CDI. Or the broken implementations that are currently bundled with the 
non-production ready releases of Glassfish 4 and Firefly 8..

Original comment by AaronJWh...@gmail.com on 29 May 2013 at 4:24

[GoogleCodeExporter]

Gak,

If you would be willing to do that, that would be wonderful. And would help 
until the various JEE7 implementations have sorted their bugs out..

Would it make sense for guava to have a guava-guice artifact/module (maven) 
too, that people could include for Guice support? Having it part of the Guava 
project would ensure it is maintained in line with the other changes to Guava.

Original comment by AaronJWh...@gmail.com on 29 May 2013 at 4:46

[GoogleCodeExporter]

Mind pulling down Guava, adding the annotation and seeing whether or not it 
works?  It'd be an interesting data point.

Original comment by gak@google.com on 29 May 2013 at 5:21

[GoogleCodeExporter]

I filed this ticket with the JIRA instance linked to by the CDI spec:
    https://issues.jboss.org/browse/CDI-377

Original comment by reuben.p...@gmail.com on 14 Jun 2013 at 5:29

[GoogleCodeExporter]

OK I'm using a guava cache in my JEE web application and am currently upgrading 
my deployments to GF 4.0.

I'm hosed by this one. Is there a workaround I can implement in my module that 
can get me over the hump?

TIA.

Original comment by paul.bri...@gmail.com on 23 Jun 2013 at 3:54

[GoogleCodeExporter]

I rolled back to guava 13.0.1 as a quick workaround ...

Original comment by reuben.p...@gmail.com on 23 Jun 2013 at 6:08

[GoogleCodeExporter]

It turns out that CDI 1.1 supports a new "bean-discovery-mode" attribute in 
META-INF/beans.xml that can be set to "all", "none", or "annotated", so adding 
a META-INF/beans.xml file to the jar with "none" discovery mode prevents CDI 
from scanning the jar.

  http://java.dzone.com/articles/java-ee-7-deployment
  http://docs.oracle.com/javaee/7/tutorial/doc/cdi-adv001.htm#CACDCFDE

I ran a test adding META-INF/beans.xml to guava's jar in a webapp on glassfish 
4.0, and it worked fine:

> cat .\META-INF\beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="none">
</beans>

> jar uvf .\guava-14.0.1-bundle.jar .\META-INF
ignoring entry META-INF/
adding: META-INF/beans.xml(in = 312) (out= 179)(deflated 42%)

Can you add an empty beans.xml CDI config file to the guava jar ?

Original comment by reuben.p...@gmail.com on 27 Jun 2013 at 10:15

[GoogleCodeExporter]

BTW - I pulled the test app in glassfish 3 just to verify that adding the 
beans.xml file to guava's jar didn't break things there, and it worked fine 
there too ...

Original comment by reuben.p...@gmail.com on 27 Jun 2013 at 10:47

[GoogleCodeExporter]

I'm in the process of upgrading to GF4.0 too. Anybody has some -not so fishy 
workaroundish- suggestions if I have a lib which declares guava 14.0 as a 
dependency?

Original comment by mr.peter...@gmail.com on 1 Jul 2013 at 10:36

[GoogleCodeExporter]

As a workaround, can you just do a variation of what comment #3 suggested? Have 
a relevant class implement:

@Produces Set<Service> dummyServices() {
  return ImmutableSet.of();
}

You might get a warning logged, but I'd think it should work.

Original comment by cgdecker@google.com on 1 Jul 2013 at 2:59

[GoogleCodeExporter]

Try overriding the dependency to use guava-13.1 in the
root pom or ivy.xml - it's likely that whatever library
you're using will run fine with guava-13:
   http://stackoverflow.com/questions/3937195/maven-how-to-override-the-dependency-added-by-a-library

I wound up wiring up my webapp build process to add a beans.xml file
to the guava jar - this kind of thing in ant:

    <target name="-post-compile" depends="ivy_build_rules.-post-compile">
        <jar update="true" keepcompression="true"
                destfile="${build.web.dir}/WEB-INF/lib/guava-14.0.1-bundle.jar"
                >
            <fileset dir="src/java" />
        </jar>
    </target>

where src/java just contains META-INF/beans.xml with
   bean-discovery-mode="none"

Good luck!

Original comment by reuben.p...@gmail.com on 1 Jul 2013 at 3:31

[GoogleCodeExporter]

It looks like the specific issue here may not be that ServiceManager has 
@Inject on a constructor, but that the class is annotated with a scope 
(@Singleton). See this section of the CDI 1.1 spec: 
http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_defining_annotations

Any scope annotation is a bean defining annotation, and any class with a bean 
defining annotation is treated as a bean. Section 12.1 
(http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#bean_archive) goes on to 
define an "implicit bean archive" as one containing any class annotated with a 
bean definining annotation. So Guava is an implicit bean archive whether it 
likes it or not.

On the other hand, another part of the spec 
(http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#what_classes_are_beans) 
states that anything with @Inject on a constructor that meets a variety of 
other requirements is a "managed bean", so I don't know. Doesn't much matter 
either way.

One thing I can't tell from what I've read of the spec is whether a beans.xml 
file at the war level (in WEB-INF/ or WEB-INF/classes/META-INF/) can exclude 
packages from jars included in the war. It really seems like it should be able 
to, but from what AaronJWhiteside said in #11 it sounds like that doesn't work. 
Can anyone confirm? Or confirm if adding a method that @Produces an empty 
Set<Service> works?

In any case, while this is clearly an issue with CDI, if there's no good 
workaround that doesn't involve modifying the Guava jar in some way, we'll 
ensure this isn't an issue in 15.0.

Original comment by cgdecker@google.com on 1 Jul 2013 at 10:00

• Changed state: Accepted
• Added labels: Milestone-Release15

[GoogleCodeExporter]

I've added a beans.xml with bean-discovery-mode="none" to the guava jar's 
META-INF/ 
(https://code.google.com/p/guava-libraries/source/detail?r=de8f4e8d1076b412a975f
5ce940b49b1d1a45628). If someone having this issue could build the jar and 
verify that it fixes the issue for them, that would be great.

Original comment by cgdecker@google.com on 11 Jul 2013 at 2:58

• Changed state: Fixed

[GoogleCodeExporter]

I just built and deployed the guava-15.0-SNAPSHOT.jar that now includes 
META-INF/beans.xml, and it works fine for me in glassfish 4.0.  Thanks!

Original comment by reuben.p...@gmail.com on 11 Jul 2013 at 9:18

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm using Glassfish 4.0 and discovered that weld-osgi-bundle.jar contains 
Guava. So my application (using Guice also) is working without having it's own 
copy of Guava but I'm using a limited subset of Guava API.

Original comment by sb.les...@gmail.com on 1 Sep 2013 at 10:27

[GoogleCodeExporter]

Unfortunately in CDI 1.0 the inclusion of a beans.xml in the guava archive 
triggers scanning of it for CDI thus (potentially) breaking applications using 
CDI 1.0 

Original comment by cody.le...@gmail.com on 10 Sep 2013 at 2:43

[GoogleCodeExporter]

GlassFish: cannot deploy war with google guava lib
https://java.net/jira/browse/GLASSFISH-20579

Original comment by sebastia...@gmail.com on 12 Sep 2013 at 8:59

[GoogleCodeExporter]

We are getting similar error with Guava 15 and JBoss 7

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 
Unsatisfied dependencies for type [Set<Service>] with qualifiers [@Default] at 
injection point [[parameter 1] of [constructor] @Inject 
com.google.common.util.concurrent.ServiceManager(Set<Service>)]

It works fine with Guava 14.0.1. 

Anyone faced the same issue?

Original comment by k...@appendium.com on 12 Sep 2013 at 10:24

[GoogleCodeExporter]

We also facing issues with guava 15.0 deploying an application to an embedded 
tomee 1.5.1

Here the stacktrace.

Caused by: javax.enterprise.inject.UnsatisfiedResolutionException: Api type 
[java.util.Set] is not found with the qualifiers 
Qualifiers: [@javax.enterprise.inject.Default()]
for injection into Constructor Injection Point, constructor name :  
com.google.common.util.concurrent.ServiceManager, Bean Owner : [ServiceManager, 
Name:null, WebBeans Type:MANAGED, API 
Types:[java.lang.Object,com.google.common.util.concurrent.ServiceManager], 
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]]
    at org.apache.webbeans.util.InjectionExceptionUtils.throwUnsatisfiedResolutionException(InjectionExceptionUtils.java:77)
    at org.apache.webbeans.container.InjectionResolver.checkInjectionPoints(InjectionResolver.java:193)
    at org.apache.webbeans.container.BeanManagerImpl.validate(BeanManagerImpl.java:1034)
    at org.apache.openejb.cdi.BeansDeployer.validate(BeansDeployer.java:269)
    at org.apache.openejb.cdi.BeansDeployer.validateInjectionPoints(BeansDeployer.java:222)
    at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:280)

Removing beans.xml would solve the problem.

Original comment by s...@imsand.li on 12 Sep 2013 at 11:04

[GoogleCodeExporter]

Removing beans.xml from the guava-15.0.jar works. Is there however a solution 
that does not involve editing the jar file?

Any help/pointers would be great. 
Thanks

Original comment by k...@appendium.com on 12 Sep 2013 at 11:27

[GoogleCodeExporter]

Ugh.
It looks like JBoss-7 is javaee-6:
   https://www.jboss.org/jbossas/
The new beans.xml file fixed a problem with javaee-7 (glassfish 4).

The beans.xml file in guava references the ee7 (beans_1_1.xsd)
XML-schema:

<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       bean-discovery-mode="none">
</beans>

I guess glassfish-3 (also ee6, but no problems) has a different
default behavior than JBoss7 when it runs into a beans.xml file for a newer
version of CDI that it doesn't know about ?

Anyway - I think we're kind of screwed.  Without beans.xml some CDI1.1 
(javaee-7)
containers break, and with beans.xml some CDI1.0 (javaee-6) containers break.
Two possible solutions:

 o. Is it too late to just remove the javax.inject.* annotations from those
    two guava classes ?  The client code can pull those classes into
    an IOC setup without those annotations anyway by just setting up a
    delegate class or via configuration files ...

 o. Publish separate -cdi1.0- and -cdi1.1- jar artifacts (without and with beans.xml)

Original comment by reuben.p...@gmail.com on 12 Sep 2013 at 8:59

[GoogleCodeExporter]

Yes, it seems to be impossible for Guava to work out of the box for both CDI 
1.0 applications and CDI 1.1 applications, which is a sad state of affairs.

At a minimum, I think we're going to remove beans.xml from the Guava jar and 
create a 15.0.1 release for it. If it won't work for a subset of CDI users 
either way, better to be in a way that's explicitly CDI-agnostic (no 
beans.xml). We don't want to go creating "CDI 1.0" and "CDI 1.1" versions of 
Guava--Guava should be entirely orthogonal to CDI, and the whole problem here 
is that the CDI 1.1 spec is broken with respect to JSR-330. We did add 
beans.xml, but that was only because it seemed like a way to solve some users' 
problems without negatively impacting others--we now know that this was not the 
case.

Removing @Inject and @Singleton from ServiceManager is a possibility--it's not 
*that* important that the annotations be there, though making that change 
internally would be some trouble. On the other hand, though, it seems wrong for 
us to be making changes that may break users taking advantage of the 
@Inject-ability of ServiceManager just because one JSR-330 implementation is 
broken.

Original comment by cgdecker@google.com on 12 Sep 2013 at 9:32

[GoogleCodeExporter]

In fairness, CDI 1.1's use of JSR-330 is not "broken" - it's just stupid.  It 
is a matter of undefined behaviour... JSR-330 doesn't say how a container will 
behave in terms of when a how it is configured, or how eager it will be.  CDI 
just went with an incompatible change to their defaults between versions of the 
spec, and chose a default behaviour that is guaranteed to have unintended 
consequences.  It's totally valid JSR-330, it's just entirely the wrong 
behavioural default. 

Original comment by christia...@gmail.com on 12 Sep 2013 at 11:20

[GoogleCodeExporter]

I don't know how likely it is that CDI-1.1 will change ?  CDI-1.1 is it's own 
JSR that was approved and integrated into java-ee7, so eventually (I assume) 
all the big EE container vendors (IBM-websphere, Oracle-weblogic, RedHat-Jboss, 
Oracle-glassfish) will implement that (glassfish 4 is the reference 
implementation).  I think the JBoss-weld guys are the CDI leads these days, but 
they don't seem to pay much attention to their bug database:
    https://issues.jboss.org/browse/CDI-377
It might be one of those "feel good" bug systems - submit a bug, and feel good! 
 Turn the knob on the toaster that doesn't do anything, and feel good!

Anyway - I hope you'll consider adding a few lines to guava's build-publish
scripts, and publish a -CDI1.1- guava artifact just to make
things easy on all the ivy (sbt, gradle, ant, ...) and maven CDI1.1 users out 
there.  You can always stop publishing the artifact in the future if it becomes 
superfluous.  It's not unusual to do that kind of oddball artifact thing - 
guice publishes a "without AOP" artifact, and then there's the "for GWT", "for 
Android", "for AppEngine", "for JDBC3", "for JDBC4", "for pre-jdk5", etc 
variants of higher level things ... the "one ring to rule them all" dream died 
a while ago ... my precious ... ;-)

Original comment by reuben.p...@gmail.com on 13 Sep 2013 at 9:00

[GoogleCodeExporter]

Using 13.0.1 helped me getting it running with Java EE 6 in Apache Tomee 1.5.2. 
I needed it as a dependency for 
https://code.google.com/p/owasp-java-html-sanitizer/
Thank you for this tip.

Original comment by zmircmir...@gmail.com on 17 Sep 2013 at 9:35

[GoogleCodeExporter]

I tried to update guava in our application today.

When I try to deploy on glassfish 4, it works fine.
Deploying on glassfish 3.1.2.2 however fails. 

When I replace the beans.xml with
<?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://java.sun.com/xml/ns/javaee/beans_1_0.xsd
                           http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">

    <weld:scan>
        <weld:exclude name="com.google.**"/>
    </weld:scan>
</beans>
instead of the Version with bean-discovery-mode="none" it's shipped with, it 
will deploy on both glassfish versions.

Original comment by thomas.a...@ergon.ch on 3 Oct 2013 at 4:15

[GoogleCodeExporter]

@thomas.andres: It looks like that will only work for Weld, though, and not 
other CDI implementations.

Original comment by cgdecker@google.com on 3 Oct 2013 at 4:27

[GoogleCodeExporter]

@cgdecker: You've mentioned in comment 33 you'll release Guava 15.0.1 (or even 
15.1) without beans.xml - is that still a plan? It would fix issue #1527 
problem.

Original comment by xaerx...@gmail.com on 4 Oct 2013 at 7:51

[GoogleCodeExporter]

My two cents.  I'm not convinced this beans.xml is doing what it advertises.  
Scanning still seems to occur.  We have successfully used guava 14.0.1 for 
quite some time without issue running essentially java EE7 inside of tomcat 
7.0.x as well as weblogic 10.3.6.  We use weld 2.1.CR1 at the moment.  I'll 
spare the details but we have nearly the entire EE7 spec running in those 
environments aside with exception of jars requiring java 7.  In those cases, we 
are still back on EE6 (EL, ejb, servlet) - all reasons beyond my control and 
silly I know.  When we try to upgrade to guava 15, we run into two issues.  
First, the issue noted here with WELD-001408.  The second is with richfaces.  
The later of which is a show stopper and something richfaces team needs to 
resolve.  However, provided they solve their issue, we still cannot upgrade so 
long as this beans.xml is inside of guava.  However, I personally have no issue 
simply removing it to make it work and keeping a patched copy in our nexus 
repository for internal use.  That matter is trivial at best.  I prefer not to 
do so, so a better solution is much wanted.  My guess is that our specific 
setup is somehow causing some regression here.  So along with others, it does 
sound like removing it is better and/or simply releasing two copies to the 
repositories until this is properly resolved.

Original comment by hazen...@gmail.com on 6 Oct 2013 at 4:27

[GoogleCodeExporter]

I'm using an OSGi web bundle which uses other OSGi services from other bundles. 
 This means I need to use CDI in my web bundle and need my classes in the 
bundle (JAR file) to be scanned.  Basically this means I can't use Guava as it 
doesn't work with CDI currently.  Whether the bean.xml is in the JAR doesn't 
really matter as I'm including the Guava code in my bundle so I don't have an 
extra dependency on Guava in case some other bundle is using a different 
version.

If the annotations are not really important for these classes, can they be 
removed?

I can manually remove these classes in my case.  However, I will not be able to 
access them in my web bundle (JAR) and seems a bit of a hack.  That is the only 
work around that I can think of right now.

Original comment by dhumen...@gmail.com on 29 Oct 2013 at 7:35

[GoogleCodeExporter]

JSR-330 annotations have been removed for Guava 16.0, so hopefully there will 
be no further issues with CDI. Now we'll just have issues when code that was 
taking advantage of the annotations stops working.

Original comment by cgdecker@google.com on 30 Oct 2013 at 10:09

[GoogleCodeExporter]

So I hope Guava 16.0 will be out soon, because right now we're stuck on ancient 
(1,5 years old) version 13...

Original comment by xaerx...@gmail.com on 30 Oct 2013 at 10:50

[GoogleCodeExporter]

@xaerxess: How are you stuck? Have you tried guava-15.0-cdi1.0.jar (with no 
beans.xml)?

Original comment by cgdec...@gmail.com on 31 Oct 2013 at 12:40

[GoogleCodeExporter]

Correct me if I'm wrong, but if we use both Java EE 6 and 7 application 
servers, there's no way having project depending on Guava 14 or 15 deployed 
without POM juggling (i.e. change classifier and rebuild whole project), right? 
It's quite troubling because Guava should remain CDI agnostic and it will be 
true for version 16.

Original comment by xaerx...@gmail.com on 31 Oct 2013 at 6:23

[GoogleCodeExporter]

@xaerxess: Yes, that's probably correct (though using Maven profiles might 
help). You could also build Guava from source with the annotations removed.

> It's quite troubling because Guava should remain CDI agnostic and it will be 
true for version 16.

So, both guava-14.0.1 and (strangely enough) guava-15.0-cdi1.0 *are* CDI 
agnostic. They only use JSR-330 annotations. To be clear: CDI itself is the 
problem here, because its specification prevents the use of libraries that 
annotate classes with certain JSR-330 annotations.

We're removing the annotations in Guava 16.0 because we feel that A) it seems 
unlikely that CDI will fix its spec anytime soon, and B) the problems this 
causes for users in CDI environments (where there apparently isn't any good 
workaround) probably outweighs the benefits of the annotations to users who are 
taking advantage of them in other environments (because at least with other 
JSR-330 frameworks like Guice and Dagger, binding the ServiceManager yourself 
isn't hard). It's not because we believe it's wrong for Guava to use the 
annotations; quite the opposite.

Original comment by cgdecker@google.com on 31 Oct 2013 at 4:14

[GoogleCodeExporter]

@cgdecker: Thanks for detailed explanation, my wording was a bit unfortunate 
(regarding Guava and CDI).

So to sum up, in perfect world (with better CDI specification *and* 
implementation) there would be no problem with JSR-330 annotated classes in 
Guava.

Original comment by xaerx...@gmail.com on 31 Oct 2013 at 6:16

[GoogleCodeExporter]

@xaerxess: Right. One of the big advantages (in my opinion) of a standard set 
of annotations for dependency injection like JSR-330 was that it would make it 
possible for libraries to make their classes easy to use with DI frameworks. 
It's really unfortunate that another Java standard simultaneously interprets 
those annotations in a way that makes that impossible.

Original comment by cgdecker@google.com on 31 Oct 2013 at 6:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

CDI 1.2 will address this problem. At least at implementation level : 
https://issues.jboss.org/browse/CDI-377
It'll be released in 2014Q1

Original comment by antoine....@gmail.com on 27 Dec 2013 at 1:53