I had to remove the binary attachement to get this on the list. Hence I sent
it
directly to Marc, Rickard and Daniel. If there is somebody else interested
in this ... please contact me and I´ll send you the 70k.
-----Ursprüngliche Nachricht-----
Von: Jung , Dr. Christoph
Gesendet: Montag, 15. Januar 2001 18:10
An: 'jBoss Developer'
Betreff: ApplicationDeployer (TNG) [was: AW: Merry X-mas]
Hi, aaah, pfff, ufff. Finally I managed to catch up with the discussion
(that obviously went to sleep to wait for some reaction of mine). I have to
admit that I was very confused with
the turns that our debate took ... I really appreciate Marc´s attempt to
redefine the ClassLoader delegation model. I have come to the same
conclusion that, without attacking this point, our efforts would be
condemned to fail.
But for my taste, and that is how I also interpret the direction of Rickards
response, the presented idea goes too far by introducing a single, global
application scope. Yes, you get rid of the (XML-) dependency annotations
that we have proposed. Yes, you laid the basics of a very fine-grained
runtime dependency computation.
But, on the other hand, you loose the possiblity of hosting separate
"apartments" in one server and I think this is a very basic requirement for
any Application Service Providing (you don´t like the binaries of your
customers to mix up, don´t you)? And this argument is even more general than
the one that I usually bring in: We at infor would like to be able to host
multiple versions of the same class in different components of our complex
application because we will not always be able to recompile/replace the
whole stuff at our customers.
So having that global scope you introduced, you will end up with computing
and resolving all these little dependencies at class-level which could be
even *artificially* introduced, i.e., not really intended at packaging time
.... where you simply could rely on *deliberately* introduced dependency
annotations.
This provoques (IMHO!) a flaw in your code leading to "non-monotonic"
behaviour: Suppose you have constructed two DependencyClassLoaders a and b
where a is defining class A. b.loadClass("A") will in fact produce
ClassNotFoundException until a.findClass("A") has been called (since
classloading is *thank god* done lazily, this will happen quite often,
wouldn´t it?).
Ok, now let me take a last crack on trying to persuade you with some
exemplary zip-attached code I just finished and tested (simply run
dist/bin/test.bat to see a few complexly arranged jars interoperate) which
could build the fundament of org.jboss.deployment.Deployment and
org.jboss.deployment.J2EEDeployer (or others).
The idea is similar to Marc´s: to break up the stringent SUN delegation
model of classloader into something more useful
(org.jboss.deployment.ApplicationClassLoader) but with a locally determined
scope (by what we have now commonly called org.jboss.deployment.Application)
that is introducing an arbitrary dependency graph.
The loading & linking semantics is IMHO quite straightforward and sound:
First try to resolve resources and classes against the applications own
repository (set of urls with a given background parent classloader), if it
fails, perform a beam-search in the application you depend on (where
reentering the beam leads to ClassNotFoundException ...).
The deployment procedure becomes also quite straightforward, though sometime
non-trivial: First, the subgraph that somehow depends on the redeployed
application is deactivated (from children/cycle nodes to their parents)
producing a replacement set of "ready-to-be-deployed" applications. These
apps are then activated/deployed in a second phase of the deployment
procedure where they also get each other to know for delegation and
interoperation purposes.
Mutual service provision is supported by an extensible sequential state
model ... for example, delegation blocks until the depending applications
have all been deployed (this will change to a more reasonable blocking as
well as the preliminary way of expressing application meta-data in the
property file "META-INF/application.properties") ... the general framework
for such behaviour (state representation, state progression, blocking calls)
is already present.
Please, have a look at the UML/Java code and tell me your opinion such that
I could maybe go on integrating that into org.jboss.deployment ...
Do you see any serious contras against the resource loading semantics? I do
not see a problem combining the proposed ApplicationClassLoader with the
existing EJB and Tomcat classloaders, except (and that would have been a
requirement with Marcs approach, too) checking for invocation optmisiation
should be done by comparing the identity of source and target interface ....
If there are any problems with the attached zip, please tell me such that I
can help (ready-made jars work at least on my machine, but who knows which
paths have found their way into the batches?)
Best,
CGJ
