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

[Mark Struberg (Commented) (JIRA)]

    [ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649256#comment-12649256 ] 

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