Github comments and pull request emails

[Paul Benedict]

Why aren't they going to our issues list? I don't think they should be
going to our "dev" list. Can we submit a ticket with infrastructure to
change the destination?

Cheers,
Paul

Re: Upgrade to tiles 3 jcl-over-slf4j

[Paul Benedict]

I could be wrong, but I thought log4j2 provides the equivalent bridging
functionality to other logging frameworks.

Cheers,
Paul

On Fri, Jan 29, 2016 at 11:14 AM, Greg Huber  wrote:

> Yes, if you are logging directly to log4j2 but if other jars use slf4j you
> need to delegate the logging (create a log4j2.xml if upgrading from v1,
> note the format is also different!)
>
>
> 
> org.slf4j
> slf4j-api
> 1.7.14
> 
> 
> org.apache.logging.log4j
> log4j-slf4j-impl
> 2.5
> 
>
> Cheers Greg
>
>
> ##
> here is what i use, via Jakarta Commons Logging JCL.
>
> (.although my velocity is logging to the console!)
>
> 
> 
> 
> commons-logging
> commons-logging
> 1.2
> 
>
> 
> 
> org.apache.logging.log4j
> log4j-core
> 2.5
> 
> 
> org.apache.logging.log4j
> log4j-api
> 2.5
> 
>
> 
> 
> 
> 
> org.apache.logging.log4j
> log4j-jcl
> 2.5
> 
> 
> 
> 
> org.apache.logging.log4j
> log4j-slf4j-impl
> 2.5
> 
>
> 
> 
> org.slf4j
> slf4j-api
> 1.7.14
> 
> 
> 
> 
> 
>
> 
>
> 
> ${sys:catalina.home}/logs
> 
>
> 
>
>  filePattern="${log-path}/events-%d{-MM-dd}-%i.log">
>
> 
> %d %-5p %c %C{1}:%M - %m%n
> 
>
> 
> 
> 
> 
>
> 
> 
>
> 
>
> 
>
> 
> 
> 
>
> 
>
> 
>
> On 29 January 2016 at 16:48, Martin Gainty  wrote:
>
> > Hi Greg-
> >
> > can you confirm these dependencies for log4j?
> >
> >   
> > org.apache.logging.log4j
> > log4j-api  2.5
> > 
> > org.apache.logging.log4j
> > log4j-core  2.5
> >   junit
> > junit  4.9
> > test  
> > Thanks!
> > Martin
> > __
> >
> >
> >
> > > Date: Fri, 29 Jan 2016 16:04:18 +
> > > Subject: Re: Upgrade to tiles 3 jcl-over-slf4j
> > > From: gregh3...@gmail.com
> > > To: dev@struts.apache.org
> > >
> > > Well, I currently log with commons, but to get struts logging working I
> > > have had to upgrade to v2 and use the log4j2.xml file.
> > >
> > > Also a good idea to bypass the commons for slf4j and go directly.
> > >
> > > Cheers Greg
> > >
> > >
> > >
> > > On 29 January 2016 at 15:07, Christoph Nenning <
> > > christoph.nenn...@lex-com.net> wrote:
> > >
> > > > > Should jcl-over-slf4j be in the tiles-core pom?
> > > > >
> > > >
> > > > I see that it is currently the case but I do not need it.
> > > >
> > > >
> > > > > 
> > > > > slf4j-jcl is used to delegate all SLF4J logging to Commons Logging.
> > > > > 
> > > > > ​and then log4j-jcl to delegate all to Commons Logging to log4j 2
> > > >
> > > > SLF4J can be forwarded to log4j 2 directly with log4j-slf4j-impl.
> > There is
> > > > no need to include Commons Logging (if you don't need it for other
> > reasons
> > > > than forwarding).
> > > >
> > > >  
> > > >org.apache.logging.log4j
> > > >log4j-slf4j-impl
> > > >  
> > > >
> > > >
> > > >
> > > > Regards,
> > > > Christoph
> > > >
> > > >
> > > >
> > > > > It seems to be an option for migrating from Jakarta Commons Logging
> > > > which
> > > > > some might not want to do.
> > > > >
> > > > > 
> > > > >   org.slf4j
> > > > >   jcl-over-slf4j
> > > > > 
> > > > >
> > > > >
> > > > > ​http://www.slf4j.org/legacy.html​
> > > > >
> > > > > ​To ease migration to SLF4J from JCL​
> > > > >
> > > > > ​#​
> > > > >
> > > > > ​I use ​Jakarta Commons Logging.
> > > > >
> > > > >
> > > > > slf4j-jcl is used to delegate all SLF4J logging to Commons Logging.
> > > > >
> > > > > ​
> > > > >   org.slf4j
> > > > >   slf4j-jcl
> > > > > ​
> > > > >
> > > > >
> > > > > ​and then log4j-jcl to delegate all to Commons Logging to log4j 2
> > > > >
> > > > > 
> > > > > org.apache.logging.log4j
> > > > > log4j-jcl
> > > > > 2.5
> > > > > ​
> > > > >
> > > > >
> > > > >
> > > > > Cheers Greg.
> > > >
> > > >
> > > > This Email was scanned by Sophos Anti Virus
> > > >
> >
>

Re: Upgrade to tiles 3 jcl-over-slf4j

[Paul Benedict]

Why not log4j2?

Cheers,
Paul

On Fri, Jan 29, 2016 at 10:48 AM, Martin Gainty  wrote:

> Hi Greg-
>
> can you confirm these dependencies for log4j?
>
>   
> org.apache.logging.log4j
> log4j-api  2.5
> 
> org.apache.logging.log4j
> log4j-core  2.5
>   junit
> junit  4.9
> test  
> Thanks!
> Martin
> __
>
>
>
> > Date: Fri, 29 Jan 2016 16:04:18 +
> > Subject: Re: Upgrade to tiles 3 jcl-over-slf4j
> > From: gregh3...@gmail.com
> > To: dev@struts.apache.org
> >
> > Well, I currently log with commons, but to get struts logging working I
> > have had to upgrade to v2 and use the log4j2.xml file.
> >
> > Also a good idea to bypass the commons for slf4j and go directly.
> >
> > Cheers Greg
> >
> >
> >
> > On 29 January 2016 at 15:07, Christoph Nenning <
> > christoph.nenn...@lex-com.net> wrote:
> >
> > > > Should jcl-over-slf4j be in the tiles-core pom?
> > > >
> > >
> > > I see that it is currently the case but I do not need it.
> > >
> > >
> > > > 
> > > > slf4j-jcl is used to delegate all SLF4J logging to Commons Logging.
> > > > 
> > > > ​and then log4j-jcl to delegate all to Commons Logging to log4j 2
> > >
> > > SLF4J can be forwarded to log4j 2 directly with log4j-slf4j-impl.
> There is
> > > no need to include Commons Logging (if you don't need it for other
> reasons
> > > than forwarding).
> > >
> > >  
> > >org.apache.logging.log4j
> > >log4j-slf4j-impl
> > >  
> > >
> > >
> > >
> > > Regards,
> > > Christoph
> > >
> > >
> > >
> > > > It seems to be an option for migrating from Jakarta Commons Logging
> > > which
> > > > some might not want to do.
> > > >
> > > > 
> > > >   org.slf4j
> > > >   jcl-over-slf4j
> > > > 
> > > >
> > > >
> > > > ​http://www.slf4j.org/legacy.html​
> > > >
> > > > ​To ease migration to SLF4J from JCL​
> > > >
> > > > ​#​
> > > >
> > > > ​I use ​Jakarta Commons Logging.
> > > >
> > > >
> > > > slf4j-jcl is used to delegate all SLF4J logging to Commons Logging.
> > > >
> > > > ​
> > > >   org.slf4j
> > > >   slf4j-jcl
> > > > ​
> > > >
> > > >
> > > > ​and then log4j-jcl to delegate all to Commons Logging to log4j 2
> > > >
> > > > 
> > > > org.apache.logging.log4j
> > > > log4j-jcl
> > > > 2.5
> > > > ​
> > > >
> > > >
> > > >
> > > > Cheers Greg.
> > >
> > >
> > > This Email was scanned by Sophos Anti Virus
> > >
>
>

Re: Secure parameters

[Paul Benedict]

I think the class name is very confusing. Can it just be StrutsParameters?
The "secure" thing I don't think is accurate.
On Oct 8, 2015 8:31 AM, "Christoph Nenning" 
wrote:

> > From: Lukasz Lenart 
> > To: Struts Developers List ,
> > Date: 06.10.2015 08:28
> > Subject: Secure parameters
> >
> > Hi,
> >
> > I have started on introducing typed parameters instead of a Map of
> > objects as we have right now [1]. Basically I am trying to introduce a
> > dedicated class which will represent HTTP parameters [2]. This isn't
> > finished yet as I need to figure out how to handle pushing objects
> > onto parameters (ie. FileuploadInterceptor is pushing files [3]) - the
> > problem is that HTTP params are arrays of strings but we have used it
> > internally to "transport" other objects.
> >
> > Any insights welcome :)
> >
> > [1] https://github.com/apache/struts/pull/53
> > [2] https://github.com/apache/struts/pull/53/files#diff-12
> > [3] https://github.com/apache/struts/pull/53/files#diff-18
> >
> >
>
>
> Basically I love the idea to have some more meta data about each
> parameter.
>
> I would expect new 'Parameter' interface would provide a method like
> 'isExternal()' or 'isUserProvided()' but maybe this is yet to come ;)
>
>
>
> > as I need to figure out how to handle pushing objects
> > onto parameters
>
> One way could be to add methods like these to 'Parameter':
>
> Object getValueNonString()
> Object[] getValuesNonString()
> boolean hasValueNonString()
>
>
> Most places dealing with parameters just need Strings. They can use
> methods 'getValue()' and 'getMultipleValue()' and don't need to cast.
> Those few places that need other types than Strings can use 'NonString'
> methods and have to cast on their own.
>
>
>
> Regards,
> Christoph
>
> This Email was scanned by Sophos Anti Virus
>

Re: Secure parameters

[Paul Benedict]

Can you explain the "secure" aspect? I don't follow what this is trying to
accomplish. This is not a criticism; just a question.


Cheers,
Paul

On Tue, Oct 6, 2015 at 1:28 AM, Lukasz Lenart 
wrote:

> Hi,
>
> I have started on introducing typed parameters instead of a Map of
> objects as we have right now [1]. Basically I am trying to introduce a
> dedicated class which will represent HTTP parameters [2]. This isn't
> finished yet as I need to figure out how to handle pushing objects
> onto parameters (ie. FileuploadInterceptor is pushing files [3]) - the
> problem is that HTTP params are arrays of strings but we have used it
> internally to "transport" other objects.
>
> Any insights welcome :)
>
> [1] https://github.com/apache/struts/pull/53
> [2] https://github.com/apache/struts/pull/53/files#diff-12
> [3] https://github.com/apache/struts/pull/53/files#diff-18
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>

Re: [VOTE] Struts 2.5 BETA2

[Paul Benedict]

+1


Cheers,
Paul

On Thu, Oct 1, 2015 at 1:30 PM, Lukasz Lenart 
wrote:

> 2015-09-28 22:53 GMT+02:00 Lukasz Lenart :
> > [ ] Leave at test build
> > [ ] Alpha
> > [X] Beta
> > [ ] General Availability (GA)
>
> +1 (binding)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>

Re: Struts 2.5-BETA1

[Paul Benedict]

I love votes to start a vote!


Cheers,
Paul

On Mon, Jul 27, 2015 at 2:13 AM, Johannes Geppert jo...@apache.org wrote:

 +1 for starting the vote.

 Johannes
 Am 27.07.2015 08:06 schrieb Lukasz Lenart lukaszlen...@apache.org:

  2015-07-24 21:49 GMT+02:00 Johannes Geppert jo...@apache.org:
   Is there a reason why we don't publish the javadocs?
   I just refactored the javadocs a bit and some of them contains may
  usefully
   information's for developers.
   May it would be great to give the search engines a chance to crawl that
   content.
 
  As a rule we cannot publish anything without voting so I will call for
  a vote to release this BETA, wdyt?
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 

Re: Struts 2.5-BETA1

[Paul Benedict]

Thanks!! Wasn't there talk to move com.opensymphony.xwork2 into
org.apache.struts.xwork? Or is that a 3.0 deal?




Cheers,
Paul

On Sun, Jul 19, 2015 at 2:50 AM, Johannes Geppert jo...@apache.org wrote:

 Hi Paul,

 here you can find the latest java doc versions.
 But I think until the first release there are no published java docs
 available.


 https://repository.apache.org/content/repositories/snapshots/org/apache/struts/struts2-core/2.5-SNAPSHOT/

 Johannes

 #
 web: http://www.jgeppert.com
 twitter: http://twitter.com/jogep


 2015-07-19 3:03 GMT+02:00 Paul Benedict pbened...@apache.org:

  Do we have any published 2.5 javadocs?
 
 
  Cheers,
  Paul
 
  On Fri, Jul 17, 2015 at 4:13 AM, Lukasz Lenart lukaszlen...@apache.org
  wrote:
 
   Hi,
  
   Please take a time and test the bits - any help is appreciated. Please
   report any problems back. I'll call for vote in a week if no problems
   will be spotted.
  
   Staging Maven repo
   https://repository.apache.org/content/groups/staging/
  
   Standalone artifacts
   https://dist.apache.org/repos/dist/dev/struts/2.5-BETA1/
  
   Release notes
   https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5
  
  
   Thanks in advance
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
   For additional commands, e-mail: dev-h...@struts.apache.org
  
  
 

Re: Struts 2.5-BETA1

[Paul Benedict]

Do we have any published 2.5 javadocs?


Cheers,
Paul

On Fri, Jul 17, 2015 at 4:13 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 Hi,

 Please take a time and test the bits - any help is appreciated. Please
 report any problems back. I'll call for vote in a week if no problems
 will be spotted.

 Staging Maven repo
 https://repository.apache.org/content/groups/staging/

 Standalone artifacts
 https://dist.apache.org/repos/dist/dev/struts/2.5-BETA1/

 Release notes
 https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5


 Thanks in advance
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Starting work on 2.5

[Paul Benedict]

+1 JDK 7


Cheers,
Paul

On Tue, May 26, 2015 at 8:39 AM, Aaron Johnson johnson.aar...@gmail.com
wrote:

 The best place for big changes is early in the release cycle. I haven't had
 any runtime issues with JDK7 and Struts.

 On Tue, May 26, 2015 at 3:51 AM, Christoph Nenning 
 christoph.nenn...@lex-com.net wrote:

  one more +1 for jdk7
 
 
  regards,
  Christoph
 
  This Email was scanned by Sophos Anti Virus
 

Re: Few ideas related to Struts 3

[Paul Benedict]

Why do we support the do prefix at all? I don't know the answer. I'd just
like to know how it came to be.

PS: I am in favor of simplifying the internals of Struts. I don't like
having multiple ways of naming an execution method.


Cheers,
Paul

On Sun, Dec 21, 2014 at 1:24 PM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 What do you think about throwing away support for the do prefix? If
 an action method cannot be found, the framework will prepend the do
 prefix to it and will try again, this pushes a bit of hassle into flow
 logic. Dropping support will allow simplify code in few places.


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Few ideas related to Struts 3

[Paul Benedict]

+1 to get rid of do support.


Cheers,
Paul

On Mon, Dec 22, 2014 at 12:34 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 2014-12-21 23:19 GMT+01:00 Paul Benedict pbened...@apache.org:
  Why do we support the do prefix at all? I don't know the answer. I'd
 just
  like to know how it came to be.

 No idea :)


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Few ideas related to Struts 3

[Paul Benedict]

Why do you guys find it bad to access the raw request/response? I haven't
found a problem doing that as a fallback. I'd like to know what you think.


Cheers,
Paul

On Mon, Dec 15, 2014 at 10:23 AM, Ken McWilliams ken.mcwilli...@gmail.com
wrote:

 +1 for the request/response wrappers. Have you had a chance to check out:
 https://tiles.apache.org/tiles-request/   ?
 +1 for getting rid of Strings. Could see the benefit of what you say, but
 if you only meant getting rid of const Strings in favour of enums that
 alone would be pretty nice.



 On Sun, Dec 14, 2014 at 9:22 AM, Dave Newton davelnew...@gmail.com
 wrote:
 
  Lukasz Lenart wrote:
  
   Request/Response wrappers
   Right now user can access raw Request or Response [...]
 
 
  Seems reasonable, although I wonder if the appearance of not being able
 to
  get the raw request/response will make people run away--they're very used
  to doing things icky.
 
 
   No more Strings
   We are passing Strings all over the framework - they represents
   expressions, parameters and other different things.
 
 
  Strings are horrible things; +bunches.
 
  Even if they're just thin wrappers, so-called micro types can help a
 lot
  when trying to understand what's happened, and why.
 
  d.
 

Re: Struts 3 and namespaces

[Paul Benedict]

Thanks for the responses. I appreciate knowing how namespaces are used.

So it sounds to me (correct me if wrong) that namespaces provided two
purposes: (1) a convenient way of chopping off the first part of the URI
and (2) namespace level interceptor. I think that's pretty minimal
functionality. Without namespaces, you would just add the first part of the
URI back to your actions and link to a globally defined interceptor stack.
Is it all that different?


Cheers,
Paul

On Fri, Dec 12, 2014 at 5:46 AM, Kofford, C. Todd tkoff...@ku.edu wrote:

 We use namespaces when we have an application that runs both as a portlet
  as a standalone web application. In the former case the portlet
 interceptor sits at the top of the stack  the latter is just our standard
 interceptor stack, and we use namespaces to differentiate action
 invocations between the 2 types.

 Maybe there's a better way to accomplish this, but it's just the way we've
 always done things. If this were to change, we would have work to do.

 --
 Todd Kofford
 tkoff...@ku.edu


  On Dec 12, 2014, at 1:54 AM, rgm r...@rgm.nu wrote:
 
  To me it's valuable for keeping an interceptor stack separate for api
  requests.
 
  /api/v1/people/list
  Json result
 
  Vs
 
  /listpeople.action
  Web / template result
  On Dec 9, 2014 2:52 PM, Paul Benedict pbened...@apache.org wrote:
 
  One concept I never really liked in S2 are namespaces. I never found a
 good
  reason to logically group actions together with common interceptor
 setup.
  Rather I always find myself in the situation where the interceptor
 stack is
  globally set and actions have one-off changes. And I also never liked
 how
  namespaces limit the scope of result types.
 
  Am I right or is this feature really valuable?
 

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

MNG-1683: Zip packaging

[Paul Benedict]

Recently I needed to create zip artifacts for overlays into WAR. Maven
doesn't have support for zip packaging type projects, but MNG-1683 wants
to introduce it.

I am curious why this issue has been ignored. Is it just a lack of time or
interest? Or is there a philosophical issue behind? For the latter, I can't
see much difference between a zip lifecycle and jar lifecycle except there
is no default compile binding.

Cheers,
Paul

Re: MNG-1683: Zip packaging

[Paul Benedict]

Sorry guys. Wrong list. :-)

Struts 3 and namespaces

[Paul Benedict]

One concept I never really liked in S2 are namespaces. I never found a good
reason to logically group actions together with common interceptor setup.
Rather I always find myself in the situation where the interceptor stack is
globally set and actions have one-off changes. And I also never liked how
namespaces limit the scope of result types.

Am I right or is this feature really valuable?

Re: Struts 3 and namespaces

[Paul Benedict]

I hear your points.

In addition, I noticed that namespaces don't translate well with
annotations. It might just be more consistent to configure on a per action
basis just by specifying the interceptor stack to use.

Also, I find namespaces most frustrating when I rename URLs and have to
move around the config to put the XML action configs in the right
namespaces.
On Dec 9, 2014 2:57 PM, Dave Newton davelnew...@gmail.com wrote:

 I used package-level interceptors from time to time, mostly for really easy
 auth interceptors applied to chunks of pages. There was some other use-case
 I had, but I can't recall what it was; it was related to some data
 transformations.

 It also provides a mechanism for grouping actions together in a logical way
 w/o having to rely on consistent URL naming convention that can be
 fat-fingered pretty easily, but I'm not sure that counts as really
 valuable.

 On Tue, Dec 9, 2014 at 3:52 PM, Paul Benedict pbened...@apache.org
 wrote:

  One concept I never really liked in S2 are namespaces. I never found a
 good
  reason to logically group actions together with common interceptor setup.
  Rather I always find myself in the situation where the interceptor stack
 is
  globally set and actions have one-off changes. And I also never liked how
  namespaces limit the scope of result types.
 
  Am I right or is this feature really valuable?
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton http://stackoverflow.com/users/438992/dave-newton

Re: [VOTE] Apache Struts 2.3.20

[Paul Benedict]

+1 binding
On Dec 2, 2014 3:32 AM, Christoph Nenning christoph.nenn...@lex-com.net
wrote:

 +1, non binding

  [ ] Leave at test build
  [ ] Alpha
  [ ] Beta
  [X] General Availability (GA)


 regards,
 Christoph






 
  The Apache Struts 2.3.20 test build is now available. With this release:
  - merged security fixes from version 2.3.16.1, 2.3.16.2, 2.3.16.3
  - implemented stronger random generator used to generate token's
  values, S2-023
  - extended existing security mechanism to block access to given Java
  packages and Classes, see #11 or read Internal security mechanism
  - collection Parameters for RedirectResults, WW-4224
  - make ParametersInterceptor supports chinese in hash key by default,
 WW-4250
  - themes.properties can be loaded using ServletContext allows to put
  template folder under WEB-INF or on classpath, WW-4260
  - new tag datetextfield, WW-3493
  - only valid Ognl expressions are cached, WW-4146
  - customTextProvider can be used for validation errors of model driven
  actions, WW-4202
  - datetimepicker's label fixed, WW-4254
  - PropertiesJudge removed and properties are checked in
  SecurityMemberAccess, WW-4257
  - resource reloading works in IBM JVM, WW-4266
  - default reloading settings were removed from default.properties,
 WW-4267
  - commons-fileupload library upgraded to version 1.3.1 to fix
  potential security vulnerability, WW-4286
  - the scheme attribute accepts expressions in s:url tag, WW-4024
  - solves problem with infinite loop in FastByteArrayOutputStream,
 WW-4383
  - LocalizedTextUtil supports many ClassLoaders, WW-4379
  - Bill of Materials pom was introduced, WW-4326
  - debug=browser|console was migrated to jQuery, WW-4322
  - struts_dojo.js was fixed, WW-4349
  - interface org/apache/struts2/views/TagLibrary was restored and
  marked as @Depreacted, WW-4255
  and many other small improvements, please see the release notes
 
  Security bulletin:
  * [https://cwiki.apache.org/confluence/display/WW/S2-023]
 
  Release notes:
  * [https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.20]
 
  Distribution:
  * [https://dist.apache.org/repos/dist/dev/struts/2.3.20/]
 
  Maven 2 staging repository:
  * [https://repository.apache.org/content/repositories/staging/]
 
  Once you have had a chance to review the test build, please respond
  with a vote on its quality:
 
  [ ] Leave at test build
  [ ] Alpha
  [ ] Beta
  [ ] General Availability (GA)
 
  Everyone who has tested the build is invited to vote. Votes by PMC
  members are considered binding. A vote passes if there are at least
  three binding +1s and more +1s than -1s.
 
  The vote will remain open for at least 72 hours, longer upon request.
  A vote can be amended at any time to upgrade or downgrade the quality
  of the release based on future experience. If an initial vote
  designates the build as Beta, the release will be submitted for
  mirroring and announced to the user list. Once released as a public
  beta, subsequent quality votes on a build may be held on the user
  list.
 
  As always, the act of voting carries certain obligations. A binding
  vote not only states an opinion, but means that the voter is agreeing
  to help do the work.
 
 
  Kind regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 

 This Email was scanned by Sophos Anti Virus

Re: Site re-organisation

[Paul Benedict]

Yes, yes, and yes. Searching for Struts 2 help is so difficult because old
documentation always floats to the top of search engine results. Finding
out what's the latest solution is not easy. When a new version introduces
functional changes, we will just note it on the respective page.


Cheers,
Paul

On Tue, Dec 2, 2014 at 4:11 PM, Dave Newton davelnew...@gmail.com wrote:

 That's probably a great idea.

 The doc versioning thing is a long-running pain point :/

 On Tue, Dec 2, 2014 at 5:00 PM, Lukasz Lenart lukaszlen...@apache.org
 wrote:
  Hi,
 
  I'm going to re-organise our website a bit, basically there be just
  one /docs folder where all the exported and Maven generated files will
  be stored. No more /release/x.x.x subfolders as users get confused
  also search engines point them to wrong versions.
 
  /docs will contain the latest version of our wiki (a snapshot)
  synchronised with release. Plus Maven generated pages ie. dependencies
  and so on - to allow users find all those with search engines.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton
 b: Bucky Bits
 g: davelnewton
 so: Dave Newton

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

Struts 3 request/response processing

[Paul Benedict]

I added this to the wiki [1] and would like this to have a general
discussion.

S1 and S2 have different infrastructure to process a request/response. They
overlap to some degree in concept but each has a strength and weakness:

S2 is superior by allowing the user to configure processing with
interceptors, but it's weakness is that not all processing is done by
interceptors -- there is stock system functionality (for lack of a better
word) that can't be easily overridden. On the other hand, S1 is superior in
allowing the user to configure the entire processing chain with its chain
filter, but it's weakness is that it lacks all the fine functionality of
S2.

I would like to see S3 combine both approaches. I want to the interceptors
of S2 to be expanded so all the stock system functionality is extracted
into interceptors (with both a request stack and a response stack?). This
will allow the entire request/response processing chain to be customized
without having to dig into non-interceptor code (in theory).

For example, there is no easy way in S2 to customize which action will be
selected -- or which method on the action will be invoked. There is no
action select interceptor. There is no method select interceptor
You get the point.

[1] https://cwiki.apache.org/confluence/display/WW/Struts+Next

Cheers,
Paul

Re: Struts 3 request/response processing

[Paul Benedict]

Responding to both you and Steven:

Yes, the ActionMapper does select the action and method. My apologies for
phrasing my question as I did. Yet where in the interceptor chain is the
ActionMapper invoked? Or invoking the action? I think it's part of our
hidden stock functionality which means I can't easily stub in code before
or after or replace. That's really my point in all this: to fully break
down the controller into a series of interceptors so developers can enhance
the processing chain in the guts of Struts.





Cheers,
Paul

On Tue, Nov 25, 2014 at 2:22 PM, Dave Newton davelnew...@gmail.com wrote:

 On Tue, Nov 25, 2014 at 10:24 AM, Paul Benedict wrote:
  For example, there is no easy way in S2 to customize which action will be
  selected -- or which method on the action will be invoked.

 Customize in what way?

 Wouldn't most situations be covered by either wildcarding or regex
 matchers?

 Dave

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

Forms with PUT and DELETE

[Paul Benedict]

FYI, I came across this in my research. There's a working draft by W3C that
is laying out the addition of PUT and DELETE in some future version of HTML
[1]. Bookmark this to stay current. Obviously, this will be a great benefit
to RESTful applications.

[1] http://www.w3.org/TR/form-http-extensions/

Cheers,
Paul

Re: Start developing on Struts3

[Paul Benedict]

I agree with the step by step approach. With GIT, each step can be a
deveopment branch. It wouldn't make sense for all us all to do major
refactoring in one branch. We need to lay out milestones on the wiki and
merge in our work to the official struts3 branch when ready.


Cheers,
Paul

On Thu, Nov 20, 2014 at 3:11 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 Hi,

 I'm not against but I think you took 2.5 too literally ;-) Basically
 we can merge plans for 2.5 and 3.0 and start coding. But even with
 directly targeting 3.0 we still have to resolve a lot of code
 unrelated issues - where to move deprecated plugins (and how without
 losing history of commits)? should we separate plugins from Core (how
 to manage version cross matrix)? what to do with webpage
 (documentation, wiki uses code snippets, should we continue using
 Confluence)? does our current git flow model is efficient (I have some
 doubts)? and so on ...

 I'd like to treat 2.5 as a milestone (and specify other milestones),
 as we can always stop, tag the source code and prepare a release
 candidate. I'm bit afraid working on 3.0 as there is many other things
 that must be resolved - that's why I wanna do it step-by-step and
 testing/resolving one code unrelated issue in that time as well.

 Another thing is that if we gonna release some intermediate versions,
 there is higher probability that someone will use it and test it for
 us - will migrate not do a new app from scratch ;-)

 So as you see I have some doubts that I'd like address them before we
 start making new branch and renaming packages to org.apache.struts3
 ;-)


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2014-11-19 19:20 GMT+01:00 Johannes Geppert jo...@apache.org:
  Hi,
 
  what you all think about starting with Struts3 and creating a brunch
  directly after next 2.3.x release and create only maintenance releases
 for
  Struts 2.3.
 
  I personal think we should skip plans for 2.5 [1] and better concentrate
 on
  creating a new major release.
 
 
  Best Regards
 
  Johannes
 
  [1] https://cwiki.apache.org/confluence/display/WW/Struts+Next
 
 
  #
  web: http://www.jgeppert.com
  twitter: http://twitter.com/jogep

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

Re: Start developing on Struts3

[Paul Benedict]

I hope Lukasz agrees. First order of business for me is updating the
package name to struts3 and updating the POM versions.


Cheers,
Paul

On Wed, Nov 19, 2014 at 12:32 PM, Dave Newton davelnew...@gmail.com wrote:

 I'm good with this, although I'm struggling to find time for anything
 these days.

 I'd like to do some refactoring of several things, primarily for
 readability.

 On Wed, Nov 19, 2014 at 1:20 PM, Johannes Geppert jo...@apache.org
 wrote:
  Hi,
 
  what you all think about starting with Struts3 and creating a brunch
  directly after next 2.3.x release and create only maintenance releases
 for
  Struts 2.3.
 
  I personal think we should skip plans for 2.5 [1] and better concentrate
 on
  creating a new major release.
 
 
  Best Regards
 
  Johannes
 
  [1] https://cwiki.apache.org/confluence/display/WW/Struts+Next
 
 
  #
  web: http://www.jgeppert.com
  twitter: http://twitter.com/jogep



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton
 b: Bucky Bits
 g: davelnewton
 so: Dave Newton

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

Is ModelDriven validation broken?

[Paul Benedict]

From the docs: Validation will also be performed on this model object,
instead of the action. [1] The validation is not performed on the model
object with annotations. I stepped through the
(Annotation)ValidationInterceptor and neither test for ModelDriven and look
into the model for annotations.

Thoughts?

[1] http://struts.apache.org/release/2.3.x/docs/model-driven.html

Cheers,
Paul

Re: Is ModelDriven validation broken?

[Paul Benedict]

The answer is no, but I had to dig for the answer.
http://struts.apache.org/release/2.3.x/docs/visitorfieldvalidator-annotation.html

We need to link to this document from the former.


Cheers,
Paul

On Thu, Nov 13, 2014 at 12:14 PM, Paul Benedict pbened...@apache.org
wrote:

 From the docs: Validation will also be performed on this model object,
 instead of the action. [1] The validation is not performed on the model
 object with annotations. I stepped through the
 (Annotation)ValidationInterceptor and neither test for ModelDriven and look
 into the model for annotations.

 Thoughts?

 [1] http://struts.apache.org/release/2.3.x/docs/model-driven.html

 Cheers,
 Paul

Conversion errors and json

[Paul Benedict]

jsonValidationWorkflowStack includes basicStack which includes
conversionError interceptor...

An unintended consequence is that conversion error messages cannot be
customized because ConversionErrorInteceptor runs before
ValidationInterceptor and, thus, will automatically report the field
conversion errors.

Do we really want that for default behavior? The error message is techy and
cryptic to the end user. I don't think we should provide the
conversionError in the basicStack. People need to report that themselves
with validation errors.

Cheers,
Paul

@ConversionErrorFieldValidator and short circuiting

[Paul Benedict]

This validator is really primordial. If this validation error is triggered,
it makes no sense to process any other validators on the same field.
Besides, if the conversion fails, the field itself can't even be stored.

I think we should mark this in 2.5 as shortCircuit=true because of that.
Thoughts?

Cheers,
Paul

Re: Ideas for 3.0 (aka let's branch)

[Paul Benedict]

Whatever we choose to do, I would like to first work on rearranging the
packages to make the api clear.
On Nov 9, 2014 8:11 AM, Lukasz Lenart lukaszlen...@apache.org wrote:

 2014-11-09 3:23 GMT+01:00 Paul Benedict pbened...@apache.org:
  We should whiteboard on the wiki. Here are some things I had in mind:
 
  * Target Java 7 and EE 6 minimum
  * Refactor to clearly delineate framework externals (apis) and framework
  internals
  * Replace XWork annotations with Beans Validation annotations

 I would rather be agnostic here and allow use any validation mechanism
 you want this means API and SPI

  * Replace XWork injection with CDI injection

 This is good but is it supported by every container?

  * Full HTML 5 support
  * Use annotations to configure actions

 Not sure what you mean - you can use annotations even now. What about
 convention? Also configuration via code or XML is also a good idea.

  * Be a candidate for EE 8's JSR web framework spec

 You can add them here
 https://cwiki.apache.org/confluence/display/WW/Struts+Next

  I also believe (and believe a debate will ensue)
  * We should make all plugins independent projects like Maven.

 I like that idea but have some doubts - not everybody is using Maven
 to manage dependencies and because of that we will have to keep some
 page with version matrix. Do you have any idea how to handle it?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Ideas for 3.0 (aka let's branch)

[Paul Benedict]

We should whiteboard on the wiki. Here are some things I had in mind:

* Target Java 7 and EE 6 minimum
* Refactor to clearly delineate framework externals (apis) and framework
internals
* Replace XWork annotations with Beans Validation annotations
* Replace XWork injection with CDI injection
* Full HTML 5 support
* Use annotations to configure actions
* Be a candidate for EE 8's JSR web framework spec

I also believe (and believe a debate will ensue)
* We should make all plugins independent projects like Maven.

Cheers,
Paul

Re: @required attribute

[Paul Benedict]

I keep telling Lukasz we need to build 3.0 -- but he hasn't taken my advice
yet :-)


Cheers,
Paul

On Fri, Nov 7, 2014 at 7:10 AM, Dave Newton davelnew...@gmail.com wrote:

 I'd vote for following HTML5 as closely as possible.

 I'm okay with a backwards-incompatible change for the next large-ish
 release.



 On Fri, Nov 7, 2014 at 12:25 AM, Lukasz Lenart lukaszlen...@apache.org
 wrote:
  2014-11-07 6:15 GMT+01:00 Paul Benedict pbened...@apache.org:
  I noticed our free marker templates are outputting required=true into
 the
  HTML fields. This is invalid HTML. It needs to be required (name with no
  value) or required=required for XHTML.
 
  Here is discussion about that
  https://issues.apache.org/jira/browse/WW-4188
 
  and here is the original issue
  https://issues.apache.org/jira/browse/WW-3908
 
  I really need someone's advice how to proceed
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton
 b: Bucky Bits
 g: davelnewton
 so: Dave Newton

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

Re: @required attribute

[Paul Benedict]

I'd rather break everything at once. That's how I feel about it. I don't
want to keep on telling users migration plans from 2.3 to 2.5 and 2.5 to 3.0


Cheers,
Paul

On Fri, Nov 7, 2014 at 8:59 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 2014-11-07 15:56 GMT+01:00 Paul Benedict pbened...@apache.org:
  I keep telling Lukasz we need to build 3.0 -- but he hasn't taken my
 advice
  yet :-)

 We can skip 2.5 if you think that's better - but we will have a lot of
 changes at once


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

@required attribute

[Paul Benedict]

I noticed our free marker templates are outputting required=true into the
HTML fields. This is invalid HTML. It needs to be required (name with no
value) or required=required for XHTML.

Cheers,
Paul

Re: [VOTE] Struts 2.3.18

[Paul Benedict]

+1 binding.


Cheers,
Paul

On Wed, Nov 5, 2014 at 5:52 AM, i...@flyingfischer.ch i...@flyingfischer.ch
 wrote:

 +1 not binding.

 Markus Fischer

 Am 04.11.2014 um 20:28 schrieb Lukasz Lenart:

 Should I cancel this vote and prepare new one? If we cannot release
 what was tested and verified the whole process doesn't make sense :(


 Regards


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

Re: New logo

[Paul Benedict]

WOW. AWESOME.


Cheers,
Paul

On Fri, Sep 19, 2014 at 2:31 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 ech...

 http://people.apache.org/~lukaszlenart/

 please test and complain ;-)

 2014-09-19 9:31 GMT+02:00 Lukasz Lenart lukaszlen...@apache.org:
  Finally, here you have!
 
 
  2014-04-15 8:25 GMT+02:00 Lukasz Lenart lukaszlen...@apache.org:
  New frontpage with small adjustments: bigger text on download button
  and info about SoftwareMill donation in the footer
 
  https://copy.com/LmnHo87Gydff
 
  She is preparing html  css now so I assume after Easters I'm going to
  apply the new LF :-)
 
 
  2014-04-08 19:11 GMT+02:00 Ken McWilliams ken.mcwilli...@gmail.com:
  L F is a big step up from what is there! Really nice.
 
 
  On Tue, Apr 8, 2014 at 8:23 AM, i...@flyingfischer.ch 
 i...@flyingfischer.ch
  wrote:
 
  Looks good! Very clean main page, great work.
 
  Maybe the honeycomb-like background image in the green/blue part
 lacks
  some contrast?
 
  Looking forward to the new design!
 
  Markus
 
  Am 08.04.2014 13:07, schrieb Lukasz Lenart:
 
   Next version of website
 
  Main page
  https://copy.com/BhaCZtoewOYV
  Documentation pages
  https://copy.com/S2Dc0SCoHyv3
 
  I love the documentation layout but have some doubts about the main
  page which I cannot articulate them :\
 
 
  2014-03-21 21:27 GMT+01:00 Ken McWilliams ken.mcwilli...@gmail.com
 :
 
  Logo looks great! Like the original all Caps version over the Camel
  case...
  the later is more understated.
 
 
  On Fri, Mar 21, 2014 at 8:25 AM, Paul Benedict 
 pbened...@apache.org
  wrote:
 
   I think the website looks great with the new design and logo.
 
 
  On Fri, Mar 21, 2014 at 8:11 AM, Lukasz Lenart 
 lukaszlen...@apache.org
 
  wrote:
 
 
   Camel cased version
  https://copy.com/jC4OWepdqrvP
 
  2014-03-21 12:59 GMT+01:00 Lukasz Lenart lukaszlen...@apache.org
 :
 
  She's working on new layout, first attempt:
 
  https://copy.com/Ly91R3KAkPCm
  https://copy.com/9gghodFkEJmr
 
  About CamelCase - hm... good question, I also like that - will
 ask her
 
  ;-)
 
 
  2014-03-19 16:32 GMT+01:00 Rene Gielen gie...@it-neering.net:
 
  By sudden I realized I forgot to comment so far - shame on me!
 
  Logo image idea / execution: fabulous
  Color scheme: 3rd ++, 2nd +
  Font: Yet undecided. My gut fav is 2nd, but I also agree with
 Lukasz
  that Aleo (1st) is classy.
 
  Is there a consensus about all uppercase writing? Am I too
  traditional
  by considering good'ol upper+lower as well? :)
 
  Anyway - great job, and a huge thanks to you guys!
 
  - René
 
  Am 07.03.14 15:53, schrieb Lukasz Lenart:
 
  New colors https://copy.com/mewPAFa0GuQo and designer's
 answer:
 
  Several blue variants to be considered. As well as several
 fonts.
 
  I do not agree about the font - I like it very much, it is
 modern -
  not all serifs are outdated.
 
  The font is called Aleo, you can read some here
  http://fontfabric.com/aleo-free-font/
 
 
  
  -
  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
 
 
 
 
  --
  Cheers,
  Paul
 
 
  -
  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
 
 
 
 
 
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Struts 2.5

[Paul Benedict]

Well... we can also bind the plugin to the appropriate minimum version of
Struts. That shouldn't be hard to do. Either the plugin specifies what it
needs in the MANIFEST who the plugin class has an annotation with the
version range.

PS: Documentation has nothing to do with Maven :-) You should document it
on the plugin site.


Cheers,
Paul

On Fri, Sep 19, 2014 at 6:38 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 2014-09-18 16:03 GMT+02:00 Paul Benedict pbened...@apache.org:
  You do it just like Maven does it. You document it. :-)

 Problem is with guys that don't use Maven...


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Struts 2.5

[Paul Benedict]

Lots of work to write a line?


Cheers,
Paul

On Fri, Sep 19, 2014 at 9:58 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 2014-09-19 16:50 GMT+02:00 Paul Benedict pbened...@apache.org:
  Well... we can also bind the plugin to the appropriate minimum version of
  Struts. That shouldn't be hard to do. Either the plugin specifies what it
  needs in the MANIFEST who the plugin class has an annotation with the
  version range.

 Good idea, but still someone has to implement this ;-)

  PS: Documentation has nothing to do with Maven :-) You should document it
  on the plugin site.

 Yeah... lots of work


 Regard
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Struts 2.5

[Paul Benedict]

You do it just like Maven does it. You document it. :-)


Cheers,
Paul

On Thu, Sep 18, 2014 at 3:31 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 2014-09-17 16:25 GMT+02:00 Paul Benedict pbened...@apache.org:
  PS: When 3.0 comes around, I recommend we split off all plugins into
  independent release cycles like Maven plugins. This way we can evolve and
  deprecate them independently without waiting for core releases.

 I have just one doubt: keeping plugins in sync with the latest release
 (easy) and how to tell which version of plugin can be used with what
 version of core


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Struts 2.5

[Paul Benedict]

Ah, struts-extras... how time comes full circle. Struts 1 had its extra
package too:
http://struts.apache.org/development/1.x/struts-extras/

What does creating the new project buy us? or an end-user? Just curious.
Not criticizing; just wanting to learn your plan.


Cheers,
Paul

On Wed, Sep 17, 2014 at 4:46 AM, Lukasz Lenart lukaszlen...@apache.org
wrote:

 One more idea: instead of dropping deprecated plugins, move them into
 a new project ie. struts-extras, so the Struts project will consist
 of:
 - struts-framework
 - struts-examples
 - struts-apps
 - struts-archetypes
 - struts-extras
 - struts-website (on SVN)

 As far I can recall there was discussion about plugins, to also move
 them into dedicated project, but I'm still not sure if this is right
 or wrong

 2014-04-05 13:11 GMT+02:00 Lukasz Lenart lukaszlen...@apache.org:
  As I'm still working on releasing 2.3.17 I have started planning 2.5
  and the rough plan is as follow:
  - remove deprecated API
  - remove deprecated plugins
  - move apps to dedicated project
  - move maven archetypes to dedicated project
  - add safe and proper support for action: prefix
  - add safe and proper support for ! aka DMI
 
  any other ideas?
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Struts 2.5

[Paul Benedict]

If you move them into a separate module for 2.5, just don't include it in
the parent's build process (include it only as a special Maven profile).
It's someone is a die-hard hacker and wants to build it themselves, they
can.

PS: When 3.0 comes around, I recommend we split off all plugins into
independent release cycles like Maven plugins. This way we can evolve and
deprecate them independently without waiting for core releases.


Cheers,
Paul

On Wed, Sep 17, 2014 at 9:20 AM, Dave Newton davelnew...@gmail.com wrote:

 I'm not excited about keeping the deprecated plugins around; IMO it implies
 support.

 People still ask questions about the Dojo plugin on Stack Overflow, running
 in S2.3. The plugin must die.

 On Wed, Sep 17, 2014 at 10:17 AM, Paul Benedict pbened...@apache.org
 wrote:

  Ah, struts-extras... how time comes full circle. Struts 1 had its extra
  package too:
  http://struts.apache.org/development/1.x/struts-extras/
 
  What does creating the new project buy us? or an end-user? Just curious.
  Not criticizing; just wanting to learn your plan.
 
 
  Cheers,
  Paul
 
  On Wed, Sep 17, 2014 at 4:46 AM, Lukasz Lenart lukaszlen...@apache.org
  wrote:
 
   One more idea: instead of dropping deprecated plugins, move them into
   a new project ie. struts-extras, so the Struts project will consist
   of:
   - struts-framework
   - struts-examples
   - struts-apps
   - struts-archetypes
   - struts-extras
   - struts-website (on SVN)
  
   As far I can recall there was discussion about plugins, to also move
   them into dedicated project, but I'm still not sure if this is right
   or wrong
  
   2014-04-05 13:11 GMT+02:00 Lukasz Lenart lukaszlen...@apache.org:
As I'm still working on releasing 2.3.17 I have started planning 2.5
and the rough plan is as follow:
- remove deprecated API
- remove deprecated plugins
- move apps to dedicated project
- move maven archetypes to dedicated project
- add safe and proper support for action: prefix
- add safe and proper support for ! aka DMI
   
any other ideas?
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
   For additional commands, e-mail: dev-h...@struts.apache.org
  
  
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton http://stackoverflow.com/users/438992/dave-newton

Re: MVC 1.0: JSR 371

[Paul Benedict]

There is always talk of the mythical Struts 3.0 :-)


Cheers,
Paul


On Fri, Aug 29, 2014 at 10:23 AM, Frans Thamura fr...@meruvian.org wrote:

 hi all
 MVC 1.0

 will we have Struts JavaMVC spec implementation?


 https://jcp.org/en/jsr/detail?id=371


 F

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

Re: [jax-rs-spec users] [jsr339-experts] MVC 1.0 JSR

[Paul Benedict]

I never heard of a JSR that codifies an official MVC solution. If you
have the JSR number for what you're speaking about, let me know.


Cheers,
Paul


On Tue, Aug 19, 2014 at 12:06 PM, Frans Thamura fr...@meruvian.org wrote:

 anyone know this?

 MVC become JSR.

 F



 -- Forwarded message --
 From: Santiago Pericas-Geertsen santiago.pericasgeert...@oracle.com
 Date: Tue, Aug 19, 2014 at 9:37 PM
 Subject: [jax-rs-spec users] [jsr339-experts] MVC 1.0 JSR
 To: jsr339-expe...@jax-rs-spec.java.net


 Hello Experts,

  As I stated in my earlier message, MVC 1.0 is now a separate JSR.
 Given the discussions we have had in the past related to MVC and
 JAX-RS, I felt it was appropriate to send you this proposal as well.

  Even though it is not part of JAX-RS anymore, if you want to be
 listed as a supporter for MVC 1.0, you can also respond to this
 message.

  Thanks.

 -- Santiago



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

Re: dynamic interceptor insertion

[Paul Benedict]

Most of the time, if not 99% of the time, all I want to do is add an
interceptor before or after some known interceptor. As I've gone on record
before, I want this feature too :-)



Cheers,
Paul


On Wed, Jul 2, 2014 at 7:16 PM, Ken McWilliams ken.mcwilli...@gmail.com
wrote:

 Thank you Lukasz I'll put it on my todo list ;)

 Martin, interceptor stacks are efficient I think the scope struts2 has is
 very good, still it is fun to push boundaries, one of those fun higher
 initiatives would be a Web IDE for struts2. You could dynamically build an
 interceptor stack, and you could step though the stack keeping an eye on
 the action as part of the debug process, (values before and after
 interceptor)...

 So in short no there isn't anything that can't be done with non dynamic
 stacks, but in the name of learning this web framework and making things
 more efficient- being able to dynamically alter the stacks is very
 interesting. At the end the the day the idea was to write out a non-dynamic
 struts.xml for production deployment.


 On Wed, Jul 2, 2014 at 1:12 PM, Lukasz Lenart lukaszlen...@apache.org
 wrote:

  2014-07-02 19:38 GMT+02:00 Ken McWilliams ken.mcwilli...@gmail.com:
   This is somethings I've wanted to do (dynamically change the
 interceptor
   stack), I'm not at a development machine so have not checked the
   plausibility of the following but would like input:
  
   Is it possible to create a custom ActionInvocation object, for this
  purpose?
   Is it possible to essentially recreate the functionality of
   ActionInvocation within an interceptor which then delegates to other
   interceptors?
 
  Hm... yeah, with custom ActionInvocation and ActionProxyFactory should
  do the trick, check the REST Plugin to see what must be implemented to
  create your own ActionInvocation
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 

Re: Do we still sign releases?

[Paul Benedict]

I am going to hit a speed bump here. I haven't signed anything in years and
I don't have the time right now to re-learn what needs to be done. If I
stage the S1 artifacts, can another committer download them and sign them?
Then we can call a vote.


Cheers,
Paul


On Tue, Jun 24, 2014 at 8:55 AM, Paul Benedict pbened...@apache.org wrote:

 Thanks everyone. I am just breaking the rust off of my release manager
 skills. I'll see what I can do.


 Cheers,
 Paul


 On Tue, Jun 24, 2014 at 8:52 AM, Christian Grobmeier grobme...@gmail.com
 wrote:

 Its actually even required by ASF policy to sign releases:
 http://apache.org/dev/release.html#what-must-every-release-contain




 On 24 Jun 2014, at 11:31, Rene Gielen wrote:

  Correct, unsigned releases won't make it to central.

 On 24. Juni 2014 07:06:46 MESZ, Lukasz Lenart lukaszlen...@apache.org
 wrote:

 I think yes
 https://repository.apache.org/content/groups/public/org/
 apache/struts/struts2-core/2.3.16/

 and this is verified by Nexus during Closing repository (I think)

 2014-06-24 3:20 GMT+02:00 Paul Benedict pbened...@apache.org:

 Back in the 1.x days, we signed releases (the jars, zips, etc.). I

 don't

 know if we always did, but I did when I was release manager. Is that
 practice still in force? ... And do we do that for Struts 2 as well?

 Cheers,
 Paul


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


 --
 Sent from my mobile phone


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

Re: Do we still sign releases?

[Paul Benedict]

Thanks everyone. I am just breaking the rust off of my release manager
skills. I'll see what I can do.


Cheers,
Paul


On Tue, Jun 24, 2014 at 8:52 AM, Christian Grobmeier grobme...@gmail.com
wrote:

 Its actually even required by ASF policy to sign releases:
 http://apache.org/dev/release.html#what-must-every-release-contain




 On 24 Jun 2014, at 11:31, Rene Gielen wrote:

  Correct, unsigned releases won't make it to central.

 On 24. Juni 2014 07:06:46 MESZ, Lukasz Lenart lukaszlen...@apache.org
 wrote:

 I think yes
 https://repository.apache.org/content/groups/public/org/
 apache/struts/struts2-core/2.3.16/

 and this is verified by Nexus during Closing repository (I think)

 2014-06-24 3:20 GMT+02:00 Paul Benedict pbened...@apache.org:

 Back in the 1.x days, we signed releases (the jars, zips, etc.). I

 don't

 know if we always did, but I did when I was release manager. Is that
 practice still in force? ... And do we do that for Struts 2 as well?

 Cheers,
 Paul


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


 --
 Sent from my mobile phone


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

Do we still sign releases?

[Paul Benedict]

Back in the 1.x days, we signed releases (the jars, zips, etc.). I don't
know if we always did, but I did when I was release manager. Is that
practice still in force? ... And do we do that for Struts 2 as well?

Cheers,
Paul

Lost JIRA admin rights to STR WW

[Paul Benedict]

Who, so mighty and powerful, can grant me the karma back?

Cheers,
Paul

Re: s:param @value does not accept expressions?

[Paul Benedict]

Christoph, nothing changes in your example; there is no expression to
evaluate.


Cheers,
Paul


On Wed, Jun 18, 2014 at 3:38 AM, Christoph Nenning 
christoph.nenn...@lex-com.net wrote:

 This could make very simple usecases overly complicated.

 E.g. using just a textfield:

 s:textfield name=myActionMember /


 This is already OGNL. And OGNL is used for reading and writing.

 How would you do this with EL (especially the writing part) ?



 Regards,
 Christoph




  That's the pattern I expect. One tag should expose what you need from
  Struts to EL -- the rest of the Struts tags should just be pure EL
 enabled.
 
 
  Cheers,
  Paul
 
 
  On Tue, Jun 17, 2014 at 10:06 AM, Christoph Nenning 
  christoph.nenn...@lex-com.net wrote:
 
   In my JSPs I have interactions with struts all the time so OGNL is
   important for me.
  
   A pattern I use quite often is to get objects via s:set (OGNL) and
   afterwards use them with EL/JSTL.
  
  
  
   Regards,
   Christoph
  
  
  
  
I believe my thoughts are similar. When I code, I explicitly try to
 be
OGNL free in my JSP. There's no reason for me to use OGNL unless I
 am
forced to via interaction with Struts. I do what I can do make sure
 my
   JSP
usage sticks with the EE standard.
   
   
   
   
Cheers,
Paul
   
   
On Tue, Jun 17, 2014 at 9:55 AM, Aaron Johnson
   johnson.aar...@gmail.com
wrote:
   
 EL now supports many functions of OGNL. Would it make sense just
 to
   replace
 OGNL with EL? There doesn't seem to be much of a community around
   updating
 OGNL. The newer versions of EL have improved support for usage
 outside
   of
 the JSP environment. Is it possible to use EL in the other
 templates
 (Velocity, Freemarker, etc)? It is very confusing to have to work
 with
 multiple expression contexts (ValueStack lookups and JSTL) when
   authoring
 JSPs.


 On Mon, Jun 16, 2014 at 11:12 AM, Paul Benedict
 pbened...@apache.org
 wrote:

  Maybe we should have two versions of the tags? One that accepts
 EL
   (and
  never executes OGNL) and another one that does. Quite honestly,
 I
   have no
  use for OGNL inside of JSP.
 
 
  Cheers,
  Paul
 
 
  On Mon, Jun 16, 2014 at 11:05 AM, Paul Benedict
   pbened...@apache.org
  wrote:
 
   That's disappointing that we're crippling the use of these
 tags. I
   just
   want to use EL for single evaluation. I don't need both OGNL
 and
   EL in
 my
   tags -- just EL.
  
  
   Cheers,
   Paul
  
  
   On Mon, Jun 16, 2014 at 10:44 AM, Dave Newton
   davelnew...@gmail.com
   wrote:
  
  
  
 
 http://struts.apache.org/release/2.2.x/docs/why-cant-i-use-jstl-
style-el-expressions-in-struts-tags.html
  
  
   On Mon, Jun 16, 2014 at 11:26 AM, Paul Benedict
   pbened...@apache.org
 
   wrote:
  
Is this a bug? I cannot use an EL expression to set the
 value
   attribute.
I don't understand why such a restriction exists. Thoughts?
   
Cheers,
Paul
   
  
  
  
   --
   e: davelnew...@gmail.com
   m: 908-380-8699
   s: davelnewton_skype
   t: @dave_newton https://twitter.com/dave_newton
   b: Bucky Bits http://buckybits.blogspot.com/
   g: davelnewton https://github.com/davelnewton
   so: Dave Newton 
   http://stackoverflow.com/users/438992/dave-newton
  
  
  
 

  
   This Email was scanned by Sophos Anti Virus
  

 This Email was scanned by Sophos Anti Virus

Re: s:param @value does not accept expressions?

[Paul Benedict]

Given this:
s:textfield name=myActionMember /

The name attribute is a literal, no? So the attribute is simply the value
you provided.


Cheers,
Paul


On Wed, Jun 18, 2014 at 8:55 AM, Christoph Nenning 
christoph.nenn...@lex-com.net wrote:

 
  Christoph, nothing changes in your example; there is no expression to
  evaluate.
 
 

 Really?

 I thought the string myActionMember is an expression which is evaluated
 against ValueStack.


 Regards,
 Christoph




 (on a side note: I will be offline for next 2.5 weeks, otherwise it would
 not be holyday ;)




 
  On Wed, Jun 18, 2014 at 3:38 AM, Christoph Nenning 
  christoph.nenn...@lex-com.net wrote:
 
   This could make very simple usecases overly complicated.
  
   E.g. using just a textfield:
  
   s:textfield name=myActionMember /
  
  
   This is already OGNL. And OGNL is used for reading and writing.
  
   How would you do this with EL (especially the writing part) ?
  
  
  
   Regards,
   Christoph
  
  
  
  
That's the pattern I expect. One tag should expose what you need
 from
Struts to EL -- the rest of the Struts tags should just be pure EL
   enabled.
   
   
Cheers,
Paul
   
   
On Tue, Jun 17, 2014 at 10:06 AM, Christoph Nenning 
christoph.nenn...@lex-com.net wrote:
   
 In my JSPs I have interactions with struts all the time so OGNL is
 important for me.

 A pattern I use quite often is to get objects via s:set (OGNL)
 and
 afterwards use them with EL/JSTL.



 Regards,
 Christoph




  I believe my thoughts are similar. When I code, I explicitly try
 to
   be
  OGNL free in my JSP. There's no reason for me to use OGNL
 unless I
   am
  forced to via interaction with Struts. I do what I can do make
 sure
   my
 JSP
  usage sticks with the EE standard.
 
 
 
 
  Cheers,
  Paul
 
 
  On Tue, Jun 17, 2014 at 9:55 AM, Aaron Johnson
 johnson.aar...@gmail.com
  wrote:
 
   EL now supports many functions of OGNL. Would it make sense
 just
   to
 replace
   OGNL with EL? There doesn't seem to be much of a community
 around
 updating
   OGNL. The newer versions of EL have improved support for usage
   outside
 of
   the JSP environment. Is it possible to use EL in the other
   templates
   (Velocity, Freemarker, etc)? It is very confusing to have to
 work
   with
   multiple expression contexts (ValueStack lookups and JSTL)
 when
 authoring
   JSPs.
  
  
   On Mon, Jun 16, 2014 at 11:12 AM, Paul Benedict
   pbened...@apache.org
   wrote:
  
Maybe we should have two versions of the tags? One that
 accepts
   EL
 (and
never executes OGNL) and another one that does. Quite
 honestly,
   I
 have no
use for OGNL inside of JSP.
   
   
Cheers,
Paul
   
   
On Mon, Jun 16, 2014 at 11:05 AM, Paul Benedict
 pbened...@apache.org
wrote:
   
 That's disappointing that we're crippling the use of these
   tags. I
 just
 want to use EL for single evaluation. I don't need both
 OGNL
   and
 EL in
   my
 tags -- just EL.


 Cheers,
 Paul


 On Mon, Jun 16, 2014 at 10:44 AM, Dave Newton
 davelnew...@gmail.com
 wrote:



   
  
 http://struts.apache.org/release/2.2.x/docs/why-cant-i-use-jstl-
  style-el-expressions-in-struts-tags.html


 On Mon, Jun 16, 2014 at 11:26 AM, Paul Benedict
 pbened...@apache.org
   
 wrote:

  Is this a bug? I cannot use an EL expression to set the
   value
 attribute.
  I don't understand why such a restriction exists.
 Thoughts?
 
  Cheers,
  Paul
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton 
 http://stackoverflow.com/users/438992/dave-newton



   
  

 This Email was scanned by Sophos Anti Virus

  
   This Email was scanned by Sophos Anti Virus
  

 This Email was scanned by Sophos Anti Virus

Re: s:param @value does not accept expressions?

[Paul Benedict]

I believe my thoughts are similar. When I code, I explicitly try to be
OGNL free in my JSP. There's no reason for me to use OGNL unless I am
forced to via interaction with Struts. I do what I can do make sure my JSP
usage sticks with the EE standard.




Cheers,
Paul


On Tue, Jun 17, 2014 at 9:55 AM, Aaron Johnson johnson.aar...@gmail.com
wrote:

 EL now supports many functions of OGNL. Would it make sense just to replace
 OGNL with EL? There doesn't seem to be much of a community around updating
 OGNL. The newer versions of EL have improved support for usage outside of
 the JSP environment. Is it possible to use EL in the other templates
 (Velocity, Freemarker, etc)? It is very confusing to have to work with
 multiple expression contexts (ValueStack lookups and JSTL) when authoring
 JSPs.


 On Mon, Jun 16, 2014 at 11:12 AM, Paul Benedict pbened...@apache.org
 wrote:

  Maybe we should have two versions of the tags? One that accepts EL (and
  never executes OGNL) and another one that does. Quite honestly, I have no
  use for OGNL inside of JSP.
 
 
  Cheers,
  Paul
 
 
  On Mon, Jun 16, 2014 at 11:05 AM, Paul Benedict pbened...@apache.org
  wrote:
 
   That's disappointing that we're crippling the use of these tags. I just
   want to use EL for single evaluation. I don't need both OGNL and EL in
 my
   tags -- just EL.
  
  
   Cheers,
   Paul
  
  
   On Mon, Jun 16, 2014 at 10:44 AM, Dave Newton davelnew...@gmail.com
   wrote:
  
  
  
 
 http://struts.apache.org/release/2.2.x/docs/why-cant-i-use-jstl-style-el-expressions-in-struts-tags.html
  
  
   On Mon, Jun 16, 2014 at 11:26 AM, Paul Benedict pbened...@apache.org
 
   wrote:
  
Is this a bug? I cannot use an EL expression to set the value
   attribute.
I don't understand why such a restriction exists. Thoughts?
   
Cheers,
Paul
   
  
  
  
   --
   e: davelnew...@gmail.com
   m: 908-380-8699
   s: davelnewton_skype
   t: @dave_newton https://twitter.com/dave_newton
   b: Bucky Bits http://buckybits.blogspot.com/
   g: davelnewton https://github.com/davelnewton
   so: Dave Newton http://stackoverflow.com/users/438992/dave-newton
  
  
  
 

Re: s:param @value does not accept expressions?

[Paul Benedict]

That's the pattern I expect. One tag should expose what you need from
Struts to EL -- the rest of the Struts tags should just be pure EL enabled.


Cheers,
Paul


On Tue, Jun 17, 2014 at 10:06 AM, Christoph Nenning 
christoph.nenn...@lex-com.net wrote:

 In my JSPs I have interactions with struts all the time so OGNL is
 important for me.

 A pattern I use quite often is to get objects via s:set (OGNL) and
 afterwards use them with EL/JSTL.



 Regards,
 Christoph




  I believe my thoughts are similar. When I code, I explicitly try to be
  OGNL free in my JSP. There's no reason for me to use OGNL unless I am
  forced to via interaction with Struts. I do what I can do make sure my
 JSP
  usage sticks with the EE standard.
 
 
 
 
  Cheers,
  Paul
 
 
  On Tue, Jun 17, 2014 at 9:55 AM, Aaron Johnson
 johnson.aar...@gmail.com
  wrote:
 
   EL now supports many functions of OGNL. Would it make sense just to
 replace
   OGNL with EL? There doesn't seem to be much of a community around
 updating
   OGNL. The newer versions of EL have improved support for usage outside
 of
   the JSP environment. Is it possible to use EL in the other templates
   (Velocity, Freemarker, etc)? It is very confusing to have to work with
   multiple expression contexts (ValueStack lookups and JSTL) when
 authoring
   JSPs.
  
  
   On Mon, Jun 16, 2014 at 11:12 AM, Paul Benedict pbened...@apache.org
   wrote:
  
Maybe we should have two versions of the tags? One that accepts EL
 (and
never executes OGNL) and another one that does. Quite honestly, I
 have no
use for OGNL inside of JSP.
   
   
Cheers,
Paul
   
   
On Mon, Jun 16, 2014 at 11:05 AM, Paul Benedict
 pbened...@apache.org
wrote:
   
 That's disappointing that we're crippling the use of these tags. I
 just
 want to use EL for single evaluation. I don't need both OGNL and
 EL in
   my
 tags -- just EL.


 Cheers,
 Paul


 On Mon, Jun 16, 2014 at 10:44 AM, Dave Newton
 davelnew...@gmail.com
 wrote:



   
   http://struts.apache.org/release/2.2.x/docs/why-cant-i-use-jstl-
  style-el-expressions-in-struts-tags.html


 On Mon, Jun 16, 2014 at 11:26 AM, Paul Benedict
 pbened...@apache.org
   
 wrote:

  Is this a bug? I cannot use an EL expression to set the value
 attribute.
  I don't understand why such a restriction exists. Thoughts?
 
  Cheers,
  Paul
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton 
 http://stackoverflow.com/users/438992/dave-newton



   
  

 This Email was scanned by Sophos Anti Virus

s:param @value does not accept expressions?

[Paul Benedict]

Is this a bug? I cannot use an EL expression to set the value attribute.
I don't understand why such a restriction exists. Thoughts?

Cheers,
Paul

Re: s:param @value does not accept expressions?

[Paul Benedict]

That's disappointing that we're crippling the use of these tags. I just
want to use EL for single evaluation. I don't need both OGNL and EL in my
tags -- just EL.


Cheers,
Paul


On Mon, Jun 16, 2014 at 10:44 AM, Dave Newton davelnew...@gmail.com wrote:


 http://struts.apache.org/release/2.2.x/docs/why-cant-i-use-jstl-style-el-expressions-in-struts-tags.html


 On Mon, Jun 16, 2014 at 11:26 AM, Paul Benedict pbened...@apache.org
 wrote:

  Is this a bug? I cannot use an EL expression to set the value
 attribute.
  I don't understand why such a restriction exists. Thoughts?
 
  Cheers,
  Paul
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton http://stackoverflow.com/users/438992/dave-newton

Re: s:param @value does not accept expressions?

[Paul Benedict]

Maybe we should have two versions of the tags? One that accepts EL (and
never executes OGNL) and another one that does. Quite honestly, I have no
use for OGNL inside of JSP.


Cheers,
Paul


On Mon, Jun 16, 2014 at 11:05 AM, Paul Benedict pbened...@apache.org
wrote:

 That's disappointing that we're crippling the use of these tags. I just
 want to use EL for single evaluation. I don't need both OGNL and EL in my
 tags -- just EL.


 Cheers,
 Paul


 On Mon, Jun 16, 2014 at 10:44 AM, Dave Newton davelnew...@gmail.com
 wrote:


 http://struts.apache.org/release/2.2.x/docs/why-cant-i-use-jstl-style-el-expressions-in-struts-tags.html


 On Mon, Jun 16, 2014 at 11:26 AM, Paul Benedict pbened...@apache.org
 wrote:

  Is this a bug? I cannot use an EL expression to set the value
 attribute.
  I don't understand why such a restriction exists. Thoughts?
 
  Cheers,
  Paul
 



 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton http://stackoverflow.com/users/438992/dave-newton

Re: Re: Less boilerplate in code

[Paul Benedict]

Christoph, I don't think the problem is in using SLF4J in itself. The
problem is it's not appropriate to switch logging frameworks in a patch
release. Adding a dependency is going to cause major upgrade headaches --
especially logging dependencies. If anything is done, this will be on the
2.5 or 3.0 radar.


Cheers,
Paul


On Fri, May 16, 2014 at 2:46 AM, Christoph Nenning 
christoph.nenn...@lex-com.net wrote:

   Yes, we could use Onyx's interface mechanism, but I think SLF4j's is
   probably more stable and definitely more supported.  So I'd probably
   recommend that we extract the SLF4j support object and use it directly
 (or
   at least make it the default).  If it's something that you're
 interested
   in, I'd have to fill out the forms to become a committer on Struts.
 Where
   would I find that information?
 
  I'm not sure if this the right move, switching to SLF4j over our
  custom solution. Please can we explore this topic a bit?
 


 Here are my 2 cent about logging:


 Recently it seems to be a best practice for libraries to depent on slf4j.

 The advanced expressions of Onyx remind me of OGNL. It would feel more
 struts style if expressions could be used for logging.


 As long as the application can choose the logging impl, and struts
 messages are appearing, I don't care what api struts uses.
 I'm also fine with the current struts logging wrapper.


 Regards,
 Christoph

 This Email was scanned by Sophos Anti Virus

Re: Merging XWork into Struts Core

[Paul Benedict]

Instead of merging, perhaps what you really need to do is modify the XWork
API to make it more extensible. It does seem a bit crazy you need to
constantly change both. XWork should be as un-struts as possible, I think.


Cheers,
Paul


On Fri, May 9, 2014 at 1:00 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 Hi,

 I'm considering merging XWork code base into Struts Core module. There
 is a lot problems when I want to write some extension points (with
 @Inject and BeanSelectionProvider) and when the same extension point
 must be defined for class from XWork - I have to translate constants
 to keep separation of concerns :\

 Do you have any objections?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: Merging XWork into Struts Core

[Paul Benedict]

On Sun, May 11, 2014 at 6:10 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 Basically we have two cores - and what I want to do is to merge them
 to be the real core (not divided), thus should also remove some clumsy
 code which exists in XWork-Core just to satisfy Struts-Core's needs.
 And also reduce some duplication like ActionContext and
 ServletActionContext.


Agreed. We don't need 2 cores. The abstraction is quite unnecessary since
XWork is already bound to Struts.


 Having one core with support of extensibility, the next step will be
 extracting some plugins, ie. struts-jsp-plugin, struts-velocity-plugin
 and so on, to finally have Core which handles only Servlet
 Request/Response and the rest can be extended/handled by plugins. To
 be more precise, when you build REST app based on S2, you don't need
 support for JSPs or any other view layer, you just want to have a
 light REST layer.

 Paul's idea about moving stuff from S2 to XW is also quite good but
 I'm not sure if it is doable as all plugins depend on S2 not on XW -
 in most cases XW is invisible for plugins. Also the whole plugin
 support logic exists in S2, XW doesn't support plugins and even
 extension points. It'd better perform XW to S2 merge IMHO.


If we get rid of this S2/XW dual-core problem, we will have people actually
be able to rely simply on S2. I see what you're doing is a necessary first
step to get to a true S3 API. Perhaps when I mentioned moving S2 in XW, I
should have spoken more clearly about my intent. XW will be consumed into
S2 and be seamless.

Paul

Re: Merging XWork into Struts Core

[Paul Benedict]

However, on second thoughts, I would like to know the purpose of keeping
XWork separate. Was it to allow other clients besides Struts? And do any of
those exist?

My line of questioning is really about the future. If we want to clearly
separate out a Struts API and Struts Core Implementation, we should think
about where XWork fits into there. Is XWork really part of the Struts API?
Because maybe more of Struts needs to move into XWork than the other way
around.


Cheers,
Paul


On Sat, May 10, 2014 at 6:15 PM, Paul Benedict pbened...@apache.org wrote:

 Instead of merging, perhaps what you really need to do is modify the XWork
 API to make it more extensible. It does seem a bit crazy you need to
 constantly change both. XWork should be as un-struts as possible, I think.


 Cheers,
 Paul


 On Fri, May 9, 2014 at 1:00 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 Hi,

 I'm considering merging XWork code base into Struts Core module. There
 is a lot problems when I want to write some extension points (with
 @Inject and BeanSelectionProvider) and when the same extension point
 must be defined for class from XWork - I have to translate constants
 to keep separation of concerns :\

 Do you have any objections?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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

Re: [struts-dev] Re: Ultimate way to solve problems with Ognl

[Paul Benedict]

On Sun, May 4, 2014 at 12:57 PM, Jason Pyeron jpye...@pdinc.us wrote:

 This begs the question (only spent a minute reviewing) should the call to
 com.sun.GoingToHackYourBox be a silent denial or a big stacktrace error?


I don't think we want a stack trace for user input. That is a vector for a
DoS attack because admins will typically log error stack traces. We don't
want to give users the power to create them at will. So my suggestion is
that illegal patterns, if detected, are tossed away in silence.

Cheers,
Paul

Re: [VOTE][FASTTRACK] Struts 2.3.16.3

[Paul Benedict]

+1


Cheers,
Paul


On Fri, May 2, 2014 at 4:16 PM, Don Brown mr...@apache.org wrote:

 +1


 On Fri, May 2, 2014 at 1:58 PM, Dave Newton davelnew...@gmail.com wrote:

  +1
  On May 2, 2014 3:52 PM, Lukasz Lenart lukaszlen...@apache.org wrote:
 
   The Struts 2.3.16.3 test build is now available. It includes the
   latest security patch which fixes one possible vulnerabilities:
   - Extends excluded params in CookieInterceptor to avoid manipulation
   of Struts' internals
  
   For details and the rationale behind these changes, please consult the
   corresponding security bulletins:
   * https://cwiki.apache.org/confluence/display/WW/S2-022
  
   Release notes:
   * [
 https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.16.3
  ]
  
   Distribution:
   * [http://people.apache.org/builds/struts/2.3.16.3/]
  
   Maven 2 staging repository:
   * [
  
 https://repository.apache.org/content/repositories/orgapachestruts-1003/
  ]
  
   Once you have had a chance to review the test build, please respond
   with a vote on its quality:
  
   [ ] Leave at test build
   [ ] Alpha
   [ ] Beta
   [ ] General Availability (GA)
  
   Everyone who has tested the build is invited to vote. Votes by PMC
   members are considered binding. A vote passes if there are at least
   three binding +1s and more +1s than -1s.
  
   This is a fast-track release vote. If we have a positive vote after
   24 hours (at least three binding +1s and more +1s than -1s),  the
   release may be submitted for mirroring and announced to the usual
   channels.
  
   The website download link will include the mirroring timestamp
   parameter [1], which limits the selection of mirrors to those that
   have been refreshed since the indicated time and date. (After 24
   hours, we *must* remove the timestamp parameter from the website link,
   to avoid unnecessary server load.) In the case of a fast-track
   release, the email announcement will not link directly to
   download.cgi, but to downloads.html, so that we can control use of
   the timestamp parameter.
  
   [1] http://apache.org/dev/mirrors.html#use
  
   - The Apache Struts group.
  
  
   Regards
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
   For additional commands, e-mail: dev-h...@struts.apache.org
  
  
 

Re: [VOTE][FASTTRACK] Struts 2.3.16.2

[Paul Benedict]

+1


On Fri, Apr 25, 2014 at 3:59 PM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 +1 GA (binding)

 2014-04-24 23:13 GMT+02:00 Lukasz Lenart lukaszlen...@apache.org:
  The Struts 2.3.16.2 test build is now available. It includes the
  latest security patch which fixes two possible vulnerabilities:
  - Improves excluded params to avoid ClassLoader manipulation via
  ParametersInterceptor
  - Adds excluded params to CookieInterceptor to avoid ClassLoader
  manipulation when the interceptors is configured to accept all cookie
  names (wildcard matching via *)
 
  For details and the rationale behind these changes, please consult the
  corresponding security bulletins:
  * https://cwiki.apache.org/confluence/display/WW/S2-021
 
  Release notes:
  * [https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.16.2
 ]
 
  Distribution:
  * [http://people.apache.org/builds/struts/2.3.16.2/]
 
  Maven 2 staging repository:
  * [
 https://repository.apache.org/content/repositories/orgapachestruts-1002/]
 
  Once you have had a chance to review the test build, please respond
  with a vote on its quality:
 
  [ ] Leave at test build
  [ ] Alpha
  [ ] Beta
  [ ] General Availability (GA)
 
  Everyone who has tested the build is invited to vote. Votes by PMC
  members are considered binding. A vote passes if there are at least
  three binding +1s and more +1s than -1s.
 
  This is a fast-track release vote. If we have a positive vote after
  24 hours (at least three binding +1s and more +1s than -1s),  the
  release may be submitted for mirroring and announced to the usual
  channels.
 
  The website download link will include the mirroring timestamp
  parameter [1], which limits the selection of mirrors to those that
  have been refreshed since the indicated time and date. (After 24
  hours, we *must* remove the timestamp parameter from the website link,
  to avoid unnecessary server load.) In the case of a fast-track
  release, the email announcement will not link directly to
  download.cgi, but to downloads.html, so that we can control use of
  the timestamp parameter.
 
  [1] http://apache.org/dev/mirrors.html#use
 
  - The Apache Struts group.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: Let's introduce a Maven BOM POM

[Paul Benedict]

My proposal has nothing to do with Spring. My email was to show Spring uses
this Maven pattern -- and so does log4j2, btw.


On Tue, Apr 15, 2014 at 6:12 AM, Martin Gainty mgai...@hotmail.com wrote:

 the BOM Version would auto-assign which spring-framework artifacts ?
 spring-core?
 spring-beans?
 spring-context?

 spring-web?

 spring-test?


 what about AOP?
 How would additional spring artifacts be included/excluded in the BOM
 umbrella?


 ideas on where the source might be ?

 Thanks
 Martin-



  From: lukaszlen...@apache.org
  Date: Tue, 15 Apr 2014 12:25:59 +0200
  Subject: Re: Let's introduce a Maven BOM POM
  To: dev@struts.apache.org
 
  Patch is always welcome :-)
 
  But I think we need a proper documentation how to setup a Maven
  project first - we have got some comment about that and introducing
  BOM doesn't help those newbies ;-)
 
  2014-04-14 23:23 GMT+02:00 Paul Benedict pbened...@apache.org:
   Quite frankly, I am tired of repeating Maven version numbers and/or
   property substitutions in my Struts 2 applications. I just want to
 import
   the right POM and forgo all the version tricks.
  
   See my inspiration here:
  
 http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/html/overview.html#overview-maven-bom
  
   Thoughts?
  
   --
   Cheers,
   Paul
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 





-- 
Cheers,
Paul

Re: Let's introduce a Maven BOM POM

[Paul Benedict]

If you're asking about the source of the POM, I haven't written that yet.


On Tue, Apr 15, 2014 at 10:24 AM, Martin Gainty mgai...@hotmail.com wrote:

 understood...any idea on where the source might be?


 M-




  Date: Tue, 15 Apr 2014 08:34:43 -0500
  Subject: Re: Let's introduce a Maven BOM POM
  From: pbened...@apache.org
  To: dev@struts.apache.org
 
  My proposal has nothing to do with Spring. My email was to show Spring
 uses
  this Maven pattern -- and so does log4j2, btw.
 
 
  On Tue, Apr 15, 2014 at 6:12 AM, Martin Gainty mgai...@hotmail.com
 wrote:
 
   the BOM Version would auto-assign which spring-framework artifacts ?
   spring-core?
   spring-beans?
   spring-context?
  
   spring-web?
  
   spring-test?
  
  
   what about AOP?
   How would additional spring artifacts be included/excluded in the BOM
   umbrella?
  
  
   ideas on where the source might be ?
  
   Thanks
   Martin-
  
  
  
From: lukaszlen...@apache.org
Date: Tue, 15 Apr 2014 12:25:59 +0200
Subject: Re: Let's introduce a Maven BOM POM
To: dev@struts.apache.org
   
Patch is always welcome :-)
   
But I think we need a proper documentation how to setup a Maven
project first - we have got some comment about that and introducing
BOM doesn't help those newbies ;-)
   
2014-04-14 23:23 GMT+02:00 Paul Benedict pbened...@apache.org:
 Quite frankly, I am tired of repeating Maven version numbers and/or
 property substitutions in my Struts 2 applications. I just want to
   import
 the right POM and forgo all the version tricks.

 See my inspiration here:

  
 http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/html/overview.html#overview-maven-bom

 Thoughts?

 --
 Cheers,
 Paul
   
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
  
  
 
 
 
  --
  Cheers,
  Paul





-- 
Cheers,
Paul

Re: Let's introduce a Maven BOM POM

[Paul Benedict]

You can see Spring's BOM POM here:
http://search.maven.org/#artifactdetails|net.anthavio.maven|spring-framework-bom|4.0.3.RELEASE|pom

In essence, it's simply a dependencyManagement section with all the
framework jars set to the same version.


On Tue, Apr 15, 2014 at 11:17 AM, Martin Gainty mgai...@hotmail.com wrote:

 I too would very much like to find a way to lockdown the version



 so to find how spring-framework-bom works..I went to github Spring repo
 and found

 https://github.com/spring-projects/spring-framework/tree/master/spring-framework-bom


 But there is no source and there is no pom?

 Would you feel comfortable writing this implementation from scratch?

 Martin






  Date: Tue, 15 Apr 2014 10:28:32 -0500
  Subject: Re: Let's introduce a Maven BOM POM
  From: pbened...@apache.org
  To: dev@struts.apache.org
 
  If you're asking about the source of the POM, I haven't written that yet.
 
 
  On Tue, Apr 15, 2014 at 10:24 AM, Martin Gainty mgai...@hotmail.com
 wrote:
 
   understood...any idea on where the source might be?
  
  
   M-
  
  
  
  
Date: Tue, 15 Apr 2014 08:34:43 -0500
Subject: Re: Let's introduce a Maven BOM POM
From: pbened...@apache.org
To: dev@struts.apache.org
   
My proposal has nothing to do with Spring. My email was to show
 Spring
   uses
this Maven pattern -- and so does log4j2, btw.
   
   
On Tue, Apr 15, 2014 at 6:12 AM, Martin Gainty mgai...@hotmail.com
   wrote:
   
 the BOM Version would auto-assign which spring-framework artifacts
 ?
 spring-core?
 spring-beans?
 spring-context?

 spring-web?

 spring-test?


 what about AOP?
 How would additional spring artifacts be included/excluded in the
 BOM
 umbrella?


 ideas on where the source might be ?

 Thanks
 Martin-



  From: lukaszlen...@apache.org
  Date: Tue, 15 Apr 2014 12:25:59 +0200
  Subject: Re: Let's introduce a Maven BOM POM
  To: dev@struts.apache.org
 
  Patch is always welcome :-)
 
  But I think we need a proper documentation how to setup a Maven
  project first - we have got some comment about that and
 introducing
  BOM doesn't help those newbies ;-)
 
  2014-04-14 23:23 GMT+02:00 Paul Benedict pbened...@apache.org:
   Quite frankly, I am tired of repeating Maven version numbers
 and/or
   property substitutions in my Struts 2 applications. I just
 want to
 import
   the right POM and forgo all the version tricks.
  
   See my inspiration here:
  

  
 http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/html/overview.html#overview-maven-bom
  
   Thoughts?
  
   --
   Cheers,
   Paul
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 


   
   
   
--
Cheers,
Paul
  
 
 
 
 
  --
  Cheers,
  Paul





-- 
Cheers,
Paul

Let's introduce a Maven BOM POM

[Paul Benedict]

Quite frankly, I am tired of repeating Maven version numbers and/or
property substitutions in my Struts 2 applications. I just want to import
the right POM and forgo all the version tricks.

See my inspiration here:
http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/html/overview.html#overview-maven-bom

Thoughts?

-- 
Cheers,
Paul

Re: Param names with spaces

[Paul Benedict]

Spaces cannot exist for names of JavaBean properties. It doesn't make sense
to have those.


On Thu, Mar 27, 2014 at 1:54 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 Hi,

 I have applied patch attached to WW-4250 [1] to support Chinese
 characters as param names, but I figured out that I forgot to test
 that patch. After launching ParametersInterceptorTest just one test
 failed - testParametersWithSpacesInTheName:

 public void testParametersWithSpacesInTheName() throws Exception {
 MapString, Object params = new HashMapString, Object();
 params.put(theProtectedMap['p0 p1'], test1);
 params.put(theProtectedMap['p0p1 '], test2);
 params.put(theProtectedMap[' p0p1 '], test3);
 params.put(theProtectedMap[' p0 p1 '], test4);

 HashMapString, Object extraContext = new HashMapString,
 Object();
 extraContext.put(ActionContext.PARAMETERS, params);

 ActionProxy proxy = actionProxyFactory.createActionProxy(,
 MockConfigurationProvider.PARAM_INTERCEPTOR_ACTION_NAME, null,
 extraContext);
 proxy.execute();
 MapString, String existingMap = ((SimpleAction)
 proxy.getAction()).getTheProtectedMap();
 assertEquals(0, existingMap.size());
 }

 I was trying to investigate why we removed support for spaces in param
 names and just found this [2] - I cannot recall what it was :/ Even
 checking the log [3] I'm not sure what was the reason - I assume
 because of S2-008 [4]. Any thoughts?

 [1] https://issues.apache.org/jira/browse/WW-4250
 [2] https://svn.apache.org/viewvc?view=revisionrevision=1225038
 [3]
 https://svn.apache.org/viewvc/struts/struts2/trunk/xwork-core/src/test/java/com/opensymphony/xwork2/interceptor/ParametersInterceptorTest.java?view=logpathrev=1558168
 [4] https://cwiki.apache.org/confluence/display/WW/S2-008


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: New logo

[Paul Benedict]

I think the website looks great with the new design and logo.


On Fri, Mar 21, 2014 at 8:11 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 Camel cased version
 https://copy.com/jC4OWepdqrvP

 2014-03-21 12:59 GMT+01:00 Lukasz Lenart lukaszlen...@apache.org:
  She's working on new layout, first attempt:
 
  https://copy.com/Ly91R3KAkPCm
  https://copy.com/9gghodFkEJmr
 
  About CamelCase - hm... good question, I also like that - will ask her
 ;-)
 
  2014-03-19 16:32 GMT+01:00 Rene Gielen gie...@it-neering.net:
  By sudden I realized I forgot to comment so far - shame on me!
 
  Logo image idea / execution: fabulous
  Color scheme: 3rd ++, 2nd +
  Font: Yet undecided. My gut fav is 2nd, but I also agree with Lukasz
  that Aleo (1st) is classy.
 
  Is there a consensus about all uppercase writing? Am I too traditional
  by considering good'ol upper+lower as well? :)
 
  Anyway - great job, and a huge thanks to you guys!
 
  - René
 
  Am 07.03.14 15:53, schrieb Lukasz Lenart:
  New colors https://copy.com/mewPAFa0GuQo and designer's answer:
 
  Several blue variants to be considered. As well as several fonts.
 
  I do not agree about the font - I like it very much, it is modern -
  not all serifs are outdated.
 
  The font is called Aleo, you can read some here
  http://fontfabric.com/aleo-free-font/
 
 
  -
  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




-- 
Cheers,
Paul

Re: [GitHub] struts pull request: Don't pass ServletContext

[Paul Benedict]

Wouldn't it make more sense for github requests to be sent to the commits
list than dev?


On Wed, Feb 19, 2014 at 12:20 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 The final test

 2014-02-18 16:09 GMT+01:00 Humbedooh g...@git.apache.org:
  Github user Humbedooh commented on the pull request:
 
  https://github.com/apache/struts/pull/1#issuecomment-35393131
 
  Testing GitHub integration, please ignore :)
 
 
  ---
  If your project is set up for it, you can reply to this email and have
 your
  reply appear on GitHub as well. To do so, please top-post your response.
  If your project does not have this feature enabled and wishes so, or if
 the
  feature is enabled but not working, please contact infrastructure at
  infrastruct...@apache.org or file a JIRA ticket with INFRA.
  ---
 
  -
  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




-- 
Cheers,
Paul

Re: HTTP PUT request with message body

[Paul Benedict]

Dong, how are you issuing your HTTP PUT request? You can't do it through
HTML since HTML does not support those verbs. Are you doing it in
Javascript?


On Tue, Feb 11, 2014 at 5:06 AM, Dave Newton davelnew...@gmail.com wrote:

 My initial guess would be because the additional HTTP verbs besides get and
 post don't usually come from browsers.
  On Feb 11, 2014 2:12 AM, Dong Qiu dong...@gmail.com wrote:

  Hi,
 
  When I do a HTTP PUT request with message body. eg. x=12. It does not
 seem
  to be put into the requestParamters. (e.g cannot find the x=12 entry in
  request.getParameterMap )
 
  I was told to try REST plugin. However, Just wondering why parsing the
 PUT
  request message body and putting the entries into the paramterMap is not
  supported in Struts2.3.16 core action?
 
  Thank you
 




-- 
Cheers,
Paul

Re: HTTP PUT request with message body

[Paul Benedict]

Here's the reason why (unrelated to Struts):
https://jira.springsource.org/browse/SPR-7030


On Tue, Feb 11, 2014 at 3:41 PM, Dong Qiu dong...@gmail.com wrote:

 I issue the PUT request using Jquery's.

 $.ajax({
   url: '/test-action/99',
   type: 'PUT',
   data: name=test,
   contentType : application/x-www-form-urlencoded,
   success: function(data) {
 alert('...');
   }
 });

 (If I change PUT to POST, I can retrieve the name=test in test-action)

 I am using Jboss 7.0.2. Guess that http put method is not enabled in its
 Tomcat by default, so the name=test
 is not put into the requestParamterMap by the container and struts2 core
 actions do not handle parsing the msg body and put it into the Map for the
 PUT req.

 Thank you




 On Tue, Feb 11, 2014 at 7:19 AM, Paul Benedict pbened...@apache.org
 wrote:

  Dong, how are you issuing your HTTP PUT request? You can't do it through
  HTML since HTML does not support those verbs. Are you doing it in
  Javascript?
 
 
  On Tue, Feb 11, 2014 at 5:06 AM, Dave Newton davelnew...@gmail.com
  wrote:
 
   My initial guess would be because the additional HTTP verbs besides get
  and
   post don't usually come from browsers.
On Feb 11, 2014 2:12 AM, Dong Qiu dong...@gmail.com wrote:
  
Hi,
   
When I do a HTTP PUT request with message body. eg. x=12. It does not
   seem
to be put into the requestParamters. (e.g cannot find the x=12 entry
 in
request.getParameterMap )
   
I was told to try REST plugin. However, Just wondering why parsing
 the
   PUT
request message body and putting the entries into the paramterMap is
  not
supported in Struts2.3.16 core action?
   
Thank you
   
  
 
 
 
  --
  Cheers,
  Paul
 



 --
 Dong Qiu




-- 
Cheers,
Paul

Re: Svn to Git migration

[Paul Benedict]

The only problem is that links to the old Struts source are broken. The
attic is traditionally been reserved for dead projects. We're not in that
situation. All we need is a read-only lock.


On Thu, Jan 16, 2014 at 1:24 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 I still don't get it - what is the problem with moving the source to
 attic? It isn't valid source code any more - what is valid are the
 tags (/struts2/tags/STRUTS_2_3_8) but I doubt that anybody uses them
 (except us).

 Wicket - very good example, I didn't know it isn't valid source code
 anymore (I have been checking it few times how they solved issues with
 SvnPubSub - I was waisting my time). There should be huge banner -
 MOVED-TO-GIT-DONT-USE-THIS-SOURCE!

 So, I opt to leave the source in attic and react if users start
 complaining about that.


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2014/1/15 Rene Gielen rene.gie...@gmail.com:
  I wonder what the downside is to just put svn subtrees in question into
  read only mode compared to moving them to attic. As for placing a
  prominent notice, such as MOVED-TO-GIT-README.txt, it would be useful to
  our users in either case.
 
  Having a look at wicket, they just left svn at a point in time, keeping
  everything in place (presumably read-only):
  http://svn.apache.org/repos/asf/wicket/
  While I would wish to find a prominent README here as described above, a
  see a case for not breaking things that are not in our hand. In the
  early days of Weld / CDI e.g., I desperately needed trunk level builds
  that were not published yet. For that reason I did a
  checkout-and-build-dependency step in the maven bootstrap phase of my
  build. While this was clearly violating the reproducible build
  principle, I could live with this trade-off since the features I needed
  were additions unlikely to go away. To some extent reproducibility may
  be seen as that if you would checkout some project published a few years
  ago, it would build without some early failures before javac even kicks
  in. I know this is a corner case, but it would suffer from repo contents
  (from which a checkout would be done during my build) being moved away.
 
  Regarding Apache policies, there are a few around that might help
  finding a decision:
  - Apache requires us to run on our own infrastructure for a single
  reason: provide resources that will last for ages at the same place.
  That is why we would not want to do canonical hosting of projects
  externally, such as on GitHub - maybe it shuts down tomorrow? Unlikely,
  yes. On the other hand, we have seen such things happen: tr.im URL
  shortener was popular by it's time, but then money ran out. Each mailing
  list posting containing tr.im URL you will look up in archive render
  useless due to the URLs cannot be resolved any more. That's why Apache
  even promotes their own URL shortener, http://s.apache.org.
  - Dead projects, that is projects with dead communities, go to the Attic
  meta project, including move of svn resources. While this has more to do
  with having a meta-PMC for keeping oversight even if the owning PMC is
  dead, it indeed involves moving of svn resources - AFAIK the only
  process where such move happens as a part of an Apache policy. So moving
  something to something called attic makes me shout out I'm not dead
  yet! spontaneously :)
 
  So far, I would really tend to go into read-only mode with notices
  placed in svn rather than to move things away. If there are good
  arguments for the move I have missed so far, I would of course happily
  switch my position on that topic.
 
  Just my 0.02$
  - René
 
  Am 15.01.14 20:54, schrieb Lukasz Lenart:
  2014/1/15 Paul Benedict pbened...@apache.org:
  The published POMs should all have a link to the SCM URL. We shouldn't
 move
  to the attic so those links can stay valid.
 
  Ok, what is wrong if they become invalid? Maybe people start thinking
  about migration :-)
 
  And what do you mean cut the wire? Is that an Apache directive to
 stop
  people from going to svn?
 
  I don't know how it is in English - when child is born, connection
  with mother is cut :-) The same here, at some point we must strictly
  say - sorry guys!
 
  It was mentioned as a good practise from other projects which migrated
 to Git.
 
 
  Regards
 
 
 
  -
  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




-- 
Cheers,
Paul

Re: Possible Bug When Using default-action-ref?

[Paul Benedict]

The string being shown in the email is: amp;amp;

So that means the output should be a literal amp; but why? Why would you
want to output that? I think the error is the extra amp;


On Thu, Jan 16, 2014 at 12:39 PM, Chris Pratt thechrispr...@gmail.comwrote:

 It's apparently being double-XML-encoded.  The first time changes  to
 amp;, the second time changes amp; to amp;amp;.  I'd look at the code
 where default-action-ref is used, it must be XML-encoding the URL that was
 formerly XML-encoded.  Just my 2 cents.
   (*Chris*)


 On Thu, Jan 16, 2014 at 5:45 AM, bphill...@ku.edu bphill...@ku.edu
 wrote:

  I'm working on JIRA issue https://issues.apache.org/jira/browse/WW-4259.
   A
  user reported that the action attribute of the form tag rendered by the
  s:from tag included a duplicate amp (e.g. form id=testform
  name=testform
  action=/formtest/TestPage.action?field1=111amp;amp;field2=222
  method=post
 
  At first I could not duplicate the problem the user reported.
 
  Then the user provided a Maven example project and running that project I
  could duplicate the problem.
 
  But I was wondering why I could not duplicate the problem in my own
 example
  project.
 
  I finally figured out that the user's project included a
 default-action-ref
  statement in his struts.xml when mine did not.  Adding a
 default-action-ref
  to my example enabled me to duplicate the user's problem.
 
  What is strange is if you leave out the default-action-ref statement in
 the
  struts.xml the s:form tag is rendered as form id=testform
  name=testform
  action=TestPage.action method=post
 
  but with the default-action-ref statement in struts.xml the s:form tag is
  rendered as form id=testform name=testform
  action=/formtest/TestPage.action?field1=111amp;amp;field2=222
  method=post
 
  Anyone have some ideas of why the default-action-ref statement would
 cause
  such as difference and if it should cause such a difference?
 
  The example project submitted by the user is attached to the JIRA ticket.
  It may be helpful to read the comments int he JIRA ticket.
 
  Thanks for the help.  I'm still new to the Struts 2 source code so if you
  could point me in the right direction that would be great.
 
  Bruce
 
 
 
 
 
 
  --
  View this message in context:
 
 http://struts.1045723.n5.nabble.com/Possible-Bug-When-Using-default-action-ref-tp5715093.html
  Sent from the Struts - Dev mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 




-- 
Cheers,
Paul

Re: Svn to Git migration

[Paul Benedict]

The published POMs should all have a link to the SCM URL. We shouldn't move
to the attic so those links can stay valid.

And what do you mean cut the wire? Is that an Apache directive to stop
people from going to svn?


On Wed, Jan 15, 2014 at 2:39 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 We suppose to cut off the wire - as moving the repos showed that we
 still have a problem with DTDs. And published POMs shouldn't be a
 problem, there are links in ciManagement section only or do I miss
 something?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2014/1/14 Paul Benedict pbened...@apache.org:
  No, please don't move things to the attic. We published POMs and other
  links to the repository. We should just make it read-only.
 
 
  On Tue, Jan 14, 2014 at 1:23 PM, Johannes Geppert joh...@gmail.com
 wrote:
 
  Looks good to me!
 
  Thanks Łukasz for taking care of this migration.
 
  Johannes
 
  #
  web: http://www.jgeppert.com
  twitter: http://twitter.com/jogep
 
 
  2014/1/14 Lukasz Lenart lukaszlen...@apache.org
 
   Guys,
   can you review cleanup I have performed?
  
   https://svn.apache.org/repos/asf/struts/
   https://svn.apache.org/repos/asf/struts/attic/
  
   what else I should move to attic as well
  
  
   Regards
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
  
   2014/1/14 Lukasz Lenart lukaszlen...@apache.org:
I think it isn't needed. I'm going to move everything to 'attic'
folder to be backed up and create README about migration
   
2014/1/14 Paul Benedict pbened...@apache.org:
Can you request to turn it read only?
On Jan 14, 2014 11:58 AM, Lukasz Lenart lukaszlen...@apache.org
 
   wrote:
   
Migration to Git is almost done! Please DON'T use Subversion
 anymore!
   
https://issues.apache.org/jira/browse/INFRA-7174
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
   
2014/1/9 Lukasz Lenart lukaszlen...@apache.org:
 Time to move forward

 https://issues.apache.org/jira/browse/INFRA-7174

 2013/12/10 Christian Grobmeier grobme...@gmail.com:
 On 10 Dec 2013, at 7:55, Lukasz Lenart wrote:

 I'm going postpone transition to Git as we must straighten
 site
 building first! Right now it's a real pain in the a.. and it
  takes
 ages to update site after release. Not saying about other
 mirror
 problems with this whole SvnPubSub crap :\


 Oh ok. :-|

 I am a bit undecided on how we approach the website (again).





 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2013/12/6 Dave Newton davelnew...@gmail.com:

 Correct; pull requests are a github thing.

 And they're nice (usually).


 On Fri, Dec 6, 2013 at 12:09 PM, Christian Grobmeier
 grobme...@gmail.comwrote:

 On 6 Dec 2013, at 15:19, Lukasz Lenart wrote:

 2013/12/6 Christian Grobmeier grobme...@gmail.com:


 On 6 Dec 2013, at 8:11, Lukasz Lenart wrote:

 Do you know if git at Apache supports Pull Requests
 between
branches?

 I've started working like that some time ago and it's
  awesome
feature
 :-)


 Honestly I don't know :-)

 I mean you can merge between branches easily. Is that what
  you
mean?


 Not exactly, in GitHub you can prepare a Pull Request
 between
 different branches in the same repo - you don't have to
 fork
  the
repo
 at all. So you'll see the PR on issues list and you can
  comment,
 change the code and so on, before merging it to
 mater/develop.

 But I think it's pure GitHub functionality not really
 related
   to git
 itself.


 I don't know for sure, but I agree, its most likely a github
   feature.
 I think something like gitlabhq might be able to do the
 same:
 https://github.com/gitlabhq/gitlabhq
 But i have not heard if this is going to live at ASF infra


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/


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



 ---
 http://www.grobmeier.de
 @grobmeier
 GPG: 0xA5CC90DB


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




 --
 e: davelnew...@gmail.com
 m: 908-380-8699
 s: davelnewton_skype
 t: @dave_newton https://twitter.com/dave_newton
 b: Bucky Bits http://buckybits.blogspot.com/
 g: davelnewton https://github.com/davelnewton
 so: Dave Newton 
   http://stackoverflow.com

Re: Svn to Git migration

[Paul Benedict]

Can you request to turn it read only?
On Jan 14, 2014 11:58 AM, Lukasz Lenart lukaszlen...@apache.org wrote:

 Migration to Git is almost done! Please DON'T use Subversion anymore!

 https://issues.apache.org/jira/browse/INFRA-7174


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2014/1/9 Lukasz Lenart lukaszlen...@apache.org:
  Time to move forward
 
  https://issues.apache.org/jira/browse/INFRA-7174
 
  2013/12/10 Christian Grobmeier grobme...@gmail.com:
  On 10 Dec 2013, at 7:55, Lukasz Lenart wrote:
 
  I'm going postpone transition to Git as we must straighten site
  building first! Right now it's a real pain in the a.. and it takes
  ages to update site after release. Not saying about other mirror
  problems with this whole SvnPubSub crap :\
 
 
  Oh ok. :-|
 
  I am a bit undecided on how we approach the website (again).
 
 
 
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/12/6 Dave Newton davelnew...@gmail.com:
 
  Correct; pull requests are a github thing.
 
  And they're nice (usually).
 
 
  On Fri, Dec 6, 2013 at 12:09 PM, Christian Grobmeier
  grobme...@gmail.comwrote:
 
  On 6 Dec 2013, at 15:19, Lukasz Lenart wrote:
 
  2013/12/6 Christian Grobmeier grobme...@gmail.com:
 
 
  On 6 Dec 2013, at 8:11, Lukasz Lenart wrote:
 
  Do you know if git at Apache supports Pull Requests between
 branches?
 
  I've started working like that some time ago and it's awesome
 feature
  :-)
 
 
  Honestly I don't know :-)
 
  I mean you can merge between branches easily. Is that what you
 mean?
 
 
  Not exactly, in GitHub you can prepare a Pull Request between
  different branches in the same repo - you don't have to fork the
 repo
  at all. So you'll see the PR on issues list and you can comment,
  change the code and so on, before merging it to mater/develop.
 
  But I think it's pure GitHub functionality not really related to git
  itself.
 
 
  I don't know for sure, but I agree, its most likely a github feature.
  I think something like gitlabhq might be able to do the same:
  https://github.com/gitlabhq/gitlabhq
  But i have not heard if this is going to live at ASF infra
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
  ---
  http://www.grobmeier.de
  @grobmeier
  GPG: 0xA5CC90DB
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
 
  --
  e: davelnew...@gmail.com
  m: 908-380-8699
  s: davelnewton_skype
  t: @dave_newton https://twitter.com/dave_newton
  b: Bucky Bits http://buckybits.blogspot.com/
  g: davelnewton https://github.com/davelnewton
  so: Dave Newton http://stackoverflow.com/users/438992/dave-newton
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
  ---
  http://www.grobmeier.de
  @grobmeier
  GPG: 0xA5CC90DB
 
  -
  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

Re: Svn to Git migration

[Paul Benedict]

No, please don't move things to the attic. We published POMs and other
links to the repository. We should just make it read-only.


On Tue, Jan 14, 2014 at 1:23 PM, Johannes Geppert joh...@gmail.com wrote:

 Looks good to me!

 Thanks Łukasz for taking care of this migration.

 Johannes

 #
 web: http://www.jgeppert.com
 twitter: http://twitter.com/jogep


 2014/1/14 Lukasz Lenart lukaszlen...@apache.org

  Guys,
  can you review cleanup I have performed?
 
  https://svn.apache.org/repos/asf/struts/
  https://svn.apache.org/repos/asf/struts/attic/
 
  what else I should move to attic as well
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2014/1/14 Lukasz Lenart lukaszlen...@apache.org:
   I think it isn't needed. I'm going to move everything to 'attic'
   folder to be backed up and create README about migration
  
   2014/1/14 Paul Benedict pbened...@apache.org:
   Can you request to turn it read only?
   On Jan 14, 2014 11:58 AM, Lukasz Lenart lukaszlen...@apache.org
  wrote:
  
   Migration to Git is almost done! Please DON'T use Subversion anymore!
  
   https://issues.apache.org/jira/browse/INFRA-7174
  
  
   Regards
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
  
   2014/1/9 Lukasz Lenart lukaszlen...@apache.org:
Time to move forward
   
https://issues.apache.org/jira/browse/INFRA-7174
   
2013/12/10 Christian Grobmeier grobme...@gmail.com:
On 10 Dec 2013, at 7:55, Lukasz Lenart wrote:
   
I'm going postpone transition to Git as we must straighten site
building first! Right now it's a real pain in the a.. and it
 takes
ages to update site after release. Not saying about other mirror
problems with this whole SvnPubSub crap :\
   
   
Oh ok. :-|
   
I am a bit undecided on how we approach the website (again).
   
   
   
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
   
2013/12/6 Dave Newton davelnew...@gmail.com:
   
Correct; pull requests are a github thing.
   
And they're nice (usually).
   
   
On Fri, Dec 6, 2013 at 12:09 PM, Christian Grobmeier
grobme...@gmail.comwrote:
   
On 6 Dec 2013, at 15:19, Lukasz Lenart wrote:
   
2013/12/6 Christian Grobmeier grobme...@gmail.com:
   
   
On 6 Dec 2013, at 8:11, Lukasz Lenart wrote:
   
Do you know if git at Apache supports Pull Requests between
   branches?
   
I've started working like that some time ago and it's
 awesome
   feature
:-)
   
   
Honestly I don't know :-)
   
I mean you can merge between branches easily. Is that what
 you
   mean?
   
   
Not exactly, in GitHub you can prepare a Pull Request between
different branches in the same repo - you don't have to fork
 the
   repo
at all. So you'll see the PR on issues list and you can
 comment,
change the code and so on, before merging it to mater/develop.
   
But I think it's pure GitHub functionality not really related
  to git
itself.
   
   
I don't know for sure, but I agree, its most likely a github
  feature.
I think something like gitlabhq might be able to do the same:
https://github.com/gitlabhq/gitlabhq
But i have not heard if this is going to live at ASF infra
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
   
   
   -
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
   
   
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
   
   
  -
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
   
   
   
--
e: davelnew...@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton https://twitter.com/dave_newton
b: Bucky Bits http://buckybits.blogspot.com/
g: davelnewton https://github.com/davelnewton
so: Dave Newton 
  http://stackoverflow.com/users/438992/dave-newton
   
   
   
  -
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
   
   
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
   
   
  -
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

Re: Re-organise docs

[Paul Benedict]

Years in the making. WOW! The Wiki documentation finally looks readable!


On Mon, Dec 16, 2013 at 3:33 PM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 I have removed custom css, the space looks better now :-)

 https://cwiki.apache.org/confluence/display/WW/Home


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2013/12/16 Lukasz Lenart lukaszlen...@apache.org:
  FYI
 
  Confluence was upgraded to version 5 and there are some problems with
  editing pages.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/12/11 Lukasz Lenart lukaszlen...@apache.org:
  One more thing: everything editable will be moved to struts-site (i.e.
  the new plugin.md) to don't mess with things generated by Maven
 
  So the project source code will contain only source code and JavaDocs,
  the rest will be outside it.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/12/11 Paul Benedict pbened...@apache.org:
  Sounds good to me. The easier the better.
 
 
  On Wed, Dec 11, 2013 at 2:06 AM, Lukasz Lenart 
 lukaszlen...@apache.orgwrote:
 
  Still thinking how to organise everything, maybe instead common
  /release/2.3.x and so on it'd be better to have something like that:
 
  /docs/latest - latest development version
  /docs/2.3.x
  /docs/2.2.x
  ...
 
  and
 
  /apidocs/latest - the same as above
  /apidocs/2.3.x
  /apidocs/2.2.x
  ...
 
  there be no more dedicated S2 subsite, everything will be put on the
  top, also Maven reports will be thrown away.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/12/10 Lukasz Lenart lukaszlen...@apache.org:
   Starting work on that - it must be resolved before next release
 comes
  out.
  
   My plan is to have two tasks:
   1. it will export pages from Confluence and will put them under
 /docs
   2. used after release to update JavaDocs (regenerate from tag) and
   Docs (copy from /docs to /release/2.3.x/docs)
  
   WDYT?
  
   https://issues.apache.org/jira/browse/INFRA-6350
  
  
   Regards
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
  
   2013/11/6 Lukasz Lenart lukaszlen...@apache.org:
   2013/11/5 Paul Benedict pbened...@apache.org:
   I usually find it a life-saver to see the docs of previous
 versions.
  Not
   everyone upgrades and it's impossible to compare latest syntax and
  features
   to what was before. I think we definitely need to keep the docs
 of the
   previously published versions around.
  
   But you meant to have the Draft docs and the latest released
 version?
   Or as it is now, version per branch (2.3, 2.2, 2.1, etc) ?
  
   If you don't want to do that, then I think the latest docs need to
  contain
   some sort of history on feature changes/upgrades.
  
   Hm... I think it's easier to keep few versions ;-)
  
  
   Regards
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
 
  --
  Cheers,
  Paul

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




-- 
Cheers,
Paul

Re: Re-organise docs

[Paul Benedict]

Sounds good to me. The easier the better.


On Wed, Dec 11, 2013 at 2:06 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 Still thinking how to organise everything, maybe instead common
 /release/2.3.x and so on it'd be better to have something like that:

 /docs/latest - latest development version
 /docs/2.3.x
 /docs/2.2.x
 ...

 and

 /apidocs/latest - the same as above
 /apidocs/2.3.x
 /apidocs/2.2.x
 ...

 there be no more dedicated S2 subsite, everything will be put on the
 top, also Maven reports will be thrown away.


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2013/12/10 Lukasz Lenart lukaszlen...@apache.org:
  Starting work on that - it must be resolved before next release comes
 out.
 
  My plan is to have two tasks:
  1. it will export pages from Confluence and will put them under /docs
  2. used after release to update JavaDocs (regenerate from tag) and
  Docs (copy from /docs to /release/2.3.x/docs)
 
  WDYT?
 
  https://issues.apache.org/jira/browse/INFRA-6350
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/11/6 Lukasz Lenart lukaszlen...@apache.org:
  2013/11/5 Paul Benedict pbened...@apache.org:
  I usually find it a life-saver to see the docs of previous versions.
 Not
  everyone upgrades and it's impossible to compare latest syntax and
 features
  to what was before. I think we definitely need to keep the docs of the
  previously published versions around.
 
  But you meant to have the Draft docs and the latest released version?
  Or as it is now, version per branch (2.3, 2.2, 2.1, etc) ?
 
  If you don't want to do that, then I think the latest docs need to
 contain
  some sort of history on feature changes/upgrades.
 
  Hm... I think it's easier to keep few versions ;-)
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: [VOTE] Struts 2.3.16

[Paul Benedict]

For any early adopters, please try out the new postback result. I'd like
to hear any feedback. The primary use case is to take the current request
parameters and allow it to be POST-ed to another URL.


On Thu, Dec 5, 2013 at 10:46 AM, Volker Krebs volker.kr...@abas.de wrote:

 If I may vote, I'll give it a +1 for GA
 Looks good.
 Thanks

 Am 04.12.2013 18:18, schrieb Lukasz Lenart:

 The Apache Struts 2.3.16 test build is now available. With this release:
 - merged security fixes from version 2.3.15.1, 2.3.15.2 and 2.3.15.3
 - solved problem with global error result in the Convention Plugin
 - the action: and method: prefixes are be by default excluded and
 changed order to first check excludeParams and then acceptedParams in
 ParametersInterceptor
 - restored previous behaviour where both ParamatersInterceptor AND
 ParameterNameAware must accept parameter - there is no more precedence
 - added proper support for multiple ActionMapper's used with
 PrefixBasedActionMapper, see PrefixBasedActionMapper
 - solved problem with creating empty map entries via Ognl,
 - and other small improvements

 Release notes:
 * [https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.16]

 Distribution:
 * [http://people.apache.org/builds/struts/2.3.16/]

 Maven 2 staging repository:
 * [https://repository.apache.org/content/repositories/staging/]

 Once you have had a chance to review the test build, please respond
 with a vote on its quality:

 [ ] Leave at test build
 [ ] Alpha
 [ ] Beta
 [ ] General Availability (GA)

 Everyone who has tested the build is invited to vote. Votes by PMC
 members are considered binding. A vote passes if there are at least
 three binding +1s and more +1s than -1s.

 The vote will remain open for at least 72 hours, longer upon request.
 A vote can be amended at any time to upgrade or downgrade the quality
 of the release based on future experience. If an initial vote
 designates the build as Beta, the release will be submitted for
 mirroring and announced to the user list. Once released as a public
 beta, subsequent quality votes on a build may be held on the user
 list.

 As always, the act of voting carries certain obligations. A binding
 vote not only states an opinion, but means that the voter is agreeing
 to help do the work.


 Kind regards


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




-- 
Cheers,
Paul

Re: Re-organise docs

[Paul Benedict]

I usually find it a life-saver to see the docs of previous versions. Not
everyone upgrades and it's impossible to compare latest syntax and features
to what was before. I think we definitely need to keep the docs of the
previously published versions around.

If you don't want to do that, then I think the latest docs need to contain
some sort of history on feature changes/upgrades.


On Tue, Nov 5, 2013 at 1:34 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 I'm wondering what is wrong with exposing only the latest Draft docs
 and just forget about publishing docs on each release? Thus will
 simplify keeping page update-2-date and reduce amount of time spend on
 preparing new release.


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2013/10/30 Lukasz Lenart lukaszlen...@apache.org:
  There is one problem - to include docs in the assemblies they must be
  downloaded with wget (there is no support for SiteExporter in
  Jenkins).
  So, I must add a task which will export docs from Confluence and put
  them under /docs and then with wget they can be downloaded to Jenkins
  and assembled :\
 
  ech... bit messy solution, but I don't see other option.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/9/10  umeshawas...@gmail.com:
  +1 for that
  It will reduce a lot of confusion
  --Original Message--
  From: Lukasz Lenart
  To: Struts Developers List
  ReplyTo: Struts Developers List
  Subject: Re-organise docs
  Sent: Sep 10, 2013 12:18 PM
 
  Hi,
 
  I thought a bit about our docs - for each main branch we provide docs,
  i.e. /release/2.3.x/, /release/2.2.x/ etc. We also expose draft docs
  as /development/2.x - all thus leads to mess when we must update
  something or so.
 
  So maybe just instead of many places with docs we should expose the
  latest related to last release under path /docs and redirect to
  Confluence in case of draft docs?
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
  Sent from BlackBerry® on Airtel

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




-- 
Cheers,
Paul

Re: Work in progress - 2.3.16

[Paul Benedict]

Yasser, do you know why it doesn't work in Jetty ... like an exception is
thrown?


On Thu, Oct 24, 2013 at 3:19 PM, Yasser Zamani yasser.zam...@live.comwrote:

 Congrats :)

 I'm not sure how much is important but s:debug/ works now with Jetty
 is not mentioned @ https://cwiki.apache.org/**
 confluence/display/WW/Version+**Notes+2.3.16https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.16


 On Thu 24 Oct 2013 11:18:51 PM IRST, Lukasz Lenart wrote:

 Two issues left :-)

 https://issues.apache.org/**jira/browse/WW/fixforversion/**12324546https://issues.apache.org/jira/browse/WW/fixforversion/12324546
 https://cwiki.apache.org/**confluence/display/WW/Version+**Notes+2.3.16https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.3.16


 Regards


 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@struts.apache.**orgdev-unsubscr...@struts.apache.org
 For additional commands, e-mail: dev-h...@struts.apache.org




-- 
Cheers,
Paul

Re: Html5 theme

[Paul Benedict]

The notion of theme is about a kind of stylistic output -- not specific to
any HTML spec. Yes, one set of tags.

I don't really know if we need to render anything differently, actually. We
should at least put in the TLD the HTML version the spec belongs to so IDE
completion can inform the user. I believe the HTML 4 spec simply ignores
unknown elements and attributes. So, there may not be anything special
for us to do programming wise.

Paul



On Fri, Oct 18, 2013 at 1:55 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 2013/10/17 Paul Benedict pbened...@apache.org:
  HTML is now a living spec. Their plan is to have 5.0 finished in 2014 and
  spin off a new version every two years:
  http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
 
  So I don't think it's good we come up with a new theme since 5.1, 5.2,
 etc.
  will be out in sort-of rapid pace. I believe the better solution is to
 
  1) Make the themes/tags support all the latest attributes
  2) Add a struts constant that specifies the HTML spec you are targeting
  3) Have a graceful desegregation of the new attributes -- do not output
  them at the wrong level (and log about it)

 So you'd like to have just one set of tags (say simple theme only)
 which can render different set of attributes depending on spec you
 want to target?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: Html5 theme

[Paul Benedict]

BTW, this was regarding the tag attributes:
We should at least put in the TLD the HTML version the spec belongs to so
IDE completion can inform the user.


On Fri, Oct 18, 2013 at 9:19 AM, Paul Benedict pbened...@apache.org wrote:

 The notion of theme is about a kind of stylistic output -- not specific to
 any HTML spec. Yes, one set of tags.

 I don't really know if we need to render anything differently, actually.
 We should at least put in the TLD the HTML version the spec belongs to so
 IDE completion can inform the user. I believe the HTML 4 spec simply
 ignores unknown elements and attributes. So, there may not be anything
 special for us to do programming wise.

 Paul



 On Fri, Oct 18, 2013 at 1:55 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 2013/10/17 Paul Benedict pbened...@apache.org:
  HTML is now a living spec. Their plan is to have 5.0 finished in 2014
 and
  spin off a new version every two years:
  http://dev.w3.org/html5/decision-policy/html5-2014-plan.html
 
  So I don't think it's good we come up with a new theme since 5.1, 5.2,
 etc.
  will be out in sort-of rapid pace. I believe the better solution is to
 
  1) Make the themes/tags support all the latest attributes
  2) Add a struts constant that specifies the HTML spec you are targeting
  3) Have a graceful desegregation of the new attributes -- do not output
  them at the wrong level (and log about it)

 So you'd like to have just one set of tags (say simple theme only)
 which can render different set of attributes depending on spec you
 want to target?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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




 --
 Cheers,
 Paul




-- 
Cheers,
Paul

Re: Html5 theme

[Paul Benedict]

HTML is now a living spec. Their plan is to have 5.0 finished in 2014 and
spin off a new version every two years:
http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

So I don't think it's good we come up with a new theme since 5.1, 5.2, etc.
will be out in sort-of rapid pace. I believe the better solution is to

1) Make the themes/tags support all the latest attributes
2) Add a struts constant that specifies the HTML spec you are targeting
3) Have a graceful desegregation of the new attributes -- do not output
them at the wrong level (and log about it)

Watcha think?

Paul


On Thu, Oct 17, 2013 at 8:36 AM, Frans Thamura fr...@meruvian.org wrote:

 We use johan geppe plugins.

 F
 On Oct 17, 2013 8:31 PM, Lukasz Lenart lukaszlen...@apache.org wrote:

  It's not exactly what I want, take a look on this example:
 
  s:submit action=cancel/
 
  will be rendered as:
 
  input type=submit name=submit formaction=cancel.action /
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/10/17 Johannes Geppert joh...@gmail.com:
   We are supporting dynamic attributes, so you can add every attribute
 you
   like.
  
   If we are going to extend the taglib with new attributes then we are
  extend
   it for
   all themes instead to add  simply new freemarker templates.
  
  
   Johannes
  
   #
   web: http://www.jgeppert.com
   twitter: http://twitter.com/jogep
  
  
   2013/10/17 Lukasz Lenart lukaszlen...@apache.org
  
   I mean, theme which supports new attributes, e.g.
  
   input type=submit formaction=... .../
   http://www.w3schools.com/tags/tag_input.asp
  
  
   Regards
   --
   Łukasz
   + 48 606 323 122 http://www.lenart.org.pl/
  
   2013/10/17 Johannes Geppert jo...@apache.org:
What exactly do you mean with Html5 theme for forms?
   
A form theme without tables and support for different input types?
Then the struts2-bootstrap-plugin is a kind of html5 theme.
   
Johannes
   
#
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
   
   
   
2013/10/17 Lukasz Lenart lukaszlen...@apache.org
   
Hi,
   
Does anyone is working on that?
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
   
   
 -
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
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 




-- 
Cheers,
Paul

Re: Security judges

[Paul Benedict]

Throw an exception instead. If Struts has a default exception handler,
translate the exception into a 403; but the goal is to give the user a
chance to customize the response.


On Thu, Oct 17, 2013 at 6:46 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 2013/10/10 Lukasz Lenart lukaszlen...@apache.org:
  2013/10/10 Steven Benitez steven.beni...@gmail.com:
  Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm
 not
  sure if it's best. What would the API look like?
 
  Not sure yet, something like this:
 
  public class SecurityGate {
 
  private ListSecurityGuard guards;
 
  public void check(HttpServletRequest) {
  for(SecurityGuard guard : guards) {
 SecurityPass pass = guard.accept(HttpServletRequest);
 if (pass.notAccepted()) {
 throw new StrutsSecurityException(pass.getGuardMessage())
}
  }
  }
 
  }

 Right now I'm planning just to throw an exception and call
 sendError(HttpServletResponse.SC_BAD_REQUEST, e.getMessage()), WDYT?


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: Strict DMI

[Paul Benedict]

If @Action is to be allowed at the method level, do its annotation's
attributes still make sense? I am not asking rhetorically. If not, it is
better to create a new annotation.


On Thu, Oct 10, 2013 at 9:21 AM, Ken McWilliams ken.mcwilli...@gmail.comwrote:

 I didn't mean to say that action: didn't make any sense, which I agree it
 doesn't; But that method: really isn't any different. The @Action
 annotation can be applied at the method level of the action class. The
 use-case for the method prefix seems to be completely addressed by using
 the @Action annotation at the method level, multiple times in one action.
 Thus a @Method annotation would serve little purpose since there is already
 an obvious remedy.

 What I meant by the definition of action being taken in a different
 context... the documentation of the method: prefix seems to indicate that
 the Action Class is the action and that it is somehow convenient to be
 able to address another method of the _action_. Why not just do it
 directly? That is why I ask: What am I missing?


 On Wed, Oct 9, 2013 at 9:40 PM, Paul Benedict pbened...@apache.org
 wrote:

  Ken,
 
  I don't think action: will be supported beyond 2.5. It is a feature
 that
  doesn't make sense. All buttons that belong to a form need to be
 processed
  by the action of the form for security to work. That's what I think.
 
  Paul
 
 
  On Wed, Oct 9, 2013 at 5:58 PM, Ken McWilliams ken.mcwilli...@gmail.com
  wrote:
 
   What am I missing? Why not just the @action annotation? The whole
 method
   annotation seems to have risen out of a poor definition of action. I
   consider the action the entire follow of execution. From mapping to
  result
   (Interceptors and the Action class too).
  
   From the DefaultActionMapper documentation:
  
   *With method-prefix, instead of calling baz action's execute() method
 (by
   default if it isn't overriden in struts.xml to be something else), the
  baz
   action's anotherMethod() will be called. A very elegant way determine
  which
   button is clicked. Alternatively, one would have submit button set a
   particular value on the action when clicked, and the execute() method
   decides on what to do with the setted value depending on which button
 is
   clicked. *
  
   If you need an annotation on anotherMethod @action would be
  functionally
   equivalent to @method. Of course you wouldn't be able to use the
  method:
   prefix but then you wouldn't have any need.
  
  
   On Sun, Oct 6, 2013 at 11:23 PM, Lukasz Lenart 
 lukaszlen...@apache.org
   wrote:
  
I think @ActionMethod or @Method is very handy. I'm still wondering
about how to map which actions are allowed to be used with action:
prefix - what about dropping action: prefix and stick only with
method: and s:form method=... ?
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
   
2013/10/4 Steven Benitez steven.beni...@gmail.com:
 I suggested this because I wrote an interceptor to require the
 @ActionMethod annotation years ago to lock down DMI. The upside to
 a
 separate annotation was that it was completely compatible with XML
 configuration (which I use). It also had a nice benefit of being
 documentation, as well. No ambiguity as to whether an method was an
 invocable action method or just a method that returned a String.


 On Fri, Oct 4, 2013 at 10:37 AM, Paul Benedict 
 pbened...@apache.org
  
wrote:

 I like that WAY better. Instead of using opaque strings in
 @Action,
   use
 @ActionMethod on the destination methods. +1


 On Fri, Oct 4, 2013 at 4:31 AM, Lukasz Lenart 
   lukaszlen...@apache.org
 wrote:

  2013/10/3 Steven Benitez steven.beni...@gmail.com:
   Why not just have an @ActionMethod annotation? If its on the
   action
  method,
   you can invoke it, if not, you can't. The global config option
  for
  allowed
   methods sounds reasonable (e.g., execute, input, etc.)
 
  Nice idea and quite simple :-) What about allowedActions ?
 Maybe
  extend @Action annotation and add callable = true|false which
  will
  indicate if action can be called by action: prefix.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
 
   -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 


 --
 Cheers,
 Paul

   
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
   
  
 
 
 
  --
  Cheers,
  Paul
 




-- 
Cheers,
Paul

Re: Strict DMI

[Paul Benedict]

Ken,

I don't think action: will be supported beyond 2.5. It is a feature that
doesn't make sense. All buttons that belong to a form need to be processed
by the action of the form for security to work. That's what I think.

Paul


On Wed, Oct 9, 2013 at 5:58 PM, Ken McWilliams ken.mcwilli...@gmail.comwrote:

 What am I missing? Why not just the @action annotation? The whole method
 annotation seems to have risen out of a poor definition of action. I
 consider the action the entire follow of execution. From mapping to result
 (Interceptors and the Action class too).

 From the DefaultActionMapper documentation:

 *With method-prefix, instead of calling baz action's execute() method (by
 default if it isn't overriden in struts.xml to be something else), the baz
 action's anotherMethod() will be called. A very elegant way determine which
 button is clicked. Alternatively, one would have submit button set a
 particular value on the action when clicked, and the execute() method
 decides on what to do with the setted value depending on which button is
 clicked. *

 If you need an annotation on anotherMethod @action would be functionally
 equivalent to @method. Of course you wouldn't be able to use the method:
 prefix but then you wouldn't have any need.


 On Sun, Oct 6, 2013 at 11:23 PM, Lukasz Lenart lukaszlen...@apache.org
 wrote:

  I think @ActionMethod or @Method is very handy. I'm still wondering
  about how to map which actions are allowed to be used with action:
  prefix - what about dropping action: prefix and stick only with
  method: and s:form method=... ?
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  2013/10/4 Steven Benitez steven.beni...@gmail.com:
   I suggested this because I wrote an interceptor to require the
   @ActionMethod annotation years ago to lock down DMI. The upside to a
   separate annotation was that it was completely compatible with XML
   configuration (which I use). It also had a nice benefit of being
   documentation, as well. No ambiguity as to whether an method was an
   invocable action method or just a method that returned a String.
  
  
   On Fri, Oct 4, 2013 at 10:37 AM, Paul Benedict pbened...@apache.org
  wrote:
  
   I like that WAY better. Instead of using opaque strings in @Action,
 use
   @ActionMethod on the destination methods. +1
  
  
   On Fri, Oct 4, 2013 at 4:31 AM, Lukasz Lenart 
 lukaszlen...@apache.org
   wrote:
  
2013/10/3 Steven Benitez steven.beni...@gmail.com:
 Why not just have an @ActionMethod annotation? If its on the
 action
method,
 you can invoke it, if not, you can't. The global config option for
allowed
 methods sounds reasonable (e.g., execute, input, etc.)
   
Nice idea and quite simple :-) What about allowedActions ? Maybe
extend @Action annotation and add callable = true|false which will
indicate if action can be called by action: prefix.
   
   
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
   
  
  
   --
   Cheers,
   Paul
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 




-- 
Cheers,
Paul

Re: DeprecationInterceptor

[Paul Benedict]

Okay, good. Document it as such as no one else will wonder. :-)


On Wed, Oct 9, 2013 at 3:08 PM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 2013/10/9 Maurizio Cucchiara mcucchi...@apache.org:
  Hi Lukasz,
  sounds good, but what happen when they use a custom stack?
  don't they see any warning message?

 I was planning to enable it just in DevMode so it will be the same as
 DebugInterceptor - it should be used as developer's tool, not in
 production.


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: Security judges

[Paul Benedict]

I like the idea except the Judge name. I think Authenticator is fine.


On Wed, Oct 9, 2013 at 3:21 PM, Steven Benitez steven.beni...@gmail.comwrote:

 Can you clarify how this would affect custom action mappers?


 On Wed, Oct 9, 2013 at 4:05 PM, Lukasz Lenart lukaszlen...@apache.org
 wrote:

  Hi,
 
  Another idea is to add some logic to handle security aspects of the
  framework in one place - it would be some kind of stack of interfaces
  which will try to cleanup incoming request.
 
  For example:
 
  - ActionNameJudge#accept() will handle if action name match expected
  pattern, the same what is already defined with constant in
  DefaultActionMapper
  - ParameterNameJudge#accept() will handle if given parameter name is
  acceptable - the same what ParametersInterceptor do right now
  - etc
 
  The idea is simple - have all the security related logic in one place
  and to have it applied to the whole framework not to some parts, i.e.
  someone will implement their own ActionMapper and won't escape/clear
  action names as it is done in DefaultActionMapper, and so on.
 
  These handlers will be configured in struts-default.xml and user can
  re-define them, additional judges, etc.
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 




-- 
Cheers,
Paul

Re: Strict DMI

[Paul Benedict]

I like that WAY better. Instead of using opaque strings in @Action, use
@ActionMethod on the destination methods. +1


On Fri, Oct 4, 2013 at 4:31 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 2013/10/3 Steven Benitez steven.beni...@gmail.com:
  Why not just have an @ActionMethod annotation? If its on the action
 method,
  you can invoke it, if not, you can't. The global config option for
 allowed
  methods sounds reasonable (e.g., execute, input, etc.)

 Nice idea and quite simple :-) What about allowedActions ? Maybe
 extend @Action annotation and add callable = true|false which will
 indicate if action can be called by action: prefix.


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

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




-- 
Cheers,
Paul

Re: We are live :-)

[Paul Benedict]

Nice work.


On Tue, Sep 17, 2013 at 3:15 PM, Philip Luppens philip.lupp...@gmail.comwrote:

 On Tue, Sep 17, 2013 at 9:11 PM, Christian Grobmeier grobme...@gmail.com
 wrote:

  Hey all,
 
  we have a new main site, I just pulled the trigger :-)
 
  http://struts.apache.org
 
  Thanks to all who corrected a lot of things when I was piled under work
  the past days. Keep on doing that. It's only for our own best to keep on
  improving the docs on all pages of our main site.
 

 Sweet! Great job y'all!

 -Phil


 
  Cheers
  Christian
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 


 --
 We cannot change the cards we are dealt, just how we play the hand. -
 Randy Pausch




-- 
Cheers,
Paul

Re: Docs: Working on Struts main

[Paul Benedict]

Where can I see the new website before it goes live?


On Fri, Sep 13, 2013 at 2:22 AM, Rene Gielen rene.gie...@gmail.com wrote:

 As this a major change, a formal vote might be a valid option.
  Am 12.09.2013 11:26 schrieb Lukasz Lenart lukaszlen...@apache.org:

  Can we go live?
 
  2013/9/11 Lukasz Lenart lukaszlen...@apache.org:
   I think we can go live with the new website even now - it looks much
   better the old one and the rest can be improved in meantime.
  
   2013/9/10 Christian Grobmeier grobme...@gmail.com:
   Am 10.09.13 18:11, schrieb Rene Gielen:
   If I'd use [Publish Site] now in the Bookmarklet, the site gets -
 well
  -
   published. So better nobody would hit this unless we are sure to
  launch the
   reworked site. Also, we are currently not able to publish small
  changes
   such as release announcements without rolling out the full new site.
 I
  just
   want to make sure anybody is aware of this (as long as I'm not
 missing
   something here).
   Ah yes, thats right. Luckily the old page is already much worse then
 the
   half completed one now.
   We have a lot of outdated links and information there. If somebody
 reads
   that he would be totally done.
   If it is really an emergency problem we can branch the trunk, rollback
   things on trunk and push a change.
   Not nice and well thought, but would work in case of fire.
  
  
   - René
  
  
   2013/9/10 Christian Grobmeier grobme...@gmail.com
  
   Am 10.09.13 14:40, schrieb Lukasz Lenart:
   2013/9/10 Rene Gielen rene.gie...@gmail.com:
   You guys are aware that we cannot publish to live anymore now? We
  would
   rollout the new site then.
   If you mean that view diff gives a no result, this was prior the
   changes. I thought it was a hickup at infra.
   I have tried that via the cms bookmarklet. Or did you mean something
  else?
   What you mean by that?
  
  
   Regards
  
  
 -
   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
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 




-- 
Cheers,
Paul

Re: Doubting OGNL

[Paul Benedict]

Isn't it already decoupled since OGNL is a separate project? I mean, of
course Struts 2 needs mediating code to support it, but how coupled is it
really?

Paul


On Wed, Sep 4, 2013 at 8:04 AM, Christian Grobmeier grobme...@gmail.comwrote:

 Folks,

 when researching on OGNL i found this link:
 https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement

 In 2008 Brian mentioned Security risks keep appearing along with OGNL
 and collected the places where we use OGNL. Given the recent events I
 thought it might be good to bring this up again. Please also note, I
 have helped with OGNLs incubation and I am also touchign it over in
 Commons land. My impression is OGNL is not easy to understand and there
 is not really much interest from other people to develop on it.

 Looking at this list I feel OGNL is pretty much tied to Struts. On the
 other hand we could start to slowly decouple the two. Not sure what we
 should use otherwise.

 Any feelings on that?

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




-- 
Cheers,
Paul

Re: Doubting OGNL

[Paul Benedict]

Can you explain to me why any EL needs to be in the struts.xml? I
understand how it's nice to pick up variable names for parameters, but
that's probably all OGNL should do -- and to be honest, you don't need OGNL
for that. Even the simplistic Commons BeanUtils can pull out values from
${...} expressions.


On Wed, Sep 4, 2013 at 10:04 AM, Dave Newton davelnew...@gmail.com wrote:

 There needs to be *something* inside the config file, although I'm leaning
 towards something other than XML config, like Groovy/etc. instead of an EL,
 but that's because I'm biased towards code.

 I've played a lot of useful games with OGNL inside resource files as well.

 This malleability is a nice feature; the issues have been around how deep
 the EL can dig into the runtime.

 Dave



 On Wed, Sep 4, 2013 at 10:53 AM, Paul Benedict pbened...@apache.org
 wrote:

  IMO, I see no use for OGNL outside of the view layer. What good use cases
  are there to evluate OGNL in anything else? I also don't think it should
 be
  used inside of struts.xml either.
 
 
  On Wed, Sep 4, 2013 at 9:50 AM, Cameron Morris cmor...@part.net wrote:
 
   I'm an outsider here, but I thought I'd chime in on this.  I'm
 presenting
   tomorrow night at an OWAP-chapter meeting on Attacking and Defending
   struts2
 http://prezi.com/yydldqt0dep-/attacking-and-defending-struts2/
   OGNL is the star of the show.  (I'd love some feedback on the
  presentation
   btw)
  
   OGNL is a big risk.  OGNL in the jsps aren't as much an issue, it's the
   OGNL use everywhere else as glue that seems to get us into trouble over
  and
   over.  We are planning on rewriting our public (non-authenticated)
  actions
   as plain-old servlets just to reduce the exposure.
  
   Not for the risk, but for future flexibility, new pages we write will
 be
   JSP using only JSTL and EL.
  
   I haven't evaluated alternatives, but there appears to be many OSS
   implementations of EL.  For the parameterInterceptor it seems like OGNL
   does too much and it just needs something simple enough to set values.
Perhaps a 1.1 version of JSTL-EL  Perhaps we can roll our own that
 does
   just enough to set parameters.   I'm curious to know if there are any
   struts3 plans around this.  I'm sorry to just offer criticism with no
  real
   solution.
  
  
   On Wed, Sep 4, 2013 at 7:53 AM, Christian Grobmeier 
 grobme...@gmail.com
   wrote:
  
Am 04.09.13 15:41, schrieb Martin Gainty:
 Granted OGNL is not intuitive but neither is JSTL

 because you don't understand something does not state the case for
removal from the framework
Not sure to whom you wrote this response.
   
My problems with OGNL are:
   
- not actively maintained (I am involved, I know about it)
- hard to maintain
- looks like it is / was responsible for a lot of security issues
   
If I would not understand alone, it is really no reason to remove
something from the framework. If a LOT of users do not understand
 well,
it is for sure. Frameworks today must be easy to understand and easy
 to
use. If we have a chance to to make things easier for users, we
 should
do it.
   
In frontend land we might consider to propagate JSTL if our own
 things
cannot be maintained because lack of man power.
 Please State your case for an alternative mechanism for accessing
entities from the Object Graph

 Specific examples such as OGNL access vs Alternative access
 could
justify the refactoring effort
I was asking to collect some input and see if there are similar
  feelings
like I have on OGNL.
   

 Martin
 __
 Verzicht und Vertraulichkeitanmerkung

 Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
   unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese
  Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit
 von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.


 Subject: Re: Doubting OGNL
 To: dev@struts.apache.org
 From: umeshawas...@gmail.com
 Date: Wed, 4 Sep 2013 13:13:20 +

 As per my experience over Stack Overflow, every alternate question
  on
Struts2 is related to OGNL syntax or user is not able to understand
 how
OGNL working.

 I have a very good experience with JSTL and honestly I am more
 than
happy with its simple syntax.


 Sent from BlackBerryŽ on Airtel

 -Original Message-
 From: Christian Grobmeier grobme...@gmail.com
 Date: Wed, 04 Sep 2013 15:04:06
 To: Struts Developers Listdev@struts.apache.org
 Reply-To: Struts Developers List dev@struts.apache.org
 Subject: Doubting OGNL

 Folks,

 when researching on OGNL

Re: Doubting OGNL

[Paul Benedict]

Christian, as I said, I am OK with the view laying using OGNL. If JSPs are
using that, I see no problem. But I should ask if the majority of
vulnerabilities are from the view layer or from the processor/controller
layer?


On Wed, Sep 4, 2013 at 10:20 AM, Christian Grobmeier grobme...@gmail.comwrote:

 Am 04.09.13 16:34, schrieb Dave Newton:
  I'd looked in to replacing OGNL with MVEL, including the templating, but
 it
  entailed a fairly extensive effort.
 
  Not saying it isn't worth it; personally I'd like to see a few other
  options and a simplification of the templates (and potential speedups).
 I found Struts-Tags often rely on the com.opensymphony.xwork2.ognl
 package (accessing the valuestack). My guess is, everything which access
 the value stack is done with with OGNL. I think Validation bases on OGNL
 too.



  Dave
 
 
 
  On Wed, Sep 4, 2013 at 10:21 AM, Paul Benedict pbened...@apache.org
 wrote:
 
  Isn't it already decoupled since OGNL is a separate project? I mean,
 of
  course Struts 2 needs mediating code to support it, but how coupled is
 it
  really?
 
  Paul
 
 
  On Wed, Sep 4, 2013 at 8:04 AM, Christian Grobmeier 
 grobme...@gmail.com
  wrote:
  Folks,
 
  when researching on OGNL i found this link:
  https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
 
  In 2008 Brian mentioned Security risks keep appearing along with OGNL
  and collected the places where we use OGNL. Given the recent events I
  thought it might be good to bring this up again. Please also note, I
  have helped with OGNLs incubation and I am also touchign it over in
  Commons land. My impression is OGNL is not easy to understand and there
  is not really much interest from other people to develop on it.
 
  Looking at this list I feel OGNL is pretty much tied to Struts. On the
  other hand we could start to slowly decouple the two. Not sure what we
  should use otherwise.
 
  Any feelings on that?
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
  --
  Cheers,
  Paul
 
 
 


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




-- 
Cheers,
Paul

Re: Doubting OGNL

[Paul Benedict]

IMO, I see no use for OGNL outside of the view layer. What good use cases
are there to evluate OGNL in anything else? I also don't think it should be
used inside of struts.xml either.


On Wed, Sep 4, 2013 at 9:50 AM, Cameron Morris cmor...@part.net wrote:

 I'm an outsider here, but I thought I'd chime in on this.  I'm presenting
 tomorrow night at an OWAP-chapter meeting on Attacking and Defending
 struts2 http://prezi.com/yydldqt0dep-/attacking-and-defending-struts2/
 OGNL is the star of the show.  (I'd love some feedback on the presentation
 btw)

 OGNL is a big risk.  OGNL in the jsps aren't as much an issue, it's the
 OGNL use everywhere else as glue that seems to get us into trouble over and
 over.  We are planning on rewriting our public (non-authenticated) actions
 as plain-old servlets just to reduce the exposure.

 Not for the risk, but for future flexibility, new pages we write will be
 JSP using only JSTL and EL.

 I haven't evaluated alternatives, but there appears to be many OSS
 implementations of EL.  For the parameterInterceptor it seems like OGNL
 does too much and it just needs something simple enough to set values.
  Perhaps a 1.1 version of JSTL-EL  Perhaps we can roll our own that does
 just enough to set parameters.   I'm curious to know if there are any
 struts3 plans around this.  I'm sorry to just offer criticism with no real
 solution.


 On Wed, Sep 4, 2013 at 7:53 AM, Christian Grobmeier grobme...@gmail.com
 wrote:

  Am 04.09.13 15:41, schrieb Martin Gainty:
   Granted OGNL is not intuitive but neither is JSTL
  
   because you don't understand something does not state the case for
  removal from the framework
  Not sure to whom you wrote this response.
 
  My problems with OGNL are:
 
  - not actively maintained (I am involved, I know about it)
  - hard to maintain
  - looks like it is / was responsible for a lot of security issues
 
  If I would not understand alone, it is really no reason to remove
  something from the framework. If a LOT of users do not understand well,
  it is for sure. Frameworks today must be easy to understand and easy to
  use. If we have a chance to to make things easier for users, we should
  do it.
 
  In frontend land we might consider to propagate JSTL if our own things
  cannot be maintained because lack of man power.
   Please State your case for an alternative mechanism for accessing
  entities from the Object Graph
  
   Specific examples such as OGNL access vs Alternative access could
  justify the refactoring effort
  I was asking to collect some input and see if there are similar feelings
  like I have on OGNL.
 
  
   Martin
   __
   Verzicht und Vertraulichkeitanmerkung
  
   Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
  Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede
 unbefugte
  Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
  dient lediglich dem Austausch von Informationen und entfaltet keine
  rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
  E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
  
  
   Subject: Re: Doubting OGNL
   To: dev@struts.apache.org
   From: umeshawas...@gmail.com
   Date: Wed, 4 Sep 2013 13:13:20 +
  
   As per my experience over Stack Overflow, every alternate question on
  Struts2 is related to OGNL syntax or user is not able to understand how
  OGNL working.
  
   I have a very good experience with JSTL and honestly I am more than
  happy with its simple syntax.
  
  
   Sent from BlackBerryŽ on Airtel
  
   -Original Message-
   From: Christian Grobmeier grobme...@gmail.com
   Date: Wed, 04 Sep 2013 15:04:06
   To: Struts Developers Listdev@struts.apache.org
   Reply-To: Struts Developers List dev@struts.apache.org
   Subject: Doubting OGNL
  
   Folks,
  
   when researching on OGNL i found this link:
   https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
  
   In 2008 Brian mentioned Security risks keep appearing along with
 OGNL
   and collected the places where we use OGNL. Given the recent events I
   thought it might be good to bring this up again. Please also note, I
   have helped with OGNLs incubation and I am also touchign it over in
   Commons land. My impression is OGNL is not easy to understand and
 there
   is not really much interest from other people to develop on it.
  
   Looking at this list I feel OGNL is pretty much tied to Struts. On the
   other hand we could start to slowly decouple the two. Not sure what we
   should use otherwise.
  
   Any feelings on that?
  
   -
   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 

Re: Doubting OGNL

[Paul Benedict]

Thank you Cameron for providing this list. I appreciate it. It helped me
alot.

Christian, what do you mean by sandboxing the ValueStack?




On Wed, Sep 4, 2013 at 10:44 AM, Cameron Morris cmor...@part.net wrote:

 Here is a Struts2 - OGNL vulnerability breakdown.

 View based OGNL Vulns:
 - S2-001 http://struts.apache.org/release/2.3.x/docs/s2-001.html
 - S2-013 http://struts.apache.org/release/2.3.x/docs/s2-013.html
 - S2-014 http://struts.apache.org/release/2.3.x/docs/s2-014.html

 Non-View based OGNL Vuln:
 - S2-003 http://struts.apache.org/release/2.3.x/docs/s2-003.html
 - S2-005 http://struts.apache.org/release/2.3.x/docs/s2-005.html
 - S2-007 http://struts.apache.org/release/2.3.x/docs/s2-007.html
 - S2-009 http://struts.apache.org/release/2.3.x/docs/s2-009.html
 - S2-012 http://struts.apache.org/release/2.3.x/docs/s2-012.html
 - S2-015 http://struts.apache.org/release/2.3.x/docs/s2-015.html
 - S2-016 http://struts.apache.org/release/2.3.x/docs/s2-016.html


 On Wed, Sep 4, 2013 at 9:31 AM, Paul Benedict pbened...@apache.org
 wrote:

  Christian, as I said, I am OK with the view laying using OGNL. If JSPs
 are
  using that, I see no problem. But I should ask if the majority of
  vulnerabilities are from the view layer or from the processor/controller
  layer?
 
 
  On Wed, Sep 4, 2013 at 10:20 AM, Christian Grobmeier 
 grobme...@gmail.com
  wrote:
 
   Am 04.09.13 16:34, schrieb Dave Newton:
I'd looked in to replacing OGNL with MVEL, including the templating,
  but
   it
entailed a fairly extensive effort.
   
Not saying it isn't worth it; personally I'd like to see a few other
options and a simplification of the templates (and potential
 speedups).
   I found Struts-Tags often rely on the com.opensymphony.xwork2.ognl
   package (accessing the valuestack). My guess is, everything which
 access
   the value stack is done with with OGNL. I think Validation bases on
 OGNL
   too.
  
  
  
Dave
   
   
   
On Wed, Sep 4, 2013 at 10:21 AM, Paul Benedict pbened...@apache.org
 
   wrote:
   
Isn't it already decoupled since OGNL is a separate project? I
 mean,
   of
course Struts 2 needs mediating code to support it, but how coupled
 is
   it
really?
   
Paul
   
   
On Wed, Sep 4, 2013 at 8:04 AM, Christian Grobmeier 
   grobme...@gmail.com
wrote:
Folks,
   
when researching on OGNL i found this link:
   
 https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement
   
In 2008 Brian mentioned Security risks keep appearing along with
  OGNL
and collected the places where we use OGNL. Given the recent
 events I
thought it might be good to bring this up again. Please also note,
 I
have helped with OGNLs incubation and I am also touchign it over in
Commons land. My impression is OGNL is not easy to understand and
  there
is not really much interest from other people to develop on it.
   
Looking at this list I feel OGNL is pretty much tied to Struts. On
  the
other hand we could start to slowly decouple the two. Not sure what
  we
should use otherwise.
   
Any feelings on that?
   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
   
   
   
--
Cheers,
Paul
   
   
   
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
   For additional commands, e-mail: dev-h...@struts.apache.org
  
  
 
 
  --
  Cheers,
  Paul
 




-- 
Cheers,
Paul

Re: Something to think about maybe

[Paul Benedict]

Christian, I agree on the awful documentation part. The S1 documentation
is better organized than S2. I thank everyone who wrote S2 documentation,
but it is incredibly difficult to sift through to find an answer. The wiki
may not be the right tool for the documentation although I don't have an
alternative except HTML files in SVN (like S1). If we can do anything to
make it more readable (even correcting the font and font size), I am all
for it.


On Wed, Sep 4, 2013 at 12:32 PM, Christian Grobmeier grobme...@gmail.comwrote:

 Comparison of web frameworks:


 http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

 Lot of the things this guy said on Struts isn't accurate.
 A few things are worth to think about it:

 Quote:

 Many devs see Struts as a legacy technology, so don’t expect fancy code
 generation in the place of boilerplate code. You need to configure a lot
 to start prototyping. An example project can be a good starting point.
 Something on the bright side: Struts has a Convention plugin, that
 enforces some convention over configuration and provides annotations to
 configure URL mappings and some other stuff. This should speed up things
 a bit.

 Score: 2/5 – Lots of boilerplate code, no built-in code generation, no
 external powerful tools.

 This guy certainly did miss maven archetypes. Asides from that, we
 actually could think about some code generation tools. For example:

 $ struts-gen.sh de.grobmeier.app.LoginAction

 Generated LoginAction.java
 Generated login.jsp

 This paragraph also tells me we should stick with the idea of pushing
 the Convention plugin.

 Later the author wrote:

 Awful official documentation. User-written tutorials are slightly better.

 As already discussed today, I think this is not so wrong.

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




-- 
Cheers,
Paul

Re: Doubting OGNL

[Paul Benedict]

Although Freemarker/Velocity doesn't have a JSP container, I think you can
somehow bridge the two.

Check out this blog post:
http://illegalargumentexception.blogspot.com/2008/04/java-using-el-outside-j2ee.html



On Wed, Sep 4, 2013 at 1:19 PM, Steven Benitez steven.beni...@gmail.comwrote:

 I prefer EL over OGNL, but the problem with removing OGNL in Struts 3 would
 be that there isn't currently (that I am aware of) a way to use EL within
 Velocity, FreeMarker, Thymleaf, etc. Not everyone uses JSP.

 Someone could probably create ElValueStack and ElValueStackFactory
 implementations. OGNL is also used for the framework's type conversion.


 On Wed, Sep 4, 2013 at 2:04 PM, Doug Erickson erick...@part.net wrote:

  A lot of my feelings about OGNL are summed up in a StackOverflow answer
 of
  mine:
 
   http://stackoverflow.com/a/**341597/3474
 http://stackoverflow.com/a/341597/3474
 
  A couple of points from there I'd like to stress:
 
  JSTL and OGNL are not comparable. A few people have mentioned JSTL today,
  but hopefully they were talking about EL. More precision with these terms
  would clarify the discussion.
 
  EL is supported by the container. It works with any framework. As a JEE
  spec, tool support for EL is also better (i.e., it exists).
 
  Ten or twelve years ago, OGNL was a defensible choice to fulfill an unmet
  need, but now we have EL. I would question whether any great deliberation
  went into WebWork's original adoption of OGNL. I'm curious if Struts2
  developers remember if the issue was considered when adopting WebWork.
 
  My ideal is that you shouldn't be able to tell what framework is used on
  the server just by looking at the JSPs. Obviously, enforcing that  in
  Struts2 would be too disruptive, but it's a practice that developers can
  choose voluntarily in the view layer.
 
  What can we do to restrict and harden the non-view components against
  these crippling OGNL-based vulnerabilities?
 
  On 09/04/2013 07:04 AM, Christian Grobmeier wrote:
 
  Folks,
 
   ...
 
   My impression is OGNL is not easy to understand and there
  is not really much interest from other people to develop on it.
 
   ...
 
   Any feelings on that?
 
 
  --**--**-
  To unsubscribe, e-mail: dev-unsubscribe@struts.apache.**org
 dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 




-- 
Cheers,
Paul

Re: Add to ParameterNameAware JavaDoc Warning About Using?

[Paul Benedict]

If you need unfiltered access, wouldn't the correct answer be to remove
the filter on the action?


On Wed, Aug 7, 2013 at 4:18 AM, Lukasz Lenart lukaszlen...@apache.orgwrote:

 return acceptableName(name) || (parameterNameAware != null 
 parameterNameAware.acceptableParameterName(name)
 ^^
 this part was changed from  to || - ParametersInterceptor, line 348


 Regards
 --
 Łukasz
 + 48 606 323 122 http://www.lenart.org.pl/

 2013/8/6 Paul Benedict pbened...@apache.org:
  Can you clarify what changed in 2.3.7?
 
 
  On Tue, Aug 6, 2013 at 3:01 AM, Lukasz Lenart lukaszlen...@apache.org
 wrote:
 
  2013/8/2 Paul Benedict pbened...@apache.org:
   If we changed ParameterNameAware interceptor so that it adheres to the
   filtering of the interceptor, then I think we did the right thing.
 That
   should be how the two work together. I would add how the two interact
 to
   BOTH javadoc headers.
 
  I'm not sure if I get you right - the behaviour of these two changed
  sometime ago (as from 2.3.7 as I can recall). And my doubt is if it
  was a good move. Right now is clearer for me what are the
  responsibilities of these two. But maybe I'm wrong?
 
 
  Regards
  --
  Łukasz
  + 48 606 323 122 http://www.lenart.org.pl/
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
  For additional commands, e-mail: dev-h...@struts.apache.org
 
 
 
 
  --
  Cheers,
  Paul

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




-- 
Cheers,
Paul