struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Topping" <>
Subject RE: initConfigDigester refactoring?
Date Tue, 16 Jul 2002 23:17:01 GMT
Hi Craig,

I've thought through this problem quite a bit at this point.  I appreciate
that you've taken the time to provide us with your suggestions, for if anyone
would have an idea on this, I figure it would be you, so it means a lot that
we've explored all the options.

But unfortunately, none of them really address what we are looking to do.
I'm going to pitch you on moving this into contrib.  Here's why:

> * Custom implementation of org.apache.struts.config.ControllerConfig

For a sample config (as it works today):

<action path="/contactListExample"
type="com.oroad.stxx.example.ContactListExampleAction" scope="request">
  <forward name="success">
    <transform name="default" path="/contactListExample.xsl"/>
    <transform name="Mozilla" path="/contactListExample_Mozilla.xsl"/>
    <transform name="MSIE" path="/contactListExample_MSIE.xsl"/>

Using <set-property/> might look like: 
<action path="/contactListExample" ...>
  <forward name="success">
    <set-property name="t1name" value="default"/>
    <set-property name="t1path" value="/contactListExample.xsl"/>
    <set-property name="t2name" value="Mozilla"/>
    <set-property name="t2path" value="/contactListExample_Mozilla.xsl"/>

The potential for error with this gets out of control as we serialize
elements (with arbitrary numbers of future attributes over the course of
time) into name-value pairs.  Worse, what happens when you want to change the
order or insert a transform?  I don't think it's workable.

> * (external processor configuration files)

If the outside processor was something like Cocoon that had a complete
sitemap implementation that was separate from the struts-config, this might
work, but IMHO sitemaps are the power as well as the problem with Cocoon --
they are amazing but way too fragile for production systems that are going to
be tweaked with under demanding circumstances.  Any time there is a
sub-config as you have suggested, it's the same slope as using Cocoon itself
-- homogeneous external configuration for transforms.  Don't get me wrong, I
think Cocoon is a work of art, but it's just too much of a paradigm shift,
and grows more complex by the minute.  (Have you looked at it lately? ;-0)

Putting the transforms directly into the struts-config is elegant and robust.
Because Struts has Java everywhere, the specter of struts-config growing to
look like a sitemap (which many people agree is the controller in an MVC
Cocoon app) is pretty remote.

> * Custom plug-in that configures things (the idea I quoted yesterday)

Even if this were to work, we are still bound by the DTD that keeps us from
having transform elements as a part of the forward element.  And by the
previous example with the propagation of <set-property> and easily botched
synthetic names for the properties, this is not robust enough for production


To maintain current grace, we basically have a couple of choices.  The first
would be to keep going the way it's been done for 1.0 -- subclass the servlet
and put our fingers back into Digester.  Since Struts-XSL is backwards
compatible with existing Struts applications, this doesn't hurt users, it
just means extra regression time for someone who wants to report a
Struts-only bug since they have to confirm the problem happens on verbatim
struts releases.  It's a pain for Struts-XSL developers because they have to
watch Struts CVS and copy changes because there isn't the possibility of a
clean override.

The second option, the one I am leaning toward at this point, is that
Struts-XSL becomes a part of Struts, initially through contrib.  The project
can get some more sunshine, and if it works out, it gets on the mainline
path.  I think you'll see the changes are minimal and well-isolated, so the
only overhead and risk that an application that doesn't use the Struts-XSL
tags will see is a few (less than five) simple conditionals that weren't
there before.  This would allow us to become a part of the DTD before it goes
final and ease the burdens of a forked code base.

Why I'm being tenacious:

>From my own perspective, I started using Struts after getting frustrated with
sitemap problems and less mature integration with the J2EE container
architecture.  But the power of XSL and pipelines is something that was never
lost on me (ask any Cocoon nut ;) and when I saw Jeff post about Struts-XSL,
one look and I was sold.  I think it's an important bridge between the two
worlds, allowing fluid use of both systems.  Having a "mini-Cocoon as a
standard feature of Struts" would give you 80% of the power with only 20% of
the Cocoon sitemap hassle.  And I wager there will be a lot of Cocoon
converts (like me) that tried it but couldn't adapt to the shift.

XML isn't an "if", it's a "when".  On my projects (which involve phone
handsets and web browsers alike), it's critical.  I'd like to have this
support there from the start because it allows application deployers to work
with XSL presentation wizards to keep the site content fresh, without
involving programmers to make simple changes to presentation objects.

Would you guys consider a contrib patch if I prepare it?  If (tongue firmly
in cheek) you absolutely-won't consider-it-no-way-go-away, how about getting
a 1.2 branch so we can get started on this properly?  I'm worried about
getting on 1.2 because the release cycle seems to be an annual event, living
with CVS for a year seems like a rough road, but the sooner the better.

best regards,


> -----Original Message-----
> From: Craig R. McClanahan [mailto:
> Sent: Tuesday, July 16, 2002 11:25 AM
> To: Brian Topping
> Cc:; Jeff Pennal
> Subject: RE: initConfigDigester refactoring?
> On Tue, 16 Jul 2002, Brian Topping wrote:
> > Date: Tue, 16 Jul 2002 07:24:16 -0400
> > From: Brian Topping <>
> > To:
> > Cc:, Jeff Pennal <>
> > Subject: RE: initConfigDigester refactoring?
> >
> > > From: Craig R. McClanahan []
> > >
> > > 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? :)
> >
> We are in beta, but the gotcha would be present even if we were not in
> feature freeze right now -- the XML parser will choke on the extra
> parameters that you want your custom RuleSet to process.
> > 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,
> (Long story, but ...) in our particular case, it solves the problem of
> making some servlet context attributes Serilaizable so that 
> Struts apps
> will run at all on some popular containers.
> The other important benefit is for tools that can build high quality
> editing interfaces for the configuration information.  Try to build an
> admin tool that understands all possible configurations of Tomcat 4's
> server.xml file for a fairly extreme example of this.
> > 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.
> >
> I will grant you that there's no way to customize them with standard
> JavaBeans properties on the request processor itself.  It is 
> not correct
> to say that it's impossible to configure request processor 
> instances in
> struts-config.xml files.  Here's a couple of ways off the top 
> of my head:
> * Custom plug-in that configures things (the idea I quoted yesterday).
> * Custom implementation of org.apache.struts.config.ControllerConfig
>   (corresponds to the <controller> element) with extra properties that
>   you can set with <set-property> elements nested inside.
>     <controller className="mypackage.MyControllerConfig" ...>
>       <set-property name="foo" value="bar"/>
>       <set-property name="baz" value="123"/>
>     </controller>
>   These properties are visible starting at the init() method of your
>   RequestProcessor instance, because it receives the ApplicationConfig
>   for this application module:
>     public void init(ActionServlet servlet, ApplicationConfig 
> appConfig)
>         throws ServletException {
>         MyControllerConfig myConfig = (MyControllerConfig)
>           appConfig.getControllerConfig();
>         if (myConfig.getFoo() != null) {
>             ...
>         }
>     }
> > 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
> >
> This particular kind of configuration doesn't fit the pattern 
> of simple
> JavaBean property setters as the customization mechanism.  For 1.1
> compatibility, your best shot is to parameterize a separate 
> XML file that
> defines your own configuration format (which, like every format, is
> probably still fluid as well :-).  In a post-1.1 release, we 
> can look at
> what's going on in the J2EE 1.4 world (using schemas for 
> validation, and
> namespaces for extensibility of deployment descriptors) as a 
> model of how
> to address this concern in a more general way.
> Craig
> --
> To unsubscribe, e-mail:   
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message