Hi J�rg,
> ?? It is the same scheme Fortress is using itself. It creates
> ContextManagementConstants as extension to ContainerManagementConstants.
> So, where is the difference? Now every developer can request an element
> from the context vital for the run-time of the component.
The deep difference is in what is tight to Fortress in your and my solution.
In your solution, in fact, everything is dependent on Fortress:
- Your root initialization code (this can't be avoided because in any cases
you must instanciate Fortress)
- Your MyServletConfig because it extends something from Fortress.
In my solution, in fact, only the root initialization code is dependent and my
ContextWrapper can be reused to wrap ServletConfig for any another container or
component.
So what is the better is to be the more independent that you can of what you use
(i mean you depend on it anyway because you use it). This way when you need to
change you don't have the whole thing to change, just change the root
initialization code. (that you need to change anyway because you replace
Fortress...)
> Well, in the end I might not expose ServletConfig to the developer, but
> several special values from this context. But it helps me now running
> existing code :)
This is another thing, nothing avoid you to do this in the Context.get() method :
public Object get(Object key) throws ContextException
{
if (key.equals(ContainedServletConstants.SERVLET_CONFIG_CONTEXT_KEY))
return m_config;
if (m_config.getInitParameter(key.toString()) != null)
return m_config.getInitParameter(key.toString());
if (m_parentContext.get(key) != null)
return m_parentContext.get(key);
throw new ContextException("No such key");
}
I added the first two lines to return you directly the ServletConfig object.
> BTW: What is the normal element used as key for the context? Such
> constants are used in Avalon code.
I do not understand what you ask, sorry... Can you explain ??
> > - How can you know the pParent context is a DefaultContext
> > without looking to
> > the source ??
>
> Who has to know this? Anyone is just referencing Context!
> MyServletConfig is used in the same way as FortressConfig ... once to
> initialize the app.
Sorry did not ask it correctly:
I meant, when you write:
public MyServletConfig() {
this(new DefaultContext(createDefaultConfig()));
}
private MyServletConfig(Context pParent) {
super(pParent);
m_context = (DefaultContext) pParent;
}
this is an error because you can't assume that the context given as parameter is
a DefaultContext. The first constructor way is better in that it does not cast.
> > - How do you manage the possibility for the FortressConfig
> > class interface to
> > evolve ?
>
> Well, this is the culprit <g>
You should use the ContextWrapper solution this is safer.
> OK. There are advantages :)
>
> > Not commiter but do not approve!!! :)
>
> Valid opinion <g>
;)
A+. Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
