Let's imagine for a moment that we decide to change jsk-dl.jar in another way. Let's say we were going to remove some classes.
What would happen? Likely clients already at runtime wouldn't notice, they've got a jsk-dl.jar already. A newly started service might care if it were expecting it's jsk-dl.jar to contain valuable classes for it's proxy. Solving this problem requires we create a new .jar for services that wish to follow the new standard whilst maintaining the old (jsk-dl.jar) for existing services. The same pattern applies for renames such as the below. An alternative would be for some period of time to say that services wishing to use org.apache.river must include these classes in their own -dl.jar. Similar problems will exist for services making assumptions about the client's platform (there are some they can make but they should download whatever other dependencies they have but betting some don't). Problems will also exist for client's compiled against org.apache.river that at runtime are given .jars from an older Jini platform (that would also be an error). Why do I mention all this? Because whilst building and packaging are things we want to clean up, we have another set of considerations which includes whether or not we want our users to experience a breaking change. Assuming not...My own instinct is to adopt a new "namespace" for .jar names and then perform a managed transition over a few releases. I'm not wedded to these names, I use them just as an example assuming one wants to try and make the transition easy for all the circumstances I list above: (1) We deliver jsk-dl.jar, jsk-platform.jar and jsk-lib.jar with the contents they've always had. (2) We deliver a new set of .jars named jsk-apache-river-2.2-dl.jar, jsk-platform-apache-river-2.2.jar etc containing revised namespace alone. Note that second set of names contains project name and version so we be more easily migrate/shuffle things around in the future. This allows services to update themselves as and when and provide clients with new .jars should they need them via download at runtime. After a period of time we'd render the .jars in (1) empty and put everything in the .jars in (2) and only support the new namespace. This may break some clients and services but they'll be easy to spot/identify by virtue of what's on their classpath/codebase. We can of course eventually throw these old .jars away. Now it's early in the morning and classloading being as complex as it is, I wouldn't be surprised if the above has more dark cornes. If nothing else, I'm hoping it'll help us thrash out what we want to do.... On 15 January 2011 23:16, Peter <j...@zeus.net.au> 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. > > Cheers, > > Peter. >
