avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [Fortress] MetaInfoManager/RoleManager relationship (was Re: [Announce] Excalibur Phase III Release Candidate 3 available)
Date Fri, 23 May 2003 15:51:33 GMT
Anton Tagunov wrote:
> Hello, Berin!
> 
> AT> user may rely on the fact that
> AT> lookup( MetaInfoManager.ROLE ) will return something.
> 
> BL> Actually any more this is not guaranteed.  The changes you made
> BL> to the ContextManager made the initializeMetaManager do nothing,
> BL> so I removed the method.  Unless the user explicitly supplies the
> BL> MetaManager, it will not be set.
> 
> Hmm.. It is the AbstractContainer now that creates a
> ServiceMetaManager, maybe we could do something like this?
> 
> -        m_serviceManager = new FortressServiceManager( this, serviceManager );
> +        localSM          = new DefaultServiceManager( serviceManager );
> +        localSM.put( MetaInfoManager.ROLE, m_metaManager );
> +        m_serviceManager = new FortressServiceManager( this, serviceManager );

Yep.

> BL> Or at least the RoleManager.  That
> BL> way the contract is that the MetaInfoManager.ROLE is always
> BL> available, but the RoleManager is only available to the
> BL> direct child container.
> 
> Berin, I feel that may be a good idea but I'm afraid I've lost my way
> a bit: what does "child container" here stand for? Does it stand for
> "a" or for "b" in the following schema:
> 
> DefaultContainerManager
>     DefaultContainer       <--- a
>          CustomContainerA  <--- b


b is what I am talking about.

> 
> (this has pushed me to create Patch #5,
> I'm sorry about so much patches in one day :-)

:)  Its ok.  I want to get this done, but of course it is better
to have a good release.

> 
> AT>    I have made the changes to SourceResolve
> AT>    ...
> AT>      * excalibur-fortress-tools.jar
> AT>      * qdox.jar
> 
> BL> The big thing is the whole GUMP build.  This introduces a circular
> BL> dependency on Fortress and SourceResolve.
> 
> Please give Patch #4 a second look!
> 
> I beleive that it solves the chicken-and-egg problem!
> 
> I put the statically generated .meta and .deps under ./src
> and if fortress-tools is not found the static ones are used.
> 
> So we have Fortress depending on SourceResolve,
> and not vice-versa!! :-)))
> 
> Does not this really chop a knot we could not untie?
> What do you think of it?

It's somewhat of a hack--but it is something we need to look at.
I still think a Tools mini-project would be good, which would
incorporate XFC, Fortress tools, etc.

Let's take this one step at a time.  After the Fortress 1.0
release, I want to look at standardizing the way we store
the meta-information.

> 
> AT> 3. Berin, please also note that those and the same patch
> AT>    to SourceResolve also adds @avalon.dependency on
> AT>    SourceFactory to SourceResolverImpl.java
> AT>    I beleive you will want this change too.
> 
> BL> The attributes are on the implementations--I could have swarn
> BL> I already did that (or somebody did).
> 
> Yes, they are there, but this one, @avalon.dependency was missing!
> SourceResolverImpl does depend on ResourceFactory, doesn't it? ;-)

Ok.


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


Mime
View raw message