struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Gielen <gie...@it-neering.net>
Subject Re: [RT] Struts 3?
Date Sun, 28 Aug 2011 07:00:15 GMT
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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message