RE: initConfigDigester refactoring?

["Jesse Alexander (KADA 11)" <al...@csfs.com>]

Hi,

the <set-property> is similar to our "innermost" structure.
Here is an excerpt from our dtd:
--------------------------------------------------------
<!ENTITY % properties "(section*, property*, resolve*)*">

<!ELEMENT section (%properties;)>
<!ATTLIST section id CDATA #REQUIRED>

<!ELEMENT property EMPTY>
<!ATTLIST property key CDATA #REQUIRED
                   value CDATA #REQUIRED
                   modifiable (yes|no) "no">

<!ELEMENT resolve EMPTY>
<!ATTLIST resolve key CDATA #REQUIRED
                  url CDATA #REQUIRED
                  modifiable (yes|no) "no">

<!-- usage sample: -->
<!ELEMENT helper (..., %properties;, ...)>
--------------------------------------------------------
The nice thing is that we allow nesting of parameters using
the recursive elements <properties> and <section>.
<property> and <resolve> basically are the same. <property>
defines a "hardcoded" configuration parameter. <resolve> 
defines a parameter that can be controlled from the outside,
eg. a System-property passed to the servlet-engine using a 
"-D...=..." parameter.

Our config-class then translates this structure using SAX into 
nested java.util.Properties structures.

sample:
--------------------------------------
<helper id="sample">
  <section id="mySample">
    <section id="subTree1">
      <property key="prop1" value="djdjdjdjdj" />
      <property key="prop2" value="dada" />
    </section>
    <section id="subTree2">
      <section id="subTree3">
        ...
      </section>
      <property key="prop3" value="hello" />
    </section>
    <property key="prop4" value="byebye" />
  </section>
  <property key="prop5" value="a sample value" />
  ...
</helper>
--------------------------------------
will create properties with the following keys (when mapped to a 
single big Properties-object:

sample.prop5 = a sample value
sample.mySample.prop4 = byebye
sample.mySample.subTree1.prop1 = djdjdjdjdj
sample.mySample.subTree1.prop2 = dada
sample.mySample.subTree2.prop3 = hello
sample.mySample.subTree2.subTree3...

each of the levels can also be accessed as a Properties of its own.

I think it permits to store and access rather complex structures 
as well. The only drawback I see is, that the sub-trees created 
like this (in our case the applications private configuration) 
themselves can only be validated by the receiving class. But the 
stuff around (in our case our framework-related config) is 
validated by the dtd. The whole config can also be distributed 
across multiple files using "dtd-includes". Some of our apps have
quite "big" config-files.... As a matter of fact we already have seen
problems related to SAX and xml-elements that cross buffer-margins
(resulting in duplicate element-events from SAX).

I do not know whether this is by definition already Digester-compatible,
but the translation into Properties was not an impossible task...

regards
Alexander

-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Mittwoch, 17. Juli 2002 17:26
To: Struts Developers List
Subject: RE: initConfigDigester refactoring?




On Wed, 17 Jul 2002, Jesse Alexander (KADA 11) wrote:

> Date: Wed, 17 Jul 2002 09:22:09 +0200
> From: "Jesse Alexander (KADA 11)" <al...@csfs.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: RE: initConfigDigester refactoring?
>
> Hi,
>
> about the config-file, validation and extension...
> We have in our framework a configuration file (XML...) that
> is validated against a dtd. But it remains extensible.
> We do it by allowing at various places inthe dtd a
> property-attribute (which basically is a mapping for a name-value pair).

Is that like the <set-property> element that is used various places in
struts-config.xml files, for exactly this purpose?

> In this way the values that must be validated go into the dtd and
> can be also defaulted. Who needs special-values can put them
> into property-attributes that can then be read by the interested
> parties.
>
> Maybe something similar could ease the Gotcha in Brian's idea.
>

The "arbitrary property" works great when you only want to add a couple of
JavaBeans properties to some subclass you are configuring.  It doesn't
work so well for more complex cases, as Brian illustrated in his response.

It also completely breaks down when you'd prefer to have an entire set of
nested XML elements and attributes for use in configuring the component,
instead of just a set of additional attributes on one element.

> regards
> Alexander

Craig


>
>
> -----Original Message-----
> From: Brian Topping [mailto:topping@digidemic.com]
> Sent: Dienstag, 16. Juli 2002 13:24
> To: craigmcc@apache.org
> Cc: struts-dev@jakarta.apache.org; Jeff Pennal
> Subject: RE: initConfigDigester refactoring?
>
>
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> >
> > This is an interesting idea.  I see a pretty serious
> > potential gotcha --
> > Struts performs a validating parse of the struts-config.xml
> > file, and this
> > is required (as of recent nightly builds) because we rely on
> > some default
> > values set in the DTD.  Thus, even if you could extend the ruleset to
> > recognize more things in struts-config.xml, the validating parser will
> > choke on them unless the DTD is modified.
>
> Hi Craig,
>
> Wow, is this for 1.1?  I thought you guys were in beta -- bug fixes on
> showstoppers, final candidate builds, yah? :)
>
> Seriously though, I've been thinking for a while on the implications of
> *requiring* config file validation, and while I can imagine there is some
> problem that was gracefully solved by it, these restrictions seem to neuter
> parallel RequestProcessor implementations, at least as far as I understand
> the servlet initialization path, which I believe I have seen most of now.
>
> Put another way, if the only RequestProcessor that can have first-class
> configuration information is the default one built into Struts, what point is
> there in having the RequestProcessor split out at all?  It seems like you
> still have to subclass ActionServlet, you still have to configure the
> separate subclass into web.xml, yada yada, and most of the effort that was
> put into consolidating applications in 1.1 is suddenly for naught.
>
> Don't get me wrong, I'm a big fan of validation of config files.  And I know
> it's hard to keep a DTD up-to-date in an OSS project if validation is not
> required.  So I don't want to sound like a stick in the mud about it.  But I
> think a pattern needs to be chosen between 1:1 or 1:n regarding
> servlet:application.  Without a significant deprecation of one or the other,
> the competing paradigms will end up consuming valuable project energy.
>
> Last time I looked, there was a non-trivial amount of work going into Cocoon
> for Sitemap DTDs, but since the DTD is a function of the current Avalon
> configuration, it's a pretty fluid target.  I doubt things are much different
> with Digester.
>
> Okay, enough hot air.  Thanks for your consideration on this.
>
> -b
>
> p.s. - the application that I am porting is Struts-XSL.  It basically allows
> for the configuration of Cocoon-ish pipelines within a Struts action, without
> the overhead of Cocoon.  Everything is operational except the Digester/config
> stuff.  But the StXX pipeline configuration is arbitrary repetition of
> <transform/> elements, so putting them in set-value elements is too unwieldy.
> -b
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>