Just to clarify org.apache.river.api.util.Commission is an interface services
should implement, I would encourage all container projects to pick up the
interface and make suggestions for improvement if there are any issues.
Interface Commission {
void start () throws Exception;
}
It's called after JMM safe construction to allow the service to start any
threads and be exported.
Regards,
Peter.
----- Original message -----
>
> 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 <[email protected]> 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 <[email protected]> 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.
> > >
> >
>
