September 2013 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-404: ---------------------------------- Just a note: although it's not very clear from the spec, interceptors are beans with scope {{@Dependent}}. See CDI spec, 6.4.1 Dependent objects: {quote} Many instances of beans with scope @Dependent belong to some other bean or Java EE component class instance and are called dependent objects. * Instances of decorators and interceptors are dependent objects of the bean instance they decorate. * ... {quote} So an interceptor from implicit bean archive should explicitly declare {{@Dependent}} scope to be processed by the container. Nevertheless making {{javax.interceptor.Interceptor}} a bean defining annotation might be a good idea... > adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" > ----------------------------------------------------------------------------------------------- > > Key: CDI-404 > URL: https://issues.jboss.org/browse/CDI-404 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.1.PFD > Reporter: Tang Yong > > [1] and [2] has reported an issue about > bean-discovery-mode="annotated". Although there are some workarounds for > the issue, I think that in the future, we should support interceptor > implict scanning while an user uses bean-discovery-mode="annotated". > Apparently, just as bean-discovery-mode="annotated", CDI Spec and > Interceptor Spec are disconnected. > [1]:https://java.net/jira/browse/GLASSFISH-20667 > [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... > About detailed discussion, please seeing the following, > https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

by Tang Yong (JIRA)

Tang Yong created CDI-404: ----------------------------- Summary: adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" Key: CDI-404 URL: https://issues.jboss.org/browse/CDI-404 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 1.1.PFD Reporter: Tang Yong [1] and [2] has reported an issue about bean-discovery-mode="annotated". Although there are some workarounds for the issue, I think that in the future, we should support interceptor implict scanning while an user uses bean-discovery-mode="annotated". Apparently, just as bean-discovery-mode="annotated", CDI Spec and Interceptor Spec are disconnected. [1]:https://java.net/jira/browse/GLASSFISH-20667 [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav... About detailed discussion, please seeing the following, https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs

by Bauke Scholtz (JIRA)

[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ] Bauke Scholtz commented on CDI-129: ----------------------------------- Dupont Dupont has a very valid question in #4. This is currently completely blocking the usage of JSF utility library OmniFaces in multiple WARs in the same EAR which is deployed to a Java EE 6 compatible container. See also https://code.google.com/p/omnifaces/issues/detail?id=251. I only wonder, isn't specifically this issue already fixed by https://issues.jboss.org/browse/WELD-1259? Haven't tried Weld 2 yet as JBoss AS 7 / EAP 6 can't be upgraded to use Weld 2. > Clarify behaviour of @ApplicationScoped in EARs > ----------------------------------------------- > > Key: CDI-129 > URL: https://issues.jboss.org/browse/CDI-129 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Contexts > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > Labels: application-scoped, visibility > Fix For: TBD > > > Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file). > There is currently no specified CDI scope for providing a single shared instance for a whole EAR. > We could (ab-)use @Singleton for that, but this is currently not well defined at all. > Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-403) why decorator requires interface

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy... ] Mathieu Lachance updated CDI-403: --------------------------------- Description: As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), would it be possible to revisit why decorator requires an interface ? I do not understand the semantic difference between: 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. Why 1. should be allowed and why 2. should be disallowed ? As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not. Thanks, was: As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), would it be possible to revisit why decorator requires an interface ? I do not understand the semantic difference between: 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. Why 1. should be allowed and why 2. should be disallowed ? As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? Thanks, > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mathieu Lachance > > As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), > would it be possible to revisit why decorator requires an interface ? > I do not understand the semantic difference between: > 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. > 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. > Why 1. should be allowed and why 2. should be disallowed ? > As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? > It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not. > Thanks, -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-403) why decorator requires interface

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy... ] Mathieu Lachance updated CDI-403: --------------------------------- Description: As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), would it be possible to revisit why decorator requires an interface ? I do not understand the semantic difference between: 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. Why 1. should be allowed and why 2. should be disallowed ? As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? Thanks, > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mathieu Lachance > > As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224), > would it be possible to revisit why decorator requires an interface ? > I do not understand the semantic difference between: > 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. > 2. a decorator to be a concrete class which extends a another class, which delegates to the same class. > Why 1. should be allowed and why 2. should be disallowed ? > As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ? > Thanks, -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-403) why decorator requires interface

by Mathieu Lachance (JIRA)

[ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy... ] Mathieu Lachance updated CDI-403: --------------------------------- Summary: why decorator requires interface (was: https://community.jboss.org/message/838498) Forum Reference: https://community.jboss.org/message/838498 > why decorator requires interface > -------------------------------- > > Key: CDI-403 > URL: https://issues.jboss.org/browse/CDI-403 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Mathieu Lachance > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-403) https://community.jboss.org/message/838498

by Mathieu Lachance (JIRA)

Mathieu Lachance created CDI-403: ------------------------------------ Summary: https://community.jboss.org/message/838498 Key: CDI-403 URL: https://issues.jboss.org/browse/CDI-403 Project: CDI Specification Issues Issue Type: Clarification Reporter: Mathieu Lachance -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by SBS JIRA Integration (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] SBS JIRA Integration updated CDI-377: ------------------------------------- Forum Reference: https://community.jboss.org/people/mkouba/blog/2013/09/20/bean-archives-i... > 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, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-377: ---------------------------------------- Well this issue is general to JavaEE. typically using spring you'll likely use @PersistenceContext, @Resource etc... and the JavaEE container can scan it (since it scans the whole app) and then try to do something and fail. In TomEE we solve it allowing to configure a list of excluding jars (a bit like Reuben said) but the issue would be to make it a CDI config since that's a JavaEE issue. Typically being able to *exclude* complete jars (surely from a pattern) would be awesome but needs IMO another descriptor usable in SE and EE mode. > 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, 3 months

1
0
0 / 0

[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 commented on CDI-377: ------------------------------------- @Mark - Maven 3.1 may be ok with @Inject annotations - for example - guice is lazy in its annotation processing, so guice will only inject a mavin class if it's required by some class needed at runtime: class Plugin { ... @Inject() public Plugin( MavinThing thing, ... ) { ... } ... } In other words - mavin's IOC world can exist along side some plugin's IOC world assuming the two worlds are working with their own set of classes. I guess OSGi is designed for this kind of plugin dso hell ... I think CDI is causing problems, because it eagerly allocates @Singleton classes that may not be needed at runtime, and may not have all dependencies available either. There are several ways CDI could make itself a more friendly JSR330 neighbor. It would be great if either or both of: o. CDI ignored jars that do not include a beans.xml o. CDI provided some outside-the-jar override mechanism in a .war or .ear or whatever file like WEB-INF/web.xml or the app-root META-INF/beans.xml: <cdi-config><exclude-jar>guava.jar</...></cdi-config> Something like that ... > 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, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2013