3:55 p.m.
[
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