Niclas Hedhman wrote:
On Fri, Dec 12, 2008 at 12:30 AM, Gregg Wonderly <[email protected]> wrote:
Perhaps Niclas you can enumerate all the reasons why JavaSpace shouldn't
have transactions or leases?
I'm dead serious about trying to understand what you are saying.
Ok, let's try this again;
Perfect! Easy to have discussion about these items as stated!
I want the 'package' that is offered to "me" to have local-JVM
implementations that are plug-replaceable with distributed ones. I
don't want to "yank" out Transactions and Leases, I want to be able to
use them easily locally without network traffic.
Is the network use the problem or is there something else about the use of the
current mechanisms? Leases don't require any other service to be running, only
a Landlord impl to use the current mechanisms. Transactions use mahalo.
Do you know about constructing an com.sun.jini.start.ServiceDescriptor and using
that in your application to start a network based service in the same process?
com.sun.jini.start.ServiceStarter does this for sets of services provided to it
in its configuration file, so we could abstract it's behaviors into something
usable as a library.
I want an introduction path into this world going through that
'local-JVM' variant first, and slowly introducing the more complex
aspects of Jini to me. I don't want to know that I have 3-4 transport
protocols, some with endless options, and I don't want to know the
details of setting up security (just assume I am the ignorant b'stard
that I am and give me AllPermissions until I sober up). I don't want
to see configuration files in a "Java-like" language, either give me a
straight shooting API, properties files or worst-case a Spring app
context...
Do you think that making it possible to get references to a JavaSpace,
TransactionManager and Landlord instance in a "trivial" way would be a solution,
or are there other things that would make you really want a "no network" solution?
I want to deploy my first Jini services and clients in a WAR on
Tomcat, without having to ask my NetAdmin to alter any setup and know
that it works out of the box everywhere.
Okay, so we might want to really look at what is going on in Bantam and take
that community's thoughts and ideas and see if we need to have that in River or
if it can be a solution external to River?
I want services to be under the control of Java code that I write. I
don't want to ever hear about RMID and Activation ever again. I don't
want to encounter classloading problems when services are in the same
JVM, even if they depend on different versions of Jini "Core".
com.sun.jini.start provides this capability. A PreferredClassLoader is
seamlessly injected and makes sure that separate services can have completely
separate codebases, including the platform for anything that is marked as
preferred in the PREFERRED.LIST.
I want every bit of the system to be Maven adapted, so that my Maven
project can consume the meta-data easily. Jini is a toolkit, and not a
installable application for JC's sake.
I'm neutral on the Maven issue because I don't have any Maven experience. I
know I can build the jars with Ant. Do we just need a Maven thing on the back
side that provide the dependency solution for other apps as a starting point, or
must we really rewire the build to make it work?
I want to be able to use Jeri without any Jini at all.
There could be a separate jar with just JERI stuff in it. But I'd still prefer
there to also be a jsk-platform.jar that is for Jini users.
I want to be able to easily(!) test my Jini clients and services
within a single JVM (otherwise too hard to automate), preferably via a
single AbstractJiniServiceTestcase and AbstractJiniClientTestcase
doing all the bits for me. And of course, those take care of whether I
am testing against InMemory or OverNetwork versions of the services.
I guess you can provide some requirements or concepts about what issues these
classes might deal with. If you look at http://startnow.dev.java.net and look
at the class org.wonderly.jini2.PersistentJiniService, you'll see what I use (I
have not sync'd that site with what I have today, so some bugs etc may still be
in that code).
public class MyService extends PersistentJiniService {
public static void main( String args[] ) {
new MyService( args, null );
}
public MyService( String args[], LifeCycle cycle ) {
super( args );
... any setup work...
startService();
}
}
With this style of framework, you can make PersistentJiniService do all kinds of
stuff based on parameterization from the command line, Configuration entries etc.
With the constructor signature there, it's compatible with com.sun.jini.start.
I want River to 'feel' like an open source and accessible project.
Simple things should be dirt easy and complex things should be
possible.
I think that saying Open Source means simple is Dirt Easy is problematic. An
opensource community will refine things that are hard over time, and somethings
can be simplified.
I _might_ want to chuck the Configuration system, or at least create
more familiar alternate implementations.
The Configuration interface is pretty agnostic to underlying expression and
storage I think. Having something external create a Map of Maps should make it
possible to create a ConfigurationMap class that would take
Map<String,Map<String,Object>> in the constructor and then be able to make the
appropriate accesses. And certainly this also provides for external dynamic
updates to configuration which ConfigurationFile requires a new instance to
allow for.
Well, that is what I can recall after midnight (now)... Maybe more later...
Does that help, or am I still confusing?
Makes a world of difference, thanks!
Gregg Wonderly
