----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
>
> the security initialization from jboss.properties, we need to move that to a
> proper JMX initialization. Move the thread local security stuff, is it
> there because there is no other way? is there a reason, or can we safely
> work towards putting that in jboss.xml, jboss.jcml
>
The setting of the security manager and server.policy file are better done from
the command line as many security related events and debugging hooks are
done on startup of the vm. I don't think these should be set at all from
within the server. Setting the thread-local mode of the SecurityAssociation
could be moved to an mbean.
> we should really only have the loading of the MLets. THEN THE LOADING IS
> FILE BASED and that is kinda fucked up, we would really need to parse the
> arguments for a URL that points to the base directory to load from. We
> needed to do that when we were asked to demonstrate on the spot that we
> could load the server from http and when we looked at the code it would all
> work from the file system and be very local.
>
> Final question... why is the "DocumentBuilderFactory" stuff in the Main
> class can't we have the actual loading mechanism make that call? It is more
> than repackaging (since you guys know I hate repackaging) it would enable us
> to put the xml classes in something else than the base spine but have the
> stuff loaded as an MLet from the conf in the beginning.
>
If I comment out the call to DocumentBuilderFactory.newInstance() I am
still able to switch the xml parsers using the JAXP properties so I don't see
that this call has any effect other than preloading the parser classes. The
xml parser settings could be moved to an MLet.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
