Startable only had one purpose:
To provide the implementor a thread of execution after construction completes.
It's provided by the the infrastructure to the service implementation, what the
implementor does with it is their business.
One alternative was, for our service implementations to be moved to abstract
classes and threads started and exporting performed in stateless concrete
classes, the other was to removal all final field modifiers, Startable was
simple and seemed more elegant.
That's about it in a nutshell, sorry if you got the impression it had another
purpose.
The problem with the tests; they've had bug fixes too, so people have trouble
trusting them.
The section of code you've found in Outrigger is ugly but correct, ideally sync
would be the responsibility of resource but in this case it's external.
Peter.
----- Original message -----
> Peter,
>
> I've been silent for a bit (lots going on for me), but suffice it to say
> I don't have any issue with you going after the many issues
> (synchronization based and other) that River has. For goodness sake,
> we're dealing with a codebase that is 1.4 based and has many issues,
> you've uncovered many of them.
>
> I just took a quick look at OutriggerServerImpl, and saw this:
>
> 1701: public long renew(Uuid cookie, long extension)
> 1702: throws UnknownLeaseException, LeaseDeniedException
> 1703: {
> 1704: leaseLogger.entering("OutriggerServerImpl","renew");
> 1705:
> 1706: LeasedResource resource;
> 1707: LeasePeriodPolicy policy;
> 1708:
> 1709: if (null != (resource = contents.getLeasedResource(cookie)))
> 1710: policy = entryLeasePolicy;
> 1711: else if (null !=
> 1712: (resource = (LeasedResource)eventRegistrations.get(cookie)))
> 1713: policy = eventLeasePolicy;
> 1714: else if (null !=
> 1715: (resource = (LeasedResource)contentsQueries.get(cookie)))
> 1716: policy = contentsLeasePolicy;
> 1717: else
> 1718: throw throwNewUnknownLeaseException(cookie);
> 1719:
> 1720: synchronized (resource) {
>
> ...
> }
>
> How is that exactly supposed to work? There are many cases just like
> this in the codebase that need to be addressed.
>
> Not to mention getting River up to Java 7 (at least). There is no
> support for generics (I see you've at least changed Configuration to
> support so casting is not required (thank god)). There are so many
> idioms of modern Java development are simply not even close to being
> available.
>
> So a suggestion; maybe we have the legacy branch (2.2) maintained, and
> River 3.0 moved forward and created from the qa_refactor branch. The new
> River 3.0 includes the repackaging of com.sun.jini to org.apache.river,
> includes the work you've been doing (we need to at least have a list of
> the changes). Seems like a nice break. Also, if the tests pass, whats
> the issue with the work thats been done in qa_refactor?
>
> BTW, I'm not particularly sold on Startable, because the interface does
> not guarantee anything. A service implementation can still call start()
> in it's constructor and all of the intentions of the interface are moot.
> Unless a service's lifecycle can be controlled by an invoking class, you
> have no guarantees.
>
> Regards
>
> Dennis
>
> On Jan 21, 2014, at 840PM, Peter <j...@zeus.net.au> wrote:
>
> > I can only give you my own thoughts and experiences, others may think
> > differently.
> >
> > The current codebase was created through an experimental development
> > process by Sun, it hadn't been compiled and tested on Java 5 until
> > River took ownership. The code's now a tad on the brittle side,
> > fixing something simple, often reveals unrelated latent bugs. A
> > change in JDK version is also doing exactly that right now, see our
> > windows 2008 JDK7 Jenkins build, 45 test failures. - Don't deploy on
> > Java 7 yet is my advise.
> >
> > To change the codebase to a more theory driven design, means fixing
> > code that works good enough, which also causes latent bugs to manifest.
> >
> > Making such a transition means fixing a lot of non compliant code, or
> > releasing with some failing tests and risk latent bugs manifesting
> > during deployment. Out of interest, Porter (Jini 2.1) was released
> > with some tests disabled, including a stress test for Outrigger,
> > StressTestInterleaved, that test now passes on qa_refactor.
> >
> > The benefit of these changes is more robust easier to maintain and
> > develop code.
> >
> > The risk is we might unintentionally break something.
> >
> > This is one of those cases, where it's easy to criticise, but hard to
> > do.
> >
> > The River community has spoken with their silence on this occassion.
> >
> > Unless some discussion indicates otherwise, I intend to let the River
> > community decide when it's ready to integrate fixes from qa_refactor
> > and will no longer be looking to merge and release.
> >
> > For that reason, I also reccommend reverting trunk, with the exception
> > of Sim's recent work, which I have peer reviewed.
> >
> > Regards,
> >
> > Peter.
> >
> >
> > ----- Original message -----
> > > Given the number of users on this mailing list, and the tiny number
> > > of votes, it seems that many people are abstaining.
> > > Why is this such a touchy issue?
> > >
> > > --
> > > Dawid Loubser <da...@travellinck.com>
> > >
> > >
> > > Op Ma, 2014-01-20 om 09:25 -0500 skryf Greg Trasuk:
> > >
> > > > On Jan 20, 2014, at 3:00 AM, Peter Firmstone <j...@zeus.net.au>
> > > > wrote:
> > > >
> > > > > Greg,
> > > > >
> > > > > We need to define the terms of reference for our discussion of
> > > > > proposed changes. We need to avoid emotive arguments, like
> > > > > “complete red herring”, “cascade of further failures” and
> > > > > “sweeping changes”. I believe a much greater risk is not
> > > > > fixing issues, I believe I can demonstrate that, given the
> > > > > opportunity. I also encourage all who are interested to become
> > > > > involved.
> > > > >
> > > > > Which is why I’m asking you to vote on theory driven development:
> > > >
> > > > I will abstain from this vote.
> > > >
> > > > Cheers,
> > > >
> > > > Greg.
> > > >
> > >
> >
>
