> -----Original Message----- > From: Wolfgang Gehner [mailto:[EMAIL PROTECTED] > Sent: 24 September 2005 11:06 > To: Struts Developers List > Subject: Re: Thread-unsafe Command classes > > > If I want to use Spring I use Spring MVC, but I think a lot > of drive in > Struts evolution is to encorporate nice ideas that have come up as > techniques elswhere over the last years, see Struts TI. So Struts > developers won't *have to* use Spring on top or instead. (I am not > convinced that TI should use/depend on Spring). > > I think CoR with Chains is great and simple for declaratively linking > things as of Struts 1.3. I also think CoR is a more beautiful pattern > than IoC for a lot of people. I also think there is a great bang in > using the execute(context) interface rather than > execute(mapping, req, > res etc). I have written commands rather than actions for 8 > months now > and I don't miss old actions a bit.
Chain of commands do give one the ability to perform "action chaining". Do you allow the action context to propogate to the background data access layer or not? In these day I dont think it makes a lot of difference, because most of us, I believe, I writing co-located J2EE applications. In the earlier days, the so-called best practice was to separate Servlet API from the back end business tier. The reason was for remote distributed EJB, which apparently just a few were actually using in ager. Nowadays everything is bundled in one EAR for deployment. Chaining is a lot more comprehensible for the beginner, because it is a use-case that many programmers have come across before. Inverse of control is harder on the brain if you have never done any event-driven or "callback" style programming where you allow the framework manage the lifecycle of your beans and action. > > I still like the behavior of a class inside the class. When > you have an > execute hook you probably need less understanding of the class > implementation and how possibly inject stuff otherwise. At least not > YACF (yet another config file) - cf. Ruby on Rails. Also think of > .execute(context) as an entry comparable to a main method. I did not quite follow the argument "class" within a "class". I agree with you it is another example of XML hell. The fly in the ointment is that inverse-of-control is now often used with aspect orient development. Beans can be intercepted or transformed if they instantiated from the framework (or indirectly from an annotation) > > If I need to create an adapter class to run particular logic, > I could do > that with plain old actions. > There may still be cases where IoC is really needed, but with > Struts 1.3 > as tool I just I don't come across them that often. > If you want to write a command with transactional or logging behaviour. then you might run with an IoC / AoP container. > Another advantage of using the command interface is if I find > that some > command is generic to an application I can add them to the defautl > struts chain, rather than wiring through a custom base-command class. > Which really leverages the new chain architecture of Struts! > Finally we > can change the default behavior of the Struts cycle. It has the > potential to wire stuff for all kinds of apps, including remote. Now > that's a great bang! > > Could you imagine having rewritten the struts request processor with > spring IOC? > > Re the singleton issue: I think you suggest to override the "bridge" > ExecuteCommand class that will do singleton/non-singleton based on an > input parameter that could be specified in ActionMapping. > Flipping out > old ExecuteCommand is a cinch with 1.3 struts-chain.xml > > Or add that as a feature as in a type="[EMAIL PROTECTED]" > attribute. Right now I think "instance" should be the default > attribute. > From the experience that non-thread-save classic Actions are > a typical > newbie error, which can lead to catastrophic behavior of the > application. > > Wolfgang > > > Joe Germuska wrote: > > > I've recently been designing applications so that per-action-path > > commands are retrieved from Spring rather than from the default > > commons-chain CatalogFactory. This then makes the lifecycle of the > > command an external property (based on the "singleton" > attribute of a > > <bean> element in a Spring beans XML file.) > > > > Of course this required custom request processing commands, since > > Struts 1.3 doesn't have direct dependencies upon Spring. > > > > More to the point, though, I don't think there's really that much > > "wow" to saying that Chain can "execute any arbitrary > class" -- even > > "executing a class" implies that the class implements Command, and > > then its not arbitrary any more. > > > > The best thing I think would be to write a command which > instantiated > > this other arbitrary class, extracting properties from the > Context to > > pass to the "main" method of the arbitrary class and > interpreting the > > return appropriately (possibly modifying the Context as well.) > > > > This is basically how the Chain deals with Struts Actions > right now; > > it's an unimportant detail that the Struts Actions are > pooled and not > > created each time, but the point is that rather than > modifying Action > > to implement Command,we wrote a bridge Command. If your arbitrary > > class isn't threadsafe, rather than modifying that > arbitrary class to > > implement Command you should write a complementary Command > which knows > > how to use that class in a threadsafe manner. > > > > Make sense? > > > > Joe > > > > > > > > At 9:49 AM +0200 9/23/05, Wolfgang Gehner wrote: > > > >> Hi there, > >> > >> I keep telling people that 1.3 allows out of the box to > execute ANY > >> ARBITRARY CLASS via command=, catalog= and chain-config, > as long as > >> it implements the command interface. If those classes have to be > >> tread-safe, like old actions had to be, that is not entirely true. > >> > >> Any idea how to configure non-thread-safe commands (i.e. that have > >> instance variables outside methods) in Struts 1.3, even if > they are > >> not perfect commands (Commons-chain says that > catalog.getCommand will > >> reuse instances). > >> > >> How about overriding ExecuteCommand to create new > instances if some > >> action-mapping parameter is present, and how to (a question to > >> commons-chain). > >> > >> That should also be made VERY evident in the Docs. > >> > >> We are just deploying a 400 screens application we wrote on Struts > >> 1.3, and it works great! of course our commands are all > thread-safe. > >> > >> Kind regards, > >> > >> Wolfgang Gehner > >> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Peter Pilgrim :: J2EE Software Development Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
