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 [EMAIL PROTECTED] 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 decision. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
