avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <atagu...@mail.cnt.ru>
Subject Patch queue contents
Date Mon, 26 May 2003 10:46:48 GMT
Hello Berin!

BL> In the mean time, Anton, don't stop with bug fixes.  What else
BL> are you seeing?

Well, now except for the patches I have submitted, only two
things still continue to worry me:

1  LifecycleExtensions

1.1

   Tough issue:

   I'm a little bit uncomfortable with how the standard
   LifecycleExtensions are handled by the AbstractContainer.

   Currently there is only one such extension: InstrumentableCreator.

   Look into the code: the LifecycleExtensionManager if passed-in
   to the container is the only thing that is not read-only.

   Instead, we browse through it and if we do not find an
   InstrumentableCreator we add it there.

   We're modifying something that does not belong to us!

   What should we do?
   Maybe create a copy of the LifecycleExtensions manager?
   
   Add a makeReadOnly method to LifecycleExtensionsManager?

1.2

   The current implementation is that if we create a new
   LifecycleExtensions object internally inside the AbstractContainer
   we do not pass it to our children. In general, should we pass it
   to our children? If the invoker has supplied his extensions?
   If we have modified the supplied extensins list?
   If we have created our own?

   If we do want to pass it to our children then
   after we create a copy or a new LifecycleExtensManager
   inside a Container there still is no nice way to pass
   it to our children: the same we had with MetaInfoManager
   (see Patch #9 comments).

   Shall we wrap context passed to us vai contextualize()
   into our own context and put the new LifecycleExtensions
   there and pass _that_ context to our children?

   (Something I tried to avoid in Patch #9)

2
   I expect I will want to hide the CONFIGURATION and CONFIGURATION
   uri-s from the Continaer in ContextManager, something like
   
   m_childContext.put( CONFIGURATION, null )

   It's a very simple change, but I have just submitted a huge
   patch, so not to clatter the matters this is still pending.

   Or, the question I have asked before: maybe m_childContext
   shouldn't be a child of m_rootContext?

   Maybe it's better to copy what we need instead of hiding what
   we do not need?

   The price of question is whether the caller will be allowed
   to pass context entries unforseen when we write this code,
   custom context entries to his custom containers.

   If we cut m_childContext from m_rootContext users won't be
   able to do that.

   Or, alternatively we could have in ContextManager

   initializeContext()
   {
       Context customContext = m_rootContext.get( CUSTOM_CONTEXT );
       m_childContext = new DefaultContext( customContext );
       ...
   }

Okay, except for these two issues: LifecycleExtensions and context
entries in m_childContext, my patch queue is empty.

- Anton


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


Mime
View raw message