[weld-issues] [JBoss JIRA] (WELD-2635) Weld core doesn't properly detect Jetty server for GWT 2.8/2.9 test environment
Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list -- weld-issues@lists.jboss.org To unsubscribe send an email to weld-issues-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[weld-issues] [JBoss JIRA] (WELD-2633) Servlet test JsfTest has to be temporarily disabled due to missing Maven dep
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2633 Servlet test JsfTest has to be temporarily disabled due to missing Maven dep Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/2008 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2633) Servlet test JsfTest has to be temporarily disabled due to missing Maven dep
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2633 Servlet test JsfTest has to be temporarily disabled due to missing Maven dep Change By: Matěj Novotný Affects Version/s: 4.0.0.Alpha4 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2633) Servlet test JsfTest has to be temporarily disabled due to missing Maven dep
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2633 Servlet test JsfTest has to be temporarily disabled due to missing Maven dep Change By: Matěj Novotný Fix Version/s: 4.0.0.Alpha4 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2619) Refactor ClassFileUtils to operate better on JDK 11+
Title: Message Title Issue was automatically transitioned when Matěj Novotný created pull request #11 in GitHub Weld / WELD-2619 Refactor ClassFileUtils to operate better on JDK 11+ Change By: Matěj Novotný Status: Open Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2634) Surefire plugin update causes weird testsuite behaviour
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2634 Surefire plugin update causes weird testsuite behaviour Change By: Matěj Novotný Fix Version/s: 3.1.6.Final Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2634) Surefire plugin update causes weird testsuite behaviour
. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2634) Surefire plugin update causes weird testsuite behaviour
Title: Message Title Matěj Novotný assigned an issue to Matěj Novotný Weld / WELD-2634 Surefire plugin update causes weird testsuite behaviour Change By: Matěj Novotný Assignee: Matěj Novotný Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2618) ProxyFactory#getProxyName() produces non-deterministic verbose proxy names
Title: Message Title Matěj Novotný assigned an issue to Matěj Novotný Weld / WELD-2618 ProxyFactory#getProxyName() produces non-deterministic verbose proxy names Change By: Matěj Novotný Assignee: Matěj Novotný Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2618) ProxyFactory#getProxyName() produces non-deterministic verbose proxy names
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2618 ProxyFactory#getProxyName() produces non-deterministic verbose proxy names Change By: Matěj Novotný Fix Version/s: 3.1.6.Final Fix Version/s: 3.1.5.Final Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2633) Servlet test JsfTest has to be temporarily disabled due to missing Maven dep
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Matěj Novotný updated WELD-2631 Weld / WELD-2631 Cleanup leftover HttpSessionDestructionContext when starting new session context Change By: Matěj Novotný Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Matěj Novotný commented on WELD-2631 Re: Cleanup leftover HttpSessionDestructionContext when starting new session context PRs were merged, this will land in WFLY whenever it updates to Weld 3.1.5+. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Issue was automatically transitioned when Matěj Novotný created pull request #2008 in GitHub Weld / WELD-2630 Publish a Milestone version of Weld-servlet-core Change By: Matěj Novotný Status: Open Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title Martin Kouba resolved as Rejected Weld / WELD-2632 Allow unwrapping of a proxied object Change By: Martin Kouba Status: Open Resolved Resolution: Rejected Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title Martin Kouba commented on WELD-2632 Re: Allow unwrapping of a proxied object however, doing it at injection point is probably the wrong place, so how about at producer: This is not possible. Client proxies are required to ensure proper functionality for normal scoped beans. That's why "unwrapping proxy" is a corner case that should require some extra handling from the client (injection site). It would probably make more sense to start this discussion at the spec level. Feel free to create a spec issue here: https://github.com/eclipse-ee4j/cdi/issues. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title
Klemen Ferjancic commented on WELD-2632
Re: Allow unwrapping of a proxied object
Yes, that works, I am just unhappy by the need to write wrappers/utility code instead of using JPA interface as intended. A few more thoughts
@AllowUnwrap
@Inject
private EntityManager em
however, doing it at injection point is probably the wrong place, so how about at producer:
@AllowUnwrap
@Produces
@RequestScoped
public EntityManager getEntityManager(){}
As a bonus, weld behaviour could be codified in the spec and this would allow a developer override. No other code changes needed when using JPA or similar use cases. I'm sure it is a bit more complicated that that and I also understand this is a rather narrow use case to merit an introduction of a new annotation/funcitonality in CDI. It seems cleaner and doable though. It would probably make more sense to start this discussion at the spec level. Feel free to close the issue as needed.
Add Comment
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title Martin Kouba commented on WELD-2632 Re: Allow unwrapping of a proxied object Since Weld 3.x you can cast a client proxy instance to org.jboss.weld.proxy.WeldClientProxy and obtain the contextual instance via proxy.getMetadata().getContextualInstance(). I believe that this approach is "good enough" for similar use cases. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
Title: Message Title
Klemen Ferjancic updated an issue
Weld / WELD-2632
Allow unwrapping of a proxied object
Change By:
Klemen Ferjancic
This is a revival of https://issues.redhat.com/browse/WELD-2245 and [https://hibernate.atlassian.net/browse/HHH-11020] for reconsideration.I am not asking for change in default behaviour but to give developer the power to override it.The setup with injected EntityManager and unwrapping the instance is quite common so I don't think it is fair to require custom workarounds for this. I understand the logic why Weld is safeguarding this to prevent escape from proxy but there are use cases like this one in JPA where you do actually want the underlying instance. I think there should be a way to tell Weld to let us do this while keeping the defaults.Something like (making this up on the fly):{color:#9e880d}@JustLetMeUnwrap{color}{color:#00}Session session {color}= em.unwrap(Session.class); ..or any developer convenient way to override the default behaviour when needed. This would also appear to be a blind spot in JPA/CDI interop at the spec level so clarification there would also be welcome.
Add Comment
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c
[weld-issues] [JBoss JIRA] (WELD-2632) Allow unwrapping of a proxied object
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2631 Cleanup leftover HttpSessionDestructionContext when starting new session context Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/2005 , https://github.com/weld/core/pull/2006 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Issue was automatically transitioned when Matěj Novotný created pull request #2005 in GitHub Weld / WELD-2631 Cleanup leftover HttpSessionDestructionContext when starting new session context Change By: Matěj Novotný Status: Open Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2631 Cleanup leftover HttpSessionDestructionContext when starting new session context Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/2005 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
verify as well. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Matěj Novotný assigned an issue to Matěj Novotný Weld / WELD-2631 Cleanup leftover HttpSessionDestructionContext when starting new session context Change By: Matěj Novotný Assignee: Matěj Novotný Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2631) Cleanup leftover HttpSessionDestructionContext when starting new session context
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2631 Cleanup leftover HttpSessionDestructionContext when starting new session context Change By: Matěj Novotný Fix Version/s: 3.1.5.Final Fix Version/s: 4.0.0.Alpha4 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný updated WELD-2570 Weld / WELD-2570 WELD-ENV-33 error using Tomcat 8+ in Eclipse Change By: Matěj Novotný Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse PRs are merged and these changes will land in next releases for Weld 3 and 4. Tassilo karge thank you for contribution and reproducer project! Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core We've got PRs up for Arq. core and Tomcat Arq. adapter which allow Weld to execute most servlet tests on Tomcat. The one exception is a JsfTest where we seem to be blocked by a Jakarta 9 jsf impl release which never landed in central - https://github.com/eclipse-ee4j/mojarra/issues/4729. Some WIP for this issue is visible on my branch. Note that it is dirty and Undertow is plain commented-out to be able to build and test. I'll look into Jetty Arq. adapter now... Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Hmm, if numberguess doesn't trigger, then I don't think there is any. You'd need to cobble something simple together. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Tassilo karge commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Is there a simple sample application that I can deploy on a tomcat, which actually uses the WebAppBeanArchiveScanner? I have looked at the numberguess example, but it does not use it. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2570 WELD-ENV-33 error using Tomcat 8+ in Eclipse Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/2003, https://github.com/weld/core/pull/2004 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Issue was automatically transitioned when karge-itestra created pull request #2004 in GitHub Weld / WELD-2570 WELD-ENV-33 error using Tomcat 8+ in Eclipse Change By: karge-itestra Status: Reopened Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Arjan Tijms commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core For those interested in testing with Piranha, I did a quick patched version here. The patched version simply removed the Tomcat, Jetty and GWT containers: https://github.com/omnifaces/omni-weld-servlet-core I added this to Piranha and at least the initial build works, but need to test more to see if everything really works. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Martin Kouba commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse 2) By the WebAppBeanArchiveScanner itself when looking for the /WEB-INF/classes/META-INF/beans.xml. See here. Carlos Aristu Tassilo karge So you're basically mapping /WEB-INF/classes to the build/classes directory? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný edited a comment on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core Some notes to self: * Arquillian servlet protocol will need to be updated for any testing to work, see [https://github.com/arquillian/arquillian-core/issues/248] * * And we will also need new Arq. adapters for Tomcat (and later jetty), there is already an [issue|https://github.com/arquillian/arquillian-container-tomcat/issues/86] created for it but it needs to first consume the new servlet protocol * Jetty has some alpha0 release of version 11 which seems to be using EE 9, we should look into that as well Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Thanks, I will look at it some time this week. Meanwhile, Tassilo karge, would you be able to provide steps to reproduce? E.g. some concise step by step summary on how to reproduce this issue so that we have a reference here (since we cannot create an automated test for this). Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Tassilo karge edited a comment on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Is there a plan to have a fix in a future version? I would like to weigh in on a fix of this issue.The WebAppBeanArchiveScanner does not do appropriate equality checks on the paths it discovers in two different ways. When a server.xml (admittedly NOT deployed via a WAR) specifies a resource directory like this (replace ... with a custom path):```xml```the DefaultBeanArchiveScanner returns `C:\...\target\classes\META-INF\beans.xml` as one of the beans paths. Afterwards, the WebAppBeanArchiveScanner does _substring matching_ to determine whether the path contains `WEB-INF\classes` (which the path does not). It then asks the servelet context for the beans.xml resource in the server´s `WEB-INF\classes\META-INF` directory, and resolves it to the _real_ file url which is again `C:\...\target\classes\META-INF\beans.xml`. Thus, the same resource is found twice.The problem is that substring matching is used to determine whether two semantically different URLs are the same. One of the URLs is the _logical_ path to the file from the server´s view and one is the _real_ path to the file. A simple fix to the issue would be to perform the path comparison _after_ the real file path of the beans.xml was resolved.However, I am not sure whether it would match with the specification to , since I do not know the relevant part. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný reopened an issue Weld / WELD-2570 WELD-ENV-33 error using Tomcat 8+ in Eclipse Change By: Matěj Novotný Resolution: Rejected Status: Resolved Reopened Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2570 WELD-ENV-33 error using Tomcat 8+ in Eclipse Change By: Matěj Novotný Fix Version/s: 3.1.5.Final Fix Version/s: 4.0.0.Alpha4 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core Some notes to self: Arquillian servlet protocol will need to be updated for any testing to work, see https://github.com/arquillian/arquillian-core/issues/248 Jetty has some alpha0 release of version 11 which seems to be using EE 9, we should look into that as well Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Tassilo karge commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Created pull request: https://github.com/weld/core/pull/2003 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Tassilo karge commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Sure! In fact I already fixed it locally. It is not an eclipse-only feature though. There is an IntelliJ plugin called SmartTomcat (https://plugins.jetbrains.com/plugin/9492-smart-tomcat) which deploys applications in the same way. It is a little difficult to find the culprit, though, so I guess most people just give up and use the slower way of packing everything into a WAR and deploying it in that way. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Matěj Novotný commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Hi Tassilo karge, this is an Eclipse-only feature which also had a workaround mentioned, the issue was rejected so no fixing was planned. I am not strictly against this even though I don't see this being used much. So if you want to step up and contribute a fix (against 3.1 branch), please go ahead. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2570) WELD-ENV-000033 error using Tomcat 8+ in Eclipse
Title: Message Title Tassilo karge commented on WELD-2570 Re: WELD-ENV-33 error using Tomcat 8+ in Eclipse Is there a plan to have a fix in a future version? I would like to weigh in on a fix of this issue. The WebAppBeanArchiveScanner does not do appropriate equality checks on the paths it discovers in two different ways. When a server.xml (admittedly NOT deployed via a WAR) specifies a resource directory like this (replace ... with a custom path): ```xml ``` the DefaultBeanArchiveScanner returns `C:\...\target\classes\META-INF\beans.xml` as one of the beans paths. Afterwards, the WebAppBeanArchiveScanner does substring matching to determine whether the path contains `WEB-INF\classes` (which the path does not). It then asks the servelet context for the beans.xml resource in the server´s `WEB-INF\classes\META-INF` directory, and resolves it to the real file url which is again `C:\...\target\classes\META-INF\beans.xml`. Thus, the same resource is found twice. The problem is that substring matching is used to determine whether two semantically different URLs are the same. One of the URLs is the logical path to the file from the server´s view and one is the real path to the file. A simple fix to the issue would be to perform the path comparison after the real file path of the beans.xml was resolved. However, I am not sure whether it would match with the specification to, since I do not know the relevant part. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core I have heard from Undertow team that they will be doing EE 9 version. That means I would like to postpone this issue until that is done which likely means few weeks at most. In the meantime, we will release Alpha 3, so this issue will target Alpha 4. If nothing else, this gives me time to play with Tomcat testing which I still haven't had much time for. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2630 Publish a Milestone version of Weld-servlet-core Change By: Matěj Novotný Fix Version/s: 4.0.0.Alpha4 Fix Version/s: 4.0.0.Alpha3 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
) Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core So, one of the issues is that our servlet core module provides an Undertow extension, see this. There is also a smoke test that uses some of Undertow classes. In both cases, Undertow operates on javax classes. I would love to have Weld servlet core ready to be used on three platforms before we release it - undertow, tomcat and jetty. Flavia Rainone is there a plan to release Undertow with Jakarta 9 packages any time soon? Then there is also legacy stuff which I think would be safe to remove for Weld 4 (like the gwt dev container using jetty 6 api). Other legacy bits could be polished (but are non blocking for this) such as JettyLegacyContainer. We would of course have to skip tons of testing for early versions due to absence of servlets. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Thiago Henrique Hüpner commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core Thanks Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core but there is a lot of dependencies of the other servlet containers, like Jetty 6, that won't be updated I think. Yeah, we need to sort that out. We can probably drop the legacy stuff at this point because thanks to the package change, it cannot even be compatible. But we need at least some testing, so that would be Tomcat now. Quick scanning Jetty, I don't see any EE 9 version there, yet. I'll look into this later this week or early next week and see what we can do here. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Thiago Henrique Hüpner commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core Oh, I see. We are targeting a new servlet container, Piranha. So, I'd like to test the Weld with the Jakarta EE namespace change. We only need the core of the servlet. I tried to build a version in my machine, but there is a lot of dependencies of the other servlet containers, like Jetty 6, that won't be updated I think. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný commented on WELD-2630 Re: Publish a Milestone version of Weld-servlet-core Hi Thiago Henrique Hüpner, this is intended and was mentioned in latest news article. It wasn't possible in this early release, but it is definitely something we want for next ones. I'll re-check availability of any EE 9 compatible servers we could test with. It looks like at least Tomcat has some early versions supporting this. What servlet are you targeting? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný assigned an issue to Matěj Novotný Weld / WELD-2630 Publish a Milestone version of Weld-servlet-core Change By: Matěj Novotný Assignee: Matěj Novotný Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2630 Publish a Milestone version of Weld-servlet-core Change By: Matěj Novotný Fix Version/s: 4.0.0.Alpha3 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2630) Publish a Milestone version of Weld-servlet-core
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2628 AfterTypeDiscovery added alternative gets ineffective priority Change By: Matěj Novotný Affects Version/s: 4.0.0.Alpha2 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný commented on WELD-2628 Re: AfterTypeDiscovery added alternative gets ineffective priority Karl von Randow PRs are merged for both, 3.1 and master, thanks for reporting this and contributing! Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný updated WELD-2628 Weld / WELD-2628 AfterTypeDiscovery added alternative gets ineffective priority Change By: Matěj Novotný Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2628 AfterTypeDiscovery added alternative gets ineffective priority Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/1999 , https://github.com/weld/core/pull/2002 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2628 AfterTypeDiscovery added alternative gets ineffective priority Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/1999 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Matěj Novotný oki, thanks for the clarification on the version. Ok also it is written in the spec but also ok it is wrong so should be fixed, opened https://issues.redhat.com/browse/CDI-746. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Matěj Novotný commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering CDI 2.0.1 does NOT exist, it is a binary version, not a spec fix so it looks ackward, nothing more. All I am saying is that all CDI TCK release in the 2.0.x line correspond (or are aligned with) CDI API 2.0 release. There can be n releases of TCK for 1 release of spec. Though there are limitations on what a TCK release for an already released CDI version can contain. This should be captured in docs inside the TCK. That's how it worked under jboss at least. It is eclipse project now, so the process might differ. Also, what Martin pointed out pretty much settles the discussion. The ordering is given by the spec after all. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Matěj Novotný CDI 2.0.1 does NOT exist, it is a binary version, not a spec fix so it looks ackward, nothing more. If you wrap instances it is fine but since PIP is also used to capture injections and beans to add in ABD then you break the container enabling to veto after. All vetos should only be doable before advanced introspection otherwise extensions are very complex to write - not a single one out there works with this paradigm btw, even in DS/MP lands. It also makes extensions + alternatives/specialization quite weirdly behaving so I think veto should be in the first phases then shouldn't be at all. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Martin Kouba commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering hmm, nowhere it is written that the bullet order must be respected so it is not in the spec IMO. The spec wording is clear. Each bullet sentence in 12.4.4. Bean discovery ends with "and then". Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title
Matěj Novotný commented on CDITCK-590
Re: Add a test for Bean Discovery which asserts lifecycle event ordering
nowhere it is written that the bullet order must be respected so it is not in the spec IMO
I am sorry, but that sounds like a rather poor argument. I am pretty sure you can find other parts in EE specs where you would happily assume ordering based on a written list. For instance Container Lifecycle Events also list certain events under Application lifecycle events, that are fired once. And I think we can all safely "assume" that BeforeBeanDiscovery somehow precedes {{BeforeShutdown }}even though the spec doesn't say that the bullet order must be respected, right? Also, if you twist it around, then having it as the test presumes allows you to introspect and change things around in PIP and PIT and then based on the current state decide whether you want to veto the bean or not inside PBA. This to me sounds a lot more sensible than firing PAT with veto option followed up by PBA with the exact same option when nothing really changes in between.
Not directly linked to this issue but since you mention it: is 2.0.1.Final anything in terms of spec (I can see what it is in terms of artifact release but not spec)?
Not sure I understand what you ask about? There are multiple releases of TCKs for each CDI spec versions. Typically containing new exclusions, test corrections and so on. Take a look here - the 2.0.x TCK version is linked to CDI 2.0. Latest for that version is actually 2.0.7.SP1.
Add Comment
This message was sent by Atlassian Jira (v7.13.8#713008-sh
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Matěj Novotný hmm, nowhere it is written that the bullet order must be respected so it is not in the spec IMO. Then on a functional sense, it is a non-sense to fire PBA after PIP and PIT. PBA is way closer to PAT by the operation it defines and a veto BA must not lead to PIP or PIT so should be just after PAT by design - but I agree it is not explicitly specified today so means PBA before is straight forward for users, PBA after requires extensions to revise the PIT and PIP capture after the whole discovery to be accurate (which is quite complex for nothing IMHO). Not directly linked to this issue but since you mention it: is 2.0.1.Final anything in terms of spec (I can see what it is in terms of artifact release but not spec)? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2629) ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations
Title: Message Title Matěj Novotný updated WELD-2629 Weld / WELD-2629 ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations Change By: Matěj Novotný Status: Pull Request Sent Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Matěj Novotný commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering The correct order - as far as I remember it has been discussed originally - is So, I don't know what you discussed and where/when, but current spec wording is pretty straightforward. If you look at Bean discovery section, it defines the ordering for both, class based bean and producer based bean. This exactly corresponds to what the test asserts. Note also, that this TCK test is not part of the official CDI-2.0 JSR but added at a random later point. The "random later point" can be divined from GH commit history - seems this got in with 2.0.1.Final even though the PR linked here was actually closed. Spec lists the needed events but it is not written the order must be this oneSpec lists the needed events but it is not written the order must be this one That's just bending the wording. Is there an actual reason why this ordering is bad? I can't see why you couldn't veto things in PBA with the current ordering, it isn't too late. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sh
[weld-issues] [JBoss JIRA] (WELD-2629) ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2629 ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/2000, https://github.com/weld/core/pull/2001 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Mark Struberg commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Note also, that this TCK test is not part of the official CDI-2.0 JSR but added at a random later point. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Romain Manni-Bucau commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Hi, Can it be revised? Spec lists the needed events but it is not written the order must be this one + it is more logical to add PBA at the beginning, next to PAT since it has veto data, does not make sense to do it at the end cause it is already too late. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Mark Struberg edited a comment on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Plus it is wrong. The correct order - as far as I remember it has been discussed originally - is> ProcessAnnotatedType -> ProcessBeanAttributes -> ProcessInjectionPoint -> ProcessInjectionTarget -> ProcessBean Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-590) Add a test for Bean Discovery which asserts lifecycle event ordering
Title: Message Title Mark Struberg commented on CDITCK-590 Re: Add a test for Bean Discovery which asserts lifecycle event ordering Plus it is wrong. The correct order is > ProcessAnnotatedType -> ProcessBeanAttributes -> ProcessInjectionPoint -> ProcessInjectionTarget -> ProcessBean Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2629) ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations
Title: Message Title Issue was automatically transitioned when Matěj Novotný created pull request #2000 in GitHub Weld / WELD-2629 ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations Change By: Matěj Novotný Status: Open Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2629) ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2629 ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations Change By: Matěj Novotný Fix Version/s: 3.1.5.Final Fix Version/s: 4.0.0.Alpha3 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2629) ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2629) ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations
Title: Message Title Matěj Novotný assigned an issue to Matěj Novotný Weld / WELD-2629 ConversationContextDestroyedOnSessionTimeoutTest goes against servlet spec expectations Change By: Matěj Novotný Assignee: Matěj Novotný Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Issue was automatically transitioned when Karl von Randow created pull request #1999 in GitHub Weld / WELD-2628 AfterTypeDiscovery added alternative gets ineffective priority Change By: Karl von Randow Status: Open Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2628 AfterTypeDiscovery added alternative gets ineffective priority Change By: Matěj Novotný Fix Version/s: 3.1.5.Final Fix Version/s: 4.0.0.Alpha3 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný commented on WELD-2628 Re: AfterTypeDiscovery added alternative gets ineffective priority I believe I've found the issue. It's the Integer.MIN_VALUE priorities on those two classes. Haha, nice, you got me there. I certainly didn't expect that I think I never saw a negative priority usage within CDI in the first place, but the spec doesn't seem to forbid it so this is a bug we need to fix. Karl von Randow would you be interested in submitting a PR containing a fix + test or should I do it? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title
Karl von Randow edited a comment on WELD-2628
Re: AfterTypeDiscovery added alternative gets ineffective priority
[~manovotn] thanks again, especially as it seems there might be is something odd with my setup.I can _confirm_ that I do see the {{getAlternatives}} list containing two classes at the end that have {{Integer.MIN_VALUE}} priority, and others earlier in the list with {{100}} and {{200}}.I believe I've found the issue. It's the {{Integer.MIN_VALUE}} priorities on those two classes. Let me try to excuse myself by saying that those priorities are actually for JAX-RS (as the classes are Filters), and I'm using CXF-CDI so my classes are {{@Dependent}} but use {{@Priority}} for JAX-RS and aren't actually alternatives.The {{compareTo}} function in {{org.jboss.weld.bootstrap.enablement.Item}} uses {{return p1 - p2;}} as the return value, which hits an integer overflow when {{p2 == Integer.MIN_VALUE}}.I'm not clear on whether (large) negative priorities are legal in the CDI spec. They're certainly possible! Perhaps it could be considered a fix to change the {{compareTo}} method to avoid integer overflow with a few comparisons?
Add Comment
This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Karl von Randow commented on WELD-2628 Re: AfterTypeDiscovery added alternative gets ineffective priority Matěj Novotný thanks again, especially as it seems there might be something odd with my setup. I can confirm that I do see the getAlternatives list containing two classes at the end that have Integer.MIN_VALUE priority, and others earlier in the list with 100 and 200. I believe I've found the issue. It's the Integer.MIN_VALUE priorities on those two classes. Let me try to excuse myself by saying that those priorities are actually for JAX-RS (as the classes are Filters), and I'm using CXF-CDI so my classes are @Dependent but use @Priority for JAX-RS and aren't actually alternatives. The compareTo function in org.jboss.weld.bootstrap.enablement.Item uses return p1 - p2; as the return value, which hits an integer overflow when p2 == Integer.MIN_VALUE. I'm not clear on whether (large) negative priorities are legal in the CDI spec. They're certainly possible! Perhaps it could be considered a fix to change the compareTo method to avoid integer overflow with a few comparisons? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný commented on WELD-2628 Re: AfterTypeDiscovery added alternative gets ineffective priority Karl von Randow hmm, that sounds fishy, there are tests in the TCK that assert the ordering in this case (and Weld passes TCKs). For instance this test which uses 3 differently prioritized alternatives and asserts ordering. I will look at what's involved to create a test case demonstrating this... That would be great. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Karl von Randow commented on WELD-2628 Re: AfterTypeDiscovery added alternative gets ineffective priority Matěj Novotný thank you very much for your quick and thorough replies. The list of alternatives accessed is not sorted by priority in Weld 3.1.4 in the case I have observed. Therefore I think Weld has a bug and does not sort by priority in ascending order. I will look at what's involved to create a test case demonstrating this... Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
Title: Message Title Matěj Novotný commented on WELD-2628 Re: AfterTypeDiscovery added alternative gets ineffective priority Karl von Randow Staring a bit longer into the spec, there is the following statement about the collection of alternatives you are getting: getAlternatives() returns the ordered list of enabled alternatives for the application, sorted by priority in ascending order. Alternatives enabled for a bean archive are not included in the list. This ultimately means that the highest priority that exists in the list is the rightmost element. Hence anything you add as a next element into the list will become rightmost and will have the priority of the previously highest value plus some constant (in this case it should be +10). So this new element inevitably becomes the one with the highest priority in the whole list. So taking what you said: If prior to AfterTypeDiscovery the alternatives list already contains an alternative implementation of FooService with a priority (say 100), but it's not the last item in the alternatives list, then an Extension adds another alternative of FooService, that new alternative will get a priority 10 greater than the priority of the last alternative in the list, but not necessarily greater than 100, and therefore will not be chosen. In this case, if there is FooService with 100 and it is not last item in the list, then any last item has to have more then 100 priority and anything you add behind that will have even more than that and certainly more then 100. With this in mind, I am failing to see the issue you are having, could you maybe provide a reproducer or a more in depth description of what you are seeing? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
hts on this? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2628) AfterTypeDiscovery added alternative gets ineffective priority
. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2627) UT000010: Session is invalid
Title: Message Title Cristian VL commented on WELD-2627 Re: UT10: Session is invalid System: WildFly 14, 16 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2627) UT000010: Session is invalid
Title: Message Title Cristian VL commented on WELD-2627 Re: UT10: Session is invalid Hi Matej, The error is in fact an Exception thrown by Undertow system but it is not caught or handled by Weld. There are multiple threads working on that session and one of them invalidate the session and the state it is not propagated by Undertow. The errors appeared recently after I added Weld into web application. No errors before. That's way I reported this error on Weld. Thanks, Cristian Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2627) UT000010: Session is invalid
Title: Message Title Matěj Novotný commented on WELD-2627 Re: UT10: Session is invalid Hi, can you provide some more specific information? Just pasting an exception isn't really helpful. What kind of application/action is causing this. What technologies are you using - I can see Weld and Undertow from the stack but that's about it. Also, the exception suggests that it is coming from Undertow, is there a reason why you report it against Weld? Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2627) UT000010: Session is invalid
(AbstractConversationContext.java:157) at org.jboss.weld.module.web.servlet.ConversationContextActivator.activateConversationContext(ConversationContextActivator.java:116) at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:254) at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152) at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246) at io.undertow.servlet.spec.AsyncContextImpl.setupRequestContext(AsyncContextImpl.java:706) at io.undertow.servlet.spec.AsyncContextImpl.access$700(AsyncContextImpl.java:73) at io.undertow.servlet.spec.AsyncContextImpl$7.run(AsyncContextImpl.java:619) at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:181) at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:178) at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:1027) ... 10 more Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
Title: Message Title Matěj Novotný resolved as Done Weld / WELD-2626 Aggressively invoke setAttribute() when manipulating with conversation map in session Change By: Matěj Novotný Status: Open Resolved Resolution: Done Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2626 Aggressively invoke setAttribute() when manipulating with conversation map in session Change By: Matěj Novotný Git Pull Request: https://github.com/weld/core/pull/1982, https://github.com/weld/core/pull/1983, https://github.com/weld/core/pull/1992 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2602) Report error if undeployed BeanManager used.
Title: Message Title Darran Lofthouse assigned an issue to Unassigned Weld / WELD-2602 Report error if undeployed BeanManager used. Change By: Darran Lofthouse Assignee: Darran Lofthouse Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2626 Aggressively invoke setAttribute() when manipulating with conversation map in session Change By: Matěj Novotný Fix Version/s: 4.0.0.Alpha3 Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2626 Aggressively invoke setAttribute() when manipulating with conversation map in session Change By: Matěj Novotný Fix Version/s: 3.1.5.Final Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2626 Aggressively invoke setAttribute() when manipulating with conversation map in session Change By: Matěj Novotný Fix Version/s: 2.4.9.Final Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
Title: Message Title Matěj Novotný updated an issue Weld / WELD-2626 Aggressively invoke setAttribute() when manipulating with conversation map in session Change By: Matěj Novotný Affects Version/s: 3.1.4.Final Affects Version/s: 3.0.6.Final Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2626) Aggressively invoke setAttribute() when manipulating with conversation map in session
r branches. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
