Re: River-452 Review proposed changes to standards.

[Gerard Fulton]

Hi Dan, below is the link to the issue.

https://issues.apache.org/jira/browse/RIVER-452

On Mon, Mar 12, 2018 at 2:27 PM, Dan Rollo  wrote:

> Hi Peter,
>
> I started to try and find 'River-452’ in Jira, but can not having any luck
> finding our Jira. What am I missing?
>
> The JIRA link on this page: https://river.apache.org/user-
> doc/found-a-bug.htm
> never returns: http://issues.apache.org/jira/browse/RIVER
>
> -Dan

Re: Code Review Request: Remove references to Java from in jini-spec.html

[Gerard Fulton]

Thanks Peter. I opened story RIVER-450 which has task RIVER-451 which
contains my current patch.

Gerard

On Sat, Feb 10, 2018 at 8:46 PM, Peter <j...@zeus.net.au> wrote:

> Hi Gerard,
>
> Can you create an issue on JIRA and upload your patch there?
>
> It looks like the mail server removed your attachment, apache uses Jira,
> so any contributions are licensed under al2.
>
> Thanks,
>
> Peter.
>
>
> On 11/02/2018 2:44 AM, Gerard Fulton wrote:
>
>> As part of a larger effort the attached patch, jini-spec.patch, contains
>> updates that attempt to  decouple Jini from Java in the jini-spec.html
>> document. Please review and provide comments and change requests.
>>
>> Change Summary
>> ==
>> - Removed text from the supporting images
>> - Updated the spec version to 2.0.0 using semver (https://semver.org/)
>> - Attempted to removed all references to Java and the Java virtual machine
>>
>> Gerard
>>
>>
>>
>

Re: Prioritize Modernizing The Specification

[Gerard Fulton]

I agree with the points made by Gregg about mobile code being one of Jini's
principal benefit and that there are multiple ways to implement the mobile
code concept. Hopefully we can refactor the Jini specifications to contain
narrowly scoped assumptions where the infrastructure, programming model,
and services as free as possible from implementation details.

--Gerard

On Sat, Feb 3, 2018 at 6:25 PM, Gregg Wonderly <gr...@wonderly.org> wrote:

> The principal benefit of Jini is mobile code.  Everything else is just
> network communications.  The primary problem is inexperienced developers or
> web developers who just want to send a user interface around.  ServiceUI
> makes that possible in Jini, but the lease services along with transaction
> services and all natures of mobile code allow you to create the complete
> UI/UX in one language with the ability to not write CSS, HTML and Java
> Script all glued together.  Instead, you get an end to end, uniform
> development and runtime environment.
>
> The Web is full of mobile code in the form of JavaScript and other
> dynamically loaded and bound pieces.  But it suffers from single threaded
> user interfaces and the limitations of the web, in general, around network
> restrictions.
>
> Gregg
>
> Sent from my iPhone
>
> > On Feb 1, 2018, at 5:39 AM, Peter <j...@zeus.net.au> wrote:
> >
> > Hello Gerard,
> >
> > Help is always welcomed, the Jini standards are quite old, so yes, I
> think it's an area definitely in need of some love.  Documentation or
> standards that explain the philosophies / design patterns River is based
> on, I can see how that adds appeal.   I'll certiainly jump in and help with
> reviews, there might be others interested in becoming involved as well.
> >
> > Thanks,
> >
> > Peter.
> >
> >> On 1/02/2018 12:09 PM, Gerard Fulton wrote:
> >> Hi Guys,
> >>
> >>
> >>
> >> I wanted to float an idea by list that has been in my head for several
> >> years. The idea is to prioritize the modernization of the River
> >> specification into a set of language a d transport agnostic
> architectural
> >> principles. River currently supports architectural concepts like
> discovery,
> >> events, proxies and more! In reality, both the implementation language
> and
> >> communication transport are minor details. For example a discovery
> service
> >> implementation could backed by DNS and exposed by a WebSockets
> >> communications transport protocol. I my opinion the most important part
> of
> >> the DNS discovery service example is the application protocol which
> >> potentially could be defined by a request/response model.
> >>
> >>
> >>
> >> As a Java developer, I fear that the wider adoption and growth of River
> are
> >> being empeeded by our laser like focus on River's Java reference
> >> implementation.
> >>
> >>
> >>
> >>
> >>
> >> Feedback is a gift!
> >>
> >>
> >>
> >> -Gerard Fulton
> >>
> >
>

Prioritize Modernizing The Specification

[Gerard Fulton]

Hi Guys,



I wanted to float an idea by list that has been in my head for several
years. The idea is to prioritize the modernization of the River
specification into a set of language a d transport agnostic architectural
principles. River currently supports architectural concepts like discovery,
events, proxies and more! In reality, both the implementation language and
communication transport are minor details. For example a discovery service
implementation could backed by DNS and exposed by a WebSockets
communications transport protocol. I my opinion the most important part of
the DNS discovery service example is the application protocol which
potentially could be defined by a request/response model.



As a Java developer, I fear that the wider adoption and growth of River are
being empeeded by our laser like focus on River's Java reference
implementation.





Feedback is a gift!



-Gerard Fulton

Re: Apacher River over Internet

[Gerard Fulton]

One potential approach is to create a service that registers a proxy that
is capable of communicating across networks.

On Wed, Jun 3, 2015 at 6:58 PM, Sergio Gomes sergio_go...@fedeltapos.com
wrote:

 Hi, I have an client/server application using Apache River using the
 BasicJeriExporter over tcp/ip. Now I have a requirement to use it across
 the Internet (currently using local network). How could be it done? I saw
 Apache River can communicate using IIOP, would it be a good approach? Has
 someone tried to use Apache River over IIOP?

 Thank you.

Re: tools.jar

[Gerard Fulton]

The ClassServer could be replaced with and sock web server like Apache or
Jetty to serve up classes/codebase via http.


On Tue, Jun 25, 2013 at 11:18 AM, Tom Hobbs tvho...@googlemail.com wrote:

 Hi Matt,

 If my memory serves me, River still has the same dependency so you should
 be fine just swapping the Jini jars for the River ones.

 Please note though, that removing the dependencies on the com.sun package
 is in the plan...somewhere.

 I've copied your email to the dev group because that's where most of the
 action happens.

 Cheers,

 Tom
 Hi,

 Our app has a dependency on jini / tools.jar / 2.1 as we use
 com.sun.jini.tool.ClassServer. Is this still OK when upgrading to River or
 has this now been packaged up somewhere else or upgraded? Are there any
 examples of maven POMs?

 Thanks for your help.

 Matt

 www.sucdenfinancial.com

 Sucden Financial Limited, Plantation Place South, 60 Great Tower Street,
 London EC3R 5AZ
 Telephone +44 203 207 5000

 Registered in England no. 1095841
 VAT registration no. GB 446 9061 33

 Authorised and Regulated by the Financial Conduct Authority (FCA) and
 entered in the FCA register under no. 114239

 This email, including any files transmitted with it, is confidential and
 may be privileged. It may be read, copied and used only by the intended
 recipient. If you are not the intended recipient of this message, please
 notify postmas...@sucfin.com immediately and delete it from your computer
 system.

 We believe, but do not warrant, that this email and its attachments are
 virus-free, but you should check.

 Sucden Financial Limited may monitor traffic data of both business and
 personal emails. By replying to this email, you consent to Sucden Financial
 's monitoring the content of any emails you send to or receive from Sucden
 Financial . Sucden Financial is not liable for any opinions expressed by
 the sender where this is a non-business email.

 The contents of this e-mail do not constitute advice and should not be
 regarded as a recommendation to buy, sell or otherwise deal with any
 particular investment.

 This message has been scanned for viruses by Mimecast.

Re: Migrating data in a JavaSpace

[Gerard Fulton]

One easy option may be to write a simple client using your old code to
serialize the entries in the space to XML on disk. Then launch your new
application and put entries into the space instance.


On Mon, Feb 4, 2013 at 3:34 AM, Dawid Loubser da...@travellinck.com wrote:

 Thanks for the quick response, Dan!

 I want to understand the classloading a bit better. Let me explain to
 you how I *think* it works. Also, for reference, I'm using the rio
 project, that has a special classloader that understands URLs in the
 form artifact:foo:bar:1.0 and which loads classes from Maven
 artifacts, but I think it's conceptually the same as any other URL
 scheme etc.

 * When an  Entry it written to space, it's turned into a
 MarshalledInstance. This is annotated with the codebase (a collection of
 URLs). Immediate question: Is there only one codebase at the top-level
 of the entry, or does every object in the graph have (or can have) its
 own codebase?

 * When a worker takes/reads an entry (which might contain things that
 both are on the worker's classpath, and perhaps lower-level content that
 is not (i.e. specialisations that it does not have to understand), how
 does the space proxy know what to do? I imagine it uses the thread
 context class loader, but then how does it deserialise the objects that
 is not on that classpath (using the codebase annotation of the
 MarshalledInstance, I imagine) whilst not colliding with the classes
 already available to the worker? Using some sort of parent/child
 delegation?

 I've got a very tricky ClassCastException problem I'm trying to debug,
 where it's clearly the same class loaded by two classloaders, and thus
 the field cannot be assigned. I don't know how to get in there and
 solve the problem, it seems I can only respond to the
 UnusableEntryException, get the partial entry, and lose the rest?

 thanks so much,
 Dawid


 On Mon, 2013-02-04 at 11:17 +, Dan Creswell wrote:
  On 4 February 2013 11:10, Dawid Loubser da...@travellinck.com wrote:
   Hi all,
  
   I have a bunch of entries in a JavaSpace (representing long-running
   process state, i.e. they exist for days or weeks), and these contain
   some objects that were generated from XML (using JAXB). That vocabulary
   has evolved (additions only) but now, of course, the computed
   SerialVersionUIDs will be different. When I redeploy my workers that
   have been built against the new API, they will surely fail when reading
   the old entries.
  
   Any strategies as to how I can migrate the data in the space? I'm
   running a persistent outrigger (snaplogstore). I was thinking of, in a
   worker with an 'old' classpath, draining the space, and storing those
   entries in some non-java representation on disk, and then in a worker
   with the 'new' classpath, reading those entries and re-populating the
   space.
 
  Slightly more complicated but it's possible to have one worker do all
  this with some classloader magic. You basically load old and new
  definitions into separate classloaders with the old version being
  directly on the classpath, the other dynamically loaded from something
  not on the classpath.
 
  Then you can take the old easily and use reflection magic to populate
  a new and write it.
 
  One other challenge is that most JavaSpace implementations don't like
  mixed schemas do probably you're better to create a second space,
  write the migrated ones into that and then turn off the old one (or
  copy back to the old once you've cleared it down/re-built it).
 
  
   Migrating data in a space is surely something that must have caused
   problems for somebody before, and I'd love to tackle this problem
   drawing on some experience of others.
  
   regards,
   Dawid
  

Re: Out of curiousity...(was:Re: Migrating data in a JavaSpace)

[Gerard Fulton]

Hi Greg, One of the major players providing space backed persistence is
Gigaspaces. The whole company is now modeled around concept of java spaces.
One of the big pushes for Gigaspaces is the concept of a space based
in-memory distributed data grid. Their architecture makes the space the
primary data store. The java space is the foundation for the transport,
persistence, and execution layers.

Gerard


On Mon, Feb 4, 2013 at 11:29 AM, Greg Trasuk tras...@stratuscom.com wrote:


 Out of curiousity, how frequently do people use JavaSpaces as a
 long-term persistence mechanism?  Obviously, it's one of the
 possibilities envisioned by the JavaSpace spec, but most examples I've
 seen (and certainly the ones I've implemented) have JavaSpaces as more
 of short-term communications mechanism.  Master-worker pattern,
 scatter-gather, data flow design, or map-reduce styles tend to be
 shorter-term, for instance, even if they use a persistence mechanism to
 guard against server failure.

 Cheers,

 Greg.

 On Mon, 2013-02-04 at 12:49, Dan Creswell wrote:
  On 4 February 2013 17:32, Dawid Loubser da...@travellinck.com wrote:
   Thanks Gerard,
  
   That does sound reasonable, but wouldn't I effectively lose the unique
   individual codebase annotations of each entry? I have various unrelated
   services that interact in often-complex ways. Consider the following:
  
   * In foo-api, I have an entry called FooEvent
   * In my space-based timer api, I have an entry called PublishLater, and
   a particular instance of PublishLater contains an instance of FooEvent,
   and a timestamp that says when to publish the nested entry.
  
   The timer service (and the timer-api) has no knowledge of foo-api.
 There
   would be no generic way to write that PublishLater entry to XML, and
   parse it again, making sure that the nested FooEvent has the correct
   codebase (which will be distinct from the codebase of the higher-level
   Entry). I have many such occurrences of entries generically containing
   other entries, and the codebase has to remain intact for each.
  
   I think I will (as Dan suggested( have to write a Java-based migration
   tool, that (using reflection) reconstructs each Entry, taking care to,
   at each level, retain the proper codebase, with only the changes
   required for the migration. Because I'm using Rio's maven-based class
   loading, I know that where a codebase URL was
 artifact:foo:bar-api:1.0
   I can now reconstruct it, replacing it with artifact:foo:bar-api:1.1.
  
   This will be very interesting indeed, and I need to do it ASAP :-( A
   production deployment depends on this. After reading the Entry spec, it
   seems that only at each top-level field of an Entry can each object
 have
   a different codebase, right? (and not at lower levels within those
   objects). If so, that'll make things a lot easier.
 
  I think it would be possible for something below top-level field to
  have its own codebase but that would be extremely rare (too ugly to
  work with).
 
  More importantly I don't think you need to be that generic as I
  suspect that your codebase probably does obey the top-level field
  rule you mention. You could check that somewhat by doing a JavaSpace05
  contents and dumping out class and associated classloader plus
  codebase if present for each entry top to bottom (in fact you could
  store it all up in a couple of hashtables and then dump it out which'd
  save you reading through piles of duplicates).
 
  
   Anybody have any experience doing this the hard (with Java
   classloading) way?
 
  Anyone who's implemented a JavaSpace at least ;)
 
  Seriously, if you need some advice or whatever, punt a request up
 here
 
  
   Dawid
  
  
   On Mon, 2013-02-04 at 06:56 -0800, Gerard Fulton wrote:
   One easy option may be to write a simple client using your old code to
   serialize the entries in the space to XML on disk. Then launch your
 new
   application and put entries into the space instance.
  
  
   On Mon, Feb 4, 2013 at 3:34 AM, Dawid Loubser da...@travellinck.com
 wrote:
  
Thanks for the quick response, Dan!
   
I want to understand the classloading a bit better. Let me explain
 to
you how I *think* it works. Also, for reference, I'm using the rio
project, that has a special classloader that understands URLs in the
form artifact:foo:bar:1.0 and which loads classes from Maven
artifacts, but I think it's conceptually the same as any other URL
scheme etc.
   
* When an  Entry it written to space, it's turned into a
MarshalledInstance. This is annotated with the codebase (a
 collection of
URLs). Immediate question: Is there only one codebase at the
 top-level
of the entry, or does every object in the graph have (or can have)
 its
own codebase?
   
* When a worker takes/reads an entry (which might contain things
 that
both are on the worker's classpath, and perhaps lower-level content
 that
is not (i.e

Re: LookupLocator

[Gerard Fulton]

Agreed.


On Tue, Nov 13, 2012 at 6:57 PM, Gregg Wonderly ge...@cox.net wrote:

 Of course, the practical matter, is that in this day and age, server port
 numbers indicate specific types of services for the things in
 /etc/services.  But, really, we should move the whole discovery business
 away from socket creation parameters and into a mechanism using an
 interface or abstract class so that through Configuration, it would be
 pluggable at deployment.

 Gregg

 On Nov 13, 2012, at 6:05 PM, Peter j...@zeus.net.au wrote:

  Hi Greg,
 
  LookupLocatorDiscovery uses LookupLocator to find a Registrar, however
 it only uses the host name and port, it doesn't use LookupLocator to
 perform discovery.
 
  LookupLocator requires a defined static port, otherwise 4160 is used if
 no port is defined.
 
  Recently a SocketFactory was added to LookupLocator, however this is
 only used by the obsolete version 1 discovery in LookupLocator and not by
 LookupLocatorDiscovery.
 
  LookupLocator is also Serializable, but it's constructed with multicast
 discovery where the SocketFactory cannot be transferred.
 
  It seems we'd be better off using URI, in fact when LookupLocator is
 constructed, it uses URI to assist parsing the host name and port.
 
  Instead of mandating Socket we could consider using a jeri Endpoint.
 
  A URI scheme provider could be used for plugging in different schemes to
 obtain the Endpoint.
 
  This might allow the use of maven provisioning or similar to obtain an
 unknown scheme or Endpoint.
 
  This would allow plugging in dns-srv URI's and other unknown future
 protocols for obtaining a registrar proxy.
 
  A default jini://host:port provider can be supplied for backward
 compatibility.
 
  Thoughts?
 
  Peter.
 
 
  - Original message -
 
  On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
  Presently LookupLocator is practically a URI of the form
  jini://hostname:port
 
  LookupLocator is constructed during multicast discovery at the client.
 
  ConstrainableLookupLocator is a subclass that implements constraints.
 
  LookupLocatorDiscovery also accepts LookupLocator to perform unicast
  discovery using constraints.
 
  We modified LookupLocator to accept a SocketFactory via a constructor
  (approx 2 years ago).
 
  LookupLocator is built around tcp, but there are obviously many
 protocols.
 
  Any ideas?
 
  I'm not sure I understand the question.  Is there a problem with
  LookupLocator?
 
  Cheers,
 
  Greg.
 
 
  Oh I found a bug in LookupLocator on ARM btw:
 
  Seems to be something wrong with the parser, dropping the port number,
  getting closer to fixing it at least now I know why port 4160 is always
  in use ;).
 
  BaseQATest.startInitLookups FINE:  initial lookups started != initial
 lookups
  wanted BaseQATest.startInitLookups FINE:  initial lookups started --
  BaseQATest.displayLookupStartInfo FINE:  # of lookups = 3
  BaseQATest.displayLookupStartInfo FINE:  locator lookup[0] =
  ConstrainableLookupLocator[[jini://je-cal-12.apache.org:37955/],
 [null]]
  GroupsUtil.displayGroupSet FINE:  group[0] =
  LLDGroup0_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE:
  group[1] = LLDGroup0_B_je-cal-12_1352811309324
 GroupsUtil.displayGroupSet
  FINE:  group[2] = LLDGroup0_C_je-cal-12_1352811309324
  BaseQATest.displayLookupStartInfo FINE:  locator lookup[1] =
  ConstrainableLookupLocator[[jini://je-cal-12.apache.org:49744/],
 [null]]
  GroupsUtil.displayGroupSet FINE:  group[0] =
  LLDGroup1_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE:
  group[1] = LLDGroup1_B_je-cal-12_1352811309324
 GroupsUtil.displayGroupSet
  FINE:  group[2] = LLDGroup1_C_je-cal-12_1352811309324
  GroupsUtil.displayGroupSet FINE:  group[3] =
  LLDGroup1_D_je-cal-12_1352811309324 BaseQATest.displayLookupStartInfo
 FINE:
  locator lookup[2] =
  ConstrainableLookupLocator[[jini://je-cal-12.apache.org:57373/],
 [null]]
  GroupsUtil.displayGroupSet FINE:  group[0] =
  LLDGroup2_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE:
  group[1] = LLDGroup2_B_je-cal-12_1352811309324
 GroupsUtil.displayGroupSet
  FINE:  group[2] = LLDGroup2_C_je-cal-12_1352811309324
  BaseQATest.startInitLookups FINE:  initial lookups wanted --
  BaseQATest.displayLookupStartInfo FINE:  # of lookups = 3
  BaseQATest.displayLookupStartInfo FINE:  locator lookup[0] =
  ConstrainableLookupLocator[[jini://je-cal-12.apache.org:4160/],
 [null]]
  GroupsUtil.displayGroupSet FINE:  group[0] =
  LLDGroup0_A_je-cal-12_1352811309324 GroupsUtil.displayGroupSet FINE:
  group[1] = LLDGroup0_B_je-cal-12_1352811309324
 GroupsUtil.displayGroupSet
  FINE:  group[2] = LLDGroup0_C_je-cal-12_1352811309324
  BaseQATest.displayLookupStartInfo FINE:  locator lookup[1] =
  ConstrainableLookupLocator[[jini://je-cal-12.apache.org:4160/],
 [null]]
  GroupsUtil.displayGroupSet FINE:  

Re: LookupLocator

[Gerard Fulton]

One possibility may be to consider makeing LookupLocator an interface
given that there are only two methods that really matter.
Implementations could support a socket based protocol like it is now
and other protocols in the future. I know that this would affects
current deployments; but it gives you a lot of bang for your buck.

public ServiceRegistrar getRegistrar()

public ServiceRegistrar getRegistrar( int timeout )



On Tue, Nov 13, 2012 at 5:31 AM, Peter Firmstone j...@zeus.net.au wrote:

 Presently LookupLocator is practically a URI of the form
 jini://hostname:port

 LookupLocator is constructed during multicast discovery at the client.

 ConstrainableLookupLocator is a subclass that implements constraints.

 LookupLocatorDiscovery also accepts LookupLocator to perform unicast
 discovery using constraints.

 We modified LookupLocator to accept a SocketFactory via a constructor
 (approx 2 years ago).

 LookupLocator is built around tcp, but there are obviously many protocols.

 Any ideas?

 Oh I found a bug in LookupLocator on ARM btw:

 Seems to be something wrong with the parser, dropping the port number,
 getting closer to fixing it at least now I know why port 4160 is always in
 use ;).

 BaseQATest.startInitLookups FINE:  initial lookups started != initial
 lookups wanted
 BaseQATest.startInitLookups FINE:  initial lookups started --
 BaseQATest.**displayLookupStartInfo FINE:# of lookups = 3
 BaseQATest.**displayLookupStartInfo FINE:  locator lookup[0] =
 ConstrainableLookupLocator[[**jini://je-cal-12.apache.org:**37955/http://je-cal-12.apache.org:37955/],
 [null]]
 GroupsUtil.displayGroupSet FINE:group[0] = LLDGroup0_A_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[1] = LLDGroup0_B_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[2] = LLDGroup0_C_je-cal-12_*
 *1352811309324
 BaseQATest.**displayLookupStartInfo FINE:  locator lookup[1] =
 ConstrainableLookupLocator[[**jini://je-cal-12.apache.org:**49744/http://je-cal-12.apache.org:49744/],
 [null]]
 GroupsUtil.displayGroupSet FINE:group[0] = LLDGroup1_A_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[1] = LLDGroup1_B_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[2] = LLDGroup1_C_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[3] = LLDGroup1_D_je-cal-12_*
 *1352811309324
 BaseQATest.**displayLookupStartInfo FINE:  locator lookup[2] =
 ConstrainableLookupLocator[[**jini://je-cal-12.apache.org:**57373/http://je-cal-12.apache.org:57373/],
 [null]]
 GroupsUtil.displayGroupSet FINE:group[0] = LLDGroup2_A_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[1] = LLDGroup2_B_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[2] = LLDGroup2_C_je-cal-12_*
 *1352811309324
 BaseQATest.startInitLookups FINE:  initial lookups wanted --
 BaseQATest.**displayLookupStartInfo FINE:# of lookups = 3
 BaseQATest.**displayLookupStartInfo FINE:  locator lookup[0] =
 ConstrainableLookupLocator[[**jini://je-cal-12.apache.org:**4160/http://je-cal-12.apache.org:4160/],
 [null]]
 GroupsUtil.displayGroupSet FINE:group[0] = LLDGroup0_A_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[1] = LLDGroup0_B_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[2] = LLDGroup0_C_je-cal-12_*
 *1352811309324
 BaseQATest.**displayLookupStartInfo FINE:  locator lookup[1] =
 ConstrainableLookupLocator[[**jini://je-cal-12.apache.org:**4160/http://je-cal-12.apache.org:4160/],
 [null]]
 GroupsUtil.displayGroupSet FINE:group[0] = LLDGroup1_A_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[1] = LLDGroup1_B_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[2] = LLDGroup1_C_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[3] = LLDGroup1_D_je-cal-12_*
 *1352811309324
 BaseQATest.**displayLookupStartInfo FINE:  locator lookup[2] =
 ConstrainableLookupLocator[[**jini://je-cal-12.apache.org:**4160/http://je-cal-12.apache.org:4160/],
 [null]]
 GroupsUtil.displayGroupSet FINE:group[0] = LLDGroup2_A_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[1] = LLDGroup2_B_je-cal-12_*
 *1352811309324
 GroupsUtil.displayGroupSet FINE:group[2] = LLDGroup2_C_je-cal-12_*
 *1352811309324
 BaseQATest.tearDown FINE:  tearDown - terminating lookup service(s)

Re: Next Release (PING)

[Gerard Fulton]

Sounds like the tests might need to be refactored.

On Thu, Nov 1, 2012 at 4:09 AM, Peter Firmstone j...@zeus.net.au wrote:
 I've noticed some new classes in the net.jini namespace, we need to move
 them to org.apache.river prior to release please, unless there is a good
 reason they should be there.

 Regards,

 Peter.

 Peter Firmstone wrote:

 Simon IJskes - QCG wrote:

 On 28-10-12 15:47, Simon IJskes - QCG wrote:

 On 28-10-12 15:45, Simon IJskes - QCG wrote:

 On 28-10-12 15:43, Tom Hobbs wrote:

 Can someone refresh my memory, please?  I recall a few months ago we
 were
 talking about gearing up for a release.  Is there any reason why we
 can't
 cut one now-ish?


 none. go for it!


 Although, what do we do with the failing tests since the URL-URI
 commits?





 I recall recently some tests were failing because of spaces in path names,
 but that's what I'd expect; spaces are used as codebase delimiters, so
 failure is correct because the path is incorrectly formatted.

 When I was developing URI changes, all tests passed when path names were
 correctly formatted, in fact it solved so many issues that the Windows
 platform can now be supported without cigwin.

 If we can find a reason URI code is not standards compliant, then lets fix
 it, but it's up to users for format their paths correctly. I've provided a
 utility class for that purpose.

 I do have a suggestion prior to release though, that all new code in
 org.apache.river be separated into org.apache.river.api or
 org.apache.river.impl.

 Cheers,

 Peter.