You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@river.apache.org by Gregg Wonderly <gr...@wonderly.org> on 2010/12/01 16:13:27 UTC

Re: Jini Community Projects on Java.net WAS: Re: java.net

I have requested that jini.dev.java.net be moved and I've requested that my 
individual projects be moved.  Any other projects own by others need to be dealt 
with pronto.  All users should have received emails about needed action.

Gregg Wonderly

On 11/24/2010 5:19 AM, Peter Firmstone wrote:
> There are a lot of Jini Community projects on Java.net which are probably stagnant.
>
> Do we know if any of these projects will be moved?
>
> It looks like they're all going to go the way of the dinosaur unless we preserve
> their source.
>
> Looks like we've got 6 days left to copy these projects. It will be a
> significant loss if we don't.
>
> Peter.
>
> Niclas Hedhman wrote:
>> Has this been discussed??
>>
>> <quote>
>> ACTION REQUIRED: Java.net is migrating to a new infrastructure and
>> project owners must request that projects be moved by November 30,
>> 2010. A list of projects that will be moved is here:
>> http://java.net/projects/help/pages/RequestedProjects For more details
>> please see the Community Manager's blog -
>> http://www.java.net/blog/30701
>> </quote>
>>
>>
>> Cheers
>
>

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Peter Firmstone <ji...@zeus.net.au>.

Yes, I had noticed the container, interesting.

Do you think it's possible to organise runtime ClassLoader's so Jini's
API, Java and the Service API are loaded with Java's application class
loader, while all  implementations are loaded into separate child class
loaders?  If we do this, we can keep, service implementations, client
code and proxy's in separate namespaces, forcing them to cooperate using
only Java, Jini's API and Service API.  Sort of like having separate
Classpath's for each, many are compiled separately so it makes sense if
they each bring their own lunch and don't step on each others
implementations and libraries etc.  Eg a proxy should bring with it any
additional libraries it needs and not rely on them being present at the
client.  Application libraries shouldn't be visible to the proxy.  Sort
of like Preferred Classes, but automatic without configuration.

Cheers,

Peter.



Greg Trasuk wrote:
> On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
>   
>> Usability is a tough problem we need to solve, I recall Dan Creswell 
>> highlighted some relevant issues.    If your looking at all the 
>> different down stream projects and want to get their cooperation for 
>> some common functionality, we'll need to get some community buy in.  
>> These people are probably more aware of the pitfalls and I think we need 
>> their insight.
>>
>> There's all the different containers too.  Perhaps it's time we have a 
>> standardised deployment container?  So users can choose and migrate 
>> among any of the downstream projects or our own in house simple version 
>> (that supports what you're working on) without lock in.
>>
>>     
>
> So, I've been working on a clean-room implementation of the Surrogate
> spec.  The work so far (mainly some building blocks) is in Subversion
> under jtsk/skunk/surrogate.
>
> I concluded early on that hosting Surrogates was really a subset of
> hosting plain old services.  As a result, the emerging architecture is
> that of a container that manages the classloaders and codebase servers,
> but that has a pluggable deployment architecture that can support
> surrogate packages, "starter-style" packages or other deployment units.
>
> To some extent, this container is "Harvester 2.0"; it reflects my unease
> with going through and restructuring the Harvester code for Apache
> release (I had thought about contributing Harvester, but decided to do
> this new surrogate container instead).
>
> I am envisioning a deployer that would support definition of services
> using annotations, much like EJB3 supports,  e.g.
>
> public interface HelloInterface {
>     public String sayHello(String name) throws IOException;
> }
>
> @Service
> public HelloService implements HelloInterface {
>     public String sayHello(String name) { return "Hi there " + name); }
>
>     /* @Proxy says "Inject my exported proxy here, please!" */
>     @Proxy 
>     HelloInterface myProxy=null;
> }
>
> You would create your services, pack them into a jar file (with an
> appropriate manifest) and copy the jar file into the deployment
> directory.  The deployer then goes through the jar file looking for
> @Service annotations and exports them.
>
> The container will also host (with all the codebase crap handled!)
> instances of the River infrastructure services (Reggie, Mahalo,
> Outrigger, etc).  Plus it appears that enabling it for JMX monitoring
> and management will not be awfully difficult.
>
> The goal, much like Harvester, is one-shot deployment, with a
> programming model that will not seem alien to servlet or EJB
> programmers.
>
> So, stand by, the container is starting to come together.  Once it's in
> a form that can host Reggie and deploy a service or two, I'll let you
> know.  At that point, I suppose we'll want a catchy name...
>
> Cheers,
>
> Greg.
>

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Peter Firmstone <ji...@zeus.net.au>.

Greg Trasuk wrote:
> On Sun, 2010-12-12 at 02:39, Peter Firmstone wrote:
>   
>> Yes, I had noticed the container, interesting.
>>
>> Do you think it's possible to organise runtime ClassLoader's so Jini's 
>> API, Java and the Service API are loaded with Java's application class 
>> loader, while all  implementations are loaded into separate child class 
>> loaders?  If we do this, we can keep, service implementations, client 
>> code and proxy's in separate namespaces, forcing them to cooperate using 
>> only Java, Jini's API and Service API.  Sort of like having separate 
>> Classpath's for each, many are compiled separately so it makes sense if 
>> they each bring their own lunch and don't step on each others 
>> implementations and libraries etc.  
>>     
>
> Goes without saying...Also that we don't put every single jar file in
> the codebase annotation.  Usually it's only the "-api" and "-dl" jar
> files, although there might be plain libraries as well.
>   

If done properly, the api exists at the client, so we shouldn't need to 
annotate it, I proposed a way of extending Service API in

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

This would allow additional classes not present at the client to be 
loaded into the proxy's class loader.  Since the deployed client doesn't 
have these classes, it only interacts using the Service API.

If there is a buggy implementation class in the original Service API 
installed in the client, the extended service API can provide an 
implementation class that extends and overrides the object method with 
the bug, the client only see's the service API class, while it uses the 
implementation class. Polymorphism.

>   
>> Eg a proxy should bring with it any 
>> additional libraries it needs and not rely on them being present at the 
>> client.  
>>     
>
> That's automatically handled by the rmi classloader
> (PreferredClassLoader I believe) and the appropriate codebase
> annotations.
>
>   
>> Application libraries shouldn't be visible to the proxy.  Sort 
>> of like Preferred Classes, but automatic without configuration.
>>
>>     
> That's actually up to the application author; in many cases, there is a
> need to have a dependent library available locally (e.g. for
> business-domain object classes).  The PreferredClassLoader mechanism
> used by Jeri allows the proxy to require a remotely downloaded class
> where it's absolutely necessary.
>
>   
Sounds like that library should be loaded with the same classloader as 
the Service API.  Is it typical in this case that the Service API 
contain a parameter or return class that is part of a business domain 
library?

If Service API depends on anything other than Jini & Java, that also 
needs to be included with the service API.

I'd like to provide a mechanism or encourage a practice to load 
application (implementation) classes into a child class loader, with a 
separate name space to proxy's  or other service implementations.

Tell me what you think?

http://labs.oracle.com/techrep/2006/smli_tr-2006-149.pdf

Cheers,

Peter.

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Greg Trasuk <tr...@stratuscom.com>.

On Sun, 2010-12-12 at 02:39, Peter Firmstone wrote:
> Yes, I had noticed the container, interesting.
> 
> Do you think it's possible to organise runtime ClassLoader's so Jini's 
> API, Java and the Service API are loaded with Java's application class 
> loader, while all  implementations are loaded into separate child class 
> loaders?  If we do this, we can keep, service implementations, client 
> code and proxy's in separate namespaces, forcing them to cooperate using 
> only Java, Jini's API and Service API.  Sort of like having separate 
> Classpath's for each, many are compiled separately so it makes sense if 
> they each bring their own lunch and don't step on each others 
> implementations and libraries etc.  

Goes without saying...Also that we don't put every single jar file in
the codebase annotation.  Usually it's only the "-api" and "-dl" jar
files, although there might be plain libraries as well.

> Eg a proxy should bring with it any 
> additional libraries it needs and not rely on them being present at the 
> client.  

That's automatically handled by the rmi classloader
(PreferredClassLoader I believe) and the appropriate codebase
annotations.

> Application libraries shouldn't be visible to the proxy.  Sort 
> of like Preferred Classes, but automatic without configuration.
> 
That's actually up to the application author; in many cases, there is a
need to have a dependent library available locally (e.g. for
business-domain object classes).  The PreferredClassLoader mechanism
used by Jeri allows the proxy to require a remotely downloaded class
where it's absolutely necessary.

> Cheers,
> 
> Peter.
> 
>

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Peter Firmstone <ji...@zeus.net.au>.

Yes, I had noticed the container, interesting.

Do you think it's possible to organise runtime ClassLoader's so Jini's 
API, Java and the Service API are loaded with Java's application class 
loader, while all  implementations are loaded into separate child class 
loaders?  If we do this, we can keep, service implementations, client 
code and proxy's in separate namespaces, forcing them to cooperate using 
only Java, Jini's API and Service API.  Sort of like having separate 
Classpath's for each, many are compiled separately so it makes sense if 
they each bring their own lunch and don't step on each others 
implementations and libraries etc.  Eg a proxy should bring with it any 
additional libraries it needs and not rely on them being present at the 
client.  Application libraries shouldn't be visible to the proxy.  Sort 
of like Preferred Classes, but automatic without configuration.

Cheers,

Peter.



Greg Trasuk wrote:
> On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
>   
>> Usability is a tough problem we need to solve, I recall Dan Creswell 
>> highlighted some relevant issues.    If your looking at all the 
>> different down stream projects and want to get their cooperation for 
>> some common functionality, we'll need to get some community buy in.  
>> These people are probably more aware of the pitfalls and I think we need 
>> their insight.
>>
>> There's all the different containers too.  Perhaps it's time we have a 
>> standardised deployment container?  So users can choose and migrate 
>> among any of the downstream projects or our own in house simple version 
>> (that supports what you're working on) without lock in.
>>
>>     
>
> So, I've been working on a clean-room implementation of the Surrogate
> spec.  The work so far (mainly some building blocks) is in Subversion
> under jtsk/skunk/surrogate.
>
> I concluded early on that hosting Surrogates was really a subset of
> hosting plain old services.  As a result, the emerging architecture is
> that of a container that manages the classloaders and codebase servers,
> but that has a pluggable deployment architecture that can support
> surrogate packages, "starter-style" packages or other deployment units.
>
> To some extent, this container is "Harvester 2.0"; it reflects my unease
> with going through and restructuring the Harvester code for Apache
> release (I had thought about contributing Harvester, but decided to do
> this new surrogate container instead).
>
> I am envisioning a deployer that would support definition of services
> using annotations, much like EJB3 supports,  e.g.
>
> public interface HelloInterface {
>     public String sayHello(String name) throws IOException;
> }
>
> @Service
> public HelloService implements HelloInterface {
>     public String sayHello(String name) { return "Hi there " + name); }
>
>     /* @Proxy says "Inject my exported proxy here, please!" */
>     @Proxy 
>     HelloInterface myProxy=null;
> }
>
> You would create your services, pack them into a jar file (with an
> appropriate manifest) and copy the jar file into the deployment
> directory.  The deployer then goes through the jar file looking for
> @Service annotations and exports them.
>
> The container will also host (with all the codebase crap handled!)
> instances of the River infrastructure services (Reggie, Mahalo,
> Outrigger, etc).  Plus it appears that enabling it for JMX monitoring
> and management will not be awfully difficult.
>
> The goal, much like Harvester, is one-shot deployment, with a
> programming model that will not seem alien to servlet or EJB
> programmers.
>
> So, stand by, the container is starting to come together.  Once it's in
> a form that can host Reggie and deploy a service or two, I'll let you
> know.  At that point, I suppose we'll want a catchy name...
>
> Cheers,
>
> Greg.
>

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by MICHAEL MCGRADY <mm...@topiatechnology.com>.

There is a list of quality control criteria (QCC and commonly called the "Ilities") that is helpful to keep in mind when integrating into the networking mix.   Usability, not out of importance but out of alphabet, is last on the list.  ;-)

MG


	1a.	accessibility,
	1b.	accountability,
	1c.	adaptability,
	1d.	administrability
	1.	affordability, 
	2.	agility, 
	3.	availability, 
	4.	composability, 
	5.	configurability, 
	5a.	customizability,
	5b.	degradeability,
	5c.	demonstrability,
	5d.	dependability,
	5e.	distributability,
	6.	durability, 
	7.	embedability, 
	8.	evolvability, 
	9.	extensibility, 
	10.	failover, 
	10a.  flexibility,
	11.   	installability,
	12.	integrability, 
	13.	interoperability, 
	14.	maintainability, 
	15.	manageability, 
	15a.	mobility,
	16.	modifiability, 
	17.	modularity,  
	17a.	nomadicity,
	17b. 	openness,
	18.	performance, 
	19.	platform independence, 
	20.	portability, 
	20a.	predictability,
	20b.	recoverability,
	21.	reliability, 
	22.	retractability, 
	23.	reusability, 
	24.	robustness, 
	25.	scalability, 
	25a.	seamlessness,
	26.	security, 
	27.	servicability (supportability),  
	27a.	simplicity,
	27b.	stability,
	27c.	survivability,
	27d.	tailorability,
	28.	testability, 
	29.	understandability, and 
	30.	usability


On Dec 9, 2010, at 10:39 AM, Greg Trasuk wrote:

> 
> On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
>> Usability is a tough problem we need to solve, I recall Dan Creswell 
>> highlighted some relevant issues.    If your looking at all the 
>> different down stream projects and want to get their cooperation for 
>> some common functionality, we'll need to get some community buy in.  
>> These people are probably more aware of the pitfalls and I think we need 
>> their insight.
>> 
>> There's all the different containers too.  Perhaps it's time we have a 
>> standardised deployment container?  So users can choose and migrate 
>> among any of the downstream projects or our own in house simple version 
>> (that supports what you're working on) without lock in.
>> 
> 
> So, I've been working on a clean-room implementation of the Surrogate
> spec.  The work so far (mainly some building blocks) is in Subversion
> under jtsk/skunk/surrogate.
> 
> I concluded early on that hosting Surrogates was really a subset of
> hosting plain old services.  As a result, the emerging architecture is
> that of a container that manages the classloaders and codebase servers,
> but that has a pluggable deployment architecture that can support
> surrogate packages, "starter-style" packages or other deployment units.
> 
> To some extent, this container is "Harvester 2.0"; it reflects my unease
> with going through and restructuring the Harvester code for Apache
> release (I had thought about contributing Harvester, but decided to do
> this new surrogate container instead).
> 
> I am envisioning a deployer that would support definition of services
> using annotations, much like EJB3 supports,  e.g.
> 
> public interface HelloInterface {
>    public String sayHello(String name) throws IOException;
> }
> 
> @Service
> public HelloService implements HelloInterface {
>    public String sayHello(String name) { return "Hi there " + name); }
> 
>    /* @Proxy says "Inject my exported proxy here, please!" */
>    @Proxy 
>    HelloInterface myProxy=null;
> }
> 
> You would create your services, pack them into a jar file (with an
> appropriate manifest) and copy the jar file into the deployment
> directory.  The deployer then goes through the jar file looking for
> @Service annotations and exports them.
> 
> The container will also host (with all the codebase crap handled!)
> instances of the River infrastructure services (Reggie, Mahalo,
> Outrigger, etc).  Plus it appears that enabling it for JMX monitoring
> and management will not be awfully difficult.
> 
> The goal, much like Harvester, is one-shot deployment, with a
> programming model that will not seem alien to servlet or EJB
> programmers.
> 
> So, stand by, the container is starting to come together.  Once it's in
> a form that can host Reggie and deploy a service or two, I'll let you
> know.  At that point, I suppose we'll want a catchy name...
> 
> Cheers,
> 
> Greg.
> -- 
> Greg Trasuk, President
> StratusCom Manufacturing Systems Inc. - We use information technology to
> solve business problems on your plant floor.
> http://stratuscom.com
> 

Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Greg Trasuk <tr...@stratuscom.com>.

On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
> Usability is a tough problem we need to solve, I recall Dan Creswell 
> highlighted some relevant issues.    If your looking at all the 
> different down stream projects and want to get their cooperation for 
> some common functionality, we'll need to get some community buy in.  
> These people are probably more aware of the pitfalls and I think we need 
> their insight.
> 
> There's all the different containers too.  Perhaps it's time we have a 
> standardised deployment container?  So users can choose and migrate 
> among any of the downstream projects or our own in house simple version 
> (that supports what you're working on) without lock in.
> 

So, I've been working on a clean-room implementation of the Surrogate
spec.  The work so far (mainly some building blocks) is in Subversion
under jtsk/skunk/surrogate.

I concluded early on that hosting Surrogates was really a subset of
hosting plain old services.  As a result, the emerging architecture is
that of a container that manages the classloaders and codebase servers,
but that has a pluggable deployment architecture that can support
surrogate packages, "starter-style" packages or other deployment units.

To some extent, this container is "Harvester 2.0"; it reflects my unease
with going through and restructuring the Harvester code for Apache
release (I had thought about contributing Harvester, but decided to do
this new surrogate container instead).

I am envisioning a deployer that would support definition of services
using annotations, much like EJB3 supports,  e.g.

public interface HelloInterface {
    public String sayHello(String name) throws IOException;
}

@Service
public HelloService implements HelloInterface {
    public String sayHello(String name) { return "Hi there " + name); }

    /* @Proxy says "Inject my exported proxy here, please!" */
    @Proxy 
    HelloInterface myProxy=null;
}

You would create your services, pack them into a jar file (with an
appropriate manifest) and copy the jar file into the deployment
directory.  The deployer then goes through the jar file looking for
@Service annotations and exports them.

The container will also host (with all the codebase crap handled!)
instances of the River infrastructure services (Reggie, Mahalo,
Outrigger, etc).  Plus it appears that enabling it for JMX monitoring
and management will not be awfully difficult.

The goal, much like Harvester, is one-shot deployment, with a
programming model that will not seem alien to servlet or EJB
programmers.

So, stand by, the container is starting to come together.  Once it's in
a form that can host Reggie and deploy a service or two, I'll let you
know.  At that point, I suppose we'll want a catchy name...

Cheers,

Greg.
-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com

Deployment Standards / Definitions

Posted by Peter Firmstone <ji...@zeus.net.au>.

I've created an issue on Jira.

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

Have you got any initial concepts, draft implementations, ideas etc?  
Please post them on River-379

Cheers,

Peter.

Dennis Reedy wrote:
>
>
> A 'container' is one small part of deployment. Sure Rio has a container (as do all the projects you listed below), and you can start any of the stock River services using Rio, but Rio is much more than that. If all you want is a container use ServiceStarter.
>
> Perhaps whats River needs a something that had been proposed much earlier, and that is a standard service descriptor/archive that documents that meta data associated with a service (artifacts, configuration, system requirements, etc ....). In this way developers dont require a standardized deployment container, but can be confident that using a standardized archive and bundling format that any 'container' can instantiate their service.
>
>   
>   
Gregg Wonderly wrote:
>
> What would help the most is some more rigorous definitions for how 
> deployment occurs.  The com.sun.jini.start interface is the only 
> tangible deployment signature for anything that might go into a 
> container.
>
> I've suggested on this list before that this is an issue I feel we 
> need to discuss.  I'd hope there is something which would could put 
> together as an SPI which containers could provide implementations of 
> so that not only can services be started, but they can interact with 
> the container to control lifecycle and Configuration needs.

Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Dennis Reedy <de...@gmail.com>.

On Dec 8, 2010, at 937PM, Peter Firmstone wrote:

> Usability is a tough problem we need to solve, I recall Dan Creswell highlighted some relevant issues.    If your looking at all the different down stream projects and want to get their cooperation for some common functionality, we'll need to get some community buy in.  These people are probably more aware of the pitfalls and I think we need their insight.
> 
> There's all the different containers too.  Perhaps it's time we have a standardised deployment container?  So users can choose and migrate among any of the downstream projects or our own in house simple version (that supports what you're working on) without lock in.
> 
> If this is a bad suggestion, is there a better one?
> 

A 'container' is one small part of deployment. Sure Rio has a container (as do all the projects you listed below), and you can start any of the stock River services using Rio, but Rio is much more than that. If all you want is a container use ServiceStarter.

Perhaps whats River needs a something that had been proposed much earlier, and that is a standard service descriptor/archive that documents that meta data associated with a service (artifacts, configuration, system requirements, etc ....). In this way developers dont require a standardized deployment container, but can be confident that using a standardized archive and bundling format that any 'container' can instantiate their service.

> Can we have your thoughts and input?
> 
> Dennis Reedy (Rio)
> Greg Trasuk (Harvester)
> Gregg Wonderly (Start now, whatsitdo)
> Dan Creswell (Blitz)
> Mark Brower (Seven)
> Tim Blackman (Jini in a Jar)
> Tom Cellucci (Bantam)
>

Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net

Posted by Peter Firmstone <ji...@zeus.net.au>.

Usability is a tough problem we need to solve, I recall Dan Creswell 
highlighted some relevant issues.    If your looking at all the 
different down stream projects and want to get their cooperation for 
some common functionality, we'll need to get some community buy in.  
These people are probably more aware of the pitfalls and I think we need 
their insight.

There's all the different containers too.  Perhaps it's time we have a 
standardised deployment container?  So users can choose and migrate 
among any of the downstream projects or our own in house simple version 
(that supports what you're working on) without lock in.

If this is a bad suggestion, is there a better one?

Can we have your thoughts and input?

Dennis Reedy (Rio)
Greg Trasuk (Harvester)
Gregg Wonderly (Start now, whatsitdo)
Dan Creswell (Blitz)
Mark Brower (Seven)
Tim Blackman (Jini in a Jar)
Tom Cellucci (Bantam)

We don't have everyone's participation, if you know them, perhaps you 
can pass it on?

Cheers,

Peter.

Tom Hobbs wrote:
> I agree, I certainly don't want (and don't want to *seem* to be
> someone who wants to) absorb all other projects and code.  I certainly
> don't want to assimilate anyone into my own personal collective, I've
> got enough voices in my head as it is... ;-)
>
> I had hoped that by creating the "Success Stories" page and linking to
> a bunch of downstream projects and by asking Gregg for links and
> permission to link to his projects I was avoiding coming across like
> that.
>
> Having said that; my continued pet peeve is that there is not enough
> *easy-to-get-going* stuff in the River download.
>
> The key part of that sentence is *in the River download*.
>
> There are one/two points here
> (http://pelegri.wordpress.com/2010/12/05/hudsons-secret-kohsuke/) that
> strike me as very important.  They are:
>
> - Lower the Barrier of Entry
>   - Every step that leads to participation needs to be easy
>
> In my opinion (and that's all it is) getting going with River/Jini is
> *not* easy.  Telling new users "download River, now look for a
> downstream project to go and learn as well - before you can do
> anything with your River download" is not as easy as "download River,
> extend these classes, run that script, and enjoy your Hello World
> service".  Again, my own opinion.
>
> The kind of "free stuff" I'm talking about doesn't warrant a
> sub-project, I don't think.  Just an extra JAR and source directory in
> River itself.  As to encouraging other down-stream projects to be come
> River sub-projects, I'm quite neutral about that.  However, I *do*
> want to link to those downstream projects.  I figure that once new
> users have outgrown the Hello World-type service I mention above, they
> should be directed to down-stream projects which will (I hope) be
> better implemented, more robust, have better documentation and have
> more fuller features.
>
>   
>> Gregg and his projects are part of our community, why not contribute to
>> Gregg's project instead, as it appears we're trying to implement / duplicate
>> existing functionality.
>>     
>
> I agree, when you look into the Jini community is actually quite rich
> and a big and valuable part of that are Gregg's projects.  The couple
> of *classes* that Gregg mentioned is something that I've been trying
> to find the time to write myself.
>
>   
>> perhaps it is time we widen the net, and capture some common functionality
>> implemented in various down stream projects, this would need to be done as
>> a process of consultation.
>>     
>
> Is that not what I was doing?  Your two statements conflict a little
> bit, "contribute to [down stream] projects" and "capture some common
> functionality [from] down stream projects".  I think that for any
> given piece of functionality, a decision needs to be made on what the
> right thing to do is.  And for any two different pieces of
> functionality, the "right thing" may well be different.  I think that
> a basic/abstract extensible service class would be a good thing to
> have in the River download.
>
> Maybe I just went about it all the wrong way  Maybe it was rude of me
> and I've put Gregg on a spot that he doesn't want to be on; in which
> case you have my complete and total apology.
>
> I don't really understand this para:
>
>   
>> I understand also what it feels like when your trying to get something done
>> and someone throws up a roadblock or another hoop to jump through and how
>> difficult it has been in the past to get things done, however if done
>> properly it's an achievement that you'll be recognised for, rather than
>> resented.
>>     
>
> Have I done something that has caused resentment?  I hadn't noticed,
> but if so I again apologise for it.  I don't really see any hoops or
> roadblocks (other than River not being easy for new developers).  I'm
> prepared to write these classes myself, I was just hoping not to have
> to.  As I understand the Apache Way, if people think the work is
> unnecessary, but otherwise don't object, and I'm prepared to do the
> work, then the work will get done when I get around to it.
>
> So, no hard feelings?
>
> Cheers,
>
> Tom
>
>
> On Wed, Dec 8, 2010 at 11:56 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>   
>> We are community, we need to be careful not to Borg, but to foster.
>>
>> We can encourage important projects to become River sub projects.  This will
>> grow our community further.
>>
>> Gregg and his projects are part of our community, why not contribute to
>> Gregg's project instead, as it appears we're trying to implement / duplicate
>> existing functionality.  I think you'll find other parts of his projects are
>> also useful.
>>
>> When we bring code into River from subprojects we take on the responsibility
>> of maintaining that code, it also becomes the default implementation.  We
>> have a responsibility to take more than our own needs into consideration.
>>
>> River is a platform and I agree we need to make it easier to deploy.  A lot
>> of external projects do this already, perhaps we can link to these?
>>
>> I also acknowledge that fragmentation causes confusion, so perhaps it is
>> time we widen the net, and capture some common functionality implemented in
>> various down stream projects, this would need to be done as a process of
>> consultation.
>>
>> I understand also what it feels like when your trying to get something done
>> and someone throws up a roadblock or another hoop to jump through and how
>> difficult it has been in the past to get things done, however if done
>> properly it's an achievement that you'll be recognised for, rather than
>> resented.
>>
>> If you just want to code though, perhaps you can create a subproject, making
>> River easier to use and deploy for first time developers, this might also
>> encourage projects with competing functionality to become subproject's of
>> River to get more of the limelight.
>>
>> Cheers,
>>
>> Peter.
>>
>> Tom Hobbs wrote:
>>     
>>> Hi Gregg,
>>>
>>> Is any of this stuff in a public repo?  You might have noticed that
>>> I've put a "River Success Stories" page on the site and it'd be great
>>> to be able to link to these projects - even the
>>> experimental/incomplete ones.
>>>
>>> With regards to startnow, particularly ConfigurableJiniApplication and
>>> PersistentJiniService, would you be willing to donate these to the
>>> River code base?  This kind of thing is exactly what I wanted to put
>>> in the "extras" drirectory of River that was discussed a while back.
>>>
>>> Let me just say that I am more than very happy to direct people onto
>>> your implementations and towards your projects, as I hope the above
>>> request for the links to public repos and permission to link to them
>>> above shows.  However I still think that it's easier and more
>>> intuitive to new users if they get more stuff like this along with
>>> their original River download.  I hope that you don't think I'm trying
>>> to absorb all of your projects into River or divert any credit away
>>> from you onto this project, but just those two quick-start classes
>>> would be really useful for new developers using River - and a donation
>>> of existing code saves me the effort of re-implementing them myself!
>>>
>>> Cheers,
>>>
>>> Tom
>>>
>>>
>>> On Fri, Dec 3, 2010 at 10:04 PM, Gregg Wonderly <gr...@wonderly.org>
>>> wrote:
>>>
>>>       
>>>> Sam, there is not a comprehensive list anywhere, but I'll post one here
>>>> just
>>>> FYI and anyone else who might be interested.  What I want to stress is
>>>> that
>>>> most of this stuff is hovering closer to "investigation" than
>>>> "production"
>>>> quality code.  I'm willing to answer questions as best I can.  Some of it
>>>> is
>>>> early versions of stuff which I later put into production with
>>>> changes/enhancements.
>>>>
>>>> gosie           A Jini Based Desktop System
>>>>               This is my serviceUI based desktop environment.
>>>>               This application lets you use a list of hosts and URL
>>>>               suffixes, and then does unicast to those hosts, and
>>>>               creates a dynamic policy for all host and URL suffix
>>>>               combinations.  In my use, I rely the reef project work
>>>>               on reggie for delayed unmarshalling as well as on the
>>>>               fact that the hosts have services returning vhttp URLs
>>>>               in the annotations which will download and locally cache
>>>>               all service jars.  In the deployments I use this, there
>>>>               are 5-10 services per machine with 2-4 jars per service.
>>>>               There are 2 or more serviceUIs per service registration.
>>>>               This results in hundreds of UIs to select from and thus
>>>>               I need very quick display of icons and choices.
>>>>
>>>> griddle         Jini Grid tuple space
>>>>               This is something that I put together while the
>>>>               JavaSpaces05 discussion was happening.  It has in-space
>>>>               executor and programmble query control because the space
>>>>               objects are separated from the keys so that the data
>>>>               can stay marshalled and the keys can be unmarshalled
>>>>               and compared with the "entry" matching implementation.
>>>>
>>>> jetset          A Jetty service for launching servlets
>>>>               This is a service that launches the Jetty web server
>>>> logman          Remote logging management using a Jini enabled LogManager
>>>>               This service is launched from the LogManager SPI in
>>>>               the JVM.  It provides remote monitoring by letting you
>>>>               change logger settings as well as remote streaming of
>>>>               the log output.
>>>>
>>>> reef            A service lookup to reduce client memory use.
>>>>               This is the work that I did to make Reggie return
>>>>               marshalled match data so that you can decide when
>>>>               to unmarshall the service and the Entry objects
>>>>               yourself.  You can thus get Name objects and other
>>>>               data without unmarshalling the service.  I also did
>>>>               work to Jini to provide the ability to configure the
>>>>               net.jini.loader.pref.ClassLoading class to "never prefer"
>>>>               some classes so that things such as Name would never
>>>>               cause the initial download that the preferred list
>>>>               discovery causes.
>>>>
>>>> startnow        A collection of Jini tools for new Users
>>>>               This includes a ConfigurableJiniApplication and a
>>>>               PersistentJiniService class that I use all the time
>>>>               as foundations for all services I write.  But there
>>>>               are also all kinds of things that I dumped into
>>>>               this project as I was experimenting with different
>>>>               concepts about abstracting parts of Jini prior to the
>>>>               2.0 release with Configuration and other good things.
>>>>               Included in this project is stuff like a configuration
>>>>               provider/manager that I was working on.  There is also
>>>>               a DynamicPolicyProxyPreparer class that was intended
>>>>               to allow proxyPreparation to look at the codesource
>>>>               and assert policy around the prepared proxy.  This was
>>>>               intended to allow "users" or "deployers" to give users
>>>>               appropropriate local policy to use for services they
>>>>               might encounter on the network.
>>>>
>>>> whatsitdo       A Jini Container system for Jini Examples
>>>>               This project was about giving people instance access
>>>>               to Jini as well as to example services which used Jini.
>>>>               It provides a container GUI that you can drag "jars" into
>>>>               and the contained services will be shown and you can then
>>>>               launch them and use the associated serviceUIs.  What is
>>>>               interesting, to me, in this, was that I put together some
>>>>               "hacks" on the JarFile/ZipFile mechanisms and jar: URL
>>>>               handling in the JVM to allow recursive jar URLs to work.
>>>>               This meant that you could put the jini jars into your
>>>>               services jar as the complete classpath for it, and include
>>>>               codebase jars as well, and through the magic I created,
>>>>               everything just worked.  It still works last I tried it.
>>>>
>>>>               The build scripts do all the work to package thinsg,
>>>>               and there are control points that are created in that
>>>>               process to allow the right thing to happen.  I used
>>>>               the com.sun.jini.start stuff as the "service launching"
>>>>               control code.
>>>>
>>>> Gregg Wonderly
>>>>
>>>> On 12/1/2010 9:25 AM, Sam Chance wrote:
>>>>
>>>>         
>>>>> Greg,
>>>>>
>>>>> Are your various Jini/River related projects listed on-line somewhere?
>>>>>
>>>>> Thank you!
>>>>> Sam
>>>>>
>>>>> On Wed, Dec 1, 2010 at 10:13 AM, Gregg Wonderly<gr...@wonderly.org>
>>>>>  wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> I have requested that jini.dev.java.net be moved and I've requested
>>>>>> that
>>>>>> my individual projects be moved.  Any other projects own by others need
>>>>>> to
>>>>>> be dealt with pronto.  All users should have received emails about
>>>>>> needed
>>>>>> action.
>>>>>>
>>>>>> Gregg Wonderly
>>>>>>
>>>>>> On 11/24/2010 5:19 AM, Peter Firmstone wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> There are a lot of Jini Community projects on Java.net which are
>>>>>>> probably
>>>>>>> stagnant.
>>>>>>>
>>>>>>> Do we know if any of these projects will be moved?
>>>>>>>
>>>>>>> It looks like they're all going to go the way of the dinosaur unless
>>>>>>> we
>>>>>>> preserve
>>>>>>> their source.
>>>>>>>
>>>>>>> Looks like we've got 6 days left to copy these projects. It will be a
>>>>>>> significant loss if we don't.
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>> Niclas Hedhman wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> Has this been discussed??
>>>>>>>>
>>>>>>>> <quote>
>>>>>>>> ACTION REQUIRED: Java.net is migrating to a new infrastructure and
>>>>>>>> project owners must request that projects be moved by November 30,
>>>>>>>> 2010. A list of projects that will be moved is here:
>>>>>>>> http://java.net/projects/help/pages/RequestedProjects For more
>>>>>>>> details
>>>>>>>> please see the Community Manager's blog -
>>>>>>>> http://www.java.net/blog/30701
>>>>>>>> </quote>
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>               
>>>>         
>>>       
>>     
>
>