Whoops, forgot to say one thing...
As you describe it, I would consider JBoss ClassLoader Domains to be
100% public as long as *any* application can import/subscribe/access it.
To me:
a. A public repository contains Modules that may be imported by any other.
b. A private repository contains Modules that may only be imported by
other modules from the *same* deployment unit (e.g. .ear file.)
Anything in between seems to cry out for an access control model.
// Bryan
Bryan Atsatt wrote:
Adrian wrote:
On Mon, 2007-06-18 at 14:09 -0700, Bryan Atsatt wrote:
So an application server would have to create, say, a private
LocalRepository instance to hold the modules of a single application.
And it would have to ensure that no other application could get it's
grubby paws on that repository instance.
Ok. That works for me. And it eliminates the need for cloning AND for
releaseModule():
1. Any given Repository instance is either 100% shared or 100% private,
with *no* in-between.
Since we are talking about appservers, I'll just point out
that this doesn't cover what JBoss allows you to do.
In JBoss we have a notion of what I like to call "ClassLoader Domains"
although they are actually called "LoaderRepositorys" after
the JMX name (note the JMX spec only has a singleton repository).
These are "isolated" classloading systems that sit on top
of a "Default Domain" and you can choose whether to do
parent/child delegation in either
* standard J2SE order (parent first)
* servlet style (child first).
When you deploy an application you get to choose the domain.
There is nothing to stop you putting multiple applications
into the same domain.
I would guess in your proposal they WOULD share the
same LocalRepository but only those named applications
would have access to it?
Right.
There are two main usecases for such a configuration.
1) Optimization
You want to optimize the inter-application communication
between related applications. i.e. one application uses
components from another application and you don't want
to do call-by-value.
By having the applications in the same classloader domain
one application can lookup and use the local interfaces
of the other application.
Yep.
2) Convenience
You deploy a rar inside an ear (making the rar classes
invisible to other applications)
but you want to configure the connection factories
of that rar outside the ear where it is easier to
edit the configuration file.
In this case you can specify that the connection factories
should use the classloading domain of the ear, making
its classes visible again.
e.g. something like:
<connection-factories>
<loader-repository>classloader:application=myapp.ear</loader-repository>
<etc/>
This last example doesn't really apply in our server, as the config is
just as easy to edit inside as outside an ear. But I see your point.
Most apps don't need to share classes in this way, and need only a
mixture of global and purely local classes. Clearly any module system
will be able to satisfy the first requirement. We need to make sure we
can also satisfy the second.
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?
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.
Our server supports three models for class sharing:
1. Global. All apps share a single version of the classes. This is a
deprecated model.
2. Shared. Our "Shared Libraries" are named/versioned loaders configured
at the server level, each with one or more code-sources. Each can
optionally import other shared-libraries. Import declarations are by
name and version range. A default set of imports is configured by the
container for all application instances, but each is app free to modify
that set via config.
(This is obviously very much like the 277/OSGi model.)
3. Application group. Applications are hierarchical: each app is
deployed under some parent, and can access the classes of that parent
(excluding web-modules). So several apps can be deployed under a common
parent, and classes visible at the parent are visible to the children.
The global model in #1 simply means deploying classes into our "default"
application.
The shared-library approach has proved to be the most flexible and most
used (surprise). But this model does not support any access control, so
at the moment, if you want restricted sharing you must use the shared
parent approach.
And while we do support execution under a SecurityManager, *very* few
companies are willing to pay the runtime overhead for this. Sure,
permissions can be applied without a SecurityManager, but this incurs
the administrative headache of granting permissions correctly.
So I'd rather steer clear of a permission based approach to restricting
access to modules, if we want to go down this path at all.
// Bryan
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
