[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-377:
-----------------------------
Comment: was deleted
(was: [~struberg] it's not entirely a hack but rather an example how to leverage the spec requirement, see also 12.1 Bean archives:
{quote}
"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."
{quote}
But I agree the field should not be vendor-specific.)
> 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
11 years, 1 month
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-377:
----------------------------------
[~struberg] it's not entirely a hack but rather an example how to leverage the spec requirement, see also 12.1 Bean archives:
{quote}
"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."
{quote}
But I agree the field should not be vendor-specific.
> 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
11 years, 1 month
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-377:
------------------------------------------
Romain, I don't understand the need for another descriptor. Providing this exclusion mechanism in beans.xml seems portable on Java EE and SE. Reuben proposal to provide an <exclude jar/> with a lis or a pattern seems the simpler choice.
Now we could also decide to provide a bean-discovery mode in which we do not to allocate beans in beans archives if the application doesn't define injection points with classes from these bean archive (if you don't use these classes as beans sot they're not beans). This solution would be more elegant IMO and simpler for devs.
> 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
11 years, 1 month
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-377:
-----------------------------------
Jozef, I suggest to not use the Workaround fields of the CDI tracker to point to workarounds which are _not_ in the spec but a vendor specific hack.
It might be better to create a respective WELD or JBOSSAS/ WILDFLY issue where you add the workaround howto and we link over to this issue from here.
The workaround fix in CDI should only be used for workarounds which are valid within the spec or work on all servers by a common JavaEE feature.
E.g. for BDA @Alternative (CDI-18) most of the time one can use @Specializes which (funnily) do not respect BDA restrictions. That would be fine to mark as workaround in the very CDI issue.
> 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
11 years, 1 month
Antoine Sabot-Durand
by Pete Muir
Hi all,
Many of you will know Antoine (https://twitter.com/antoine_sd) from his work on Seam, CDI and Agorava. Antoine started working at Red Hat a few months ago, and I’m delighted to say that from now on he will be working with me on the CDI spec, as well as other CDI related things.
There have been a number of issues from CDI 1.1, that need urgent attention. Therefore, Antoine’s first objective is to work on a maintenance release for CDI 1.1 (i.e. CDI 1.1.1). The goal here is to address any “typos” in the spec, as well as deal with things we underspecified, or just got plain wrong. Obviously, we do want to keep the scope of this tight, as it should be a drop in replacement for people!
I know Antoine is keen to get started, and start collecting issues that the community would like to see addressed. I think he’ll be setting up a meeting soon, but in the meantime, please do put together a list of any issues you want to see addressed in the MR.
Looking ahead, Antoine will also be joining me as co-spec lead for CDI 2, when we decide to submit the JSR for that (I would like to soon, but IMO CDI 1.1.1 is more important).
Pete
11 years, 1 month