ouch.
--jason
On Thu, 20 Sep 2001, marc fleury wrote:
> | <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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
