--- Joe Germuska <[EMAIL PROTECTED]> wrote: > >I'm just making this up as I go, but what if there were an optional > >servlet init param which could consist of one or more class names, > >where each class implemented a "StrutsConfigurator" interface. Then > >in servlet.init(), the servlet could instantiate each and pass > >itself to the configure method (or maybe just pass the > >ServletContext, if that's safer or better). > > I decided to take a look at this today, and it's a little bit tangly. > I figure that it's not something to commit until we cut Struts 1.2.1 > anyway, but here is a bit about how I'm starting and some questions. > All feedback is welcomed.
This thread seems to have taken a turn into something I'm interested in; too bad the subject didn't change with it so I could have started following sooner. If this is about refactoring Struts initialization code out of ActionServlet then I'm definitely interested. In fact, I took a look at this some time ago but stopped to pursue other items. > > I created an interface: org.apache.struts.action.StrutsConfigurator. > I have no great love for the name nor insistence on it being in that > package. > > I wanted it to have a single method: > public void configure(ServletConfig config) throws Exception; > > I'm open to any strong opinions about whether it should throw > ServletException instead, or anything else. I really don't like methods that throw Exception so I like ServletException better. > > However, it's tricky to only pass in the ServletConfig, as some of > the legacy code that I'm trying to move out from ActionServlet into > an implementation class (currently named "ClassicConfigurator") wants > access to the ActionServlet itself. Specifically, the datasources > are still a member of the ActionServlet, rather than being shared in > the Application Context. I have never used Struts to manage > datasources and don't really plan to, but I don't want to mess anyone > up. Should we move those into the ServletContext so that various > configurators can get at them? Or just relax and pass ActionServlet > into the configurator instead? I'd really like to avoid that if > possible. IMO, Struts datasource handling should be deprecated and removed. It had it's place in the past but now Struts has no business "managing" datasources; that's the containers job and most of them do it better than Struts. I would like part of Struts 2.x to focus on simplifying users' lives and removing this feature follows in that spirit; but that may be for another thread. > > However, I now remember, we also need an ActionServlet to initialize > plugins. Do I just have to bite the bullet? Or can we figure out > another way? I can't think of anything which would be backwards > compatible. I just liked the idea of keeping the actual > ActionServlet class out of things, especially as we pull more and > more functionality out of that class. At this point isn't ActionServlet merely init. code plus delegation to the RequestProcessor? In the future ActionServlet may just be delegating to init. classes and to Commons Chain so I agree that we should probably limit passing it around. It's really more of a starting point for a request than anything else. David > > In a different vein, I was wondering about handling "internal" > message resources. I was thinking about copying the pattern from > ActionServlet, but there are classes (like ExceptionHandler) which do > essentially the same thing but in a slightly different pattern. In > the spirit of consistency, is there a "preferred" implementation > pattern that we should use for this? > > Assuming that all this gets straightened out, then, the final step > would be to deprecate the ActionServlet init* methods which are > copied into ClassicConfigurator and to re-implement the middle-part > of init() to initialize one or more configurators and execute their > configure methods. But maybe we'll get into that a little more later. > > My first pass was pretty crude, just copying stuff from ActionServlet > into ClassicConfigurator. It seems like it might make sense to make > it easier for things like a configDigester to be shared, but then, > perhaps its not appropriate to assume that extended config rulesets > that apply to one configurator apply to another. If that's the case, > well, everyone already has access to the ConfigRuleSet class which > covers the basics. > > Looking forward to some feedback... > Joe > > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Imagine if every Thursday your shoes exploded if you tied them > the usual way. This happens to us all the time with computers, and > nobody thinks of complaining." > -- Jef Raskin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
