[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:
-----------------------------------
Martin, should we support @Vetoed on annotations at all? We don't fire ProcessAnnotatedType for them neither, isn't? It just sounds crazy to use a veto annotation on a CDI annotation. You could simply comment out the @Qualifier and get the same effect ;)
> 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, 11 months
self interception for CDI beans
by Mark Struberg
Hi!
For EJBs there is a 'self-interception' defined. E.g.
@Stateless
public class MyEjb {
public String someBusinessMehod() {
returns "Schneewittchen";
}
@AroundInvoke
public Object interceptMe(InvocationContext ic) throws Exception {
System.out.println("got intercepted");
return ic.proceed();
}
}
But should the same trick also work for CDI beans when replacing @Stateless with @SessionScoped ?
LieGrue,
strub
11 years, 11 months
clarification about interceptors in ejb-jar.xml
by Mark Struberg
The cdi spec defines that
"Interceptors declared using @Interceptors or in ejb-jar.xml are called before interceptors declared using interceptor
bindings"
does that mean that we need to apply interceptors defined in ejb-jar.xml to pure CDI beans as well?
LieGrue,
strub
11 years, 11 months
Order of the new system events
by Mark Struberg
Hi!
Arne and me have discussed the order of the new system events and came to a point where the order is not well defined yet.
After ProcessAnnotatedType we need to build up the Beans.
In this process the following events are involved
* ProcessInjectionTarget
* ProcessInjectionPoint
* ProcessBeanAttributes
* ProcessBean
Now the following underlying conditions needs to be met:
* InjectionPoint has a method #getBean()
* ProcessBean does only read information thus it will be the last in the chain.
The following questions are open:
* If ProcessInjectionPoint gets fired before ProcessInjectionTarget then we would fire it for InjectionPoints which probably later get removed. And it will not get fired for freshly added InjectionPoints.
* If ProcessInjectionTarget gets fired before ProcessInjectionPoint then this might be not that worse.
* When will the initial BeanAttributes get created from the AnnotatedType? In the spec it seems like it should get fired just before the ProcessBean, but that doesn't make sense in our opinion. It imo should get fired just right at the beginning and the rest of the processing (e.g. ProcessInjectionTarget) should get this information via the getBean().
Thus we finally figured that the order which makes the most sense would be:
1.) .. create a Bean<T> with the initial information taken from the AnnotatedType
2.) fire ProcessBeanAttributes<T> and apply the results eventually
3.) fire ProcessInjectionTarget and apply it if changed
4.) fire ProcessInjectionPoint for each InjectionTarget#getInjectionPoints()
5.) fire ProcessBean
We think that would make sense, wdyt?
LieGrue,
arne and strub
11 years, 11 months
[JBoss JIRA] (CDI-247) It's currently not possible to implement a primitive and wrapping type producer method for the same type
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-247?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-247:
-----------------------------------
Right.
Btw, for backward compat reasons we should move isNullable() back from BeanAttributes to Bean<T> and deprecated it there.
> It's currently not possible to implement a primitive and wrapping type producer method for the same type
> --------------------------------------------------------------------------------------------------------
>
> Key: CDI-247
> URL: https://issues.jboss.org/browse/CDI-247
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> I like to implement a producer which can satisfy the following injection points:
> {code}
> private @Inject @IsFeatureA Boolean featureA;
> private @Inject @IsFeatureA boolean featureA;
> {code}
> Boolean (wrapper type) and boolean (primitive type) used at the same time.
> This is currently not allowed by the CDI spec!
> 5.2.4. "Primitive types and null values" defines that
> "For the purposes of typesafe resolution and dependency injection, primitive types and their corresponding wrapper types in the package java.lang are considered identical and assignable."
> In the same paragraph it also states that
> "However, if an injection point of primitive type resolves to a bean that may have null values, such as a producer method with a non-primitive return type or a producer field with a non-primitive type, the container automatically detects the prob- lem and treats it as a deployment problem."
> This means that I can only have producer methods and fields which have primitive return values and never use their wrapper types if I like to inject into both boolean and Boolean fields.
> But if I use the primitive type, then I loose the ability to explicitly return null for those.
> Possible solution:
> As primitives and their wrapper only can be @Dependent, it would be perfectly possible to e.g. inspect the InjectionPoint and on a primitive type return a default value and for a wrapper type return null.
--
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, 11 months
intercepted private @PostConstruct method behaviour?
by Mark Struberg
Hi folks!
What happens if I have a
@Transactional
public class MyService {
@PostConstruct
private void doTheInit() {...}
Where the interceptor looks like
@Interceptor @Transactional
public class TransactionalInterceptor {
@PostConstruct
public void postConstructInterception(InvocationContext ic) {..}
Question a.) does the @Transactional interceptor still apply to the _private_ doTheInit() method?
Question b.) consider the doTheInit() method being changed to public and it will get invoked by a user. Does the postConstructInterception still get invoked? Or must it only get invoked for _real_ PostConstruct actions triggered by the container?
LieGrue,
strub
11 years, 11 months
[JBoss JIRA] (CDI-247) It's currently not possible to implement a primitive and wrapping type producer method for the same type
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-247?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-247:
----------------------------------
The spec still contains following description in 11.1 "The Bean interface":
{quote}
* isNullable() must return true if the method Bean.create() sometimes returns a null value, and false otherwise, as defined in Section 5.2.5.
{quote}
No info about deprecation (https://github.com/jboss/cdi/commit/136d070026cd69278e651fcc483e7d0950091b22)
> It's currently not possible to implement a primitive and wrapping type producer method for the same type
> --------------------------------------------------------------------------------------------------------
>
> Key: CDI-247
> URL: https://issues.jboss.org/browse/CDI-247
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.0, 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> I like to implement a producer which can satisfy the following injection points:
> {code}
> private @Inject @IsFeatureA Boolean featureA;
> private @Inject @IsFeatureA boolean featureA;
> {code}
> Boolean (wrapper type) and boolean (primitive type) used at the same time.
> This is currently not allowed by the CDI spec!
> 5.2.4. "Primitive types and null values" defines that
> "For the purposes of typesafe resolution and dependency injection, primitive types and their corresponding wrapper types in the package java.lang are considered identical and assignable."
> In the same paragraph it also states that
> "However, if an injection point of primitive type resolves to a bean that may have null values, such as a producer method with a non-primitive return type or a producer field with a non-primitive type, the container automatically detects the prob- lem and treats it as a deployment problem."
> This means that I can only have producer methods and fields which have primitive return values and never use their wrapper types if I like to inject into both boolean and Boolean fields.
> But if I use the primitive type, then I loose the ability to explicitly return null for those.
> Possible solution:
> As primitives and their wrapper only can be @Dependent, it would be perfectly possible to e.g. inspect the InjectionPoint and on a primitive type return a default value and for a wrapper type return null.
--
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, 11 months
unify areQualifiersEquivalent and areInterceptorBindingEquivalent?
by Mark Struberg
areQualifiersEquivalent
and
areInterceptorBindingsEquivalent
are pretty much the same internally, right?
So what about to generalize this into a
areAnnotationsEquivalent(Annotation ann1, Annotation ann2)
which returns only true if the classes of ann1 == ann2 and all except @Nonbinding members are equal.
same goes for the hashCode methods of those 2.
wdyt?
LieGrue,
strub
11 years, 11 months
CDI#setCDIProducer usage
by Mark Struberg
Hi folks!
How is setCDIProducer expected to work?
Consider you have the CDI class in a shared container folder which is available to many EARs.
In that case I would have expected that it must maximally account for the CDIProducer vor a specific EAR and all other EARs CDIProducers remain unchanged.
any tip?
LieGrue,
strub
11 years, 11 months
