My org.wonderly.jini2.PersistentJiniService class at
http://startnow.dev.java.net, was my attempt to create this "traceable" layer of
"Java" using "Configuration" so that people could start with something that was
100% java, and then see the basics of how "Configuration" could be used to
provide "values". At the time, I wasn't really wanting to say "don't use
configuration, just use Java", because I wanted to see how Configuration would
work out, with various implementations. The ConfigurationFile syntax is fairly
close to Java, but the "subtle" differences can be a little confusing,
especially if documentation doesn't lead you, easily, to a discovery/learning
experience.
A lot of Java developers, seem to be more than willing to click through Javadoc,
because that's easy to navigate in web form. The Javadoc for Configuration,
leads to ConfigurationFile, so I think its practical to believe that it would be
possible for people to find "documentation" for that.
But, Dennis' work on Groovy configuration, makes some things a lot easier, if
you grok Groovy. I think that annotations, could have some traction for people
who have used them. Otherwise, in the end, if you just want Java, then creating
a factory class, or some sort of "ServiceContainer" class, which has "Java/PoJo"
interfaces to the values you need, might be the right path.
The deal with ConfigurationFile, of course, is to be able to do configuration at
deployment time, instead of at development time, and thus, even your development
environment is a "deployment" that might be different from production. For
example, in development, you might just use TCP endpoints, no policy, and a LUS
group that is different from the production environment, so that there is no
chance to interfere with production, which might be on the same
routable/multicast-accessible network.
Gregg Wonderly
On 1/11/2012 3:17 AM, Tom Hobbs wrote:
Don't know about the Groovy stuff, because I want configuration to be easy
and non-scary to newbies, I have looked at it at all. Learning Jini/River
is enough without expecting people to learn Groovy as well (assuming they
don't already).
Injecting values based on annotations is an idea, but again I want to keep
the configuration side of things as plain and simple as possible. What you
suggest might be a good idea as an additional option for configuration
though.
Sent via mobile device, please forgive typos and spacing errors.
On 11 Jan 2012 09:12, "Greg Trasuk"<tras...@stratuscom.com> wrote:
On Wed, 2012-01-11 at 01:01, Peter Firmstone wrote:
You could try Dennis Reedy's Groovy Configuration Provider, that'll give
you Pojo's with Java like syntax. We still need to add an ant task to
generate the groovy javadoc too.
It would be nice to see that system used by default.
Just curious...What is the advantage of Groovy's syntax over
ConfigurationFile?
Also, I just had an interesting thought: What if a service deployer (as
in "ServiceStarter is a service deployer") were to scan the service
class for JSR330 @Inject annotations and plug in values taken from the
config file?
Cheers,
Greg.
Cheers,
Peter.
Greg Trasuk wrote:
On Tue, 2012-01-10 at 17:04, Tom Hobbs wrote:
Hey dudes,
I'm currently working (read: hacking) my way through the code trying
to work out how to make it possible to remove the need for starting
services with config files. I remember a user asking about this a
while back, but their problem isn't the problem I'm trying to solve
right now.
I've quite easily gotten rid of the "start-xyz" config files, but I've
not worked out a way of getting rid of the last piece of the puzzle.
Consider the code;
return new ServiceDescriptor[] {
new NonActivatableServiceDescriptor(
codebase,
policy,
classpath,
"com.sun.jini.reggie.TransientRegistrarImpl",
new String[] { config }) };
Here, "config" wants to be the name of a config file such as can be
found in $RIVER_HOME/examples/hello/config/jrmp-reggie.config. What
I'd much rather do is remove the need for that and instead replace it
with some pojo or similar that could be the actual configuration (or
pretend to be a config file...)
Substituting null for config and running through a debugger blows up
in a useful fashion, which shows me that the problem is (I think) in
ConfigurationProvider:192 where it tries to assign a value to "cname".
It fails to do this and so later on in line is assumes that it must
be looking for a ConfigurationFile. Beyond looking for a resource
called "META-INF/services/net.jini.config.Configuration" on the
classpath, I admit to not being entirely sure what else
ConfigurationProvider:192 is trying to do or how it helps. Maybe I'm
going about this the wrong way. Any suggests?
ConfigurationProvider is checking for the resource to see if you want a
particular implementation of the Configuration interface. It defaults
to ConfigurationFile, which uses the argument as a file name from which
to read configuration entries (in the ConfigurationFile format). If
you'd prefer a different implementation for the Configuration
interface,
you put the class name in the
'META-INF/services/net.jini.config.Configuration' resource. This way,
we're not locked into the oft-maligned ConfigurationFile format.
So, if you really wanted to replace the configuration file with a POJO,
you could just write a POJO that implements Configuration (of course I
guess that would't really be a POJO, but you get the idea) and place
the
name of that class in the aforesaid resource.
If you're OK with the idea of a config file, but just don't like having
to have it in the file system, I did some work last year in the 'extra'
branch that might be of interest. Have a look at
http://svn.apache.org/viewvc/river/extra/RiverConfigurationResources/trunk/
.
The project builds to 'RiverConfigurationResources.jar'. When you
include that jar file in your classpath, you can include configuration
files as resources on the classpath. Also, there are two very plain
configuration files 'nonSecureClient.config' and
'nonSecureService.config' that can be used for beginner-type services
and clients.
You might also want to have a look at
http://svn.apache.org/viewvc/river/extra/JiniInfrastructure/, which
uses
the resource configuration to startup all the infrastructure services
(reggie, norm, outrigger, etc) from one command line. It can also
start
the service browser (have a look in
http://svn.apache.org/viewvc/river/extra/JiniInfrastructure/trunk/src/org/apache/river/extra/start/infrastructure/Main.java?view=markupfor
info).
I envisioned these projects as 'extra' distrubutables apart from the
core distributable, hence the 'extra' branch. If people think they are
useful, we can talk about adding some documentation and a link from
'river.apache.org'.
Cheers,
Greg.
My reason for this work is that I still maintain that starting with
Jini/River, making services work and doing stuff is still to hard for
new comers.
Cheers,
Tom
