river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Mon, 11 Jun 2007 23:03:02 GMT
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> 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.
> 
> Then it would seem you chose the wrong context class loader.

The Jini Service that is responsible for creating the class loaders is
also the one that acts as the actual remote event listener (due to all
kinds of reasons for which you must trust that it makes sense). So at
some point of time it exported itself with a context class loader that
is the class loader the service is defined within. During the life-cycle
of the service a web application (class loader is child class loader of
the Jini service) is deployed and that web application has access to
facilities for finding services.

Every time the SDM exports a RemoteEventListener a specialized exporter
is used that produces a smart proxy that utilizes a wire protocol for a
bunch of aggregated remote objects (those supplied by the service and
those of provided by the container) that has been exported once. And
each RemoteEventListener proxy has a Uuid that identifies the remote
object at the server side.

So reasoning from the assumption that the exporter in the SDM would
really export a remote object I could agree with your statement "Then it
would seem you chose the wrong context class loader". I solved this
problem now by implementing custom unmarshalling as I have an
association between a Uuid and context class loader at the time of
'exporting'. What I wanted to make clear that for a framework that wants
to get things done on behalf of an entity that operates under a
different context class loader an inverted event model makes live a bit
easier.

>> 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.
> 
> Insufficient information to infer this is a direct consequence of an
> inverted event model.

I agree it will depend on how much you want to specify with regard to
how the actual events will be delivered, but I would say the events are
unmarshalled with the context class loader effective at the moment of
the event registration.

I must admit I ran out of steam about this subject and SARE. I don't see
us getting any closer and there is not that much involvement of others
therefore I see no value in continuing this discussions as part of
River. Lets move on to something else ...
-- 
Mark



Mime
View raw message