Win a copy of Java Challengers this week in the Java in General forum!
  • 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
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
Bartenders:
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

JSF 2.3 and custom converters

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I use in my code JSF 1.9 and custom converter with arguments.
Now I update JSF to 2.3 (jakarta.faces-2.3.14.jar) and found that custom converters stop working because converter arguments (constraints) are not passed to the converter. I found that I need to use "managed=true" but in this case injection stops working. Is any way to make custom converters works in JSF 2.3?
 
Saloon Keeper
Posts: 23540
161
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 Ranch, Igor!

"managed=true" means that CDI must handle the injection, but if you're using Tomcat or jetty or an older JEE full-stack server, then CDI may not be built into the server and thus you'd have to provide CDI services manually.

I wouldn't rush to do that, though, because mixing traditional JSF injection and CDI might get messy..

Could you explain what "converter arguments (constraints) are not passed to the converter." means? An error message? stack trace?

You might define the converter to work on the lowest-common denominator type (see below) and see if that provides a quick fix. Obviously something more specific would be better, but it might at least get you past this obstacle for the moment:
 
Igor Sluge
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello, thanks a lot for your response

I use Tomcat 9.0.

I use the following tag for converter:


and my converter inhered from Converter<Object>

The problem is that limitation doesn't pass to the converter class. And I don't use "managed=true"
 
Tim Holloway
Saloon Keeper
Posts: 23540
161
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
I don't recognise that tag. It doesn't appear to comply with the schema for faces-config.xml and I cannot see how you could use it in a JSF View Template either.

So unless you can give me more information on why that's supposed to work, I'll have to consider that it doesn't work because JSF doesn't understand how it's supposed to work, either.
 
Igor Sluge
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello, this is custom tag defined by user and this is xhtml file
 
Tim Holloway
Saloon Keeper
Posts: 23540
161
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
OK. It would probably be a good thing if you posted the tag definition, then. Incidentally, "xhtml" is a file type, meanting HTML that conforms to XML syntax rules. In JSF, it's the file type used by View Templates. The actual JSF tags are known as View Definition Language (VDL) or sometimes as View Template Langage (VTL).

You did not define a namespace for your converter tag, and that probably means that it didn't get connected to its definition. JSF VDL is like HTML in that tags that are not understood are silently ignored - no error or warning message will be displayed.
 
Igor Sluge
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually this tag has a namespace but to simplify the code I omitted it. I'm looking for tag definition...
 
Igor Sluge
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Igor Sluge wrote:Actually this tag has a namespace but to simplify the code I omitted it. I'm looking for tag definition...



Hello, the actual tag definition is:



The problem with the code


is that only the hardcoded value "beanName" is transferred to the converter's code but all values that using EL don't transfer from JSF 2.3. Is any way to fix that?
 
Tim Holloway
Saloon Keeper
Posts: 23540
161
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
You're probably right. Have you checked by hard-coding the EL values just to be sure?

I'm thinking that the context of a converter bean makes EL impossible to use. Basically, you're looking at a single object instance (referenced by name) that is designed to be shared not only within a webapp user, but potentially between multiple webapp users concurrently. So the property injections would have to be done at construction time and not change thereafter.

People have had similar problems with the "id=" JSF attribute. They think that everything can be EL, and that's not 100% true.
 
Igor Sluge
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:You're probably right. Have you checked by hard-coding the EL values just to be sure?

I'm thinking that the context of a converter bean makes EL impossible to use. Basically, you're looking at a single object instance (referenced by name) that is designed to be shared not only within a webapp user, but potentially between multiple webapp users concurrently. So the property injections would have to be done at construction time and not change thereafter.

People have had similar problems with the "id=" JSF attribute. They think that everything can be EL, and that's not 100% true.



It looks like it's required to put “managed=true” somewhere
 
Tim Holloway
Saloon Keeper
Posts: 23540
161
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
"managed=true" indicates that CDI should be used instead of legacy injection.

Have you tried injecting @ManagedProperty's into the converter: https://stackoverflow.com/questions/8675831/inject-managed-bean-property-into-custom-converter ?
 
Igor Sluge
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:"managed=true" indicates that CDI should be used instead of legacy injection.

Have you tried injecting @ManagedProperty's into the converter: https://stackoverflow.com/questions/8675831/inject-managed-bean-property-into-custom-converter ?



Hello, unfortunately it's not acceptable for be because I need to pass current values of the #{item.name} to the converter. Bean can't help me in that case
 
Tim Holloway
Saloon Keeper
Posts: 23540
161
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
You can inject a String as a ManagedProperty.

What I am beginning to wonder is if you haven't designed a clever solution because you didn't realize a simpler one was possible. I don't have enough information to be certain, though.

The idea of feeding external data into a validator or converter isn't new. I once did a password-checking validator where two different password controls had to match, for example. At the time I think I did some brute-force walking up and down the Component Tree, although in retrospect it would have probably been better to simply let the action method do the checking. Then again, there have been some changes in JSF's internal pipelines since then.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic