December 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Arne Limburg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Arne Limburg commented on CDI-70: --------------------------------- OK, but then the complete section should be more concrete. What about fields from superclasses, especially when a field of the same name exists in the subclass. I would expect that AnnotatedType.getFields() returns both, whereas I would expect that overridden methods from a superclass are not contained in AnnotatedType.getMethods(). But none of these things is currently specified. > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Martin Kouba (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Martin Kouba commented on CDI-70: --------------------------------- It's not clear from my point of view. If we say that the container must call AnnotatedType.getConstructors() to determine the members (constructors) of a bean class, IMO we declare that the container should not inspect the bean class via reflection to discover any constructors at all. The spec also states that "AnnotatedType.getConstructors() - returns all the constructors declared for the type". We should either modify spec to explicitly mention the default constructor: "AnnotatedType.getConstructors() - returns all the constructors declared for the type; if an empty set is returned, a default constructor with no parameters will be assumed" or modify javadoc to align with spec. BTW current Weld impl does not "assume" default constructor with no parameters if original AnnotatedType is replaced during processing of ProcessAnnotatedType event. > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Arne Limburg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Arne Limburg commented on CDI-70: --------------------------------- Where is your problem here? Should we add a second part to the second sentence like "The container must not directly call the Java Reflection API to discover them." We are just talking of discovery here and that perfectly fits with the javadoc. We are able to discover that the developer has not added any constructor to a class by retrieving an empty set from javax.enterprise.inject.spi.AnnotatedType.getConstructors(). > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-70) Clarify that if an extension provides an Annotated* then it is considered "metadata complete"

by Martin Kouba (Reopened) (JIRA)

[ https://issues.jboss.org/browse/CDI-70?page=com.atlassian.jira.plugin.sys... ] Martin Kouba reopened CDI-70: ----------------------------- The spec states: "The container must use the operations of Annotated and its subinterfaces to discover program element types and annotations. The container must not directly call the Java Reflection API. In particular, the container must: call AnnotatedType.getConstructors(), AnnotatedType.getMethods() and AnnotatedType.getFields() to determine the members of a bean class." However javadoc for *javax.enterprise.inject.spi.AnnotatedType.getConstructors()* states: "Get the constructors of the type. If an empty set is returned, a default constructor with no parameters will be assumed." IMHO this is contradictory. > Clarify that if an extension provides an Annotated* then it is considered "metadata complete" > --------------------------------------------------------------------------------------------- > > Key: CDI-70 > URL: https://issues.jboss.org/browse/CDI-70 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 1.1.EDR1 > > > I think the correct behavior is to ignore any members that are missing from the AnnotatedType. You should not be directly accessing the reflection API at all. If the parameters for a method or a constructor don't match the underlying class, it should be considered a definition error. -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-18: ---------------------------------- Or course interceptors, decorators and alternatives enablement in beans.xml must also only be done with respect of visibility in the scope. And why I wrote the part with the @NScoped: it's perfectly possible to @Specialize (web) @ApplicationScoped beans, because they don't effect the singleton behaviour even if defined in a shared ear-lib. And another observation: I _explicitly_ don't wrote anything about enterprise archives but did hold this general. Because EARs are not the most global area neither! You could theoretically also introcude a @JvmScoped or @ClusterScoped - in those cases you must also guarantee the visibility somehow... > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> 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 <alternatives> 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. 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-18: ---------------------------------- Yes Pete, for the problem see the issue text. For why the BDA stuff became what it is now please see my very first comment: > This issue originates from the interceptor order problematic I'll try to sum up the discussion so far: While discussing this very issue with BDAs we identified another related issue (class visibility) while discussing CDI-129 (@EnterpriseApplicationScoped): @Specializes. This doesn't need a BDA entry in beans.xml and is also broken atm. My solution would be as follwing a.) Introduce an 'ordinal' + 'enabled' in beans.xml for <interceptors>, <decorators> and <alternatives> as described in my first post. This will solve the interceptor ordering issue and remove the troubles with BDAs b.) Specify the class visibility rules (see CDI-129 for the problem): "The container must ensure that for any * @Specializes @NScoped class Y extends X and * @Alternative @NScoped class Y implements X class Y is accessible by all classes which can access X in the same @NScoped context. Example: If the container discovers a public @EnterpriseApplicationScoped class X { } defined in a shared ear-lib which has a public @EnterpriseApplicationScoped @Specializes class Y extends class X { } defined in WEB-INF/classes of one of the EARs web application, a DeploymentException must be thrown. Defining the public @EnterpriseApplicationScoped @Specializes class Y extends class X { } in a shared ear-lib jar as well will be perfectly fine. " > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> 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 <alternatives> 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. 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Gerhard Petracek (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Gerhard Petracek commented on CDI-18: ------------------------------------- @pete: we aren't proposing to leave it undefined. just the isolation for jars causes major issues - esp. in combination with some other issues. i'm currently discussing the suggested wording with mark and he will post it soon. > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> 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 <alternatives> 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. 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Ales Justin (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Ales Justin commented on CDI-18: -------------------------------- >> @Ales: In fact, JBossAS7 already killed the BDA partly! You already contradict the spec by allowing definitions in WEB-INF/beans.xml to count for all jars in WEB-INF/lib. Please go back and read the spec - this is clearly defined different! As per the CDI-1.0 spec, any definitions in WEB-INF/beans.xml must ONLY affect WEB-INF/classes/** and MUST NOT have any effect on jars in WEB-INF/lib! I don't think that's true for AS7. Are you 100% sure? It was true for AS6, but that was a mistake / bug. And what do you mean by "affect"? > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> 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 <alternatives> 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. 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Pete Muir (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on CDI-18: ------------------------------ Mark, I think this just points as to why you need to write up the problems you see in a coherent way. I think we are all discussing the same problems, just using different terminology. Yes, this area is underspecified, which is why we get this confusion. However I don't think the answer is just to scrap everything and leave it all undefined, which is what I currently understand you are proposing (again, why you need to provide a fuller problem statement and proposed solutions). > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> 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 <alternatives> 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. 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

13 years

1
0
0 / 0

[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives

by Mark Struberg (Commented) (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-18: ---------------------------------- > Single classpath works best most of the time For web-applications, yes! For ear-applications, no! For containers, hell definitely not! Whenever EE server vendors hit such problems they made all the classloaders flat. That introduced some heavy security and stability issues. A colleague of mine managed to kill a whole cluster because of an error in his Seam2 application. Sadly this crashed some static variable which also got used in the admin console. And that way it got propagated all over the cluster -> this must not be possible if a server has a sane classloader hierarchy in place! There is an _official_ recommendation about how classloader hierarchies in EE containers should look like in the EE spec itself - just use it! > Graph based classloading (such as OSGI and Jigsaw) shows promise > But OSGi classloading's resultion is NP-complete (= non-determinstic in practice) so it's broken. fully agree! > Hierachical classloading (AKA parant classloading as defined by ClassLoader's javadocs) is utterly broken Actually I consider this the _only_ sane scenario! Of course it means that people must understand what they are doing, and e.g. a class in an shared ear-lib must be not cache something like String className -> cache like e.g. old facelets and JSF impls had, but rather Class->cache or Map<ClassLoader, Map<String, CacheItem>>. But hey, that's very basic Java knowledge and _most_ libraries know this already. And if there are still some out which don't, then just fix them or don't use them in shared ear-libs but rather in WEB-INF/lib of each war. Btw, BDA means that any <interceptors>, <alternatives>, etc defined in a beans.xml *only* works for the jar which it's defined in! @Ales: In fact, JBossAS7 already killed the BDA _partly_! You already contradict the spec by allowing definitions in WEB-INF/beans.xml to count for all jars in WEB-INF/lib. Please go back and read the spec - this is clearly defined different! As per the CDI-1.0 spec, any definitions in WEB-INF/beans.xml must *ONLY* affect WEB-INF/classes/** and *MUST NOT* have any effect on jars in WEB-INF/lib! > Global enablement of interceptors, decorators and alternatives > -------------------------------------------------------------- > > Key: CDI-18 > URL: https://issues.jboss.org/browse/CDI-18 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans, Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Priority: Critical > Fix For: 1.1 (Proposed) > > > Currently the spec defines that <interceptors>, <decorators> and <alternatives> 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 <alternatives> 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. 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

13 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2011