[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 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-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] (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] (WELD-2615) HttpSessionContext#destroy(Contextual) should always destroy the underlying contextual instance
Title: Message Title Martin Kouba updated WELD-2615 Weld / WELD-2615 HttpSessionContext#destroy(Contextual) should always destroy the underlying contextual instance Change By: Martin Kouba Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1974 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-2615) HttpSessionContext#destroy(Contextual) should always destroy the underlying contextual instance
Title: Message Title
Martin Kouba updated an issue
Weld / WELD-2615
HttpSessionContext#destroy(Contextual) should always destroy the underlying contextual instance
Change By:
Martin Kouba
Currently, it's only destroyed if the bean is previously used in the request. It's very likely caused by the "attributes lazy fetching" optimization: {{org.jboss.weld.context.attributes.lazyFetch}}. See https://github.com/eclipse-ee4j/cdi/issues/427 for more information.
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-2615) HttpSessionContext#destroy(Contextual) should always destroy the underlying contextual instance
Title: Message Title Martin Kouba created an issue Weld / WELD-2615 HttpSessionContext#destroy(Contextual) should always destroy the underlying contextual instance Issue Type: Bug Affects Versions: 3.1.3.Final Assignee: Unassigned Components: Scopes & Contexts Created: 03/Mar/20 2:53 AM Priority: Major Reporter: Martin Kouba It's very likely caused by the "attributes lazy fetching" optimization: org.jboss.weld.context.attributes.lazyFetch. See https://github.com/eclipse-ee4j/cdi/issues/427 for more information. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2614) Beans representing array types do not include Cloneable and Serializable in their type closures
Title: Message Title Martin Kouba commented on WELD-2614 Re: Beans representing array types do not include Cloneable and Serializable in their type closures No, it shouldn't. The CDI spec is clear that the set of bean types of a producer method "exactly two types: the method return type and java.lang.Object". Note that CDI defines its own assignability rules. Feel free co create a spec issue if you think it's a major issue that requires clarification. 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-2610) Wars observe other wars' conversation destroyed events
Title: Message Title Martin Kouba updated WELD-2610 Weld / WELD-2610 Wars observe other wars' conversation destroyed events Change By: Martin Kouba Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1959 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-2610) Wars observe other wars' conversation destroyed events
Title: Message Title Martin Kouba assigned an issue to Martin Kouba Weld / WELD-2610 Wars observe other wars' conversation destroyed events Change By: Martin Kouba Assignee: Martin Kouba 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-2610) Wars observe other wars' conversation destroyed events
Title: Message Title Martin Kouba commented on WELD-2610 Re: Wars observe other wars' conversation destroyed events It seems that Weld is using GlobalLenientObserverNotifier when destroying expired/ended conversations when the conversation context is deactivated. This notifier should not be used in this case because only observers accessible from the web archive should be notified. Moreover, it seems that two events with qualifier @Destroyed(ConversationScoped.class) are fired for the current conversation that ended in the current request. One with payload javax.servlet.http.HttpServletRequest and one with payload java.lang.String. The spec is clear that if the conversation context is associated with the current Servlet request javax.servlet.http.HttpServletRequest should be used (see https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#conversation_context_ee). Currently, if you define an observer like this: @Observes @Destroyed(ConversationScoped.class) Object event it would be notified twice. I'll try to propose a fix for both of these 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-2608) Adding a bean using AfterBeanDiscovery does not register its observer methods
Title: Message Title Martin Kouba commented on WELD-2608 Re: Adding a bean using AfterBeanDiscovery does not register its observer methods From what I read there, the @Vetoed beans should also trigger a ProcessAnnotatedType event and I could remove the @Vetoed annotation there. That's not correct. ProcessAnnotatedType is not fired for any type annotated with @Vetoed. See also 11.5.6. ProcessAnnotatedType event. 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-2609) ObserverMethodConfigurator#read methods do not set async and notify callback
Title: Message Title Martin Kouba commented on WELD-2609 Re: ObserverMethodConfigurator#read methods do not set async and notify callback I think that the absence of the async property is a bug. However, the the notify callback is not something you can reliably deduct from a method, ie. the annotatedBeanType.javaClass might not be enough to find the correct bean instance. Therefore, I suppose that the original intent was to always require a callback to be manually set. 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-2608) Adding a bean using AfterBeanDiscovery does not register its observer methods
Title: Message Title Martin Kouba commented on WELD-2608 Re: Adding a bean using AfterBeanDiscovery does not register its observer methods I believe that this works as designed. The purpose of the BeanConfigurator is to register/configure beans and not observers. The truth is that BeanConfigurator.read() could be more explicit and describe the intention in more details. In any case, there is no TCK test that verifies this behavior. We should probably file a spec issue. Matěj Novotný WDYT? 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-2604) Enabling alternatives does not work if weld-se archive isolation is enabled
Title: Message Title Martin Kouba commented on WELD-2604 Re: Enabling alternatives does not work if weld-se archive isolation is enabled I'm sorry that I have to ask again... No problem. Does / should adding a @Priority annotation already automatically enable the alternative? Yes, it does and it should enable/select the alternative globally, ie. for the whole application. I thought if I give the class to selectAlternatives... Nope. These are two different ways of enabling alternatives: 1. beans.xml or SeContainerInitializer.selectAlternatives() - locally, per bean archive 2. @Priority - globally, for the application Is there a way to achieve this... Hm, probably not. Well, you can disable the discovery completely (SeContainerInitializer.disableDiscovery()) and use the synthetic bean archive only - SeContainerInitializer.selectAlternatives() would work in this case. Add Comment This message was sent by Atlassian Jira (v7.13.8#713008-sha1:1606a5c)
[weld-issues] [JBoss JIRA] (WELD-2604) Enabling alternatives does not work if weld-se archive isolation is enabled
Title: Message Title Martin Kouba commented on WELD-2604 Re: Enabling alternatives does not work if weld-se archive isolation is enabled No problem 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] (WELD-2604) Enabling alternatives does not work if weld-se archive isolation is enabled
Title: Message Title Martin Kouba resolved as Rejected Weld / WELD-2604 Enabling alternatives does not work if weld-se archive isolation is enabled 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-2604) Enabling alternatives does not work if weld-se archive isolation is enabled
Title: Message Title Martin Kouba commented on WELD-2604 Re: Enabling alternatives does not work if weld-se archive isolation is enabled This works as designed. The SeContainerInitializer.selectAlternatives() method enables the alternatives only for the synthetic bean archive, ie. for the beans added through the SeContainerInitializer.addBeanClasses() and SeContainerInitializer.addPackages methods. It's a programmatic alternative to the element of the beans.xml file. If isolation is disabled a "flat" deployment structure is used - all bean classes share the same bean archive and all beans.xml descriptors are merged into one. In this case, SeContainerInitializer.selectAlternatives() effectively enables the alternatives globally. If you need to enable an alternative globally you can use the @javax.annotation.Priority annotation - see Declaring selected alternatives for an application. 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-2594) Message Driven Bean's around invoke interceptor invoked twice
Title: Message Title Martin Kouba commented on WELD-2594 Re: Message Driven Bean's around invoke interceptor invoked twice I think that this will require an update in GF/Payara integration. WELD-2404 fixed a problem for which a "workaround" probably exists in GF/Payara and this workaround should be removed 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-2588) Injection of parametrized type to actual type
Title: Message Title Martin Kouba commented on WELD-2588 Re: Injection of parametrized type to actual type I think that Matej is right - those types are not assignable according to the spec rules. Injected foo.someMethod() should return a long value but FooImpl could simply return any comparable leading into class cast exception. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2563) In a CDI SE application, three instances of every Service loaded are created; only one is used
Title: Message Title Issue was automatically transitioned when Martin Kouba created pull request #1918 in GitHub Weld / WELD-2563 In a CDI SE application, three instances of every Service loaded are created; only one is used Change By: Martin Kouba Status: Open Pull Request Sent Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2563) In a CDI SE application, three instances of every Service loaded are created; only one is used
Title: Message Title Martin Kouba commented on WELD-2563 Re: In a CDI SE application, three instances of every Service loaded are created; only one is used Adding a callback to org.jboss.weld.bootstrap.api.Service requires an API change. Therefore, I'm going to move this issue to v3.2. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2563) In a CDI SE application, three instances of every Service loaded are created; only one is used
Title: Message Title Martin Kouba updated an issue Weld / WELD-2563 In a CDI SE application, three instances of every Service loaded are created; only one is used Change By: Martin Kouba Fix Version/s: 3.2 Fix Version/s: 3.1.1.Final Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2563) In a CDI SE application, three instances of every Service loaded are created; only one is used
Title: Message Title Martin Kouba commented on WELD-2563 Re: In a CDI SE application, three instances of every Service loaded are created; only one is used Yes, such a callback could make sense. The only problem is that it could be also invoked many times because it could be registered for more bean managers. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2563) In a CDI SE application, three instances of every Service loaded are created; only one is used
Title: Message Title Martin Kouba commented on WELD-2563 Re: In a CDI SE application, three instances of every Service loaded are created; only one is used Yeah, it is a bit strange . The reason why we can't stop the discovery is that there might be multiple service providers for the same service interface and Weld only registers the one with highest priority. We could filter out services by the class name but in theory each class loader can load a different class for a given name... Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2563) In a CDI SE application, three instances of every Service loaded are created; only one is used
Title: Message Title Martin Kouba commented on WELD-2563 Re: In a CDI SE application, three instances of every Service loaded are created; only one is used You're right that the lifecycle of the services registered through the ServiceLoader mechanism is not well defined. On the other hand, the AdditionalServiceLoader's javadoc is very clear that it's using the deployment classloaders, TCCL and Weld's classloader to discover the service providers. Another thing is that JpaInjectionServices should be a per-module service but AdditionalServiceLoader loads services globally, i.e. the instance is also copied to all BeanManager registries. This does not seem to be correct and should be documented at least. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2517) Fix se/numberguess example with SecurityManager enabled
Title: Message Title Martin Kouba updated WELD-2517 Weld / WELD-2517 Fix se/numberguess example with SecurityManager enabled Change By: Martin Kouba Status: Coding In Progress Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1895 Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2517) Fix se/numberguess example with SecurityManager enabled
Title: Message Title Martin Kouba assigned an issue to Martin Kouba Weld / WELD-2517 Fix se/numberguess example with SecurityManager enabled Change By: Martin Kouba Assignee: Martin Kouba Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2517) Fix se/numberguess example with SecurityManager enabled
Title: Message Title Martin Kouba started work on WELD-2517 Change By: Martin Kouba Status: Open Coding In Progress Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2536) Make InjectableRequestContextController more robust
Title: Message Title Martin Kouba updated WELD-2536 Weld / WELD-2536 Make InjectableRequestContextController more robust Change By: Martin Kouba Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1894 Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2546) InterceptorLogger.unableToDetermineInterceptedBean() should be probably logged at the INFO level
Title: Message Title Martin Kouba updated WELD-2546 Weld / WELD-2546 InterceptorLogger.unableToDetermineInterceptedBean() should be probably logged at the INFO level Change By: Martin Kouba Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1893 Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2551) Interface default methods are treated inconsistently by AnnotatedType and WithAnnotations
Title: Message Title Martin Kouba updated WELD-2551 Weld / WELD-2551 Interface default methods are treated inconsistently by AnnotatedType and WithAnnotations Change By: Martin Kouba Status: Coding In Progress Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1892 Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2551) Interface default methods are treated inconsistently by AnnotatedType and WithAnnotations
Title: Message Title Martin Kouba started work on WELD-2551 Change By: Martin Kouba Status: Open Coding In Progress Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2536) Make InjectableRequestContextController more robust
Title: Message Title Martin Kouba assigned an issue to Martin Kouba Weld / WELD-2536 Make InjectableRequestContextController more robust Change By: Martin Kouba Assignee: Martin Kouba Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2546) InterceptorLogger.unableToDetermineInterceptedBean() should be probably logged at the INFO level
Title: Message Title Martin Kouba assigned an issue to Martin Kouba Weld / WELD-2546 InterceptorLogger.unableToDetermineInterceptedBean() should be probably logged at the INFO level Change By: Martin Kouba Assignee: Martin Kouba Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2551) Interface default methods are treated inconsistently by AnnotatedType and WithAnnotations
Title: Message Title Martin Kouba assigned an issue to Martin Kouba Weld / WELD-2551 Interface default methods are treated inconsistently by AnnotatedType and WithAnnotations Change By: Martin Kouba Assignee: Martin Kouba Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2554) ProcessInjectionPoint.setInjectionPoint() doesn't work in some environment.
Title: Message Title Martin Kouba commented on WELD-2554 Re: ProcessInjectionPoint.setInjectionPoint() doesn't work in some environment. For the record - this is not required by the spec - the container must fire PIP for every injection point of every Java EE component only when running in Java EE, see also ProcessInjectionPoint event and EJB. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2534) Log a warning when starting multiple SE containers and resetting SingletonProvider
Title: Message Title Martin Kouba commented on WELD-2534 Re: Log a warning when starting multiple SE containers and resetting SingletonProvider I'm fine with closing this issue. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2546) InterceptorLogger.unableToDetermineInterceptedBean() should be probably logged at the INFO level
Title: Message Title Martin Kouba created an issue Weld / WELD-2546 InterceptorLogger.unableToDetermineInterceptedBean() should be probably logged at the INFO level Issue Type: Enhancement Assignee: Unassigned Created: 21/Nov/18 2:57 AM Priority: Optional Reporter: Martin Kouba This message is currently logged at the WARN level. However, CDI interceptors are often used for non-contextual instances (e.g. Java EE components) where Weld simply injects null. I think it would be reasonable to use INFO instead. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505)
[weld-issues] [JBoss JIRA] (WELD-2541) Should @AroundInvoke apply to mdb methods called by container?
Title: Message Title Martin Kouba commented on WELD-2541 Re: Should @AroundInvoke apply to mdb methods called by container? I think that purely from the spec point of view the Mdb27891072#setMessageDrivenContext() method should not be intercepted as it is not a message listener method . And CDI 1.2 is clear that only invocations of message listener methods of message-driven beans are passed through method interceptors (see also 7.2. Container invocations and interception). Also the EJB 3.2 mentions that "AroundInvoke interceptor methods may be defined for business methods of sessions beans and for the message listener methods of message-driven beans", see also 7.3 Business Method Interceptors. CDI 2.0 wording is a little bit vague though - see also 23. Interceptor bindings in Java EE. However, I'm not an EJB/MDB expert and I can not judge whether it could have some practical impact. In any case, it's the responsibility of an integrator (WebLogic) to use the Weld SPIs in a way that complies with the specific spec (EJB) requirements. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2539) Weld API - add WeldManager#getAllContexts() method
Title: Message Title Martin Kouba commented on WELD-2539 Re: Weld API - add WeldManager#getAllContexts() method Hm, I'd say that getScopes() should be enough. You could use isContextActive() + getContext() to obtain the context without ContextNotActiveException and eventually test with instanceof WeldAlterableContext. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2539) Weld API - add WeldManager#getAllContexts() method
Title: Message Title Martin Kouba commented on WELD-2539 Re: Weld API - add WeldManager#getAllContexts() method I would vote for getContexts() and it should not throw ContextNotActiveException. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2525) Observer methods process events in reverse order
Title: Message Title Martin Kouba commented on WELD-2525 Re: Observer methods process events in reverse order Hi Marco Strauch there is really no guarantee in which order transactional observer methods are notified. I think that CDI 2.0 + priorities wouldn't help either because every Event#fire() results in a new JTA Synchronization (although used for all transactional observer methods for the given payload) and I don't think the ordering of JTA Synchronization callbacks is defined. The behavior you observe is probably just a matter of coincidence. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2525) Observer methods process events in reverse order
Title: Message Title
Martin Kouba edited a comment on WELD-2525
Re: Observer methods process events in reverse order
Hi,sorry for the late answer.We cannot easily update to CDI 2.0 and I don't think that the priority annoation will help us because we have no predictable order for fireing events. But we expect that when we fire a specific event for one object and then fire another event for another object the listeners are executed in the same order.In fact it is not easy for us to provide some code because in the software this is a little bit more complex, but I will provide some sample code to present what we did and what we expect. {code:java} /** * * Only a dummy object to present the object operations */public class EventObject { }/** * Stateless Bean class that produces the events */@Statelesspublic class EventProducerClass { @Inject @Created Event createEvent; @Inject @Locked Event lockEvent; public void testEventing() {EventObject eo1 = new EventObject(); EventObject eo2 = new EventObject(); // first fire lock event for first object (we expect that this event is being handled by the observers below at first) lockEvent.fire(eo1);// second fire create event for second object (we expect that this event is being handled by the observers below at second) createEvent.fire(eo2); }}/** * Sample Event consumer that reacts on the events after trasaction success. * In the above case the lock event on the first object is fired before the create event of the second object. * So we expect that the event of the lock event is being fired before the create event. * But in the case of after TX Success the create event of the second object is being fired before the lock event of the first object and that may be not the correct / expected behaviour. */public class EventConsumerAfterTXSuccess { public void onCreate(@Observes(during = TransactionPhase.AFTER_SUCCESS) @Created EventObject object) { // do some action after creating an object } public void onLock(@Observes(during = TransactionPhase.AFTER_SUCCESS) @Locked EventObject object) { // do some action on locking first object that must be done before the create event of the second object received } }/** * Sample Event consumer that reacts on the events before the transaction was finished. * In the above case the lock event on the first object is fired before the create event of the second object. * So we expect that the event of the lock event is being fired before the create event. * And in this case of before TX Success the lock event of the first object is being fired before the create event of the second object and that is the correct behaviour. */public class EventConsumerBeforeTXSuccess { public void onCreate(@Observes(during = TransactionPhase.BEFORE_COMPLETION) @Created EventObject object) { // do some action after creating an object } public void onLock(@Observes(during = TransactionPhase.BEFORE_COMPLETION) @Locked EventObject object) { // do some action on locking first object that must be done before the create event of the second object received } } {code}
[weld-issues] [JBoss JIRA] (WELD-2537) Weld API - add WeldManager#isContextActive()
Title: Message Title Martin Kouba updated an issue Weld / WELD-2537 Weld API - add WeldManager#isContextActive() Change By: Martin Kouba Fix Version/s: 3.1.0.Final Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2537) Weld API - add WeldManager#isContextActive()
Title: Message Title Martin Kouba created an issue Weld / WELD-2537 Weld API - add WeldManager#isContextActive() Issue Type: Enhancement Assignee: Unassigned Created: 10/Oct/18 10:42 AM Priority: Minor Reporter: Martin Kouba Currently, the only portable way to find out whether a request context is active is to call BeanManager#getContext(Class) but this method throws ContextNotActiveException. Note that there is org.jboss.weld.manager.BeanManagerImpl.isContextActive(Class) but it's not part of the API. Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505)
[weld-issues] [JBoss JIRA] (WELD-2536) Make InjectableRequestContextController more robust
Title: Message Title Martin Kouba created an issue Weld / WELD-2536 Make InjectableRequestContextController more robust Issue Type: Enhancement Assignee: Unassigned Created: 10/Oct/18 10:17 AM Priority: Minor Reporter: Martin Kouba The object should be considered stateful, invoking the same instance on different threads may not work properly, non-portable behavior may occur. (6.5.2.1. Activating a Request Context) In theory, we could use threadlocal and so it would be possible to reuse the bean from multiple threads. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2535) Weld handleJar does not handle packages with overlapping names correct
Title: Message Title Martin Kouba commented on WELD-2535 Re: Weld handleJar does not handle packages with overlapping names correct Lars-Fredrik Smedberg Thanks for the report! You're absolutely right. Would you mind sending a pull request? Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2535) Weld handleJar does not handle packages with overlapping names correct
Title: Message Title Martin Kouba updated an issue Weld / WELD-2535 Weld handleJar does not handle packages with overlapping names correct Change By: Martin Kouba Fix Version/s: 3.1.0.Final Fix Version/s: 2.4.9.Final Add Comment This message was sent by Atlassian Jira (v7.12.1#712002-sha1:609a505) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2497) Weld API - make it possible to propagate built-in contexts
Title: Message Title
Martin Kouba updated an issue
Weld / WELD-2497
Weld API - make it possible to propagate built-in contexts
Change By:
Martin Kouba
By definition: bq. A context with a certain scope is said to propagate from one point in the execution of the program to another when the set of mapped instances of contextual types with that scope is preserved.Application context is an example of propagating context. However, other built-in normal scopes (such as request context) usually do not propagate and are only bound to a single thread. It seems there are use cases where propagation makes sense (async jax-rs/servlet).Weld context management API currently does not allow to:# *"capture"* the current instances easily ({{javax.enterprise.context.spi.Context#get()}} can only be used if the set of beans for the given scope is known - requires a portable extension etc.)# *"clear"* the external storage without destroying the contextual instances (i.e. the context needs to be invalidated before)# *"initialize"* the external storage with the map of current instances (e.g. {{HttpServletRequest}} in case of request context bound to {{ServletRequest}}).h2. Proposalh3. ManagedContextAdd {{org.jboss.weld.context.ManagedContext#getCurrentInstances()}} method (name to be discussed) that returns an immutable map of {{javax.enterprise.context.spi.Contextual}} to the current instance of the contextual type. Contextual is not guaranteed to be designed correctly as a map key so we might need to return a map of {{org.jboss.weld.serialization.spi.BeanIdentifier}} to current instances instead. This method would be used to "capture" the state. By default, the method would throw {{UnsupportedOperationException}}. *UPDATE:* Note that we cannot actually return just a map of {{Contextual}} -> {{Object}} because we need to preserve the {{CreationalContext}} too so that we're able to destroy the dependent objects correctly. h3. BoundContextAdd {{org.jboss.weld.context.BoundContext#reset()}} method (name to be discussed) that would accept a map of {{javax.enterprise.context.spi.Contextual}} to the current instance of the contextual type (or BeanIdentifier->instance, see above). This method would be used to "reset" the external storage and clear all threadl local caches. By default, the method would throw {{UnsupportedOperationException}}. h2. TODO: Typical use case
[weld-issues] [JBoss JIRA] (WELD-2523) Weld SE bootstrap API - make it possible to add bean defining annotations
Title: Message Title Martin Kouba created an issue Weld / WELD-2523 Weld SE bootstrap API - make it possible to add bean defining annotations Issue Type: Enhancement Assignee: Unassigned Components: Java SE Support Created: 02/Aug/18 9:37 AM Priority: Major Reporter: Martin Kouba I.e. add something like org.jboss.weld.environment.se.Weld#addBeanDefiningAnnotation(Class) Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849)
[weld-issues] [JBoss JIRA] (WELD-2500) ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier
Title: Message Title Martin Kouba updated WELD-2500 Weld / WELD-2500 ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier Change By: Martin Kouba 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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title Martin Kouba updated WELD-2506 Weld / WELD-2506 Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean Change By: Martin Kouba 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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title Martin Kouba updated an issue Weld / WELD-2506 Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean Change By: Martin Kouba Git Pull Request: https://github.com/weld/core/pull/1851 , https://github.com/weld/core/pull/1852 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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title Martin Kouba updated an issue Weld / WELD-2506 Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean Change By: Martin Kouba Fix Version/s: 3.0.5.Final 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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title Martin Kouba updated WELD-2506 Weld / WELD-2506 Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean Change By: Martin Kouba Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1851 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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title Martin Kouba updated an issue Weld / WELD-2506 Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean Change By: Martin Kouba 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] (WELD-2500) ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier
Title: Message Title Martin Kouba updated WELD-2500 Weld / WELD-2500 ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier Change By: Martin Kouba Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1850 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-2483) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
Title: Message Title Martin Kouba commented on WELD-2483 Re: WELD o.j.w.e.IllegalStateException after saved session does not auto-recover Auto-recovery might be tricky. I think this would deserve some deeper analysis and probably cooperation with WildFly and Infinispan teams. 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-2483) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
Title: Message Title Martin Kouba updated an issue Weld / WELD-2483 WELD o.j.w.e.IllegalStateException after saved session does not auto-recover Change By: Martin Kouba Fix Version/s: Unscheduled 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-2483) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
Title: Message Title Martin Kouba commented on WELD-2483 Re: WELD o.j.w.e.IllegalStateException after saved session does not auto-recover Darryl Miles FYI in your particular case the bean identifier index consists only of built-in HttpSession beans which are not indexed since 3.0.0.CR2 and 2.4.3.Final (see also WELD-2343). I.e. the index would be empty for WildFly 11+ and no exception would be thrown. 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-2509) Update JBoss Classfilewriter to 1.2.3.Final
Title: Message Title Martin Kouba resolved as Done Weld / WELD-2509 Update JBoss Classfilewriter to 1.2.3.Final Change By: Martin Kouba Status: Open 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-2512) cid not appended to action URLs if there is already a parameter with a name ending with "cid"
Title: Message Title Martin Kouba resolved as Done Weld / WELD-2512 cid not appended to action URLs if there is already a parameter with a name ending with "cid" Change By: Martin Kouba Status: Open 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-2415) Consider adding a handler interface for lazily-initialized dependencies
Title: Message Title
Martin Kouba commented on WELD-2415
Re: Consider adding a handler interface for lazily-initialized dependencies
A more general solution which should work with 3.0.2+ and 2.4.6+:
@Dependent
public class Lazy {
private final Handler handler;
@SuppressWarnings("unchecked")
@Inject
public Lazy(InjectionPoint injectionPoint, WeldInstance instance) {
ParameterizedType parameterizedType = (ParameterizedType) injectionPoint.getType();
Type requestedType = parameterizedType.getActualTypeArguments()[0];
this.handler = (Handler) instance.select(requestedType, injectionPoint.getQualifiers().toArray(new Annotation[] {})).getHandler();
}
[weld-issues] [JBoss JIRA] (WELD-2415) Consider adding a handler interface for lazily-initialized dependencies
Title: Message Title Martin Kouba updated an issue Weld / WELD-2415 Consider adding a handler interface for lazily-initialized dependencies Change By: Martin Kouba Fix Version/s: 3.1.x 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-2497) Weld API - make it possible to propagate built-in contexts
Title: Message Title Martin Kouba updated an issue Weld / WELD-2497 Weld API - make it possible to propagate built-in contexts Change By: Martin Kouba Fix Version/s: 3.1.x 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-2510) Different BeanManager for the same context across redeployments
Title: Message Title Martin Kouba resolved as Rejected Rejecting - this is an integration problem. Weld / WELD-2510 Different BeanManager for the same context across redeployments Change By: Martin Kouba Status: Open Resolved 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] (WELD-2510) Different BeanManager for the same context across redeployments
Title: Message Title Martin Kouba commented on WELD-2510 Re: Different BeanManager for the same context across redeployments arjan tijms I also think that javax.enterprise.inject.spi.CDI would deserve some improvements. Feel free to create a spec 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-2508) Methods added in our proxies should have more complex names
Title: Message Title Martin Kouba updated an issue Weld / WELD-2508 Methods added in our proxies should have more complex names Change By: Martin Kouba Fix Version/s: 3.1.x 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-2512) cid not appended to action URLs if there is already a parameter with a name ending with "cid"
Title: Message Title Martin Kouba commented on WELD-2512 Re: cid not appended to action URLs if there is already a parameter with a name ending with "cid" Vsevolod Golovanov These are good points! In any case, don't hesitate to add comments directly to 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-2512) cid not appended to action URLs if there is already a parameter with a name ending with "cid"
Title: Message Title Martin Kouba commented on WELD-2512 Re: cid not appended to action URLs if there is already a parameter with a name ending with "cid" I believe that the issue is that FacesUrlTransformer is looking for cid= and thus primefaces' pfdlgcid is also matched. So the FacesUrlTransformer should probably look for ?cid= and = instead. The truth is that those delimiters are probably not standardized, i.e. a web server may allow different query string param delimiters, but it should work in most cases. 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-2512) cid not appended to action URLs if there is already a parameter with a name ending with "cid"
Title: Message Title Martin Kouba updated an issue Weld / WELD-2512 cid not appended to action URLs if there is already a parameter with a name ending with "cid" Change By: Martin Kouba Fix Version/s: 3.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-2511) JsonObjects#createBuiltInDependency produces NPE for Instance injection sites
Title: Message Title Martin Kouba commented on WELD-2511 Re: JsonObjects#createBuiltInDependency produces NPE for Instance injection sites Hi Scott and thanks for the report. I believe this was fixed within WELD-2376, that means Weld 3.0.0+ and 2.4.4+; see also https://github.com/weld/core/blob/2.4/probe/core/src/main/java/org/jboss/weld/probe/JsonObjects.java#L1179-L1190. Unfortunately, Thorntail v2 is using Weld 2.4.3.Final because that's the version the WildFly it is based on is using. 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-2510) Different BeanManager for the same context across redeployments
Title: Message Title Martin Kouba commented on WELD-2510 Re: Different BeanManager for the same context across redeployments Hi Charles and thanks for the report. Using CDI.current() could be tricky, esp. for EAR scenarios. I would stick with JNDI lookups if using EARs. In any case, there is nothing we can do in Weld - CDI.current() is using a service provider of javax.enterprise.inject.spi.CDIProvider to obtain the current container and it's the responsibility of the integrator to provide a CDIProvider implementation. By the way, WildFly CDIProvider implementation has a workaround for soteria too. 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-2435) Java 9 jigsaw - weld-servlet-core WeldProvider not in module
Title: Message Title Martin Kouba commented on WELD-2435 Re: Java 9 jigsaw - weld-servlet-core WeldProvider not in module Leonardo Zanivan You're welcome. I don't think we publish snapshot builds. 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-2435) Java 9 jigsaw - weld-servlet-core WeldProvider not in module
Title: Message Title Martin Kouba updated an issue Weld / WELD-2435 Java 9 jigsaw - weld-servlet-core WeldProvider not in module Change By: Martin Kouba Fix Version/s: 3.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-2435) Java 9 jigsaw - weld-servlet-core WeldProvider not in module
Title: Message Title Martin Kouba updated WELD-2435 Weld / WELD-2435 Java 9 jigsaw - weld-servlet-core WeldProvider not in module Change By: Martin Kouba 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-2502) Make Weld-SE StartMain more compatible with container execution
Title: Message Title Martin Kouba updated an issue Weld / WELD-2502 Make Weld-SE StartMain more compatible with container execution Change By: Martin Kouba Fix Version/s: 3.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-2502) Make Weld-SE StartMain more compatible with container execution
Title: Message Title Martin Kouba updated WELD-2502 Weld / WELD-2502 Make Weld-SE StartMain more compatible with container execution Change By: Martin Kouba 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-2508) Methods added in our proxies should have more complex names
Title: Message Title Martin Kouba commented on WELD-2508 Re: Methods added in our proxies should have more complex names Theoretically speaking we shouldn't break anything by changing it as this is all a matter of Weld internals... I agree but in practice a lot of things might break . Therefore, I suggest to fix this in 3.1. 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-2443) Weld fails to invoke an observer method with a private access
Title: Message Title Martin Kouba commented on WELD-2443 Re: Weld fails to invoke an observer method with a private access Yes, see also WELD-2506. However, I'm not sure where exactly the problem is and how to fix it. 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-2443) Weld fails to invoke an observer method with a private access
Title: Message Title
Martin Kouba edited a comment on WELD-2443
Re: Weld fails to invoke an observer method with a private access
[~ steappe joeezar ] I can confirm that this special use case throws {{IllegalAccessError}} (conditional observer is not needed). I'm going to create a separate issue. Anyway, thanks for investigation!
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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title Martin Kouba updated an issue Weld / WELD-2506 Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean Change By: Martin Kouba Affects 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-2506) Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Title: Message Title
Martin Kouba created an issue
Weld / WELD-2506
Intercepted private observer method throws IllegalAccessError if notified within invocation of another business method of the declaring bean
Issue Type:
Bug
Assignee:
Unassigned
Created:
14/Jun/18 8:11 AM
Priority:
Major
Reporter:
Martin Kouba
@ApplicationScoped
@SomeInterceptorBinding // -> observer method is intercepted
public class Foo {
@Inject
Event event;
[weld-issues] [JBoss JIRA] (WELD-2443) Weld fails to invoke an observer method with a private access
Title: Message Title Martin Kouba commented on WELD-2443 Re: Weld fails to invoke an observer method with a private access Stéphane Appercel I can confirm that this special use case throws IllegalAccessError (conditional observer is not needed). I'm going to create a separate issue. Anyway, thanks for investigation! 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-2500) ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier
Title: Message Title Martin Kouba assigned an issue to Unassigned Weld / WELD-2500 ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier Change By: Martin Kouba Assignee: Martin Kouba 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-2504) weld-core has dependency with java.desktop module when using JPMS
Title: Message Title Martin Kouba updated an issue Weld / WELD-2504 weld-core has dependency with java.desktop module when using JPMS Change By: Martin Kouba Fix Version/s: 3.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-2504) weld-core has dependency with java.desktop module when using JPMS
Title: Message Title Martin Kouba updated WELD-2504 Weld / WELD-2504 weld-core has dependency with java.desktop module when using JPMS Change By: Martin Kouba 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-2498) FastAnnotatedTypeLoader should not create SlimAnnotatedTypeContext for local and anonymous classes
Title: Message Title Issue was automatically transitioned when Martin Kouba created pull request #1834 in GitHub Weld / WELD-2498 FastAnnotatedTypeLoader should not create SlimAnnotatedTypeContext for local and anonymous classes Change By: Martin Kouba 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-2500) ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier
Title: Message Title
Martin Kouba updated an issue
Weld / WELD-2500
ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier
Change By:
Martin Kouba
Consequently, {{BeforeDestroyed}} (CDI 2.0) events are not marked as container events and cannot be easily filtered 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-2443) Weld fails to invoke an observer method with a private access
Title: Message Title Martin Kouba commented on WELD-2443 Re: Weld fails to invoke an observer method with a private access Well, conditional observer makes no difference in my test. Do you still get an IllegalAccessError or how does the stack look like? 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-2500) ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier
Title: Message Title Martin Kouba created an issue Weld / WELD-2500 ProbeObserver.isContainerEvent() does not recognize BeforeDestroyed qualifier Issue Type: Bug Affects Versions: 3.0.4.Final Assignee: Martin Kouba Components: Development Tools (Probe) Created: 06/Jun/18 5:25 AM Fix Versions: 3.0.5.Final Priority: Optional Reporter: Martin Kouba Consequently, BeforeDestroyed events are not marked as container events and cannot be easily filtered out. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2443) Weld fails to invoke an observer method with a private access
Title: Message Title Martin Kouba commented on WELD-2443 Re: Weld fails to invoke an observer method with a private access But I still have this issue when declaring the interceptor on the class level of a class which contains the private observer method. Hm, I've tried to move the interceptor binding from the method to the class in our test and it passed. Could you expand on your particular use case? 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-2499) OSGi bundle does not optionally import org.apache.bcel
Title: Message Title Martin Kouba updated an issue Weld / WELD-2499 OSGi bundle does not optionally import org.apache.bcel Change By: Martin Kouba Fix Version/s: 3.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-2499) OSGi bundle does not optionally import org.apache.bcel
Title: Message Title Martin Kouba resolved as Done Weld / WELD-2499 OSGi bundle does not optionally import org.apache.bcel Change By: Martin Kouba Status: Open 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-2496) org.jboss.weld.literal.BeforeDestroyedLiteral may fail to initialize with a security manager
Title: Message Title Martin Kouba commented on WELD-2496 Re: org.jboss.weld.literal.BeforeDestroyedLiteral may fail to initialize with a security manager Well, there is already CDI-699 and we can send a PR but I'm afraid the release would take a lot of time. Antoine Sabot-Durand is there a way to do some "accelerated" maintenance release? Anyway, I wonder why it took so long to find this issue. This code is in CDI API since 1.0 (added a looong time ago). 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 Martin Kouba commented on WELD-2496 Re: org.jboss.weld.literal.BeforeDestroyedLiteral may fail to initialize with a security manager There was no reason to have it. 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 Martin Kouba resolved as Done Weld / WELD-2491 Update patching profiles for Weld 3 Change By: Martin Kouba Status: Open 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-2481) Qualifiers are missed in constructor injection point
Title: Message Title
Martin Kouba updated an issue
Weld / WELD-2481
Qualifiers are missed in constructor injection point
Change By:
Martin Kouba
Hello:I am from Oracle Wls team and working on Weld3 / Wls integration, a cdi-tck case failed in my test, the case is:org.jboss.cdi.tck.tests.context.passivating.broken.producer.field.enterprise.EnterpriseBeanWithIllegalDependencyTestThe stack trace is like: > {noformat} Caused by: java.lang.RuntimeException: CDI deployment failure:WELD-001413: The bean Session bean [class org.jboss.cdi.tck.tests.context.passivating.broken.producer.field.enterprise.ConstructorInjectionCorralBrokenwith qualifiers [@Any @Default]; local interfaces are [ConstructorInjectionCorralBroken] declares a passivating scope but has a non-passivation-capable dependency Managed Bean [class org.jboss.cdi.tck.tests.context.passivating.broken.producer.field.enterprise.Cow] with qualifiers [@Any @Default]: at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:466) at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:400) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:287) at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:140) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:161) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:504) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:479) at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:480) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90) at com.oracle.injection.provider.weld.WeldInjectionContainer.start(WeldInjectionContainer.java:150) < {noformat} The cdi-tck code is like: {code:java} package org.jboss.cdi.tck.tests.context.passivating.broken.producer.field.enterprise;public class Cow {}public class CowProducer {@Produces@Britishpublic Cow cow = new Cow();}@Stateful@SessionScopedpublic class ConstructorInjectionCorralBroken extends Corral {private Cow cow;public ConstructorInjectionCorralBroken(){}@Injectpublic ConstructorInjectionCorralBroken(@British Cow cow){ this.cow = cow;}...} {code} In deployment, the qualifier @British is missing in constructor injection point creation, so a @Default Cow injects into wrongly, which is not passivation capable and causes the exception. And the reason of qualifier missing is: {code:java} package org.jboss.weld.module.ejb;...class InternalEjbDescriptor extends ForwardingEjbDescriptor { ... public Class getImplementationClass() { if (delegate instanceof SubclassedComponentDescriptor) { SubclassedComponentDescriptor descriptor = Reflections.>cast(delegate); Class implementationClass = descriptor.getComponentSubclass(); if (implementationClass != null) {
