XWork 2.1.3 released
Hi, I just released XWork 2.1.3... So, as soon as the maven repositories are mirrored, we could start with the Struts 2.1.7 release. cheers, Rainer -- Rainer Hermanns aixcept Willibrordstraße 82 52134 Herzogenrath - Germany w: http://aixcept.de/ t: +49 - 2406 - 979 22 11 f: +49 - 2406 - 979 22 13 m: +49 - 170 - 343 29 12 - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork 2.1.3 released
thanks Rainer. musachy On Fri, Apr 24, 2009 at 9:07 AM, Rainer Hermanns wrote: > Hi, > > I just released XWork 2.1.3... > So, as soon as the maven repositories are mirrored, we could start with > the Struts 2.1.7 release. > > cheers, > Rainer > > > -- > Rainer Hermanns > aixcept > Willibrordstraße 82 > 52134 Herzogenrath - Germany > w: http://aixcept.de/ > t: +49 - 2406 - 979 22 11 > f: +49 - 2406 - 979 22 13 > m: +49 - 170 - 343 29 12 > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving struts assembly to a profile
+42.5 at least ... Rainer Hermanns schrieb: > Wes, > > +42, please do so... that was disturbing me as well a lot :) > The build takes currently "forever", just to download all the docs. > > Thanks, > Rainer > >> Hey guys, >> >> Unless someone can raise a decent reason not to do it, I'd like to >> move the assembly in the struts2 build into it's own profile. I don't >> mind Hudson and Bamboo creating the zips through the assembly module, >> but I like to keep up-to-date and running mvn clean install -Pall on >> my machine takes an extra ten minutes. Moving it into a profile will >> still leave it available, but you'll have to do 'mvn -Pall,assembly >> install' to build. 'mvn -Pall install' will build everything it builds >> now, except the assembly. >> >> Anyone have a problem with that? >> >> -Wes >> >> -- >> Wes Wannemacher >> Author - Struts 2 In Practice >> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more >> http://www.manning.com/wannemacher >> >> - >> 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: Moving struts assembly to a profile
Rene, I went ahead and did it yesterday. Now, if you want to build everything except mirror the wiki and zip up everything, just do - mvn clean install -DskipAssembly I know in my case, it shaves off 10 minutes from a 15 minute build. -Wes On Fri, Apr 24, 2009 at 11:57 AM, Rene Gielen wrote: > +42.5 at least ... > > Rainer Hermanns schrieb: >> Wes, >> >> +42, please do so... that was disturbing me as well a lot :) >> The build takes currently "forever", just to download all the docs. >> >> Thanks, >> Rainer >> >>> Hey guys, >>> >>> Unless someone can raise a decent reason not to do it, I'd like to >>> move the assembly in the struts2 build into it's own profile. I don't >>> mind Hudson and Bamboo creating the zips through the assembly module, >>> but I like to keep up-to-date and running mvn clean install -Pall on >>> my machine takes an extra ten minutes. Moving it into a profile will >>> still leave it available, but you'll have to do 'mvn -Pall,assembly >>> install' to build. 'mvn -Pall install' will build everything it builds >>> now, except the assembly. >>> >>> Anyone have a problem with that? >>> >>> -Wes >>> >>> -- >>> Wes Wannemacher >>> Author - Struts 2 In Practice >>> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more >>> http://www.manning.com/wannemacher >>> >>> - >>> 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 > > -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Moving struts assembly to a profile
Great, I built a few times yesterday and wasn't aware of the already existing change. This is a real time (and nerve..) saver! BTW, did not know that property inversion with ! works. Always good to have a Maven guru on board *wavingHandsTowardsWendy* Wes Wannemacher schrieb: > Rene, > > I went ahead and did it yesterday. Now, if you want to build > everything except mirror the wiki and zip up everything, just do - > > mvn clean install -DskipAssembly > > I know in my case, it shaves off 10 minutes from a 15 minute build. > > -Wes > > On Fri, Apr 24, 2009 at 11:57 AM, Rene Gielen wrote: >> +42.5 at least ... >> >> Rainer Hermanns schrieb: >>> Wes, >>> >>> +42, please do so... that was disturbing me as well a lot :) >>> The build takes currently "forever", just to download all the docs. >>> >>> Thanks, >>> Rainer >>> Hey guys, Unless someone can raise a decent reason not to do it, I'd like to move the assembly in the struts2 build into it's own profile. I don't mind Hudson and Bamboo creating the zips through the assembly module, but I like to keep up-to-date and running mvn clean install -Pall on my machine takes an extra ten minutes. Moving it into a profile will still leave it available, but you'll have to do 'mvn -Pall,assembly install' to build. 'mvn -Pall install' will build everything it builds now, except the assembly. Anyone have a problem with that? -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher - 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
Re: Ready for Struts 2.2 and XWork 2.2?
to add some ideas that came to my mind lately: Rework on i18n support 1. create a TextProviderNextGen component that can easily be used and injected 2. create a TextProvider interceptor which - sets up a TextProvider - sets it on an Action implementing TextProviderAware interface - pushes the TextProvider on the stack to have a mixin/"trait"-like functionality 3. make formats easier to use in tags (textfield, property, select etc) - add a "format" property to name a text format to apply to the value - provide predefined default formats like number, money, percent comments: 1. The new component would give us the opportunity to get out of the TextProvider hell without braking backwards compatibility 2. Extracting TextProvider functionality to an aspect would remove the main reason to extend ActionSupport. While Actions would explicitly declare their need for TextProvider as a component, the view developer would still be able to use getText(...) expressions directly (via TextProvider residing on the stack), without the need to write textProvider.getText(...) given TextProviderAware introduces a textProvider property on the action. 3. Although the use of getText expressions provide all the needed functionality for i18n/l10n support, they are quite clumsy to use when it comes to the widely used pattern of applying text formats to numbers and dates. Adding a convenience property named format would held view developers to get very easy access to those formats, without the need to understand the getText signatures (I have to constantly look it up again) for their most common use cases. Providing some reasonable default formats would make it work out of the box, while the developer could define additional formats as well as use getText expressions like before when it comes to multiparameter formats etc. That said, should we go to setup a (s|x) 2.2 roadmap in Confluence? - Rene Don Brown schrieb: > Off the top of my head: > * Split out the XML parser from XmlConfigurationProvider so that you > can parse XML from any source > * Get rid of all the Class.forName() calls in XWork > > I'd rather not do this on a stable branch, particularly since new > public classes will be created. How many changes are there in 2.1.7 > and 2.1.3 that haven't been released? Could we get those releases out > the door so we know we branch at a known good state? > > Don > > On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso wrote: >> I think we are good. What changes do you have in mind?, the OSGi >> plugin could take advantage of some refactoring of xwork so I am >> interested :) >> >> musachy >> >> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown wrote: >>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it >>> off and move trunk to 2.2? I was wanting to do some refactoring of >>> how XWork configuration is loaded and parsed, but new classes and the >>> like really isn't appropriate for a patch/micro release. >>> >>> Any objections to the branching? >>> >>> Don >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> - >> 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
Re: about OGNL and parameter binding
Great stuff!
wouldn't that be a good topic for the XW/S 2.2 branches discussed lately?
Musachy Barroso schrieb:
> Not yet, the MVEL stuff is pretty much a draft at this moment. We
> could roll this in 2 steps, first stop using OGNL for parameter
> binding, and then, plugin MVEL. After #1 is achieve, #2 should be
> easy. The good thing is that the new parameter binding implementation
> can be turned on/off with a constant, so we can get people to test it
> for a while with no risk. I will commit it sometime this week.
>
> musachy
>
> On Tue, Apr 21, 2009 at 5:56 PM, Mathias Bogaert
> wrote:
>> Musachy,
>>
>> Great stuff! Is the new implementation using ScriptEngine (JSR 223) in
>> some way? Both OGNL and MVEL have a ScriptEngineFactory
>> implementation, and many other scripting languages do, maximal
>> decoupling.
>>
>> Regards,
>>
>> Mathias
>>
>> On Sun, Apr 19, 2009 at 11:28 PM, Musachy Barroso wrote:
>>> Every attempt to replace OGNL by another EL library hits a big wall
>>> because of the tight integration between xwork and OGNL. The biggest
>>> problem comes from the "magical" instantiation of null objects in
>>> expressions, and type conversion (applied together). This magic
>>> instantiation is only used during parameter binding.
>>>
>>> That being said, I am toying with a new implementation of the
>>> parameter binding process, which does not use OGNL and is very simple.
>>> It doesn't support any fancy expressions, besides nested and indexed
>>> properties. The null handling (instantiation) and type conversion work
>>> the same (existing classes are used). The advantages of using this
>>> implementation are:
>>>
>>> # decoupling. We don't depend on OGNL for parameter binding, so to
>>> plugin in a new EL we just need to provide a new ValueStack (with its
>>> helper classes) (then I can finally use my MVEL implementation..woot!)
>>> # security. We don't need to worry about parameter names being
>>> evaluated as evil expression ("System.exit(1)"="die die!")
>>> # performance. Parameter binding will be faster (no big deal really)
>>>
>>> I would say the main reason to do something like this, is that it give
>>> us the possibility of getting rid of OGNL eventually, which is not
>>> possible now, and as far as I know, OGNL is not maintained anymore.
>>>
>>> thoughts?
>>>
>>> musachy
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> -
>>> 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
Re: about OGNL and parameter binding
oh yeah, this would definitely go into another branch. I am almost
done with it, I am adding more tests.
musachy
On Fri, Apr 24, 2009 at 12:54 PM, Rene Gielen wrote:
> Great stuff!
>
> wouldn't that be a good topic for the XW/S 2.2 branches discussed lately?
>
> Musachy Barroso schrieb:
>> Not yet, the MVEL stuff is pretty much a draft at this moment. We
>> could roll this in 2 steps, first stop using OGNL for parameter
>> binding, and then, plugin MVEL. After #1 is achieve, #2 should be
>> easy. The good thing is that the new parameter binding implementation
>> can be turned on/off with a constant, so we can get people to test it
>> for a while with no risk. I will commit it sometime this week.
>>
>> musachy
>>
>> On Tue, Apr 21, 2009 at 5:56 PM, Mathias Bogaert
>> wrote:
>>> Musachy,
>>>
>>> Great stuff! Is the new implementation using ScriptEngine (JSR 223) in
>>> some way? Both OGNL and MVEL have a ScriptEngineFactory
>>> implementation, and many other scripting languages do, maximal
>>> decoupling.
>>>
>>> Regards,
>>>
>>> Mathias
>>>
>>> On Sun, Apr 19, 2009 at 11:28 PM, Musachy Barroso wrote:
Every attempt to replace OGNL by another EL library hits a big wall
because of the tight integration between xwork and OGNL. The biggest
problem comes from the "magical" instantiation of null objects in
expressions, and type conversion (applied together). This magic
instantiation is only used during parameter binding.
That being said, I am toying with a new implementation of the
parameter binding process, which does not use OGNL and is very simple.
It doesn't support any fancy expressions, besides nested and indexed
properties. The null handling (instantiation) and type conversion work
the same (existing classes are used). The advantages of using this
implementation are:
# decoupling. We don't depend on OGNL for parameter binding, so to
plugin in a new EL we just need to provide a new ValueStack (with its
helper classes) (then I can finally use my MVEL implementation..woot!)
# security. We don't need to worry about parameter names being
evaluated as evil expression ("System.exit(1)"="die die!")
# performance. Parameter binding will be faster (no big deal really)
I would say the main reason to do something like this, is that it give
us the possibility of getting rid of OGNL eventually, which is not
possible now, and as far as I know, OGNL is not maintained anymore.
thoughts?
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
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
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork - Overriding interceptors in sub package (XW-554)
although hard to realize, I find the idea really intriguing. Given e.g. you would provide a NoOperationInterceptor, it would let you selectively disable interceptors when needed, without repeating stack configs. Given the configuration immutability, how does the JavaRebel Struts2 plugin work - anybody knows? Nils-Helge Garli Hegvik schrieb: > I would like a feature in XWork that allows sub packages to override > interceptors in the interceptor stacks > (http://jira.opensymphony.com/browse/XW-554). What I want is that if I > define an interceptor in a package with a name that already exists in > parent packages, I want all the stacks that are using this interceptor > to use the one defined in the local package instead, but only for this > package and it's sub packages. The reason I want to be able to do this > is so that I don't have to redefine all the stacks with my new > interceptor, which would be particularly useful with the portlet > plugin, which needs some tweaks to existing interceptors for them to > work in a portlet environment. This is an area of XWork I have little > experience with, and I've been digging through the XWork code base, > but I have not yet found out how to achieve this. I guess I could > either override the interceptors "configuration time", or at runtime. > I'm not sure what happens when, and if/how I can modify the behaviour > to do what I want. So if anyone have any ideas and pointers to where > to start, I'd be grateful. > > Nils-H > > - > 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: Ready for Struts 2.2 and XWork 2.2?
We should include/improve a flash result/scope for 2.2: https://issues.apache.org/struts/browse/WW-2635 an yes, we should start drafting some sort of roadmap. musachy On Fri, Apr 24, 2009 at 12:49 PM, Rene Gielen wrote: > to add some ideas that came to my mind lately: > > Rework on i18n support > 1. create a TextProviderNextGen component that can easily be used and > injected > 2. create a TextProvider interceptor which > - sets up a TextProvider > - sets it on an Action implementing TextProviderAware interface > - pushes the TextProvider on the stack to have a mixin/"trait"-like > functionality > 3. make formats easier to use in tags (textfield, property, select etc) > - add a "format" property to name a text format to apply to the value > - provide predefined default formats like number, money, percent > > comments: > 1. The new component would give us the opportunity to get out of the > TextProvider hell without braking backwards compatibility > > 2. Extracting TextProvider functionality to an aspect would remove the > main reason to extend ActionSupport. While Actions would explicitly > declare their need for TextProvider as a component, the view developer > would still be able to use getText(...) expressions directly (via > TextProvider residing on the stack), without the need to write > textProvider.getText(...) given TextProviderAware introduces a > textProvider property on the action. > > 3. Although the use of getText expressions provide all the needed > functionality for i18n/l10n support, they are quite clumsy to use when > it comes to the widely used pattern of applying text formats to numbers > and dates. Adding a convenience property named format would held view > developers to get very easy access to those formats, without the need to > understand the getText signatures (I have to constantly look it up > again) for their most common use cases. Providing some reasonable > default formats would make it work out of the box, while the developer > could define additional formats as well as use getText expressions like > before when it comes to multiparameter formats etc. > > That said, should we go to setup a (s|x) 2.2 roadmap in Confluence? > > - Rene > > Don Brown schrieb: >> Off the top of my head: >> * Split out the XML parser from XmlConfigurationProvider so that you >> can parse XML from any source >> * Get rid of all the Class.forName() calls in XWork >> >> I'd rather not do this on a stable branch, particularly since new >> public classes will be created. How many changes are there in 2.1.7 >> and 2.1.3 that haven't been released? Could we get those releases out >> the door so we know we branch at a known good state? >> >> Don >> >> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso wrote: >>> I think we are good. What changes do you have in mind?, the OSGi >>> plugin could take advantage of some refactoring of xwork so I am >>> interested :) >>> >>> musachy >>> >>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown wrote: Now that 2.1 is GA (thanks guys and gals), are we ready to branch it off and move trunk to 2.2? I was wanting to do some refactoring of how XWork configuration is loaded and parsed, but new classes and the like really isn't appropriate for a patch/micro release. Any objections to the branching? Don - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >>> -- >>> "Hey you! Would you help me to carry the stone?" Pink Floyd >>> >>> - >>> 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 > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: XWork - Overriding interceptors in sub package (XW-554)
Configuration is semi-inmutable(oxymoron?), you can add and remove packages, but you cannot modify an action config, or a package config. You can also reload the whole configuration, which is what Convention and the XML config do when files are modified. musachy On Fri, Apr 24, 2009 at 1:05 PM, Rene Gielen wrote: > although hard to realize, I find the idea really intriguing. Given e.g. > you would provide a NoOperationInterceptor, it would let you selectively > disable interceptors when needed, without repeating stack configs. > Given the configuration immutability, how does the JavaRebel Struts2 > plugin work - anybody knows? > > Nils-Helge Garli Hegvik schrieb: >> I would like a feature in XWork that allows sub packages to override >> interceptors in the interceptor stacks >> (http://jira.opensymphony.com/browse/XW-554). What I want is that if I >> define an interceptor in a package with a name that already exists in >> parent packages, I want all the stacks that are using this interceptor >> to use the one defined in the local package instead, but only for this >> package and it's sub packages. The reason I want to be able to do this >> is so that I don't have to redefine all the stacks with my new >> interceptor, which would be particularly useful with the portlet >> plugin, which needs some tweaks to existing interceptors for them to >> work in a portlet environment. This is an area of XWork I have little >> experience with, and I've been digging through the XWork code base, >> but I have not yet found out how to achieve this. I guess I could >> either override the interceptors "configuration time", or at runtime. >> I'm not sure what happens when, and if/how I can modify the behaviour >> to do what I want. So if anyone have any ideas and pointers to where >> to start, I'd be grateful. >> >> Nils-H >> >> - >> 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 > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
