Carsten Ziegeler wrote: > > Unico Hommes wrote: > > Carsten Ziegeler wrote: > > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > > > > unico 2003/12/27 07:10:22 > > > > > > > > Modified: src/java/org/apache/cocoon/components/source > > > > CocoonSourceResolver.java > > > > Log: > > > > - tag quotes don't work > > > > - also play excalibur SourceResolver role > > > > - remove cyclic dependency declaration (Fortress chokes on it) > > > > FIXME: now that a component can play multiple roles do we > > > still need > > > > the customResolver dependency? > > > > (Carsten?) > > > > > > > I haven't followed your commits and changes :), can you > > > expand a little bit on the problem? > > > > > > > No real problem, just that declaring a dependency on a component of > > the same service type as the declaring component makes Fortress > > complain about a cyclic dependency. So I removed it. > > > Ah, ok. > > > My question is that I am not sure what was the intended > purpose of the > > customResolver. And given the fact that we now have *one* resolver > > instance playing both roles of excalibur sourceresolver > *and* cocoon > > environment sourceresolver, whether that code is still > necessary, or > > that the customResolver field is meant for something else. > > > Unfortunately, Cocoon requires a special (own) source > resolver, so you can't simply configure your own version of > an excalibur sourceresolver withint Cocoon. This would break > the cocoon source resolving :( However, in order to support > this very rare case, you can tell the CocoonSourceResolver to > use internally your own component (and this is the customResolver). >
So, a custom resolver is a custom implementation right? I mean, the default excalibur implementation has no configuration, neither does CocoonSourceResolver. Wouldn't it then - in this rare case - be better to create a 'CustomCocoonResolver extends CustomResolver implements o.a.cocoon.environment.SourceResolver'? Unico
