[weld-issues] [JBoss JIRA] (WELD-2416) Memory behaviour of of javax.enterprise.inject.Instance.iterator().next vs. of javax.enterprise.inject.Instance.get() in Weld 1.1.18 vs. Weld 2.3.5
Title: Message Title
Antoine Sabot-Durand edited a comment on WELD-2416
Re: Memory behaviour of of javax.enterprise.inject.Instance.iterator().next vs. of javax.enterprise.inject.Instance.get() in Weld 1.1.18 vs. Weld 2.3.5
Nowhere in the CDI spec it is said that bean instances retrieved from {{Instance.get()}} and from iterating with {{Instance.iterator()}} should be treated differently regarding their destruction. In other words, it's normal that {{Instance.get()}} and {{Instance.iterator().next()}} behave the same. So your trick is exploiting a bug in Weld 1.1Weld 2.3 is behaving correctly according to CDI 1.2 spec. You're using {{Instance}} to request instances for dependent beans. [Section 6.4.2 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#dependent_destruction] reads:{quote}Dependent objects of a contextual instance are destroyed when {{Contextual.destroy()}} calls {{CreationalContext.release()}}, as defined in The {{CreationalContext}} interface.Additionally, the container must ensure that:* all dependent objects of a non-contextual instance of a bean or other Java EE component class are destroyed when the instance is destroyed by the container,{quote}We are in this case. The CDI container doesn't guarantee that all instances will be destroyed with the destruction of injecting servlet. So don't expect it to happen during your servlet life. You have to use {{Instance.destroy()}} method to explicitly cleanup your dependent instances.Now, why don't you experience memory leak when {{CDIBean2}} is injected directly and not thru {{Instance}}?Probably because Weld use an optimisation allowed by the spec (end of section 6.4.2):bq. Finally, the container is permitted to destroy any {{@Dependent}} scoped contextual instance at any time if the instance is no longer referenced by the application (excluding weak, soft and phantom references).But as you see it's not guarantee: Weld is doing you a favour here.So to comply to CDI code spec , your example should be modified like this:{code:java}@WebServlet("/Servlet")public class Servlet extends HttpServlet { private static final long serialVersionUID = 1L; @Inject private Instance cdi; /** * @see HttpServlet#service(HttpServletRequest request, HttpServletResponse response) */ protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {CDIInterface myInterface = cdi.get(); response.getWriter().write("Here " + Servlet.class.getName() + " - " + myInterface.sayHello());cdi.destroy(myInterface); }}public interface CDIInterface { public abstract String sayHello();}@Defaultpublic class CDIBean implements CDIInterface{ @Inject private Instance bean2; public String sayHello() {CDIBean2 myBean2 = bean2.get(); return "Here " + CDIBean.class.getName() + " - " + myBean2.get().testHello();bean2.destroy(myBean2); }}public class CDIBean2 { public String testHello() { return "Here " + CDIBean2.class.getName(); }}{code}
[weld-issues] [JBoss JIRA] (WELD-2416) Memory behaviour of of javax.enterprise.inject.Instance.iterator().next vs. of javax.enterprise.inject.Instance.get() in Weld 1.1.18 vs. Weld 2.3.5
Title: Message Title
Antoine Sabot-Durand edited a comment on WELD-2416
Re: Memory behaviour of of javax.enterprise.inject.Instance.iterator().next vs. of javax.enterprise.inject.Instance.get() in Weld 1.1.18 vs. Weld 2.3.5
Nowhere in the CDI spec it is said that bean instances retrieved from {{Instance.get()}} and from iterating with {{Instance.iterator()}} should be treated differently regarding their destruction. In other words, it's normal that {{Instance.get()}} and {{Instance.iterator().next()}} behave the same. So your trick is exploiting a bug in Weld 1.1Weld 2.3 is behaving correctly according to CDI 1.2 spec. You're using {{Instance}} to request instances for dependent beans. [Section 6.4.2 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#dependent_destruction] reads:{quote}Dependent objects of a contextual instance are destroyed when {{Contextual.destroy()}} calls {{CreationalContext.release()}}, as defined in The {{CreationalContext}} interface.Additionally, the container must ensure that:* all dependent objects of a non-contextual instance of a bean or other Java EE component class are destroyed when the instance is destroyed by the container,{quote}We are in this case. The CDI container doesn't guarantee that all instances will be destroyed with the destruction of injecting servlet. So don't expect it to happen during your servlet life. You have to use {{Instance.destroy()}} method to explicitly cleanup your dependent instances.Now, why don't you experience memory leak when {{CDIBean2}} is injected directly and not thru {{Instance}}?Probably because Weld use an optimisation allowed by the spec (end of section 6.4.2):bq. Finally, the container is permitted to destroy any {{@Dependent}} scoped contextual instance at any time if the instance is no longer referenced by the application (excluding weak, soft and phantom references).But as you see it's not guarantee: Weld is doing you a favour here.So to comply CDI code, your example should be ;edified modified like this:{code:java}@WebServlet("/Servlet")public class Servlet extends HttpServlet { private static final long serialVersionUID = 1L; @Inject private Instance cdi; /** * @see HttpServlet#service(HttpServletRequest request, HttpServletResponse response) */ protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {CDIInterface myInterface = cdi.get(); response.getWriter().write("Here " + Servlet.class.getName() + " - " + myInterface.sayHello());cdi.destroy(myInterface); }}public interface CDIInterface { public abstract String sayHello();}@Defaultpublic class CDIBean implements CDIInterface{ @Inject private Instance bean2; public String sayHello() {CDIBean2 myBean2 = bean2.get(); return "Here " + CDIBean.class.getName() + " - " + myBean2.get().testHello();bean2.destroy(myBean2); }}public class CDIBean2 { public String testHello() { return "Here " + CDIBean2.class.getName(); }}{code}
[weld-issues] [JBoss JIRA] (WELD-2416) Memory behaviour of of javax.enterprise.inject.Instance.iterator().next vs. of javax.enterprise.inject.Instance.get() in Weld 1.1.18 vs. Weld 2.3.5
Title: Message Title
Antoine Sabot-Durand commented on WELD-2416
Re: Memory behaviour of of javax.enterprise.inject.Instance.iterator().next vs. of javax.enterprise.inject.Instance.get() in Weld 1.1.18 vs. Weld 2.3.5
Nowhere in the CDI spec it is said that bean instances retrieved from Instance.get() and from iterating with Instance.iterator() should be treated differently regarding their destruction. In other words, it's normal that Instance.get() and Instance.iterator().next() behave the same. So your trick is exploiting a bug in Weld 1.1 Weld 2.3 is behaving correctly according to CDI 1.2 spec. You're using Instance to request instances for dependent beans. Section 6.4.2 of the spec reads:
Dependent objects of a contextual instance are destroyed when Contextual.destroy() calls CreationalContext.release(), as defined in The CreationalContext interface.
Additionally, the container must ensure that:
all dependent objects of a non-contextual instance of a bean or other Java EE component class are destroyed when the instance is destroyed by the container,
We are in this case. The CDI container doesn't guarantee that all instances will be destroyed with the destruction of injecting servlet. So don't expect it to happen during your servlet life. You have to use Instance.destroy() method to explicitly cleanup your dependent instances. Now, why don't you experience memory leak when CDIBean2 is injected directly and not thru Instance? Probably because Weld use an optimisation allowed by the spec (end of section 6.4.2):
Finally, the container is permitted to destroy any @Dependent scoped contextual instance at any time if the instance is no longer referenced by the application (excluding weak, soft and phantom references).
But as you see it's not guarantee: Weld is doing you a favour here. So to comply CDI code, your example should be ;edified like this:
@WebServlet("/Servlet")
public class Servlet extends HttpServlet {
private static final long serialVersionUID = 1L;
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Antoine Sabot-Durand commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Mark StrubergI mentioned CDI 1.1, why are you talking about 1.0 ? The test is in CDI 1.1 TCK validated in 2013 by the CDI 1.1 EG and released to the JCP: https://github.com/cdi-spec/cdi-tck/blob/1.1/impl/src/main/java/org/jboss/cdi/tck/tests/implementation/simple/lifecycle/unproxyable/UnproxyableManagedBeanTest.java The Weld Ticket you mention is the middle of the story, the origin is CDITCK-263, closed 5 years ago with no comment. This test was enhanced in 2015 with other use case thru CDITCK-508, again no comment. I'm sorry you missed these occasion to discuss your point, but they are closed now and CDI 2.0 is released. You're assuming the original intent of the CDI 1.0 EG because of this test that was decided wrong later. I prefer to assume intent of the original EG to have these failing at runtime by reading the spec and the section related to UnproxyableResolutionException (http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#contextual_reference). Again Spec supersede TCK and that's what happened with CDITCK-263. What you propose is interesting but non portable because the following behaviour was already adopted in RI, supported in vendors application servers and changing it could create backward compatibility issues. Again, I suggest that you propose a mention of this non portable behaviour in the spec. May I also suggest that you avoid putting exclamation marks and explaining people that they are wrong, It really doesn't help discussion. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Antoine Sabot-Durand commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Mark StrubergThis test has been in the TCK for 5 years now. It has been accepted as deliverable by the JCP in CDI 1.1 / 1.2MR and 2.0. Weld passes this test for CDI compliance, so it's possible to implement. The validity to his test doesn't have to be discussed here : you should expose your point to the future CDI 2.x EG. Spec is not designed from the TCK but the other way around, so, please, fill a ticket in CDI JIRA to ask for a clarification or a change in the spec for this non portable optimisation. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Antoine Sabot-Durand commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Totally agree with Tomas Remes first comment, spec states in 3.11 A bean type must be proxyable if an injection point resolves to a bean: It implies that if there's no injection point, the bean type doesn't have to be proxyable. Tests exist for non proxyable bean detected at deployment, you can check all of them in the version of the spec with assertion: http://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#unproxyable UnproxyableManagedBeanTest relates to 6.5.4 where UnproxyableResolutionException is clearly stated: http://docs.jboss.org/cdi/spec/2.0/cdi-spec-with-assertions.html#contextual_reference So for me this test is consistent with the spec. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-580) illegal TCK test for indirect specialization
Title: Message Title Antoine Sabot-Durand commented on CDITCK-580 Re: illegal TCK test for indirect specialization Agree that spec should clarify this point. I created CDI-703 for this. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Antoine Sabot-Durand commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Agree with Tomas Remes and Martin Kouba. and having a reproducer EAR will help us to focus on the actual problem. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2273) An abstract decorator class that extends a managed bean causes NPE
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1669 in GitHub Weld / WELD-2273 An abstract decorator class that extends a managed bean causes NPE Change By: Antoine Sabot-Durand Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2331) Misleading error message when Extension observer method is (wrongly) static
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1606 in GitHub Weld / WELD-2331 Misleading error message when Extension observer method is (wrongly) static Change By: Antoine Sabot-Durand Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2337) OSGI bundle exports need to export modules
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1604 in GitHub Weld / WELD-2337 OSGI bundle exports need to export modules Change By: Antoine Sabot-Durand Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2335) InterceptionFactory used on interface causes NPE
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1599 in GitHub Weld / WELD-2335 InterceptionFactory used on interface causes NPE Change By: Antoine Sabot-Durand Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2335) InterceptionFactory used on interface causes NPE
Title: Message Title Antoine Sabot-Durand commented on WELD-2335 Re: InterceptionFactory used on interface causes NPE I went for a graceful failure since the use case doesn't make sense: using InterceptionFactoryto produce the instance means that we'll only be able to configure interceptor bindings on an AnnotatedType
. As interceptors binding are not inherited from Interface, it seems normal that we don't support this. More broadly I think we should only accept instance of the exact same type than the one used in InterceptorFactory type parameter: it would be too complex to support and not compliant with Interceptor Specification. Wdyt ? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2338) Revise the check of valid injection points for an extension observer method with observed type java.lang.Object and a qualifier other than @Any
Title: Message Title Antoine Sabot-Durand commented on WELD-2338 Re: Revise the check of valid injection points for an extension observer method with observed type java.lang.Object and a qualifier other than @Any agree Martin Kouba Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2338) Revise the check of valid injection points for an extension observer method with observed type java.lang.Object and a qualifier other than @Any
Title: Message Title Antoine Sabot-Durand commented on WELD-2338 Re: Revise the check of valid injection points for an extension observer method with observed type java.lang.Object and a qualifier other than @Any +1, but shouldn't the title be "... qualifier different than @Any or @Default" ? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2335) InterceptionFactory used on interface causes NPE
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-2335
InterceptionFactory used on interface causes NPE
Change By:
Antoine Sabot-Durand
I tried using interception factory on a produced {{ Map List }} (using the {{ Map List }} interface instead of actual underlying {{ HashMap ArrayList }}).This causes an NPE to be thrown - we should be handling this is some more pleasant manner.Here is a [link to my branch with test/reproducer for this|https://github.com/manovotn/core/blob/weld_2335/tests-arquillian/src/test/java/org/jboss/weld/tests/interceptors/producer/Producer.java#L94]. Runnable with {{-Dtest=InterceptionFactoryTest#testListAdd}}.
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2302) Wro4j maven plugin does not work with JDK 9
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1593 in GitHub Weld / WELD-2302 Wro4j maven plugin does not work with JDK 9 Change By: Antoine Sabot-Durand Status: Coding In Progress Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2302) Wro4j maven plugin does not work with JDK 9
Title: Message Title Antoine Sabot-Durand started work on WELD-2302 Change By: Antoine Sabot-Durand Status: Open Coding In Progress Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2302) Wro4j maven plugin does not work with JDK 9
Title: Message Title Antoine Sabot-Durand assigned an issue to Antoine Sabot-Durand Weld / WELD-2302 Wro4j maven plugin does not work with JDK 9 Change By: Antoine Sabot-Durand Assignee: Antoine Sabot-Durand Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2264) Implement BeforeBeanDiscovery.configureQualifier() and configureInterceptorBinding() [CDI-642]
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1524 in GitHub Weld / WELD-2264 Implement BeforeBeanDiscovery.configureQualifier() and configureInterceptorBinding() [CDI-642] Change By: Antoine Sabot-Durand Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-554) Assertions C for "11.5.1 - BeforeBeanDiscovery event" - (CDI-642) is wrong
Title: Message Title
Antoine Sabot-Durand edited a comment on CDITCK-554
Re: Assertions C for "11.5.1 - BeforeBeanDiscovery event" - (CDI-642) is wrong
Test class injects:{code:java} @InjectInstance instance;{code} when it should inject:{code:java} @Inject @AnyInstance instance;{code} to allow programmatic lookup in test method
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-554) Assertions C for "11.5.1 - BeforeBeanDiscovery event" - (CDI-642) is wrong
Title: Message Title Antoine Sabot-Durand commented on CDITCK-554 Re: Assertions C for "11.5.1 - BeforeBeanDiscovery event" - (CDI-642) is wrong Test class injects: @Inject Instance instance; when it should inject: @Inject @Any Instance instance; Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-554) Assertions C for "11.5.1 - BeforeBeanDiscovery event" - (CDI-642) is wrong
Title: Message Title Antoine Sabot-Durand created an issue CDI TCK / CDITCK-554 Assertions C for "11.5.1 - BeforeBeanDiscovery event" - (CDI-642) is wrong Issue Type: Bug Assignee: Tomas Remes Created: 13/Dec/16 6:37 AM Priority: Major Reporter: Antoine Sabot-Durand Test testQualifierAddition in org.jboss.cdi.tck.tests.extensions.configurators.annotatedTypeConfigurator.beforeBeanDiscovery.AnnotatedTypeConfiguratorInBBDTest fails. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (WELD-2264) Implement BeforeBeanDiscovery.configureQualifier() and configureInterceptorBinding() [CDI-642]
Title: Message Title Antoine Sabot-Durand assigned an issue to Antoine Sabot-Durand Weld / WELD-2264 Implement BeforeBeanDiscovery.configureQualifier() and configureInterceptorBinding() [CDI-642] Change By: Antoine Sabot-Durand Assignee: Antoine Sabot-Durand Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization And you probably misunderstood me, I am not diminishing/closing this issue at all. Quite the opposite, I think its relevant but I want to fully understand the extent to which it affects Weld. I got the impression this is just a first of many Java 9 issues to show up with modularization. Well sorry for the misunderstanding. As you said solving this point is only the very first step on the complex Jigsaw path. Question like these pop up: 1) Is this the only "package clash" we have in Weld? How do we easily determine this? Good question, I'll ask on openjdk ml if we have an easy way to find out 2) What do we do in Weld 2.4, we probably want ppl to run it on Java 9 (and if we don't want it, EAP will want it) but this change is not backward compatible to put it there. I think we should sy that 2.4 cannot be used with JDK9 or in module path. As solving this very fitst point breaks compatibility we should at least go for a 2.5 if we ant to support this in Weld 2.x 3) Then there is Maven and its module-path. Why can't we determine between CP and MP - Java 9 operates on both (e.g. automatic modules versus unnamed module) I guess it's because they didn't want to add extra info on dependencies to indicate if they could be used in Module path or not. Class Path support is seen as a legacy support so Maven team didn't want to add structural info for the backward compatibility sake IMO. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization Maven compiler plugin doesn't support mixing module-path and class-path. Just remove module-info.java file and it will revert to classpath. Because supporting Java 9 is not the same as turning whole project into Java 9 modules? The idea around J9 is that you should be able to use existing non-modular projects by simply putting them on classpath and it would work as it used to before. Turning the whole project into Java 9 modules is not the topic of this issue. My point is "I understand we can discuss about the interest of making Weld modular (by providing explicit module-info.java files) but I don't understand that we decide to close the discussion before it begins because of the location 3 classes". FYI I opened a similar issue to rest-easy (RESTEASY-1480) that was solved in a few days. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization The reason being that this way Maven will force the creation of so called automatic modules out of Weld dependencies It's not maven which create this it's the java compiler because maven called it witht the jar on the module path. Also, I cannot really say if this would be a blocker if we were to modularize Weld (which I unsure we aim to, at least any time soon TM), but it might prove to be so. It will. You can double check by going to the openJDK mailing list as I have done and ask about package splitting. Honnestly I don't understand why the question of supporting modularity is asked, when support Java EE 8 servers will be released, Java 9 will be every where and not supporting it might be seen as being legacy. Fixing this problem is mainly deciding to move three classes in a new sub-package. It may break backward compatibility, hat's why we should introduce it in a major release: Weld 3.0.0 Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2253) BeforeBeanDiscovery and AfterTypeDiscovery new addAnnotatedType methods don't work
Title: Message Title
Antoine Sabot-Durand created an issue
Weld / WELD-2253
BeforeBeanDiscovery and AfterTypeDiscovery new addAnnotatedType methods don't work
Issue Type:
Bug
Affects Versions:
3.0.0.Alpha17
Assignee:
Unassigned
Created:
01/Nov/16 8:21 AM
Priority:
Major
Reporter:
Antoine Sabot-Durand
Adding this code in extension doesn't create a MetricRegistry bean
public void addMetricRegistryAnnotatedType(@Observes AfterTypeDiscovery atd) {
atd.addAnnotatedType(MetricRegistry.class.getName(),MetricRegistry.class)
.add(ApplicationScoped.Literal.INSTANCE);
}
Same if done in BeforeBeanDiscovery observer Of course doing it the old way works
[weld-issues] [JBoss JIRA] (WELD-2239) Switch to the Commons annotation MR 1.3
Title: Message Title Antoine Sabot-Durand created an issue Weld / WELD-2239 Switch to the Commons annotation MR 1.3 Issue Type: Bug Assignee: Unassigned Created: 04/Oct/16 8:52 AM Priority: Major Reporter: Antoine Sabot-Durand Commons annotations 1.3 (with @Priority targeted to parameters) is now available. Weld 3.0 should switch to this new version in next beta. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
[weld-issues] [JBoss JIRA] (WELD-2233) CDI Implicit bean archive not supported in Java SE
Title: Message Title Antoine Sabot-Durand closed an issue as Won't Fix Weld / WELD-2233 CDI Implicit bean archive not supported in Java SE Change By: Antoine Sabot-Durand Status: Open Closed Resolution: Won't Fix Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2233) CDI Implicit bean archive not supported in Java SE
Title: Message Title Antoine Sabot-Durand commented on WELD-2233 Re: CDI Implicit bean archive not supported in Java SE Sorry, I missed section 15.1 in the spec... So it's not Weld related and is more a clarification needed between core and SE in the spec. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2233) CDI Implicit bean archive not supported in Java SE
Title: Message Title Antoine Sabot-Durand created an issue Weld / WELD-2233 CDI Implicit bean archive not supported in Java SE Issue Type: Bug Affects Versions: 3.0.0.Alpha17 Assignee: Unassigned Components: Java SE Support Created: 15/Sep/16 6:40 AM Priority: Major Reporter: Antoine Sabot-Durand When using an implicit bean archive (without beans.xml but with classes having bean defining annotation), those beans are not discovered. This is either a bug in Weld or in CDI spec, since implicit bean archive is defined in core part of the spec and should work in SE as in EE. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization Well iff you use your module on the classpath, it works (for backward compatibility), the problem arise when you're using the module path. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization Sorry Matej Novotny, I just made the tes and asked one expert on Jigsaw (Rémi Forax) who confirmed, on module path package splitting is forbidden whatever is the export status of the package. This is done for security reason mainly. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization weld-servlet-core depends on weld-environment-common so you'll have dependencies on both module. Regarding your second remark I really don't think that it will work when module-info.java will be added. I can't find the reference now, but my understanding is that Jigsaw doesn't allow 2 modules sharing the same package no matter their visibility. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Issue was automatically transitioned when Antoine Sabot-Durand created pull request #1410 in GitHub Weld / WELD-2189 weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization Change By: Antoine Sabot-Durand Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-2189
weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Change By:
Antoine Sabot-Durand
{{weld-environment-common}} and {{weld-servlet-core}} artifacts share the {{org.jboss.weld.environment}} package making their jigsaw modularization impossible since Java 9 checks for package unicity in across modules
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand commented on WELD-2189 Re: weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization This can be solved by emptying the package in one of the artifact (for instance by moving AbstractContainer, Container and ContainerContext in a sub package) Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-2189
weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Change By:
Antoine Sabot-Durand
{{weld-environment-common}} and {{weld-servlet-core}} artifacts share the {{org.jboss.weld.environment}} package making their jigsaw modularization impossible since Java 9 checks for package unicity in modules
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2189) weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization
Title: Message Title Antoine Sabot-Durand created an issue Weld / WELD-2189 weld-environment-common and weld-servlet-core share common package preventing Jigsaw modularization Issue Type: Bug Affects Versions: 3.0.0.Alpha16 Assignee: Unassigned Components: Servlet Container Support Created: 03/Jul/16 4:29 PM Priority: Major Reporter: Antoine Sabot-Durand weld-environment-common and weld-servlet-core share the org.jboss.weld.environment package making their jigsaw modularization impossible since Java 9 checks for package unicity in modules Add Comment
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle with JDK9
Title: Message Title Antoine Sabot-Durand commented on WELD-2149 Re: Weld build fails on checkstyle with JDK9 Matej Novotny, There are a lot of issues with building Weld on JDK9. That's the reason why I started by cutting this big task in small pieces. There are issues with the Format helpers (bcel has visibility restriction in JDK 9) Arquillian, the Groovy compiler and perhaps others. Some of them have to be resolved on our side, some on others (Groovy team, Arquillian ?), some may be linked to JDK 9 bug or non finished features. This bug was the first and obviously a problem on our side since tools.jar will never be available in the final JDK 9 release. Others needs exploration and action on our side or ticket raising to other team (Arquillian, Groovy, open JDK). Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle with JDK9
Title: Message Title Antoine Sabot-Durand commented on WELD-2149 Re: Weld build fails on checkstyle with JDK9 Sent the 4 PRs. Build no longer fails on checkstyle on tools.jar:1.4.2 on JDK9 and still work on JDK8. It now fails on tests but that's for others JIRA Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle with JDK9
Title: Message Title Antoine Sabot-Durand assigned an issue to Antoine Sabot-Durand Weld / WELD-2149 Weld build fails on checkstyle with JDK9 Change By: Antoine Sabot-Durand Assignee: Antoine Sabot-Durand Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle with JDK9
Title: Message Title Antoine Sabot-Durand updated an issue Weld / WELD-2149 Weld build fails on checkstyle with JDK9 Change By: Antoine Sabot-Durand Summary: Weld build fails on checkstyle on with JDK9 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle on JDK9
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-2149
Weld build fails on checkstyle on JDK9
Change By:
Antoine Sabot-Durand
As described in WELD-1847, building Weld on JDK9 fails on Chekstyle Maven plugin. Even when upgrading to the latest version the build fails with the following error:{ { code:none} Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle (check-style) on project weld-core-parent: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6.0 at specified path /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/../lib/tools.jar {code } }
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1847) Weld SE build fail on JDK 9
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-1847
Weld SE build fail on JDK 9
Change By:
Antoine Sabot-Durand
Fails on Weld SE (Core):{ { code:none} 1. ERROR in /home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/groovy/org/jboss/weld/environment/se/test/groovy/interceptors/MyBean.groovy (at line 0) /** ^The type java.lang.Class cannot be resolved. It is indirectly referenced from required .class files {code} After removing this test I am get the same error on: {code:none} /home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/provider/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/beandiscovery/stereotype/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/singleton/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/inheritance/Plant.java/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/beandiscovery/alternatives/AlternativeTree.java/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/interceptors/AggregatingInterceptor.java {code } } After last one I am stopped to test it. So it is can be even more.After excluding SE module another modules builds successfully. P.S. Also building is not working with maven checkstyle plugin.
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
[weld-issues] [JBoss JIRA] (WELD-1847) Weld SE build fail on JDK 9
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-1847
Weld SE build fail on JDK 9
Change By:
Antoine Sabot-Durand
Fails on Weld SE (Core): {{ 1. ERROR in /home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/groovy/org/jboss/weld/environment/se/test/groovy/interceptors/MyBean.groovy (at line 0) /** ^The type java.lang.Class cannot be resolved. It is indirectly referenced from required .class filesAfter removing this test I am get the same error on:/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/provider/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/beandiscovery/stereotype/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/singleton/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/inheritance/Plant.java/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/beandiscovery/alternatives/AlternativeTree.java/home/kgaevski/Documents/github/weld-core-parent/environments/se/core/src/test/java/org/jboss/weld/environment/se/test/interceptors/AggregatingInterceptor.java }} After last one I am stopped to test it. So it is can be even more.After excluding SE module another modules builds successfully. P.S. Also building is not working with maven checkstyle plugin.
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle on JDK9
Title: Message Title Antoine Sabot-Durand commented on WELD-2149 Re: Weld build fails on checkstyle on JDK9 tools.jar is a system dependency in checkstyle (defined in weld-parent)and weld-common-build-config. In Jdk 9 most classes included in tools.jar are now part of the JDK in dedicated modules. Due to dependencies multiple Weld projects must be upgraded to correct this issues: weld-common-build-config weld-api which depend on the previous one weld-parent also depend on weld-common-build-config and define version for checkstyle maven plugin and checkstyle runtime weld-core using weld-parent Others ? Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle on JDK9
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-2149
Weld build fails on checkstyle on JDK9
Change By:
Antoine Sabot-Durand
As described in WELD-1847, building Weld on JDK9 fails on Chekstyle Maven plugin. Even when upgrading to the latest version the build fails with the following error:{{Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle (check-style) on project weld-core-parent: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:checkstyle failed: Plugin org.apache.maven.plugins:maven-checkstyle-plugin:2.17 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6.0 at specified path /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/../lib/tools.jar}}
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle on JDK9
Title: Message Title Antoine Sabot-Durand updated an issue Weld / WELD-2149 Weld build fails on checkstyle on JDK9 Change By: Antoine Sabot-Durand Affects Version/s: 3.0.0.Alpha16 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle on JDK9
Title: Message Title Antoine Sabot-Durand updated an issue Weld / WELD-2149 Weld build fails on checkstyle on JDK9 Change By: Antoine Sabot-Durand Component/s: Infrastructure Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2149) Weld build fails on checkstyle on JDK9
Title: Message Title Antoine Sabot-Durand updated an issue Weld / WELD-2149 Weld build fails on checkstyle on JDK9 Change By: Antoine Sabot-Durand Summary: Verify Weld build fails on checkstyle on JDK9 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2108) Observer resolution fails if payload is a lambda expression
Title: Message Title Antoine Sabot-Durand commented on WELD-2108 Re: Observer resolution fails if payload is a lambda _expression_ If we have good test in TCK and Weld, adding the types derived from Event should work (OWB pass the TCK with this approach). Regarding BeanManager.fire() I had a discussion with Jozef Hartinger about deprecation of this method in favor of a method returning an Event. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2108) Observer resolution fails if payload is a lambda expression
Title: Message Title Antoine Sabot-Durand commented on WELD-2108 Re: Observer resolution fails if payload is a lambda _expression_ Let's begin with the ticket related to event type : CDI-583 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2108) Observer resolution fails if payload is a lambda expression
Title: Message Title Antoine Sabot-Durand created an issue Weld / WELD-2108 Observer resolution fails if payload is a lambda _expression_ Issue Type: Bug Affects Versions: 3.0.0.Alpha15, 2.3.2.Final Assignee: Unassigned Components: Events Created: 11/Feb/16 9:48 AM Priority: Major Reporter: Antoine Sabot-Durand When using a lambda in an event payload. Parameter types are lost when resolving observers. For instance: @Inject EventstringSupplierEvent;
[weld-issues] [JBoss JIRA] (WELD-2108) Observer resolution fails if payload is a lambda expression
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-2108
Observer resolution fails if payload is a lambda _expression_
Change By:
Antoine Sabot-Durand
When using a lambda in an event payload. Parameter types are lost when resolving observers.For instance:{code}@InjectEvent stringSupplierEvent; ... Supplier stringSupplier = () -> "Hello world"; stringSupplierEvent.fire(stringSupplier);{code}will triggers an observer of for {{Supplier}} but not an observer of for {{Supplier}}
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2108) Observer resolution fails if payload is a lambda expression
Title: Message Title Antoine Sabot-Durand commented on WELD-2108 Re: Observer resolution fails if payload is a lambda _expression_ It's a well known JDK 8 limitation: http://jdk8-dev.openjdk.java.narkive.com/bSPiKxap/jdk-8-lambda-reflection-issues Other projects or specs had to find some trick to solve this issue: https://java.net/jira/browse/WEBSOCKET_SPEC-226 We should consider adding the declared type of the event (at the injection point) to the set of event type for observer resolution. Right now we only analyze the payload object to get its type closure, which doesn't work for lambdas since Class#getGenericInterfaces() and Class#getGenericSuperclass() always return raw types. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1855) Circular generics reference in type definition are not correctly resolved
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-1855
Circular generics reference in type definition are not correctly resolved
Change By:
Antoine Sabot-Durand
Steps to Reproduce:
I'veatestinthefollowingrepohttps://github.com/antoinesd/CDI-Sandbox/tree/typeassignClonetherepoandlaunch ` {{ mvncleantest-Pweld-2.2 ` }} or ` {{ mvncleantest-Pweld-1.1 ` }} torunthetest.
Add Comment
This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1855) Circular generics reference in type definition are not correctly resolved
Title: Message Title
Antoine Sabot-Durand created an issue
Weld / WELD-1855
Circular generics reference in type definition are not correctly resolved
Issue Type:
Bug
Affects Versions:
2.2.9.Final, 1.1.28.Final
Assignee:
Unassigned
Components:
Resolution
Created:
30/Jan/15 10:49 AM
Priority:
Major
Reporter:
Antoine Sabot-Durand
If I have these classes
public abstract class MasterDboT {}
public abstract class DetailDbo {}
[weld-issues] [JBoss JIRA] (WELD-1855) Circular generics reference in type definition are not correctly resolved
Title: Message Title
Antoine Sabot-Durand updated an issue
Weld / WELD-1855
Circular generics reference in type definition are not correctly resolved
Change By:
Antoine Sabot-Durand
Steps to Reproduce:
I'veatestinthefollowingrepohttps://github.com/antoinesd/CDI-Sandbox /tree/typeassign Clonetherepo ,switchtobranch{{typeassign}} andlaunch{{mvncleantest-Pweld-2.2}}or{{mvncleantest-Pweld-1.1}}torunthetest.
Add Comment
This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1855) Circular generics reference in type definition are not correctly resolved
Title: Message Title Antoine Sabot-Durand commented on WELD-1855 Re: Circular generics reference in type definition are not correctly resolved So Jozef Hartinger could you quote the rules in 5.2.4 who prevent this resolution, because I'm missing something here. Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-438) InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
Title: Message Title Antoine Sabot-Durand commented on CDITCK-438 Re: InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml This test is not about Interceptor but about wrong meta-data injection in interceptor. Injection of InterceptorCream in InterceptorField (instead of InterceptorInterceptorField is what is tested. And it does the job. The spec is rather clear regarding the fact that Interceptors are bean in implicit terms here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#what_classes_are_beans or in more explicit way in this the recent clarification : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations It is said nowhere that unused interceptor or decorators should be ignored by the container. Now that can be discussed but doesn't seem very interesting IMO. Anyway this ticket is off topic and misleading. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-438) InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
Title: Message Title
Antoine Sabot-Durand edited a comment on CDITCK-438
Re: InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
ThistestisnotaboutInterceptor activation butaboutwrongmeta-datainjectionininterceptor.Injectionof{{InterceptorCream}}in{{InterceptorField}}(insteadof{{InterceptorInterceptorField}} ) iswhatistested.Anditdoesthejob bythrowinfadefinitionexceptionasstatedhere:http://docs . jboss.org/cdi/spec/1.2/cdi-spec.html#bean_metadata. ThespecisratherclearregardingthefactthatInterceptorsarebeaninimplicittermshere:http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#what_classes_are_beansorinmoreexplicitwayinthistherecentclarification:http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotationsItissaidnowherethatunusedinterceptorordecoratorsshouldbeignoredbythecontainer.Nowthatcanbediscussedbutdoesn'tseemveryinterestingIMO.Anywaythisticketisofftopicandmisleading.
Add Comment
This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-438) InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
Title: Message Title
Antoine Sabot-Durand edited a comment on CDITCK-438
Re: InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
ThistestisnotaboutInterceptoractivationbutaboutwrongmeta-datainjectionininterceptor.Injectionof{{InterceptorCream}}in{{InterceptorField}}(insteadof{{InterceptorInterceptorField}})iswhatistested.Anditdoesthejobbythrowinfadefinitionexceptionasstatedhere:http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_metadata.ThespecisratherclearregardingthefactthatInterceptorsarebeaninimplicittermshere:http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#what_classes_are_beansorinmoreexplicitwayinthistherecentclarification:http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations Itissaidnowherethatunusedinterceptorordecoratorsshouldbeignoredbythecontainer. Now thatcanbediscussedbutdoesn ,asit ' tseem snot veryinteresting IMO.Anywaythisticketisofftopic totestunusedInterceptorsorDecoractors and misleading astheexpectedbehaviourwillbethesamewiththeseactivated,wecouldadd{{@Priority}}tothefaultyInterceptors/Decoratorswithoutchangingthenatureofwhatistested .
Add Comment
This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-349) Incorrect assertion regarding assignabillity of parameterized types
Antoine Sabot-Durand commented on CDITCK-349 Incorrect assertion regarding assignabillity of parameterized types CDI-389 is solved we cancelled CDI-85 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1577) Adding a JDK8 build for Weld
Antoine Sabot-Durand created WELD-1577 Adding a JDK8 build for Weld Issue Type: Task Assignee: Jozef Hartinger Created: 20/Dec/13 9:52 AM Description: We should add a build on JDK8 to make sure that build on java 8 and that tests run without braking on it. Project: Weld Priority: Major Reporter: Antoine Sabot-Durand 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1552) InjectionPoint resolution not conform to CDI 1.1 spec
Antoine Sabot-Durand
created WELD-1552
InjectionPoint resolution not conform to CDI 1.1 spec
Issue Type:
Bug
Affects Versions:
2.1.0.CR1, 2.0.2.Final
Assignee:
Jozef Hartinger
Components:
Built-in beans
Created:
12/Nov/13 9:29 AM
Description:
If I define a producer with an injection point for buil-in bean InjectionPoint like this :
@Produces
@Named
public OAuthSession getCurrentSession(InjectionPoint ip) {…}
And I call {currentSession} in JSF or JSP page, I get an exception
WELD-09: Dynamic lookup of Implicit Bean [javax.enterprise.inject.spi.InjectionPoint] with qualifiers [@Default] is not supported
thrown by InjectionPointBean.getInjectionPoint() method.
In Weld 1.x I had a null value injected in my InjectionPoint.
According to the CDI 1.1 spec : "6.5.3. Contextual reference for a bean", the correct behavior should be the Weld 1.x one : returning a null InjectionPoint.
Environment:
Tested on Wildfly 8.0 Alpha 1 and Glassfish 4.0
Project:
Weld
Priority:
Major
Reporter:
Antoine Sabot-Durand
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
