[weld-issues] [JBoss JIRA] Created: (CDITCK-183) DestroyedInstanceReturnedByGetTest seems broken
DestroyedInstanceReturnedByGetTest seems broken --- Key: CDITCK-183 URL: https://jira.jboss.org/browse/CDITCK-183 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.2.CR2 Reporter: Mark Struberg DestroyedInstanceReturnedByGetTest currently calls {noformat} destroyContext(getCurrentManager().getContext(SessionScoped.class)); setContextActive(getCurrentManager().getContext(SessionScoped.class)); {noformat} The problem is that destroying the SessionContext will render it inactive. So the getContext() call in the following line will throw a ContextNotActiveException according to the spec 6.5.1: "If no active context object exists for the scope type, the container throws a ContextNotActiveException." -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Created: (CDI-18) cleanup Bean Archive behaviour (BDA) of interceptors, decorators and alternatives
cleanup Bean Archive behaviour (BDA) of interceptors, decorators and alternatives - Key: CDI-18 URL: https://jira.jboss.org/browse/CDI-18 Project: CDI Specification Issues Issue Type: Feature Request Components: Specification Affects Versions: 1.0 Reporter: Mark Struberg Fix For: 1.0 Currently the spec defines that , and affect only the Bean Archives where they are configured in (via beans.xml). Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder! This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the sections in their beans.xml. Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment! -- 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: (CDI-18) cleanup Bean Archive behaviour (BDA) of interceptors, decorators and alternatives
[ https://jira.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563062#comment-12563062 ] Mark Struberg commented on CDI-18: -- This issue originates from the interceptor order problematic as discussed on the EG and weld-dev lists a year ago. One possible solution would be to introduce 'ordinal' and 'enabled' attributes to the , and sections like the following example shows: org.myclass.MyInterceptor3 org.myclass.MyOtherInterceptor org.myclass.MyFirstInterceptor Where sections with higher ordinals get applied later and thus being more 'important'. So if the default interceptor order you get with a jar doesn't fit your needs, you can still provide a beans.xml containing a fixed one with a higher ordinal. It is also possible to disable interceptors which got switched on by default in a lower prioritized beans.xml section by adding enabled="false". > cleanup Bean Archive behaviour (BDA) of interceptors, decorators and > alternatives > - > > Key: CDI-18 > URL: https://jira.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Specification >Affects Versions: 1.0 >Reporter: Mark Struberg > Fix For: 1.0 > > > Currently the spec defines that , and > affect only the Bean Archives where they are configured in > (via beans.xml). > Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT > count for the jars in it's WEB-INF/lib folder! > This is pretty unhandy because you would need to repackage all your jars in > your WEB-INF/lib folder and add/expand the sections in their > beans.xml. > Needless to say that this is not only hard to do in a company build but is > also impossibly to handle at deploy time in an OSGi environment! -- 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: (CDI-24) Make it easier to build passivating contexts by making sure Contextual objects passed to them are serializable
[ https://issues.jboss.org/browse/CDI-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573753#comment-12573753 ] Mark Struberg commented on CDI-24: -- Please note that the CreationalContext also needs to be Serializable! Otherwise it cannot be stored on a medium which needs to be serialised (e.g. the JSF ViewMap) Maybe we can simply say: if a bean is PassivationCapable, it also needs to be Serializable or Externalizable? > Make it easier to build passivating contexts by making sure Contextual > objects passed to them are serializable > -- > > Key: CDI-24 > URL: https://issues.jboss.org/browse/CDI-24 > Project: CDI Specification Issues > Issue Type: Feature Request >Reporter: Pete Muir > > OWB ensures that any Contextual impl passed to a passivating context is > serializable, making it much easier to impl a custom passivating context. We > should probably make this required by the spec. -- 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] Created: (CDI-35) add support for 'optional' beans
add support for 'optional' beans Key: CDI-35 URL: https://issues.jboss.org/browse/CDI-35 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Mark Struberg sometimes it's neat to mark a bean as @Optional depending if a specified class can get loaded or not. This is a simple way to implement deployment specific functionality. An example would be a BvalSupportBean which only should become active if the JSR-303 bean validation API can be found on the classpath. -- 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: (CDI-35) add support for 'optional' beans
[ https://issues.jboss.org/browse/CDI-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574968#comment-12574968 ] Mark Struberg commented on CDI-35: -- If the spec would specify that the classpath scanning also needs to work for 'unfinished classes' then we would be able to implement such a functionality as portable extension. I got pointed to Seams @Required, but this is currently not working in OWB because we throw a DeploymentException if we find a bean with an unresolved class dependency. > add support for 'optional' beans > > > Key: CDI-35 > URL: https://issues.jboss.org/browse/CDI-35 > Project: CDI Specification Issues > Issue Type: Feature Request >Reporter: Mark Struberg > > sometimes it's neat to mark a bean as @Optional depending if a specified > class can get loaded or not. > This is a simple way to implement deployment specific functionality. > An example would be a BvalSupportBean which only should become active if the > JSR-303 bean validation API can be found on the classpath. -- 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-tabpanel&focusedCommentId=12587903#comment-12587903 ] Mark Struberg commented on WELD-867: Hi! To clarify this issue a bit, the problem is not that Beans are not serializable (this could be worked around by using the passivationId) but that they will get stored in CreationalContexts which is not serializable anymore afterwards. So either make the Beans serializable, or also use the passivationId in your CreationalContext impl. > 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 >Affects Versions: 1.1.0.Final >Reporter: Gerhard Petracek >Priority: Blocker > Fix For: 1.2.0.CR1 > > > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=12589327#comment-12589327 ] Mark Struberg commented on WELD-867: what about this one? :) * @author pmuir * */ public class SerializableContextualImpl, I> extends ForwardingContextual implements SerializableContextual and /** * A serializable version of contextual that knows how to restore the * original bean if necessary. * * @author Pete Muir * @author Marius Bogoevici */ public interface SerializableContextual, I> extends Serializable, Contextual { C get(); } taken from http://repo2.maven.org/maven2/org/jboss/weld/weld-core/1.0.0/weld-core-1.0.0-sources.jar and http://repo2.maven.org/maven2/org/jboss/weld/weld-spi/1.0/weld-spi-1.0-sources.jar > 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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=12597126#comment-12597126 ] Mark Struberg commented on WELD-778: The whole BDA definition is completely against any other EE spec out in the wild anyway. So please let's just get rid of this whole BDA nightmare. There is one really well working classloader configuration available with 1 CL for the EAR + 1 child classloader for each webapp. But this (and other classloader scenarios) is afaik not specified in any EE spec. The problem starts that there is are old and very insane classloader configurations which just share classes even amongst different EARs (figured recently on JBossAS5), etc. This is imo pretty sick and every little jetty and tomcat offer better (== more secure) classloader isolation. We imo should _not_ propagate those _bad_ classloader habits but instead either a) kill all the BDA definition (which currently infringes other EE specs) or b) finally start defining a (default) standard ClassLoader schema in EE7 and build our behaviour upon this. > 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-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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=12597728#comment-12597728 ] Mark Struberg commented on WELD-778: Pete what I meant is that the EE doesn't specify any classloading nor class handling at all. Thus the BDA definition must not rely on such things. E.g. in some OSGi environments, you don't get your hands on any JAR at all. Instead all those 'physical' parts are shielded from you and you just get one big fat classpath. Not sure how the BDA definition should ever work for those situations. And yes, the ClassLoading -> CDI is somehow circular. I know this is not a failure of the CDI spec, but we still must take care of it As for 'Application': JSR-316 both names a 'Web Application' (Servlet3.0 references) and a 'Java EE application'. The problem is that the JSR-299 section 2.4.1 _explicitly_ says the following: > The @RequestScoped, @ApplicationScoped and @SessionScoped annotations defined > in Section 6.7, > “Context management for built-in scopes” represent the standard scopes > defined by the > Java Servlets specification. And the Java Servlets Specification _only_ mentions the Web Application. See what I mean? Sorry for not being clear enough in my previous comment, but I'm also juggling through hundreds of spec pages which almost drives me crazy ;) > 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-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-tabpanel&focusedCommentId=12597944#comment-12597944 ] Mark Struberg commented on WELD-778: > IMO this was an error in CDI I actually don't believe this was erroneous - in fact all the other etablishec @ApplicationScoped annotations (Spring, JSF, etc) always mean the WebApplication. For 'enterprise application' wide singletons, those frameworks rely on EJBs. And imo that was also the original take of WebBeans as I saw it back in early 2008. So rather than re-defining @ApplicationScoped as not being WebApp centric (that would be a rather huge change in the spec!) I'd say we either introduce an own @EarScoped or just use the JSR-330 @Singleton annotation for it. Currently doing my paperwork for the CDI EG, so we can talk over there. 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] (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] (WELD-1113) Specializing beans in different bean archives is still broken
[ https://issues.jboss.org/browse/WELD-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12687015#comment-12687015 ] Mark Struberg commented on WELD-1113: - will try to reproduce it later today, currently in another project. > 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 >Assignee: Marko Lukša > > 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] (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 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-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-1580) synthethic InjectionPoint does not reflect all metadata from Instance#select
Mark Struberg created WELD-1580 synthethic InjectionPoint does not reflect all metadata from Instance#select Issue Type: Bug Assignee: Jozef Hartinger Created: 02/Jan/14 4:40 AM Description: A synthetic InjectionPoint should reflect all the metadata gathered in the Instance plus the additional qualifiers and types from select(). Currently it seems that only the type and qualifiers are filled and all other stuff is empty. Please check the new wording for InjectionPoint in CDI-1.1 Project: Weld Priority: Major Reporter: Mark Struberg 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-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-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"; Set> 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-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-429) CDI TCK custom AnnotatedTypes are often wrong
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-429 CDI TCK custom AnnotatedTypes are often wrong Issue Type: Feature Request Affects Versions: 1.2.1.Final Assignee: Tomas Remes Components: Tests Created: 02/Jul/14 2:17 PM Priority: Major Reporter: Mark Struberg Security Level: Public (Everyone can see) Many TCK tests modify the AnnotatedTypes via Extensions. But they only change the Annotated itself and don't use those in the 'deepeer' structures. This e.g. leads to the situation that org.jboss.cdi.tck.tests.extensions.alternative.metadata.Grocery#observes1 parameter 'Milk' event parameter AnnotatedParameter#getDeclaringCallable() still points to the original AnnotatedMethod and not the changed one.
[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-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-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-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-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-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-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-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-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-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-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-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-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 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 Bean 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 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 Jozef Hartinger Please also point to the other mail. The posted algorithm will create random results depending on the processing order. I do not consider this a valid approach. Of course we are talking about REALLY edge cases which will barely happen in 'the wild'... 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-476) ConversationFilterTest is too strict
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-476 ConversationFilterTest is too strict Issue Type: Bug Affects Versions: 1.2.4.Final Assignee: Tomas Remes Components: Tests Created: 06/May/15 6:10 PM Priority: Major Reporter: Mark Struberg ConversationFilterTest uses a Tester class which calls beanManager.getContext(ConversationScoped.class).isActive(); The problem with the test is that this already might blow up with a BusyConversationException in OWB. But the test only expects the BCE a single line later. From the spec: The container ensures that a long-running conversation may be associated with at most one request at a time, by blocking or rejecting concurrent requests. If the container rejects a request, it must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.BusyConversationException. We do this check already if you resolve the ConversationContext, which is perfectly allowed by the spec imo.
[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-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-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 false 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 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-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&paste 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-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 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] (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 agree that the EE spec requires the TCCL to be set up for any 'invocation on application methods'. And CDI Extensions are surely part of the application. Otoh please note that Apache OpenWebBeans has no single usage of Thread.currentThread().setContextClassLoader(); in it's codebase. It should imo be part of the integration. No sure what OWB does different that it is possible. I cannot judge as I don't know the Weld codebase. Otoh I'm pretty confident that the setup which got used in WebSphere 8 (separate BeanManagers per WAR) should also work fine with Weld as CDI 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 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] (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 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 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 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 > 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 edited a comment on WELD-2381 Re: Set web application classloader as TCCL when calling observers > and used to load classesBut 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. PS: I'm still with you that this is not a Weld fault but an integration issue! 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-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] (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-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-578) CustomBeanImplementationTest relies on unspecified hashCode on proxies
Title: Message Title Mark Struberg created an issue CDI TCK / CDITCK-578 CustomBeanImplementationTest relies on unspecified hashCode on proxies Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Tomas Remes Components: Tests Created: 27/May/17 4:33 AM Priority: Major Reporter: Mark Struberg #testCustomBeanIsPassivationCapable() calls hashCode on a Contextual Reference proxy. But the hashCode behaviour of proxies is not specified at all afaik. Add Comment
[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-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-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 Thanks for clarifying, will look at the other ticket again. 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-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 commented on CDITCK-580 Re: illegal TCK test for indirect specialization Yes. Think about it a bit further. Take your original @Landowner Farmer: What if you like to do class @Specializes @Landowner BigFarmer extends Farmer plus class @Specializes @Lazy LazyFarmer extends Farmer With your interpretation you have no way to get rid of any qualifier, right? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) __
[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 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-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-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-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-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 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 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-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-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 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 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' +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 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' 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 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' 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' 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' 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-i
[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 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@list
[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-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-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-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-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)