[JBoss JIRA] (CDI-316) Adopt usage of the @since Javadoc tag
by George Gastaldi (JIRA)
George Gastaldi created CDI-316:
-----------------------------------
Summary: Adopt usage of the @since Javadoc tag
Key: CDI-316
URL: https://issues.jboss.org/browse/CDI-316
Project: CDI Specification Issues
Issue Type: Clarification
Components: Javadoc and API
Affects Versions: 1.1.PRD
Reporter: George Gastaldi
It's a good practice to use the @since javadoc tag in the methods and interfaces/classes created in this new version.
This is necessary when one need to figure out if some feature is targeted to work in 1.1 only, for example.
This issue was created so that all the API code can be reviewed before the next release. Some classes already have this information, other still don't (@Vetoed is one that is missing, afaik)
--
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
Proposal for global CDI enablement
by Pete Muir
I've been working with the Bill and Linda, the Java EE spec leads, as well as with Jason, Stuart and Emmanuel at Red Hat, to come up with a proposal for global enablement for CDI in Java EE 7. Based on Linda and Bill's poll of the community, this appears to be much more popular than we had previously thought, so we have decided to propose it, despite it being quite late into the spec development. I think what we have come up with represents a good approach to achieve it, and also addresses a long requested feature request, that CDI should not consider every class a bean. Please let us know your thoughts. If you aren't on the Java EE EG, or the observers list, or the same for CDI, then please say, and I'll forward your thoughts.
--------------------------------
Background
-----------------
Globally enabling CI would allow other specifications in the Java EE platform to rely on CDI, and not have to provide an abstraction over DI services, such as those introduced by JSF managed beans, and considered by JAX-RS, Batch and others.
Challenges
----------------
* The startup time of Weld is O(n) with the number of beans. We assert that it is not possible for a CDI impl to attain an O(1) startup time, therefore globally enabling CDI will increase the startup time of Java EE servers. For Red Hat, low startup time is a top priority.
* Compatibility with other users of JSR-330. By considering all deployments as CDI deployments without any enablement marker, we will likely cause deployments which used another JSR-330 implementation to fail. This would have worked on Java EE 6. Other JSR-330 impls that fall into this camp are Spring and Guice.
* Backwards compatibility. Some users may have intentionally not placed a beans.xml into a deployment, but used CDI annotations, and enabled the beans some other way, eg. via a portable extension.
* A large proportion of Java EE users 800/1000 indicate they want this feature, thus meaning we should try to address it
Proposed solution
-------------------------
We introduce the concept of a "bean defining annotation" and define that any class in any deployment (including those with no beans.xml) with a bean defining annotation is discovered and may be a CDI bean, and can participate fully in the application. Any archive with a beans.xml continues to work in the same way, such that all classes in the archive are discovered and may be CDI beans.
This addresses the startup time problem. Whilst a scan of classes is still required, the impact on startup time is negligible:
* A Java EE server must scan all classes to discover other component defining annotations such as EJBs, Servlet's, JAX-RS resources etc.
* This scan can be done at the bytecode level, with no need to classload the class, which our research shows is the costly part of CDI startup
Any scope (normal scope or pseudo-scope) applied to a bean at source level is a bean defining annotation (so you must add @Dependent to your class in order to get it to be picked up as a dependent bean).
Only classes with a bean defining annotation, or with an annotation, or meta-annotation, present specified by @WithAnnotations are passed to ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1 PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType is observed for a type without a bean defining annotation, as a result of having an annotation present that is specified by @WithAnnotations, it may instruct the container to add discover the class as a bean.
Every archive in a deployment would be considered a bean archive, simply with differing contents depending on the presence of beans.xml
If a developer adds a beans.xml to their archive, behavior is as CDI 1.0. We will add an attribute to beans.xml "auto-discover=true", which the user may set to false in order to add a beans.xml and only have classes with a bean defining annotation discovered, which allows beans.xml to be used as a deployment descriptor but still limit the classes discovered.
OPEN ISSUE: Should auto-discover be false by default for beans.xml with version 1.1. This would mean that adding a beans.xml would have no impact on discovery for 1.1 apps, however it is a significant change from 1.0.
OPEN ISSUE: Should only scopes for which a CDI context exists be considered component defining? This could introduce some thorny edge cases, but would address the JSR-330 compatibility issue better.
OPEN ISSUE: Should we extend auto-discover in beans.xml to allow complete disablement of scanning e.g. auto-discover="all|bean-defining-annotations-only|none" ?
OPEN ISSUE: How should the ProcessAnnotatedType event instruct the container to discover a class as a bean? Perhaps something like event.discover(clazz)?
OPEN ISSUE: Should we integrate this with the package level scanning control we have proposed for CDI 1.1?
---------------------------------
12 years
[JBoss JIRA] (CDI-315) Allow BeanManager methods, such as getBeans in AfterDeploymentValidation observers
by Marek Schmidt (JIRA)
Marek Schmidt created CDI-315:
---------------------------------
Summary: Allow BeanManager methods, such as getBeans in AfterDeploymentValidation observers
Key: CDI-315
URL: https://issues.jboss.org/browse/CDI-315
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Reporter: Marek Schmidt
Fix For: 1.1 (Proposed)
CDI-274 which disallows some BeanManager methods during application initialization is too strict.
Mark's original suggestion for CDI-274 contained a very important part "...before the AfterDeploymentValidation phase". AfterDeploymentValidation observers would be quite useless if we can't use BeanManager.getBeans in them IMHO, and I think there is no reason to disallow BeanManager methods in AfterDeploymentValidation, so we should allow them there...
So maybe something like:
"IllegalStateException if called during application initialization before the AfterDeploymentValidation phase"
--
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
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Marek Schmidt (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Marek Schmidt commented on CDI-274:
-----------------------------------
Does "during application initialization" mean AfterDeploymentValidation observers?
Mark's suggestion contained a very important part "...before the AfterDeploymentValidation phase". AfterDeploymentValidation observers would be quite useless if we can't use BeanManager.getBeans in them IMHO.
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
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
[JBoss JIRA] (CDI-314) Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean
by Martin Kouba (JIRA)
Martin Kouba created CDI-314:
--------------------------------
Summary: Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean
Key: CDI-314
URL: https://issues.jboss.org/browse/CDI-314
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.1.PRD
Reporter: Martin Kouba
In CDI 1.1 a bean which has {{@Alternative}} stereotype applied may be selected using the bean class. If both a stereotype and a bean class is used to select/deselect an alternative bean, conflicts may occur (in the cotext of CDI-18). E.g.:
{code}
@Stereotype
@Alternative
@Target({ TYPE, METHOD, FIELD })
@Retention(RUNTIME)
public @interface Mock {
}
@Mock
class Foo {
}
<beans>
<alternatives>
<class priority="1000">org.mycompany.Foo</class>
<stereotype priority="100">org.mycompany.Mock</stereotype>
</alternatives>
</beans>
{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
12 years
JCP 2.9
by Pete Muir
Hi all,
FYI CDI has moved to JCP 2.9, which is identical to JCP 2.8 (which we were previously running under) except that the SE&EE EC has merged with the ME EC (which has no impact on us). So no impact on us :-)
Pete
12 years
Producer#dispose(T instance) and similar
by Mark Struberg
Hi!
I'm currently stumbling over implementing
Producer#dispose(T instance) properly
The Producer#produce(CreationalContext)
has the CreationalContext parameter but the dispose and others do not have it.
Problem here is that a Producer could probably get exchanged via a portable extension via ProcessProducer#setProducer(Producer) so it could be from a foreign source which must not know anything about container implementation details.
What now about having an interceptor on @PreDestroy? This is what you get if your interceptor has a@PreDestroy method himself as per the interceptors and EJB specs. That would mean that the instance passed to dispose() whould be the proxy? That purely sounds wrong to me.
Another issue being InjectionTarget#postConstruct() only having the instance T as well. Now what about @PostConstruct interceptors as defined in the interceptors spec?
Currently we have a dirty hack in OWB to pass over the CreationalContext which contains the dependent scoped interceptors for our own Producers and InjectionTargets. But I have no clue yet how that should get implemented if one plugs in a portable Producer via an Extension ^^
Who is responsible of performing the interception? The Producer? Or must the instance being handed into already be a Proxy?
LieGrue,
strub
12 years
[JBoss JIRA] (CDI-312) ProcessModule doesn't reflect the @Priority changes in CDI-18
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-312?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-312:
-----------------------------------
I'm currently thinking about removing the ProcessModule event again. This got introduced very early in our CDI-1.1 phase before we had a common understanding about CDI-18. Now that we have a common understanding that global enablement is a good thing we need to review the ProcessModule event again.
Imo the pattern of programmatic per-BDA enablement doesn't fit well to the CDI 1.1 approach and I'd rather not support this. Instead I'd propose adding methods to BeforeBeanDiscovery. e.g.
{code}
addAlternitiveDefinition(Class alternativeClass, int priority, boolean enabled);
{code}
And similar for Interceptors and Decorators.
The only probably useful feature left is getBeansXml(). But to be honest this is the same than doing a classloader.getResources(), right?
> ProcessModule doesn't reflect the @Priority changes in CDI-18
> -------------------------------------------------------------
>
> Key: CDI-312
> URL: https://issues.jboss.org/browse/CDI-312
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment, Portable Extensions
> Reporter: Mark Struberg
>
> ProcessModule has a getAlternatives() method which returns a Set<Class> of all enabled alternatives. This Set is mutable and can get changed via extensions. But which 'priority' should such an added Alternative have? (see CDI-18). And should this only account for the one beans.xml or all?
> Also what is about 'globally' enabled alternatives? Should they get returned in all modules or just in the module they are enabled in?
--
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
[JBoss JIRA] (CDI-312) ProcessModule doesn't reflect the @Priority changes in CDI-18
by Mark Struberg (JIRA)
Mark Struberg created CDI-312:
---------------------------------
Summary: ProcessModule doesn't reflect the @Priority changes in CDI-18
Key: CDI-312
URL: https://issues.jboss.org/browse/CDI-312
Project: CDI Specification Issues
Issue Type: Bug
Components: Packaging and Deployment, Portable Extensions
Reporter: Mark Struberg
ProcessModule has a getAlternatives() method which returns a Set<Class> of all enabled alternatives. This Set is mutable and can get changed via extensions. But which 'priority' should such an added Alternative have? (see CDI-18). And should this only account for the one beans.xml or all?
Also what is about 'globally' enabled alternatives? Should they get returned in all modules or just in the module they are enabled in?
--
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
