On Tue, 16 Jul 2002, Brian Topping wrote: > Date: Tue, 16 Jul 2002 19:17:01 -0400 > From: Brian Topping <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Struts Developers List <[EMAIL PROTECTED]>, > Jeff Pennal <[EMAIL PROTECTED]> > Subject: RE: initConfigDigester refactoring? > > 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. >
Brian, You're absolutely right that the "arbitrary properties on the controller config" appraoch, or similar things, don't scale very well to the kinds of things you are trying to do. > 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"/> > </forward> > </action> > I suppose you could extend this for locale-sensitive transforms as well? > 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"/> > ... > </forward> > </action> > > 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. > As I mentioned in a previous mail in this thread, the solution to this kind of thing I like best is using XML namespaces for extensibility. It is essentially the way that JSP pages are "extensible" (custom tag libraries live in their own namespaces), and it's the direction that all the deployment descriptors in J2EE 1.4 (including Servlet 2.4 and JSP 2.0) are going. Mechanically, I don't know if we can get there with DTD based parsing (i.e. JAXP/1.1) without giving up validation. Fortunately, in the future, we'll have schema support so you can have validation and extensibility both, but as for now I sure like getting an error message on bad input instead of wondering why my configuration info was mysteriously ignored (say, because of a typo in the element name). > > * (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) > Not for a while ... I'm almost scared to :-). But I agree that "work of art" is a pretty accurate asseessment. > 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 > systems. > > Options: > > 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. > I would definitely be interested in this. > 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? I would definitely like to see such a contrib patch. With the agreement of the other Struts committers, it would make sense to have you become a committer as well at some point -- especially at the point when we decide to integrate something like this into the Struts core (so that it doesn't require extensions to the DTD :-). When you're ready, just ship me a zip or tar.gz and I'll put it into the CVS repository. > 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. > Yah, who woulda thunk it would take this long ... I have very deliberately tried not to think beyond 1.1 very much (otherwise I'll succumb to working on the "cool new stuff" and never get 1.1 out the door :-), but I suspect it's going to be a pretty long release cycle no matter what. Consider just some of the things we should think about at the strategic level (let alone all the detailed features): * Is the next version 1.2 or 2.0 (i.e. do we become at least a little more willing to break backwards compatibility to fix/refactor things). * Which servlet/JSP specs do we base it on? Currently Struts is servlet 2.2 and JSP 1.1, which is tremendously limiting. I'm not going to settle for less than Servlet 2.3 / JSP 1.2, but we should also be thinking about the next round, because there is some very cool stuff in JSP 2.0. * Integration with JSTL tags, and possible deprecation of the corresponing tags in the "bean" and "logic" libraries. We might want to ease the conversion here by supporting the expression language from JSTL 1.0 (and JSP 2.0) in existing tags as an alternative to the current syntax supported by the "name/property/scope" attribute triplets. * Integration with JavaServer Faces when it comes out, and possible deprecation of the "html" library. Once it's clear that Faces will be popular (and it certainly generates *tons* of interest), it won't make sense to invest a lot of effort in creating GUI components that don't conform to the standard APIs. (In my role as spec lead for JavaServer Faces, you can correctly presume that I'm going to make sure this works well for Struts users :-). * Integration with the "web services" craze, by making it easy to use Struts as the architecture for web services as well as web applications. (XML is definitely real, not hype, and IMHO the term "web servicse" doesn't have to be arbitrarily limited to using SOAP). * Integration of workflow and scripting mechanisms (wouldn't it be cool to "script" a multi-page wizard with an XML based language like commons-jelly, and/or "script" an Action -- including arbitrary method calls on arbitrary business logic -- so that non-Java developers could help out on the back end side of Struts applications as well. So, it's going to take a while for the developers to sort out our wishes for post-1.1 things. But the future is definitely going to be exciting. > best regards, > > -b Craig > > > -----Original Message----- > > From: Craig R. McClanahan [mailto: > > Sent: Tuesday, July 16, 2002 11:25 AM > > To: Brian Topping > > Cc: [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Cc: [EMAIL PROTECTED], Jeff Pennal <[EMAIL PROTECTED]> > > > Subject: RE: initConfigDigester refactoring? > > > > > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > > > > > > > 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: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
