From rinsvind at gmail.com Mon Oct 9 07:17:23 2017 From: rinsvind at gmail.com (Todor Boev) Date: Mon, 9 Oct 2017 14:17:23 +0300 Subject: [cdi-dev] scope vs scope type vs context Message-ID: I am looking for formal definitions of scope, scope type, context The closest seem to be in http://docs.jboss.org/cdi/spec /2.0/cdi-spec.html#scopes Scope: The scope of a bean determines the lifecycle of its instances, and which instances of the bean are visible to instances of other beans, Scope type: A scope type is represented by an annotation type. Context: Scoped objects, exist in a well-defined lifecycle context: ... Custom scopes are normally defined by portable extensions, which must also provide a context object, as defined in The Context interface, that implements the custom scope. These seem vague. Specifically it seems that the spec prefers to talk about "contextual instances" rather that about a uniform set of objects that represent the current "context". Intuitively to me "scope" relates to "context", as "class" relates to "object". The scope seems like a composite type, consisting of all beans (not bean instances) marked with the same scope annotation. The context is an object cache that collects the bean instances of that scope created during a dependency injection pass. Can someone clarify these terms? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171009/d60f9cbc/attachment.html From issues at jboss.org Tue Oct 10 05:48:01 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 10 Oct 2017 05:48:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-715) Transitive stereotype declarations - clarify conflicting default scopes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated CDI-715: ----------------------------- Fix Version/s: 2.1 (Discussion) > Transitive stereotype declarations - clarify conflicting default scopes > ----------------------------------------------------------------------- > > Key: CDI-715 > URL: https://issues.jboss.org/browse/CDI-715 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Minor > Fix For: 2.1 (Discussion) > > > Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined. > > Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho). > Note that this is not a problem for {{@Named}}, {{@Alternative}} and -interceptor bindings-. > Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. -All bindings are added to the set-. > UPDATE: Interceptor bindings are probably also affected. The interceptors spec defines _"An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass."_ (3.3 Binding an Interceptor to a Component) which implies that multiple interceptor bindings of the same type are not supported. So the spec should probably cover cases where stereotypes declare the interceptor bindings of the same type. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:32:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:32:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-717) Element mistakenly removed from beans_2_0.xsd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-717: ------------------------------------- Fix Version/s: 2.1 > Element mistakenly removed from beans_2_0.xsd > --------------------------------------------- > > Key: CDI-717 > URL: https://issues.jboss.org/browse/CDI-717 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final > Reporter: Matej Novotny > Fix For: 2.1 > > > While creating and editing {{beans_2_0.xsd}} there was one line removed as part of [this PR|https://github.com/cdi-spec/cdi/pull/348]. This line is present in {{beans_1_1.xsd}} -> [see the code|https://github.com/cdi-spec/cdi/blob/master/api/src/main/resources/beans_1_1.xsd#L83]. > To sum up the meaning of this line, it allows presence of any other non-defined element from _other namespace (than target namespace)_ and further on enforces validation of such element against corresponding XSD. > As a consequence of this change, following {{beans.xml}} is valid with CDI 1.2 ({{beans_1_1.xsd}}) but no longer against CDI 2.0 ({{beans_2_0.xsd}}): > {code} > > xmlns:weld="http://jboss.org/schema/weld/beans" > xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" > bean-discovery-mode="all"> > > > > > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:33:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-716) Allow to recognize custom Bean at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-716: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Allow to recognize custom Bean at runtime > ----------------------------------------- > > Key: CDI-716 > URL: https://issues.jboss.org/browse/CDI-716 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 .Final > Reporter: Matej Novotny > Fix For: 2.1 (Discussion) > > > At the moment, they only way to tell custom bean (created via {{BeanConfigurator}} or class implementing {{javax.enterprise.inject.spi.Bean}}) from "standard" one is to have an extension and listen to {{ProcessSyntheticBean}}. This is good enough if it's sufficient to tell the difference at bootstrap time. > However, at runtime, there is no way to do this. > We could add a method to {{javax.enterprise.inject.spi.Bean}} which would allow to tell the difference. The name of the method could be {{isCustom()}} or {{getKind()}}. > Generally, there should be no need to differentiate between custom/standard beans, but when digging deeper, it doesn't hurt to know. Putting this into {{Bean}} interface keeps it deep enough while still giving the information. > One of the use cases for this would be CDI-194, which could be "nicely" implemented (avoiding {{null}} values), if there was a way to recognize custom bean. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:33:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:33:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-714) No way to access the underlying bean in a producer when using BeanConfigurator In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-714: ------------------------------------- Fix Version/s: 2.1 (Discussion) > No way to access the underlying bean in a producer when using BeanConfigurator > ------------------------------------------------------------------------------ > > Key: CDI-714 > URL: https://issues.jboss.org/browse/CDI-714 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > I was reusing an example the Weld guys pointed me at. > {code} > InjectionPoint ip = (InjectionPoint)bm.getInjectableReference(new EmptyInjectionPoint(be...), cc); > {code} > The problem is that I'm using the configurator to create the bean, and the resulting function for the producer doesn't have access to the bean that was created. > {code} > abd.addBean() > .addQualifiers(new ClaimLiteral("", Claims.UNKNOWN)) > .addType(type) > .scope(Dependent.class) > .createWith(ClaimProducer.INSTANCE); > {code} > So because of this, I have no way to get the injection point. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:42:01 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:42:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-713) Why can't Provider injection points use non-proxyable types with @RequestScoped providers? In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand closed CDI-713. ------------------------------------ Resolution: Rejected As said, this is expected behaviour from the spec. > Why can't Provider injection points use non-proxyable types with @RequestScoped providers? > --------------------------------------------------------------------------------------------- > > Key: CDI-713 > URL: https://issues.jboss.org/browse/CDI-713 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions, Resolution > Affects Versions: 1.2.Final > Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final. > Reporter: Scott Stark > > In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers: > {code:java} > @Inject > @Claim(standard = Claims.iat) > private Provider providerIAT; > {code} > {code:java} > @Produces > @Claim(standard = Claims.iat) > @RequestScoped > Long getIAT() { > JsonWebToken jwt = getJWTPrincpal(); > if (jwt == null) { > System.out.printf("getIAT, null JsonWebToken\n"); > return null; > } > System.out.printf("getIAT\n"); > return jwt.getIssuedAtTime(); > } > {code} > I ran into the following exception: > {noformat} > Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}. > at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182) > at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144) > at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736) > at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189) > at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100) > at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269) > {noformat} > The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:49:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476233#comment-13476233 ] Antoine Sabot-Durand commented on CDI-712: ------------------------------------------ This should be clarified for all built-in bean that container must provide in the spec > Clarify whether is should be possible to "override" built-in Instance/Provider > ------------------------------------------------------------------------------ > > Key: CDI-712 > URL: https://issues.jboss.org/browse/CDI-712 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > In theory, an extension could register an alternative custom bean to override the built-in Instance/Provider bean for injection points such as {{@Inject Provider}}. > It is not forbidden at the moment. The spec only states that there must be a built-in bean eligible for any injection point with Instance/Provider required type and any qualifier. See also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance. > It seems to be a powerful feature. On the other hand, it might be a source of confusion. Take for example this injection point: > {code:java} > @Inject > @MyQualifier > Instance instance; > {code} > The qualifier is now considered when calling {{instance.get()}} and NOT when resolving the injection point. > Note that the spec already allows to decorate built-in beans. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:49:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:49:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-712: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Clarify whether is should be possible to "override" built-in Instance/Provider > ------------------------------------------------------------------------------ > > Key: CDI-712 > URL: https://issues.jboss.org/browse/CDI-712 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > In theory, an extension could register an alternative custom bean to override the built-in Instance/Provider bean for injection points such as {{@Inject Provider}}. > It is not forbidden at the moment. The spec only states that there must be a built-in bean eligible for any injection point with Instance/Provider required type and any qualifier. See also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance. > It seems to be a powerful feature. On the other hand, it might be a source of confusion. Take for example this injection point: > {code:java} > @Inject > @MyQualifier > Instance instance; > {code} > The qualifier is now considered when calling {{instance.get()}} and NOT when resolving the injection point. > Note that the spec already allows to decorate built-in beans. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Oct 12 05:58:00 2017 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Thu, 12 Oct 2017 05:58:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Antoine Sabot-Durand updated CDI-710: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Require default event ExecutorService to be managed on Java EE > -------------------------------------------------------------- > > Key: CDI-710 > URL: https://issues.jboss.org/browse/CDI-710 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Guillermo Gonz?lez de Ag?ero > Fix For: 2.1 (Discussion) > > > When running on a Java EE environment, CDI should use a managed executor service by default for asynchronous operations. > This is already required by the JAX-RS 2.1 spec (http://download.oracle.com/otndocs/jcp/jaxrs-2_1-pfd-spec/index.html), section 5.8: > {quote}In an environment that supports the Concurrency Utilities for Java EE [13], such as the Java EE Full Profile, implementations MUST use ManagedExecutorService and ManagedScheduledExecutorService, respectively. The reader is referred to the Javadoc of ClientBuilder for more information about executor services.{quote} > Containers will presumably offer monitoring features and thread pool configuration options for managed executor services. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From arjan.tijms at gmail.com Fri Oct 13 07:09:25 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 13 Oct 2017 12:09:25 +0100 Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0 interception factory In-Reply-To: References: Message-ID: Hi, On Tue, Sep 19, 2017 at 2:22 PM, arjan tijms wrote: > > No really. Weld stores the bindings also in context data but the API is >> using a direct reference to a stored set. > > [...] > I don't think this is an InterceptionFactory-specific problem. It's a >> general issue. It should work the same if you use an extension to add an >> interceptor binding. >> > So that would hold for Java EE 7 then as well. Last time I looked for Weld 3, but is there also a way to get the interceptor bindings (in a Weld specific way) from Weld 2? Say from a TerminalAroundInvokeInvocationContext? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171013/ea6f1f65/attachment.html From mkouba at redhat.com Fri Oct 13 07:35:02 2017 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 13 Oct 2017 13:35:02 +0200 Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0 interception factory In-Reply-To: References: Message-ID: <09b47e74-5ccd-b67e-1097-388d7abe77e0@redhat.com> Dne 13.10.2017 v 13:09 arjan tijms napsal(a): > Hi, > > On Tue, Sep 19, 2017 at 2:22 PM, arjan tijms > wrote: > > No really. Weld stores the bindings also in context data but the > API is using a direct reference to a stored set. > > > [...] > > > I don't think this is an InterceptionFactory-specific problem. > It's a general issue. It should work the same if you use an > extension to add an interceptor binding. > > > So that would hold for Java EE 7 then as well. Last time I looked for > Weld 3, but is there also a way to get the interceptor bindings (in a > Weld specific way) from Weld 2? Say from a > TerminalAroundInvokeInvocationContext? No, this is not possible in weld 2. Feel free to file a feature request to backport this. > > Kind regards, > Arjan Tijms > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From arjan.tijms at gmail.com Fri Oct 13 09:17:41 2017 From: arjan.tijms at gmail.com (arjan tijms) Date: Fri, 13 Oct 2017 14:17:41 +0100 Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0 interception factory In-Reply-To: <09b47e74-5ccd-b67e-1097-388d7abe77e0@redhat.com> References: <09b47e74-5ccd-b67e-1097-388d7abe77e0@redhat.com> Message-ID: On Fri, Oct 13, 2017 at 12:35 PM, Martin Kouba wrote: > >> No, this is not possible in weld 2. Feel free to file a feature request > to backport this. > I just did, see here: https://issues.jboss.org/browse/WELD-2433 Thx! Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171013/d97f9926/attachment.html From issues at jboss.org Fri Oct 13 13:26:00 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Fri, 13 Oct 2017 13:26:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477144#comment-13477144 ] John Ament commented on CDI-468: -------------------------------- [~atijms] has another usecase around this, maybe it deserves its own ticket. When you programmatically add an interceptor to a bean via {{InterceptionFactory}} the actual interceptor binding added gets lost. For similar use cases, when you have a nonbinding attribute the value of that attribute is just completely lost. > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > Fix For: 2.1 (Discussion) > > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 03:35:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 16 Oct 2017 03:35:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477311#comment-13477311 ] Martin Kouba commented on CDI-468: ---------------------------------- [~meetoblivion] do you think we should provide a different solution for the {{InterceptionFactory}} use case? > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > Fix For: 2.1 (Discussion) > > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 05:21:00 2017 From: issues at jboss.org (Todor Boev (JIRA)) Date: Mon, 16 Oct 2017 05:21:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-719) Allow attributes on scope annotations In-Reply-To: References: Message-ID: Todor Boev created CDI-719: ------------------------------ Summary: Allow attributes on scope annotations Key: CDI-719 URL: https://issues.jboss.org/browse/CDI-719 Project: CDI Specification Issues Issue Type: Feature Request Components: Contexts Affects Versions: 2.Future Reporter: Todor Boev Priority: Minor The 2.0 specification states that scope annotations with attributes result in non-portable behavior: https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#defining_new_scope_type At the same time Java EE standards like JSF use attributes on some of their scope annotations.:http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html There are use cases of applications that have a well defined structure, but the user must specify multiple copies of that structure. One can imagine a server application that must handle multiple endpoints, so the user must have the means to create multiple copies of a request processing pipeline. E.g. {{@RequestScoped("login")}}, {{@RequestScoped("shopping-card")}}. Ideally CDI should use annotation instances, rather than annotation classes to select contexts. http://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/BeanAttributes.html#getScope-- http://docs.jboss.org/cdi/api/2.0/javax/enterprise/inject/spi/BeanManager.html#getContext-java.lang.Class- http://docs.jboss.org/cdi/api/2.0/javax/enterprise/context/spi/Context.html#getScope-- If this is not possible at least BeanAttributes can have a convenience method to get the scope annotation instance, and the specification should explicitly allow the use of attributes on scope annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Oct 16 07:27:01 2017 From: issues at jboss.org (John Ament (JIRA)) Date: Mon, 16 Oct 2017 07:27:01 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477448#comment-13477448 ] John Ament commented on CDI-468: -------------------------------- [~mkouba] I'm not sure TBH. I think one way to solve it is to get access to the interceptor binding that caused the current interceptor to be invoked. It shouldn't matter if: - The interceptor binding was added directly to the class OR - It was added programmatically via {{InterceptionFactory}} OR - It was added programmatically via an {{Extension}} OR - It was added via a {{Stereotype}} I would hope it's a seamless experience. I just want the current interceptor binding, and that's all I really need. > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > Fix For: 2.1 (Discussion) > > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public A getInterceptorBinding(Class type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Oct 18 05:28:00 2017 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 18 Oct 2017 05:28:00 -0400 (EDT) Subject: [cdi-dev] [JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478574#comment-13478574 ] Martin Kouba commented on CDI-712: ---------------------------------- So I've just updated the [test repo|https://github.com/mkouba/alternative-builtin-beans] and both impls still fail (even OWB 2.0.2). > Clarify whether is should be possible to "override" built-in Instance/Provider > ------------------------------------------------------------------------------ > > Key: CDI-712 > URL: https://issues.jboss.org/browse/CDI-712 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > In theory, an extension could register an alternative custom bean to override the built-in Instance/Provider bean for injection points such as {{@Inject Provider}}. > It is not forbidden at the moment. The spec only states that there must be a built-in bean eligible for any injection point with Instance/Provider required type and any qualifier. See also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance. > It seems to be a powerful feature. On the other hand, it might be a source of confusion. Take for example this injection point: > {code:java} > @Inject > @MyQualifier > Instance instance; > {code} > The qualifier is now considered when calling {{instance.get()}} and NOT when resolving the injection point. > Note that the spec already allows to decorate built-in beans. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From john.ament at spartasystems.com Sat Oct 21 10:22:28 2017 From: john.ament at spartasystems.com (John Ament) Date: Sat, 21 Oct 2017 14:22:28 +0000 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 Message-ID: Hey all Not sure where else to turn ? I'm trying to start testing my apps on Java 9, I believe Java 9 kicks back the javax.annotation dependency that CDI declares due to a package collision with the built in JDK's javax.annotation package. The errors I get are due to missing javax/annotation/Priority. I'm wondering if anyone else has tried this, and if there's a clean work around? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171021/3a390912/attachment.html From rmannibucau at gmail.com Sat Oct 21 12:17:52 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Sat, 21 Oct 2017 18:17:52 +0200 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: Message-ID: Hi John, the exact same issue happens with @Nullable which is used by a bunch of libraries (static code analyzis, @AutoValue of guava etc...) Best i was able to do was to force all these javax annotation to be load in a classloader which is not the root JVM one but this is a huge regression of java 9 which has no solution and oracle claims it is intended since it is a bad practise to have packages over jars (even if jars are abstracted into a classloader so this is not something which means anything) :(. A workaround is to not activate the JVM javax.annotation package and provide all javax.* in the unamed module but this will not last very long since all modules will slowly be named with time. Hope it helps a bit even if it doesn't solve anything. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-10-21 16:22 GMT+02:00 John Ament : > Hey all > > > Not sure where else to turn ? > > > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks back > the javax.annotation dependency that CDI declares due to a package > collision with the built in JDK's javax.annotation package > . > The errors I get are due to missing javax/annotation/Priority. I'm > wondering if anyone else has tried this, and if there's a clean work around? > > > John > > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171021/d262f899/attachment.html From john.ament at spartasystems.com Sun Oct 22 21:54:35 2017 From: john.ament at spartasystems.com (John Ament) Date: Mon, 23 Oct 2017 01:54:35 +0000 Subject: [cdi-dev] Consistency across specs with the use of @Priority Message-ID: I found this interesting to say the least. In CDI, we use highest priority where the value of the @Priority annotation is compared the higher numeric value is considered higher priority. We followed suite so far in MicroProfile specs. I'm not looking to throw dirt, but wanted to get a general opinion from others on this. The JAX-RS treats the lower numeric value as more important (in mathematical terms, it's being treated as the denominator). > If two or more providers are candidates for a certain task, the one with the highest priority is chosen: the highest priority is defined to be the one with the lowest value in this case. That is, @Priority(1) is higher than @Priority(10). So I'm wondering, why did CDI use the approach that CDI is using? John ________________________________ NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/d0b31c1d/attachment-0001.html From rmannibucau at gmail.com Mon Oct 23 01:10:46 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 23 Oct 2017 07:10:46 +0200 Subject: [cdi-dev] Consistency across specs with the use of @Priority In-Reply-To: References: Message-ID: >From what I recall it is not the same for interceptors and decorators too. More about the chain vision and what is the "0" from my understanding. Le 23 oct. 2017 03:55, "John Ament" a ?crit : > I found this interesting to say the least. In CDI, we use highest > priority where the value of the @Priority annotation is compared the higher > numeric value is considered higher priority. We followed suite so far in > MicroProfile specs. I'm not looking to throw dirt, but wanted to get a > general opinion from others on this. The JAX-RS treats the lower numeric > value as more important (in mathematical terms, it's being treated as the > denominator). > > > > If two or more providers are candidates for a certain task, the one > with the highest priority is chosen: the highest priority is defined to be > the one with the lowest value in this case. That is, @Priority(1) is > higher than @Priority(10). > > So I'm wondering, why did CDI use the approach that CDI is using? > > > John > > > ------------------------------ > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the > sender immediately by return e-mail, delete this message, and destroy all > physical and electronic copies. Thank you. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/634f2fc8/attachment.html From manovotn at redhat.com Mon Oct 23 02:54:45 2017 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 23 Oct 2017 02:54:45 -0400 (EDT) Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: Message-ID: <1764929442.22638820.1508741685270.JavaMail.zimbra@redhat.com> Hi Haven't come across that one yet, but what Romain says is right. You cannot have the same package coming from multiple modules. So the only way is to make sure they come from one module - so either unnamed module, or not using their internal module (which I am not sure is possible here). I don't really know how they imagine people will deal with this... Every other project out there will have similar problems. Matej ----- Original Message ----- > From: "Romain Manni-Bucau" > To: "John Ament" > Cc: "cdi-dev" > Sent: Saturday, October 21, 2017 6:17:52 PM > Subject: Re: [cdi-dev] Duplicate javax.annotation packages and Java 9 > > Hi John, > > the exact same issue happens with @Nullable which is used by a bunch of > libraries (static code analyzis, @AutoValue of guava etc...) > > Best i was able to do was to force all these javax annotation to be load in a > classloader which is not the root JVM one but this is a huge regression of > java 9 which has no solution and oracle claims it is intended since it is a > bad practise to have packages over jars (even if jars are abstracted into a > classloader so this is not something which means anything) :(. > > A workaround is to not activate the JVM javax.annotation package and provide > all javax.* in the unamed module but this will not last very long since all > modules will slowly be named with time. > > Hope it helps a bit even if it doesn't solve anything. > > > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > 2017-10-21 16:22 GMT+02:00 John Ament < john.ament at spartasystems.com > : > > > > > > Hey all > > > > > Not sure where else to turn ? > > > > > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks back > the javax.annotation dependency that CDI declares due to a package collision > with the built in JDK's javax.annotation package . The errors I get are due > to missing javax/annotation/Priority. I'm wondering if anyone else has tried > this, and if there's a clean work around? > > > > > John > > > > > NOTICE: This e-mail message and any attachments may contain confidential, > proprietary, and/or privileged information which should be treated > accordingly. If you are not the intended recipient, please notify the sender > immediately by return e-mail, delete this message, and destroy all physical > and electronic copies. Thank you. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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. From mkouba at redhat.com Mon Oct 23 03:25:36 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 23 Oct 2017 09:25:36 +0200 Subject: [cdi-dev] Consistency across specs with the use of @Priority In-Reply-To: References: Message-ID: Just to sum it up. In CDI we use pririority (either @Priority or Prioritized) to: - select an alternative globally and resolve ambiguous dependencies - enable interceptor globally - enable decorator - order observers - order CDIProviders For alternatives the _highest_ priority value wins. Interceptors and decorators with the _smaller_ priority values are called first which means that an interceptor/decorator with highest priority value is the "closest" to a bean business method invocation. Observers with _smaller_ priority values are called first. BTW there was a vote about observer ordering: http://lists.jboss.org/pipermail/cdi-dev/2016-December/009410.html CDIProvider with _highest_ priority is used. Personally, I think it's more natural to process components with higher priority first (note that priority != order). But when it comes to interceptor chains things get more complicated. Martin Dne 23.10.2017 v 07:10 Romain Manni-Bucau napsal(a): > From what I recall it is not the same for interceptors and decorators > too. More about the chain vision and what is the "0" from my understanding. > > Le?23 oct. 2017 03:55, "John Ament" > a ?crit?: > > I found this interesting to say the least. In CDI, we use highest > priority where the value of the @Priority annotation is compared the > higher numeric value is considered higher priority.? We followed > suite so far in MicroProfile specs. I'm not looking to throw dirt, > but wanted to get a general opinion from others on this.? The JAX-RS > treats the lower numeric value as more important (in mathematical > terms, it's being treated as the denominator). > > > >?If two or more providers are candidates for a certain task, the > one with the highest priority is chosen: the highest priority is > defined to be the one with the lowest value in this case. That is, > @Priority(1) is higher than @Priority(10). > > So I'm wondering, why did CDI use the approach that CDI is using? > > > John > > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which > should be treated accordingly. If you are not the intended > recipient, please notify the sender immediately by return e-mail, > delete this message, and destroy all physical and electronic copies. > Thank you. > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 at 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 Senior Software Engineer Red Hat, Czech Republic From mkouba at redhat.com Mon Oct 23 03:36:09 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 23 Oct 2017 09:36:09 +0200 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: Message-ID: For the record, the CDI API itself does not define a dependency on javax.annotation at all. In fact, I'm wondering why @Priority is not part of JDK?? I suppose the reasons are similar to why javax.annotation.Priority only has @Target({TYPE,PARAMETER}) (even if we tried to push other element types :-(. M Dne 21.10.2017 v 16:22 John Ament napsal(a): > Hey all > > > Not sure where else to turn ? > > > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks > back the javax.annotation dependency that CDI declares due to a package > collision with the built in JDK's javax.annotation package > . > The errors I get are due to missing javax/annotation/Priority.? I'm > wondering if anyone else has tried this, and if there's a clean work around? > > > John > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 Senior Software Engineer Red Hat, Czech Republic From asd at redhat.com Mon Oct 23 04:17:12 2017 From: asd at redhat.com (Antoine Sabot-Durand) Date: Mon, 23 Oct 2017 08:17:12 +0000 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: Message-ID: I encountered the same type of collision with java.transaction.InvalidTransactionException which is in the JDK and in JTA. I remember sending this problem to jigsaw ML [1], but obviously they didn't have time to do something or expect having Java EE spec do the required stuff :-(. Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will be) to support jigsaw, we'll probably have to change packages names :-(. Antoine [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008779.html On Mon, Oct 23, 2017 at 9:51 AM Martin Kouba wrote: > For the record, the CDI API itself does not define a dependency on > javax.annotation at all. > > In fact, I'm wondering why @Priority is not part of JDK?? I suppose the > reasons are similar to why javax.annotation.Priority only has > @Target({TYPE,PARAMETER}) (even if we tried to push other element types > :-(. > > M > > Dne 21.10.2017 v 16:22 John Ament napsal(a): > > Hey all > > > > > > Not sure where else to turn ? > > > > > > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks > > back the javax.annotation dependency that CDI declares due to a package > > collision with the built in JDK's javax.annotation package > > < > https://docs.oracle.com/javase/9/docs/api/javax/annotation/package-summary.html > >. > > The errors I get are due to missing javax/annotation/Priority. I'm > > wondering if anyone else has tried this, and if there's a clean work > around? > > > > > > John > > > > ------------------------------------------------------------------------ > > NOTICE: This e-mail message and any attachments may contain > > confidential, proprietary, and/or privileged information which should be > > treated accordingly. If you are not the intended recipient, please > > notify the sender immediately by return e-mail, delete this message, and > > destroy all physical and electronic copies. Thank you. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/ce6d5c6a/attachment-0001.html From mkouba at redhat.com Mon Oct 23 04:20:10 2017 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 23 Oct 2017 10:20:10 +0200 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: Message-ID: <9b29745e-9c00-5867-c5bc-5d1cb862cae4@redhat.com> Dne 23.10.2017 v 10:17 Antoine Sabot-Durand napsal(a): > I encountered the same type of collision with > java.transaction.InvalidTransactionException which is in the JDK and in > JTA. I remember sending this problem to jigsaw ML [1], but obviously > they didn't have time to do something or expect having Java EE spec do > the required stuff :-(. > Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will > be) to support jigsaw, we'll probably have to change packages names :-(. What packages do you have in mind? We don't "own" javax.annotation and we cannot introduce our own priority annotation... > > > Antoine > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008779.html > > > On Mon, Oct 23, 2017 at 9:51 AM Martin Kouba > wrote: > > For the record, the CDI API itself does not define a dependency on > javax.annotation at all. > > In fact, I'm wondering why @Priority is not part of JDK?? I suppose the > reasons are similar to why javax.annotation.Priority only has > @Target({TYPE,PARAMETER}) (even if we tried to push other element > types :-(. > > M > > Dne 21.10.2017 v 16:22 John Ament napsal(a): > > Hey all > > > > > > Not sure where else to turn ? > > > > > > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks > > back the javax.annotation dependency that CDI declares due to a > package > > collision with the built in JDK's javax.annotation package > > > . > > The errors I get are due to missing javax/annotation/Priority.? I'm > > wondering if anyone else has tried this, and if there's a clean > work around? > > > > > > John > > > > > ------------------------------------------------------------------------ > > NOTICE: This e-mail message and any attachments may contain > > confidential, proprietary, and/or privileged information which > should be > > treated accordingly. If you are not the intended recipient, please > > notify the sender immediately by return e-mail, delete this > message, and > > destroy all physical and electronic copies. Thank you. > > > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 > Senior Software Engineer > Red Hat, Czech Republic > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 Senior Software Engineer Red Hat, Czech Republic From asd at redhat.com Mon Oct 23 04:30:56 2017 From: asd at redhat.com (Antoine Sabot-Durand) Date: Mon, 23 Oct 2017 08:30:56 +0000 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: <9b29745e-9c00-5867-c5bc-5d1cb862cae4@redhat.com> References: <9b29745e-9c00-5867-c5bc-5d1cb862cae4@redhat.com> Message-ID: I was not talking about CDI specifically: the spec doesn't have package collision with JDK 9. I'm talking about the EE4J platform since there are collision with javax.annotation and probably a few other collision between jdk9 module and packages in EE4J specs. On Mon, Oct 23, 2017 at 10:20 AM Martin Kouba wrote: > Dne 23.10.2017 v 10:17 Antoine Sabot-Durand napsal(a): > > I encountered the same type of collision with > > java.transaction.InvalidTransactionException which is in the JDK and in > > JTA. I remember sending this problem to jigsaw ML [1], but obviously > > they didn't have time to do something or expect having Java EE spec do > > the required stuff :-(. > > Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will > > be) to support jigsaw, we'll probably have to change packages names :-(. > > What packages do you have in mind? We don't "own" javax.annotation and > we cannot introduce our own priority annotation... > > > > > > > Antoine > > > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008779.html > > > > > > On Mon, Oct 23, 2017 at 9:51 AM Martin Kouba > > wrote: > > > > For the record, the CDI API itself does not define a dependency on > > javax.annotation at all. > > > > In fact, I'm wondering why @Priority is not part of JDK?? I suppose > the > > reasons are similar to why javax.annotation.Priority only has > > @Target({TYPE,PARAMETER}) (even if we tried to push other element > > types :-(. > > > > M > > > > Dne 21.10.2017 v 16:22 John Ament napsal(a): > > > Hey all > > > > > > > > > Not sure where else to turn ? > > > > > > > > > I'm trying to start testing my apps on Java 9, I believe Java 9 > kicks > > > back the javax.annotation dependency that CDI declares due to a > > package > > > collision with the built in JDK's javax.annotation package > > > > > < > https://docs.oracle.com/javase/9/docs/api/javax/annotation/package-summary.html > >. > > > The errors I get are due to missing javax/annotation/Priority. > I'm > > > wondering if anyone else has tried this, and if there's a clean > > work around? > > > > > > > > > John > > > > > > > > > ------------------------------------------------------------------------ > > > NOTICE: This e-mail message and any attachments may contain > > > confidential, proprietary, and/or privileged information which > > should be > > > treated accordingly. If you are not the intended recipient, please > > > notify the sender immediately by return e-mail, delete this > > message, and > > > destroy all physical and electronic copies. Thank you. > > > > > > > > > _______________________________________________ > > > cdi-dev mailing list > > > cdi-dev at 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 > > Senior Software Engineer > > Red Hat, Czech Republic > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev at 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 > Senior Software Engineer > Red Hat, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/9457bbc7/attachment.html From rmannibucau at gmail.com Mon Oct 23 05:33:56 2017 From: rmannibucau at gmail.com (Romain Manni-Bucau) Date: Mon, 23 Oct 2017 11:33:56 +0200 Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: <9b29745e-9c00-5867-c5bc-5d1cb862cae4@redhat.com> Message-ID: Technically we can rewrite the loaded bytecode etc but this is ugly and unfair for end users, maybe we can request oracle to support "fragments" for packages (like in OSGi) to merge multiple jars in a single module? Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn 2017-10-23 10:30 GMT+02:00 Antoine Sabot-Durand : > I was not talking about CDI specifically: the spec doesn't have package > collision with JDK 9. I'm talking about the EE4J platform since there are > collision with javax.annotation and probably a few other collision between > jdk9 module and packages in EE4J specs. > > On Mon, Oct 23, 2017 at 10:20 AM Martin Kouba wrote: > >> Dne 23.10.2017 v 10:17 Antoine Sabot-Durand napsal(a): >> > I encountered the same type of collision with >> > java.transaction.InvalidTransactionException which is in the JDK and in >> > JTA. I remember sending this problem to jigsaw ML [1], but obviously >> > they didn't have time to do something or expect having Java EE spec do >> > the required stuff :-(. >> > Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will >> > be) to support jigsaw, we'll probably have to change packages names :-(. >> >> What packages do you have in mind? We don't "own" javax.annotation and >> we cannot introduce our own priority annotation... >> >> > >> > >> > Antoine >> > >> > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016- >> July/008779.html >> > >> > >> > On Mon, Oct 23, 2017 at 9:51 AM Martin Kouba > > > wrote: >> > >> > For the record, the CDI API itself does not define a dependency on >> > javax.annotation at all. >> > >> > In fact, I'm wondering why @Priority is not part of JDK?? I suppose >> the >> > reasons are similar to why javax.annotation.Priority only has >> > @Target({TYPE,PARAMETER}) (even if we tried to push other element >> > types :-(. >> > >> > M >> > >> > Dne 21.10.2017 v 16:22 John Ament napsal(a): >> > > Hey all >> > > >> > > >> > > Not sure where else to turn ? >> > > >> > > >> > > I'm trying to start testing my apps on Java 9, I believe Java 9 >> kicks >> > > back the javax.annotation dependency that CDI declares due to a >> > package >> > > collision with the built in JDK's javax.annotation package >> > > >> > > annotation/package-summary.html>. >> > > The errors I get are due to missing javax/annotation/Priority. >> I'm >> > > wondering if anyone else has tried this, and if there's a clean >> > work around? >> > > >> > > >> > > John >> > > >> > > >> > ----------------------------------------------------------- >> ------------- >> > > NOTICE: This e-mail message and any attachments may contain >> > > confidential, proprietary, and/or privileged information which >> > should be >> > > treated accordingly. If you are not the intended recipient, >> please >> > > notify the sender immediately by return e-mail, delete this >> > message, and >> > > destroy all physical and electronic copies. Thank you. >> > > >> > > >> > > _______________________________________________ >> > > cdi-dev mailing list >> > > cdi-dev at 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 >> > Senior Software Engineer >> > Red Hat, Czech Republic >> > _______________________________________________ >> > cdi-dev mailing list >> > cdi-dev at 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 >> Senior Software Engineer >> Red Hat, Czech Republic >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/95126534/attachment-0001.html From struberg at yahoo.de Mon Oct 23 11:06:27 2017 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 23 Oct 2017 15:06:27 +0000 (UTC) Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: References: Message-ID: <161293714.2588884.1508771187560@mail.yahoo.com> JAX-B has the same issue. I guess also a lot more 'EE' specs which got merged into SE but didn't get updated in time by the SE team. LieGrue,strub On Monday, 23 October 2017, 10:27:04 GMT+2, Antoine Sabot-Durand wrote: I encountered the same type of collision with java.transaction.InvalidTransactionException which is in the JDK and in JTA. I remember sending this problem to jigsaw ML [1], but obviously they didn't have time to do something or expect having Java EE spec do the required stuff :-(.Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will be) to support jigsaw, we'll probably have to change packages names :-(. Antoine [1]?http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008779.html On Mon, Oct 23, 2017 at 9:51 AM Martin Kouba wrote: For the record, the CDI API itself does not define a dependency on javax.annotation at all. In fact, I'm wondering why @Priority is not part of JDK?? I suppose the reasons are similar to why javax.annotation.Priority only has @Target({TYPE,PARAMETER}) (even if we tried to push other element types :-(. M Dne 21.10.2017 v 16:22 John Ament napsal(a): > Hey all > > > Not sure where else to turn ? > > > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks > back the javax.annotation dependency that CDI declares due to a package > collision with the built in JDK's javax.annotation package > . > The errors I get are due to missing javax/annotation/Priority.? I'm > wondering if anyone else has tried this, and if there's a clean work around? > > > John > > ------------------------------------------------------------------------ > NOTICE: This e-mail message and any attachments may contain > confidential, proprietary, and/or privileged information which should be > treated accordingly. If you are not the intended recipient, please > notify the sender immediately by return e-mail, delete this message, and > destroy all physical and electronic copies. Thank you. > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at 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 Senior Software Engineer Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev at 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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/2fdb706e/attachment.html From struberg at yahoo.de Mon Oct 23 11:10:56 2017 From: struberg at yahoo.de (Mark Struberg) Date: Mon, 23 Oct 2017 15:10:56 +0000 (UTC) Subject: [cdi-dev] Duplicate javax.annotation packages and Java 9 In-Reply-To: <9b29745e-9c00-5867-c5bc-5d1cb862cae4@redhat.com> References: <9b29745e-9c00-5867-c5bc-5d1cb862cae4@redhat.com> Message-ID: <1553078730.2596152.1508771456447@mail.yahoo.com> >> Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will >> be) to support jigsaw, we'll probably have to change packages names :-(. > > What packages do you have in mind? We don't "own" javax.annotation and > we cannot introduce our own priority annotation... Indeed we (CDI) do not own common-annotations. That was the reason why the JSR-250 working group release a MR for it which did contain the changes we needed in CDI. So from our side (EE) all was fine imo. It's just that the SE team didn't update the JDK to this official MR it seems. LieGrue,strub On Monday, 23 October 2017, 10:31:22 GMT+2, Martin Kouba wrote: Dne 23.10.2017 v 10:17 Antoine Sabot-Durand napsal(a): > I encountered the same type of collision with > java.transaction.InvalidTransactionException which is in the JDK and in > JTA. I remember sending this problem to jigsaw ML [1], but obviously > they didn't have time to do something or expect having Java EE spec do > the required stuff :-(. > Now that JDK9 is out, if we want EE4J 9 (or whatever it's version will > be) to support jigsaw, we'll probably have to change packages names :-(. What packages do you have in mind? We don't "own" javax.annotation and we cannot introduce our own priority annotation... > > > Antoine > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008779.html > > > On Mon, Oct 23, 2017 at 9:51 AM Martin Kouba > wrote: > >? ? For the record, the CDI API itself does not define a dependency on >? ? javax.annotation at all. > >? ? In fact, I'm wondering why @Priority is not part of JDK?? I suppose the >? ? reasons are similar to why javax.annotation.Priority only has >? ? @Target({TYPE,PARAMETER}) (even if we tried to push other element >? ? types :-(. > >? ? M > >? ? Dne 21.10.2017 v 16:22 John Ament napsal(a): >? ? ? > Hey all >? ? ? > >? ? ? > >? ? ? > Not sure where else to turn ? >? ? ? > >? ? ? > >? ? ? > I'm trying to start testing my apps on Java 9, I believe Java 9 kicks >? ? ? > back the javax.annotation dependency that CDI declares due to a >? ? package >? ? ? > collision with the built in JDK's javax.annotation package >? ? ? > >? ? . >? ? ? > The errors I get are due to missing javax/annotation/Priority.? I'm >? ? ? > wondering if anyone else has tried this, and if there's a clean >? ? work around? >? ? ? > >? ? ? > >? ? ? > John >? ? ? > >? ? ? > >? ? ------------------------------------------------------------------------ >? ? ? > NOTICE: This e-mail message and any attachments may contain >? ? ? > confidential, proprietary, and/or privileged information which >? ? should be >? ? ? > treated accordingly. If you are not the intended recipient, please >? ? ? > notify the sender immediately by return e-mail, delete this >? ? message, and >? ? ? > destroy all physical and electronic copies. Thank you. >? ? ? > >? ? ? > >? ? ? > _______________________________________________ >? ? ? > cdi-dev mailing list >? ? ? > cdi-dev at 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 >? ? Senior Software Engineer >? ? Red Hat, Czech Republic >? ? _______________________________________________ >? ? cdi-dev mailing list >? ? cdi-dev at 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 Senior Software Engineer Red Hat, Czech Republic _______________________________________________ cdi-dev mailing list cdi-dev at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20171023/ae099ab4/attachment-0001.html