You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Anton Tagunov <at...@mail.cnt.ru> on 2003/05/23 17:24:10 UTC
Re[2]: [Announce] Excalibur Phase III Release Candidate 3 available
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 );
AT> However, currenlty lookup( RoleManager.ROLE ) also ALWAYS
AT> returns something. If users start writing applications
AT> relying on that and if we take RoleManager away later
AT> we may sort of brake backwards compatibility..
BL> This is a problem, but we also have a chicken and the egg problem.
BL> We can't remove the RoleManager concept unless we outfit all our
BL> released components with the Meta Information that is necessary.
BL> The FortressRoleManager was written when Fortress was new so that
BL> the user didn't have to write a roles file for excalibur components.
We can do this -- see bellow! :-))
BL> We would have to make it explicitly known to our users that the
BL> FortressRoleManager concept would be going away, and that they
BL> would have to hand-write the Roles file for those components,
BL> unless we provide a .roles file for them.
It would also be viable desision.
AT>
AT> Oh, am I talking crap? Most likely users will never do
AT> lookup( RoleManager.ROLE )... only maybe for writing
AT> nested containers...
AT>
BL> No, you have a good point. The only entities that would look
BL> up RoleManagers or MetaManagers are containers. We can
BL> manage some of those entries so that the container hides them
BL> from regular components.
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
(this has pushed me to create Patch #5,
I'm sorry about so much patches in one day :-)
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?
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? ;-)
AT> excalibur-fortress-tools.jar/<collect-meta>
AT> does not generate .deps for me.
BL> Ok. I will look into that. It is rather important.
Good luck! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Fortress] MetaInfoManager/RoleManager relationship
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Anton Tagunov wrote:
>>
>> 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? ;-)
You were looking in the wrong place. It should be in the JavaDoc
for the service() method.
BTW, the Deps generation info is fixed as well as a bug in the DAG
verification code.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[Fortress] MetaInfoManager/RoleManager relationship (was Re: [Announce]
Excalibur Phase III Release Candidate 3 available)
Posted by Berin Loritsch <bl...@apache.org>.
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