[JBoss JIRA] (CDI-227) API is underspecified for corner cases
by Guy Veraghtert (JIRA)
Guy Veraghtert created CDI-227:
----------------------------------
Summary: API is underspecified for corner cases
Key: CDI-227
URL: https://issues.jboss.org/browse/CDI-227
Project: CDI Specification Issues
Issue Type: Bug
Components: Java SE Integration, Packaging and Deployment
Affects Versions: 1.1.EDR1, 1.0
Reporter: Guy Veraghtert
The CDI api's are mainly used to develop (portable) extensions. In practice, we see that those so called _portable_ extensions are not portable at all due to underspecified api's.
For example BeanManager.resolve(set) doesn't specify how to deal with an empty set or null. This leads to incompatible implementations and unportable extensions. See for example https://issues.apache.org/jira/browse/OWB-625 (Unfortunately Websphere 8 includes openwebbeans < 1.1.3, making Seam3 not out-of-the-box usable). Currently most implementations (weld, owb and candi) return null for an empty set. OWB returns null when null is passed, others will throw an exception.
To create extensions that are truly portable, we should specify all corner cases (what about BeanManager.getBean((String)null)?). In theory developers should not depend on undefined behavior, but in practice we all do (Seam3 is full of examples).
Ideally, we should go over the complete public API and specify what should happen with these corner cases: null-values, empty collections, ...
Just adding that an IllegalArgumentException should be thrown in case of null for example would suffice.
These things are very easy to incorporate in the TCK and would contribute a lot to the success of portable extensions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
Problem with EJB´s, Stereotype with an @Alternative and Specialization
by Daniel Sachse
Hey guys,
I ran into a problem today and I am unsure if the behavior I encountered is the way it should be.
My Environment:
JBoss 7.1.1.Final with Weld 1.1.5
My Scenario:
------------------------------------------------------------------------------------------------------
public abstract class AbstractClass implements DemoInterface {…}
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class Real extends AbstractClass {…}
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Alternative
@Specializes
public class Mock extends Real {…}
------------------------------------------------------------------------------------------------------
If I register class Mock as an @Alternative in beans.xml, everything works fine.
<alternatives>
<class>at.w0mb.example.Mock</class>
</alternatives>
As soon as I try:
------------------------------------------------------------------------------------------------------
@Alternative
@Stereotype
@Retention(RUNTIME)
@Target(TYPE)
public @interface Mock {}
@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Mock
//@Alternative
@Specializes
public class Mock extends Real {…}
------------------------------------------------------------------------------------------------------
If I now register the @Stereotype Mock as an @Alternative in beans.xml, the application won´t deploy.
<alternatives>
<stereotype>at.w0mb.example.stereotype.Mock</stereotype>
</alternatives>
The thrown error message is:
WELD-001408 Unsatisfied dependencies for type [DemoInterface] …….
Do you guys think that this is normal? Is it a specification Issue? Or Weld?
Regards,
Daniel
12 years, 12 months
[JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer
by Christian Beikov (JIRA)
[ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.sys... ]
Christian Beikov commented on CDI-20:
-------------------------------------
I am not sure whether deltaspike already ported all of the ideas of seam catch, but I only know deltaspike so I can't speak of catch. Anyway, deltaspike did a good job with the exception event chaining which should IMO also be available for CDI events. Especially for this problem something like an event context where one could set a flag, that the current event is handled or so, would be nice.
> @Observes(propagate = false) - stop event propagation after being handled by an observer
> ----------------------------------------------------------------------------------------
>
> Key: CDI-20
> URL: https://issues.jboss.org/browse/CDI-20
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.0
> Environment: any
> Reporter: Walter White
> Fix For: TBD
>
>
> I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation.
--
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
12 years, 12 months
[JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class
by Daniel Sachse (JIRA)
[ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.sys... ]
Daniel Sachse commented on CDI-21:
----------------------------------
You are absolutely right! Should have thought twice ;)
> Support PostConstruct callbacks in Extension class
> --------------------------------------------------
>
> Key: CDI-21
> URL: https://issues.jboss.org/browse/CDI-21
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Sivakumar Thyagarajan
> Priority: Minor
> Fix For: TBD
>
>
> It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification.
> Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue.
--
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
13 years
[JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.sys... ]
Jozef Hartinger commented on CDI-21:
------------------------------------
You can observe BeforeBeanDiscovery and initialize the extension in the observer method.
> Support PostConstruct callbacks in Extension class
> --------------------------------------------------
>
> Key: CDI-21
> URL: https://issues.jboss.org/browse/CDI-21
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Sivakumar Thyagarajan
> Priority: Minor
> Fix For: TBD
>
>
> It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification.
> Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue.
--
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
13 years
[JBoss JIRA] (CDI-21) Support PostConstruct callbacks in Extension class
by Daniel Sachse (JIRA)
[ https://issues.jboss.org/browse/CDI-21?page=com.atlassian.jira.plugin.sys... ]
Daniel Sachse commented on CDI-21:
----------------------------------
I would also favor this. Have a use case where I observe "ProcessAnnotatedType<T>" events and I don´t want to reinit a variable each time.
> Support PostConstruct callbacks in Extension class
> --------------------------------------------------
>
> Key: CDI-21
> URL: https://issues.jboss.org/browse/CDI-21
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Sivakumar Thyagarajan
> Priority: Minor
> Fix For: TBD
>
>
> It is sometimes useful to get to know after a portable extension class has been instantiated, so that the state of the Extension could be initialized [ie not establishing state in the constructor and having it called twice when the Extension is proxied]. Though the 1.0 specification does not require this, it would be useful to support @PostConstruct callback on Extension class in the next version of the specification.
> Please see https://jira.jboss.org/browse/WELD-713 for additional information on this issue.
--
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
13 years
