[weld-issues] [JBoss JIRA] (CDITCK-621) WebService is not starting before it is injected into a Filter
Title: Message Title Matej Novotny closed an issue as Rejected Thanks for confirmation. Closing as rejected. CDI TCK / CDITCK-621 WebService is not starting before it is injected into a Filter Change By: Matej Novotny Status: Pull Request Sent Closed Resolution: Rejected Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-621) WebService is not starting before it is injected into a Filter
Title: Message Title Matej Novotny edited a comment on CDITCK-621 Re: WebService is not starting before it is injected into a Filter I understand what the fix test modification entails.What I am saying is that current deployment doesn't violate any specification from what I can tell.Therefore, it should work (and it does on WFLY though I am not familiar with it enough to say why). Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-621) WebService is not starting before it is injected into a Filter
Title: Message Title Matej Novotny commented on CDITCK-621 Re: WebService is not starting before it is injected into a Filter I understand what the fix entails. What I am saying is that current deployment doesn't violate any specification from what I can tell. Therefore, it should work (and it does on WFLY though I am not familiar with it enough to say why). Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-622) Backport fix for CDITCK-597 to 1.2 branch
Title: Message Title Matej Novotny updated CDITCK-622 CDI TCK / CDITCK-622 Backport fix for CDITCK-597 to 1.2 branch Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-622) Backport fix for CDITCK-597 to 1.2 branch
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #175 in GitHub CDI TCK / CDITCK-622 Backport fix for CDITCK-597 to 1.2 branch Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2496) org.jboss.weld.literal.BeforeDestroyedLiteral may fail to initialize with a security manager
Title: Message Title Matej Novotny commented on WELD-2496 Re: org.jboss.weld.literal.BeforeDestroyedLiteral may fail to initialize with a security manager Also note that we are only using BeforeDestroyedLiteral (as our own class) because of double CDI impl in WFLY where we cannot rely on CDI API 2.0 always being there. Otherwise, our code should be using CDI's BeforeDestroyed That being said, it's the underlying AnnotationLiteral causing this. While it should be fixed on CDI side, that will take certain (non-short) amount of time. So meanwhile, we should probably do what Martin suggested. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2494) WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used
Title: Message Title Matej Novotny updated an issue Weld / WELD-2494 WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1831 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2494) WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2494 WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2494) WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2494
WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used
Change By:
Matej Novotny
{{WeldResourceLoader}} is used to determine a class loader to load classes with for further processing. The code now tries to grab the TCCL and work primarily with that, using {{WeldResourceLoader.class.getClassLoader()}} as a fallback should TCCL be {{null}}.Now, if in SE and with bean discovery enabled, we by default use {{ForkJoinPool}}.JDK 8 and 9+ both have different results if you invoke {{Thread.currentThread().getContextClassLoader()}} and operate on a thread from {{ForkJoinPool}}. See [this JDK issue|https://bugs.openjdk.java.net/browse/JDK-8172726] for more info. In short, since JDK 9+, any thread from this pool has hard-set system CL as it's TCCL whereas in JDK 8 this was inherited from parent thread.Alas, system CL cannot load the classes we need, hence we get errors.The solution would be to implement either:* Implement a fallback behaviour, trying TCCL first, then using CL which loaded {{WeldResourceLoader}} . Alternatively, we can think of * Setting setting setting TCCL to null, just like it's done [in WFLY|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldExecutorServices.java#L75] . ** Can be done via wrapping {{Callable}}, first set TCCL to null, then {{call()}} and finally set TCCL back to previous value** *Preferable solution*
Add Comment
This
[weld-issues] [JBoss JIRA] (WELD-2495) Review Weld examples and enable them on JDK 10+
Title: Message Title Matej Novotny created an issue Weld / WELD-2495 Review Weld examples and enable them on JDK 10+ Issue Type: Enhancement Affects Versions: 3.0.4.Final Assignee: Unassigned Components: Examples Created: 15/May/18 6:19 AM Priority: Major Reporter: Matej Novotny We have many examples in numerous environments (EE with JSF, SE, Groovy, OSGi,...). A review should take place, purging unnecessary ones or possibly melding them together if that makes sense. Those which are too trivial or obsolete should be removed. As the examples are standalone, we need to also look into their dependencies and update them to be JDK 10+ ready. The goal is to have smaller set of examples, all of which can execute on JDK 8 and JDK 10+. We may also want to limit the amount of platforms we support in examples (GF, Jetty, etc). Whatever will be problematic on JDK 10, we probably won't push for now. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2494) WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used
Title: Message Title Matej Novotny created an issue Weld / WELD-2494 WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used Issue Type: Bug Affects Versions: 3.0.4.Final Assignee: Unassigned Created: 15/May/18 6:08 AM Priority: Major Reporter: Matej Novotny WeldResourceLoader is used to determine a class loader to load classes with for further processing. The code now tries to grab the TCCL and work primarily with that, using WeldResourceLoader.class.getClassLoader() as a fallback should TCCL be null. Now, if in SE and with bean discovery enabled, we by default use ForkJoinPool. JDK 8 and 9+ both have different results if you invoke Thread.currentThread().getContextClassLoader() and operate on a thread from ForkJoinPool. See this JDK issue for more info. In short, since JDK 9+, any thread from this pool has hard-set system CL as it's TCCL whereas in JDK 8 this was inherited from parent thread. Alas, system CL cannot load the classes we need, hence we get errors. The solution would be to implement a fallback behaviour, trying TCCL first, then using CL which loaded WeldResourceLoader. Alternatively, we can think of setting setting TCCL to null, just like it's done in WFLY. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2492) NPE in BeanIdentifierIndex.getIndex due to race condition
Title: Message Title Matej Novotny edited a comment on WELD-2492 Re: NPE in BeanIdentifierIndex.getIndex due to race condition [~buurmansven] thanks for more logging info. The PR still looks like it could help.As for upgrading...The proper way would be to update WFLY to Weld 3.0.4.Final which was released in the meantime (using the patch and the how-to described [in the end of the release article|http://weld.cdi-spec.org/news/2018/04/26/weld-304Final/]) and _then_ upgrade core to 3.0.5 snapshot.If you just bump core from 3.0.3.Final to 3.0.5-SNAPSHOT, _I think_ it won't work (there was an API update so core will expect to use a version of API which won't exist). EDIT: Actually, I just ran some of our tests with WFLY 12 with just core swapped to PR snapshot and they passed. But that might be just me not hitting the "right" parts of code. I would still recommend going through update to 3.0.4.Final. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2492) NPE in BeanIdentifierIndex.getIndex due to race condition
Title: Message Title Matej Novotny commented on WELD-2492 Re: NPE in BeanIdentifierIndex.getIndex due to race condition S Haster thanks for more logging info. The PR still looks like it could help. As for upgrading... The proper way would be to update WFLY to Weld 3.0.4.Final which was released in the meantime (using the patch and the how-to described in the end of the release article) and then upgrade core to 3.0.5 snapshot. If you just bump core from 3.0.3.Final to 3.0.5-SNAPSHOT, I think it won't work (there was an API update so core will expect to use a version of API which won't exist). Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-621) WebService is not starting before it is injected into a Filter
Title: Message Title Matej Novotny commented on CDITCK-621 Re: WebService is not starting before it is injected into a Filter You may be right. Alas, we have little to no control over that TCK and can hardly get it there. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2492) NPE in BeanIdentifierIndex.getIndex due to race condition
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #1829 in GitHub Weld / WELD-2492 NPE in BeanIdentifierIndex.getIndex due to race condition Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2250) WeldStartService failed to start: object is not an instance of declaring class
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #1827 in GitHub Weld / WELD-2250 WeldStartService failed to start: object is not an instance of declaring class Change By: Matej Novotny Status: Reopened Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2492) NPE in BeanIdentifierIndex.getIndex due to race condition
Title: Message Title Matej Novotny commented on WELD-2492 Re: NPE in BeanIdentifierIndex.getIndex due to race condition Hi S Haster, I have submitted a PR(link) which I think should address this however we have no such testsuite which would demonstrate this problem. Do you think you could verify it with yours? If you need, I can explain how to patch Weld version in your WFLY to that in the PR. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2492) NPE in BeanIdentifierIndex.getIndex due to race condition
Title: Message Title Matej Novotny updated an issue Weld / WELD-2492 NPE in BeanIdentifierIndex.getIndex due to race condition Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1829 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-615) Regenerate signature tests for CDI API 2.0
Title: Message Title Matej Novotny updated CDITCK-615 CDI TCK / CDITCK-615 Regenerate signature tests for CDI API 2.0 Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-615) Regenerate signature tests for CDI API 2.0
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-615 Regenerate signature tests for CDI API 2.0 Change By: Matej Novotny Fix Version/s: 2.1.0.Final Fix Version/s: 2.0.5.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-615) Regenerate signature tests for CDI API 2.0
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-615 Regenerate signature tests for CDI API 2.0 Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/164 , https://github.com/cdi-spec/cdi-tck/pull/173 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2493) Make Weld modular according to JPMS specs
Title: Message Title Matej Novotny commented on WELD-2493 Re: Make Weld modular according to JPMS specs ... according to JPMS specs as it will give a lot of advantages. Can't wait to hear of all those advantages. It sure wouldn't hurt listing them here Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-620) Annotated Type test fails depending on constructor ordering
Title: Message Title Matej Novotny updated CDITCK-620 Commits merged into both branches, 2.0 and master. Thanks for contribution! CDI TCK / CDITCK-620 Annotated Type test fails depending on constructor ordering Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-620) Annotated Type test fails depending on constructor ordering
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-620 Annotated Type test fails depending on constructor ordering Change By: Matej Novotny Fix Version/s: 2.1.0.Final Fix Version/s: 2.0.5.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-620) Annotated Type test fails depending on constructor ordering
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-620 Annotated Type test fails depending on constructor ordering Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/171 , https://github.com/cdi-spec/cdi-tck/pull/172 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2250) WeldStartService failed to start: object is not an instance of declaring class
Title: Message Title Matej Novotny updated an issue Weld / WELD-2250 WeldStartService failed to start: object is not an instance of declaring class Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1827 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2250) WeldStartService failed to start: object is not an instance of declaring class
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2250 WeldStartService failed to start: object is not an instance of declaring class Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2250) WeldStartService failed to start: object is not an instance of declaring class
Title: Message Title Matej Novotny edited a comment on WELD-2250 Re: WeldStartService failed to start: object is not an instance of declaring class - Not sure I fully understand this. Are we able to discern that we are dealing with an EAR scenario? Because that's probably the only case where this can happen. - - If yes, then perhaps we should modify the store to be able to differentiate the archive that it came from? - - Not sure if the full reflection isn't too expensive approach here? -Alright, after a discussion with Martin I see what he meant.+1 for reflection fallback Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2250) WeldStartService failed to start: object is not an instance of declaring class
Title: Message Title Matej Novotny commented on WELD-2250 Re: WeldStartService failed to start: object is not an instance of declaring class Not sure I fully understand this. Are we able to discern that we are dealing with an EAR scenario? Because that's probably the only case where this can happen. If yes, then perhaps we should modify the store to be able to differentiate the archive that it came from? Not sure if the full reflection isn't too expensive approach here? Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-617) Invalid test URL for interceptedBeanForEEComponentIsNullInInterceptor
Title: Message Title Matej Novotny updated CDITCK-617 Cherry-picked the PR to 2.0 branch as well, thanks for contribution! CDI TCK / CDITCK-617 Invalid test URL for interceptedBeanForEEComponentIsNullInInterceptor Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-612) AfterTypeDiscoveryTest does not test List#remove(Object)
Title: Message Title Matej Novotny updated CDITCK-612 CDI TCK / CDITCK-612 AfterTypeDiscoveryTest does not test List#remove(Object) Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-617) Invalid test URL for interceptedBeanForEEComponentIsNullInInterceptor
Title: Message Title Matej Novotny commented on CDITCK-617 Re: Invalid test URL for interceptedBeanForEEComponentIsNullInInterceptor Thanks for the report, the tests should indeed be aligned to use the same syntax. I will cherry pick your PR to 2.0 as well (no need to expand exclude list as I don't think the test in necessarily "wrong"). Also, if I understand correctly, it is up to the server if it wants to collapse '//' into a single '/' or if it wants to treat it as a different resource. Got any source for this? Not disputing it, just casually interested. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-617) Invalid test URL for interceptedBeanForEEComponentIsNullInInterceptor
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-617 Invalid test URL for interceptedBeanForEEComponentIsNullInInterceptor Change By: Matej Novotny Fix Version/s: 2.1.0.Final Fix Version/s: 2.0.5.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-616) Literal classes missing in archive of PassivationIdTest
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-616 Literal classes missing in archive of PassivationIdTest Change By: Matej Novotny Fix Version/s: 2.1.0.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-616) Literal classes missing in archive of PassivationIdTest
Title: Message Title Matej Novotny updated CDITCK-616 CDI TCK / CDITCK-616 Literal classes missing in archive of PassivationIdTest Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-618) Need to expose @Remove-annotated method to EJB interface
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-618 Need to expose @Remove-annotated method to EJB interface Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/168 , https://github.com/cdi-spec/cdi-tck/pull/169 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-618) Need to expose @Remove-annotated method to EJB interface
Title: Message Title Matej Novotny updated CDITCK-618 Thanks for the PRs. CDI TCK / CDITCK-618 Need to expose @Remove-annotated method to EJB interface Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-619) Fix cdi-tck-ext-lib manifest
Title: Message Title Matej Novotny updated CDITCK-619 Cherry-picked the PR to master as well. Resolving issue. CDI TCK / CDITCK-619 Fix cdi-tck-ext-lib manifest Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2491) Update patching profiles for Weld 3
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2491 Update patching profiles for Weld 3 Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2491) Update patching profiles for Weld 3
Title: Message Title Matej Novotny created an issue Weld / WELD-2491 Update patching profiles for Weld 3 Issue Type: Enhancement Affects Versions: 3.0.4.Final Assignee: Unassigned Created: 24/Apr/18 6:48 AM Priority: Major Reporter: Matej Novotny In core/jboss-as/pom.xml we have some profiles allowing us to download,patch and generate patch file for WFLY. Those are now outdated as they target WFLY 11 and need bumping to WFLY 12. Furthermore, we should create a new patch file for WFLY 12 here. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2465) Switch to JBoss version of commons annotation 1.3
Title: Message Title Matej Novotny updated an issue Weld / WELD-2465 Switch to JBoss version of commons annotation 1.3 Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1797, https://github.com/weld/ core/pull/1823, https://github.com/weld/ api/pull/75 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-618) Need to expose @Remove-annotated method to EJB interface
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-618 Need to expose @Remove-annotated method to EJB interface Change By: Matej Novotny Fix Version/s: 2.0.5.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-618) Need to expose @Remove-annotated method to EJB interface
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-618 Need to expose @Remove-annotated method to EJB interface Change By: Matej Novotny Fix Version/s: 2.1.0.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2482) Globally selected alternatives with the same priority do not result in ambiguous dependency
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #1822 in GitHub Weld / WELD-2482 Globally selected alternatives with the same priority do not result in ambiguous dependency Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2482) Globally selected alternatives with the same priority do not result in ambiguous dependency
Title: Message Title Matej Novotny updated an issue Weld / WELD-2482 Globally selected alternatives with the same priority do not result in ambiguous dependency Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1822 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2484) Add sensible toString() to org.jboss.weld.bootstrap.events.configurator.InjectionPointConfiguratorImpl.ImmutableInjectionPoint
Title: Message Title
Matej Novotny commented on WELD-2484
Re: Add sensible toString() to org.jboss.weld.bootstrap.events.configurator.InjectionPointConfiguratorImpl.ImmutableInjectionPoint
The changes should encompass other configurators as well, e.g. AT and OM. The rest is already created or delegated to our internal constructs which have toString() defined. The only exception is ProducerConfigurator where I can think of no sensible {[toString()}} so I will just leave that one out.
Add Comment
This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2484) Add sensible toString() to org.jboss.weld.bootstrap.events.configurator.InjectionPointConfiguratorImpl.ImmutableInjectionPoint
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2484 Add sensible toString() to org.jboss.weld.bootstrap.events.configurator.InjectionPointConfiguratorImpl.ImmutableInjectionPoint Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2484) Add sensible toString() to org.jboss.weld.bootstrap.events.configurator.InjectionPointConfiguratorImpl.ImmutableInjectionPoint
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #1817 in GitHub Weld / WELD-2484 Add sensible toString() to org.jboss.weld.bootstrap.events.configurator.InjectionPointConfiguratorImpl.ImmutableInjectionPoint Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2463) ProbeObserversTest relies on a specific java.lang.annotation.Annotation.toString() implementation
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2463 ProbeObserversTest relies on a specific java.lang.annotation.Annotation.toString() implementation Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2463) ProbeObserversTest relies on a specific java.lang.annotation.Annotation.toString() implementation
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #1816 in GitHub Weld / WELD-2463 ProbeObserversTest relies on a specific java.lang.annotation.Annotation.toString() implementation Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2488) JDK 9/10 testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2488 JDK 9/10 testing Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1795 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2465) Switch to JBoss version of commons annotation 1.3
Title: Message Title Matej Novotny updated WELD-2465 Weld / WELD-2465 Switch to JBoss version of commons annotation 1.3 Change By: Matej Novotny Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-616) Literal classes missing in archive of PassivationIdTest
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #166 in GitHub CDI TCK / CDITCK-616 Literal classes missing in archive of PassivationIdTest Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-616) Literal classes missing in archive of PassivationIdTest
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-616 Literal classes missing in archive of PassivationIdTest Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/165, https://github.com/cdi-spec/cdi-tck/pull/166 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-614) ConfiguratorAndSetMethodTest can result in unsatisfied dependency
Title: Message Title Matej Novotny updated CDITCK-614 CDI TCK / CDITCK-614 ConfiguratorAndSetMethodTest can result in unsatisfied dependency Change By: Matej Novotny Status: Pull Request Sent Resolved Fix Version/s: 2.1.0.Final Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2488) JDK 9/10 testing
Title: Message Title Matej Novotny resolved as Done PR executors are now running on both Java versions and passing (test deps have been updated/altered). Release jobs have been switched over to JDK 10 + 8 so beginning with Weld 3.0.4.Final we will have that kind of feedback as well. We now have additional CI job running integration tests with security manager on JDK 8 + 10. Most of Weld 3 CI jobs are now matrix jobs with JDK 10 and 8 setups so we have continuous feedback on this. We cannot yet run with denied illegal access as there are errors coming from outside weld ATM (when running in container). Weld / WELD-2488 JDK 9/10 testing Change By: Matej Novotny Status: Open Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849)
[weld-issues] [JBoss JIRA] (WELD-2487) Update JBoss Classfilewriter to 1.2.2.Final
Title: Message Title Matej Novotny updated an issue Weld / WELD-2487 Update JBoss Classfilewriter to 1.2.2.Final Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1815 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2490) Weld uses JDK's internal BCEL classes
Title: Message Title Matej Novotny updated an issue Weld / WELD-2490 Weld uses JDK's internal BCEL classes Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1815 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1815 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-616) Literal classes missing in archive of PassivationIdTest
Title: Message Title Matej Novotny commented on CDITCK-616 Re: Literal classes missing in archive of PassivationIdTest Thanks for the report, the test is adding whole test package, which means BeanManagerTest gets in as well and that one requires those literals. I will either add the literals to deployment or cull the deployment so that only truly required test classes are added instead of whole package. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-616) Literal classes missing in archive of PassivationIdTest
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-616 Literal classes missing in archive of PassivationIdTest Change By: Matej Novotny Fix Version/s: 2.0.5.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2490) Weld uses JDK's internal BCEL classes
Title: Message Title Matej Novotny updated an issue Weld / WELD-2490 Weld uses JDK's internal BCEL classes Change By: Matej Novotny Fix Version/s: 3.0.4.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2490) Weld uses JDK's internal BCEL classes
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2490 Weld uses JDK's internal BCEL classes Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9/10 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
Our main problem is {{ClassFileUtils}} which use CL to invoke {{defineClass()}}. In order to do this, you need to {{setAccessible()}} those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} to crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will work as it did up to this point* We cannot be sure when/if/whether Oracle guys wake up one morning and say "Hey, we are removing those {{Unsafe}} methods!" (case of {{Unsafe.defineClass()}} in EA JDK 11)2. We can use {{MethodHandles.Lookup}}, namely {{privateLookupIn()}} to define new classes ([branch with simple impl draft|https://github.com/manovotn/core/tree/methodHandles]) * This is the intended way, but it has limitations:** {{Lookup.defineClass()}} has no way to specify {{ProtectionDomain}} which is something we currently do, we enrich it, so that newly added classes always have "getDeclaredFields()" rights** In WFLY, proxies built from JDK classes ({{Map}},...) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{MethodHandle.Lookup}} from WFLY and if we define those classes on our CL, we have a memory leak*** This also entails change to our API where WFLY hands us over _some_ {{MethodHandles.Lookup}} which we can work with** In WFLY, static modules w/o Weld dependency use (top level) CL of the deployment's module*** Same problem as above* This approach implies the need for *multi-release JAR* of at least {{core-impl}} artifact ([branch with draft|https://github.com/manovotn/core/tree/multiRelease]) ** Easy to do, nuisance to maintain and test (and bothersome with the current state of IDE support for those JDKs) Another illegal access issues is usage of JDK's internal BCEL classes.* We will replace this with optional Maven dependency* Hence this functionality will only work if user adds that dependency* This only hinders reporting error lines in bytecodeThere might be some changes required in classfilewriter itself which is to be discovered (likely related to https://github.com/jbossas/jboss-classfilewriter/issues/14)* Newest version uses {{Unsafe.defineClass()}} so we need to update to that one for the time being (1.2.2.Final)Another part of this issue is to ensure we are continuously testing on JDK 9 (or 10, doesn't matter) as well as JDK 8.* Releases will be tested on JDK 8 + latest fully released JDK (9/10/11)* All PRs will be tested on JDK 8 + latest fully released JDK (9/10/11)** In the future with illegal access _denied_Goal is to be able to execute all our tests with JDK 9+ with {{--illegal-access=deny}} switch.
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9/10 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
Our main problem is {{ClassFileUtils}} which use CL to invoke {{defineClass()}}. In order to do this, you need to {{setAccessible()}} those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} to crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will work as it did up to this point* We cannot be sure when/if/whether Oracle guys wake up one morning and say "Hey, we are removing those {{Unsafe}} methods!" (case of {{Unsafe.defineClass()}} in EA JDK 11) * There is also a fair possibility this won't work on obscure Java distributions such as IBM JDK 2. We can use {{MethodHandles.Lookup}}, namely {{privateLookupIn()}} to define new classes* This is the intended way, but it has limitations:** {{Lookup.defineClass()}} has no way to specify {{ProtectionDomain}} which is something we currently do, we enrich it, so that newly added classes always have "getDeclaredFields()" rights** In WFLY, proxies built from JDK classes ({{Map}},...) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{MethodHandle.Lookup}} from WFLY and if we define those classes on our CL, we have a memory leak*** This also entails change to our API where WFLY hands us over _some_ {{MethodHandles.Lookup}} which we can work with** In WFLY, static modules w/o Weld dependency use (top level) CL of the deployment's module*** Same problem as above* This approach implies the need for *multi-release JAR* of at least {{core-impl}} artifact** Easy to do, nuisance to maintain and test (and bothersome with the current state of IDE support for those JDKs) Another illegal access issues is usage of JDK's internal BCEL classes. * We will replace this with optional Maven dependency* Hence this functionality will only work if user adds that dependency* This only hinders reporting error lines in bytecode There might be some changes required in classfilewriter itself which is to be discovered (likely related to https://github.com/jbossas/jboss-classfilewriter/issues/14)* Newest version uses {{Unsafe.defineClass()}} so we need to update to that one for the time being (1.2.2.Final)Another part of this issue is to ensure we are continuously testing on JDK 9 (or 10, doesn't matter) as well as JDK 8.* Releases will be tested on JDK 8 + latest fully released JDK (9/10/11)* All PRs will be tested on JDK 8 + latest fully released JDK (9/10/11)** In the future with illegal access _denied_Goal is to be able to execute all our tests with JDK 9+ with {{--illegal-access=deny}} switch.
[weld-issues] [JBoss JIRA] (WELD-2490) Weld uses JDK's internal BCEL classes
Title: Message Title Matej Novotny created an issue Weld / WELD-2490 Weld uses JDK's internal BCEL classes Issue Type: Sub-task Affects Versions: 3.0.3.Final Assignee: Unassigned Created: 13/Apr/18 3:30 AM Priority: Major Reporter: Matej Novotny Weld's org.jboss.weld.util.reflection.Formats uses JDK's internal BCEL classes. This yield illegal access on JDK 9+. The only purpose of this class is to provide more information about line on which a problem occurred in bytecode. And even with this, the functionality is limited. Best way to handle this will be adding an optional dependency on BCEL classes as a Maven artifact. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9/10 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
Our main problem is {{ClassFileUtils}} which use CL to invoke {{defineClass()}}. In order to do this, you need to {{setAccessible()}} those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} to crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will work as it did up to this point* We cannot be sure when/if/whether Oracle guys wake up one morning and say "Hey, we are removing those {{Unsafe}} methods!" (case of {{Unsafe.defineClass()}} in EA JDK 11) * There is also a fair possibility this won't work on obscure Java distributions such as IBM JDK 2. We can use {{MethodHandles.Lookup}}, namely {{privateLookupIn()}} to define new classes* This is the intended way, but it has limitations:** {{Lookup.defineClass()}} has no way to specify {{ProtectionDomain}} which is something we currently do, we enrich it, so that newly added classes always have "getDeclaredFields()" rights** In WFLY, proxies built from JDK classes ({{Map}},...) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{MethodHandle.Lookup}} from WFLY and if we define those classes on our CL, we have a memory leak*** This also entails change to our API where WFLY hands us over _some_ {{MethodHandles.Lookup}} which we can work with** In WFLY, static modules w/o Weld dependency use (top level) CL of the deployment's module*** Same problem as above* This approach implies the need for *multi-release JAR* of at least {{core-impl}} artifact** Easy to do, nuisance to maintain and test (and bothersome with the current state of IDE support for those JDKs) There might be some changes required in classfilewriter itself which is to be discovered (likely related to https://github.com/jbossas/jboss-classfilewriter/issues/14)* Newest version uses {{Unsafe.defineClass()}} so we need to update to that one for the time being (1.2.2.Final)Another part of this issue is to ensure we are continuously testing on JDK 9 (or 10, doesn't matter) as well as JDK 8.* Releases will be tested on JDK 8 + latest fully released JDK (9/10/11)* All PRs will be tested on JDK 8 + latest fully released JDK (9/10/11)** In the future with illegal access _denied_Goal is to be able to execute all our tests with JDK 9+ with {{--illegal-access=deny}} switch.
[weld-issues] [JBoss JIRA] (WELD-2488) JDK 9/10 testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2488 JDK 9/10 testing Change By: Matej Novotny Labels: jdk10 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2487) Update JBoss Classfilewriter to 1.2.2.Final
Title: Message Title Matej Novotny updated an issue Weld / WELD-2487 Update JBoss Classfilewriter to 1.2.2.Final Change By: Matej Novotny Component/s: Testing Infrastructure (Mocks and Harness Integration) Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2367) JDK9 Reference To Internal APIs
Title: Message Title Matej Novotny closed an issue as Duplicate Issue Closing this issue, we will cover this within WELD-2460. Weld / WELD-2367 JDK9 Reference To Internal APIs Change By: Matej Novotny Status: Open Closed Resolution: Duplicate Issue Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2488) JDK 9/10 testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2488 JDK 9/10 testing Change By: Matej Novotny Fix Version/s: 3.0.4.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2488) JDK 9/10 testing
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2488 JDK 9/10 testing Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2488) JDK 9/10 testing
Title: Message Title Matej Novotny created an issue Weld / WELD-2488 JDK 9/10 testing Issue Type: Sub-task Affects Versions: 3.0.3.Final Assignee: Unassigned Created: 12/Apr/18 10:50 AM Priority: Major Reporter: Matej Novotny Make sure Weld is able to run our tests and TCK tests in container (with WFLY) and standalone. [This issue does not need to result in a PR directly] Namely we need to: Have all release jobs for Weld 3 in a matrix config for JDK 8 and 10 Have working PR executors for JDK 8 and 10 10 may be limited right now as spotbugs and other stuff may not work Update/align test dependencies to work on JDK 10 Possibly execute on JDK 10 with --illegal-access=deny Servlet integration is not a priority here but should get a separate review later on.
[weld-issues] [JBoss JIRA] (WELD-2487) Update JBoss Classfilewriter to 1.2.2.Final
Title: Message Title Matej Novotny created an issue Weld / WELD-2487 Update JBoss Classfilewriter to 1.2.2.Final Issue Type: Sub-task Affects Versions: 3.0.3.Final Assignee: Unassigned Components: Testing Infrastructure (Mocks and Harness Integration) Created: 12/Apr/18 10:45 AM Priority: Major Reporter: Matej Novotny Update classfilewriter to 1.2.2.Final, that's the lowest version capable of dealing with JDK 10 and illegal access (via Unsafe). Note that we need to do this even for compilation (plus some modules override version, watch out for that). Add Comment
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2487) Update JBoss Classfilewriter to 1.2.2.Final
Title: Message Title Matej Novotny updated an issue Weld / WELD-2487 Update JBoss Classfilewriter to 1.2.2.Final Change By: Matej Novotny Labels: jdk10 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2487) Update JBoss Classfilewriter to 1.2.2.Final
Title: Message Title Matej Novotny updated an issue Weld / WELD-2487 Update JBoss Classfilewriter to 1.2.2.Final Change By: Matej Novotny Fix Version/s: 3.0.4.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Fix Version/s: 3.0.4.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2487) Update JBoss Classfilewriter to 1.2.2.Final
Title: Message Title Matej Novotny assigned an issue to Matej Novotny Weld / WELD-2487 Update JBoss Classfilewriter to 1.2.2.Final Change By: Matej Novotny Assignee: Matej Novotny Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Labels: jdk10 jdk9 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Summary: JDK 9 /10 - reflection usage, multirelease jar, testing Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9 - reflection usage, multirelease jar, testing
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2460
JDK 9 - reflection usage, multirelease jar, testing
Change By:
Matej Novotny
We need to inspect and rework our calls to JDK internal libs - with JDK 9 this Our main problem is permitted but throws warnings in logs {{ClassFileUtils}} which use CL to invoke {{defineClass()}} . In JDK 10 order to do this is , you need to be forbidden and {{ Handles setAccessible() }} anr/or those methods which is a no-go for JDK 9+.There are two approaches that we can take:1. Use {{Unsafe}} needs to be used. Once done, crack open the CL's methods and keep the code as it is* This is a "safe" way in that we know all will likely need to java a multirelease JARs work as the new solution won't it did up to this point* We cannot be available sure when/if/whether Oracle guys wake up one morning and say "Hey, we are removing those {{Unsafe}} methods!" (case of {{Unsafe.defineClass()}} in EA JDK 8. 11) Note that it does not matter whether you 2. We can use classpath or module path {{MethodHandles . Lookup}}, namely {{privateLookupIn()}} to define new classes One such case of our reflection usage * This is the intended way we create proxies by calling , but it has limitations:** {{ ClassLoader Lookup .defineClass()}} has no way to specify {{ProtectionDomain}} which is something we currently do, we enrich it, so that newly added classes always have "getDeclaredFields ( protected method on CL ) in " rights** In WFLY, proxies built from JDK classes ( {{ ClassFileUtils Map }} , . This could instead be done via either ..) use (top level) CL of the deployment's module*** Hence on undeploy those proxies are tossed away (no leaks)*** We cannot (easily) get such {{ Unsafe MethodHandle.Lookup }} or from WFLY and if we define those classes on our CL, we have a memory leak*** This also entails change to our API where WFLY hands us over _some_ {{ MethodHandles. Lookup}} . which we can work with ** In WFLY, static modules w/o Weld dependency use (top level) CL of the deployment's module *** Same problem as above* This approach implies the need for *multi-release JAR* of at least {{core-impl}} artifact** Easy to do, nuisance to maintain and test (and bothersome with the current state of IDE support for those JDKs) There might be some changes required in classfilewriter itself which is to be discovered (likely related to https://github.com/jbossas/jboss-classfilewriter/issues/14) * Newest version uses {{Unsafe.defineClass()}} so we need to update to that one for the time being (1.2.2.Final) Another part of this issue is to ensure we are continuously testing on JDK 9 (or 10, doesn't matter) as well as JDK 8. * Releases will be tested on JDK 8 + latest fully released JDK (9/10/11) * All PRs will be tested on JDK 8 + latest fully released JDK (9/10/11)** In the future with illegal access _denied_ Goal is to be able to execute all our tests with JDK 9 without any WARN messages related to + with {{-- illegal -
[weld-issues] [JBoss JIRA] (WELD-2460) JDK 9/10 - reflection usage, multirelease jar, testing
Title: Message Title Matej Novotny updated an issue Weld / WELD-2460 JDK 9/10 - reflection usage, multirelease jar, testing Change By: Matej Novotny Affects Version/s: 2.4.6.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2463) ProbeObserversTest relies on a specific java.lang.annotation.Annotation.toString() implementation
Title: Message Title Matej Novotny commented on WELD-2463 Re: ProbeObserversTest relies on a specific java.lang.annotation.Annotation.toString() implementation Partial (hot)fix contained in this PR. It only modifies the toString() so that it passes the test. It would be better to fix this for all invocations of Annotation.toString() Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2486) Weld docs - wrong listener class of WeldTerminalListener
Title: Message Title Matej Novotny updated an issue Weld / WELD-2486 Weld docs - wrong listener class of WeldTerminalListener Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1813 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2486) Weld docs - wrong listener class of WeldTerminalListener
Title: Message Title
Matej Novotny updated an issue
Weld / WELD-2486
Weld docs - wrong listener class of WeldTerminalListener
Change By:
Matej Novotny
In Weld 3, the {{listener-class}} of {{WeldTerminalListener}} changed (as part of WELD-2305).This is not reflected in our [documentation|http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/# _the_numberguess_example_in_apache_tomcat_or_jetty weld-servlet ].
Add Comment
This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2486) Weld docs - wrong listener class of WeldTerminalListener
Title: Message Title Matej Novotny created an issue Weld / WELD-2486 Weld docs - wrong listener class of WeldTerminalListener Issue Type: Bug Affects Versions: 3.0.3.Final Assignee: Unassigned Components: Documentation Created: 06/Apr/18 2:34 AM Priority: Major Reporter: Matej Novotny In Weld 3, the listener-class of WeldTerminalListener changed (as part of WELD-2305). This is not reflected in our documentation. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2476) java.nio.file.ProviderMismatchException when using application-scope-injected java.nio.Path
Title: Message Title Matej Novotny commented on WELD-2476 Re: java.nio.file.ProviderMismatchException when using application-scope-injected java.nio.Path Correct? Wow! That is unexpected. Like Martin said, this is defined behaviour if you read the spec. To counter the surprise, look at it this way - in the class hierarchy, if you focus on implementation types, those can oftentimes classify as unproxyable types. It can be due to final methods, constructors and so on This would ultimately mean, that the proxy cannot be created at all because some type you do not even own (maybe it comes from another 3rd party library) is unproxyable. I'd say that is far more unfortunate than the current design. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-614) ConfiguratorAndSetMethodTest can result in unsatisfied dependency
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-614 ConfiguratorAndSetMethodTest can result in unsatisfied dependency Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/162 , https://github.com/cdi-spec/cdi-tck/pull/163 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-614) ConfiguratorAndSetMethodTest can result in unsatisfied dependency
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #162 in GitHub CDI TCK / CDITCK-614 ConfiguratorAndSetMethodTest can result in unsatisfied dependency Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-614) ConfiguratorAndSetMethodTest can result in unsatisfied dependency
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-614 ConfiguratorAndSetMethodTest can result in unsatisfied dependency Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/162 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-614) ConfiguratorAndSetMethodTest can result in unsatisfied dependency
Title: Message Title Matej Novotny created an issue CDI TCK / CDITCK-614 ConfiguratorAndSetMethodTest can result in unsatisfied dependency Issue Type: Bug Affects Versions: 2.0.4.Final Assignee: Matej Novotny Created: 03/Apr/18 7:35 AM Fix Versions: 2.0.5.Final Priority: Major Reporter: Matej Novotny ConfiguratorAndSetMethodTest was already reworked but there is still a failure possible. Given certain ordering of observer method invocation (unspecified in spec) in an extension, the result can be an IP which expects @Default Box and an actual bean @Any Box which has had it's @Default qualifier removed. This blows up with unsatisfied dependency. The fix should go to both branches, 2.0.x and 2.1 and is as simple as making sure both, @Any and @Default are in place. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2479) List#remove(Object) does not work for lists returned by AfterTypeDiscovery
Title: Message Title Matej Novotny updated an issue Weld / WELD-2479 List#remove(Object) does not work for lists returned by AfterTypeDiscovery Change By: Matej Novotny Git Pull Request: https://github.com/weld/core/pull/1808 , https://github.com/weld/core/pull/1810 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2479) List#remove(Object) does not work for lists returned by AfterTypeDiscovery
Title: Message Title Matej Novotny updated an issue Weld / WELD-2479 List#remove(Object) does not work for lists returned by AfterTypeDiscovery Change By: Matej Novotny Fix Version/s: 2.4.8.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2479) List#remove(Object) does not work for lists returned by AfterTypeDiscovery
Title: Message Title Matej Novotny updated an issue Weld / WELD-2479 List#remove(Object) does not work for lists returned by AfterTypeDiscovery Change By: Matej Novotny Affects Version/s: 2.4.7.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-612) AfterTypeDiscoveryTest does not test List#remove(Object)
Title: Message Title Matej Novotny commented on CDITCK-612 Re: AfterTypeDiscoveryTest does not test List#remove(Object) Martin Kouba The PR for this issue covers most mass-operation methods alongside remove(). Let me know if you are missing any other crucial method(s). Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2479) List#remove(Object) does not work for lists returned by AfterTypeDiscovery
Title: Message Title Issue was automatically transitioned when Matej Novotny created pull request #1808 in GitHub Weld / WELD-2479 List#remove(Object) does not work for lists returned by AfterTypeDiscovery Change By: Matej Novotny Status: Open Pull Request Sent Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-612) AfterTypeDiscoveryTest does not test List#remove(Object)
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-612 AfterTypeDiscoveryTest does not test List#remove(Object) Change By: Matej Novotny Git Pull Request: https://github.com/cdi-spec/cdi-tck/pull/161 Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-612) AfterTypeDiscoveryTest does not test List#remove(Object)
Title: Message Title Matej Novotny updated an issue CDI TCK / CDITCK-612 AfterTypeDiscoveryTest does not test List#remove(Object) Change By: Matej Novotny Fix Version/s: 2.1.0.Final Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2478) Weld SE throws NPE when trying to intercept a method called by constructor
Title: Message Title Matej Novotny commented on WELD-2478 Re: Weld SE throws NPE when trying to intercept a method called by constructor Thanks for report and reproducer. We'll be sure to look into this soon, from the first glance, this looks very similar to reported WELD-2473. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
