river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: helper classes for running without lookup
Date Fri, 27 Aug 2010 10:24:44 GMT
I put a page on the Wiki about how to write self-healing proxy, I want to
tidy that up and make it formal.

I also want to write some simple helper classes for discovery (using lookup

I also want to write some (very) simple abstract classes which can be easily
extended to get very simple River services running.  In my opinion, having a
class which assumed a lot of defaults which other developers could just
extend to get their own services running would help them to start playing
with River; without getting scared away by having to delve into the specs
and detail.

I don't mind about using a skunk or just adding to the trunk.  The Ant
script will also need updating to build this extra JAR.

On Fri, Aug 27, 2010 at 11:15 AM, Sim IJskes - QCG <sim@qcg.nl> wrote:

> On 08/27/2010 12:06 PM, Tom Hobbs wrote:
>> I've a few things cluttering up my head which I'd like to include in River
>> for making things more simple for those just starting out.
>> I had in mind to create a package such as;
>> org.apache.river.extras.specificthingiamtryingtodo
>> I was also considering creating an "extras" source directory as well.
>> thoughts?
> Perfect! Shall we create a 'extra' directory in the svn jtsk/skunk
> directory? We can 'svn switch' in this directory in order to do a full build
> if we need to.
> I started a confl. page on running without lookup service, but it became a
> bit code-dominant, so i decided to write some helper classes. Actually, i
> have them already, but not in ASF ready state.
> What kind of 'extra' classes do you want to work on? If you want to work on
> the exact same subject as well, there is no problem on starting from scratch
> again, because i need to lift the current code i have from an existing
> project, and starting from scratch might create neater code.
> Gr. Sim

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message