Craig: > OK, I think I've got it working now -- the support for multiple Struts > sub-applications in a single web-app, that is.
I'm happy to hear about this, as it's one of the things we extended in Struts 1.0 when we connected it with Expresso, as the "sub-app" concept was important for Expresso applications, like eForum, ePoll, etc. I'd like to merge what we did with where you're going, and of course any bits of what we've done already that are useful you're welcome to as well. Just some observations on the parallels, for people using both Expresso and Struts - they're pretty close in most cases, so a merge wouldn't be a serious "impedance mismatch" from what I can see: > * All of the configuration information about a sub-app is stored > in the ApplicationConfig object, including a bunch of stuff that > used to be set with init parameters on the controller servlet. This sounds a lot like what we currently call a "Schema" object (which is a misleading name, I know). The relative path to the MessageBundle for the sub-app lives in the Schema. In Expresso the Schema object also defines the list of DBObjects, Jobs, and Controllers (Action) objects, so we can do things like default security, DB creation, etc. Sounds like maybe "Schema extends ApplicationConfig" is in the cards... > * A multi-app environment still runs from a single instance of the > controller servlet, but you can have multiple struts-config.xml > files -- one per sub-application. One of our contributors extended ControllerServlet to simply read all xml's with the appropriate DTD in a specific directory, one per sub-app. Might this be easier than having to least each app in the web.xml? One less thing to configure? Just thinking out loud... Or does the param to the ControllerServlet also define the prefix? We do the same kind of thing with Lo4j config files - put each of them in a specific directory, then read everything that matches that doctype. Makes configuring a new app pretty quick and painless. > * The sub-application that applies to a particular request is based > on matching an "application prefix" at the beginning of the > context-relative URI (similar to the way that a servlet container > chooses the web app to run based on the context path prefix of the > request URI. In Expresso we have a table in the DB that lists all the "Schema" objects, and each one has a prefix like this associated with it. It also forms a prefix for finding related JSP/HTML/doc for the sub-app, so it serves double-duty in that sense. > * Like a servlet container, there is the notion of a "default" > sub-application that is used to process requests not assigned to > any sub-applicaiton. The prefix for this application is "" > (i.e. the empty string). Great news - we're already on this path, so that's no change at all. > * All of the "context relative" values in struts-config.xml are now > "application-relative" instead -- in other words, the request URI > equals "context path" + "application prefix" + "local value". This > works even for the default sub-application, because its prefix is > a zero-length string. Ditto, no change here. > * A known issue is that sub-apps won't work for path-mapped actions -- > only extension mapped at the moment. I believe this can be fixed, but > wanted to focus on getting the basics right first. Has there been any thought to extended path info as parameters? We were doing this before Expresso 4.0, but dropped it when we integrated Struts 1.0 - does make for cleaner URLs sometimes... I look forward to seeing this evolve, and helping Expresso evolve with it. Thanks for the update! Regards, Mike -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
