I've finally had a chance to download this check-in. Please note that while I've built it, I haven't yet had a chance to test it with anything. Are there any examples yet which include all these new features (exceptions, roles, multi-apps, etc.)? There's a lot get one's arms around.
Most importantly, this is great stuff and really appreciated. If one of the committers would propose giving Craig a raise, I'd +1 it. ;) So... Some general comments and comments from looking at pieces of the code: 1. I don't know if this is carved in stone yet, but IMHO this is much more than a 1.1 release. Perhaps not a 2.0 release, but at least a 1.5 release. The implications of a single point release to me are minor functional enhancements and bug fixes. These are substantive, major functional enhancements which still provide backward compatibility. Again, just my opinion... 2. I'm thrilled to see all the config-related stuff broken out from the servlet. I did this myself in some recent attempts at refactoring ActionServlet, and the effort was desperately needed to make ActionServlet more approachable. Naturally, Craig did a better job than I, as he gave each piece of config info its own class. Much more manageable and flexible that way. 3. In the DTD, the BeanName entity is being overloaded somewhat in that it's used for naming keys to various context attributes as well as for the form beans. BeanName is documented as having to be a legal Java identifier since it's used in JSPs; not sure off the top of my head if that is a constraint on attribute names in the various servlet contexts or not. In any case, might I suggest a "ContextKey" entity be added to the DTD and that used where appropriate (data-source.key, action.attribute, etc.). 4. Breaking out the request processing into RequestProcessor is also huge. ActionServlet plus the config stuff seem like they can now stand alone with pluggable request processing easily able to reuse those elements. 5. In the new ActionServlet, doGet and doPost are identical. Would it be better to delegate their implementations, simple though they are, to a protected overridable method? 6. It's a little confusing seeing member variables of type and name "FastHashmap actions" in both ApplicationConfig and RequestProcessor. Perhaps the variable names could be clarified. 7. Is the special handling for the default app's ControllerConfig and MessageResourcesConfig so that existing web.xml files will still work for setting those parameters? 8. ActionForward and ActionMappings both still retain references to ActionServlet, and in both cases it seems primarily to allow the user of an ActionForward or ActionMappings to get a reference to the servlet. With the drastic changes to ActionServlet, what method on ActionServlet would the user of an ActionForward or ActionMappings need to call? I guess what I'm saying is that it would be nice to deprecate and/or remove those getServlet/setServlet methods from those classes if they're not really required, esp. if the "best practice" way to get to a resource is through one of the contexts. FWIW... Thanks for bearing with me. Please note that I'm not trying to avoid contributing by bringing up these issues. I want to make sure I don't jump to any false conclusions before I try to help out. Thanks again, Donnie > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 12, 2002 7:53 PM > To: [EMAIL PROTECTED] > Subject: The BIG Check-In for Multi-App Support > > > OK, I think I've got it working now -- the support for multiple Struts > sub-applications in a single web-app, that is. > > While I'm writing up some documentation for it, here's the key points that > will help you experiment with it: > > * 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. > > * 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. > > * 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. > > * 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). > > * 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. > > * A primary design goal is that the "struts-config.xml" for an existing > Struts applicaiton can be used as a sub-application with no changes. > Failure of this to work should be considered a bug in the current > implementation, and needs to be fixed. > > * In addition to its other duties, the controller servlet creates > two request attributes for all requests that flow through the > controller: > > Action.APPLICATION_KEY Will contain the ApplicationConfig > instance for the sub-applcation that > is selected by the current request URI. > > Action.MESSAGES_KEY Will contain the MessageResources > instance for the sub-applcation that > is selected by the current request URI. > > * WARNING: If you want to use your existing Struts application as a > sub-application, then *ALL* of the requests must flow through the > controller servlet -- no direct linking to pages -- in order for the > above request attributes to always be set. In a servlet 2.3 > environment, we'd be able to avoid worrying about this by using > a filter, but that doesn't help under servlet 2.2. > > * 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. > > As a quick example of the new approach, assume you have three sub-apps: > main - Main menu and such (this is the default subapp) > catalog - The shopping portion of a shopping site - prefix "/catalog" > checkout - The checkout portion of a shopping site - prefix "/checkout" > > You would configure the sub-applicaitons in their own struts-config files, > and tell the controller servlet about them like this: > > <servlet> > > <servlet-name>action</servlet-name> > <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> > > <!-- The default sub-application --> > <init-param> > <param-name>config</param-name> > <param-value>/WEB-INF/struts-config-main.xml</param-value> > </init-param> > > <!-- The catalog sub-application --> > <init-param> > <param-name>config/catalog</param-name> <-- Includes prefix! --> > <param-value>/WEB-INF/struts-config-catalog.xml</param-value> > </init-param> > > <!-- The checkout sub-application --> > <init-param> > <param-name>config/checkout</param-name> <-- Includes prefix! --> > <param-value>/WEB-INF/struts-config-checkout.xml</param-value> > </init-param> > > ... other global parameters ... > > </servlet> > > In such an environment, you might have context-relative request URIs like: > > /index.jsp Main menu of the entire site > /logon.do Log on action (default subapp) > > /catalog/index.jsp Main menu of the product catalog > /catalog/addItem.do Add an item to the shopping cart > > /checkout/index.jsp Beginning of the "check out" area > /checkout/checkVisa.do Check the entered VISA credit card number > > Application Development Issues: > > * As stated above, I tried to maximize backwards compatibility. The > following points are things I know about that might impact porting > of existing Struts apps into being usable in a multi-sub-app > environment as a sub-application (no change should be required to > continue use as the "default" sub-app). > > * Applications that are calling Action.getResources() should be modified > to call Action.getResources(HttpServletRequest) instead. This allows > you to pick up the message resources that are unique to this > sub-application. Otherwise, the message resources for the default > sub-app will be used. > > * Applications that depend on the ActionFormBeans, ActionForwards, or > ActionMappings servlet context attributes should be modified to > get the information they need from the ApplicationConfig object instead. > > * Applications that subclass ActionServlet will most likely need to be > modified because of the refactoring to create RequestProcessor. It > should be straightforward to subclass the request processor class > instead. > > Let's get this new code wrinkled out in the short term so that we can move > towards a 1.1 release as well as the 1.0.1 that was just created. > > 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]>
