we use Jalopy formatting referenced in the build http://jalopy.sourceforge.net/
I would prefer the user not be married to a interceptor library OR any DI library the pom should be the ultimate arbiter of which interceptor or DI methodology a user wants to use what has been characterised as XML hell takes away configuration responsibilites from Sys admin and delivers to the developer your proposal to gut XML Declarators to populate those details by annotations probably will not work in production environments and may cause proposed future developments in Struts to lose to Spring or Seam I have my reservations for Whistler..see you soon Martin ______________________________________________ Note de déni et de confidentialité Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Sun, 28 Aug 2011 15:00:15 +0800 > From: gie...@it-neering.net > To: dev@struts.apache.org > Subject: Re: [RT] Struts 3? > > Christian, > > always good to start such discussions and bring in momentum. See my > comments inline > > Am 27.08.11 19:09, schrieb Christian Grobmeier: > > Hello guys, > > > > are there already plans for a Struts 3? > > > > 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. > > 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... > > 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. > > > * 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 :) > > That said, we should do an important additional refactoring here and > move all S2 / XW related annotations into a seperate module. This would > make it easier for users to use them without automatically coupling to > the framework. E.g. some enhancements like abstract event support for > the portlet2 plugin would directly benefit. Currently it is very hard to > introduce new annotations without creating coupling. > > > * 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? > > > * 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 :-) > > > > The worst times are over here, since XWork was finally moved to our > codebase. Also, I'd fully support to clean up package names in general > for a 3.x release, since it allows you to make breaking API changes. > > I'm a little bit concerned that remerging XWork fully into the S2 base > would cause architectural flaws slipping in over time. The architectural > decision behind the seperation of concerns is still valid, thus the > division between both project parts (WebWork / S2 vs. XWork) caused > people to think about what they were about to do. > > > * 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! > > > > > > > So, I am not sure if there is enough interest or enough manpower to do > > the changes. Maybe there are some other roadmaps around. I couldn't > > find them. In any case, I am interested in your thoughts of the future > > Struts development, be it S2 or S3. > > > > Cheers > > Christian > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > > For additional commands, e-mail: dev-h...@struts.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org >
