Thread: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
Brought to you by:
chrismair
Menu
▾
▴
codenarc-user
|
From: Roshan D. <ros...@gm...> - 2011-12-15 10:21:37
|
Hi, I am trying to use CodeNarc on a Grails app. The Grails services have other dependencies - some are injected through the app context configuration, and others that need more logic are set in afterPropertiesSet(), etc. CodeNarc gives (GrailsStatelessService ) warnings for the fields defined to hold these dependencies. I don't want to turn the rule off. Is there a way to tell CodeNarc that these fields do not make "state" in typical sense but actually dependencies satisfied through Spring? -- Roshan Lucy.me: http://www.lucy.me/roshan Blog: http://roshandawrani.wordpress.com/ |
|
From: <chr...@we...> - 2011-12-15 15:44:23
|
You can set the addToIgnoreFieldNames property of the rule to add your own custom field names, either in the ruleset definition or in "codenarc.properties".
e.g.
GrailsStatelessService {
addToIgnoreFieldNames = '*Holder, fooHelper, thing1, thing2'
}
You can also ignore fields by type using the ignoreFieldTypes property. See http://codenarc.sourceforge.net/codenarc-rules-grails.html for more info on these properties.
Chris
From: Roshan Dawrani [mailto:ros...@gm...]
Sent: Thursday, December 15, 2011 5:21 AM
To: cod...@li...
Subject: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
Hi,
I am trying to use CodeNarc on a Grails app. The Grails services have other dependencies - some are injected through the app context configuration, and others that need more logic are set in afterPropertiesSet(), etc.
CodeNarc gives (GrailsStatelessService ) warnings for the fields defined to hold these dependencies.
I don't want to turn the rule off.
Is there a way to tell CodeNarc that these fields do not make "state" in typical sense but actually dependencies satisfied through Spring?
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 15:48:42
|
There are many services for us with many dependencies (very many of them do
not have a common type) and it's a pain maintaining a long list in
codenarc.properties.
Can there be a better way of informing CodeNarc that "it is an injected
property and do not complain about it"?
On Thu, Dec 15, 2011 at 9:13 PM, <chr...@we...> wrote:
> You can set the *addToIgnoreFieldNames* property of the rule to add your
> own custom field names, either in the ruleset definition or in
> “codenarc.properties”.****
>
> e.g.****
>
> GrailsStatelessService {****
>
> addToIgnoreFieldNames = ‘*Holder, fooHelper, thing1, thing2’**
> **
>
> }****
>
> ** **
>
> You can also ignore fields by type using the *ignoreFieldTypes* property.
> See http://codenarc.sourceforge.net/codenarc-rules-grails.html for more
> info on these properties.****
>
> ** **
>
> Chris****
>
> ** **
>
> *From:* Roshan Dawrani [mailto:ros...@gm...]
> *Sent:* Thursday, December 15, 2011 5:21 AM
> *To:* cod...@li...
> *Subject:* [Codenarc-user] GrailsStatelessService - bean properties and
> dependencies****
>
> ** **
>
> Hi,****
>
> ** **
>
> I am trying to use CodeNarc on a Grails app. The Grails services have
> other dependencies - some are injected through the app context
> configuration, and others that need more logic are set in
> afterPropertiesSet(), etc.****
>
> ** **
>
> CodeNarc gives (GrailsStatelessService ) warnings for the fields defined
> to hold these dependencies.****
>
> ** **
>
> I don't want to turn the rule off. ****
>
> ** **
> McAfee SiteAdvisor Warning
> This e-mail message contains potentially unsafe links to these sites:
> lucy.me [image: more info...]<http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0>
>
> Is there a way to tell CodeNarc that these fields do not make "state" in
> typical sense but actually dependencies satisfied through Spring?
> ****
>
> ** **
>
> --
> Roshan****
>
> Lucy.me: http://www.lucy.me/roshan
> Blog: http://roshandawrani.wordpress.com/****
>
> ** **
>
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: Corum, M. <mc...@rg...> - 2011-12-15 16:05:32
|
We've been forced to turn off the stateless service warning because it hit too many categories of issues for us. One is the injected services. For instance, a service may have another service injected. Another is constants. While there may be a philosophical discussion there (move constants somewhere else, an interface maybe), having this gank us for a constant basically encourages programmers to move away from good refactorings and leave "magic constants" or "magic strings" all through the code, a practice I consider to be much worse than having constants as fields in a service. In essence, codenarc is encouraging duplication there so that is not acceptable if you are doing extreme programming or true test-driven development.
Mike
From: Roshan Dawrani [mailto:ros...@gm...]
Sent: Thursday, December 15, 2011 9:49 AM
To: chr...@we...
Cc: cod...@li...
Subject: Re: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
There are many services for us with many dependencies (very many of them do not have a common type) and it's a pain maintaining a long list in codenarc.properties.
Can there be a better way of informing CodeNarc that "it is an injected property and do not complain about it"?
On Thu, Dec 15, 2011 at 9:13 PM, <chr...@we...<mailto:chr...@we...>> wrote:
You can set the addToIgnoreFieldNames property of the rule to add your own custom field names, either in the ruleset definition or in "codenarc.properties".
e.g.
GrailsStatelessService {
addToIgnoreFieldNames = '*Holder, fooHelper, thing1, thing2'
}
You can also ignore fields by type using the ignoreFieldTypes property. See http://codenarc.sourceforge.net/codenarc-rules-grails.html for more info on these properties.
Chris
From: Roshan Dawrani [mailto:ros...@gm...<mailto:ros...@gm...>]
Sent: Thursday, December 15, 2011 5:21 AM
To: cod...@li...<mailto:cod...@li...>
Subject: [Codenarc-user] GrailsStatelessService - bean properties and dependencies
Hi,
I am trying to use CodeNarc on a Grails app. The Grails services have other dependencies - some are injected through the app context configuration, and others that need more logic are set in afterPropertiesSet(), etc.
CodeNarc gives (GrailsStatelessService ) warnings for the fields defined to hold these dependencies.
I don't want to turn the rule off.
McAfee SiteAdvisor Warning
This e-mail message contains potentially unsafe links to these sites:
lucy.me<http://lucy.me> [data:image/gif;base64,R0lGODlhEgASAPeIAOF2iN1pfdI3VeylruzAwOaPnLUDA/C2vNdPaMEsLNVCXuSCksIvL9pbcvfk5LQCAs0jQ+mapb8mJsxRUf34+P7//8MzM8UZMM8+UtNsbP78/Pns7M1MTsU8PNVxcfjm5/nk5cIcKMMZKuSTl7sxN+apqe6wtboXF9FUWvDT0+J+jdNscv/+/uesrLgNDdhXbfbf39FBVdhWbNltc8g2OscyNsYhMsIxMcI3Od12gf/9/td3d85MVfrw8MAuMPz19t96hrYICM5bW/rt7ssgP8sgPvLS0vnp6chERMtOTsMYKf35+fPS0/fc3cI2N89QVvXd3dx3fdNfYrwdHbcKCsQ4ONh7gbYJCeF/h8InK+m0tMpMTPzv8Pbg4vPb3cUYL8IwMN50fdJbXuvExtx1e7cMDPTY2PXc3NVwcM5SU+WVmr4kJPjr68IiJunBwsUfMPPY2bYjKboVFdFaYrURE+u6uuzLyshGRuN+jr8wMLYWGNmAgNpzeLgPD8EuLv79/e2utLwMGLsYGP77+88sTO6utrQBAf///////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAIgALAAAAAASABIAAAj/ABEJHEiwoEFEDjyAoWLIUBkLO44crCNBihoTBw4AGiGGAYGCWgRFKUSyJEk+Uz4KhLKGzICGhga8bDhgRgIHAoWgiGAoDZcaDWno4GAowpMMAiUAKWBoyCEQYbAMOtTEUIEcfgQGwbPAUJYuh8KyYNLG0AIVVwQaAsDW0JwfYT/wWNtWbYC7hqxQCLthhaG7AQwJdPGigSEnh5bA8XKohw9DDWT0EcggBgJDFQ6NiUMixSE2hhBgqCIQTQgFhnC4odNQj508hhQ82CPwTwcbAmAKyN1QwJs7GgYaSSCCkPHjxpXcMFPwDJJAF4hAgFDky4MtMA4iKpFEjgEDJya0BdBO3mBAADs=] <http://www.siteadvisor.com/sites/lucy.me?pip=false&premium=true&client_uid=1010617928&client_ver=3.4.0.143&client_type=IEPlugin&suite=true&aff_id=0&locale=en_au&ui=1&os_ver=6.1.1.0>
Is there a way to tell CodeNarc that these fields do not make "state" in typical sense but actually dependencies satisfied through Spring?
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
--
Roshan
Lucy.me: http://www.lucy.me/roshan
Blog: http://roshandawrani.wordpress.com/
|
|
From: Roshan D. <ros...@gm...> - 2011-12-15 16:41:15
|
On Thu, Dec 15, 2011 at 9:22 PM, Corum, Michael <mc...@rg...> wrote: > We’ve been forced to turn off the stateless service warning because it hit > too many categories of issues for us. One is the injected services. For > instance, a service may have another service injected. > It will be unfortunate to disable the rule because it cannot anyhow handle bean depedencies and bean properties. The other option to list everything down against fields-to-ignore is also quite inconvenient, because that list may be quite large for us and it is a maintenance headache. |
|
From: <chr...@we...> - 2011-12-15 16:46:32
|
>> It will be unfortunate to disable the rule because it cannot anyhow handle bean depedencies and bean properties. Agreed. What about enhancing the rule to ignore fields that are declared as "def" (i.e., java.lang.Object), public, and with no initialized value. Would that be appropriate? Can you think of any better way to determine whether a field is injected? |
|
From: Roshan D. <ros...@gm...> - 2011-12-15 16:55:37
|
On Thu, Dec 15, 2011 at 10:16 PM, <chr...@we...> wrote: > >> It will be unfortunate to disable the rule because it cannot anyhow > handle bean depedencies and bean properties. **** > > ** ** > > Agreed.**** > > ** ** > > What about enhancing the rule to ignore fields that are declared as “def” > (i.e., java.lang.Object), public, and with no initialized value. Would that > be appropriate? > ignoring fields with "no initialized value" seems like a good idea to me. It should help with fields that are tied to Spring - injected or pulled in afterPropertiesSet(), etc. > Can you think of any better way to determine whether a field is injected? > Spring 3.x also has this annotation called @Inject. I won't mind flagging my dependency fields as @Inject, but I don't know how closely CodeNarc wants to be tied with a new-ish Spring version. |
|
From: <chr...@we...> - 2011-12-15 18:54:04
|
>> ignoring fields with "no initialized value" seems like a good idea to me. It should help with fields that are tied to Spring - injected or pulled in afterPropertiesSet(), etc.
I am just concerned about casting too wide a net (and missing true violations of statelessness). So, I would be inclined to only ignore "properties" declared with "def".
So, public/private/protected fields, or fields with specific types (e.g., String, int, MyClass) would still cause violations. Is that ok?
>> Spring 3.x also has this annotation called @Inject.
We could consider supporting that. We only check the name of the annotation ("Inject"), not the type, so in that case there would be no runtime dependency.
Chris
|
|
From: Roshan D. <ros...@gm...> - 2011-12-16 03:05:12
|
On Fri, Dec 16, 2011 at 12:23 AM, <chr...@we...> wrote: > > > I am just concerned about casting too wide a net (and missing true > violations of statelessness). So, I would be inclined to only ignore > “properties” declared with “def”.**** > > ** ** > > So, public/private/protected fields, or fields with specific types (e.g., > String, int, MyClass) would still cause violations. Is that ok? > Yes, Chris. That sounds ok. In addition, I would suggest, the rule can skip fields with specific types / visibility annotations also if those are annotated as @Inject. I have filed the bug here: https://sourceforge.net/tracker/?func=detail&aid=3460463&group_id=250145&atid=1126573 > ** ** > > >> Spring 3.x also has this annotation called @Inject.**** > > ** ** > > We could consider supporting that. We only check the name of the > annotation (“Inject”), not the type, so in that case there would be no > runtime dependency. > Great! If it can skip on the basis of @Inject without having a runtime dependency. Thanks. -- Roshan http://roshandawrani.wordpress.com/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X