>> I have several features I would love to see. The good user I am, I >> share it with you :-) >> >> * JSR-330 >> Currently Struts uses Spring as DI provider. But there is now a >> standard. Should't it be used? Reference implementation is available >> with Google Juice. Spring could be optional only. My guess is that >> many features of Spring are unused for a normal webapp and using plain >> Java is always nice, if it is not java.util.logging (kidding) >> http://www.jcp.org/en/jsr/detail?id=330 > > As already said in this thread, S2 internally uses a very early version > of Guice, directly contributed by Bob Lee - not Spring as in earlier > WebWork days. Nevertheless Spring is directly supported for user's DI.
yes, I learned that now. > Supporting JSR-330 can be divided into two seperate questions - do we > want to base the framework internal DI on JSR-330 or do we want to > provide JSR-330 support for users. > > The first question, is answered with yes, would most probably result in > replacing the pre-release Guice by a current version. It would be great > to see this happen, although this is a massive refactoring - some of us > already had a deeper look into it, it's kind of frightening... If everybody is afraid to replace a pre-release Version of a lib with a stable release - well, that's bad. Of course I have no oversight on the impact. But using the latest developments in a framework is a good thing. As Struts 2.3.x release process mainly provides smaller portions of code, a branch for this improvement would be helpful, if it will be ever started. > For the user side, it is all about the DI plugins such as Spring or > Guice plugin. The plugin has to care about how injection should happen > within actions and interceptors. As for the Spring plugin, when used > with Spring 3+, it should support JSR-330 afaik. > > More interesting from the user perspective is IMHO JSR-299 (CDI), which > builds on JSR-330. This brings real power and choice to the user. > Luckily the CDI plugin was just promoted out of the sandbox, so the next > full release would support it. Very interesting! > >> * Annotation-driven Actionmapping >> There was / is a Plugin doing that, but it was deprecated recently. >> Why not break up Struts and check if Annotations aren't possible from >> the core? XML is out - Annotations are in. These Annotations was one >> of the "coolest" features when somebody has explained me why the Play >> Framework is so cool >> > > I'm also pretty much for making the convention plugin a part of core. > This does not mean we have to ditch XML configuration in any way, but it > would bring annotation and convention support out of the box, without > the need to find the right plugin. Making this a first class citizen > would help to remove the notion of Struts = XML hell :) ++1 >> * Log4j 2.0 >> Currently there is some effort with Log4j 2.0. It is far from >> proudction ready at the moment, but Struts 3 could take a while. >> Besides, version used by struts is 1.2.9. But the current is 1.2.16. >> Time for an upgrade in current development? >> > It's great to see that log4j gets new momentum, and I even saw some > interesting discussions about pimping commons-logging over at Commons I > guess. Nevertheless we should take into account that we're providing > just the toolkit with which others build their actual applications. Each > application has it's own operations plan, and it should be free to chose > the right logging framework for it's needs. To switch to a pluggable > logging system would IMHO be the natural choice, and although I'd > usually prefer some homebrew from Apache, slf4j currently seems to be > the leader of the pack. > > As you're quite involved as I know, could you give us a brief status on > what is going on in logging abstraction land over at Commons? Hard to say to be honest. The discussion raises now from time to time. A few are looking at slf4j too and consider commons-logging as dead. Others say: it works, it is not dead, it is just complete. There is no real consens on what will happen to commons-logging. But it seems people are looking eagerly at log4j 2.0. logback is rising, but it has not reached the market share of a log4j. I think this might be the last chance for the log4j project to keep the pole position. My feeling says, if log4j 2.0 does not come, log4j will die, and then commons-logging will die too. But there are very good signs at logging. At logging we try to push now the next chainsaw release. Log4j2 gets quite good commits recently and had its discussions already on list. If I would maintain a framework like Struts I would ask myself these questions: - how important is a switchable logging system really (for my users)? - slf4j is still not world dominating - is it ok for me to rely on an API which is mainly driven by one man? (slf4j/logback has a different development model and without the dev leader, nothing happens) - What actually gives slf4j to me? My impression is Struts should wait - thats why I said in "Struts 3". Look at the how log4j2 develops. If it fails, then there is probably no discussion necessary. > >> * Complete assimilation of WebWork >> As a user I always had some trouble with WebWork separated from >> Struts. I remember the discussion when WebWork was merged - it was all >> about easy migration for WebWork users and such. Now, with changing >> the Actionmapping to Annotations and use of JSR-330 it might be a good >> time to merge WebWork fully into Struts and change the package names. >> I am not sure if I am aware on all complications, but my users heart >> desires easy to understand modules :-) >> >> * OGNL 4.0 >> OGNL is a Commons project now. It may take a while until the next >> release, probably it is ready for a Struts 3, maybe even earlier. >> Latest with Struts 3, OGNL 4.0 should be there. >> > Great, of course - hopefully even with some solution for WW-3580 ??? > Good to see OGNL being vivid again, especially here at Apache! I do not know if WW-3580 is addressed, but I will post this to the commons dev list. No reason why projects should not help each other :-) Cheers Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
