Hi Alex,
Did you try to use the new setLogger() method on Context? That should remove
the need to provide your own Context. Otherwise, you could simply wrap the
Component's context to only change the logger and keep to wrapped
dispatcher. Finally, if you are still curious to understand how the
Component gets its context (with the dispatcher instantiated), here is an
excerpt from the Component constructor:
public Component() {
super(null);
if (Engine.getInstance() != null) {
this.helper = Engine.getInstance().createHelper(this);
if (this.helper != null) {
setContext(this.helper.createContext(getClass()
.getCanonicalName()));
[...]
Best regards,
Jerome
> -----Message d'origine-----
> De : news [mailto:[EMAIL PROTECTED] De la part de Alex Combs
> Envoyé : vendredi 9 février 2007 01:58
> À : [email protected]
> Objet : Context logging fallout
>
> Ok, remember when I said I had a hack to change the context
> logger? Well,
> that's come around to bite me now. If I call
> Component.getContext().getDispatcher(), by default I get a nice
> TemplateDispatcher. However, because I have to create a new
> Context to set the
> logging in, calling getDispatcher() on it will return null.
> (The code in Context
> as it stands is
> public Uniform getDispatcher() {
> return null;
> }
> )
> Thus, when I override the default Component context with this
> new context, any
> future calls to getDispatcher() will fail (or more
> accurately, will return
> null). Where and how does the Component's Context's default
> Dispatcher get set,
> so I can do the same with mine?
