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 Thu, 10 Sep 2015 23:37:07 GMT
My understanding is that new api, intended to be used by proxy's or 
services, should go into jsk-lib.jar and jsk-dl.jar?

Things like SecurityManager's, ClassLoaders are client based and go into 
platform.jar?

This allows for compatible evolution with previous versions.

In the past I have found it very difficult to discuss api on river-dev.  
Hopefully now that people are seeing the difficulties we have as 
implementation developers, dealing with implementation issues, we'll be 
given some breathing space to discuss them, in meaningful solutions 
based conversations.

Now that the project has decided the only api is net.jini.* it would 
seem appropriate to move the org.apache.river.api packages into 
org.apache.river.

Does anyone want to make any suggestions regarding package structure, 
also it seems we have two identically named AbstractLeasMap 
implementations, that should probably go into the same package?

Regards,

Peter.

On 11/09/2015 8:36 AM, Peter 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