----- 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. Cheers, Peter.
