[JBoss JIRA] (CDI-317) review PassivationCapable interface
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-317:
-----------------------------------
Read 6.6.1
{quote}
A producer method is passivation capable if and only if it never returns a value which is not passivation capable at runtime.
{quote}
plus
{quote}
A custom implementation of Bean is passivation capable if it implements the interface PassivationCapable.
{quote}
So, how does a Bean tells the container: "most of my implementations are passivation capable, but sadly some are not? There is no such thing like dynamically adding an interface. At least not with compiled classes.
You would need to add 2 Bean classes for the same logic. In OWB we allow getId() to return null which indicates that this very bean is not passivation capable.
> review PassivationCapable interface
> -----------------------------------
>
> Key: CDI-317
> URL: https://issues.jboss.org/browse/CDI-317
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface.
> But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not.
> Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation.
--
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
11 years, 3 months
[JBoss JIRA] (CDI-282) Vetoing types - clarify consequences
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-282?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-282:
-----------------------------------
package annotations are broken by design anyway. Didn't we drop that already?
> Vetoing types - clarify consequences
> ------------------------------------
>
> Key: CDI-282
> URL: https://issues.jboss.org/browse/CDI-282
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The spec currently says {{@Vetoed}} type is *prevented from being considered by CDI* and {{ProcessAnnotatedType.veto()}} forces the container to ignore the type. This is quite obvious for classes and interfaces. However not so clear when vetoing annotations (e.g. qualifier). I think ignoring means not being considered as qualifier (thus affects resolution). Other (rather theoretical) example is vetoing non-contextual instances - should it prevent performing dependency injection?
--
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
11 years, 3 months
[JBoss JIRA] (CDI-282) Vetoing types - clarify consequences
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-282?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-282:
----------------------------------
Well, it makes sense not to support it. This issue was raised with PAT for annotations in mind, which is not relevant any more. But the use case I was originally thinking of was @Vetoed used on package.
> Vetoing types - clarify consequences
> ------------------------------------
>
> Key: CDI-282
> URL: https://issues.jboss.org/browse/CDI-282
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The spec currently says {{@Vetoed}} type is *prevented from being considered by CDI* and {{ProcessAnnotatedType.veto()}} forces the container to ignore the type. This is quite obvious for classes and interfaces. However not so clear when vetoing annotations (e.g. qualifier). I think ignoring means not being considered as qualifier (thus affects resolution). Other (rather theoretical) example is vetoing non-contextual instances - should it prevent performing dependency injection?
--
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
11 years, 3 months
[JBoss JIRA] (CDI-317) review PassivationCapable interface
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-317?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-317:
-------------------------------------
{quote}For e.g. a ProducerMethodBean it depends on the scope of the produced instance.{quote}
It does not. It works the other way around. If a bean has a passivating scope it has to be passivation capable. However, a bean may be passivation capable yet not have a passivating scope.
> review PassivationCapable interface
> -----------------------------------
>
> Key: CDI-317
> URL: https://issues.jboss.org/browse/CDI-317
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface.
> But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not.
> Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation.
--
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
11 years, 3 months
[JBoss JIRA] (CDI-317) review PassivationCapable interface
by Mark Struberg (JIRA)
Mark Struberg created CDI-317:
---------------------------------
Summary: review PassivationCapable interface
Key: CDI-317
URL: https://issues.jboss.org/browse/CDI-317
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Reporter: Mark Struberg
Currently the spec says that only _passivation capable Beans_ must implement the PassivationCapable interface.
But a Bean class could result in both passivation-capable and not-passivation-capable beans. For e.g. a ProducerMethodBean it depends on the scope of the produced instance. For implementing this properly you would need to always need 2 classes for each bean-type. And even worse - often you know only after the all the Bean-building that this very bean is passivation-capable or not.
Thus I suggest to extend the meaning of PassivationCapable#getId() to allow returning *null* if the very bean doesn't support passivation.
--
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
11 years, 3 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-271:
----------------------------------
Later on we should also change
{quote}
The getType() and getQualifiers() methods return the required type and required qualifiers of the injection point. If
the injection point represents a dynamically obtained instance, the getType() and getQualifiers() methods should
return the required type (as defined by Instance.select()), and required qualifiers of the injection point including
any additional required qualifiers (as defined by Instance.select()).{quote}
to
{quote}
The getType() and getQualifiers() methods return the required type and required qualifiers of the injection point. If
the injection point represents a dynamically obtained instance or event, the getType() and getQualifiers() methods should
return the required type (as defined by Instance.select() and Event.select()), and required qualifiers of the injection point including any additional required qualifiers (as defined by Instance.select() and Event.select()).{quote}
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Fix For: 1.1 (Proposed)
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg edited comment on CDI-271 at 1/13/13 5:59 AM:
-----------------------------------------------------------
Just saw, that the second part is already clarified :)
So we only have to add a bullet point to 5.5.7 like
{quote}An instance of InjectionPoint may represent:
...
- An Event obtained dynamically using Event.select(...).{quote}
and this issue can be closed.
was (Author: arnelim):
Just saw, that the second part is already clarified :)
So we only have to add a bullet point to 5.5.7 like
"An instance of InjectionPoint may represent:
...
- An Event obtained dynamically using Event.select(...)."
and this issue can be closed.
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Fix For: 1.1 (Proposed)
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg edited comment on CDI-271 at 1/13/13 5:57 AM:
-----------------------------------------------------------
Just saw, that the second part is already clarified :)
So we only have to add a bullet point to 5.5.7 like
"An instance of InjectionPoint may represent:
...
- An Event obtained dynamically using Event.select(...)."
and this issue can be closed.
was (Author: arnelim):
Just saw, that the second part is already clarified :)
So we only have to add a bullet point to 5.5.7 like
"An instance of InjectionPoint may represent:
...
- An Event obtained dynamically using Event.select(...)."
and this issue can be closed.
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Fix For: 1.1 (Proposed)
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-271:
----------------------------------
Just saw, that the second part is already clarified :)
So we only have to add a bullet point to 5.5.7 like
"An instance of InjectionPoint may represent:
...
- An Event obtained dynamically using Event.select(...)."
and this issue can be closed.
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Fix For: 1.1 (Proposed)
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-271:
----------------------------------
Just saw, that section 5.5.7 already is changed so that Instance.get() is an injection point.
For this issue it would suffice to add Event.fire() here and to clarify that for Instance.select(...).get() and Event.select(...).fire(...) the InjectionPoint.getType() returns the selected type and InjectionPoint.getQualifiers() contains the selected qualifiers. We don't have to touch the Annotated then.
WDYT?
Shall I write a proposal?
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Fix For: 1.1 (Proposed)
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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
11 years, 3 months