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 03:22:22 GMT
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