You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Robert Graf-Waczenski <rg...@lsoft.com> on 2009/11/26 12:48:30 UTC
S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Hi,
we are currently in the process of evaluating if upgrading our app from
Struts 2.1.6 to 2.1.8.1 is feasible. Currently it is not because various
things stopped working, but i'll like to work on one of them at a time.
We frequently (*very* frequently, actually) use property names such as
"mProperty" which are to be bound to class member variables of the same
name and get/set via methods called "getmProperty" and "setmProperty".
This practice deviates from the JavaBean rules for property access, i.e.
in this example, the getter would have to be called getMProperty and the
setter setMProperty (each with a capital M). Struts 2.1.6 was able to
map the property "mProperty" to calls to getmProperty and setmProperty,
respectively. Struts 2.1.8.1 apparently does not have this leniency (or
faulty behavior, depending on your POV...) and behaves strictly
according to what Introspector.decapitalize() does.
Since we (obviously) don't want to rename the myriads of
getters/setters, i'd like to know if there is a way around this, maybe
with a custom interceptor somewhere?
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Posted by Rafał Krupiński <r....@gmail.com>.
On Thu, Nov 26, 2009 at 4:01 PM, Robert Graf-Waczenski <rg...@lsoft.com> wrote:
> Hi,
>
> we do of course use a refactoring tool, but we are talking about a huge
> amount of methods. I'm not aware of a refactoring tool that would allow me
> to rename *all* methods in *one* step.
jEdit should be powerful enough to open each java file in project
directory, find all strings matching regex:
([sg]et)([a-z])Property\(
replace it with:
$1\u$2Property\(
This should work for both getters and setters and make first character
upper case, assuming you have get[1character]Property() pattern.
All this in one step.
--
Pozdrawiam / Best Regards
Rafal Krupinski
http://www.linkedin.com/in/krupinskir
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Posted by Saeed Iqbal <sa...@gmail.com>.
I would think that is a feature of Struts that it requires proper OOP names.
On Thu, Nov 26, 2009 at 8:01 PM, Robert Graf-Waczenski <rg...@lsoft.com>wrote:
> Hi,
>
> we do of course use a refactoring tool, but we are talking about a huge
> amount of methods. I'm not aware of a refactoring tool that would allow me
> to rename *all* methods in *one* step.
>
> Robert
>
> Rafał Krupiński schrieb:
>
> Robert Graf-Waczenski pisze:
>>
>>> Hi,
>>>
>> [...]
>>
>>> Since we (obviously) don't want to rename the myriads of getters/setters,
>>> i'd like to know if there is a way around this, maybe with a custom
>>> interceptor somewhere?
>>>
>>
>> Hi
>> If the only problem is the number of methods to be changed, maybe you
>> should consider using a refactoring tool.
>>
>> -you do that only once
>> -your code is kosher
>> -you don't get performance overhead introduced by another interceptor
>>
>>
>> Regards
>> Rafał
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Saeed Iqbal
http://www.iqbalconsulting.com
Struts - J2EE - Application Architect / Developer
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Posted by Musachy Barroso <mu...@gmail.com>.
You could write your own value stack that extends the OGNLValueStack
and just hacks the property name to make it the right/wrong case, but
oh boy does that scream trouble :)
musachy
On Thu, Nov 26, 2009 at 9:04 AM, Bill Bohnenberger <bi...@gmail.com> wrote:
> What an amusing thread. It seems to me the only problem here is the arrogant
> SOB that decided to defy the Bean naming conventions. LOL. (No offense
> intended if he is present company :)
>
> With affection,
> Bill
>
> On Thu, Nov 26, 2009 at 8:31 AM, Robert Graf-Waczenski <rg...@lsoft.com>wrote:
>
>> Rafał Krupiński schrieb:
>>
>> On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski <rg...@lsoft.com>
>>> wrote:
>>>
>>>
>>>> approach, which is tedious work because
>>>>
>>>>
>>> [...]
>>>
>>>
>>>> i have to go through each applicable class and
>>>> refactor-rename each method.
>>>>
>>>>
>>>
>>> Please don't try to make us feel guilty :-)
>>> You'll get paid for this, we're not.
>>>
>>> In previous post I stated clearly: "If the only problem is the number
>>> of methods to be changed"
>>> not "If you can change only some classes".
>>>
>>>
>>>
>>>
>> Well, yes, i am getting paid for this. So the time that i need to rename
>> the methods costs my employer big money.
>>
>> This is a case of true backwards incompatibility and causes trouble in
>> non-trivial projects such as ours. Other projects may decide to not upgrade
>> from earlier Struts versions to V 2.1.8.1, which is something i would
>> definitely take serious if i were working without getting paid, because
>> having your stuff used by as many people out there as possible is a major
>> point of FOSS, right? Freedom of choice is the other, meaning that we could
>> of course stick with V2.1.6 and patch it to our liking. I personally voted
>> against the latter option and decided to go for the renaming option because
>> we need some other fixes that are available in 2.1.8. And, to tell the
>> truth, our choice to use "getmProperty()" as accessor method naming pattern
>> was a bad one originally but we lived with it since the beginning and are
>> now being bitten in the behind :-)
>>
>> Robert
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar
to 2.1.6)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
The SOB you are talking about is a well-respected (and present)
colleague of mine and our team backed the decision, so the fun (which i
was not observing as you did) ends exactly here :-(
Robert
Bill Bohnenberger schrieb:
> What an amusing thread. It seems to me the only problem here is the arrogant
> SOB that decided to defy the Bean naming conventions. LOL. (No offense
> intended if he is present company :)
>
> With affection,
> Bill
>
> On Thu, Nov 26, 2009 at 8:31 AM, Robert Graf-Waczenski <rg...@lsoft.com>wrote:
>
>
>> Rafał Krupiński schrieb:
>>
>> On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski <rg...@lsoft.com>
>>
>>> wrote:
>>>
>>>
>>>
>>>> approach, which is tedious work because
>>>>
>>>>
>>>>
>>> [...]
>>>
>>>
>>>
>>>> i have to go through each applicable class and
>>>> refactor-rename each method.
>>>>
>>>>
>>>>
>>> Please don't try to make us feel guilty :-)
>>> You'll get paid for this, we're not.
>>>
>>> In previous post I stated clearly: "If the only problem is the number
>>> of methods to be changed"
>>> not "If you can change only some classes".
>>>
>>>
>>>
>>>
>>>
>> Well, yes, i am getting paid for this. So the time that i need to rename
>> the methods costs my employer big money.
>>
>> This is a case of true backwards incompatibility and causes trouble in
>> non-trivial projects such as ours. Other projects may decide to not upgrade
>> from earlier Struts versions to V 2.1.8.1, which is something i would
>> definitely take serious if i were working without getting paid, because
>> having your stuff used by as many people out there as possible is a major
>> point of FOSS, right? Freedom of choice is the other, meaning that we could
>> of course stick with V2.1.6 and patch it to our liking. I personally voted
>> against the latter option and decided to go for the renaming option because
>> we need some other fixes that are available in 2.1.8. And, to tell the
>> truth, our choice to use "getmProperty()" as accessor method naming pattern
>> was a bad one originally but we lived with it since the beginning and are
>> now being bitten in the behind :-)
>>
>> Robert
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Posted by Bill Bohnenberger <bi...@gmail.com>.
What an amusing thread. It seems to me the only problem here is the arrogant
SOB that decided to defy the Bean naming conventions. LOL. (No offense
intended if he is present company :)
With affection,
Bill
On Thu, Nov 26, 2009 at 8:31 AM, Robert Graf-Waczenski <rg...@lsoft.com>wrote:
> Rafał Krupiński schrieb:
>
> On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski <rg...@lsoft.com>
>> wrote:
>>
>>
>>> approach, which is tedious work because
>>>
>>>
>> [...]
>>
>>
>>> i have to go through each applicable class and
>>> refactor-rename each method.
>>>
>>>
>>
>> Please don't try to make us feel guilty :-)
>> You'll get paid for this, we're not.
>>
>> In previous post I stated clearly: "If the only problem is the number
>> of methods to be changed"
>> not "If you can change only some classes".
>>
>>
>>
>>
> Well, yes, i am getting paid for this. So the time that i need to rename
> the methods costs my employer big money.
>
> This is a case of true backwards incompatibility and causes trouble in
> non-trivial projects such as ours. Other projects may decide to not upgrade
> from earlier Struts versions to V 2.1.8.1, which is something i would
> definitely take serious if i were working without getting paid, because
> having your stuff used by as many people out there as possible is a major
> point of FOSS, right? Freedom of choice is the other, meaning that we could
> of course stick with V2.1.6 and patch it to our liking. I personally voted
> against the latter option and decided to go for the renaming option because
> we need some other fixes that are available in 2.1.8. And, to tell the
> truth, our choice to use "getmProperty()" as accessor method naming pattern
> was a bad one originally but we lived with it since the beginning and are
> now being bitten in the behind :-)
>
> Robert
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: [OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency
similar to 2.1.6)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Dave Newton schrieb:
> Robert Graf-Waczenski wrote:
>> And, to tell the truth, our choice to use "getmProperty()" as
>> accessor method naming pattern was a bad one originally but we lived
>> with it since the beginning and are now being bitten in the behind :-)
>
> That about sums it up, I think.
>
> I'm assuming the naming convention "mProperty" is designed to increase
> internal readability by showing that the property is an instance
> variable. Using the "m" convention in the getters/setters then
> propagates implementation details to the outside world, which defeats
> the purpose of getters and setters.
>
There's a bit more to the "m" than meets the eye. This is a legacy
application designed for the Struts1 MVC form/model pattern with library
code that transfers bean object properties to model object properties
and vice versa. Now, since our form classes have far more methods that
are only needed for the controller part of the application, we designed
our bean<->model transfer code around the presence of the "m" in the
getter/setter method name (to avoid accessing controller-only getters
and model utility methods). So even though your point about
implementation detail propagation still stands, it is exactly this
implementation detail that our application needs internally. Nowadays,
of course, you would do the same thing much more elegantly with
annotations, but back then, there were no annotations :-(
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency
similar to 2.1.6)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
I agree to your observation, Dave. Point well made. I would like to get
a comment from you about my claim about backwards incompatibility, though.
Robert
Dave Newton schrieb:
> Robert Graf-Waczenski wrote:
>> And, to tell the truth, our choice to use "getmProperty()" as
>> accessor method naming pattern was a bad one originally but we lived
>> with it since the beginning and are now being bitten in the behind :-)
>
> That about sums it up, I think.
>
> I'm assuming the naming convention "mProperty" is designed to increase
> internal readability by showing that the property is an instance
> variable. Using the "m" convention in the getters/setters then
> propagates implementation details to the outside world, which defeats
> the purpose of getters and setters.
>
> Folks that use an underscore convention ("_property") would name the
> getter "getProperty", not "get_Property" or "get_property".
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar
to 2.1.6)
Posted by Dave Newton <ne...@yahoo.com>.
Robert Graf-Waczenski wrote:
> And, to tell the truth, our choice to use "getmProperty()" as
> accessor method naming pattern was a bad one originally but we lived
> with it since the beginning and are now being bitten in the behind :-)
That about sums it up, I think.
I'm assuming the naming convention "mProperty" is designed to increase
internal readability by showing that the property is an instance
variable. Using the "m" convention in the getters/setters then
propagates implementation details to the outside world, which defeats
the purpose of getters and setters.
Folks that use an underscore convention ("_property") would name the
getter "getProperty", not "get_Property" or "get_property".
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar
to 2.1.6)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Rafał Krupiński schrieb:
> On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski <rg...@lsoft.com> wrote:
>
>> approach, which is tedious work because
>>
> [...]
>
>> i have to go through each applicable class and
>> refactor-rename each method.
>>
>
> Please don't try to make us feel guilty :-)
> You'll get paid for this, we're not.
>
> In previous post I stated clearly: "If the only problem is the number
> of methods to be changed"
> not "If you can change only some classes".
>
>
>
Well, yes, i am getting paid for this. So the time that i need to rename
the methods costs my employer big money.
This is a case of true backwards incompatibility and causes trouble in
non-trivial projects such as ours. Other projects may decide to not
upgrade from earlier Struts versions to V 2.1.8.1, which is something i
would definitely take serious if i were working without getting paid,
because having your stuff used by as many people out there as possible
is a major point of FOSS, right? Freedom of choice is the other, meaning
that we could of course stick with V2.1.6 and patch it to our liking. I
personally voted against the latter option and decided to go for the
renaming option because we need some other fixes that are available in
2.1.8. And, to tell the truth, our choice to use "getmProperty()" as
accessor method naming pattern was a bad one originally but we lived
with it since the beginning and are now being bitten in the behind :-)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Posted by Rafał Krupiński <r....@gmail.com>.
On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski <rg...@lsoft.com> wrote:
> approach, which is tedious work because
[...]
>i have to go through each applicable class and
> refactor-rename each method.
Please don't try to make us feel guilty :-)
You'll get paid for this, we're not.
In previous post I stated clearly: "If the only problem is the number
of methods to be changed"
not "If you can change only some classes".
--
Pozdrawiam / Best Regards
Rafal Krupinski
http://www.linkedin.com/in/krupinskir
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar
to 2.1.6)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Well, i was hoping for an interceptor-based solution. But since
something like this apparently is unavailable, i'm going for the method
renaming approach, which is tedious work because i'm only changing the
classes that are used by the Struts2 part of our codebase. So a global
search/replace approach will not work, i have to go through each
applicable class and refactor-rename each method.
Robert
Paweł Wielgus schrieb:
> Hi Robert,
> maybe not in one step,
> but for sure it's pretty easy to do.
> Just look for "public [^ ]+ get[a-z]" regexp in your codebase, and
> eclipse will do the rest,
> plus there's a bonus, You don't need to change anything in your jsp files.
> Ant to be absolutely sure everything worked well
> simply run all your tests after the refactoring.
>
> But of course it's for You to decide what to do.
>
> Best greetings,
> Paweł Wielgus.
>
>
> 2009/11/26 Robert Graf-Waczenski <rg...@lsoft.com>:
>
>> Hi,
>>
>> we do of course use a refactoring tool, but we are talking about a huge
>> amount of methods. I'm not aware of a refactoring tool that would allow me
>> to rename *all* methods in *one* step.
>>
>> Robert
>>
>> Rafał Krupiński schrieb:
>>
>>> Robert Graf-Waczenski pisze:
>>>
>>>> Hi,
>>>>
>>> [...]
>>>
>>>> Since we (obviously) don't want to rename the myriads of getters/setters,
>>>> i'd like to know if there is a way around this, maybe with a custom
>>>> interceptor somewhere?
>>>>
>>> Hi
>>> If the only problem is the number of methods to be changed, maybe you
>>> should consider using a refactoring tool.
>>>
>>> -you do that only once
>>> -your code is kosher
>>> -you don't get performance overhead introduced by another interceptor
>>>
>>>
>>> Regards
>>> Rafał
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to
2.1.6)
Posted by Paweł Wielgus <po...@gmail.com>.
Hi Robert,
maybe not in one step,
but for sure it's pretty easy to do.
Just look for "public [^ ]+ get[a-z]" regexp in your codebase, and
eclipse will do the rest,
plus there's a bonus, You don't need to change anything in your jsp files.
Ant to be absolutely sure everything worked well
simply run all your tests after the refactoring.
But of course it's for You to decide what to do.
Best greetings,
Paweł Wielgus.
2009/11/26 Robert Graf-Waczenski <rg...@lsoft.com>:
> Hi,
>
> we do of course use a refactoring tool, but we are talking about a huge
> amount of methods. I'm not aware of a refactoring tool that would allow me
> to rename *all* methods in *one* step.
>
> Robert
>
> Rafał Krupiński schrieb:
>>
>> Robert Graf-Waczenski pisze:
>>>
>>> Hi,
>>
>> [...]
>>>
>>> Since we (obviously) don't want to rename the myriads of getters/setters,
>>> i'd like to know if there is a way around this, maybe with a custom
>>> interceptor somewhere?
>>
>> Hi
>> If the only problem is the number of methods to be changed, maybe you
>> should consider using a refactoring tool.
>>
>> -you do that only once
>> -your code is kosher
>> -you don't get performance overhead introduced by another interceptor
>>
>>
>> Regards
>> Rafał
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar
to 2.1.6)
Posted by Robert Graf-Waczenski <rg...@lsoft.com>.
Hi,
we do of course use a refactoring tool, but we are talking about a huge
amount of methods. I'm not aware of a refactoring tool that would allow
me to rename *all* methods in *one* step.
Robert
Rafał Krupiński schrieb:
> Robert Graf-Waczenski pisze:
>> Hi,
> [...]
>> Since we (obviously) don't want to rename the myriads of
>> getters/setters, i'd like to know if there is a way around this,
>> maybe with a custom interceptor somewhere?
>
> Hi
> If the only problem is the number of methods to be changed, maybe you
> should consider using a refactoring tool.
>
> -you do that only once
> -your code is kosher
> -you don't get performance overhead introduced by another interceptor
>
>
> Regards
> Rafał
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar
to 2.1.6)
Posted by Rafał Krupiński <r....@gmail.com>.
Robert Graf-Waczenski pisze:
> Hi,
[...]
> Since we (obviously) don't want to rename the myriads of
> getters/setters, i'd like to know if there is a way around this, maybe
> with a custom interceptor somewhere?
Hi
If the only problem is the number of methods to be changed, maybe you should consider using a refactoring tool.
-you do that only once
-your code is kosher
-you don't get performance overhead introduced by another interceptor
Regards
Rafał
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org