Adrian wrote:
On Tue, 2007-06-19 at 12:17 -0700, Bryan Atsatt wrote:
But you are right, of course, that there exist more complex scenarios
that require an intermediate form of sharing. Your named domains seems
to satisfy that requirement. Can you restrict access to domains?
Not really. We assume that if you have "createClassLoader" permission
then you can modify the classloading structure however you like.
Right. So, like our shared-libraries, these loaders are generally
available to any app.
And, as you know, even *within* an application, web-modules need to be
isolated. So the private repository approach breaks down a bit here, or
must be taken to the extreme of a single module repository instance.
This is where an access control model might be a better solution.
The big issue with web-apps is their "load locally first".
This gets people into all sorts of trouble when they start
adding random things to WEB-INF/lib that is also visible
elsewhere in the application.
Sure. This is in fact why we disable "child-first" behavior by default,
and strongly discourage it in our docs. This servlet spec
"recommendation" has been a nightmare! (The ironic part is that it
caused Sun's own CTS to break, as they had copies of EJB interfaces in
the wars! Turns out this was a really good thing, as it was a giant red
flag that caused me to set the default the other way, long before any of
this was really understood.)
Let's not repeat the same mistake here! There should not be any way to
invert the search order in a module system. Period. It was a *major
hack* and works only in carefully controlled circumstances.
The isolation problem needs a general solution.
e.g. You add commons logging to an ear and then put
it in WEB-INF/lib of a war also in the ear
Ideally you'd want them to share the same classes,
but sometimes it is done this way so each webapp can
have its own singletons.
Yes, and this is exactly the sort of situation where you might want to
share a ModuleDefinition, but *not* a Module. This would be an enhanced
equivalent of child-first: enabling class duplication but only of a
*subset* of required classes (i.e. specific module/modules).
But, without the OSGi "uses" like functionality, I don't know that we
can implement a good enough validation model to detect the collision cases.
Personally, I'd rather we not support this kind of hack; it is nothing
but a way to work around a serious deficiency of some existing code that
uses statics poorly. That code should just be fixed!
And, while we wait for that fix, a fully private copy of the module is a
reasonable work-around. There aren't too many of these cases, at least
not that I'm aware of.
These additional complexities aside, we still need a solution for the
simple case of web-app loader isolation within an app.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
