On 12/18/05, Wendy Smoak <wsmoak@gmail.com> wrote:
>
> On 12/18/05, Craig McClanahan <craigmcc@apache.org> wrote:
>
> > As usual in Apache land, we tried to stay backwards compatible with the
> old
> > syntax, even though it ideally would have gotten pulled before the
> > 1.0release. I would suggest sticking with the syntax that supports
> > multiple catalogs, but with one final warning -- the actual element name
> of the
> > outermost element of your document does not really matter.
>
> I'm not sure which one is 'old'. None of the cookbook examples uses
> <catalog> at all. What syntax are you suggesting?
Sorry ... <catalog> outer element *is* the old syntax (although it will
still work). Confusing, huh?
The critical difference between the old-style and new-style configuration
processing is the presence or absence of a particular context init parameter
*org.apache.commons.chain.CONFIG_ATTR*
which is deprecated in 1.0. If you used this parameter, you were declaring
the name of a servlet context attribute under which the one-and-only Catalog
would be stored. This was used before CatalogFactory existed.
But, it still works even using the new style parsing, because the <catalog>
element is matched against a Digester rule pattern of "*/catalog" (if you
take the defaults) ... and this works even if <catalog> is the outermost
element in your document.
My personal preference is to do what the Shale Use Cases example does, and
use an outermost element name of <catalogs>, to denote the fact that the
nested elements are themselves <catalog> elements. For example:
<catalogs>
<catalog name="first catalog">
<chain name="first chain in first catalog" ...>
...
</chain>
<chain name="second chain in first catalog" ...>
...
</chain>
</catalog>
<catalog name="second catalog">
...
</catalog>
...
<catalogs>
But, as mentioned earlier, the outermost element name is not relevant to the
actual matching being performed.
Craig
Craig
*
*
Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
|