[ https://jira.jboss.org/jira/browse/CDITCK-137?page=com.atlassian.jira.plu... ] Gurkan Erdogdu commented on CDITCK-137: --------------------------------------- Please look at https://issues.apache.org/jira/browse/OWB-302. It means that we do not inject decorators into delegate injection points like Weld did. We have a single delegate injection point proxy that is responsible for calling decorators and bean instance over decorator stack. For example; FooDecorator1-->FooDecorator2-->Bean Instance Weld does : inject FooDecorator1 into FooDecorator2 and Bean instance into FooDecorator2 etc. OWB does :inject Special Delegate Proxy it calls FooDecorator1 --> FooDecroator 2 --> Bean Instance Specification does not define any implementation logic. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/CDITCK-137?page=com.atlassian.jira.plu... ] Gurkan Erdogdu commented on CDITCK-137: --------------------------------------- Failed test method is : public void testChainedDecoratorInvocation() with assertions of InjectionPoints For example : assert FooDecorator1.getInjectionPoint().getBean().getBeanClass().equals(CowShed.class); In our implementation FooDecorator1.getInjectionPoint() returns null because we do not inject FooDecorator1 into any delegate injection point. Therefore all injection points in decorators and bean instance are null. In weld, you inject decorators into delegate injection points. In OWB, we inject single proxy for delegate injection point that is responsible for calling decorator stack in order. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/CDITCK-137?page=com.atlassian.jira.plu... ] Gurkan Erdogdu commented on CDITCK-137: --------------------------------------- I have sent an email about the issue to EG -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on CDITCK-137: ---------------------------------- I've re-read the spec, in order to try to construct a clear picture. "The container must ensure that every injection point of type InjectionPoint and qualifier @Default of any dependent object instantiated during this process receives: • an instance of InjectionPoint representing the injection point into which the dependent object will be injected, or • a null value if it is not being injected into any injection point." a) that the decorator it is injected into is a "dependent object", and that b) that the decorator is being "injected into an injection point" Given that 8.1 says "A decorator is a managed bean." and that the decorator is dependent scoped, (a) is clearly true. I can find no direct statement to say that (b) is true, otoh, I can find no direct statement to say it is false. Therefore, we have to fall back to secondary evidence. 1) Given the overall design philosophy injection points, it seems reasonable, and useful, to have them work inside decorators 2) It is reasonable to assume that the decorators and injection points should work in a consistent fashion - either decorators should be visible to injection points (and thus be able to inject injection points, and use them) or be invisible (and thus have no effect on injection points, such that they behave as though the decorators aren't present) 3) Given the existence of the InjectionPoint.isDelegate() method, the spec clearly intends you to be able to identify that the bean is being injected into a decorator's delegate injection point. If we were to assume that decorators are "invisible" to injection points (so that the injection point for the decorated bean is in fact the client), then this method would always return false, and thus be pointless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Gurkan Erdogdu commented on CDITCK-137: --------------------------------------- I am also on the EG but I do not accept this rejection. Clearly spec, does not provide that decorator must be injected into Decorators delegate injection points. Implementations could not behave how it likes to implement and others have to obey them. Either spec, has to be changed to assert your implementation, or TCK test has to be excluded. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on CDITCK-137: ---------------------------------- I have asked Gavin to review this issue again. Beyond that, you would need to refer it to the JCP Executive Committee. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Pete Muir updated CDITCK-137: ----------------------------- Affects Version/s: 1.0.2.CR2 We will no longer check that injection points can be injected into decorators. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Pete Muir updated CDITCK-137: ----------------------------- Component/s: Tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Lance Andersen commented on CDITCK-137: --------------------------------------- org.jboss.jsr299.tck.tests.decorators.invocation.DecoratorInvocationTest(no .testChainedDecoratorInvocation) does exist, so i think the exclude as defined is a typo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on CDITCK-137: ---------------------------------- Added Lance as a watcher -- Lance, please see my previous comment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/CDITCK-137?page=com.atlassian.jira.plugin.s... ] Pete Muir closed CDITCK-137. ---------------------------- Resolution: Done -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira