Rehi Anton and Unico,
uff, I have to say, hard job, but it works :-)
But I did it in other way (like your a.2 ...).
Before I start, a little note...
yes, I know the problem with nested container and accessing
components. But with using role-/configfiles a have a little
'size-problem', so therefore I tried to separate them.
(remind, my specialContainer has more then 80 components, and
the same size is the parentContainer-config. So, this is the
reason why I want to separate them from each other. Maybe you asking
yourself why so many components ? -> I am running in an EJB-Server and
these containers host the DAOImpls / EJB-Business-Impls to make them
configurable and rechangable without changing EJB-Business-structure)
So, more details...
The approach Unico gave to me I used to build a
"NestedContainer"-Interface.
public interface NestedContainer extends Initializable, Serviceable,
Disposable, Component {
// to initialize the container
public void initialize() throws Exception;
// to get the serviceManager from parentContainer
public void service(ServiceManager manager) throws ServiceException;
// to get an instance of the container
public ServiceManager getServiceManagerInstance() throws
AvalonException;
// to dispose things correctly
public void dispose();
}
Futhermore, my specialContainer(WMSContainer) is a component of his
parentContainer
(implements Component... and NestedContainer as well).
At first I run into an endless-loop, because I extend specialContainer
by DefaultContainer, so the Component-Interface called initialize() and this
method
itself built the container and called once more initialize() (because of
extending
DefaultContainer :-( )
Therefore, my specialContainerComponent does not extend DefaultContainer,
but uses one
with config.setContainerClass(). This method give you also the opportunity
to
use your own implementation of a container (maybe with disabled proxies).
The roleFile of the rootContainer : (at the moment only one childContainer)
<fortress-roles>
<role name="com.dcx.glc.wms.common.components.container.WMSContainer">
<component shorthand="wmsContainer"
class="com.dcx.glc.wms.common.components.container.impl.WMSContainerImpl"
handler="org.apache.avalon.fortress.impl.handler.ThreadSafeComponentHandler"
/>
</role>
</fortress-roles>
the configFile :
<configuration>
<wmsContainer id="wmsContainer" logger="components.WMSContainer"
activation="inline">
<parameter name="max" value="2" />
</wmsContainer>
</configuration>
(RootContainer is a DefaultContainer... initialized absolutly normal...)
WMSContainerImpl implements WMSContainer, NestedContainer {
...
service(ServiceManager man) {
upperSerMan = man;
}
initialize() {
FortessConfig config = new FortressConfig();
...
config.buildOwnRoles();
config.buildOwnConfig();
(config.buildOwnLogger();
...
config.setServiceManager(upperSerMan);
config.setContainerConfiguration(sysConfig);
config.setLoggerManagerConfiguration(loggerConfig);
config.setRoleManagerConfiguration(roleConfig);
config.setContainerClass(NoProxyContainerImpl.class);
...
}
...
}
While running initialize() the service()-method has already been called by
parentContainer and so I can set reference of the parentServiceManager.
That?s all you need to lookup components from a parentContainer.
Notice, everything is down by the framework and it?s lifecycle.
So I am happy about that everything works fine...
Thanks both,
Regards, Marco
-----Ursprungliche Nachricht-----
Von: Anton Tagunov [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 28. Juni 2003 23:18
An: Avalon framework users
Betreff: Re: [Fortress] Snipplet how to nest container ?
Hello Marco!
GMF> Hi,
GMF> does anyone have some snipplets how to nest containers ?
Okay, let's do it :")
a) what is the intent of nesting the containers?
I can imagine two possible intents
a.1)
In your example if we have the following hierarchy
generalContainer
|
-------------------------
| |
specialContainer ComGC1
| | |
ComSC1 ComSC2 ComSC3
ComSC1 will have access to all components
* ComSC1
* ComSC2
* ComSC3
* ComGC1
But ComGC1 won't have access to ComSC1, ComSC2, ComSC3
This looks like a sort of "partitioning component space"
Is this the intent?
Probably I have to scratch my head some more to find a clean
way to do this...
The code proposed by Unico may be the way. Only make sure
to manually dispose specialContainer before disposing
generalContainer. (You have to dispose it manually since you
created it manually.)
GMF> The GeneralContainer and SpecialContainer are similar
GMF> (DefaultContainer), they just should have different role/config-files,
GMF> so that a component from the SpecialContainer can lookup a component
from
GMF> the GeneralContainer.
This suggests that you really wanted to do a.1...
Still I will tell about what I know how to do well, it's a.2
a.2)
specialContainer is a component itself. It has a role. Like
public class SpecialContainer extends DefaultContainer
implements RoleA
In this case all becomes somewhat clearer.
Do not create specialContainer manually.
Just declare it in the configuration file like any other
normal component. Probably you will like to overload its
configure method:
public class SpecialContainer extends DefaultContainer
implements RoleA
{
public void configure( Configuration conf ) throws ...
{
Configuration myConfig = conf.getChild( "my" );
Configuration childConfig = conf.getChild( "child" );
super.configure( childConfig );
.... use myConfig to setup yourself ....
}
}
and your config will look like
super.xconf
<config>
<special-container id="specialContainer">
<my>
....regular configuration...
</my>
<child>
<!-- now declare all child component for special
container --->
<component-type-1 id="ComSC1">
....
</component-type-1>
<component-type-2 id="ComSC2">
....
</component-type-2>
<component-type-3 id="ComSC3">
....
</component-type-3>
</special-container>
<component-type-4 id="ComGC1">
...
</component-name-4>
</config>
Note that ComGC1 will have access to "specialContainer" as a
component (remember, it implements RoleA ?), but not to
ComSC1, ComSC2, ComSC3.
ComSC1 in its turn will have access to ComGC1, specialContainer,
ComSC1, ComSC2, ComSC3.
Good luck!
GMF> maybe ServeltContainer...
you're probably looking for SEVAK, it's in avalon-sandbox
GMF> Only the ServletContainer may override the DefaultContainer)
this sentence has remained a miracle to me (i did not understand
what "override" means)
GMF> Have any ideas how to build this with fortress ?
Have relined my.
The approach for a.2 is different because I'm not sure
if all goes well for a component without any roles.
Still you may try to use a.2 style for a.1.
I would subclass DefaultContainer, only to add
@avalon.component directive there and give it a name,
say "default-container", but no roles.
Then I would try to configure it like
<config>
<default-container>
<component-type-1 id="ComSC1">
....
</component-type-1>
<component-type-2 id="ComSC2">
....
</component-type-2>
<component-type-3 id="ComSC3">
....
</component-type-3>
</default-container>
<component-type-4 id="ComGC1">
....
</component-type-4>
</config>
This should work too. Please report your failure/success
(sorry, not time atm to experiment myself :-(
-Anton
GMF> Thanks,
GMF> Marco
GMF> ---------------------------------------------------------------------
GMF> To unsubscribe, e-mail: [EMAIL PROTECTED]
GMF> For additional commands, e-mail: [EMAIL PROTECTED]
GMF> ---------------------------------------------------------------------
GMF> To unsubscribe, e-mail: [EMAIL PROTECTED]
GMF> For additional commands, e-mail: [EMAIL PROTECTED]
--
Best regards,
Anton mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
