Re: Doubting OGNL

Am 11.09.13 07:54, schrieb Lukasz Lenart: > 2013/9/11 David Black : >> On 9 September 2013 20:52, Christian Grobmeier wrote: >> >> >> From a security standpoint we may have the man power to improve things. >> For example, if we manage to "disable static method" calls from OGNL we >> would have a w

Re: Doubting OGNL

Yes, but we can do it via custom SecurityManager - as I understand OGNL uses SM internally quite often. 2013/9/11 Christian Grobmeier : > Am 11.09.13 07:54, schrieb Lukasz Lenart: >> 2013/9/11 David Black : >>> On 9 September 2013 20:52, Christian Grobmeier wrote: >>> >>> >>> From a security stan

Re: Docs: Working on Struts main

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 : > 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 b

Re: Working with GitHub

2013/9/10 Christian Grobmeier : > Hi all, > > i am currently documenting a way people can contribute using github. > Basically its all pretty easy with one exception: people cannot send us > pull requests > when they work with the official Struts mirror: > > https://github.com/apache/struts2 > > I

Svn to Git migration

Hi, I'd like to start discussion about the migration process - there are few things we must clarify, at least: - Git structure - development flow I think we should have just one repo: git.apache.org/struts.git and diverse versions internally via branches - so the current S2 source become the base

bad commits with git... (was: Re: svn commit: r1521783 - in /struts/struts2/trunk/archetypes/struts2-archetype-angularjs: ./ src/main/resources/META-INF/maven/ src/main/resources/archetype-resources/

Hi, its easy to mess up the svn repos with git - prove below :-) I forked from the official struts-mirror and added our svn as git svn repos. The I tried to merge the strutsathon outcome (angularjs) with my repo. Somewhere in between Johannes added the files manually to SVN. I fetched and tried t

Build failed in Jenkins: Struts2-JDK6 #797

See Changes: [grobmeier] Add archetype for Struts2 with AngularJS -- [...truncated 9597 lines...] [JENKINS] Archiving

Re: Svn to Git migration

I use gitflow in my day job and its a great workflow. +1 On Wednesday, September 11, 2013, Lukasz Lenart wrote: > Hi, > > I'd like to start discussion about the migration process - there are > few things we must clarify, at least: > - Git structure > - development flow > > I think we should have

Jenkins build is back to normal : Struts2-JDK6 #798

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

Re: Svn to Git migration

Am 11.09.13 11:24, schrieb Lukasz Lenart: > Hi, > > I'd like to start discussion about the migration process - there are > few things we must clarify, at least: > - Git structure > - development flow > > I think we should have just one repo: git.apache.org/struts.git and > diverse versions internal

Re: Svn to Git migration

Use tags for all released versions, rather than keeping branches for them. As for Struts 2.5 or 3.0, I'd probably use feature branches for those. On Wed, Sep 11, 2013 at 10:19 AM, Christian Grobmeier wrote: > Am 11.09.13 11:24, schrieb Lukasz Lenart: > > Hi, > > > > I'd like to start discussion

Proposal: "required" attribute changes (related to WW-4188)

So as not to pollute the JIRAs too much with speculation or suggestions that haven't been thought out, I'd like to have a discussion about the "required" attribute here on the list. I propose that we revert the changes made in WW-3908, namely -- turn "requiredLabel" back into "required." Then, t

Re: Proposal: "required" attribute changes (related to WW-4188)

I already updated to requiredLabel, so I vote we stick with that. :) Besides, requiredLabel actually makes more sense, since that's all it does. You could invert the logic you proposed so that if a required attribute is detected with a value of anything but "false", you consider that to trigger re

Build failed in Jenkins: Struts2-JDK6 #799

See Changes: [jogep] Revert: WW-4197 Update Archetypes READMEs [jogep] WW-4197 Update Archetypes READMEs -- [...truncated 7516 lines...] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 Sep 11, 201

Re: Proposal: "required" attribute changes (related to WW-4188)

Okay thank you for the clarification. I had changed my copy of themes/simple/text.ftl to add the html5 attribute in the case when "required=true" was set. This continues to work fine for me when I set "requiredLabel=true" -- so in my case it does have an additional (beneficial) side effect, in t

Re: Proposal: "required" attribute changes (related to WW-4188)

I see -- I was under the mistaken impression that "requiredLabel" before 2.3.12 defined -- at the field level -- which character would be used to indicate that a field is required. Similar to how "labelSeparator" works. I see now that the character used is hard-coded to an asterisk, and that "re

Re: Proposal: "required" attribute changes (related to WW-4188)

Nope, it's just the asterisk. Backend validation is handled in the action's validate method or validation XML. On Wednesday, September 11, 2013, struts wrote: > I see -- I was under the mistaken impression that "requiredLabel" before > 2.3.12 defined -- at the field level -- which character would

Proposal: "required" attribute changes (related to WW-4188)

So as not to pollute the JIRAs too much with speculation or suggestions that haven't been thought out, I'd like to have a discussion about the "required" attribute here on the list. I propose that we revert the changes made in WW-3908, namely -- turn "requiredLabel" back into "required." Then, t