river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Compatibility
Date Fri, 11 Sep 2015 08:50:52 GMT
Dennis,

I've commited the code, it should  work now.

Regards,

Peter.

On 11/09/2015 1:22 PM, Peter wrote:
> Hmm, you're right, we only need to know if the method exists, we don't 
> actually need to call the method using reflection.
>
> On 11/09/2015 1:09 PM, Patricia Shanahan wrote:
>> If reflection does turn out to be too slow, could we catch 
>> java.lang.NoSuchMethodError?
>>
>> On 9/10/2015 6:34 PM, Peter wrote:
>>> The change was made for River-336.
>>>
>>> Can we refactor the Proxy's to use reflection, first discover if the 
>>> the
>>> method exists, if not revert to RMIClassLoader.getClassAnnotation?
>>>
>>> This affects proxy's for Reggie, Outrigger and Norm.
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>>
>>> On 11/09/2015 10:36 AM, Dennis Reedy wrote:
>>>> Hi Perter,
>>>>
>>>> I don’t know if this one is fixable. There are changes to
>>>> net.jini.loader.ClassLoading, that force incompatibility with it’s
>>>> predecessor. I get this for starters:
>>>>
>>>> java.lang.NoSuchMethodError:
>>>> net.jini.loader.ClassLoading.getClassAnnotation(Ljava/lang/Class;)Ljava/lang/String;

>>>>
>>>>
>>>>     at
>>>> org.apache.river.reggie.EntryClassBase.setCodebase(EntryClassBase.java:54)

>>>>
>>>>
>>>>     at
>>>> org.apache.river.reggie.ClassMapper.toEntryClassBase(ClassMapper.java:156)

>>>>
>>>>
>>>>     at
>>>> org.apache.river.reggie.ClassMapper.toEntryClassBase(ClassMapper.java:117)

>>>>
>>>>
>>>>     at org.apache.river.reggie.EntryClass.toClass(EntryClass.java:180)
>>>>     at org.apache.river.reggie.EntryRep.get(EntryRep.java:98)
>>>>     at org.apache.river.reggie.EntryRep.toEntry(EntryRep.java:202)
>>>>     at org.apache.river.reggie.Item.get(Item.java:160)
>>>>     at org.apache.river.reggie.Item.toServiceItem(Item.java:185)
>>>>     at org.apache.river.reggie.Matches.get(Matches.java:63)
>>>>     at
>>>> org.apache.river.reggie.RegistrarProxy.lookup(RegistrarProxy.java:128)
>>>>     at net.jini.core.lookup.ServiceRegistrar$lookup.call(Unknown 
>>>> Source)
>>>>
>>>> Dennis
>>>>
>>>>> On Sep 10, 2015, at 636PM, Peter<jini@zeus.net.au>  wrote:
>>>>>
>>>>> Thanks Dennis,
>>>>>
>>>>> Well spotted.
>>>>>
>>>>> This class shouldn't be in platform.jar, it should be in jsk-lib.jar
>>>>> and jsk-dl.jar
>>>>>
>>>>> It's used by org.apache.river.impl.lease.AbstractLeaseMap, which is a
>>>>> replacement for org.apache.river.lease.AbstractLeaseMap.
>>>>>
>>>>> It's also used by FiddlerLease, LandlordLease and RegistrarLease.
>>>>>
>>>>> FiddlerLeaseMap, LandlordLeaseMap and RegistrarLeaseMap all extend
>>>>> the replacement AbstractLeaseMap.
>>>>>
>>>>> This is the javadoc from the new AbstractLeaseMap:
>>>>>
>>>>> /**
>>>>> * AbstractLeaseMap is intended to work around some minor design warts
>>>>> in the
>>>>> * {@link Lease} interface:
>>>>> *
>>>>> * In the real world, when a Lease is renewed, a new Lease contract
>>>>> document
>>>>> * is issued, however when an electronic Lease is renewed the Lease
>>>>> expiry
>>>>> * date is changed and the record of the previous Lease is lost.
>>>>> Ideally the
>>>>> * renew method would return a new Lease.
>>>>> *
>>>>> * Current Lease implementations rely on a {@link Uuid} to represents
>>>>> the lease,
>>>>> * the expiry date is not included the equals or hashCode
>>>>> calculations.  For this
>>>>> * reason, two Lease objects, one expired and one valid, may be equal,
>>>>> this
>>>>> * is undesirable.
>>>>> *
>>>>> * The Lease interface doesn't specify a contract for equals or 
>>>>> hashCode,
>>>>> * all Lease implementations are also mutable, previous 
>>>>> implementations
>>>>> * of {@link LeaseMap} used Leases as keys.
>>>>> *
>>>>> * AbstractLeaseMap uses only the {@link ID}, usually a {@link Uuid}
>>>>> * provided by a Lease for internal map keys, if {@link ID} is not
>>>>> implemented
>>>>> * then the Lease itself is used as the key.
>>>>> *
>>>>> * Both Lease keys and Long values are actually stored internally as
>>>>> values
>>>>> * referred to by ID keys, allowing Lease implementations to either
>>>>> not override
>>>>> * hashCode and equals object methods or allow implementations that 
>>>>> more
>>>>> * accurately model reality.
>>>>> *
>>>>> * This implementation is thread safe, concurrent and doesn't require
>>>>> external
>>>>> * synchronization.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>> On 11/09/2015 2:55 AM, Dennis Reedy wrote:
>>>>>> I’m not sure this is about release notes. You seem quite keen on
>>>>>> getting 3.0 out the door, while I applaud the urgency, lets not dump
>>>>>> the baby out with the bath water. The net.jini namespace has not
>>>>>> been changed, the implementation of those interfaces has.
>>>>>>
>>>>>> I should be able to discover a ServiceRegistrar started from 3.0
>>>>>> from a 2.x client. The classes required should be dynamically
>>>>>> downloaded with the proxy. The change here that has been aded to
>>>>>> jsk-platform has resulted in classes (org.apache.river.api.util.ID
>>>>>> for starters), not being available. I’m not so sure this is good.
>>>>>> It’s certainly not a good thing for projects that may want to use
>>>>>> existing tools for discovery.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Dennis
>>>>>>
>>>>>>> On Sep 10, 2015, at 1242PM, Bryan Thompson<bryan@systap.com>
  
>>>>>>> wrote:
>>>>>>>
>>>>>>> I guess the question is whether River 2.x is a breaking change
in
>>>>>>> terms of
>>>>>>> cross service communications with River 3.x.  As this is a major
>>>>>>> release, I
>>>>>>> see it an opportunity to make breaking changes if we need to
make
>>>>>>> them.
>>>>>>> But there is no reason to break interoperability by accident.
>>>>>>>
>>>>>>> So, are there good reasons why River 2.x will not be able to
talk
>>>>>>> to River
>>>>>>> 3.x?  If so, can we capture them here and then summarize them
in
>>>>>>> release
>>>>>>> notes?  Is there a specific location in which the release notes
are
>>>>>>> being
>>>>>>> developed (SVN file, wiki page, etc.)?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bryan
>>>>>>>
>>>>>>> ----
>>>>>>> Bryan Thompson
>>>>>>> Chief Scientist&   Founder
>>>>>>> SYSTAP, LLC
>>>>>>> 4501 Tower Road
>>>>>>> Greensboro, NC 27410
>>>>>>> bryan@systap.com
>>>>>>> http://blazegraph.com
>>>>>>> http://blog.bigdata.com<http://bigdata.com>
>>>>>>> http://mapgraph.io
>>>>>>>
>>>>>>> Blazegraph™<http://www.blazegraph.com/>   is our ultra
>>>>>>> high-performance
>>>>>>> graph database that supports both RDF/SPARQL and 
>>>>>>> Tinkerpop/Blueprints
>>>>>>> APIs.  Blazegraph is now available with GPU acceleration using
our
>>>>>>> disruptive
>>>>>>> technology to accelerate data-parallel graph analytics and graph
>>>>>>> query.
>>>>>>>
>>>>>>> CONFIDENTIALITY NOTICE:  This email and its contents and
>>>>>>> attachments are
>>>>>>> for the sole use of the intended recipient(s) and are 
>>>>>>> confidential or
>>>>>>> proprietary to SYSTAP. Any unauthorized review, use, disclosure,
>>>>>>> dissemination or copying of this email or its contents or
>>>>>>> attachments is
>>>>>>> prohibited. If you have received this communication in error,
>>>>>>> please notify
>>>>>>> the sender by reply email and permanently delete all copies of
the
>>>>>>> email
>>>>>>> and its contents and attachments.
>>>>>>>
>>>>>>> On Thu, Sep 10, 2015 at 12:37 PM, Dennis 
>>>>>>> Reedy<dennis.reedy@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I’m building and running an example that I based off of
Greg’s
>>>>>>>> example
>>>>>>>> from the qa-refactor-namespace branch. I had a browser utility
>>>>>>>> that I use
>>>>>>>> at times running that is based on 2.2.2. I could not discover
>>>>>>>> reggie with
>>>>>>>> the browser utility because of
>>>>>>>>
>>>>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>>>>> org.apache.river.api.util.ID
>>>>>>>>         at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
>>>>>>>>         at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>>>>>>>>         at java.security.AccessController.doPrivileged(Native

>>>>>>>> Method)
>>>>>>>>         at 
>>>>>>>> java.net.URLClassLoader.findClass(URLClassLoader.java:360)
>>>>>>>>
>>>>>>>> The org.apache.river.api.util.ID class is an interface:
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * A mix in interface that provides an identity to be used
as a 
>>>>>>>> key in
>>>>>>>> Collections.
>>>>>>>> *
>>>>>>>> * @param<T>   Object identity.
>>>>>>>> * @author peter
>>>>>>>> */
>>>>>>>> public interface ID<T>   {
>>>>>>>>
>>>>>>>>     /**
>>>>>>>>      * @return object representing identity, usually a Uuid.
>>>>>>>>      */
>>>>>>>>     public T identity();
>>>>>>>> }
>>>>>>>>
>>>>>>>> Seems to be used by the following classes:
>>>>>>>>
>>>>>>>> ./src/org/apache/river/fiddler/FiddlerLease.java:import
>>>>>>>> org.apache.river.api.util.ID;
>>>>>>>> ./src/org/apache/river/impl/lease/AbstractLeaseMap.java:import
>>>>>>>> org.apache.river.api.util.ID;
>>>>>>>> ./src/org/apache/river/landlord/LandlordLease.java:import
>>>>>>>> org.apache.river.api.util.ID;
>>>>>>>> ./src/org/apache/river/lease/AbstractLease.java:import
>>>>>>>> org.apache.river.api.util.ID;
>>>>>>>> ./src/org/apache/river/reggie/RegistrarLease.java:import
>>>>>>>> org.apache.river.api.util.ID;
>>>>>>>>
>>>>>>>> Perhaps org.apache.river.api.util.ID should be in jsk-dl.jar

>>>>>>>> instead?
>>>>>>>>
>>>>>>>> As a user I might expect that I should be able to use Apache
River
>>>>>>>> 3.0
>>>>>>>> services from 2.x (perhaps not the other way around). What
do
>>>>>>>> others think?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Dennis
>>>>
>>>
>>
>
>


Mime
View raw message