struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <>
Subject [jira] Commented: (SHALE-185) @Value is too restrictive on naming
Date Thu, 08 Jun 2006 22:02:16 GMT
    [ ] 

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:
>      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).
> @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:
For more information on JIRA, see:

View raw message