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 <j...@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<br...@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 >>> br...@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.re...@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 >> >