You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Adam Brod (JIRA)" <ji...@apache.org> on 2006/06/06 20:27:16 UTC
[jira] Created: (SHALE-185) @Value is too restrictive on naming
@Value is too restrictive on naming
-----------------------------------
Key: SHALE-185
URL: http://issues.apache.org/struts/browse/SHALE-185
Project: Shale
Type: Bug
Components: Tiger
Versions: 1.0.3
Environment: Windows XP sp3, Weblogic 9.1, MyFaces 1.1.3
Reporter: Adam Brod
We use a prefix convention for our member variables. All private member fields being with 'm_'. For example, in my managed bean, I have a private field m_fileId with getFileId() and setFileId() methods.
This works fine when I use the faces-config.xml to configure my beans, because I just say the property-name is "fileId". This doesn't work for Shale-Tiger - I get an exception because there is no setter for m_fileId. As far as I know, the Java Beans spec doesn't mandate the name of the private variable, just the getters and setters.
Shale-Tiger should be more flexible to support this.
Here are three possible solutions:
1) The @Value annotation should take an optional property field to allow me to specify the property the field corresponds to. E.g.
@Value(value="#{param.fileId}", property="fileId")
private Long m_fileId;
2) The @Value annotation could be applied to methods or fields (much like JPA annotations). E.g.:
@Value("#{param.fileId}")
public void setFileId(Long fileId) { this.m_fileId = fileId; }
3) I specify some mapping rules somewhere that define all member fields begin with "m_", so the annotation processor should handle that. That is similar to what Eclipse does. You can configure field prefixes, and then the tool automatically handles those when generating getters and setters.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-185) @Value is too restrictive on naming
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-185?page=comments#action_37456 ]
Craig McClanahan commented on SHALE-185:
----------------------------------------
I agree with your summary statement. At the moment, I'm leaning towards your solution #1, but the idea of annotating a getter or setter (like you can do in JPA entity classes) might also be a good idea.
> @Value is too restrictive on naming
> -----------------------------------
>
> Key: SHALE-185
> URL: http://issues.apache.org/struts/browse/SHALE-185
> Project: Shale
> Type: Bug
> Components: Tiger
> Versions: 1.0.3
> Environment: Windows XP sp3, Weblogic 9.1, MyFaces 1.1.3
> Reporter: Adam Brod
>
> We use a prefix convention for our member variables. All private member fields being with 'm_'. For example, in my managed bean, I have a private field m_fileId with getFileId() and setFileId() methods.
> This works fine when I use the faces-config.xml to configure my beans, because I just say the property-name is "fileId". This doesn't work for Shale-Tiger - I get an exception because there is no setter for m_fileId. As far as I know, the Java Beans spec doesn't mandate the name of the private variable, just the getters and setters.
> Shale-Tiger should be more flexible to support this.
> Here are three possible solutions:
> 1) The @Value annotation should take an optional property field to allow me to specify the property the field corresponds to. E.g.
> @Value(value="#{param.fileId}", property="fileId")
> private Long m_fileId;
> 2) The @Value annotation could be applied to methods or fields (much like JPA annotations). E.g.:
> @Value("#{param.fileId}")
> public void setFileId(Long fileId) { this.m_fileId = fileId; }
> 3) I specify some mapping rules somewhere that define all member fields begin with "m_", so the annotation processor should handle that. That is similar to what Eclipse does. You can configure field prefixes, and then the tool automatically handles those when generating getters and setters.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (SHALE-185) @Value is too restrictive on naming
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-185?page=all ]
Craig McClanahan resolved SHALE-185:
------------------------------------
Fix Version: 1.0.3
Resolution: Fixed
Fixed in nightly build 20060627. You can now optionally specify a "name" attribute on @Property to set the JavaBeans property name being affected.
> @Value is too restrictive on naming
> -----------------------------------
>
> Key: SHALE-185
> URL: http://issues.apache.org/struts/browse/SHALE-185
> Project: Shale
> Type: Bug
> Components: Tiger
> Versions: 1.0.3
> Environment: Windows XP sp3, Weblogic 9.1, MyFaces 1.1.3
> Reporter: Adam Brod
> Fix For: 1.0.3
>
> We use a prefix convention for our member variables. All private member fields being with 'm_'. For example, in my managed bean, I have a private field m_fileId with getFileId() and setFileId() methods.
> This works fine when I use the faces-config.xml to configure my beans, because I just say the property-name is "fileId". This doesn't work for Shale-Tiger - I get an exception because there is no setter for m_fileId. As far as I know, the Java Beans spec doesn't mandate the name of the private variable, just the getters and setters.
> Shale-Tiger should be more flexible to support this.
> Here are three possible solutions:
> 1) The @Value annotation should take an optional property field to allow me to specify the property the field corresponds to. E.g.
> @Value(value="#{param.fileId}", property="fileId")
> private Long m_fileId;
> 2) The @Value annotation could be applied to methods or fields (much like JPA annotations). E.g.:
> @Value("#{param.fileId}")
> public void setFileId(Long fileId) { this.m_fileId = fileId; }
> 3) I specify some mapping rules somewhere that define all member fields begin with "m_", so the annotation processor should handle that. That is similar to what Eclipse does. You can configure field prefixes, and then the tool automatically handles those when generating getters and setters.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira