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 <[email protected]> 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<[email protected]> 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
>>> [email protected]
>>> 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<[email protected]>
>>> 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
>>
>
