January 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-161) Java DSL to define beans to create and deploy

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-161?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-161: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Java DSL to define beans to create and deploy > --------------------------------------------- > > Key: CDI-161 > URL: https://issues.jboss.org/browse/CDI-161 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > This would be especially useful in Java SE mode -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-157) Enabling/Disabling Extensions

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-157?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-157: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Enabling/Disabling Extensions > ----------------------------- > > Key: CDI-157 > URL: https://issues.jboss.org/browse/CDI-157 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 2.0 (discussion) > > > Typically an extension class is packaged in a jar, along with a META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. However, this means that an application, or another extension, has no way of disabling extensions. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-160) Split specification into "core" and "Java EE integration"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-160: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: TBD) > Split specification into "core" and "Java EE integration" > --------------------------------------------------------- > > Key: CDI-160 > URL: https://issues.jboss.org/browse/CDI-160 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Antoine Sabot-Durand > Priority: Critical > Fix For: 2.0 (proposed) > > > In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-160) Split specification into "core" and "Java EE integration"

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-160?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-160: ---------------------------------------- Assignee: Antoine Sabot-Durand (was: Pete Muir) > Split specification into "core" and "Java EE integration" > --------------------------------------------------------- > > Key: CDI-160 > URL: https://issues.jboss.org/browse/CDI-160 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Antoine Sabot-Durand > Priority: Critical > Fix For: 2.0 (proposed) > > > In order to better support implementations of CDI such as Weld SE, Errai, and OpenWebBeans which are currently not certifiable by JSR-299 (as they don't implement any of the Java EE integrations) we should split the spec into core and Java EE integrations, and offer two modes within the TCK as well. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-137) Changing ProcessManagedBean getBean Method Signature

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-137?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-137: ------------------------------------- Description: Currently ProcessSessionBean class signature is {code:java} public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} {code} Therefore, observers work as Example: {code:java} @Stateless public class Elephant{} public void observe(@Observes ProcessBean<Elephant>) // --> Not allowed public void observe(@Observes ProcessSessionBean<Elephant>) // --> Allowed {code} Pete said that main reason of using ProcessManagedBean<Object> is that {quote} {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is. {quote} Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class. Therefore, it is more convenient to change "ProcessManagedBean getBean" method declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean. And change the {{ProcessSessionBean}} signature as {code:java} public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} {code} Also See https://issues.jboss.org/browse/CDITCK-215 was: Currently ProcessSessionBean class signature is public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} Therefore, observers work as Example: {code:java} @Stateless public class Elephant{} public void observe(ProcessBean<Elephant>) // --> Not allowed public void observe(ProcessSessionBean<Elephant>) // --> Allowed {code} Pete said that main reason of using ProcessManagedBean<Object> is that {quote} {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is. {quote} Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class. Therefore, it is more convenient to change "ProcessManagedBean getBean" method declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean. And change the {{ProcessSessionBean}} signature as {code:java} public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} {code} Also See https://issues.jboss.org/browse/CDITCK-215 > Changing ProcessManagedBean getBean Method Signature > ---------------------------------------------------- > > Key: CDI-137 > URL: https://issues.jboss.org/browse/CDI-137 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Gurkan Erdogdu > Fix For: TBD > > > Currently ProcessSessionBean class signature is > {code:java} > public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} > {code} > Therefore, observers work as > Example: > {code:java} > @Stateless > public class Elephant{} > public void observe(@Observes ProcessBean<Elephant>) // --> Not allowed > public void observe(@Observes ProcessSessionBean<Elephant>) // --> Allowed > {code} > Pete said that main reason of using ProcessManagedBean<Object> is that > {quote} > {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is. > {quote} > Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. > Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class. > Therefore, it is more convenient to change "ProcessManagedBean getBean" method declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean. > And change the {{ProcessSessionBean}} signature as > {code:java} > public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} > {code} > Also See https://issues.jboss.org/browse/CDITCK-215 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-137) Changing ProcessManagedBean getBean Method Signature

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-137?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-137: ------------------------------------- Description: Currently ProcessSessionBean class signature is public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} Therefore, observers work as Example: {code:java} @Stateless public class Elephant{} public void observe(ProcessBean<Elephant>) // --> Not allowed public void observe(ProcessSessionBean<Elephant>) // --> Allowed {code} Pete said that main reason of using ProcessManagedBean<Object> is that {quote} {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is. {quote} Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class. Therefore, it is more convenient to change "ProcessManagedBean getBean" method declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean. And change the {{ProcessSessionBean}} signature as {code:java} public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} {code} Also See https://issues.jboss.org/browse/CDITCK-215 was: Currently ProcessSessionBean class signature is public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} Therefore, observers work as Example: @Stateless public class Elephant{} public void observe(ProcessBean<Elephant>) --> Not allowed public void observe(ProcessSessionBean<Elephant>) --> Allowed Pete said that main reason of using ProcessManagedBean<Object> is that "ProcessBean<X> offers a method getBean() which returns Bean<X>. Bean<X> has a method of type create() which returns an X. If we were to have ProcessSessionBean<X> extend ProcessManagedBean<X> then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is." Main reason of using the ProcessSessionBean event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. Moreover, other methods in the interface hierarchy of "ProcessSessionBean" gets <X> into the account, for example AnnotatedType<X> getAnnotatedBeanClass() Returns the AnnotatedType representing the bean class. Therefore, it is more convenient to change "ProcessManagedBean getBean" method decleration as public <T> Bean<T> getBean(); where T is the local/local view interface of the session bean. And change the ProcessSessionBean signature as public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} Also See https://issues.jboss.org/browse/CDITCK-215 > Changing ProcessManagedBean getBean Method Signature > ---------------------------------------------------- > > Key: CDI-137 > URL: https://issues.jboss.org/browse/CDI-137 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Gurkan Erdogdu > Fix For: TBD > > > Currently ProcessSessionBean class signature is > public class ProcessSessionBean<T> extends ProcessManagedBean<Object>{} > Therefore, observers work as > Example: > {code:java} > @Stateless > public class Elephant{} > public void observe(ProcessBean<Elephant>) // --> Not allowed > public void observe(ProcessSessionBean<Elephant>) // --> Allowed > {code} > Pete said that main reason of using ProcessManagedBean<Object> is that > {quote} > {{ProcessBean<X>}} offers a method {{getBean()}} which returns {{Bean<X>}}. {{Bean<X>}} has a method {{create()}} which returns an {{X}}. If we were to have {{ProcessSessionBean<X> extends ProcessManagedBean<X>}} then this would imply that you can create something of type, which in the case of a session bean is the bean class (which can't be created for EJBs with local or remote business interfaces). So ProcessSessionBean is correct as is. > {quote} > Main reason of using the {{ProcessSessionBean}} event is to observe "Session Bean Class" registration, not the observe for the session bean local interface/s. > Moreover, other methods in the interface hierarchy of {{ProcessSessionBean}} gets {{<X>}} into the account, for example {{AnnotatedType<X> getAnnotatedBeanClass()}} returns the AnnotatedType representing the bean class. > Therefore, it is more convenient to change "ProcessManagedBean getBean" method declaration as {{public <T> Bean<T> getBean();}} where {{T}} is the local/local view interface of the session bean. > And change the {{ProcessSessionBean}} signature as > {code:java} > public class ProcessSessionBean<X> extends ProcessManagedBean<X>{} > {code} > Also See https://issues.jboss.org/browse/CDITCK-215 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-128) Ability to access CDI enhanced metadata from the InvocationContext.getMethod()

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-128?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-128: ------------------------------------------ Could also be useful for metadata added from an extension. > Ability to access CDI enhanced metadata from the InvocationContext.getMethod() > ------------------------------------------------------------------------------ > > Key: CDI-128 > URL: https://issues.jboss.org/browse/CDI-128 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors > Affects Versions: 1.0 > Reporter: Richard Hightower > Fix For: 2.0 (discussion) > > > The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI). > For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class). > I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-128) Ability to access CDI enhanced metadata from the InvocationContext.getMethod()

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-128?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-128: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Ability to access CDI enhanced metadata from the InvocationContext.getMethod() > ------------------------------------------------------------------------------ > > Key: CDI-128 > URL: https://issues.jboss.org/browse/CDI-128 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Interceptors > Affects Versions: 1.0 > Reporter: Richard Hightower > Fix For: 2.0 (discussion) > > > The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI). > For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class). > I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-110) Provide support for binding an invocation handler to an interface or abstract class

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-110: ------------------------------------------ Looks similar to Deltaspike Partial Bean > Provide support for binding an invocation handler to an interface or abstract class > ----------------------------------------------------------------------------------- > > Key: CDI-110 > URL: https://issues.jboss.org/browse/CDI-110 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Inheritance and Specialization > Affects Versions: 1.0 > Reporter: George Gastaldi > Labels: cdi > Fix For: 2.0 (discussion) > > > The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding. > Binding type: > {code:java} > @Target({ METHOD, TYPE }) > @Retention(RetentionPolicy.RUNTIME) > @ServiceHandlerBindingType > public @interface EchoService {} > {code} > Invocation handler: > {code:java} > @ServiceHandler > @EchoService > public class EchoServiceHandler { > @AroundInvoke > public Object invoke(InvocationContext ctx) { > return ctx.getMethod().getName().toString(); > } > } > {code} > Usage: > {code:java} > @EchoService > public interface HelloWorld { > String helloWorld(); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-110) Provide support for binding an invocation handler to an interface or abstract class

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-110?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-110: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: TBD) > Provide support for binding an invocation handler to an interface or abstract class > ----------------------------------------------------------------------------------- > > Key: CDI-110 > URL: https://issues.jboss.org/browse/CDI-110 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Inheritance and Specialization > Affects Versions: 1.0 > Reporter: George Gastaldi > Labels: cdi > Fix For: 2.0 (discussion) > > > The purpose of this feature is to allow interfaces and abstract classes to be automatically implemented by an invocation handler to which all abstract method invocations are delegated. The invocation handler would get "bound" to the type using the same strategy as is used for interceptor binding. > Binding type: > {code:java} > @Target({ METHOD, TYPE }) > @Retention(RetentionPolicy.RUNTIME) > @ServiceHandlerBindingType > public @interface EchoService {} > {code} > Invocation handler: > {code:java} > @ServiceHandler > @EchoService > public class EchoServiceHandler { > @AroundInvoke > public Object invoke(InvocationContext ctx) { > return ctx.getMethod().getName().toString(); > } > } > {code} > Usage: > {code:java} > @EchoService > public interface HelloWorld { > String helloWorld(); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2015