Hi Tom, I don't have developers :) There are people/organizations that use the framework I've lead and developed (with great input from so many), and people/organizations that I've worked with that want to understand how to deal with dynamic distributed systems. I've been fortunate enough to advise and apply much of the architectural principles that River brings to these engagements. My assertions are based on my experience.
As for people who are new to any technology, I think the most important thing is to communicate concepts and knock down barriers for entry, Additionally, the project needs to show how easy it is to get something running. Perhaps not just get it running, but how to develop and test your service. Right now the bar is way too high for anybody to create a project using River that has full lifecycle support for: 1. Dependency management 2. Testing framework (not for River but for your services) 3. Packaging and deployment Once River can provide an approach for developers to easily develop, start, test and deploy their code, how can anyone really expect an uptick in use? Once the project accomplishes that, then lead the trail into how to customize and configure your services, smart proxies, dynamic systems. If I'm new to something, and it's a burden, I quickly turn the page and look elsewhere. Thats just me, but I'm not sure if it's not common with others as well. IMHO, the challenge for River is not configuration (sure it's a burden, but that can be dealt with the convention over configuration), it is grasping why River, and distributed services are different. Things (clients and service) come and go, this is the big difference. I mentioned these semantics before: - When has my service joined? - When is my service ready? - When should my service clean up resources? - Are all the things my service needs (think other services) found? With Rio, I've provided the following annotations that assist service developers with lifecycle transitions that we have seen to be important (there are other annotations, but I these are germane to the discussion): @Started: The Started annotation is used on a method in a service to allow the service to be notified that it has been started, that all infrastructure and property settings have been accomplished. @PreAdvertise: The PreAdvertise annotation is used on a method in a service to allow the bean to be notified before the service has been advertised. Note that this is important if you use Rio Associations (http://www.rio-project.org/associations.html). If your service strongly depends on (requires) other services, it will be advertised/unadvertised based on the availability of the services you require. Even if you are not using Rio associations, knowing that you have joined the network allows a service developer to start logic based on knowing you are discoverable. @PostUnAdvertise: The PostUnAdvertise annotation is used on a method in a service to allow the service to be notified after the service has been unadvertised. So basically, you were part of the djinn, now you're not. This is also important is using Rio associations, and one of your associated services is a requires association. Even if not using associations, being notified that you are no longer 'joined' is an important semantic. Need to checkpoint something? Clean up resources? I hope this addresses your question(s), if not let me know where I can elaborate/expand. Regards Dennis On Sep 25, 2012, at 742PM, Tom Hobbs wrote: > Just to prove I'm still here; > > If it's spitting out of config files you're interested in, a little while > ago I put some code in that allowed programmatic config generation. I > forget the exact syntax, but something like; > > myconfig.setLookupGroups(grps).setName("My > Service").setEndpoint(EnpointType.class); > SeriviceStarter.start(myconfig) > > ...and so on. > > This used (from memory) Velocity (?) to create an in-memory file which the > existing ConfigurationFile bits could be fooled into thinking was a real > file and allow configuration off the back of that. > > Using the above, with Velocity (or whatever it was) to then write that file > to disk for tweaking, would be a reasonably trivial task. > > I'm interested in Dennis' assertion that developers are more interested in > lifecycle than config. I think that's probably true of developers, but > probably not true of people new to River and who just want to write Hello > World services. That's just my gut feel. But I'm still interested in his > point. So if we were to give Dennis' developers a magic annotation wand, > what kind of annotations would they like to see? What would they look > like? Or is it some other lifecycle mechanism handling thing they're > interested in? > > > On Tue, Sep 25, 2012 at 9:34 PM, Gregg Wonderly <[email protected]> wrote: > >> >> On Sep 25, 2012, at 3:10 PM, Dennis Reedy <[email protected]> wrote: >> >>> >>> On Sep 25, 2012, at 405PM, Gregg Wonderly wrote: >>> >>>> >>>> On Sep 25, 2012, at 2:52 PM, Simon IJskes - QCG <[email protected]> wrote: >>>> >>>>> On 25-09-12 21:37, Gregg Wonderly wrote: >>>>> >>>>>> From my perspective, it seems that the most predominate step forward >>>>>> that we might take, would be to make all configuration used in >>>>>> services be visible to tooling on the outside which could then guide >>>>>> the deployment much more dependably and accelerate this small but >>>>>> currently oh so fragile set of steps toward getting River up and >>>>>> running in your environment. >>>>> >>>>> To me this reads like a mode where the 'easy' environment spits out a >> configuration file, which if presented to the easy environment produces the >> exact same result, and allows for editting to tweak things. Does it? >>>> >>>> >>>> That might be one of the things which happens. But, the annotations, >> ultimately, provide the metadata which defines the "parameters" of >> configuration which are valid. So, tooling of all different nature can use >> that meta-data. >>>> >>> >>> Interesting idea! You also could create a ConfigurationProvider that >> writes out component, name, type, defaultValue (if any) and optional data. >> Might be a start for services that already exist and may not have >> annotations applied. >> >> One of the scenarios that I think about here, is that >> ConfigurationProvider then remains as the "interface" to configuration >> data. An implementation which is constructed with a service that has >> annotations as being discussed here, could then read the annotations and >> know what should be available. A subclass of that might be provided for a >> particular deployment environment to bridge from the annotated application >> to the runtime deployment needs as administered by the particular >> environments tooling. >> >> public class AnnotationNotProvidedException extends ConfigurationException >> { } >> >> public AnnotationBasedConfigurationProvider implements >> ConfigurationProvider { >> private final Map<String,Object> configValues; >> public AnnotationBasedConfigurationProvider( Remote svc ) throws >> AnnotationNotProvidedException { >> …look for annotations and create a map for Configuration >> Provider containing defaults from annotations… >> localConfigurationChanges(); >> } >> protected abstract void localConfigurationChanges() throws >> ConfigurationException; >> } >> >> public RioAnnotationConfigurationProvider extends >> AnnotationBasedConfigurationProvider { >> protected void localConfigurationChanges() throws >> ConfigurationException { >> } >> } >> >> Gregg
