| <mbean name="MBeanLoader" class="org.jboss.system.MBeanLoader">
| <set name="classpath">
| ${jboss.lib}/jboss-spine.jar,
| ${jboss.lib}/log4j.jar
| </set>
| </mbean>
no, it is more obscure than the classpath tags that are there...
It achieves the same.
Don't fix this.
| <!-- Use this MBean loader for botting -->
| <mbeanloader name="MBeanLoader">
|
| <!-- get logging up and running -->
| <mbean name="Logging" class="org.jboss.system.Logging">
| <!-- override the default logger type for log4j -->
| <set name="LoggerFactoryType">
| <new class="org.jboss.log.log4j.CategoryLoggerFactory">
|
| <!-- override the default configuration file -->
| <set name="ConfigURL">${jboss.conf}/log4j.xml</set>
|
| <!-- override the default refresh interval -->
| <set name="RefreshInterval">600</set>
| </new>
| </set>
| </mbean>
|
| <!-- Logging is now functional -->
|
| <!--
| | next startup the library manager, with handle getting classes
| |
| | provides a robust mechanism for getting class
|libraries, may boot
| | strap higher functionality after establishing link to BaseURL.
| -->
| <mbean name="LibraryManager"
| class="org.jboss.system.LibraryManager">
| <set name="BaseURL">${jboss.lib}</set>
| <set name="StateDir">${jboss.var}/libcache</set>
| </mbean>
We never use these variables. NEVER. Why expose them... keep it simple...
there was NOTHING added in the previous stuff... so why do it?
Remove all of this.
| <!--
| | Manage security.
| -->
| <mbean name="SecurityManager"
|class="org.jboss.system.SecurityManager">
| <!-- who knows -->
| <set name="Password">hi</set>
| </mbean>
Yes that might be relevant but I suspect it might be naive in Scott eyes,
let Scott move the security. It needs to be moved to a read jsr
configuration with jmx.
| <!--
| | setup the service controller and deployer
| |
| | this will take over with all other loading and provide a richer
| | language interface.
| -->
| <mbean name="ServiceController"
| class="org.jboss.system.ServiceController"/>
| <mbean name="ServiceDeployer"
| class="org.jboss.system.ServiceDeployer"/>
|
| </mbeanloader>
NO! NO! NO! NO!
Why is this exposed AT ALL? if you don't put this JBoss doesn't work and
there is just no way you are going to change this.
Jason if it is not used REMOVE IT.
Remove the above,
|Now, on to the Jetty-like config stuff. I think this is really, really
|cool. It basically gives us super flexiblity for adapting to different
|mbeans and the different was that beans get configured.
you don't use the semantic since you show only get on the properties then...
why change the current "property" stuff...
|The service(s).xml stuff would probably just be the bits inside of
|<services> (perhaps properties too).
|
|The <set> stuff is basically <attribute>, but more terse (and fiting with
|the other names).
Exactly what I am saying above... you don't add anything and change the
semantic for no gain.
mucho pain and no gain...
you got it?
|<call> & <new> are nested scope elements, which operate on the returned
|object. This would really make configuration of complex components much,
|much easier, but allowing a configuration helper object be used or rather
|plugged in. I am not sure that we need a fullblown MBean for many trivial
|uses, perhaps we do...
That is the part that is pretty cool but we don't make use it, I still have
to see a clear example of JBoss needing this.
|<mbeanloader> probably needs some more work, but is essential a scoped
yes remove it... it is already done with a clearer semantic in the
"classpath" element in a clearer way. Worse semantic for same result is
really not going to cut it Jason...
|This could be a simple nested <classpath> too, but this will simply hookup
|the mbean creation stuff via JMX instead of hardcoding the class.
The problem with the "nested" stuff is that I want to be able to declare
just one per file, it is very redundant information. Read the current code
in CVS.
|I also added a hint of support calling alternative methods for service
|lifecycle stuff (so you don't have to write an adapter for this), and the
|idea to expose our System.exit() usage to make it easier to embed.
That might be relevant.
|So that's it (for the moment), more power, slightly more complex boot
|sequence, more complex configuration where needed with out any loss of the
|simplicity of the current configuration dialect.
Forget it it sucks imho
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
