[weld-issues] [JBoss JIRA] (CDITCK-591) AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules
Title: Message Title
Mark Struberg edited a comment on CDITCK-591
Re: AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules
I think we have to look at 2 different pieces. The sentence quoted above regarding Disposer-Producer matching requires that the exact same *return type*. Not Type Closures, it _explicitly_ says "return type".This rule is violated by the exampleThe other point which is imo violated is that the type closure must only be a sub section of the original types. Let's look at the following sample:{code:java}@ApplicationScopedpublic class Dog extends Mammal (extends Animal) {..}{code}Now what if you change the Type Closure to 'Poodle'?This will simply blow up.I also don't see the practical use of the hack in this test.If you want to have automatic support for @Inject Tomato and @Inject Carrot then you can do this via collecting the info in ProcessInjectionPoint and register a custom Bean for each type.
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-591) AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules
Title: Message Title
Mark Struberg commented on CDITCK-591
Re: AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules
I think we have to look at 2 different pieces. The sentence quoted above regarding Disposer-Producer matching requires that the exact same return type. Not Type Closures, it explicitly says "return type". This rule is violated by the example The other point which is imo violated is that the type closure must only be a sub section of the original types. Let's look at the following sample:
@ApplicationScoped
public class Dog extends Mammal (extends Animal) {..}
Now what if you change the Type Closure to 'Poodle'? This will simply blow up. I also don't see the practical use of the hack in this test. If you want to have automatic support for @Inject Tomato and @Inject Carrot then you can do this via collecting the info in ProcessInjectionPoint and register a custom Bean for each type.
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-591) AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules
Title: Message Title Matej Novotny commented on CDITCK-591 Re: AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules I dare disagree, from my perspective, you are not restricting the set (you are not using @Typed at all btw) - you are replacing whole underlying AT with another one. Regarding spec, 2.2 and 3.2.1 basically says that unrestricted set of bean types is based on return type (and follows up with a precise definition how to derive that from interface/primitive/class). So yes, that holds true, until you start changing the method which is the case here. You basically take the existing one as a template, alter it and put in there instead. As with many custom things in extensions, you might break your code easily (e.g. your example with Tomato) but that's your problem, really. I think you are enforcing rules which aren't implied by spec and might be unnecessarily strict. Ofc we both might be wrong, so it would be nice if we get to hear some more opinions Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2401) Regression in BeanDeploymentModules registration
Title: Message Title Matej Novotny created an issue Weld / WELD-2401 Regression in BeanDeploymentModules registration Issue Type: Bug Affects Versions: 2.4.4.Final Assignee: Unassigned Created: 16/Jun/17 4:35 AM Priority: Critical Reporter: Matej Novotny Weld 2.4.4.Final causes test failures on WFLY. The test is an EAR without WAR but it has a library and one EJB jar; both of these observe @Initialized(AppplicationScoped.class). See WFLY-3334 for more information on that. The real problem is that we have introduced a stricter check in WELD-2389 and only register a module if an integrator implements our Environments API by adding exactly same set of services. However, this is not the case with WildFly - see WildFlyWeldEnvironment (transaction services are missing in order to make it EE environment). As a result of that, Weld fails to register a non-web module (and therefore doesn't fire those events for it later on). So there are two options here: Revert the change in Weld and go back to lenient check to permit this behaviour. Change code on WildFly side and try to "correct" this Might require special handling in regard to Swarm
