> You mean: replace the old DI engine (which is the predecessor of Guice) > with current Guice. Do I understand correctly?
Yep. I'm also unsure of the amount of work required--I'm trying to dig in to it along with a related side project and just don't know yet. > Do you mean change the package naming from com.opensymphony to > org.apache.struts If yes, I agree. Yes, although I really want to keep the command pattern bit isolated from the web bits still. That's as simple as correct packaging, though. Along with that comes finding the code that XWork dupes, like some commons stuff, and replacing it. Some of that has already been done. > > S1. Refactorings for further extensibility based on questions on the list, > > on CodeRanch, and Stack Overflow. > Have you got some links handy? just some example to better understand what > you mean. I don't, actually, but off the top of my head, things like the JR plugin make it difficult to make report files come from anywhere but the file system, because the compiled report lookup happens (relatively) deep within the result processing. Most problems like that are solvable with fairly trivial refactoring. This extends to some of the XWork stuff (I've brought up the type conversions before, as have others) and potentially a bit in S2-non-plugin code--still poking around. d. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
