@Nathan
> We are in the middle of a 2.3 -> 2.5 conversion now, would hate to do
it again.
Can you elaborate on why it was difficult to migrate (if it was :) )?
Have you followed migration guide [1]? It is pretty straightforward.
As for the java version I would suggest using java 8, 2.5.x
We discussed it before but it was quite some time ago. How about
upgrading to jdk8 in 2.6 version?
- Java versions are now released more frequently
- 2.5.x will still be on jdk7
- Currently custom converters must be created to use java 8 date/time
classes
- Currently date tag is useless with
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[x] General Availability (GA)
+1 binding
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
> I think the basic idea was that, it's not I18Interceptor
responsibility to create a session.
Technically it is not I18Interceptor who creates session, it is specific
implementation of LocaleHandler - SessionLocaleHandler. If someone
doesn't like what default LocaleHandler does, then
Hello.
Can someone shed some light on why I18nInterceptor no longer creates
session in SessionLocaleHandler#store method? [1] [2]
What was wrong with previous behavior?
After all, it is `Storage.SESSION` storage which should operate on
session. If someone doesn't want to use session then
> @dev wdyt? I thought what about add integration with front-end trends
e.g. React, Angular, Vu.js, Node.js?
Node.js is not front-end.
You can use Struts with js front-ends, all you need is to serve json.
Which can be achieved with rest or json plugin.
Speaking of which, the json plugin can
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
Hello,
Seems that coveralls shows coverage of the PR-s like it is in the master
branch. Can we do something about that?
Also it reports that "coverage remained the same" for this build [1],
which adds tests for new files.
Can someone explain that?
[1] https://coveralls.io/builds/16057728
> [ ] Leave at test build
> [ ] Alpha
> [ ] Beta
> [X] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
> [ ] Leave at test build
> [ ] Alpha
> [ ] Beta
> [X] General Availability (GA)
+1 binding
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
+1 GA, binding
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
Hi,
Right now some PR-s have quit large number of commits. Even PR-s that
fix pretty trivial issues tend to grow fast (test fixes, improving stuff
that came up in the review, etc.)
That makes it harder to pinpoint exact commit that addressed issue at hand.
There is a Squash and merge option
> Right but the version will be 2.5.6 (the archetypes live they own
> release cycle now) or we can mark them as 3.0 or whatever we think it
> should be :)
How do we going to communicate this to users? Right now maven-archetypes
page [1] says -DarchetypeVersion=.
[1]
>> Maybe we should think about the way to release version which will
hold only
>> the fix. Separate branch for patches or something.
> I don't understand what you mean by this.
> Can you please explain?
Right now most releases which hold security fixes hold new features as
well. The point is
Even with BOM it will be a version nightmare.
Maybe we should think about the way to release version which will hold
only the fix. Separate branch for patches or something.
---
Regards,
Aleksandr
-
To unsubscribe, e-mail:
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[x] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
> That would be awesome but it's hard if there are just few who test the
> latest test build ;-) That being said, I'm going to extend a test
> build period and instead of a week give a month for everyone to test
> it, hope this allow reduce such problems.
Month seems like a long leap from the
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 binding
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Maybe this can help: http://www.viaboxx.de/code/confluence2md/
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Hi,
> does 'unassigned' mean no one already work on it?
Usually, yes.
> is it better to solve old reported one or newer ones?
Pick the one you can solve. Just make sure that particular issue is
still relevant.
Looking forward to see PR-s from you.
---
Regards,
Aleksandr
+1
Can we export some of the pages from Confluence to MD?
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
> but then having a dedicated class doesn't make sense, we cannot
> control how those parameters are accessed. I know that there is no
> much gain right now but I hope it will improve (as with accessors).
Map interface implementation it is, then.
---
Regards,
Aleksandr
>>> I would rather implement Map interface in HttpParameters and keep
>>> backward compatibility, wdyt?
>>
>> Yes, or maybe just convert HttpParameters to Map in Dispatcher.
>
> It won't work, I mean it will work only for EL expression, i.e.:
> ${parameters.contains('error')} but not for OGNL
Maybe Servlet 3.0 and JSP 2.2.
For example: Apache Tomcat implements both in it 7.0.x series, which is
available since ~2011.
And support for the Apache Tomcat 6.0.x will end on 31 December 2016.
---
Regards,
Aleksandr
-
To
> I would rather implement Map interface in HttpParameters and keep
> backward compatibility, wdyt?
Yes, or maybe just convert HttpParameters to Map in Dispatcher.
---
Regards,
Aleksandr
-
To unsubscribe, e-mail:
Now I've noticed the property accessors. :)
We should probably indicate somewhere that now if there is no parameters
the "#parameters" is not an empty collection and that
"#parameters.contains('error')" must be used instead of
"#parameters.containsKey('error')".
---
Regards,
Aleksandr
Just to clarify. From now on the "parameters" on JSP will be
HttpParameters instead of a Map, and should be used something like
#parameters.get('error').value ?
---
Regards,
Aleksandr
-
To unsubscribe, e-mail:
Instant is since 1.8, S2 is currently on 1.7.
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Hello,
Currently supports java.util.Date and java.util.Calendar. How
about adding support for long?
It will allow to display timestamps of long type w/o converting them and
to do some arithmetics on date on JSP w/o creating intermediate date object.
E.g.
and
Implemented this
> [ ] Leave at test build
> [ ] Alpha
> [ ] Beta
> [X] General Availability (GA)
+1 (binding)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
Started Struts 2.3 to 2.5 migration guide -
https://cwiki.apache.org/confluence/display/WW/Struts+2.3+to+2.5+migration
Feel free to improve / add additional steps (SMI, DMI, Tiles, etc.).
---
Regards,
Aleksandr
-
To
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
+1 not binding
--
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
A lot of parenthesis :)
Great, thanks!
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
>>2016-05-06 10:19 GMT+02:00 Aleksandr Mashchenko <amashche...@apache.org>:
>> Some strange issue here with 2.5.
>>
>> Required labels are shown on both sides of the label. Seems like
both if-s
>> in xhtml controlheader-core.ftl evaluate to true.
>>
> Has the s:div tag been removed?
Yes, is was left over from ajax theme.
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Some strange issue here with 2.5.
Required labels are shown on both sides of the label. Seems like both
if-s in xhtml controlheader-core.ftl evaluate to true.
https://github.com/apache/struts/blob/master/core/src/main/resources/template/xhtml/controlheader-core.ftl#L65
and
Apparently it is broken by this commit -
https://github.com/apache/struts/commit/098ee502b406235755b939c7ef44a8b6cbf9416e.
Doesn't work with 2.4 as well.
---
Regards,
Aleksandr
-
To unsubscribe, e-mail:
+1 not binding
[ ] Leave at test build
[ ] Alpha
[ ] Beta
[X] General Availability (GA)
---
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail:
+1 for merging tiles PR
Regards,
Aleksandr
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
42 matches
Mail list logo
