• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JSF uses reflection for backing bean members?

 
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Weird problem. In my backing bean, I have a private String called mName and getters and setters called setMName() and getMName(). JSF can't resolve this in a page at runtime - I try to access

<h utputText value="#{bean.mName}" />

and it blows up. Now, if I call

<h utputText value="#{bean.MName}" />

it works just fine. Is this a bug or is my understanding buggy? I thought JSF uses reflection on data members then looks for the proper accessors, but it must not somehow. Anyone see this before?
[ September 07, 2005: Message edited by: Paul Smiley ]
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I really don't know the reason behind this but the correct access method syntax for mName is:

getmName() and setmName(String mName)

If you code it this way your backing bean, it will work the way you expect with value="#{bean.mName}".

I might also point out that prefixing variables as such is a rather old convention that I rarely see followed outside of the C world. Not that there is anything wrong with it, but as you can see, it makes things like this more difficult. I'd just lose them if you can.
 
Paul Smiley
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Hibernate/EJB team here has control over the pojo, so the only thing I can do is use the "bean.MName" for now and recommend the change to getmName() syntax.

I hate the naming also, but our hands are tied on that too.

Thanks!
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You could get the source and do a quick refactor if you have a good IDE. Maybe they would never notice.
 
Paul Smiley
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I get a shot, I'll do that. Looks like the culprit is good old Eclipse when you generate getters and setters it does it improperly.

GoodIDE=false;

 
Paul Smiley
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:
I really don't know the reason behind this but the correct access method syntax for mName is:

getmName() and setmName(String mName)



Hey Greg, BTW, do you know where I can find this in the spec in writing? It would be good ammo to have
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Smiley:


Hey Greg, BTW, do you know where I can find this in the spec in writing? It would be good ammo to have



I'll see what I can find...
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Smiley:
When I get a shot, I'll do that. Looks like the culprit is good old Eclipse when you generate getters and setters it does it improperly.

GoodIDE=false;



I figured it out because Intellij created them the correct way. You might post something in the IDE forum about eclipse doing it wrong and see what you get back.
 
Paul Smiley
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:


I figured it out because Intellij created them the correct way. You might post something in the IDE forum about eclipse doing it wrong and see what you get back.



Good idea.
 
Paul Smiley
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I still don't know if IntelliJ and JSF are wrong, or Eclipse is. Looking through the code, it appears as if the former are...
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From the book "Core JavaServer Faces":

Note that the name of the property is the “decapitalized” form of the part of the method name that follows the get or set prefix. For example, getFoo gives rise to a property named foo, with the first letter turned into lowercase. However, if the first two letters after the prefix are uppercase, then the first letter stays unchanged. For example, the method name getURL defines a property URL and not uRL.

So in your case, JSF searches for a property called MName.
 
Saloon Keeper
Posts: 27764
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Eric!

What you have done is something we call "Waking a Zombie". Usually, after a thread has gone dormant for a long time, it's considered "dead". We don't actually de-activate it, but we discourage adding to it, since the people involved in the thread have probably lost interest. We'd rather have a new thread that resurrect an old one.

This particular thread has been dead so long that probably not only has everyone moved on to new projects and new jobs, but it's even possible one or more participants could have retired and lost interest in the subject entirely.
reply
    Bookmark Topic Watch Topic
  • New Topic