You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "Md. Rezaul Hoque" <ja...@gmail.com> on 2005/12/18 19:22:25 UTC
DTD/XSD of config-chain.xml
Hi,
Can you tell me please where can I get dtd/xsd to know about to write
config-chain.xml of commons-chain?
Regards
-Babu
Re: [chain] DTD/XSD of config-chain.xml
Posted by Craig McClanahan <cr...@apache.org>.
On 12/18/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 12/18/05, Craig McClanahan <cr...@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
>
>
Re: [chain] DTD/XSD of config-chain.xml
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/18/05, Craig McClanahan <cr...@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?
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [chain] DTD/XSD of config-chain.xml
Posted by Craig McClanahan <cr...@apache.org>.
On 12/18/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 12/18/05, Rahul Akolkar <ra...@gmail.com> wrote:
>
> > I'm not aware of one. Some thoughts that may help, based on my
> understanding:
> >
> > * A <catalog> element (usually the root) can contain any number of
> commands.
> > * A command may be represented by a single <command> element or a
> > <chain> element
> > * A <chain> element can contain multiple <command> elements, which
> > get executed in order
>
> Any thoughts on the use of <catalog> as the root element vs. <chains>
> as shown in the cookbook examples?
>
> Using <catalog> puts the commands into the default catalog which is
> retrieved with CatalogFactory.getInstance().getCatalog().
>
> Using <chains> seems to do something else. I haven't figured out if
> the commands are going somewhere else, if the config file just isn't
> being parsed, (or if I'm imagining it.)
Chain tries to be incredibly (perhaps insanely :-) flexible about what
element and attribute names it recognizes. As I mentioned in a previous
message, the code that actually decides this is the instance of
ConfigRuleSet that you use to configure the Digester that parses the XML
configuration resources. The cookbook page on the web site illustrates what
to use when you take the defaults.
http://jakarta.apache.org/commons/chain/cookbook.html
In addition, you are also running into a semantics issue caused by the
development history of Chain. Originally, there was no concept of catalogs;
all the commands and chains were registered together, and the <catalog>
syntax was sufficient for that. Later on, it became clear that multiple
catalogs were a very useful gadget. (As a side note, you'll smile when you
see whose idea *that* was, and did a lot of the heavy lifting :-):
http://issues.apache.org/bugzilla/show_bug.cgi?id=31566
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. The Digester
rules are initialized with patterns like "*/chain" and "*/command" that
match wherever in the XML document hierarchy they are found.
Thanks,
> --
> Wendy
Craig
Re: [chain] DTD/XSD of config-chain.xml
Posted by Craig McClanahan <cr...@apache.org>.
On 12/19/05, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 12/18/05, Wendy Smoak <ws...@gmail.com> wrote:
> <snip/>
> >
> > Any thoughts on the use of <catalog> as the root element vs. <chains>
> > as shown in the cookbook examples?
> >
> > Using <catalog> puts the commands into the default catalog which is
> > retrieved with CatalogFactory.getInstance().getCatalog().
> >
> > Using <chains> seems to do something else. I haven't figured out if
> > the commands are going somewhere else, if the config file just isn't
> > being parsed, (or if I'm imagining it.)
> <snap/>
>
> As Craig mentions, its in fact better to have <catalogs> (or <foo>,
> but thats not readable) as the root since that allows placing more
> than one <catalog> elements in the chain config. Sorry, I'm not sure
> what <chains> is all about,
AFAIK it has no semantic meaning at all ... just an outer container for
multiple commands or chains defined inside.
I'll have to take one more look at the
> cookbook later. But looking at the trunk I can tell you the only
> elements of any semantic significance are <catalog>, <chain>,
> <command> and <define> (by default, though <define> could add others
> -- and it might even be possible to redefine <command>, which I
> believe is part of the "insanity" that was refered to ;-).
>
> The absence of a DTD and validating digester can indeed cause "silent
> failures" where the *intent* of the author goes unnoticed.
>
> Going back to the question asked, is there anything that can be done
> to help WRT validation at authoring time for chain configs, short of
> having users understand the digester? What do folks think about
> providing a DTD for the defaults, maybe on the wiki? This can provide
> some "in-editor" validation for the default rule-set, and a user may
> enhance the DTD for their own custom rules if they see fit (while the
> digester will continue to not be validating).
If you added <catalogs> as an outer element, you could cover the elements
for <catalog>, <chain>, and <command>. However, DTDs (or even schemas) are
not capable of dealing with what <define> does, and that is darned handy for
reducing the amount of stuff you have to write when using a common command
over and over again.
>From a strategic perspective, I could see some educational benefit to this
... but it also seems likely that it would cause confusion since it wouldn't
be required (and you should *not* declare it in DOCTYPE declarations on your
config files, because it is not complete).
An alternative approach might be to provide a utility class that could
"pretty print" all of the configured catalogs and commands, so you can look
at the result and see if it's what you expected.
-Rahul
>
>
> > Thanks,
> > --
> > Wendy
> >
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: [chain] DTD/XSD of config-chain.xml
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/18/05, Wendy Smoak <ws...@gmail.com> wrote:
<snip/>
>
> Any thoughts on the use of <catalog> as the root element vs. <chains>
> as shown in the cookbook examples?
>
> Using <catalog> puts the commands into the default catalog which is
> retrieved with CatalogFactory.getInstance().getCatalog().
>
> Using <chains> seems to do something else. I haven't figured out if
> the commands are going somewhere else, if the config file just isn't
> being parsed, (or if I'm imagining it.)
<snap/>
As Craig mentions, its in fact better to have <catalogs> (or <foo>,
but thats not readable) as the root since that allows placing more
than one <catalog> elements in the chain config. Sorry, I'm not sure
what <chains> is all about, I'll have to take one more look at the
cookbook later. But looking at the trunk I can tell you the only
elements of any semantic significance are <catalog>, <chain>,
<command> and <define> (by default, though <define> could add others
-- and it might even be possible to redefine <command>, which I
believe is part of the "insanity" that was refered to ;-).
The absence of a DTD and validating digester can indeed cause "silent
failures" where the *intent* of the author goes unnoticed.
Going back to the question asked, is there anything that can be done
to help WRT validation at authoring time for chain configs, short of
having users understand the digester? What do folks think about
providing a DTD for the defaults, maybe on the wiki? This can provide
some "in-editor" validation for the default rule-set, and a user may
enhance the DTD for their own custom rules if they see fit (while the
digester will continue to not be validating).
-Rahul
> Thanks,
> --
> Wendy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [chain] DTD/XSD of config-chain.xml
Posted by Wendy Smoak <ws...@gmail.com>.
On 12/18/05, Rahul Akolkar <ra...@gmail.com> wrote:
> I'm not aware of one. Some thoughts that may help, based on my understanding:
>
> * A <catalog> element (usually the root) can contain any number of commands.
> * A command may be represented by a single <command> element or a
> <chain> element
> * A <chain> element can contain multiple <command> elements, which
> get executed in order
Any thoughts on the use of <catalog> as the root element vs. <chains>
as shown in the cookbook examples?
Using <catalog> puts the commands into the default catalog which is
retrieved with CatalogFactory.getInstance().getCatalog().
Using <chains> seems to do something else. I haven't figured out if
the commands are going somewhere else, if the config file just isn't
being parsed, (or if I'm imagining it.)
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [chain] DTD/XSD of config-chain.xml
Posted by Rahul Akolkar <ra...@gmail.com>.
Please add component prefixes to email subjects, I've prepended
[chain] to this email's subject.
On 12/18/05, Md. Rezaul Hoque <ja...@gmail.com> wrote:
> Hi,
>
> Can you tell me please where can I get dtd/xsd to know about to write
> config-chain.xml of commons-chain?
>
<snip/>
I'm not aware of one. Some thoughts that may help, based on my understanding:
* A <catalog> element (usually the root) can contain any number of commands.
* A command may be represented by a single <command> element or a
<chain> element
* A <chain> element can contain multiple <command> elements, which
get executed in order
* The generic command LookupCommand allows you to refer to another
command in the same or different catalog
* Commands can be Filters, which get calls for postprocessing on
failure or run to completion.
* It is possible to define multiple catalogs (chain-config files) in
the web.xml.
-Rahul
> Regards
> -Babu
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org