[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-458:
-------------------------------------
Fix Version/s: 2.0-EDR2
(was: 2.0 (proposed))
> Give the possibility to deactivate an observer in ProcessObserverMethod
> -----------------------------------------------------------------------
>
> Key: CDI-458
> URL: https://issues.jboss.org/browse/CDI-458
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0-EDR2
>
>
> Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{(a)WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage.
> We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-522) Create add method setObserver() to ProcessObserverMethod SPI event
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-522?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-522:
-------------------------------------
Fix Version/s: 2.0-EDR2
(was: 2.0 (discussion))
> Create add method setObserver() to ProcessObserverMethod SPI event
> ------------------------------------------------------------------
>
> Key: CDI-522
> URL: https://issues.jboss.org/browse/CDI-522
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0-EDR2
>
>
> Right now {{ObserverMethod}} cannot be change in an extension. In the philosophy of {{ProcessAnnotatedType#setAnnotatedType}} or {{ProcessBeanAttributes#setBeanAttributes}} we could add a {{ProcessObserverMethod#setObserverMethod}} to change properties on an observer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-544) 10.2.3. The Event interface - provided executor cannot execute observers notification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-544?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-544:
-------------------------------------
Fix Version/s: 2.0-EDR2
> 10.2.3. The Event interface - provided executor cannot execute observers notification
> -------------------------------------------------------------------------------------
>
> Key: CDI-544
> URL: https://issues.jboss.org/browse/CDI-544
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 2.0-EDR1
> Reporter: Tomas Remes
> Fix For: 2.0-EDR2
>
>
> {quote}
> If the provided executor cannot execute observers notification, an IllegalArgumentException is thrown.
> {quote}
> What does it mean "cannot execute"? I am not really sure. Does it mean the observer throws an exception which should be wrapped in IAE?
> This would likely contradict {{10.5.1. Handling multiple exceptions thrown during an asynchronous event}}.
> Maybe this sentence could be omitted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-528) Minor inconsistency in Built-in qualifiers chapter
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-528?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-528:
-------------------------------------
Fix Version/s: 2.0-EDR2
(was: 2.0 (discussion))
> Minor inconsistency in Built-in qualifiers chapter
> --------------------------------------------------
>
> Key: CDI-528
> URL: https://issues.jboss.org/browse/CDI-528
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Tomas Remes
> Assignee: Antoine Sabot-Durand
> Priority: Minor
> Fix For: 2.0-EDR2
>
>
> 2.3.1. Built-in qualifier types states:
> {quote}
> If a bean does not explicitly declare a qualifier other than @Named , the bean has exactly one additional qualifier, of type @Default .
> {quote}
> This means that following bean has @Named, @Default, @Any qualifiers:
> {code}
> @Named
> public class Dog {}
> {code}
> but this one is not required to have @Default qualifier:
> {code}
> @Named
> @Any
> public class Dog {}
> {code}
> It doesn't make much sense IMHO.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-433) AdminEvent example has redundant qualifiers.
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-433?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-433:
-------------------------------------
Fix Version/s: 2.0-EDR2
> AdminEvent example has redundant qualifiers.
> --------------------------------------------
>
> Key: CDI-433
> URL: https://issues.jboss.org/browse/CDI-433
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: John Ament
> Priority: Minor
> Fix For: 2.0-EDR2
>
>
> In the CDI 1.2 spec, the following text appears:
> For example, this injected Event has specified type LoggedInEvent and specified qualifier @Admin:
> {{@Inject @Admin Event<LoggedInEvent> any;}}
> The select() method returns a child Event for a given specified type and additional specified qualifiers. If no specified type is given, the specified type is the same as the parent.
> For example, this child Event has required type AdminLoggedInEvent and additional specified qualifier {{@Admin}}:
> {noformat}
> Event<AdminLoggedInEvent> admin = any.select(
> AdminLoggedInEvent.class,
> new AdminQualifier() );
> {noformat}
> The problem is that the injection point any already is qualified @Admin, so the use is duplicate here. I believe the intention was that the injection point would read
> {{@Inject Event<LoggedInEvent> any;}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-522) Create add method setObserver() to ProcessObserverMethod SPI event
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-522?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-522 at 10/16/15 9:53 AM:
--------------------------------------------------------------------
PR Also solves CDI-458
was (Author: antoinesabot-durand):
Also solves CDI-458
> Create add method setObserver() to ProcessObserverMethod SPI event
> ------------------------------------------------------------------
>
> Key: CDI-522
> URL: https://issues.jboss.org/browse/CDI-522
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> Right now {{ObserverMethod}} cannot be change in an extension. In the philosophy of {{ProcessAnnotatedType#setAnnotatedType}} or {{ProcessBeanAttributes#setBeanAttributes}} we could add a {{ProcessObserverMethod#setObserverMethod}} to change properties on an observer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
arjan tijms commented on CDI-565:
---------------------------------
{quote}Do you mean java.util.Optional? It's final and not serializable. So you can't use it for passivating scopes.{quote}
You're right, I overlooked that. Very unfortunate for this situation. It's a long time away still, but I remember hearing that JDK 10 Optional may become a value type and value types are implicitly serializable.
{quote}Optional instances are not directly serializable putting something with optional dependencies in a serializable scope will probably cause either exceptions or headaches for CDI providers {quote}
It's sure not going to be pretty. A custom serializer may threat {{Optional}} fields special, e.g. just checking if they have a value and if so serializing that instead in a custom location. Upon restoring, if there's nothing saved in a custom location instantiate an empty Optional for the field in question, otherwise an Optional with the deserialized value.
But yeah, not pretty, and probably headache inducing indeed.
{quote}If the next CDI version solely depend on Java 8, one could introduce a new method like Instance#getOptional(){quote}
I don't know. It's a little help but doesn't give you the "at most 1" guaranty during deployment.
> Unsatisfied dependency should be null?
> --------------------------------------
>
> Key: CDI-565
> URL: https://issues.jboss.org/browse/CDI-565
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Reporter: Martin Andersson
>
> What if I am writing a component that call a collaborator only if that class exist during runtime? It is amazingly intuitive to write code like this:
> {code:java}
> class MyComponent
> {
> @Inject
> SomeCollaborator collaborator;
> public void someMethod() {
> // .. do something
> if (collaborator != null) {
> collaborator.callback();
> }
> }
> }
> {code}
> But the specification currently says in section "5.2.2. Unsatisfied and ambiguous dependencies" that this code should cause a "deployment problem". IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. They will inject {{null}}. WebLogic 12, I just learned, do crash during deployment.
> I believe it is unfortunate to have this null value logic for no apparent reason. It is inevitably so that the application code would crash anyways as soon as it tries to dereference a null reference. And you probably agree with me that there's a general guideline established in the developer community which say you shouldn't do null pointer checks all over the code because null pointers will crash exactly when and where the absence of a value really is a problem.
> The work around is to inject an {{Instance}} of my type and iterate through all of them, or do any other form of programmatic lookup. However, me personally, I've had this requirement far too many times now. It is often the case that a component I write has a "subframework" in place such that when I want to affect how the application performs, I can just add in new classes of a particular type and it is scoped up. Please don't even make the notion of a design smell out of your own lack of creativity, if you want to see a concrete example then of course I am more than happy to provide you with that. Just saying =)
> Something so intuitive and present in our every day coding life as a "null return value" should be present in the CDI specification too. I mean that is what the specification in essence is; one huge {{lookupInstanceOf(class)}}-method. Reading this method name, would you really expect it to crash, or return {{null}}?
> How about adding in a new annotation such that the injection point accept null values for unsatisfied dependencies, but if the injection point has an annotation {{@Required}}, then an unsatisfied dependency do crash for this injection point?
> You will probably say "let's do it the other way around so that we don't brake backward compatibility" by creating an {{@Optional}} annotation. Hey, if I am abusive to my wife and she divorce me. Should I continue to be abusive to my next wife so that I don't break backward compatibility? Our number one goal should be to define the most awesome specification and API possible - nothing else. If we keep leaving small piles of poo everywhere, then we will inevitably end up deep in shit.
> Thank you all for your hard work and time devoted to making all of our lives so much greater.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
Re: [cdi-dev] HttpSession failover from cdi 1.0 impl to cdi 1.2 impl
by Emily Jiang
Thank you Mark for the useful information! I forgot to cc cdi-dev:(. Yes, I
meant the session failover in a cluster containing multiple servers.
>From what you described, it seems the session failover can only occur among
the servers containing the same level of OWB. It is going to be very tricky
to get OWB 1.0/1.1 to failover to OWB 1.2 servers. The
serialization/deserialization is very different.
I believe in Weld, the Weld generated subclass is stored in the session.
Martin K, please correct me if I am wrong.
To move forward, can we work out a plan to support failover among different
CDI levels of the same kind in the future CDI releases as the current
failover support is a real limitation?
On Mon, Oct 12, 2015 at 9:29 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
> Deliberately private? Or did you simply forget to cc cdi-dev? Feel free to
> forward my answers to the list.
>
>
> > The EJB spec does not say anything about failover.
>
> Yes it says nothing about session failover or session replication. It is
> pretty vocal about remoting however. And this is technologically very close
> to clustering on many servers (Server talking to another Server).
> We probably have to explicitly distinguish a simple Session failover to a
> functional clustering aka scale up (mostly @Remote).
>
> Guess you are just refering to the former, right?
> For EJBs you can also only have @Stateful beans affected by session
> replication. And only if you store them in the Session (which gets
> replicated) of course. Or since EE6 if they are annotated with a CDI Scope
> annotation which ends up in the http session along the line
> (@SessionScoped, @ConversationScoped, various custom scopes, e.g.
> DeltaSpike @WindowScoped or @ViewAccessScoped). Or an @Dependent @Stateful
> which gets injected in a bean which ends up in the HttpSession.
> Any other EJBs which might get moved to another cluster node as a whole?
>
> Re OWB 1.1 and 1.2 compat. I fear it’s not easy. The ‚Contextual Instance‘
> stored in OWB-1.1 is _always_ without any interceptors or decorators. It
> doesn’t even contain any javassist dependencies. BUT if you inject any
> other NormalScoped bean into it _THEN_ you will have the ‚proxy shale‘ for
> those. And they of course contain javassist classes.
>
> In OWB-1.0 and 1.1 we also had a single ‚unified‘ proxy stack which
> contained NormalScoping, Interceptor logic and Decorator logic.
> In OWB-1.2 and up we did split this and now have 3 different proxies:
> NormalScoping proxies aka the ‚Contextual References‘. They are _not_ part
> of the Contextual Instance. Then we have Interceptor/Decoratpr Proxies
> (both in a single proxy class) and for abstract Decorators we also generate
> a simple proxy which just implements the missing methods. The later 2
> proxies are part of the ‚Contextual Instance‘ and thus get stored in the
> ContextualInstanceBag/SessionContext in the HttpSession.
> And of course you have the same impact of injected NormalScoped beans into
> a e.g. @SessionScoped bean as with OWB-1.1.
>
>
> I guess that wou will get hit with similar constellations in Weld as well.
>
>
> LieGrue,
> strub
>
>
>
>
> > Am 11.10.2015 um 22:28 schrieb Emily Jiang <emijiang6(a)googlemail.com>:
> >
> > The EJB spec does not say anything about failover. Some EJB
> implementations can support failover between different server levels. I am
> talking about failover among the same kind. I don't believe OWB can support
> failover between cdi 1.0 and cdi 1.2, neither does Weld can do.
> >
> > On Fri, Oct 9, 2015 at 12:53 PM, Mark Struberg <struberg(a)yahoo.de>
> wrote:
> > Wonder the same. I’m 100% sure that it is NOT portable for NIV. Wheras
> for EJB2 style EJBs it _might_ working due to RMI/IIOP (Though don’t
> remember whether this was only specified for remoting or also for
> clustering. Nor do I remember if the spec said anything about clustering at
> all).
> >
> > I guess there often is ‚additional‘ wrapper stuff handed over in
> addition to the normal beans for EJB3 style EJBs. I know for sure that we
> do exactly that in OpenEJB. We have additional wrappers e.g. for
> transported Exceptions when doing remoting. We hand over the ’string
> representation’ and the original Exception stack data separately. In case
> we cannot de-serialize the Exception on the other side. Think about sending
> some OptimisticLockException (or even some internal Hibernate Exception)
> over to an EJB client which doesn’t have any Hibernate jars and not even
> the jaa-spec jar on it’s classpath… Similar additional information might be
> stored in any EJB proxy. Or think about Extended Persistence Contexts. How
> should that ever work to be serialized between e.g. WildFly and Glassfish?
> How would you replicate over some Hibernate Exception if the other node is
> running Glassfish with EclipseLink? :)
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.10.2015 um 12:54 schrieb Martin Kouba <mkouba(a)redhat.com>:
> > >
> > > I wonder whether this behavior is defined somewhere, i.e. if all EJB
> > > implementations must support "failover" between minor versions (e.g.
> EJB
> > > 3.0 and 3.2), in other words the passivation mechanism may not change.
> > > This would mean that an EJB app might be deployed to a "cluster" of
> > > mixed Java EE 6 and Java EE 7 app servers - seems to me like an
> > > extremely risky experiment.
> > >
> > > Martin
> > >
> > > Dne 9.10.2015 v 11:42 Emily Jiang napsal(a):
> > >> I am investigating the HttpSession failover for SessionScoped or
> > >> ConversationScoped beans. I think it is not easy to failover from the
> > >> CDI 1.0 impl to CDI1.2 impl, as the bean proxies instead of the raw
> bean
> > >> was serialised and the proxies are different between cdi 1.0 and cdi
> > >> 1.2. Has anyone have any thoughts on this? If not possible, this is a
> > >> big limitation for CDI as EJB container has no such limitation.
> > >>
> > >> --
> > >> Thanks
> > >> Emily
> > >> =================
> > >> Emily Jiang
> > >> ejiang(a)apache.org <mailto:ejiang@apache.org>
> > >>
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>
> > >> Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> > >>
> > >
> > > --
> > > Martin Kouba
> > > Software Engineer
> > > Red Hat, Czech Republic
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses
> the code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> >
> >
> > --
> > Thanks
> > Emily
> > =================
> > Emily Jiang
> > ejiang(a)apache.org
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang(a)apache.org
8 years, 6 months
[JBoss JIRA] (CDI-565) Unsatisfied dependency should be null?
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-565?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-565:
------------------------------------
As far as I remember there was already a discussion around introducing optional dependencies via {{java.util.Optional}}. The problem is {{java.util.Optional}} was not meant for long term state holding, but rather for API design. Optional instances are not directly serializable putting something with optional dependencies in a serializable scope will probably cause either exceptions or headaches for CDI providers ;)
If the next CDI version solely depend on Java 8, one could introduce a new method like {{Instance#getOptional()}}, which likely still throw an exception if multiple instances are available.
> Unsatisfied dependency should be null?
> --------------------------------------
>
> Key: CDI-565
> URL: https://issues.jboss.org/browse/CDI-565
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Reporter: Martin Andersson
>
> What if I am writing a component that call a collaborator only if that class exist during runtime? It is amazingly intuitive to write code like this:
> {code:java}
> class MyComponent
> {
> @Inject
> SomeCollaborator collaborator;
> public void someMethod() {
> // .. do something
> if (collaborator != null) {
> collaborator.callback();
> }
> }
> }
> {code}
> But the specification currently says in section "5.2.2. Unsatisfied and ambiguous dependencies" that this code should cause a "deployment problem". IIRC, GlassFish 4.1 and WildFly 9 doesn't actually crash during deployment. They will inject {{null}}. WebLogic 12, I just learned, do crash during deployment.
> I believe it is unfortunate to have this null value logic for no apparent reason. It is inevitably so that the application code would crash anyways as soon as it tries to dereference a null reference. And you probably agree with me that there's a general guideline established in the developer community which say you shouldn't do null pointer checks all over the code because null pointers will crash exactly when and where the absence of a value really is a problem.
> The work around is to inject an {{Instance}} of my type and iterate through all of them, or do any other form of programmatic lookup. However, me personally, I've had this requirement far too many times now. It is often the case that a component I write has a "subframework" in place such that when I want to affect how the application performs, I can just add in new classes of a particular type and it is scoped up. Please don't even make the notion of a design smell out of your own lack of creativity, if you want to see a concrete example then of course I am more than happy to provide you with that. Just saying =)
> Something so intuitive and present in our every day coding life as a "null return value" should be present in the CDI specification too. I mean that is what the specification in essence is; one huge {{lookupInstanceOf(class)}}-method. Reading this method name, would you really expect it to crash, or return {{null}}?
> How about adding in a new annotation such that the injection point accept null values for unsatisfied dependencies, but if the injection point has an annotation {{@Required}}, then an unsatisfied dependency do crash for this injection point?
> You will probably say "let's do it the other way around so that we don't brake backward compatibility" by creating an {{@Optional}} annotation. Hey, if I am abusive to my wife and she divorce me. Should I continue to be abusive to my next wife so that I don't break backward compatibility? Our number one goal should be to define the most awesome specification and API possible - nothing else. If we keep leaving small piles of poo everywhere, then we will inevitably end up deep in shit.
> Thank you all for your hard work and time devoted to making all of our lives so much greater.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months