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
