Like many network environments, compatibility needs to be an important part of how services are resolved. I think it’s important that any service which can be registered should be able to be resolved by any client which can access the ServiceRegistrar instance which accepted the registration. There are of course exceptions for platforms you define yourself, by moving downloaded code to codebase code. But, I don’t think we should trivially change the “base” platform by adding references in downloaded code, to new codebase stored classes.
Gregg Wonderly > On Sep 10, 2015, at 11:55 AM, Dennis Reedy <dennis.re...@gmail.com> 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 >
