avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <atagu...@mail.cnt.ru>
Subject [Fortress] MetaInfoManager/RoleManager interplay
Date Sun, 18 May 2003 06:47:57 GMT
Hello, Developers!

Let me volunteer to help polishing
the MetaInfoManager/RoleManager interplay :-)

1. Introduction

    AbstractContainer

        if     ( userServiceMetaManager provided )
        {
            use it in cooperation with a new ServiceMetaManager
        }
        elseif ( userRoleManager        provided )
        {
            use it in cooperation with a new ServiceMetaManager
        }
        else
        {
            use a new FortressRoleManager with a new ServiceMetaManager
        }

    ContextManager
    
        another contract, probably a bit messy at the moment :-)

2. Proposition A

   Let us make sure Fortress-style meta-tags are present in
   (and compiled in as .meta and .dep into the corresponding jars)
       * JdbcDataSource
       * J2eeDataSource,
       * InformixDataSource
       * ActiveMonitor
       * PassiveMonitor
       * XPathProcessorImpl
       * JaxenProcessorImpl
       * SourceResolverImpl
       * JaxpParser
       * XercesParser
   and decommission FortressRoleManager?

   Among other benefits this will eliminate messages
   about f.e. *DataSource components not being available
   we get when we run a Fortress application without
   all of these libraries on the classpath.

3. Proposition B

   I also propose two alternative contracts for the overall
   RoleManager + MetaInfoManager interplay: B1 and B2
   
3.1 Notation
   
       ( m, r ) = ( userMetaInfoManager, userRoleManager )

3.2 Proposed overall contract B1

       ( 1, 0 ) -->       userMetaInfoManager      + new ServiceMetaManager
       ( 0, 1 ) -->       userRoleManager          + new ServiceMetaManager
       ( 1, 1 ) --> WARN, userMetaInfoManager      + new ServiceMetaManager
       ( 0, 0 ) -->       new ServiceMetaManager

3.3 Proposed overall contract B2

       ( 1, 0 ) -->       userMetaInfoManager
       ( 0, 1 ) -->       userRoleManager           + new ServiceMetaManager
       ( 1, 1 ) --> WARN, userMetaInfoManager
       ( 0, 0 ) -->       new ServiceMetaManager

3.4 Analysis

Both B1 and B2 put the job of making the descision and issuing a
warning onto AbstractContainer removing it from ContextManager.
All ContextManager does is creating a RoleManager from a RoleConfig
if necessary.

The diffrence between B1 and B2 is the following:
B1 says: if the user has supplied a MetaInfoManger wrap it into a
ServiceMetaManager and go.
B2 says: if the user has supplied a MetaInfoManager he knows better
what he is doing, so do not wrap it into anything and use it right
away. Not sure which is better.

4.  getChildLogger or getLoggerForCategory?

Currently when creating a new MetaInfoManager ContextManager does
approximately

    loggerManager.getLoggerForCategory( "system.roles" );
    loggerManager.getLoggerForCategory( "system.meta"  );

while AbstractContainer does approximately

    new_metaManager.enableLogging( logger.getChildLogger( "roles" ) );

4.1 So, what should it be?

    * getLoggerForCategory
    * getLoggerForCategory, if that fails getChildLogger
    * getChildLogger

4.2 What name should we use for our new_RoleManager if we create it
    (in case user has supplied a RoleConfig) ?
    
    * roles
    * system.roles

4.3 What name should we use for our new_ServiceMetaManager if we
    create it ?

    * roles
    * system.roles
    * meta
    * system.meta

5 Implementation.

Will gladly supply the patches as soon as I know what to do! :-)

With best regards,

- Anton Tagunov


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message