RE: Configuration file format

Hi all

I did a similar work a while a go for our internal loader and one of the things
I was wondering then was how to specify the order of creating, loading,
unloading and invoking operations

Will the order be set by the positions of the create/register/unregister nodes
in the file? Isn't that a bit risky since the parser may change the order?

What if you have an explicity "order" or "index" attribute that guides how to go?

Regards

Quoting "Bordet, Simone" <[email protected]>:

> Hi,
> 
> > > Comments are very welcome.
> >   Well...
> >   How about securing this shutdown socket?
> >   I wouldn't want anyone else to be able to shutdown my server. Right?
> >   Something like:
> > 
> > <configuration port="xyz" command="24rgfisg7346">
> 
> Well, the server socket listens on the loopback interface, so noone from
> outside can connect: you must have access to the host. Once you have that,
> you can read the config file for the command so it's not really a secure
> thing...
> I hesitate on adding a 'command' attribute because I want to keep it simple.
> One can always subclass (or rewrite) and make it more secure.
> And we would need:
> 
> <configuration port="xyz" shutdownCommand="24rgfisg7346"
> restartCommand="blah">
> 
> I would keep it simple for this first iteration, so no command for now.
> 
> >   Then... What do you think of having the ability to not only stop the
> > loader, but to also restart it? Hm?
> 
> Right.
> I'll add this.
> 
> >   Ahmmm... How about this:
> >   <configuration>
> >     <classpath>
> >       <url  ref="http://my.server.com/classes/"/>
> > 
> >       <!-- RELATIVE TO SCRIPT FILE -->
> >       <file ref="libs/jarfile.jar"/>
> > 
> >       <!-- RELATIVE TO SCRIPT FILE -->
> >       <file ref="classes"/>
> > 
> >       <!-- RELATIVE TO SCRIPT FILE -->
> >       <dir  ref="libs/plugins/" match="*.plugin.jar"/>
> >     </classpath>
> >     <startup>
> >     ....
> >   </configuration>
> > 
> > Then the loader can have an MLet classloader instantiated 
> > and use it to
> > instantiate beans that do not have the loader specified i.e.:
> >        <create
> >           classname="com.mycomp.MyWorker
> >           objectname="JOB:type=worker" />
> 
> I thought about this, and frankly I'd prefer to do it explicitely.
> With the current configuration file format you can create MLets, add URLs to
> it, register them and use them as loaders for other MBeans.
> 
> I am again in defensive mode: your <classpath /> extension is "syntactic
> sugar": you can achieve it already with a more verbose syntax; so I'd keep
> the current as is, and eventually add it later on user's demand.
> You know, while writing it, a *lot* of such things came to my mind and I
> explicitely decided to keep it at low level.
> 
> The stuff is quite extensible, you can customize it as you want.
> 
> > In any case I would love to see this. Is it in the CVS?
> 
> Not yet. It seems we agree on most stuff, I'll commit today.
> 
> I'd love to hear comments from you on the real code, and on its
> extensibility.
> 
> Thanks
> 
> Simon
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Mx4j-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mx4j-devel
> 




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/