[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 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] (CDITCK-610) the CDI spec does not require Servlets to be interceptable
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-610 the CDI spec does not require Servlets to be interceptable Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 14/Feb/18 3:11 PM Priority: Major Reporter: Mark Struberg I did nowhere in the CDI spec find a word that Servlets must be interceptable. But exactly that is assumed by org.jboss.cdi.tck.tests.implementation.builtin.metadata.ee.BuiltinMetadataEEBeanTest Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-609) org.jboss.cdi.tck.tests.event.observer.priority.contextLifecycleEvent.ApplicationContextLifecycleEventObserverOrderingTest misses to package the TestExtension
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-609 org.jboss.cdi.tck.tests.event.observer.priority.contextLifecycleEvent.ApplicationContextLifecycleEventObserverOrderingTest misses to package the TestExtension Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 14/Feb/18 9:59 AM Priority: Major Reporter: Mark Struberg org.jboss.cdi.tck.tests.event.observer.priority.contextLifecycleEvent.ApplicationContextLifecycleEventObserverOrderingTest should add the TestExtension to the @Deployment. Otherwise this test fails on an EE server Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-608) LongRunningConversationLifecycleEventTest and others wrongly assume that Session get destroyed at shutdown
Title: Message Title Mark Struberg commented on CDITCK-608 Re: LongRunningConversationLifecycleEventTest and others wrongly assume that Session get destroyed at shutdown why not simply use Session.invalidate? That must trigger the BeforeDestroyed as well. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-608) LongRunningConversationLifecycleEventTest and others wrongly assume that Session get destroyed at shutdown
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-608 LongRunningConversationLifecycleEventTest and others wrongly assume that Session get destroyed at shutdown Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 07/Feb/18 4:06 PM Priority: Major Reporter: Mark Struberg Some tests wrongly assume that the Servlet Sessions will all get destroyed during shutdown. But that is not necessarily the case. An undeploy or shudown might passivate the Session to a storage and pick it up later again. This is perfectly valid from a Servlet perspective and CDI must follow those rules. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-607) EnterpriseBeanDiscoveryTest assumes that AnnotatedType class must reflect the @Local interface, but this is not backed by the spec
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-607 EnterpriseBeanDiscoveryTest assumes that AnnotatedType class must reflect the @Local interface, but this is not backed by the spec Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 07/Feb/18 12:57 PM Fix Versions: TBD Priority: Major Reporter: Mark Struberg EnterpriseBeanDiscoveryTest assumes that AnnotatedType class must reflect the @Local interface, but this is not backed by the spec. The TCK tests in question all refer to 26.1 and 26.2, but this dose nowhere even mention @Local. Furthermore the old spec didn't define this but the 'type of the EJB class which is parsed' Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-606) org.jboss.cdi.tck.tests.deployment.discovery.enterprise.annotated.EnterpriseDefaultBeanDiscoveryModeTest should fail because of ambiguous beans
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-606 org.jboss.cdi.tck.tests.deployment.discovery.enterprise.annotated.EnterpriseDefaultBeanDiscoveryModeTest should fail because of ambiguous beans Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 07/Feb/18 6:10 AM Priority: Major Reporter: Mark Struberg org.jboss.cdi.tck.tests.deployment.discovery.enterprise.annotated.EnterpriseDefaultBeanDiscoveryModeTest contains a class AppleTrea which has 2 producer for the same class+qualifier plus only one disposal method. @Produces static Apple apple = new Apple(); @Produces
[weld-issues] [JBoss JIRA] (CDITCK-604) create a TCK test for alternative sterotype + @Priority on the class
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-604 create a TCK test for alternative sterotype + @Priority on the class Issue Type: Enhancement Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 06/Dec/17 7:47 AM Priority: Major Reporter: Mark Struberg We currently have no test for an @Alternative @Stereotype which has a @Priority on the class it gets applied on. This should work according to the spec, but we miss a test. Basically a variation of org.jboss.cdi.tck.tests.alternative.selection.stereotype.SelectedBeanWithUnselectedStereotypeTest but not enabled via beans.xml but via @Priority on the class. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-602) Tests SpecializationModularity03 05 06 and 07 have wrong assumption
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-602 Tests SpecializationModularity03 05 06 and 07 have wrong assumption Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 25/Oct/17 7:16 AM Priority: Major Reporter: Mark Struberg It is perfectly possible to solve the situations defined in those tests. This is having the webapp using the @Specialized version vs the other parts using the original bean. Works perfectly fine if done right. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-601) SpecializationModularity*Test should be in the JAVAEE_FULL group
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-601 SpecializationModularity*Test should be in the JAVAEE_FULL group Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 25/Oct/17 7:11 AM Priority: Major Reporter: Mark Struberg SpecializationModularity*Test should be in the JAVAEE_FULL group as they test EAR behaviour. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-600) WrappedInjectionTargetTest assumes unspecified lifecycle behaviour
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-600 WrappedInjectionTargetTest assumes unspecified lifecycle behaviour Issue Type: Bug Affects Versions: 2.0.3.Final Assignee: Matej Novotny Components: Tests Created: 25/Oct/17 6:44 AM Priority: Major Reporter: Mark Struberg org.jboss.cdi.tck.tests.extensions.lifecycle.processInjectionTarget.WrappedInjectionTargetTest uses an @ApplicationScoped bean to 'transfer' information. But according to the spec, the Context for @ApplicationScoped beans is only active after AfterDeploymentValidation on. But the Servlet Container might set up Servlet Filters, Listeners etc way before that. Thus sending an event to an @ApplicationScoped bean in ProcessInjectionTarget is very unlikely to ever reach the intended audience. Thus this test is doomed to fail. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title Mark Struberg commented on WELD-2411 Re: Registering a custom Bean of Type Provider doesn't resolve to the right class Oki, I understand the point with Prioritized. 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-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title Mark Struberg commented on WELD-2411 Re: Registering a custom Bean of Type Provider doesn't resolve to the right class Oki, if I got this right then there might be 2 different things mixed up. Q1: is it allowed to register an Alternative to a built-in Bean, e.g. an @Alternative for Provider? Q2: what happens if you have an @Alternative Bean but there is no enabled Bean? Btw, I think it is perfectly allowed to have an Alternative Bean without any original Bean. 5.2.1. Unsatisfied and ambiguous dependencies An unsatisfied dependency exists at an injection point when no bean is eligible for injection to the injection point. An ambiguous dependency exists at an injection point when multiple beans are eligible for injection to the injection point. Note that an unsatisfied or ambiguous dependency cannot exist for a decorator delegate injection point, defined in Section 8.1.2, “Decorator delegate injection points”. When an ambiguous dependency exists, the container attempts to resolve the ambiguity. The container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable. So from a pure spec perspective all the Alternative evaluation is ONLY done if there is an ambiguity in the first place! Add Comment
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title
Mark Struberg edited a comment on WELD-2411
Re: Registering a custom Bean of Type Provider doesn't resolve to the right class
Oki, if I got this right then there might be 2 different things mixed up.Q1: is it allowed to register an Alternative to a built-in Bean, e.g. an @Alternative for Provider?Q2: what happens if you have an @Alternative Bean but there is no enabled Bean?Btw, I think it is perfectly allowed to have an Alternative Bean without any original Bean.{ noformat quote }5.2.1. Unsatisfied and ambiguous dependenciesAn unsatisfied dependency exists at an injection point when no bean is eligible for injection to the injection point. An ambiguous dependency exists at an injection point when multiple beans are eligible for injection to the injection point.Note that an unsatisfied or ambiguous dependency cannot exist for a decorator delegate injection point, defined in Section 8.1.2, “Decorator delegate injection points”.When an ambiguous dependency exists, the container attempts to resolve the ambiguity. The container eliminates all eligible beans that are not alternatives, except for producer methods and fields of beans that are alternatives. If there is exactly one bean remaining, the container will select this bean, and the ambiguous dependency is called resolvable.{ noformat quote }So from a pure spec perspective all the Alternative evaluation is ONLY done if there is an ambiguity in the first place!
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title Mark Struberg commented on WELD-2411 Re: Registering a custom Bean of Type Provider doesn't resolve to the right class Martin Kouba Where in the spec does it state that this is not legal? One could even create an Alternative for Instance and it would still be perfectly fine from a spec perspective! 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 reopened an issue CDI TCK / CDITCK-591 AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules Change By: Mark Struberg Resolution: Rejected Status: Resolved Reopened 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 Antoine Sabot-Durand I did not question that one can create inconsistent Beans. Nonetheless the rules for producer/disposal methods DO also apply to them. And if the 'return type' (which in the AT boils down to getBaseType) does not match, then the disposer and producer does not fit together. And this is exactly the case with this test - which renders the test as it currently is invalid. 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 Tomas Remes it would not violate the first restriction if it would return Carrot in getBaseType() ! But the wrapped AT violates this requirement by having a getTypeClosures() contain a class which is not contained in the the fully transitive type closure of getBaseType(). > The related disposal method has parameter with type Carrot Again, the spec paragraph clearly does not refer to type closures but to "return type". That's some different term and relates to getBaseType() in the AT afaict. 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 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
Mark Struberg created an issue
CDI TCK / CDITCK-591
AlternativeMetadataTest createVegetables and destroyVegetables violate Type Closure rules
Issue Type:
Bug
Affects Versions:
2.0.0.Final
Assignee:
Tomas Remes
Components:
Tests
Created:
15/Jun/17 2:53 PM
Priority:
Major
Reporter:
Mark Struberg
This test has actually quite a few shortcomings. It modifies the AnnotatedType for the createVegetables producer method to have a TypeClosure of {Carrot.class} (Carrot implements Vegetables). The problem is that this violates the rules for type closures (2.2). Type closures is by default the bean type and all it's interfaces, parent classes, etc. One can further restrict those classes via @Typed or by modifying the AnnotatedType. But it imo not allowed to have a Type in the TypeClosures which is not contained in e.g. the return type of a producer method. In the TCK test the producer method returns Vegetables and the test modifies it to a type closure of {Carrot.class} . So what happens if the producer method returns a new Tomato() ? The other point is that for matching producers and disposers the type closures is not taken into account as per the spec, but only the return type and the type of the dispose parameter. See
3.4.1. Disposed parameter of a disposer method Each disposer method must have exactly one disposed parameter, of the same type as the corresponding producer method return type or producer field type.
[weld-issues] [JBoss JIRA] (CDITCK-573) BeanConfiguratorTest operates on incomplete beans
Title: Message Title Mark Struberg commented on CDITCK-573 Re: BeanConfiguratorTest operates on incomplete beans +1 OWB actually blows up with an exception if neither the createCallback nor the produceCallback are set. We might add this to the spec. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-589) AnnotatedTypeConfiguratorTest fails randomly
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-589 AnnotatedTypeConfiguratorTest fails randomly Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 07/Jun/17 3:58 PM Priority: Major Reporter: Mark Struberg AnnotatedTypeConfiguratorTest modifies the constructors of 'Cat' in an ambiguous way. In org.jboss.cdi.tck.tests.extensions.configurators.annotatedTypeConfigurator.ProcessAnnotatedTypeObserver#98 // remove @Inject and @Cats from constructor with parameter annotatedTypeConfigurator.filterConstructors(ac -> ac.getParameters().size() > 0).findFirst().get().remove(a -> a.equals(InjectLiteral.INSTANCE)) .filterParams(ap -> ap.getPosition() == 0).findFirst().get().remove(a -> a.equals(Cats.CatsLiteral.INSTANCE));
[weld-issues] [JBoss JIRA] (CDITCK-588) AnnotatedTypeConfiguratorTest#annotatedTypesAndMemebersEqual wrongly assumes that AnnotatedTypes implement equals()
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-588 AnnotatedTypeConfiguratorTest#annotatedTypesAndMemebersEqual wrongly assumes that AnnotatedTypes implement equals() Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 07/Jun/17 3:50 PM Priority: Major Reporter: Mark Struberg AnnotatedTypeConfiguratorTest#annotatedTypesAndMemebersEqual wrongly assumes that AnnotatedTypes implement equals(). But I could not find where this would be defined. In fact there are quite a few cases where identity equality makes much more sense and I could not find any good use case where one needs equals on AT. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title
Mark Struberg edited a comment on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
[~mkouba] Let's get back to your sample. I don't quite get it.You said one might be able to add another Bean implementing Baz and that would work? I cannot see how this should work, please help me to understand what you meant.{code:java}@ApplicationScopedpublic class OtherFoo implements Baz { ..}{code}As far as I understand you would then get an AmbiguousResolutionException. The bean resolving algorithm doesn't care whether a Bean is proxyable or not. So you would end up with Bean and Bean for the InjectionPoint @Inject Baz baz; Or does Weld behave different in that case?Regarding my reference to Instance and Provider:Neither the atinject nor the CDI specification define that those methods return a 'Contextual Reference'.The CDI spec says in the Instance section:{ qoute quote }The Instance interface provides a method for obtaining instances of beans..{ qoute quote }Thus my question what Weld does. According to your interpretation a CDI container must not blow up with an UnproxyableResolutionExceptionthen because it's not specified. Again: I strongly believe that both Weld and OWB operate well within the intention and wording of the spec. What about using an Injected Arquillian deployer and check whether the UnproxyableResolutionException *either* gets thrown during bootstrap _or_ during the actual use of this bean?
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title
Mark Struberg commented on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Martin Kouba Let's get back to your sample. I don't quite get it. You said one might be able to add another Bean implementing Baz and that would work? I cannot see how this should work, please help me to understand what you meant.
@ApplicationScoped
public class OtherFoo implements Baz { ..}
As far as I understand you would then get an AmbiguousResolutionException. The bean resolving algorithm doesn't care whether a Bean is proxyable or not. So you would end up with Bean and Bean for the InjectionPoint @Inject Baz baz; Or does Weld behave different in that case? Regarding my reference to Instance and Provider: Neither the atinject nor the CDI specification define that those methods return a 'Contextual Reference'. The CDI spec says in the Instance section: {qoute} The Instance interface provides a method for obtaining instances of beans..{qoute} Thus my question what Weld does. According to your interpretation a CDI container must not blow up with an UnproxyableResolutionExceptionthen because it's not specified. Again: I strongly believe that both Weld and OWB operate well within the intention and wording of the spec. What about using an Injected Arquillian deployer and check whether the UnproxyableResolutionException either gets thrown during bootstrap or during the actual use of this bean?
Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' I looked at the test again and afaict it was effectively disabled for 1.1 as it belonged to an unknown (and thus not enabled) testng Group. But let's take a step back and see what all the rules are for: 3.11 covers that any unproxyable bean which gets used in an InjectionPoint must lead to a deployment error. Both Weld and OWB behave correctly in that regard, right? 6.5.4 covers that any call to BeanManager#getReference must not hand out unproxyable beans. Weld does solve this by blowing up at the time a user calls this method, OWB solves this by detecting this situation even earlier. Both are perfectly spec compliant regarding 6.5.4 because they do not hand out unproxyable beans. What is left missing is the following cases: @Inject Instance instance; @Inject Provider provider; beanManager.getContext(RequestScoped.class).get(Contextual bean) And probably even more. Not sure what Weld does for them. OWB also detects these problems during bootstrap. Do you see anything where one of the containers contradict the spec from a user perspective? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Martin Kouba What, why? CDI 1.0 wording is: "If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem." But the test does NOT test this! The test does NOT have any Injection Point! The correct test to prove this section would be to have an unproxyable bean plus another Bean which injects this bean. And then verify that a deployment problem occurs! That's what this paragraph describes. But the current test checks for way more and implies behaviour which is not covered by the spec and even contradicts the CDI 1.0 TCK directly! Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Oh, one more: If this rule is really that way since CDI-1.0, then please try to run that exact test with Weld-1.x^! You will see that it will blow up... Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg edited a comment on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' No [~antoinesabot-durand] This is wrong!The test got changed because of WELD-1052 which was only Weld-2.x!Originally in CDI-1.0 it was REQUIRED to fail at boot time!The CDI-1.0 TCK did REQUIRE to fail at boot!That was the ORIGINAL behaviour and is still valid!Of course, one possible interpretation of the spec wording is that is not required to fail at boot. But it's also not forbidden!The current version of the test is just pinning down Weld specific behaviour and even contradicts JSR-299! Please check the revision history of this test! 576d4f5d2b489fa0ed76e Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' No Antoine Sabot-Durand This is wrong! The test got changed because of WELD-1052 which was only Weld-2.x! Originally in CDI-1.0 it was REQUIRED to fail at boot time! The CDI-1.0 TCK did REQUIRE to fail at boot! That was the ORIGINAL behaviour and is still valid! Of course, one possible interpretation of the spec wording is that is not required to fail at boot. But it's also not forbidden! The current version of the test is just pinning down Weld specific behaviour and even contradicts JSR-299! Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Btw we have now changed our algorithm. It now parses the bytecode at boot time and detects BeanManager#getReferences and Instance#get and Select calls to those beans at startup. Would that be illegal? Doubt that! Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg reopened an issue EG needs to clarify this. CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Change By: Mark Struberg Resolution: Rejected Status: Resolved Reopened Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' +1 for Romains argument. Antoine Sabot-Durand your argument would be true with a "IF, AND ONLY IF" phrase. But since this is not there it is not required. And to be honest it also makes sense that way. The test scenario should trigger an error, right? And it triggers that error in Weld and OWB. But at some slightly different point in time. That's really all! Oh one more. If one would follow the strict interpretation, then the following should also NOT cause an Exception: @Inject Instance boomBaby; Because this is NOT an InjectionPoint of 'NonProxyableBean'. But that imo clearly should get detected at bootstrap time as well imo. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title
Mark Struberg edited a comment on CDITCK-584
Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
{quote} legacy libraries which contain CDI NormalScoped beans? {quote} C'mon ;)I give you another thing to think:You create a library jar which contains a few CDI Beans. They are intended to be used in other projects and by accident you do not touch them in your test suite.You will never figure that you have an actually broken bean. And yes, it's exactly that: a broken CDI bean!So now again please tell me where it's written that this detection must NOT be done already at startup?
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' legacy libraries which contain CDI NormalScoped beans? C'mon I give you another thing to think: You create a library jar which contains a few CDI Beans. They are intended to be used in other projects and by accident you do not touch them in your test suite. You will never figure that you have an actually broken bean. And yes, it's exactly that: a broken CDI bean! So now again please tell me where it's written that this detection must NOT be done already at startup? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Why would one then use @ApplicationScoped on a bean which is not intended to be used in CDI? That makes no sense at all to me. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg commented on CDITCK-584 Re: UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' That doesn't define that it's disallowed to detect those issues earlier - during deployment (as required by the spec). That test is illegal anyway. Because if we follow your interpretation then there is NO requirement for testing for unproxyable beans during runtime! The spec clearly only defines that the validation must happen during bootstrap - but no further behaviour at runtime is specified. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-584) UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error'
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-584 UnproxyableManagedBeanTest assumes detection at runtime, but the spec requires a 'deployment error' Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 30/May/17 3:14 PM Priority: Major Reporter: Mark Struberg UnproxyableManagedBeanTest assumes that only invocation of unproxyable beans at runtime lead to an UnproxyableResolutionException. But this clearly contradicts the specification (same wording since 1.0): See 3.11 Unproxyable Bean Types "Otherwise, the container automatically detects the problem, and treats it as a deployment problem." Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-583) org.jboss.cdi.tck.tests.definition.stereotype.broken.nonEmptyNamed.NonEmptyNamedTest needs to define a Bean with the stereotype
Title: Message Title Mark Struberg commented on CDITCK-583 Re: org.jboss.cdi.tck.tests.definition.stereotype.broken.nonEmptyNamed.NonEmptyNamedTest needs to define a Bean with the stereotype Oki will verify. 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-582) BeanDiscoveryTest causes AmbiguousResolutionException
Title: Message Title Mark Struberg commented on CDITCK-582 Re: BeanDiscoveryTest causes AmbiguousResolutionException Ouch this is this weirdo rule that jars which contain an Extension are not implicit BDAs Yes, while I personally find this rule extremely weird, it nonetheless does exist. Ok to reject. 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-583) org.jboss.cdi.tck.tests.definition.stereotype.broken.nonEmptyNamed.NonEmptyNamedTest needs to define a Bean with the stereotype
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-583 org.jboss.cdi.tck.tests.definition.stereotype.broken.nonEmptyNamed.NonEmptyNamedTest needs to define a Bean with the stereotype Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 30/May/17 7:53 AM Priority: Major Reporter: Mark Struberg org.jboss.cdi.tck.tests.definition.stereotype.broken.nonEmptyNamed.NonEmptyNamedTest contains a broken StereoType. But this StereoType is not even used in any Bean. There is a class FallowDeer_Broken, but this is NOT annotated with any bean-defining-annotation. And since there is also no beans.xml we end up with no single Bean Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-582) BeanDiscoveryTest causes AmbiguousResolutionException
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-582 BeanDiscoveryTest causes AmbiguousResolutionException Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 30/May/17 7:23 AM Priority: Major Reporter: Mark Struberg BeanDiscoveryTest has a @RequestScoped LegacyAlpha bean plus it adds the AnnotatedType (without any change) via an Extension. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-579) CustomBeanImplementationTest relies on unspecified usage of InjectionPoint
Title: Message Title
Mark Struberg commented on CDITCK-579
Re: CustomBeanImplementationTest relies on unspecified usage of InjectionPoint
Uff, about 30 different usages. E.g in the InjectionPointProducer, DecoratorInjectionFactory etc But the main use case is probably the InjectionTargetImpl.
for (InjectionPoint injectionPoint : getInjectionPoints())
{
if (injectionPoint.getMember().getDeclaringClass().equals(type))
This happens in various situations, while injecting fields, members, parameters, etc.
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-581) DynamicLookupTest#testDuplicateBindingsThrowsException should not lead to an Exception
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-581 DynamicLookupTest#testDuplicateBindingsThrowsException should not lead to an Exception Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 29/May/17 1:51 PM Priority: Major Reporter: Mark Struberg org.jboss.cdi.tck.tests.lookup.dynamic.DynamicLookupTest#testDuplicateBindingsThrowsException checks that there are no duplicate Qualifier bindings. But the 2 provided Qualifiers instances are actually different! So I assume that this test doesn't take the new rules of repeatable annotations into account. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-580) illegal TCK test for indirect specialization
Title: Message Title Mark Struberg commented on CDITCK-580 Re: illegal TCK test for indirect specialization Yes you are right, the sample was dumb I also had a few more thoughts. After thinking a few hours about it I took a step back. You know what? In all the soon 10 years of working on CDI in big projects I've not often seen indirect specialization. And I never saw that the qualifier got changed. Do you guys have any other impression? In the end we are fighting about an almost purely academical problem which has no practical impact 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-577) org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest#testRawBeanTypes swallows ParameterizedType
Title: Message Title Mark Struberg commented on CDITCK-577 Re: org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest#testRawBeanTypes swallows ParameterizedType That would be really great, thanks for considering it! Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-580) illegal TCK test for indirect specialization
Title: Message Title Mark Struberg commented on CDITCK-580 Re: illegal TCK test for indirect specialization No, read the comments, e.g. from Pete > It would also be highly weird that if you added a parent class to the bean that has been specialised, that the name would magically change. And my own message which remained unchallenged: http://lists.jboss.org/pipermail/cdi-dev/2014-June/005089.html Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-580) illegal TCK test for indirect specialization
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-580 illegal TCK test for indirect specialization Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 29/May/17 5:01 AM Priority: Major Reporter: Mark Struberg SimpleBeanSpecializationTest#testIndirectSpecialization() assumes that qualifiers of 'inbetween' specialisations should also get picked up. But this contradicts the spec 4.3.1. Direct and indirect specialization ... Formally, a bean X is said to specialize another bean Y if either: • X directly specializes Y, or • a bean Z exists, such that X directly specializes Z and Z specializes Y. Then X will inherit the qualifiers and name of Y: It does intentionally NOT say "Then X will inherit the qualifiers and name of Y and Z" So having a class @Specializes @Lazy LazyFarmer extends Farmer class @Specializes @Landlord Farmer extends Human class Human Should per spec lead to LazyFarmer having @Lazy and @Default, but not @Landlord! Also compare this with the wording for @Named which is really the same! And you also do not pickup any @Named from the 'intermediate' beans, right?
[weld-issues] [JBoss JIRA] (CDITCK-577) org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest#testRawBeanTypes swallows ParameterizedType
Title: Message Title Mark Struberg commented on CDITCK-577 Re: org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest#testRawBeanTypes swallows ParameterizedType In OWB we created an own ParameterizedTypeImpl to solve this problem. So this is a perfectly resolvable problem and we should not limit this in the spec just becuase Weld didn't implement it. 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-579) CustomBeanImplementationTest relies on unspecified usage of InjectionPoint
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-579 CustomBeanImplementationTest relies on unspecified usage of InjectionPoint Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 27/May/17 12:19 PM Priority: Major Reporter: Mark Struberg Not sure why, but CustomBeanImplementationTest#testInjectionPointGetMemberIsUsedToDetermineTheClassThatDeclaresAnInjectionPoint seems to presume that InjectionPoint#getMember() gets triggered during bootstrap. But that is simply not the case in OWB. It's also nowhere defined that this should be. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-432) some TCK tests assume InjectionPoints in decorators and interceptors are working
Title: Message Title Mark Struberg reopened an issue This still seems not resolved. It is ambiguous. The underlying change got revoked as far as I understand. See CDI-78. CDI TCK / CDITCK-432 some TCK tests assume InjectionPoints in decorators and interceptors are working Change By: Mark Struberg Resolution: Partially Completed Status: Resolved Reopened 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-577) org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest#testRawBeanTypes swallows ParameterizedType
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-577 org.jboss.cdi.tck.tests.definition.bean.BeanDefinitionTest#testRawBeanTypes swallows ParameterizedType Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 26/May/17 5:26 PM Priority: Major Reporter: Mark Struberg I don't get why the bean.getTypes() should contain MySuperInterface.class instead of the actual ParameterizedType MySuperInterface. After all getTypes() returns a Set and not a Set! Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-576) BuiltinBeanPassivationDependencyTest#testInjectionPoint uses equals on the IP which is not defined
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-576 BuiltinBeanPassivationDependencyTest#testInjectionPoint uses equals on the IP which is not defined Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 26/May/17 3:55 PM Priority: Major Reporter: Mark Struberg testInjectionPoint uses equals on the InjectionPoint. But the Spec doesn't define that an InjectionPoint must implement equals. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-576) BuiltinBeanPassivationDependencyTest#testInjectionPoint uses equals on the IP which is not defined
Title: Message Title Mark Struberg commented on CDITCK-576 Re: BuiltinBeanPassivationDependencyTest#testInjectionPoint uses equals on the IP which is not defined the code in question is assertEquals(inspectorCopy.getInjectionPoint(), inspector.getInjectionPoint()); Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers > and used to load classes But even this is not working, right? Try it out to load a class from your WAR with this TCCL. It will most likely not work. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Matej Novotny DeltaSpike is by far not the only framework which relies on the TCCL. Both MyFaces and Mojarra do as well. As do all JPA Implementations, and many other EE frameworks. So by not having the TCCL set up correctly you basically trash most of JavaEE in EARs if respective features get accessed during startup. That's the reason why the JavaEE umbrella spec explicitly defines that applications can rely that the TCCL has been set up. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Matej Novotny EE.6.2.3.7 Context Class Loader Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Martin Kouba An application can rely (as per the EE umbrella spec) that a TCCL is set. But I agree with you that it's not in the CDI container responsibility to provide this setup. I don't know how the CDI could even do that because it does most likely not even have the necessary information. This setup has to be done by the EE container. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers Martin, this is actutally PERFECTLY well defined in the EE spec. The TCCL MUST be set up for all application method invocations! It's just that it's not part of CDI but the EE umbrella spec. > Mark, I have no idea what you're talking about. Section B in https://struberg.wordpress.com/2015/02/18/cdi-in-ears/ This is how WebSphere8 and Tomee-1.x was set up and this works rather well for EARs. At least better than treating all the EAR as one big ball of mud... Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2381) Set web application classloader as TCCL when calling observers
Title: Message Title Mark Struberg commented on WELD-2381 Re: Set web application classloader as TCCL when calling observers I don't agree that this is not possible with Weld. Of course it would be quite some work to do it, but there is no technical show stopper afaict. You might probably need to swap out the Bean for @ApplicationScoped to properly support equals across different BeanManagers. But that should be it. 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-509) VetoTest is based on invalid spec wording
Title: Message Title Mark Struberg commented on CDITCK-509 Re: VetoTest is based on invalid spec wording Again: if you play with changing types and isAlternative then you might end up with PBA not getting fired for AnnotatedTypes which will later end up as enabled Beans. Not that this is an everyday problem, but it might happen. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-509) VetoTest is based on invalid spec wording
Title: Message Title Mark Struberg commented on CDITCK-509 Re: VetoTest is based on invalid spec wording Oh I think we missed the most obvious chicken-egg problem yet: The spec currently defines that ProcessBeanAttributes must ONLY get fired for 'enabled' beans. But if you use ProcessBeanAttributes#veto() then this bean is not enabled anymore... Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-509) VetoTest is based on invalid spec wording
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-509 VetoTest is based on invalid spec wording Issue Type: Feature Request Affects Versions: 1.2.8.Final Assignee: Tomas Remes Components: Tests Created: 12/Feb/16 5:03 AM Priority: Major Reporter: Mark Struberg The current org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.specialization.VetoTest also verifies that a ProcessBeanAttributes does not get fired for AnnotatedTypes which are likely to end up as disabled Bean. There are 2 problems with this behaviour as outlined in CDI-581 a.) the whole approach is not deterministic as it has an implicit chicken-egg problem b.) the spec wording "if the class is an enabled bean,.." is simply wrong. There is no 'enabled bean' at this early stage! This might have been a copy error while moving the wording from ProcessBean (which has no veto and thus is deterministic) to ProcessBeanAttributes (which has a veto and can also amend other enable-relevant information). Probably it's also a mixture with ProcessAnnotatedType? It should rather test if AnnotatedTypes which got vetoed (via annotation and also via PAT#veto()) does not result in a ProcessBeanAttributes.
[weld-issues] [JBoss JIRA] (CDITCK-509) VetoTest is based on invalid spec wording
Title: Message Title
Mark Struberg commented on CDITCK-509
Re: VetoTest is based on invalid spec wording
The same problem might apply to org.jboss.cdi.tck.tests.extensions.lifecycle.processBeanAttributes.VerifyValuesTest.
There is a class
@Alternative
public class Mike {}
and the test checks that there is no ProcessBeanAttributes fired for this class (because it's a not-enabled alternative). But what happens if I would like to return false in BeanAttributes#isAlternative(). Whether that bean ends up enabled or not can imo only be judged after ProcessBeanAttributes.
Add Comment
This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Mark Struberg commented on CDITCK-482 Re: SessionContextListenerShutdownTest relies on non-specified behaviour ApplicationShutdownLifecycleTest is also affected. What if we set distributablefalse in the web.xml? Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Mark Struberg commented on CDITCK-482 Re: SessionContextListenerShutdownTest relies on non-specified behaviour As pointed out by ~mkouba setting distributable wont help much. See servlet-3.0 spec 10.8 A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-482) SessionContextListenerShutdownTest relies on non-specified behaviour
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-482 SessionContextListenerShutdownTest relies on non-specified behaviour Issue Type: Feature Request Affects Versions: 1.2.4.Final Assignee: Tomas Remes Created: 16/May/15 1:58 PM Priority: Major Reporter: Mark Struberg SessionContextListenerShutdownTest relies on sessionDestroyed getting invoked on undeploy. But this is actually not defined by the servlet spec. Many containers really don't call this. Instead they serialize away the Session to disc or to another cluster node and then de-serialize them back again. In which case the Session continues as nothing has happened. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-480) ClientConversationContextTest checks for a 'nocid' parameter which doesn't exist in the spec
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-480 ClientConversationContextTest checks for a 'nocid' parameter which doesn't exist in the spec Issue Type: Bug Affects Versions: 1.2.4.Final Assignee: Tomas Remes Components: Tests Created: 13/May/15 11:47 AM Priority: Major Reporter: Mark Struberg org.jboss.cdi.tck.tests.context.conversation.ClientConversationContextTest#testSuppressedConversationPropagation seems to test for a 'nocid' parameter which does not exist in the spec. Please remove these lines. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-467) SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans
Title: Message Title Mark Struberg commented on CDITCK-467 Re: SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans I c but there are another TCK tests which require that ProcessBeanAttributes get set for specialized away beans. This test modifies them and change the specialization chain. So have 2 options: 1.) Evaluate the specialization chain upfront, don't fire PBA for specialized away beans but do NOT allow ProcessBeanAttributes to change anything in it's specialization state. 2.) Fire PBA also for specialized away beans and thus have a way to properly change the specialization state. Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-467) SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans
Title: Message Title Mark Struberg commented on CDITCK-467 Re: SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans Your quote even says there IS a bean: that the second BEAN is never instantiated or called Still this doesn't say anything about BeanAttributes. Btw, there is still a certain mixup between BeanT and it's contextual intance left in the spec... There is also another issue open which affects this behaviour. In ProcessBeanAttributes you can change the attributes in a way that the specialization chain gets changed. And thus we NEED to invoke it. If this isn't done in Weld, then you might have a hole in there. At least in theory, as I'm not sure if there are many extensions who rely on such nerdy tricks So I really think this is minor minor minor, but still the TCK should not test this. The spec simply doesn't say anything specific about it. Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-467) SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans
Title: Message Title Mark Struberg commented on CDITCK-467 Re: SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans VerifyValuesTest#testManagedBeanAttributes doe the same for not enabled @Alternatives. Despite the spec even explicitly says that not-enabled alternatives are 'disabled beans' (and thus ARE Beans). Add Comment This message was sent by Atlassian JIRA (v6.3.11#6341-sha1:83c4d29) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-467) SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-467 SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans Issue Type: Feature Request Affects Versions: 1.2.4.Final Assignee: Tomas Remes Created: 07/Mar/15 11:07 AM Priority: Major Reporter: Mark Struberg SpecializationTest wrongly assumes that ProcessBeanAttribute does not get called for specialized beans. The spec says nothing about when the 'disabling' of specialized away beans is to be performed or how this is done. Thus it also doesn't define whether ProcessBeanAttributes gets called for those beans. Pretty much the only thing the spec defines is that those beans shall not get found by BeanManager#getBeans(). Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-466) AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-466 AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine Issue Type: Bug Affects Versions: 1.2.4.Final Assignee: Tomas Remes Created: 03/Mar/15 10:14 AM Priority: Major Reporter: Mark Struberg AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine. There is nothing in the spec which says that a non-normalscope cannot be passivating. The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy. Actually the test should come in 2 flavours: 1.) RomanEmpire being Serializable - all fine must work 2.) RomainEmpire not Serializable - DefinitionException Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-459) cycle in Wizzard class producer
Title: Message Title
Mark Struberg created an issue
CDI TCK / CDITCK-459
cycle in Wizzard class producer
Issue Type:
Feature Request
Affects Versions:
1.1.5.Final
Assignee:
Tomas Remes
Components:
Tests
Created:
14/Dec/14 3:59 AM
Priority:
Major
Reporter:
Mark Struberg
org.jboss.cdi.tck.tests.implementation.enterprise.newBean.Wizard has a cycle which is very similar to the constellation of
CDITCK-427
.
@RequestScoped
public class Wizard {
[weld-issues] [JBoss JIRA] (CDITCK-458) ProcessBeanTest and ProcessSessionBeanTest use the same class with static counters
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-458 ProcessBeanTest and ProcessSessionBeanTest use the same class with static counters Issue Type: Bug Affects Versions: 1.0.7.Final Assignee: Tomas Remes Components: Tests Created: 25/Nov/14 5:23 PM Priority: Major Reporter: Mark Struberg org.jboss.jsr299.tck.tests.extensions.processBean.ProcessBeanTest and ProcessSessionBeanTest in the same package both scan and process Cat.class. The number of processings will get counted in a static ProcessBeanObserver.catProcessBeanCount. Now if ProcessSessionBeanTest randomly runs before ProcessBeanTest we get 4 instead of 2 in catProcessBeanCount Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-449) specify types with @Typed
Title: Message Title Mark Struberg commented on CDITCK-449 Re: specify types with @Typed But in that case Annotated#getTypeClosures() would be totally useless and always be the same as getBaseType() + superclasses. The description of Annotated#getTypeClosure() strongly indicates that @Typed must get applied to AnnotatedType already. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-444) TCK tests that getStereotypes() must not be null
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-444 TCK tests that getStereotypes() must not be null Issue Type: Bug Assignee: Tomas Remes Created: 12/Sep/14 2:10 AM Priority: Major Reporter: Mark Struberg Actually the spec says that Bean#getStereotypes() must only return valid stereotypes. Which means that it should complain if a class which is not a Stereotype gets returned. Otoh null is a perfectly valid value and shall just get handled the same like an empty Set for that matter. This happens in InvalidStereotypeExtension as detected by Reinhard Sandtner. Maybe you wanted to return PlainOldAnnotation.class instead of null? Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1)
[weld-issues] [JBoss JIRA] (CDITCK-444) TCK tests that getStereotypes() must not be null
Title: Message Title Mark Struberg commented on CDITCK-444 Re: TCK tests that getStereotypes() must not be null Yes, WE can avoid null, but this is something user Extensions do implement. And we could get quite a few of them around which return null in various cases. I'd rather keep the container as forgiving as possible and only complain about really wrong situations. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-439) YoghurtConstructor and other normalscoped classes miss a default ct
Title: Message Title Mark Struberg commented on CDITCK-439 Re: YoghurtConstructor and other normalscoped classes miss a default ct I did re-read it as I could not believe it - but it seems you are right. So this is not a bug in Weld if it doesn't detect this programming error. For the record: if you write a @RequestScoped bean without a default ct, then you cannot use it. Not via @Inject, nor via @EJB nor via BeanManager#getReference, Provider or Instance... It would just trash at runtime. Imo this is a clear programming error from the user. Please note that the spec defines in which cases the container must detect a problem - but it doesn't say that other cases must work. In OWB we just detect those cases as bugs as well. This is of course not required, but also not forbidden. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-436) tests with @ShouldThrowException in Extensions must not later try to use the BeanManager
Title: Message Title Mark Struberg commented on CDITCK-436 Re: tests with @ShouldThrowException in Extensions must not later try to use the BeanManager indeed this fixed our issue! Txs for the pointer! Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-438) InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
Title: Message Title Mark Struberg commented on CDITCK-438 Re: InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml It seems the broken decorator tests also do not enable their Decorators... Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-439) YoghurtConstructor and other normalscoped classes miss a default ct
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-439 YoghurtConstructor and other normalscoped classes miss a default ct Issue Type: Feature Request Affects Versions: 1.2.1.Final Assignee: Tomas Remes Created: 07/Sep/14 3:19 PM Priority: Major Reporter: Mark Struberg There are quite a few tests which heavily rely on the order of failure detection and thus work on Weld only by accident! For example in the org.jboss.cdi.tck.tests.implementation.builtin.metadata.broken.typeparam.YoghurtConstructor which contains a wrong injection point but ALSO misses the default ct for this NormalScoped bean. And OWB fails with finding this error and thus throws the 'wrong' exception - which is nontheless correct... Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-438) InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-438 InterceptorTypeParamFieldTest must either use @Priority or add the interceptors to beans.xml Issue Type: Bug Assignee: Tomas Remes Created: 06/Sep/14 3:47 PM Priority: Major Reporter: Mark Struberg InterceptorTypeParamFieldTest and the other tests in the same package define interceptors which are NOT enabled. They have no @Priority nor are they defined in beans.xml. Thus they do not need to get checked and thus don't throw the expected DefinitionException. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1)
[weld-issues] [JBoss JIRA] (CDITCK-436) tests with @ShouldThrowException in Extensions must not later try to use the BeanManager
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-436 tests with @ShouldThrowException in Extensions must not later try to use the BeanManager Issue Type: Feature Request Affects Versions: 1.2.2.Final Assignee: Tomas Remes Created: 02/Sep/14 5:45 PM Priority: Major Reporter: Mark Struberg Security Level: Public (Everyone can see) This happens in e.g WithAnnotationsAppliedToIllegalContainerLifecycleEventParameterTest Our container blows up with the expected DefinitionException. But if we detect a failure in an Extension, we stop the whole deployment. Thus the CDIInjectionEnricher called a bit later will fail, which is perfectly fine. Add Comment
[weld-issues] [JBoss JIRA] (CDITCK-432) some TCK tests assume InjectionPoints in decorators and interceptors are working
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-432 some TCK tests assume InjectionPoints in decorators and interceptors are working Issue Type: Bug Affects Versions: 1.2.1.Final Assignee: Tomas Remes Components: Tests Created: 08/Jul/14 3:52 AM Priority: Major Reporter: Mark Struberg Security Level: Public (Everyone can see) I struggle with a few TCK tests which assume that in Decorators and Interceptors you can have an @Inject ct which has a valid InjectionPoint. But I cannot find in the spec how this is supposed to work. 5.5.7 defines in which situations the CDI container must create an InjectionPoint: An instance of InjectionPoint may represent: • an injected field or a parameter of a bean constructor, initializer method, producer method, disposer method or observer method, or • an instance obtained dynamically using Instance.get().
[weld-issues] [JBoss JIRA] (CDITCK-427) NormalSelfConsumingDependentProducer is illegal
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-427 NormalSelfConsumingDependentProducer is illegal Issue Type: Feature Request Assignee: Tomas Remes Components: Tests Created: 29/Jun/14 2:47 PM Priority: Major Reporter: Mark Struberg Security Level: Public (Everyone can see) NormalSelfConsumingDependentProducer is an illegal class. This class contains a producer method for a @Dependent scoped bean 'Violation' and also an injection point for this very bean. So for invoking the producer method on the bean we first need to inject all @Inject ct, fields, methods and then call any @PostConstruct method. And only AFTER that we are allowed to invoke the producer method. This is not perfectly clear from the CDI spec itself, but you can deduct this from JSR-250 @PostConstruct wording. (see 'must not be put into service'). But we cannot @Inject Violation before we have the owner bean class created...
[weld-issues] [JBoss JIRA] (CDITCK-422) testSpecializingBeanHasNameOfSpecializedBean seems to contradict 4.3.1
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-422 testSpecializingBeanHasNameOfSpecializedBean seems to contradict 4.3.1 Issue Type: Feature Request Affects Versions: 1.2.0.Final Assignee: Martin Kouba Created: 02/Jun/14 7:24 PM Priority: Major Reporter: Mark Struberg Security Level: Public (Everyone can see) LazyFarmer @Specializes extends Farmer @Named Farmer @Specializes extends Human Human is a plain pojo 3.4.1 defines that for X-Z-Y only Y counts. Z is kind of 'invisible'. But as 'Human' has no @Named, there is just no bean with EL name 'farmer'. String expectedName = farmer; SetBean? beans = getCurrentManager().getBeans(expectedName); assertEquals(beans.size(), 1); In org.jboss.cdi.tck.tests.inheritance.specialization.simple.SimpleBeanSpecializationTest this is.
[weld-issues] [JBoss JIRA] (CDITCK-410) some tests fail with Java8
Mark Struberg created CDITCK-410 some tests fail with Java8 Issue Type: Bug Assignee: Martin Kouba Created: 22/Apr/14 7:49 AM Description: The following tests fail with Java8: org.jboss.jsr299.tck.tests.event.observer.conditional.ConditionalObserverTest org.jboss.jsr299.tck.tests.implementation.disposal.method.definition.DisposalMethodDefinitionTest The underlying problem is that java8 returns getMethods() in a different order now. And those 2 tests really depend on the order they are executed in. The first test method e.g. notifies a Bean which has an IF_EXIST observer method and later asserts that the observer method did not get triggered. But this test method fails if the other test-methods of the class got executed before it (because of the different method ordering in Java8). Project: CDI TCK Priority: Major Reporter: Mark Struberg Security Level: Public (Everyone can see) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-280) NonPassivationCapableProducerFieldTest broken
Mark Struberg commented on CDITCK-280 NonPassivationCapableProducerFieldTest broken yes, new issue. We should really clarify the Exception rules. Those appear to be quite random right now. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1113) Specializing beans in different bean archives is still broken
Mark Struberg commented on WELD-1113 Specializing beans in different bean archives is still broken Hi! I hope to be able to give it a try in the next month. Needs just some tweaking to get our app running on jbossas as we use openjpa, quartz, etc. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-276) check visibility rules for injected proxies
Mark Struberg created CDITCK-276:
Summary: check visibility rules for injected proxies
Key: CDITCK-276
URL: https://issues.jboss.org/browse/CDITCK-276
Project: CDI TCK
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Mark Struberg
Consider the following situation:
You have an EAR with the following in a shared ejb-jar.xml lib:
public interface X..
and
@Stateless class MyEJB{ private @Inject X; ...
The EAR also contains 2 web applications which have the following
implementations of X:
A implements X in webappA
B implements X in webappB
regarding on the webapp, the proxy either points to an instance of A or B
which are NOT castable to each other.
This is basically only possible if we only inject a subclass (or implementation
if X is a pure interface) of X as proxy into the shared EJB.
Not sure though how this could be unit tested via the TCK.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1113) Specializing beans in different bean archives is still broken
Mark Struberg created WELD-1113:
---
Summary: Specializing beans in different bean archives is still
broken
Key: WELD-1113
URL: https://issues.jboss.org/browse/WELD-1113
Project: Weld
Issue Type: Bug
Reporter: Mark Struberg
This is a follow up on WELD-912.
It appears that this is still broken!
I tried it first on glassfish-3.1.1. with an upgraded
weld-osgi-bundle.1.1.7.Final.
I get the following error reported:
remote failure: Error occurred during deployment: Exception while loading the
app : WELD-47 Specializing bean must extend another bean: Managed Bean
[class at.ac.tuwien.tiss.core.fe.codi.TissCodiWindowContextConfig] with
qualifiers [@Any @Default]. Please see server.log for more details.
But my class extends the parent class:
public class TissCodiWindowContextConfig extends WindowContextConfig { ..
The TissCodiWindowContextConfig is in my project jar, the parent class in
codi-jsf.jar, both in my WEB-INF/lib folders of my webapp.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-778) Weld must be able to support extension discovery in the modules of an multi-module application (EAR)
[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597127#comment-12597127 ] Mark Struberg commented on WELD-778: ... so that loadExtensions is per BDA not per app. Pete, the main problem is that there is NO explicit definition what an 'Application' is! One interpret it as Web APP another one interpret it as EAR=APP ... I personally don't care about whether we use, but we finally need to get down on one or the other. LieGrue, strub Weld must be able to support extension discovery in the modules of an multi-module application (EAR) Key: WELD-778 URL: https://issues.jboss.org/browse/WELD-778 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Fix For: TBC Currently, only extensions which are visible to the entire application (i.e. all modules) are installed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-867) bean implementations should be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589212#comment-12589212 ] Mark Struberg commented on WELD-867: Stu, the idea was to use the passivationId internally in the Beans and not to serialize the all the fields in those beans ;) bean implementations should be serializable --- Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that beans are serializable. - one of the following classes should implement java.io.Serializable https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/RIBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/AbstractBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/ManagedBean.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-867) bean implementations should be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589295#comment-12589295 ] Mark Struberg commented on WELD-867: As I said in my initial comment: the main problem is not the serialization of Bean itself, but serialization of CreationalContexts containing those Beans! CreationalContext itself is not Serializable yet and there is no passivationId for them of course... bean implementations should be serializable --- Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that beans are serializable. - one of the following classes should implement java.io.Serializable https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/RIBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/AbstractBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/ManagedBean.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589317#comment-12589317 ] Mark Struberg commented on WELD-867: Yes, that was the origin or our discussion. My argument is: a) the CreationalContext definition is currently broken regarding Serialization. Agree? b) So we need to fix the CC anyway, which means that we can also clarify the Bean part of the spec and even improve it by defining the original Weld behaviour (Weld 1.0, which was _THE_ RI for the official spec, DID serialize Beans properly!) as the standard. CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589334#comment-12589334 ] Mark Struberg commented on WELD-867: Ah oki, but that was the one we used to get handed over to our Extension Contexts as well with weld-1.0. And now we seem to get the naked Contextual and not the wrapped SerializableContextual. CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
