Hi Didier,
> I think that you can pass a Context to the FortressConfig,
> and FortressConfig
> have a static method createDefaultConfig(ClassLoader):Context
> that creates the
> base context for FortressConfig.
[...]
yes, I think this would have been a solution, too.
I came up with another solution by implementing a subclass for FortressConfig.
Overloading both ctors. I put now an additional context between the root context and
the context of the container:
public class MyServletConfig
extends FortressConfig
{
private DefaultContext m_context;
public MyServletConfig() {
this(new DefaultContext(createDefaultConfig()));
}
private MyServletConfig(Context pParent) {
super(pParent);
m_context = (DefaultContext) pParent;
}
public void setServletConfig(final ServletConfig pServletConfig) {
m_context.put(MyServletContextManagerConstants.SERVLET_CONFIG, pServletConfig);
}
public Context getContext() {
m_context.makeReadOnly();
return super.getContext();
}
}
TestCase written, works fine.
Regards,
J�rg
BTW: If any of the committers approve this as "good solution" I may add this to the
wiki. I understand, that such a beast is normally not necessary, since anything could
normally be initialized using a normal configuration. However, in triggered
environments like a webapp or a plug-in, such "additional" context information may be
necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
