April 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-494) Events - clarify that a type variable that resolves to a wildcard is not resolvable

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-494?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-494: ----------------------------- Summary: Events - clarify that a type variable that resolves to a wildcard is not resolvable (was: Clarify that a type variable that resolves to a wildcard is not resolvable) > Events - clarify that a type variable that resolves to a wildcard is not resolvable > ----------------------------------------------------------------------------------- > > Key: CDI-494 > URL: https://issues.jboss.org/browse/CDI-494 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Fix For: 2.0 (discussion) > > > This is implicit but I've seen people confused about this several times. See e.g. https://issues.jboss.org/browse/WELD-1799 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec

by Vsevolod Golovanov (JIRA)

[ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.sy... ] Vsevolod Golovanov commented on CDI-525: ---------------------------------------- Please keep it consistent. JSF, JPA and everyone else use JavaBeans rules - CDI should too. Otherwise, one EL expression in JSF could have its parts resolved by the different rules for no good reason: {code} #{cDI.JSF} {code} > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-597) Make Principal unwrappable

by Arjan t (JIRA)

[ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.sy... ] Arjan t commented on CDI-597: ----------------------------- {quote}it is in JAAS {quote} But not all application servers use JAAS, and JAAS is not a mandatory part of Java EE or Servlet. Unless... unless you're referring to the JASPIC LoginModule bridge profile ;) But then the {{CallerPrincipalCallback}} is the primary artifact to deal with, and the SAM just gets the {{Principal}} from the {{LoginModule}}. {quote} +100 to move it to security spec. That said it means principal injection moves too since today it is in CDI (shouldn't have been I agree) {quote} Okay, would be great if we can make this happen. > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-597) Make Principal unwrappable

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-597: ---------------------------------------- [~arjant] it is in JAAS so should be supported somehow (but LoginContext is not mandatory). +100 to move it to security spec. That said it means principal injection moves too since today it is in CDI (shouldn't have been I agree) > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-597) Make Principal unwrappable

by Arjan t (JIRA)

[ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.sy... ] Arjan t commented on CDI-597: ----------------------------- {quote} Here CDI is blocking cause of proxies, user can't really produce the Principal cause LoginModule are often reused{quote} Just wanted to mention that not every Java EE server makes use of {{LoginModule}}, if you mean {{javax.security.auth.spi.LoginModule}} ;) The responsibility of providing the {{Principal}} instance should perhaps be with the Security API and not with CDI itself. Antoine already asked for Servlet to take responsibility of providing Beans for the Servlet artifacts. I do acknowledge there may be some backward compatibility issues here. > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-597) Make Principal unwrappable

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-597: ---------------------------------------- [~mkouba] happy to do it but not tempted to parse method bodies with asm to do so handling java code dependencies etc and that's actually the only way to do it from the container point of view. Point is: very often you rely on a particular principal in the login module and you use it in your app in a dependent manner to propagate some fields (mail, display name...). The LoginModule could even instantiate different kind of principal in its implementation and you could use a "switch" like logic in your code if needed but for that or simply the basic need of accessing additional fields you need to access the actual principal. Here CDI is blocking cause of proxies, user can't really produce the Principal cause LoginModule are often reused (ie code is not under your responsability). > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-597) Make Principal unwrappable

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-597?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-597: ---------------------------------- Hi Romain, so the client code would depend on a specific Principal impl, right? If so, then it would make sense to provide a bean for this type (on the Java EE container level - e.g. in the TomEE integration code) so that a client could inject it directly (I don't see a reason for portability here). > Make Principal unwrappable > -------------------------- > > Key: CDI-597 > URL: https://issues.jboss.org/browse/CDI-597 > Project: CDI Specification Issues > Issue Type: Epic > Reporter: Romain Manni-Bucau > > CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. > Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to get it injected directly as Principal today. > This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-597) Make Principal unwrappable

by Romain Manni-Bucau (JIRA)

Romain Manni-Bucau created CDI-597: -------------------------------------- Summary: Make Principal unwrappable Key: CDI-597 URL: https://issues.jboss.org/browse/CDI-597 Project: CDI Specification Issues Issue Type: Epic Reporter: Romain Manni-Bucau CDI allows to get injected a Principal but often you need to access the actual Principal instance when you need more than a name. Since the injection is a proxy (otherwise it would be broken in most of scoped wrapper instances cases) we would need a CDI solution to unwrap this instance. Solution I see without creating a new kind of API but just something specific to this case: CDIPrincipal extends Principal { <T> T unwrap(Class<T> t) } and allow to get it injected directly as Principal today. This issue can be linked to CDI-10 but here it is safe to add unwrap() where on CDI-10 it is not (too general). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-596: ------------------------------------------ I think throwing exception is the best approach > ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-596 > URL: https://issues.jboss.org/browse/CDI-596 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Right now, it's not clear what happens if: > * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) > * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} > We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. > This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-596: ----------------------------- Summary: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification (was: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used) > ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used within observer notification > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-596 > URL: https://issues.jboss.org/browse/CDI-596 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > Right now, it's not clear what happens if: > * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed) > * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}} > We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone. > This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev April 2016