From jira-events at lists.jboss.org Mon Dec 2 05:54:07 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 05:54:07 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-377: ------------------------------------- Fix Version/s: TBD (was: 1.1.1 (Proposed)) > 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-1.1-mr > Fix For: TBD > > > 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 From jira-events at lists.jboss.org Mon Dec 2 05:56:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 05:56:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-397) Clarify Section 6.6.3 regarding singletons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-397: ------------------------------------- Fix Version/s: 1.1.1 (Proposed) (was: TBD) > Clarify Section 6.6.3 regarding singletons > ------------------------------------------ > > Key: CDI-397 > URL: https://issues.jboss.org/browse/CDI-397 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Priority: Minor > Labels: cdi-1.1-mr > Fix For: 1.1.1 (Proposed) > > > The section 6.6.3 Passivation capable dependencies states: > {quote} > all singleton beans are passivation capable dependencies > {quote} > Clearly the specification intents to address *singleton session beans* but the current wording does not make that explicit and users confuse this line and consider javax.inject.Singleton-scoped beans also to be passivation capable dependencies. > The spec should instead say that: > {quote} > all singleton *session* beans are passivation capable dependencies > {quote} -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:04:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:04:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-389) Revert CDI-85 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-389: ------------------------------------- Labels: (was: cdi-1.1-mr) > 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 > Fix For: 1.1.1 (Proposed) > > > 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 From jira-events at lists.jboss.org Mon Dec 2 06:12:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:12:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-395: ------------------------------------- Labels: cdi-1.1-mr investigate (was: cdi-1.1-mr) > Public fields in extensions should not be allowed > ------------------------------------------------- > > Key: CDI-395 > URL: https://issues.jboss.org/browse/CDI-395 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > Labels: cdi-1.1-mr, investigate > > Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans. > The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors. > See also WELD-1474 -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:30:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:30:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-377: ------------------------------------- Labels: cdi-1.1-mr investigate (was: cdi-1.1-mr) > 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-1.1-mr, investigate > Fix For: TBD > > > 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 From jira-events at lists.jboss.org Mon Dec 2 06:36:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:36:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-370: ------------------------------------- Labels: cdi-1.1-mr investigate (was: cdi-1.1-mr) > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > Labels: cdi-1.1-mr, investigate > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-382) Clarify interceptors are not associated with the result of a producer method/field In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-382: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > 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 > Labels: 12-02-13-EGM, cdi-1.1-mr > > 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-379: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > Clarify life cycle of RequestScoped > ----------------------------------- > > Key: CDI-379 > URL: https://issues.jboss.org/browse/CDI-379 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Joseph Snyder > Priority: Minor > Labels: 12-02-13-EGM, cdi-1.1-mr > > This is one of the areas where the CDI spec could be clearer. It defines > the points where "some" request scope is active, and where "some" request > scope is destroyed, but it doesn't clearly state what the span of a particular > request context is. You sort of have to work backwards and figure it out. > Update the spec to indicate when a particular request scope is > created, what operations it's active during, and when it's destroyed. -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-77) Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-77: ------------------------------------ Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans > ---------------------------------------------------------------------------------------------------- > > Key: CDI-77 > URL: https://issues.jboss.org/browse/CDI-77 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Labels: 12-02-13-EGM, cdi-1.1-mr > Fix For: TBD > > > for example > class Foo { > @Inject Bar bar; > } > class bar { > @Inject Foo foo; > } -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-381) Additional implementations of Request Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-381: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > 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 > Priority: Minor > Labels: 12-02-13-EGM, cdi-1.1-mr > > 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-386) Two examples in section 5.2.4 contradict the rules of the same section In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-386: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > Two examples in section 5.2.4 contradict the rules of the same section > ---------------------------------------------------------------------- > > Key: CDI-386 > URL: https://issues.jboss.org/browse/CDI-386 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > Assignee: Marko Luk?a > Labels: 12-02-13-EGM, cdi-1.1-mr > > The examples in section 5.2.4 state that bean {{Dao}} is eligible for injection into both {{Dao}} and {{Dao}}, but according to the rules stated in the same section this isn't true. > Also note that the spec doesn't state explicitly that {{Order extends Persistent}} and {{User extends Persistent}}. -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:07 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:07 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-401) Clarify the meaning of "bean class local view" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-401: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > Clarify the meaning of "bean class local view" > ---------------------------------------------- > > Key: CDI-401 > URL: https://issues.jboss.org/browse/CDI-401 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Labels: 12-02-13-EGM, cdi-1.1-mr > > 3.2.2 Bean types of a session bean: > {quote} > The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a *bean class local view*, the unrestricted set of bean types contains the bean class and all superclasses. > ... > {quote} > AFAIK the EJB spec does not define anything like "bean class local view". I believe the CDI spec is referencing *No-Interface View* here (a variation of the local view that exposes the non-static public methods of the bean class without the use of a separate business interface). -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:07 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:07 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-392) Clarify when the operations of BeanManager can be called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-392: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > Clarify when the operations of BeanManager can be called > -------------------------------------------------------- > > Key: CDI-392 > URL: https://issues.jboss.org/browse/CDI-392 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Matus Abaffy > Labels: 12-02-13-EGM, cdi-1.1-mr > > The current version of spec. states (under 11.3. The BeanManager object): "Any operation of BeanManager may be called at any time during the execution of the application." > This sentence is likely to be misinterpreted (see WELD-1453). Pointing out that BeanManager's methods can be called (without causing exception) just after AfterDeploymentValidation event is fired might be helpful. -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:07 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:07 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-405) Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-405: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 > -------------------------------------------------------------------------------- > > Key: CDI-405 > URL: https://issues.jboss.org/browse/CDI-405 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Labels: 12-02-13-EGM, cdi-1.1-mr > > @RequestScoped and @ApplicationScoped are not servlet-specific (see sections 6.7.1 and 6.7.3 for more use cases). -- 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 From jira-events at lists.jboss.org Mon Dec 2 06:51:07 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Mon, 2 Dec 2013 06:51:07 -0500 (EST) Subject: [cdi-dev] [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 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-398: ------------------------------------- Labels: 12-02-13-EGM cdi-1.1-mr (was: cdi-1.1-mr) > 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 > Labels: 12-02-13-EGM, cdi-1.1-mr > > 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 From antoine at sabot-durand.net Mon Dec 2 08:10:07 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 2 Dec 2013 14:10:07 +0100 Subject: [cdi-dev] Fwd: Today's hangout agenda References: <33BFADD1-B9DC-47C1-A337-0DF07719381D@redhat.com> Message-ID: <27FA284F-13E1-4F13-A0EC-CB9DB58F3D2C@sabot-durand.net> Hi all I propose the following Agenda 1) Pete will do a feed back on Java EE EG conf call we had on tuesday 2) Issues discussion I propose we try to deal with this issues. If we don?t have enough time, we?ll have some more next week CDI-405 Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1 CDI-401 Clarify the meaning of "bean class local view" CDI-398 Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type CDI-392 Clarify when the operations of BeanManager can be called CDI-386 Two examples in section 5.2.4 contradict the rules of the same section CDI-382 Clarify interceptors are not associated with the result of a producer method/field CDI-381 Additional implementations of Request Context CDI-379 Clarify life cycle of RequestScoped CDI-77 Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans The hangout link is here : https://plus.google.com/hangouts/_/calendar/YW50b2luZS5zYWJvdGR1cmFuZEBnbWFpbC5jb20.1hfu90pc7ofusmsjhgim6d2p7s Antoine Sabot-Durand ??????????????? Twitter : @antoine_sd CDI co-spec lead & eco-system development Agorava tech lead -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131202/3d6afb97/attachment-0001.html From antoine at sabot-durand.net Mon Dec 2 11:22:37 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 2 Dec 2013 17:22:37 +0100 Subject: [cdi-dev] EG meeting publish on web site Message-ID: <41CECBF1-4DF2-4314-99DA-F7847898AF16@sabot-durand.net> Hi all, Just to let you know that I published meeting minutes on the website. in the news section [1] I also did some minor change to the site : - Removed ? major issues section ? which wasn?t working (will put it back after I figured out how to make it work again) - Added link to G+ and Twitter Before adding tutorial, howtos and a page pouting CDI initiatives and extensions, I plan to do a little more work on UI and navigation. Roughly, I plan to change the navigation with a more classical navbar on the top, Upgrade to awestruct 0.5.3 and bootstrap 3.x (started the migration) and integrated our ml from Nabble embedded or an other service if you know a better one. Your input, ideas, help is off course most welcome. Antoine [1] http://www.cdi-spec.org/news/ From jira-events at lists.jboss.org Tue Dec 3 04:09:06 2013 From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 3 Dec 2013 04:09:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-410: ----------------------------------- Summary: @RequestScoped Javadoc outdated Key: CDI-410 URL: https://issues.jboss.org/browse/CDI-410 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.1.FD Reporter: Jozef Hartinger The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context] -- 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 From jira-events at lists.jboss.org Tue Dec 3 04:24:05 2013 From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 3 Dec 2013 04:24:05 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec In-Reply-To: References: Message-ID: Jozef Hartinger created CDI-411: ----------------------------------- Summary: CDI conversation activation conflicts with the Servlet spec Key: CDI-411 URL: https://issues.jboss.org/browse/CDI-411 Project: CDI Specification Issues Issue Type: Bug Components: Java EE integration Affects Versions: 1.1.FD Reporter: Jozef Hartinger The Servlet specification says: {quote} If the client hasn't set character encoding and the request data is encoded with a different encoding than the default as described above, breakage can occur. To remedy this situation, a new method setCharacterEncoding(String enc) has been added to the ServletRequest interface. Developers can override the character encoding supplied by the container by calling this method. It must be called prior to parsing any post data or reading any input from the request. Calling this method once data has been read will not affect the encoding. {quote} The CDI specification says: {quote} The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web application and before the container calls any ServletRequestListener or AsyncListener in the web application. {quote} and {quote} The long-running conversation associated with a request may be propagated to any Servlet request via use of a request parameter named cid containing the unique identifier of the conversation. {quote} This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding. This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion. -- 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 From jira-events at lists.jboss.org Tue Dec 3 04:24:06 2013 From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 3 Dec 2013 04:24:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger updated CDI-411: -------------------------------- Workaround Description: Map the CDI Conversation Filter in web.xml and set character encoding in a filter that executes before the CDI filter http://weld.cdi-spec.org/documentation/#3 Workaround: Workaround Exists > CDI conversation activation conflicts with the Servlet spec > ----------------------------------------------------------- > > Key: CDI-411 > URL: https://issues.jboss.org/browse/CDI-411 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > > The Servlet specification says: > {quote} > If the client hasn't set character encoding and the request data is encoded with a > different encoding than the default as described above, breakage can occur. To > remedy this situation, a new method setCharacterEncoding(String enc) has been > added to the ServletRequest interface. Developers can override the character > encoding supplied by the container by calling this method. It must be called prior to > parsing any post data or reading any input from the request. Calling this method > once data has been read will not affect the encoding. > {quote} > The CDI specification says: > {quote} > The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the > user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the > application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any > service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web > application and before the container calls any ServletRequestListener or AsyncListener in the web application. > {quote} > and > {quote} > The long-running conversation associated with a request may be propagated to any Servlet request via use of a request > parameter named cid containing the unique identifier of the conversation. > {quote} > This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding. > This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion. -- 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 From antoine at sabot-durand.net Tue Dec 3 05:09:51 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 3 Dec 2013 11:09:51 +0100 Subject: [cdi-dev] Yesterday meeting notes Message-ID: <7083F6EC-15EA-4CD9-9588-488C36F8F99D@sabot-durand.net> Hi all, Meetings notes are available on cdi-spec website [1]. Let me know if you have correction or things I forgotten. Antoine [1] http://www.cdi-spec.org/news/2013/12/02/EG-meeting/ From antoine at sabot-durand.net Tue Dec 3 05:40:27 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 3 Dec 2013 11:40:27 +0100 Subject: [cdi-dev] Google short URL Message-ID: Hi, Just to let you know that thanks to website association Google allowed us to create a short URL for CDI G+ page : google.com/+CdiSpecOrgPage. The drawback is that we lost most of our +1 in the process (we add +105 and reverted +29) probably due to the score of official website page. Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131203/1fe43c3b/attachment.html From jira-events at lists.jboss.org Tue Dec 3 05:41:05 2013 From: jira-events at lists.jboss.org (Martin Kouba (JIRA)) Date: Tue, 3 Dec 2013 05:41:05 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-412) Add assertions to tests located in org.jboss.cdi.tck.interceptors.tests.aroundConstruct package and subpackages In-Reply-To: References: Message-ID: Martin Kouba created CDI-412: -------------------------------- Summary: Add assertions to tests located in org.jboss.cdi.tck.interceptors.tests.aroundConstruct package and subpackages Key: CDI-412 URL: https://issues.jboss.org/browse/CDI-412 Project: CDI Specification Issues Issue Type: Feature Request Components: Interceptors Reporter: Martin Kouba These tests do not contain assertions because it wasn't clear whether the Interceptors 1.2 spec will have its own TCK. -- 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 From jira-events at lists.jboss.org Fri Dec 6 03:33:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 6 Dec 2013 03:33:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-379: ------------------------------------- Labels: (was: 12-02-13-EGM cdi-1.1-mr) > Clarify life cycle of RequestScoped > ----------------------------------- > > Key: CDI-379 > URL: https://issues.jboss.org/browse/CDI-379 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Joseph Snyder > Priority: Minor > > This is one of the areas where the CDI spec could be clearer. It defines > the points where "some" request scope is active, and where "some" request > scope is destroyed, but it doesn't clearly state what the span of a particular > request context is. You sort of have to work backwards and figure it out. > Update the spec to indicate when a particular request scope is > created, what operations it's active during, and when it's destroyed. -- 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 From jira-events at lists.jboss.org Fri Dec 6 03:37:05 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 6 Dec 2013 03:37:05 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-379. ------------------------------------ Resolution: Rejected This task was examined during 12/02/2013 EG meeting (Hangout). CDI spec cannot tell how other spec use built-in scopes. So it's the work of each specification to give information about validity and activation of @RequestScoped and others. > Clarify life cycle of RequestScoped > ----------------------------------- > > Key: CDI-379 > URL: https://issues.jboss.org/browse/CDI-379 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Joseph Snyder > Priority: Minor > > This is one of the areas where the CDI spec could be clearer. It defines > the points where "some" request scope is active, and where "some" request > scope is destroyed, but it doesn't clearly state what the span of a particular > request context is. You sort of have to work backwards and figure it out. > Update the spec to indicate when a particular request scope is > created, what operations it's active during, and when it's destroyed. -- 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 From jira-events at lists.jboss.org Fri Dec 6 03:39:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 6 Dec 2013 03:39:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-77) Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-77: ------------------------------------ Labels: (was: 12-02-13-EGM cdi-1.1-mr) > Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans > ---------------------------------------------------------------------------------------------------- > > Key: CDI-77 > URL: https://issues.jboss.org/browse/CDI-77 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: TBD > > > for example > class Foo { > @Inject Bar bar; > } > class bar { > @Inject Foo foo; > } -- 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 From jira-events at lists.jboss.org Fri Dec 6 03:50:06 2013 From: jira-events at lists.jboss.org (Antoine Sabot-Durand (JIRA)) Date: Fri, 6 Dec 2013 03:50:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-77) Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-77. ----------------------------------- Resolution: Rejected This task was examined during 12/02/2013 EG meeting (Hangout). The specification already specify that container doesn't have to support circular chains of dependencies on pseudo-scope's only beans (Last sentence of Chapter 5 introduction). So this issue is already answered. The answer is "unpredictable result since container doesn't have to support this kind of circular dep" > Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans > ---------------------------------------------------------------------------------------------------- > > Key: CDI-77 > URL: https://issues.jboss.org/browse/CDI-77 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: TBD > > > for example > class Foo { > @Inject Bar bar; > } > class bar { > @Inject Foo foo; > } -- 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 From antoine at sabot-durand.net Fri Dec 6 05:12:39 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Fri, 6 Dec 2013 11:12:39 +0100 Subject: [cdi-dev] Monday EG meeting agenda Message-ID: Dear all, The following issue are the last one to deal with for 1.2 MR inclusion : CDI-380 Clarify SessionScoped CDI-372 clarify behaviour of implicit bean archive CDI-370 Expand @RequestScoped and @SessionScoped to account for WebSocket CDI-320 Clarify whether ProcessAnnotatedType should be fired for annotations CDI-318 @WithAnnotations types can appear on any supertype CDI-280 clarify usage of 'bean' term usage in the spec CDI-220 behaviour of CDI bean @Specializes session bean is undefined I also wanted to have a definitive decision for "CDI -377 automatic JSR-330 annotation processing problematic" We agreed on the fact that specific exclusion list should be maintain at implementation level, but we didn?t decide if the exclusion mechanism (that would allow user to add their own excluded Beanarchive / package) should be exposed in the spec and thus be fixed in 1.2. Which would be great IMHO. Antoine From jira-events at lists.jboss.org Fri Dec 6 13:46:07 2013 From: jira-events at lists.jboss.org (Bill Shannon (JIRA)) Date: Fri, 6 Dec 2013 13:46:07 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929288#comment-12929288 ] Bill Shannon commented on CDI-379: ---------------------------------- There's two parts to this: 1. The existing uses of @RequestScoped need to be better specified. Yes, that should probably be done in each spec that controls the scope, but until that can be done it would be helpful to do it in the CDI spec. 2. The definition of @RequestScoped needs to be generalized so that it's clear that other specs *can* define their own use of @RequestScoped, and that the use of @RequestScoped isn't limited to the cases currently defined by the CDI spec. > Clarify life cycle of RequestScoped > ----------------------------------- > > Key: CDI-379 > URL: https://issues.jboss.org/browse/CDI-379 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Joseph Snyder > Priority: Minor > > This is one of the areas where the CDI spec could be clearer. It defines > the points where "some" request scope is active, and where "some" request > scope is destroyed, but it doesn't clearly state what the span of a particular > request context is. You sort of have to work backwards and figure it out. > Update the spec to indicate when a particular request scope is > created, what operations it's active during, and when it's destroyed. -- 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 From jira-events at lists.jboss.org Mon Dec 9 07:52:08 2013 From: jira-events at lists.jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Dec 2013 07:52:08 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-318: ----------------------------- Priority: Minor (was: Major) > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Minor > Labels: cdi-1.1-mr > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- 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 From jira-events at lists.jboss.org Mon Dec 9 07:58:07 2013 From: jira-events at lists.jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Dec 2013 07:58:07 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929478#comment-12929478 ] Martin Kouba commented on CDI-318: ---------------------------------- Actually this is not a real issue but rather a hint for clarification. An example: {code} @Target({ TYPE, METHOD, PARAMETER, FIELD, CONSTRUCTOR }) @Retention(RUNTIME) @Inherited public @interface Marker { } @Marker public interface Foo { } public class Bar implements Foo { } {code} and observer: {code} public void observeMarker(@WithAnnotations({ Marker.class }) @Observes ProcessAnnotatedType pat) { } {code} I think PAT for Bar should be observed because @Marker is inherited (CDI follows JSL rules here). The question is whether this makes sense because "A bean may inherit type-level metadata and members from its superclasses", not superinterfaces. > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Minor > Labels: cdi-1.1-mr > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- 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 From jira-events at lists.jboss.org Mon Dec 9 11:42:06 2013 From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 9 Dec 2013 11:42:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-410) @RequestScoped Javadoc outdated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger updated CDI-410: -------------------------------- Labels: cdi-1.1-mr (was: ) > @RequestScoped Javadoc outdated > ------------------------------- > > Key: CDI-410 > URL: https://issues.jboss.org/browse/CDI-410 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Labels: cdi-1.1-mr > > The Javadoc for [@RequestScoped|http://docs.jboss.org/cdi/api/1.1/javax/enterprise/context/RequestScoped.html] is since CDI 1.1 out of sync with the [specification|http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#request_context] -- 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 From jira-events at lists.jboss.org Mon Dec 9 11:42:06 2013 From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 9 Dec 2013 11:42:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger updated CDI-411: -------------------------------- Labels: cdi-1.1-mr (was: ) > CDI conversation activation conflicts with the Servlet spec > ----------------------------------------------------------- > > Key: CDI-411 > URL: https://issues.jboss.org/browse/CDI-411 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Labels: cdi-1.1-mr > > The Servlet specification says: > {quote} > If the client hasn't set character encoding and the request data is encoded with a > different encoding than the default as described above, breakage can occur. To > remedy this situation, a new method setCharacterEncoding(String enc) has been > added to the ServletRequest interface. Developers can override the character > encoding supplied by the container by calling this method. It must be called prior to > parsing any post data or reading any input from the request. Calling this method > once data has been read will not affect the encoding. > {quote} > The CDI specification says: > {quote} > The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the > user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the > application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any > service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web > application and before the container calls any ServletRequestListener or AsyncListener in the web application. > {quote} > and > {quote} > The long-running conversation associated with a request may be propagated to any Servlet request via use of a request > parameter named cid containing the unique identifier of the conversation. > {quote} > This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding. > This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion. -- 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 From jira-events at lists.jboss.org Mon Dec 9 12:28:06 2013 From: jira-events at lists.jboss.org (Martin Kouba (JIRA)) Date: Mon, 9 Dec 2013 12:28:06 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-318) @WithAnnotations types can appear on any supertype In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929478#comment-12929478 ] Martin Kouba edited comment on CDI-318 at 12/9/13 12:26 PM: ------------------------------------------------------------ Actually this is an inconsistency between the spec wording and javadoc. An example: {code} @Target({ TYPE, METHOD, PARAMETER, FIELD, CONSTRUCTOR }) @Retention(RUNTIME) @Inherited public @interface Marker { } @Marker public interface Foo { } public class Bar implements Foo { } {code} and observer: {code} public void observeMarker(@WithAnnotations({ Marker.class }) @Observes ProcessAnnotatedType pat) { } {code} @WithAnnotations javadoc defines the PAT for Bar should be observed (CDI does not follow JSL rules here) whereas the spec text states CDI should follow JSL rules. was (Author: mkouba): Actually this is not a real issue but rather a hint for clarification. An example: {code} @Target({ TYPE, METHOD, PARAMETER, FIELD, CONSTRUCTOR }) @Retention(RUNTIME) @Inherited public @interface Marker { } @Marker public interface Foo { } public class Bar implements Foo { } {code} and observer: {code} public void observeMarker(@WithAnnotations({ Marker.class }) @Observes ProcessAnnotatedType pat) { } {code} I think PAT for Bar should be observed because @Marker is inherited (CDI follows JSL rules here). The question is whether this makes sense because "A bean may inherit type-level metadata and members from its superclasses", not superinterfaces. > @WithAnnotations types can appear on any supertype > -------------------------------------------------- > > Key: CDI-318 > URL: https://issues.jboss.org/browse/CDI-318 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Minor > Labels: cdi-1.1-mr > > Is this intentional? Supertypes also include interfaces which are not very useful here as beans may inherit type-level metadata and members from superclasses only. > Is there any special use-case for this? -- 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 From linda.demichiel at oracle.com Mon Dec 9 13:09:58 2013 From: linda.demichiel at oracle.com (Linda DeMichiel) Date: Mon, 09 Dec 2013 10:09:58 -0800 Subject: [cdi-dev] Java EE 8 features survey Message-ID: <52A60776.1010907@oracle.com> As part of our early planning for Java EE 8, at JavaOne we held a "Meet the Spec Leads" BOF and a Java EE Platform expert group meeting to gather input about features to consider. A summary of the results of from that effort are linked here https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-10/message/2. Our intent was to use the input from those gatherings to prepare a survey to collect feedback from the entire community, similar to what we had done a year ago for Java EE 7 issues. We've just launched this broader Java EE 8 features survey. Due to its length, we are running it in two parts. Part 1 is now live at https://www.surveymonkey.com/s/KGV7RWS We plan to release part 2 in mid/late January. Once we gather, distill, and announce the results, our plan will be to ask for further feedback to help us prioritize among items that receive significant support. Please participate and help us spread the word. thanks, -Linda From antoine at sabot-durand.net Wed Dec 11 06:00:36 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 11 Dec 2013 12:00:36 +0100 Subject: [cdi-dev] monday's meeting notes Message-ID: <03F75FA4-3D19-4B1A-B365-B0C5856C7AF6@sabot-durand.net> Hi all, You?ll find monday?s meeting notes here [1]. As mentioned in the notes we still have time to examine other easy tickets (would say between 5 and 10) to decide their inclusion in MR. So if you have wishes feel free to send them before the closing of the list after next meeting. Antoine [1] http://www.cdi-spec.org/news/2013/12/09/EG-meeting/ From antoine at sabot-durand.net Wed Dec 11 09:34:49 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Wed, 11 Dec 2013 15:34:49 +0100 Subject: [cdi-dev] MR issue list References: <99934C77-D49A-45C3-9633-3E3F02272F2F@redhat.com> Message-ID: Hi all, Just posted list of 22 issue we discussed these last weeks and their adoption status in MR [1]. So, 18 issues were already included, 3 were rejected and one still need input from implementations team : CDI-395 Public fields in extensions should not be allowed [2]. As I said in my previous mail we could still add a few more ticket (if they are not big) to discuss during our next meeting (monday 16th). So send the tickets ! [1] http://www.cdi-spec.org/news/2013/12/11/CDI-1-2MR-issues-list/ [2] https://issues.jboss.org/browse/CDI-395 Antoine Sabot-Durand -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131211/f9949778/attachment.html From struberg at yahoo.de Thu Dec 12 10:23:52 2013 From: struberg at yahoo.de (Mark Struberg) Date: Thu, 12 Dec 2013 15:23:52 +0000 (GMT) Subject: [cdi-dev] Producer wrapper Message-ID: <1386861832.39864.BPMail_high_noncarrier@web28901.mail.ir2.yahoo.com> 1. Producer / InjectionTarget might create instances which are wrapped in proxies. 2. event observer methods are allowed to be private and thus are not in the proxies. 3. extensions are allowed to 'decorate' InjectionTargets and Producers. This means that we need some unwrap method in the spec, right? Currently this does not York. LieGrue, strub From antoine at sabot-durand.net Mon Dec 16 05:29:48 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Dec 2013 11:29:48 +0100 Subject: [cdi-dev] Today's meeting Agenda Message-ID: <63D71831-ABD1-44CA-B9E0-C0200CDD2342@sabot-durand.net> Hi all, I didn?t receive any extra wishes for the MR. So I guess we have a final list here (except if you bring your issues in live in the last minute). I propose the following agenda : 1. Discussion on the last ticket pending : CDI-395 Public fields in extensions should not be allowed [1] 2. Last second ticket if any 3. Starting the MR Regards, Antoine [1] https://issues.jboss.org/browse/CDI-395 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/38f22ca6/attachment.html From antoine at sabot-durand.net Mon Dec 16 06:16:35 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Dec 2013 12:16:35 +0100 Subject: [cdi-dev] Preparing CDI 2.0 Message-ID: <0C1C783B-F6B9-44E4-AEA5-D5A9780C5979@sabot-durand.net> Hi all, I really like to gather community feedback on CDI to prepare the coming CDI 2.0 JSR proposal. It will help us to deliver something nearer from user?s need and will have the side effect to make some buzz around CDI. I propose the following steps : 1. Open an informal idea box. A google form with which anybody could send us 3 wishes for CDI 2.0. It could be launch now and be open until midd-january for instance 2. Compiling these ideas + Our wishes idea + JIRA already open , we?ll prose a survey to obtain priorities on all the topic. It could be open from end-januray to mid-february (could be more depending on Java EE 8 launch timeframe) 3. Create the prioritize list of feature for CDI 2.0 4. Propose a JSR for CDI 2.0 in March-april including the list of prioritize items. Other side-effect from this is the possibility to gain new contributor to the specification in the process. Your feedback, ideas, concern about this idea are as always, welcome. Regards, Antoine From arne.limburg at openknowledge.de Mon Dec 16 06:37:53 2013 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Mon, 16 Dec 2013 11:37:53 +0000 Subject: [cdi-dev] Producer wrapper In-Reply-To: <1386861832.39864.BPMail_high_noncarrier@web28901.mail.ir2.yahoo.com> Message-ID: Hi, A simple solution to this topic would be to state in the spec, that, if an extension replaces an InjectionTarget or Producer it MUST provide a custom Implementation of an ObserverMethod for every private observer method of that bean. WDYT? Maybe we should discuss this in the meeting this evening? Regards, Arne Am 12.12.13 16:23 schrieb "Mark Struberg" unter : > >1. Producer / InjectionTarget might create instances which are wrapped in >proxies. > >2. event observer methods are allowed to be private and thus are not in >the proxies. > >3. extensions are allowed to 'decorate' InjectionTargets and Producers. > > >This means that we need some unwrap method in the spec, right? >Currently this does not York. > >LieGrue, >strub > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev From arne.limburg at openknowledge.de Mon Dec 16 06:52:21 2013 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Mon, 16 Dec 2013 11:52:21 +0000 Subject: [cdi-dev] FW: Producer wrapper In-Reply-To: Message-ID: I guess, this mail was meant to go to the list ;-) Von: Romain Manni-Bucau > Datum: Montag, 16. Dezember 2013 12:50 An: Arne Limburg > Betreff: Re: [cdi-dev] Producer wrapper I think the main issue is to avoid to make extensions hard/long to write (already too complicated for common stuff IMO) so i dont like this solution. It is great to have a clean design...it is better to have something usable. CDI needs to work on the last quickly IMO before adding any feature. Le 16 d?c. 2013 12:38, "Arne Limburg" > a ?crit : Hi, A simple solution to this topic would be to state in the spec, that, if an extension replaces an InjectionTarget or Producer it MUST provide a custom Implementation of an ObserverMethod for every private observer method of that bean. WDYT? Maybe we should discuss this in the meeting this evening? Regards, Arne Am 12.12.13 16:23 schrieb "Mark Struberg" unter >: > >1. Producer / InjectionTarget might create instances which are wrapped in >proxies. > >2. event observer methods are allowed to be private and thus are not in >the proxies. > >3. extensions are allowed to 'decorate' InjectionTargets and Producers. > > >This means that we need some unwrap method in the spec, right? >Currently this does not York. > >LieGrue, >strub > >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/0ffe332e/attachment.html From rmannibucau at gmail.com Mon Dec 16 06:54:59 2013 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 16 Dec 2013 12:54:59 +0100 Subject: [cdi-dev] FW: Producer wrapper In-Reply-To: References: Message-ID: Sure! Thks Arne. Le 16 d?c. 2013 12:52, "Arne Limburg" a ?crit : > I guess, this mail was meant to go to the list ;-) > > Von: Romain Manni-Bucau > Datum: Montag, 16. Dezember 2013 12:50 > An: Arne Limburg > Betreff: Re: [cdi-dev] Producer wrapper > > I think the main issue is to avoid to make extensions hard/long to > write (already too complicated for common stuff IMO) so i dont like this > solution. > > It is great to have a clean design...it is better to have something > usable. CDI needs to work on the last quickly IMO before adding any feature. > Le 16 d?c. 2013 12:38, "Arne Limburg" a > ?crit : > >> Hi, >> >> >> A simple solution to this topic would be to state in the spec, that, if an >> extension replaces an InjectionTarget or Producer it MUST provide a custom >> Implementation of an ObserverMethod for every private observer method of >> that bean. >> WDYT? Maybe we should discuss this in the meeting this evening? >> >> Regards, >> Arne >> >> Am 12.12.13 16:23 schrieb "Mark Struberg" unter : >> >> > >> >1. Producer / InjectionTarget might create instances which are wrapped in >> >proxies. >> > >> >2. event observer methods are allowed to be private and thus are not in >> >the proxies. >> > >> >3. extensions are allowed to 'decorate' InjectionTargets and Producers. >> > >> > >> >This means that we need some unwrap method in the spec, right? >> >Currently this does not York. >> > >> >LieGrue, >> >strub >> > >> >_______________________________________________ >> >cdi-dev mailing list >> >cdi-dev at lists.jboss.org >> >https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/018a3ee1/attachment-0001.html From jens.schumann at openknowledge.de Mon Dec 16 07:38:12 2013 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Mon, 16 Dec 2013 12:38:12 +0000 Subject: [cdi-dev] Today's meeting Agenda In-Reply-To: <63D71831-ABD1-44CA-B9E0-C0200CDD2342@sabot-durand.net> Message-ID: Hi Antoine! Here is MY extra wish: https://issues.jboss.org/browse/CDI-408. For the MR I think it would be OK to clarify that both @Producer and @Observes will be ignored if bean-discovery-mode="annotated" and the producer field/producer method/observer method is in a bean without a bean defining annotation. Even if I consider @Dependent @Producer/@Observes a bad practice it did work before and can lead to unexpected results, especially for observers. @Arne: Could you please be my voice in today's meeting? ;) Jens Von: Antoine Sabot-Durand > Datum: Montag, 16. Dezember 2013 11:29 An: CDI-Dev > Betreff: [cdi-dev] Today's meeting Agenda Hi all, I didn?t receive any extra wishes for the MR. So I guess we have a final list here (except if you bring your issues in live in the last minute). I propose the following agenda : 1. Discussion on the last ticket pending : CDI-395 Public fields in extensions should not be allowed [1] 2. Last second ticket if any 3. Starting the MR Regards, Antoine [1] https://issues.jboss.org/browse/CDI-395 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/6106bd1e/attachment.html From arne.limburg at openknowledge.de Mon Dec 16 07:45:46 2013 From: arne.limburg at openknowledge.de (Arne Limburg) Date: Mon, 16 Dec 2013 12:45:46 +0000 Subject: [cdi-dev] Today's meeting Agenda In-Reply-To: Message-ID: Hmm, especially the @Produces case needs to be clarified, since it may be that there is a bean-defining annotation at method-level. And we should address https://issues.jboss.org/browse/CDI-404 too in this context. Regards, Arne Von: Jens Schumann > Datum: Montag, 16. Dezember 2013 13:38 An: Antoine Sabot-Durand >, "cdi-dev at lists.jboss.org" > Betreff: Re: [cdi-dev] Today's meeting Agenda Hi Antoine! Here is MY extra wish: https://issues.jboss.org/browse/CDI-408. For the MR I think it would be OK to clarify that both @Producer and @Observes will be ignored if bean-discovery-mode="annotated" and the producer field/producer method/observer method is in a bean without a bean defining annotation. Even if I consider @Dependent @Producer/@Observes a bad practice it did work before and can lead to unexpected results, especially for observers. @Arne: Could you please be my voice in today's meeting? ;) Jens Von: Antoine Sabot-Durand > Datum: Montag, 16. Dezember 2013 11:29 An: CDI-Dev > Betreff: [cdi-dev] Today's meeting Agenda Hi all, I didn?t receive any extra wishes for the MR. So I guess we have a final list here (except if you bring your issues in live in the last minute). I propose the following agenda : 1. Discussion on the last ticket pending : CDI-395 Public fields in extensions should not be allowed [1] 2. Last second ticket if any 3. Starting the MR Regards, Antoine [1] https://issues.jboss.org/browse/CDI-395 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/ffca8f22/attachment.html From issues at jboss.org Mon Dec 16 07:48:34 2013 From: issues at jboss.org (Arne Limburg (JIRA)) Date: Mon, 16 Dec 2013 07:48:34 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931806#comment-12931806 ] Arne Limburg commented on CDI-404: ---------------------------------- Two options here, I guess: 1. Make @Interceptor and @Decorator a bean-defining annotation 2. Define, that the container must detect the problem that there is an interceptor or decorator enabled through beans.xml that is no bean, because it has no bean-defining annotation. > 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 > Fix For: 1.1.1 (Proposed) > > > [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-java-ee7 > 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 From antoine at sabot-durand.net Mon Dec 16 09:21:30 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Dec 2013 15:21:30 +0100 Subject: [cdi-dev] Today's meeting Agenda In-Reply-To: References: Message-ID: Thanks jens. That?s an interesting point that worth MR inclusion discussion. Antoine Le 16 d?c. 2013 ? 13:38, Jens Schumann a ?crit : > Hi Antoine! > > Here is MY extra wish: https://issues.jboss.org/browse/CDI-408. > > For the MR I think it would be OK to clarify that both @Producer and @Observes will be ignored if bean-discovery-mode="annotated" and the producer field/producer method/observer method is in a bean without a bean defining annotation. Even if I consider @Dependent @Producer/@Observes a bad practice it did work before and can lead to unexpected results, especially for observers. > > @Arne: Could you please be my voice in today's meeting? ;) > Jens > > Von: Antoine Sabot-Durand > Datum: Montag, 16. Dezember 2013 11:29 > An: CDI-Dev > Betreff: [cdi-dev] Today's meeting Agenda > > Hi all, > > I didn?t receive any extra wishes for the MR. So I guess we have a final list here (except if you bring your issues in live in the last minute). > > I propose the following agenda : > > 1. Discussion on the last ticket pending : CDI-395 Public fields in extensions should not be allowed [1] > 2. Last second ticket if any > 3. Starting the MR > > Regards, > > Antoine > > > [1] https://issues.jboss.org/browse/CDI-395 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/831b7d8b/attachment.html From antoine at sabot-durand.net Mon Dec 16 09:32:06 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Mon, 16 Dec 2013 15:32:06 +0100 Subject: [cdi-dev] Producer wrapper In-Reply-To: References: Message-ID: Romain, I totally agree. Extension are a powerful tool but they are very intimidating to write for newbie : CDI bootstrap lifecycle doesn?t give an impression of easiness ;). I think we should think about a kind of ? configuration layer ? on top of extension for CDI 2.0 to allow an easier way to create simple extension? Antoine Le 16 d?c. 2013 ? 12:54, Romain Manni-Bucau a ?crit : > Sure! Thks Arne. > > Le 16 d?c. 2013 12:52, "Arne Limburg" a ?crit : > I guess, this mail was meant to go to the list ;-) > > Von: Romain Manni-Bucau > Datum: Montag, 16. Dezember 2013 12:50 > An: Arne Limburg > Betreff: Re: [cdi-dev] Producer wrapper > > I think the main issue is to avoid to make extensions hard/long to write (already too complicated for common stuff IMO) so i dont like this solution. > > It is great to have a clean design...it is better to have something usable. CDI needs to work on the last quickly IMO before adding any feature. > Le 16 d?c. 2013 12:38, "Arne Limburg" a ?crit : > Hi, > > > A simple solution to this topic would be to state in the spec, that, if an > extension replaces an InjectionTarget or Producer it MUST provide a custom > Implementation of an ObserverMethod for every private observer method of > that bean. > WDYT? Maybe we should discuss this in the meeting this evening? > > Regards, > Arne > > Am 12.12.13 16:23 schrieb "Mark Struberg" unter : > > > > >1. Producer / InjectionTarget might create instances which are wrapped in > >proxies. > > > >2. event observer methods are allowed to be private and thus are not in > >the proxies. > > > >3. extensions are allowed to 'decorate' InjectionTargets and Producers. > > > > > >This means that we need some unwrap method in the spec, right? > >Currently this does not York. > > > >LieGrue, > >strub > > > >_______________________________________________ > >cdi-dev mailing list > >cdi-dev at lists.jboss.org > >https://lists.jboss.org/mailman/listinfo/cdi-dev > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131216/a2d2925e/attachment-0001.html From issues at jboss.org Tue Dec 17 08:12:32 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:12:32 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-395: ------------------------------------- Labels: (was: cdi-1.1-mr investigate) > Public fields in extensions should not be allowed > ------------------------------------------------- > > Key: CDI-395 > URL: https://issues.jboss.org/browse/CDI-395 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans. > The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors. > See also WELD-1474 -- 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 From issues at jboss.org Tue Dec 17 08:14:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:14:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand resolved CDI-395. -------------------------------------- Resolution: Rejected Resolving this could bring more problems (with backward compatibility) that it could solve. Implementations are encouraged to give a warning when it's detected in the code. > Public fields in extensions should not be allowed > ------------------------------------------------- > > Key: CDI-395 > URL: https://issues.jboss.org/browse/CDI-395 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans. > The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors. > See also WELD-1474 -- 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 From issues at jboss.org Tue Dec 17 08:16:36 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:16:36 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-411: ------------------------------------- Labels: cdi-1.1-mr investigate (was: cdi-1.1-mr) > CDI conversation activation conflicts with the Servlet spec > ----------------------------------------------------------- > > Key: CDI-411 > URL: https://issues.jboss.org/browse/CDI-411 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Labels: cdi-1.1-mr, investigate > > The Servlet specification says: > {quote} > If the client hasn't set character encoding and the request data is encoded with a > different encoding than the default as described above, breakage can occur. To > remedy this situation, a new method setCharacterEncoding(String enc) has been > added to the ServletRequest interface. Developers can override the character > encoding supplied by the container by calling this method. It must be called prior to > parsing any post data or reading any input from the request. Calling this method > once data has been read will not affect the encoding. > {quote} > The CDI specification says: > {quote} > The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the > user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the > application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any > service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web > application and before the container calls any ServletRequestListener or AsyncListener in the web application. > {quote} > and > {quote} > The long-running conversation associated with a request may be propagated to any Servlet request via use of a request > parameter named cid containing the unique identifier of the conversation. > {quote} > This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding. > This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion. -- 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 From issues at jboss.org Tue Dec 17 08:22:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:22:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-370: ------------------------------------- Labels: (was: cdi-1.1-mr investigate) > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- 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 From issues at jboss.org Tue Dec 17 08:22:34 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:22:34 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-370: ---------------------------------------- Assignee: Antoine Sabot-Durand > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- 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 From issues at jboss.org Tue Dec 17 08:22:34 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:22:34 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932050#comment-12932050 ] Antoine Sabot-Durand commented on CDI-370: ------------------------------------------ It?s the responsibility of Websocket spec to implement these scopes. We should ensure they take the point before closing the ticket. > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- 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 From issues at jboss.org Tue Dec 17 08:38:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:38:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-411) CDI conversation activation conflicts with the Servlet spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-411: ------------------------------------- Labels: Investigate (was: ) > CDI conversation activation conflicts with the Servlet spec > ----------------------------------------------------------- > > Key: CDI-411 > URL: https://issues.jboss.org/browse/CDI-411 > Project: CDI Specification Issues > Issue Type: Bug > Components: Java EE integration > Affects Versions: 1.1.FD > Reporter: Jozef Hartinger > Labels: Investigate > Fix For: 1.2 > > > The Servlet specification says: > {quote} > If the client hasn't set character encoding and the request data is encoded with a > different encoding than the default as described above, breakage can occur. To > remedy this situation, a new method setCharacterEncoding(String enc) has been > added to the ServletRequest interface. Developers can override the character > encoding supplied by the container by calling this method. It must be called prior to > parsing any post data or reading any input from the request. Calling this method > once data has been read will not affect the encoding. > {quote} > The CDI specification says: > {quote} > The container provides a filter with the name "CDI Conversation Filter", which may be mapped in web.xml, allowing the > user alter when the conversation is associated with the servlet request. If this filter is not mapped in any web.xml in the > application, the conversation associated with a Servlet request is determined at the beginning of the request before calling any > service() method of any servlet in the web application, calling the doFilter() method of any servlet filter in the web > application and before the container calls any ServletRequestListener or AsyncListener in the web application. > {quote} > and > {quote} > The long-running conversation associated with a request may be propagated to any Servlet request via use of a request > parameter named cid containing the unique identifier of the conversation. > {quote} > This implies that in the default setup (CDI Conversation Filter not mapped), a CDI implementation is required to determine the conversation at the beginning of the request. That means that it has to read the "cid" parameter before any listener/filter/servlet is invoked. Reading the "cid" parameter causes the request body to be read. Therefore, if a listener/filter/servlet attempts to set the request character encoding using the aforementioned setCharacterEncoding(String enc) method, this never has any effect because a CDI implementation has already read the request body using the default encoding. > This can be worked around by mapping the CDI Conversation Filter and adding a custom encoding-setting filter before it. However, in the default configuration this issue often causes confusion. -- 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 From issues at jboss.org Tue Dec 17 08:44:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:44:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-408: ------------------------------------- Fix Version/s: 1.2 > bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans > --------------------------------------------------------------------------- > > Key: CDI-408 > URL: https://issues.jboss.org/browse/CDI-408 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Beans > Reporter: Jens Schumann > Fix For: 1.2 > > > Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly. > However there are two impacts: > 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere. > 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere. > I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier. > If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD. > -- > [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;) > > Btw: Which JIRA version is CDI 1.1 Final? -- 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 From issues at jboss.org Tue Dec 17 08:44:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:44:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-388) Session bean specialization example is not valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-388: ------------------------------------- Fix Version/s: 1.2 > Session bean specialization example is not valid > ------------------------------------------------ > > Key: CDI-388 > URL: https://issues.jboss.org/browse/CDI-388 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Martin Kouba > Fix For: 1.2 > > > {code} > @Stateless > public class LoginActionBean implements LoginAction { ... } > @Stateless @Mock @Specializes > public class MockLoginActionBean extends LoginActionBean { ... } > {code} > {{LoginAction}} is a local interface (whether it's annotated with {{@Local}} or not) therefore the bean types of {{LoginActionBean}} are {{LoginAction}}, {{Object}}. On the other hand {{MockLoginActionBean}} does not have a local interface (client views exposed by a particular session bean are not inherited by a subclass; see also the EJB spec 4.9.2.1 Session Bean Superclasses). Therefore the bean types of {{MockLoginActionBean}} are {{MockLoginActionBean}}, {{LoginActionBean}} and {{Object}} (3.2.2 Bean types of a session bean: "the unrestricted set of bean types contains the bean class and all superclasses"). > The spec also states (4.3.1 Direct and indirect specialization): > {quote} > Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error. > {quote} > So I believe the aforementioned example should result in a definition exception. To make it valid the {{MockLoginActionBean}} should also implement {{LoginAction}}. -- 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 From issues at jboss.org Tue Dec 17 08:44:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 17 Dec 2013 08:44:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-376: ------------------------------------- Fix Version/s: 1.2 > BeanManager#getProducerFactory return type differs between API and spec > ----------------------------------------------------------------------- > > Key: CDI-376 > URL: https://issues.jboss.org/browse/CDI-376 > Project: CDI Specification Issues > Issue Type: Bug > Components: Javadoc and API > Affects Versions: 1.1.PFD > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.2 > > > return type differs between API and spec wording for both BeanManager#getProducerFactory methods. > 1st is API git, 2nd is spec version: > public ProducerFactory getProducerFactory(AnnotatedMethod method, Bean declaringBean); > public ProducerFactory getProducerFactory(AnnotatedMethod method, Bean declaringBean); > They differ in the return type: > ProducerFactory vs > ProducerFactory -- 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 From antoine at sabot-durand.net Tue Dec 17 09:21:43 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Dec 2013 15:21:43 +0100 Subject: [cdi-dev] Maintenance Release preparation final Message-ID: <637BB80A-BBB2-436D-B453-94CE031EBA82@sabot-durand.net> Hi all, You?ll find yesterday?s meeting notes here : http://www.cdi-spec.org/news/2013/12/16/EG-meeting/ In Jira, I created the 1.2 Proposed version and affected all the tickets to it (you can access the list with this short link [1]). Please double check the content of the list as it should normally be closed by now. So a mistake could cost a lot when the MR will begin. There?s still a pending issue (even if I added it to the list) : CDI-411 CDI conversation activation conflicts with the Servlet spec [2]. Jozef has to investigate this point to see if we can safely keep it in the MR. MR will be officially launched on jan 6th week at this time this list will be locked. Thank you for the preparation work and your coming work on this MR. Antoine [1] http://s.shr.lc/1fBf5ix [2] https://issues.jboss.org/browse/CDI-411 From jens.schumann at openknowledge.de Tue Dec 17 09:39:29 2013 From: jens.schumann at openknowledge.de (Jens Schumann) Date: Tue, 17 Dec 2013 14:39:29 +0000 Subject: [cdi-dev] Maintenance Release preparation final In-Reply-To: <637BB80A-BBB2-436D-B453-94CE031EBA82@sabot-durand.net> Message-ID: Thanks for including CDI-408. Jens Am 17.12.13 15:21 schrieb "Antoine Sabot-Durand" unter : >Hi all, > > >You?ll find yesterday?s meeting notes here : >http://www.cdi-spec.org/news/2013/12/16/EG-meeting/ > > >In Jira, I created the 1.2 Proposed version and affected all the tickets >to it (you can access the list with this short link [1]). > >Please double check the content of the list as it should normally be >closed by now. So a mistake could cost a lot when the MR will begin. > >There?s still a pending issue (even if I added it to the list) : CDI-411 >CDI conversation activation conflicts with the Servlet spec [2]. Jozef >has to investigate this point to see if we can safely keep it in the MR. > >MR will be officially launched on jan 6th week at this time this list >will be locked. > >Thank you for the preparation work and your coming work on this MR. > > >Antoine > > >[1] http://s.shr.lc/1fBf5ix >[2] https://issues.jboss.org/browse/CDI-411 >_______________________________________________ >cdi-dev mailing list >cdi-dev at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev From issues at jboss.org Tue Dec 17 10:58:32 2013 From: issues at jboss.org (nathan dennis (JIRA)) Date: Tue, 17 Dec 2013 10:58:32 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932112#comment-12932112 ] nathan dennis commented on CDI-395: ----------------------------------- Antoine... "bring more problems" .... truer words were never spoken. > Public fields in extensions should not be allowed > ------------------------------------------------- > > Key: CDI-395 > URL: https://issues.jboss.org/browse/CDI-395 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans. > The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors. > See also WELD-1474 -- 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 From antoine at sabot-durand.net Tue Dec 17 17:31:32 2013 From: antoine at sabot-durand.net (Antoine Sabot-Durand) Date: Tue, 17 Dec 2013 23:31:32 +0100 Subject: [cdi-dev] Make 3 CDI 2.0 wishes Message-ID: <1C78FA01-F017-41AF-A2AA-B7F249290B41@sabot-durand.net> So the informal feedback has started : http://www.cdi-spec.org/news/2013/12/17/Make-3-CDI-2_0-wishes/ Thanks for spreading the news ;) Antoine From issues at jboss.org Wed Dec 18 03:33:33 2013 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 18 Dec 2013 03:33:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932276#comment-12932276 ] Jozef Hartinger commented on CDI-404: ------------------------------------- The option (2) does not deal with interceptors enabled using @Priority (not beans.xml) which still would not be found. > 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 > Fix For: 1.2 Proposed > > > [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-java-ee7 > 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 From ljnelson at gmail.com Wed Dec 18 17:00:24 2013 From: ljnelson at gmail.com (Laird Nelson) Date: Wed, 18 Dec 2013 14:00:24 -0800 Subject: [cdi-dev] Observer methods in Java EE Message-ID: Hello; the CDI specification says that an observer method is a non-abstract method of a managed bean class or session bean class (or of an > extension, as defined in [init_events]). > An observer method may be either static or non-static. *If the bean is a > session bean, the observer method must be either a business method of the > EJB *or a static method of the bean class. If I have a business interface that my SLSB implements that is intended to be an observer method, must @Observes be present on the interface's method's event parameter, the bean class' method's event parameter, or both? Thanks, Best, Laird -- http://about.me/lairdnelson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131218/9d7df9c8/attachment.html From jharting at redhat.com Thu Dec 19 04:04:35 2013 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 19 Dec 2013 10:04:35 +0100 Subject: [cdi-dev] Observer methods in Java EE In-Reply-To: References: Message-ID: <52B2B6A3.4030509@redhat.com> On the session bean class' method's event parameter. On 12/18/2013 11:00 PM, Laird Nelson wrote: > Hello; the CDI specification says that an observer method is a > > non-abstract method of a managed bean class or session bean > class (or of an extension, as defined in [init_events] > ). > An observer method may be either static or non-static. *If the > bean is a session bean, the observer method must be either a > business method of the EJB *or a static method of the bean class. > > > If I have a business interface that my SLSB implements that is > intended to be an observer method, must @Observes be present on the > interface's method's event parameter, the bean class' method's event > parameter, or both? > > Thanks, > Best, > Laird > > -- > http://about.me/lairdnelson > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20131219/a1525035/attachment-0001.html From issues at jboss.org Thu Dec 19 12:44:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 19 Dec 2013 12:44:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: Antoine Sabot-Durand created CDI-413: ---------------------------------------- Summary: Update outdated license Key: CDI-413 URL: https://issues.jboss.org/browse/CDI-413 Project: CDI Specification Issues Issue Type: Clarification Components: Javadoc and API Affects Versions: 1.1.FD Reporter: Antoine Sabot-Durand As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- 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 From issues at jboss.org Thu Dec 19 12:44:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 19 Dec 2013 12:44:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand reassigned CDI-413: ---------------------------------------- Assignee: Antoine Sabot-Durand > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- 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 From issues at jboss.org Thu Dec 19 12:46:33 2013 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 19 Dec 2013 12:46:33 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-413) Update outdated license In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-413: ------------------------------------- Fix Version/s: 1.2 Proposed > Update outdated license > ----------------------- > > Key: CDI-413 > URL: https://issues.jboss.org/browse/CDI-413 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.1.FD > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 1.2 Proposed > > > As mention on the [site|http://www.cdi-spec.org/download/] the license in Spec documentation is outdated. > As we release the spec in dual licensing, we should provide this [license|https://jcp.org/aboutJava/communityprocess/speclead/final-license.txt] for the JCP and the ASL2 for the website download. > Right now an old version of JCP license is included [here|https://github.com/cdi-spec/cdi/blob/master/spec/preface.asciidoc#11-evaluation-license] it mention Red Hat Middleware LLC instead of Red Hat, Inc. -- 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