[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-527 started by Antoine Sabot-Durand.
------------------------------------------------
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Antoine Sabot-Durand
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (CDI-644) Link formatting in the specification text
by Tomas Remes (JIRA)
Tomas Remes created CDI-644:
-------------------------------
Summary: Link formatting in the specification text
Key: CDI-644
URL: https://issues.jboss.org/browse/CDI-644
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Tomas Remes
In the last version of specification there was good use of link formatting in the text. It looks as follows:
{noformat}
Section 2.4.1, “Built-in scope types”
{noformat}
I would like to keep this format (especialy the prefix "Section x.x.x") also in the new version because I think it's more legible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
John Ament reassigned CDI-471:
------------------------------
Assignee: John Ament
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
> Key: CDI-471
> URL: https://issues.jboss.org/browse/CDI-471
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Reporter: Antonin Stefanutti
> Assignee: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
> String value;
> }
> public @interface ContextNames {
> ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (CDI-312) ProcessModule doesn't reflect the @Priority changes in CDI-18
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-312?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba resolved CDI-312.
------------------------------
Resolution: Out of Date
{{ProcessModule}} was removed.
> 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 was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-490 started by John Ament.
--------------------------------------
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Assignee: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (CDI-30) An API for managing built in request contexts designed for other frameworks
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ]
John Ament updated CDI-30:
--------------------------
Summary: An API for managing built in request contexts designed for other frameworks (was: An API for managing built in contexts designed for other frameworks)
> An API for managing built in request contexts designed for other frameworks
> ---------------------------------------------------------------------------
>
> Key: CDI-30
> URL: https://issues.jboss.org/browse/CDI-30
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Assignee: John Ament
> Fix For: 2.0 .Final
>
>
> In order to allow CDI to play well in the general ecosystem, it needs to have SPIs. These SPIs need to allow other libraries to do things like register beans (CDI extensions), look up a bean manager, and get managed versions of its classes.
> CDI has no way currently to support a framework starting and stopping built in contexts. These built in contexts are not really clear in how they are started, other than the container is responsible for starting them. This means its near impossible for an external library which is not Java EE aware to start these built in contexts. Being able to reuse these contexts allow developers to build their beans once and reuse them in many use cases.
> These use cases may include:
> 1. Quartz Scheduler/CDI Integration. A Prototype of this is available in DeltaSpike, where jobs can be managed beans, by overriding the InstanceJobFactory, and can have contexts started via an annotation. To bring it a step further, Quartz, in order to mirror Java EE capabilities, may want to say that during the execution of a job, an instance of a request context is active. To do this, the developer should not need to do anything, but instead Quartz may automatically register a job listener that starts and stops the context (see: http://www.quartz-scheduler.org/documentation/quartz-2.2.x/cookbook/JobLi...)
> 2. Camel-CDI. Camel may want to say that during the execution of a route, a request context is active.
> 3. Netty/CDI (or any arbitrary network based server). During the reception of a message over TCP, a request is active. Likewise, for the entire TCP connection a session context is active.
> 4. Sparkjava/CDI. Assuming that sparkjava isn't running in a servlet container, during the execution of an arbitrary reactive method call, a request context is available for use.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
Finding a new name for InterceptorProxyFactory
by Antoine Sabot-Durand
Hi all,
In my last review for CDI-580 (https://github.com/cdi-spec/cdi/pull/315), I
removed all reference to proxies in Javadoc and spec doc following various
feedback.
So now the name of the interface is the only one dealing with Proxy, so we
really need to find it a new name.
I listed some proposal in PR 315:
- InstanceEnhancer (short but not very clear)
- BusinessMethodInvocationFactory (more exact from spec pov, but is it
clear from user pov?)
- InterceptionFactory (cleared from user pov and near our initial name)
- InterceptionEnhancer
Feedback and other names are welcome.
Antoine
9 years
Need a review for PR 323 (new xsd for CDI 2.0)
by Antoine Sabot-Durand
Hi all,
PR 323 is blocking 2 other PR, so if some of you have time today to review
the new xsd. Changes a rather small: version and year mainly.
Another PR is dealing with examples in the spec document.
Thx for your help,
Antoine
9 years
