So...

On 1 February 2011 01:29, Gregg Wonderly <[email protected]> wrote:

> 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.
>
>
"deserialization of Entry's from the service object"? What does "service
object" refer to?

I think you _have_ to worry about how the codebase is structured. Anything
else is a hack and if we're going to do hacks there are better ones like
bundling up people's .jars for them etc so save on connections/add caching
and such. Doing it further downstream in the lookup mechanism is treating a
symptom not the problem. Not the sort of thing that keeps a design clean or
consistent.



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.
>
>
Digging through classes belonging to a service implementation that is
designed to be encapsulated/not your concern? Does that sound right? I gotta
say, it sounds horribly invasive, very hacky and speaks of an overly complex
solution as the result of treating symptoms, not problems.

Which brings me to a point Peter made elsewhere: "delayed umarshalling and
selective unmarshalling of Entry's are very important features, missing from
River."

Important to whom? How many people are in the category?

If it's a lot of people, we should spend some time evaluating whether the
default class resolution/download/lookup approach is the generic norm and
potential replacements.

Simplistically, delaying downloading is as simple as returning a
MarshalledInstance on which one can then call .get as and when one
desires.....

Now, I haven't had my coffee yet and I've got a pile of operational worries
to attend to this morning which means I'm maybe a little shout'y,
nevertheless I for one am not convinced of the value of this and less
convinced we have the right solution which feels complex, exceptional and
clunky.


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();
> > }
> >
>
>

Reply via email to