November 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-194) Allow AnnotatedType for a given Bean to be obtained

by Jozef Hartinger (Created) (JIRA)

Allow AnnotatedType for a given Bean to be obtained --------------------------------------------------- Key: CDI-194 URL: https://issues.jboss.org/browse/CDI-194 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Jozef Hartinger Fix For: 1.1 (Proposed) See Stuart's comment on CDI-83. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

5
18
0 / 0

[JBoss JIRA] (CDI-239) Define Extension notification rules for shared libraries

by Mark Struberg (JIRA)

Mark Struberg created CDI-239: --------------------------------- Summary: Define Extension notification rules for shared libraries Key: CDI-239 URL: https://issues.jboss.org/browse/CDI-239 Project: CDI Specification Issues Issue Type: Clarification Components: Portable Extensions Affects Versions: 1.1.EDR1 Reporter: Mark Struberg Consider an EAR file with a shared xy.JAR file in the EARs ./lib folder with an @EnterpriseApplicationScoped class X and a @RequestScoped class Y The EAR also contains 2 web applications WebAppA and WebAppB. WebAppA has ExtensionA in it's WEB-INF/classes and WebAppB has ExtensionB in it's classes both with a public void met(@Observes ProcessAnnotatedType pat) and each modifying the AnnotatedType. What should happen here? Will there be 2 Bean<T> for X and 2 for Y? (one Bean for each WebApp)? or will X and Y not trigger a ProcessAnnotatedType for the extensions defined in the webapps (but only for Extensions defined in the shared ear lib)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

2
2
0 / 0

[JBoss JIRA] (CDI-218) Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes a bean archive

by Dan Allen (JIRA)

Dan Allen created CDI-218: ----------------------------- Summary: Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes a bean archive Key: CDI-218 URL: https://issues.jboss.org/browse/CDI-218 Project: CDI Specification Issues Issue Type: Feature Request Components: Packaging and Deployment Reporter: Dan Allen Priority: Minor Chapter 12.1 specifies that beans.xml must be in the WEB-INF directory of a web archive to activate the WEB-INF/classes directory of that war as a bean archive (and thus make java:comp/BeanManager visible to the web app). However, many developers find this location both confusing and inconvenient at times. The instinct of many developers is to put the beans.xml in WEB-INF/classes/META-INF since that follows the convention that applies to library jars. Obviously, we cannot break backwards compatibility. Therefore, this issue proposes to honor either location in the war: - WEB-INF/beans.xml - WEB-INF/classes/META-INF/beans.xml If both files are present, the WEB-INF/beans.xml should take precedence and a warning is recommended. (Merging them is not likely the behavior that a developer would want). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

6
21
0 / 0

Fwd: [jsr342-experts] CDI in Application Client Container

by Pete Muir

All, It's come to light that whilst the CDI spec explicitly does not require support for the Java EE client container, the Java EE spec does require support for it. There are no TCK tests for this. The Java EE spec leads would like to rectify this by changing the CDI spec to require support for it, however, I would prefer to alter the Java EE spec and recognise this as a bug in the Java EE spec. IMO this relates very closely to Java SE support, which I we want to address in CDI 2, not in 1.1. Thoughts? Begin forwarded message: > From: Jason Greene <jason.greene(a)redhat.com> > Subject: [jsr342-experts] Re: CDI in Application Client Container > Date: 12 November 2012 23:58:17 GMT > To: jsr342-experts(a)javaee-spec.java.net > > We purposefully did not include support for the app client container in the CDI spec, mainly because it has low usage, there are numerous differences in container implementations, SE support was politically unpopular at the time, and we were waiting to see what happened with modularity. > > On Nov 11, 2012, at 2:07 PM, Bill Shannon <bill.shannon(a)oracle.com> wrote: > >> Sigh... >> >> It appears that we neither implemented nor tested support for CDI in the app client container. Clearly something we'll need to fix for EE 7, if not sooner. >> >> Bill Shannon wrote on 11/09/2012 04:47 PM: >>> Yes, based on the Java EE 6 platform spec, I intended and expected CDI to work in the app client container. >>> >>> I'm trying to find out what we actually implemented and tested... :-) >>> >>> Antonio Goncalves wrote on 11/09/12 14:10: >>>> Ok, good to know. But that means that all ACC implementations should support it then ? As Pete said, looks like the JBoss one doesn't.... >>>> >>>> I found the mail I sent to the GlassFish forum a couple of years ago about this topic (http://www.java.net/forum/topic/glassfish/glassfish/using-cdi-acc-se-envi...). I'll be doing more test to make sure and fill a bug if needed. >>>> >>>> >>>> On Fri, Nov 9, 2012 at 10:57 PM, Bill Shannon <bill.shannon(a)oracle.com> wrote: >>>> CDI is supposed to be supported in the app client container. If it's not working, please file bugs. >>>> >>>> Antonio Goncalves wrote on 11/09/12 06:09: >>>>> Hum.... for me it's just another container (EJB, Servlet & Client) so I would expect the same services from CDI. ACC is not plain Java SE, it's a container that gives you a small set of services, and that includes CDI (as per Java EE specification). >>>>> >>>>> Bill/Linda, if CDI is not supported in ACC why not getting rid of it in Figure EE.2-1 ? It's confusing. >>>>> >>>>> Antonio >>>>> >>>>> >>>>> On Fri, Nov 9, 2012 at 3:01 PM, Pete Muir <pmuir(a)bleepbleep.org.uk> wrote: >>>>> This also ties in to more general Java SE support for CDI IMO. I would probably prefer to get a general solution sorted, rather than a special case for ACC. >>>>> >>>>> On 9 Nov 2012, at 14:56, Antonio Goncalves wrote: >>>>> >>>>>> I like to use Producers and Alternatives so I can easily switch context. In the case of having CDI in ACC that would allow me to invoke different Web Serivces just by changing beans.xml >>>>>> >>>>>> >>>>>> On Fri, Nov 9, 2012 at 2:44 PM, Pete Muir <pmuir(a)bleepbleep.org.uk> wrote: >>>>>> It's not in the cdi tck so I doubt it is in jboss as. >>>>>> >>>>>> Nigel's point about scopes is very relevant. >>>>>> On 9 Nov 2012 14:03, "Antonio Goncalves" <antonio.goncalves(a)gmail.com> wrote: >>>>>> I'm not an ACC expert, but I do use it once in a while. But to be honest, I don't know why it doesn't work. If you look at the EE spec (eg. EE 7 - Figure EE.2-1) you see that CDI & DI is in the ACC. But on the other hand, the CDI 1.0 spec (12.1. Bean archives) says "The container is not required to support application client jar bean archives." I tried several time with the appclient from GlassFish, and CDI just doesn't work (wonder if JBoss ACC allows CDI or not). The "is not required" part is frustrating. >>>>>> >>>>>> Antonio >>>>>> >>>>>> >>>>>> On Fri, Nov 9, 2012 at 12:48 PM, Pete Muir <pmuir(a)bleepbleep.org.uk> wrote: >>>>>> I'm not an expert in the ACC, so would need a ACC expert who knows CDI to help us define the behavior. Interested Antonio? >>>>>> >>>>>> On 9 Nov 2012, at 12:41, Antonio Goncalves wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Correct me if I'm wrong but I haven't seen any discussion on this topic. In Java EE 6 CDI doesn't work in ACC. Wouldn't it be useful to add it in EE 7 ? >>>>>>> >>>>>>> A use case I'm working on at the moment is that I have a Java SE class (running in ACC) that injects a web service reference with @WebServiceRef. With CDI enabled I could produce this reference and just @Inject it. >>>>>>> >>>>>>> What do you think ? >>>>>>> >>>>>>> -- >>>>>>> Antonio Goncalves >>>>>>> Software architect and Java Champion >>>>>>> >>>>>>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Antonio Goncalves >>>>>> Software architect and Java Champion >>>>>> >>>>>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Antonio Goncalves >>>>>> Software architect and Java Champion >>>>>> >>>>>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Antonio Goncalves >>>>> Software architect and Java Champion >>>>> >>>>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>>> >>>> >>>> >>>> >>>> -- >>>> Antonio Goncalves >>>> Software architect and Java Champion >>>> >>>> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France >>> >> >

11 years, 5 months

5
8
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-83: ------------------------------------ Yes, createAnnotatedType() makes sense and we must retain it on the BeanManager. I was referring to the new getAnnotatedType() methods where I see no point in calling them before the container discovers and processes AnnotatedTypes. > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1 (Proposed) > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-58: ------------------------------------ In CDI-83 there is a proposal for getAnnotatedType() methods in the AfterBeanDiscovery event that would allow an extension to get the final version of the AnnotatedType it had added previously. Furthermore we could introduce getId() to ProcessSyntheticAnnotatedType. > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1 (Proposed) > > > This decision is really important to make. Either we remove/redefine BeanManager#getAnnoatadType(Class) or we remove the 'artificial annotated 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-50: ---------------------------------- https://github.com/jboss/cdi/pull/140 > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Mark Struberg reopened CDI-50: ------------------------------ Our preface still mentions @Requires. Plus it's not clear in 11.5.6 what happens if there are package-info.java @Vetoed for the same package in different JARs. Do we need to scan all jars for those first and merge the packages upfront? That could slow down scanning. It' also not clear from the Java Lang Spec what happens if you don't use package-info.java but annotate the package in a single class file. package-info.java is recommended, but the spec allows other ways as well: http://docs.oracle.com/javase/specs/jls/se5.0/html/packages.html#7.4.1.1 > Ability to veto beans, both unconditionally and based on classes visible > ------------------------------------------------------------------------ > > Key: CDI-50 > URL: https://issues.jboss.org/browse/CDI-50 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Concepts, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.PRD > > > This should support both a straight veto, and conditional based on classes available. > Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}). > Mark Struberg proposed using @Optional -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-58) Clarify that there can be multiple AnnotatedType instances per Java class

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-58?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-58: ---------------------------------- Basically ok, but don't we need an information about it's ID in the AnnotatedType itself? That could be useful for Extensions, isn't? Otherwise an Extension like Seam-XML could not differentiate between the built-in and the external AnnotatedType. > Clarify that there can be multiple AnnotatedType instances per Java class > ------------------------------------------------------------------------- > > Key: CDI-58 > URL: https://issues.jboss.org/browse/CDI-58 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans, Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Critical > Fix For: 1.1 (Proposed) > > > This decision is really important to make. Either we remove/redefine BeanManager#getAnnoatadType(Class) or we remove the 'artificial annotated 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (CDI-83) Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events.

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-83?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-83: ---------------------------------- > It is not possible to use the methods before annotated types are discovered and processed. Indeed it is! BM#createAnnotatedType is often used to create a fresh AnnotatedType from an external class which is not part of a BDA. See Seam-XML and quite a few other CDI Extensions. Removing that would break backward compatibility. I agree that it doesn't make much sense at runtime. > Clarify that BeanManager.createAnnotatedType() should return any modifications made by lifecycle events. > -------------------------------------------------------------------------------------------------------- > > Key: CDI-83 > URL: https://issues.jboss.org/browse/CDI-83 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > Fix For: 1.1 (Proposed) > > -- 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, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2012