The way that services are instantiated and setup is an implementation detail.
When I think of compatibility I think of the API and the lookup methods. We
think of compatibility from a client point of view. From the client point of
view, using a service looks like this:
- Use multicast of unicast discovery to find one or more
ServiceRegistrar instances
- Call lookup(…) on one or more of these instances to get a set of
service candidates
- Choose a candidate and prepare() it using a ProxyPreparer, to yield a
usable service proxy.
- Make calls on it. Ideally hang on to this proxy instance, so you can
skip the discovery and lookup next time you need it.
- If the call fails, repeat the lookup (and possibly discovery) til you
get a proxy that works.
Nowhere does the client need to know whether the service instance is started up
using the “com.sun.jini.start” mechanism, your Commission interface, some other
IOC container (Rio, Harvester, Seven or RiverContainer) or some unknown
mechanism that starts with a static main() method.
JSK2.0 was 2.0 because of the introduction of the proxy verification
mechanisms, as well as JERI. Absent some new client usage mechanism, River
doesn’t need to go to 3.0.
Cheers,
Greg.
On Dec 17, 2013, at 1:58 PM, Peter <j...@zeus.net.au> wrote:
> I think changing services to use safe construction techniques is enough to
> cause the version jump.
>
> At this point I've allowed services to continue unsafe construction
> practices, while logging a SEVERE warning when the Commission interface isn't
> implemented, rather than fail.
>
> This is a fundamental change to the way services are written.
>
> Regards,
>
> Peter.
>
> ----- Original message -----
>>
>> Assuming that there aren’t major incompatibilities, I think that would
>> be a “minor” version change according to our versioning policy, so we’d
>> be looking at the “2.3” branch rather than a “3.0” release.
>>
>> I’m still unnerved by the massive amounts of changes to both code and
>> tests in the qa_refactor branch, as well as the apparent instability of
>> the code, although that seems to be improving. In the next few weeks
>> I’m going to try and setup a cross-test case, to see what the “2.2”
>> tests say about the potential “2.3” release and vice-versa.
>>
>> I think what I’d really like to see is an incremental approach where we
>> update limited components of the “2.2” branch, one at a time. Is there
>> anything that we could pull out piecemeal? Maybe it would make sense to
>> split out the infrastructure services, like Reggie, Mahalo, and
>> Outrigger into different sub-projects that could be updated separately?
>>
>> Any thoughts?
>>
>> Greg.
>>
>> On Dec 17, 2013, at 5:03 AM, Peter <j...@zeus.net.au> wrote:
>>
>>> When the qa_refactor branch stabilises, I plan to merge trunk and
>>> provide a beta release for client compatibility testing.
>>>
>>> Changes made have been focused on making our code thread safe, there
>>> are significant changes internally, the public api remains focused on
>>> backward compatibility, however it is advisable that client services
>>> adopt new safe construction techniques for services and implement the
>>> new Commission interface.
>>>
>>> What's a suitable test period for client testing?
>>>
>>> Regards,
>>>
>>> Peter.
>>
>
