[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 edited comment on CDI-377 at 2/13/14 8:06 AM:
-------------------------------------------------------------------
I really think we should provide a solution at spec level for CDI-377.
For me the best solution is to change default bean discovery type to ‘none’
It’ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It’ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that they cannot support CDI 1.0 and 1.1 at the same time).
The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it’s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn’t intend to use.
was (Author: antoinesabot-durand):
I really think we should provide a solution at spec level for CDI-377.
For me the best solution is to change default bean discovery type to ‘none’
It’ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It’ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time).
The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it’s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn’t intend to use.
> 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_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> 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, 10 months
thoughts about CDI-377
by Antoine Sabot-Durand
Hi all,
Yesterday someone asked me why he couldn’t deploy hawtio [1] in Wildfly without having a crash full of weld exceptions. He couldn’t understand why he was having CDI related error on an app that contains no CDI stuff. I orientated him to Wildfly settings[2] to indicate how he could turn off implicite Bean Archive. I also had to tell him that he should do something else if he want the app to turn on Glassfish and something else when it’ll be deployed on the future Java EE 7 TomEE version.
One of the implicit jar in the hawtio.war that triggers CDI and thus make the app crash (thanks to CDI-377) is 'sisu-inject-plexus-2.3.4.jar’ coming from sonatype plexus framework I guess. First time I see this dependency...
Right now the idea to solve CDI-377 is to add exclusion list at the implementation level. But I’m quite sure that 'sisu-inject-plexus-2.3.4.jar’ would be forgot on such a list as lot of other libs. So for me this approach is flawed and totally useless. It’s a non sense to have to maintain a list of all lib including JSR 330 annotation that are not CDI !
I really think we should provide a solution at spec level for CDI-377.
Right now I have 2 suggestion :
1) Revert back default bean discovery type to ‘none’
It’ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It’ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time).
The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. Perosnaly I think it’s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn’t intend to use.
2) Provide new propagation attribute on bean element in beans.xml
so when I put
<beans version="1.1" bean-discovery-mode="none" propagate="true" >
it would propagate the « none » to all bean archive without beans.xml
I guess this solution is harder to implement and that it is not working for EAR packaging so that’s not my favorite.
Thanks for your feedback on that.
Antoine
[1] http://hawt.io
[2] https://docs.jboss.org/author/display/WFLY8/CDI+Reference
10 years, 10 months
[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:
------------------------------------------
I really think we should provide a solution at spec level for CDI-377.
For me the best solution is to change default bean discovery type to ‘none’
It’ll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It’ll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time).
The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. IMO it’s better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn’t intend to use.
> 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_spec_chge, CDI_tck_chge
> Fix For: 1.2 Proposed
>
>
> 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, 10 months
Monday meeting minutes
by Antoine Sabot-Durand
Hi all,
Forgot to post meeting minutes [1] and full log [2]. you’’l find the minutes below as well
======================
===============
#jsr346 Meeting
===============
Meeting started by antoine_sd at 16:51:58 UTC. The full logs are
available at
http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346....
.
Meeting summary
---------------
* Ready to fix review and assignation (antoine_sd, 16:52:14)
* LINK: https://issues.jboss.org/issues/?filter=12320805
(antoine_sd, 16:52:55)
* waiting PR (antoine_sd, 16:54:53)
* LINK: https://github.com/cdi-spec/cdi/pull/200 (antoine_sd,
16:56:12)
* AGREED: review policy is : at least review from the impl team + one
other (antoine_sd, 17:00:49)
* implementing team is jharting, mkouba, struberg and arne
(antoine_sd, 17:11:48)
* ACTION: create a ticket to tranform project in full maven one
(antoine_sd, 17:20:42)
* Progess and obstacles (antoine_sd, 17:21:00)
Meeting ended at 17:41:12 UTC.
Action Items
------------
* create a ticket to tranform project in full maven one
Action Items, by person
-----------------------
* **UNASSIGNED**
* create a ticket to tranform project in full maven one
======================
Unassigned point at the end is mine ;)
Antoine
[1] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346....
[2] http://transcripts.jboss.org/meeting/irc.freenode.org/jsr346/2014/jsr346....
10 years, 10 months
[JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-382:
-------------------------------
Agreed with [~struberg], I would have said something like "no additional interceptors are added to the return value, other than any already applied to injected objects or any added manually". But that is very poorly worded, ideally we would reduce this sentence to have no conjunctions that express additional conditions.
> Clarify interceptors are not associated with the result of a producer method/field
> ----------------------------------------------------------------------------------
>
> Key: CDI-382
> URL: https://issues.jboss.org/browse/CDI-382
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec.
> [1] https://github.com/cdi-spec/cdi/pull/110
> "Interceptors are not associated with the return value of a producer method or the current value of a producer field."
--
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, 10 months
[JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-382:
----------------------------------
[~struberg] by the way the spec does use the original wording for decorators, see chapter 8:
{quote}
Decorators are not applied to the return value of a producer method or the current value of a producer field.
{quote}
> Clarify interceptors are not associated with the result of a producer method/field
> ----------------------------------------------------------------------------------
>
> Key: CDI-382
> URL: https://issues.jboss.org/browse/CDI-382
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.1.PFD
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Labels: CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The interceptors part from CDI-59 resolution [1] is missing in the final version of the spec, probably lost during the Interceptors section transfer to the Interceptors 1.2 spec.
> [1] https://github.com/cdi-spec/cdi/pull/110
> "Interceptors are not associated with the return value of a producer method or the current value of a producer field."
--
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, 10 months
[JBoss JIRA] (CDI-381) Additional implementations of Request Context
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-381?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reassigned CDI-381:
----------------------------------------
Assignee: Antoine Sabot-Durand
> Additional implementations of Request Context
> ---------------------------------------------
>
> Key: CDI-381
> URL: https://issues.jboss.org/browse/CDI-381
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Labels: CDI_api_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> Suppose another spec wanted to define when @RequestScoped applied to its
> operations, how would it do that? The javadocs for @RequestScoped seem to
> be an exhaustive list, not allowing the scope to be used in other contexts.
> The javadocs need to indicate that the scope can be active at other
> times beyond what the spec describes. It can be tricky to do that in a
> way that doesn't allow people to implement the currently defined scopes
> incorrectly.
--
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, 10 months
