river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: MarshalledServiceItem
Date Tue, 01 Feb 2011 20:30:00 GMT
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.


-----Original Message-----
From: Gregg Wonderly [mailto:gregg@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,
> * 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
> * 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
> * will not return the service, however it will not break that software
> * 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[]
>       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
>    */
>   public abstract Entry[] getEntries();
>     public abstract URI[] getAnnotations();
> }

View raw message