river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Namespace change
Date Sun, 16 Jan 2011 02:47:52 GMT
On 1/15/2011 5:16 PM, Peter wrote:
> ----- Original message -----
>> On Sat, 2011-01-15 at 16:11, Peter Firmstone wrote:
>>> With the namespace change, some proxy's may not find the
>>> org.apache.river.* classes they need in existing deployed clients,
>>> rather than increase the size of jsk-dl.jar (river-dl.jar in the modular
>>> build), we could create another jar, perhaps called namespace-compat-dl.jar?
>>> Something like this would be required regardless of the build
>>> environment, but to avoid conflicts with existing deployed codebases,
>>> jsk-dl.jar should also be renamed.
>>> Thoughts?
>>> Peter.
>> I would think that one would deploy the appropriate downloadable jars
>> with their service.  Perhaps I'm missing something, but I don't see a
>> problem.  If a client is running and you deploy a new version of the
>> service (with associated downloadable jars), the old proxy should fail,
>> the client downloads a new proxy and continues on.  That's the Jini way.
>> Or do I misunderstand the question?
> If jsk-dl.jar already exists at a client and that jar contains com.sun.jini.* instead
of org.apache.river.* the client might not re download the right jar file.  Just thinking
about problems that might occur and how to avoid them.
> I'm considering how new proxy's might potentially fail in existing deployed clients,
where the new proxy has had a namespace change.
> Currently the com.sun.jini.* namespace is considered implemtation detail, a side-effect
of this is these classes are duplicated in jar files, however the classes from these files
are not loaded if they're already loaded in the client by the application class loader, with
consequent codebase annotation loss.
> I'm wondering if we need to consider making some implementation classes package private
where they're used and perhaps make others public api?  Only in the platform jar however.

In general Peter, I think that the important thing is to make services 
completely independent of each other by keeping duplicate implementation classes 
separated.  This makes it possible to rebuild river to fix a bug in reggie, and 
just deploy reggie-dl.jar as the "fix" and not have to worry about what happens 
if this breaks another service that might use something from a shared class 
which would go into another jar that would be in the codebase of other services 
as an optimization.

I am prejudiced by the fact that I have jar file caching on all of my clients 
via my vhttp: protocol handler and thus I don't care about the size or duplicity 
of downloads because they only happen once per service, when it is launched by 
the user/client.

Gregg Wonderly

Gregg Wonderly

View raw message