james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: [jira] Commented: (JAMES-495) Decide how to replace Avalon Configuration
Date Tue, 23 May 2006 20:09:35 GMT
Stefano Bagnara wrote:

> Steve Brewin wrote:
> > Stefano Bagnara wrote:
> >>
> >> Noel J. Bergman wrote:
> >>> Steve,
> >>>
> >>> I suspect that we agree, but I want to confirm.  
> >> Configuration should, essentially, be JMX native, and the 
> >> configuration scheme should be bridging between the 
> >> configuration store and the internal calls.
> >>> 	--- Noel
> >> Is there any project (better if it's an Apache project) using 
> >> this approach?
> >> I would like to put my hands in similar code using this approach...
> > 
> > I'm sure I could trawl up a set of OSS examples that use 
> each aspect of this approach. I'm not sure I could find one 
> which is an exemplar of all aspects acting in unison.
> > 
> > I think the only vaguely original things here are that we 
> are delegating to each component the responsibility for how 
> and if it responds to a configuration change and making the 
> original static configuration just the first of many possible 
> dynamic change events.
> > 
> > I guess you are asking because there is something you feel 
> unclear or uncomfortable about? If the former I can knock up 
> a UML diagram or two if it would help. If the latter, shout!
> > 
> > Cheers
> > 
> > -- Steve
> Yes, I feel unclear.
> I'm currenlty following the directory@apache dev mailing list about 
> their configuration issues and refactoring.
> I think that James has not enough community power, now and reusing 
> components/patterns from the directory project is currently an 
> interesting option.
> They are moving to felix (OSGi) and they extensively use 
> JNDI. They also 
> provide a good network abstraction (based on MINA or different 
> subprojects).
> If I understood it correctly in their plan the directory/felix 
> integration will also bring a GUI to manage component wiring / 
> configuration. Felix is coming out from the incubation and 
> maybe in few 
> months we'll have an official felix release and a directory release 
> based on felix.

As I believe I said a while back, like you and others I am looking at OSGi and have been quite
positive about it. But this is just one option. We should explore others before making our
> That said, even if I don't think it's the best idea to start from 
> something that needs an UML diagram and that does not have 
> people time 
> to be supported, I'm always happy to look at UML diagrams and discuss 
> this topics.

I find UML diagrams an excellent way to communicate architectural design, be it for new or
existing ideas. Its also a good way of presenting a strawman design for focussing discussion,
tearing down and starting over, recursively arriving at a solution.

If we can find a pre-existing solution that meets our needs, that's great. But we shouldn't
be afraid of stitching together pre-existing solutions to meet our needs either, which is
what I am proposing in this one of many possible solutions.

-- Steve 


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message