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<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
