Hi Didier,
> 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...)
I liked your solution already in the first place, I was just not aware that
my solution was
*that* bad :) ... and I hated to rewrite the complete code again after
having something running
with Fortress in my real app. <g>
>
> > 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 ??
You mensioned this "*i-dont-know-where-to-put-it* key constant" and I
wondered,
what you use accessing the context elements. Looking into Avalon code it
seems a
normal scheme defining and using MyConstants.CONSTANT_KEY. Even for the
solution
above I would define such keys for the servlet init param keys.
> > > - 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.
Well, you might have missed the "private". Therefore I *know* that I have a
DefaultContext ;)
(was a pragmatic solution, I knew that I would not use this ctor from
outside - otherwise I would
have to implement a private ctor with a dummy argument to offer the same
interface)
Regards,
J�rg
BTW: Your comments are highly welcome ...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
