My alternative solution to the same problem as Gregg's was to compute SHA-1 hashes of the codebase jars, use that hash in the codebase URLs, and aggressively cache the jars client-side via a custom URLStreamHandlerFactory implementation instantiated in my PreferredClassProvider subclass. It works great -- it dramatically reduced startup time after the first deployment and I no longer have to worry too much about codebase jar sizes because I almost never need to download them. And it didn't require any code changes except in the createLoader() method of my PreferredClassProvider subclass.
Chris -----Original Message----- From: Gregg Wonderly [mailto:gr...@wonderly.org] Sent: Monday, January 31, 2011 7:30 PM To: river-dev@incubator.apache.org Subject: Re: MarshalledServiceItem One of the important things for my use of my changes to the ServiceRegistrar interface was separating deserialization of the Entrys from the service object. Ultimately, I wanted to not have to worry about how the "codebase" was structured in order to minimize downloading. Some Jini deployers have done things to put a small jar at the front of the codebase that just has the preferred.list in it. Even that download, for me, would have been too much. My customers' deployments have nearly 50 codebases visible when my client starts up. Those 50 connections over a cellular or other high latency network would make service selection take way too long. Being able to defer downloading was also controlled by the changes to ClassLoading to include the "neverPrefer" settings on a class name. I can do that now through the recent RMIClassLoaderSPI override capabilities. But I still need to be able to control which Entry is deserialized. I need to be able to ask what classes, by name, are in the namespace of each Entry object as my implementation allowed. I had made changes to Reggie marshalling to use reflection to get the class hierarchy, and then provided access to the list of classnames as part of the returned, marshalled value in my API. Gregg Wonderly On Jan 30, 2011, at 2:23 PM, Peter Firmstone wrote: > Gut feel, tells me the following class is not right, it's intent is to provide an api for implementation of delayed unmarshalling and provisioning of codebases, for services implementing a lookup service or ServiceRegistrar, whilst retaining backward compatibility. > > In other words, the lookup service proxy would implement it. > > Thoughts I had were to declare IOException's on methods, and to return a String annotation, rather than a URI. > > What are your thoughts? > > Cheers, > > Peter. > > /* > * Licensed to the Apache Software Foundation (ASF) under one > * or more contributor license agreements. See the NOTICE file > * distributed with this work for additional information > * regarding copyright ownership. The ASF licenses this file > * to you under the Apache License, Version 2.0 (the > * "License"); you may not use this file except in compliance > * with the License. You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > * See the License for the specific language governing permissions and > * limitations under the License. > */ > > package org.apache.river.api.lookup; > > import java.net.URI; > import java.security.CodeSource; > import net.jini.core.entry.Entry; > import net.jini.core.lookup.ServiceID; > import net.jini.core.lookup.ServiceItem; > > /** > * MarshalledServiceItem extends ServiceItem and can be used anywhere a > * ServiceItem can. A MarshalledServiceItem implementation instance > * contains the marshalled form of a Service and it's Entry's, > * the corresponding superclass ServiceItem however contains null values > * for the service and can exclude any Entry's, however where Entry > * classes already exist at the client, that they be unmarshalled. > * > * The ServiceID shall be in unmarshalled form always in the ServiceItem super class. > * > * Since the ServiceItem.service is null, use of this class in existing software > * will not return the service, however it will not break that software as > * ServiceItem's contract is to set service or Entry's to null when they cannot > * be unmarshalled. > * > * ServiceItem's toString() method will return a different result for > * MarshalledServiceItem instances. > * > * If required, a new ServiceItem that is fully unmarshalled > * can be constructed from this class's methods and ServiceID. > * > * @author Peter Firmstone. > */ > public abstract class MarshalledServiceItem extends ServiceItem{ > private static final long SerialVersionUID = 1L; > protected MarshalledServiceItem(ServiceID id, Entry[] unmarshalledEntries){ > super(id, (Object) null, unmarshalledEntries); > } > /** > * Unmarshall the service proxy. > * @param load service with local or existing CodeSource or null for > * default. > * @return the service proxy, null if class not found. > */ > public abstract Object getService(CodeSource[] code); > /** > * Unmarshall the Entry's > * @return array of Entry's, null entry in array for any class not found. > */ > public abstract Entry[] getEntries(); > public abstract URI[] getAnnotations(); > } >
