[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Reuben Pasquini (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Reuben Pasquini reopened CDI-377:
---------------------------------
Reopening. Colin Decker described the problem well.
o. CDI-1.0 -- META-INF/beans.xml indicates "scan this jar"
o. CDI-1.1 -- no META-INF/beans.xml indicates "scan this jar"
A library like guava that has some JSR-330 annotated classes
suitable for javase IOC containers like guice, spring, and dagger; but
not suitable for CDI (which eagerly allocates singletons) is caught in
a catch 22.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI, guava, guice
> Fix For: 1.1.PFD
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Colin Decker (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Colin Decker commented on CDI-377:
----------------------------------
I think this issue should be reopened.
CDI 1.1's handling of JSR-330 annotations in jar files on the classpath is overly eager and causes problems for libraries that simply want to include JSR-330 annotations to make it easy to use those classes with JSR-330 compatible frameworks. I feel that CDI 1.1 is effectively violating JSR-330 by assuming the presence of its standard annotations (for example, @Singleton) means not that a class *can* be injected but that it *must* be injected.
This has caused problems for users of Guava, as indicated in the linked Guava issue. We tried to help those users by adding a beans.xml to the Guava jar with bean-discovery-mode=none, but that breaks CDI 1.0 users because the presence of beans.xml in the jar causes CDI 1.0 to scan the jar where it didn't before, while the bean-discovery-mode, being new in CDI 1.1, is ignored. This is a frustrating situation as it seems to mean that Guava has to choose between working out of the box for CDI 1.0, working out of the box for CDI 1.1, or removing the JSR-330 annotations entirely, an inconvenience to users of other JSR-330 frameworks.
In short, CDI should respect the fact that JSR-330 annotations are a shared standard and should not handle them in ways that restrict their use in libraries. They should never, on their own, be treated a signal that a class must be instantiated and injected. At a minimum, requiring a beans.xml file in the jar as an explicit acknowledgement that the jar wants be handled according to CDI's specification, as CDI 1.0 does, seems reasonable.
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI, guava, guice
> Fix For: 1.1.PFD
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (CDI-400) 5.4.1 Client proxy invocation section contradicts EJB spec section 3.4.7Session Object Identity
by Marina Vatkina (JIRA)
[ https://issues.jboss.org/browse/CDI-400?page=com.atlassian.jira.plugin.sy... ]
Marina Vatkina updated CDI-400:
-------------------------------
Description:
CDI 1.1
5.4.1 Client proxy invocation
"The behavior of all methods declared by java.lang.Object, except for toString(), is undefined for a client proxy.
Portable applications should not invoke any method declared by java.lang.Object, except for toString(), on a client
proxy."
EJB 3.2
3.4.7Session Object Identity
"A client can test two EJB 3.x remote or local view references for identity by means of the Object.equals and Object.hashCode methods."
Subsections define it further.
> 5.4.1 Client proxy invocation section contradicts EJB spec section 3.4.7Session Object Identity
> -----------------------------------------------------------------------------------------------
>
> Key: CDI-400
> URL: https://issues.jboss.org/browse/CDI-400
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Marina Vatkina
>
> CDI 1.1
> 5.4.1 Client proxy invocation
> "The behavior of all methods declared by java.lang.Object, except for toString(), is undefined for a client proxy.
> Portable applications should not invoke any method declared by java.lang.Object, except for toString(), on a client
> proxy."
> EJB 3.2
> 3.4.7Session Object Identity
> "A client can test two EJB 3.x remote or local view references for identity by means of the Object.equals and Object.hashCode methods."
> Subsections define it further.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (CDI-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Marko Lukša (JIRA)
Marko Lukša created CDI-398:
-------------------------------
Summary: Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
Key: CDI-398
URL: https://issues.jboss.org/browse/CDI-398
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.PFD
Reporter: Marko Lukša
Section 2.2.1 says:
{quote}
Almost any Java type may be a bean type of a bean:
• A bean type may be an array type.
{quote}
and:
{quote}
A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
{quote}
This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (CDI-389) Revert CDI-85
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-389?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-389:
----------------------------------------
Said it on the list but the minimum we have to expect from CDI is to support java rules. I agree Mark it is broken here and can't be kept in something as important as the standard IoC
> Revert CDI-85
> -------------
>
> Key: CDI-389
> URL: https://issues.jboss.org/browse/CDI-389
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (CDI-389) Revert CDI-85
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-389?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-389:
-----------------------------------
Sadly this slipped through to the final release I fear. It is really important to get this reverted as this effectively prevents us from creating generic producer methods.
See the discussion in https://issues.apache.org/jira/browse/DELTASPIKE-405
> Revert CDI-85
> -------------
>
> Key: CDI-389
> URL: https://issues.jboss.org/browse/CDI-389
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
>
> Bullet 4 of section 5.2.4 should be reverted back from:
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *from*
> the upper bound, if any, of the type variable, or
> {quote}
> to
> {quote}
> the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable *to*
> the upper bound, if any, of the type variable, or
> {quote}
> See discussion at http://lists.jboss.org/pipermail/cdi-dev/2013-July/004290.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
