Mark Brouwer wrote:
Bob Scheifler wrote:
Mark Brouwer wrote:
I think I try to ask whether you think an inverted event model should be
'standardized' as a mandated or optional feature of ServiceRegistrar,
JavaSpace, etc. and be on par with the Jini Distributed Event
specification.
I'm not particularly keen on having two events models around
where avoiding callbacks is the only justification for the
second model. I'd be much happier if there were additional
significant value adds in a new model (I don't have a list).
I might have another one for you Bob. It might be the case you are
already overwhelmed by happiness as result of the first one (so far no
negative feedback yet), but to be sure a second one I just realized due
to some stuff I'm working on.
You might remember as result of the postings related to
MarshalledInputStream that I'm working on the ability to create class
loaders that play nicely in a Jini environment from a Jini service. The
purpose for this was to create a Jini service that could act as a proper
Jini service and be able to (re)deploy WAR files, in other words a web
application server service. Another purpose is to facilitate the
creation of services that can act as a framework for plug-ins (each
running in their own class loader) that must be able to interact with
other Jini services in the djinn.
The result is that a class loader hierarchy is created something like this:
ClassLoader A (Jini service)
|
|
--- Class Loader B (Web application)
|
|
--- Class Loader C (Some plugin)
At the Jini service level (class loader A) one must expect to have
facilities available to a web application or plugin, such as the ability
to find Jini services, participate in the two-phase commit protocol,
listening for remote events, etc. Configuration of constraints and all
other stuff is handled at the service level as that is what the Jini
service (indirectly through the container) is good at you don't want to
bother the code in the web application or plug-in with that.
Assume operations in the web application or plugin take place with a
context class loader that equals the class loaders it is defined within
and that has as its parent the class loader the Jini service is defined
within. Lets analyze the case where a reference to a lookup service is
obtained and the web application queries the lookup service for types
only available at the web application class loader. Due to the context
class loader active everything goes fine, the client will get the
services implementing the types defined in the web app class loader and
the implementation classes will be defined in a created class loader
that has as its parent the context class loader.
Now the situation in which some services are not available and under the
hood one registers for receiving service events (well the container/Jini
service will do this for you). As the Jini service defined one level
lower in the class loader hierarchy that acts as a 'proxy' for the web
application has been exported with a context class loader that is the
parent of the context class loader of the web application, all matching
services found will be unmarshalled and defined in a class loader that
has as its parent the class loader of the Jini service instead of the
one of the web application, resulting in some ClassCastExceptions.
The funny thing is when I force my SDM [1] implementation to use the
inverted event model all services are unmarshalled with the proper
context class loader and the services are usable by the plugin or web
application. Hurray this is what people expect that don't understand
class loaders to the level that makes it obvious why something doesn't
work (I realize these cases also most of time only when I'm debugging
equals [2] by checking class loaders on classes, others likely would
have ditched their Jini environment already in the garbage bin and went
for shipping data, because you have to admit that data seems to work
everywhere and parsing data in a wrong way they account to themselves
and not to the framework).
To get the same effect for the callback event model I currently have to
resort to custom unmarshalling (which has been implemented and seems to
work fine, applause to the Jini ERI stack) but as you might see the
inverted event model gets you this behavior for free which is nice for
any library/framework that wants to provide certain services to entities
that might operate from a child (context) class loader.
Another thing that might be possible is that given the assumption an
inverted event model is done by polling from the specialized proxy is
that the polling proxy can find out about the status of the service and
about failures for the event delivery. I've been requested at regular
intervals by fellow developers about exposing this some way, but I've
been holding that of as I really wondered what they could do with it and
I wanted to keep the models rather similar from an API perspective.
FWIW I've been thinking too of an inverted event model based API on the
transaction manager service that publishes transaction state transition
events (in the abstract) that could be utilized by an object that
implements TransactionParticipant for the purpose of getting rid of
callbacks for the two-phase commit protocol as well. In other words an
inverted event model would be great to get rid off callbacks which is in
an Internet deployment scenario pretty useless these days.
[1] I have full control over the context class loaders effective for
each and every operation of the SDM due to the thread pool
implementations to which TaskManager delegates, also the JSC
Specification equivalent of SDM called ServiceFinder and ServiceCache
specify how context class loader are utilized.
[2] equals for services, leases, event registrations, etc. is still a
painful exercise as became clear to me when debugging why 2
ServerTransactions not being equal this weekend (also the callbacks with
a wrong class loader while unmarshalling). From the Davis project I know
that ReferentUuid was designed to help in this are, given the fact since
then none of the classes that could take advantage of it have been made
aware of it and neither one of the Jini Specifications got any language
that indicates that ReferentUuid plays a role here. I'm curious to find
out whether you think it fails to bring in the end what I believe could
still bring to us.
--
Mark
