RestorableViewHandler - ClassCastException: java.util.HashMap cannot be cast to javax.faces.convert.Converter

[GoogleCodeExporter]

Please see attached file, 20130416_stackTrace01.txt. Have you ever seen this 
exception or know the root cause?

I can reproduce the problem, and I will tell you the following:

1. Recently, I have been making major optimization code changes throughout the 
app, hopefully not 'premature optimization' though. :)

2. Attached, in index.xhtml, you will see that I am using OmniFaces 
restorableViewHandler, which is my parent xhtml that references most xhtml 
pages in my app, dynamically, via ui:include.

Please NOTE: I actually don't think I need restorableViewHandler on 
index.xhtml, but I do need it on login.xhtml, to prevent the 
viewExpiredException. I really don't get that error on index.xhtml, since I do 
the following, and I also have loginFilter (both, which I learned from BalusC 
answers on stackoverflow.com).

<meta http-equiv="refresh" 
content="#{session.maxInactiveInterval};url=#{pf_usersController.isLoggedInViaAn
droid() ? 'pf_viewExpiredOnMobile.jsf' : 'pf_viewExpired.jsf'}" />

3. Also, attached in the file, 20130416_index_jsf_1.txt, is the rendered HTML 
prior to duplicating this exception. There is a defect (or unwanted behavior) 
with PrimeFaces Extension pe:layout that causes some of the content in the 
'center' pane, which renders under the p:menu, and 'usually' to resume, I can 
press F5 key on keyboard to refresh the page, and 'restoreView' or page will 
re-render as expected. there were a few times, that I attempted to duplicate 
this exception, and pressed F5 key on this row/record of data, and other 
rows/records of data, and I don't experience the exception.

4. To give you an idea of what the page looks like, please see attached file, 
20130416_ordersViewPriorToException.png.

5. Honestly, I don't know why, there is a class exception, casting to 
converter. This is a readonly page, and attached, in the file, 
pf_ViewAll.xhtml, is the 'tabview' xhtml (ID = orderViewTabView) that is 
referenced in the exception.

6. As to the class exception, cannot cast to converter, please see the 
stackoverflow.com question that I asked and answered. This was one of the 
optimizations that I completed in my app, and it is working great throughout 
the app. I don't know if it is causing this issue with OmniFaces restorableView 
or MyFaces 'restoreView' source code. Please confirm.

http://stackoverflow.com/questions/15987483/can-converter-facesconverterforclass
-someclass-class-be-implemented-as-sin

What is the expected output?

Page will render without this exception whenever I press F5 key on keyboard.

What do you see instead?

OmniFaces FullAjaxExceptionHandler error page with this exception thrown, 
unexpectedly.

What OmniFaces version are you using?

omnifaces-1.5-SNAPSHOT-20130407.jar

What JSF impl/version are you using?

MyFaces Core 2.1.11

What servletcontainer impl/version are you using?

TomEE-plus 1.6.0 SNAPSHOT (2013-03-27); can use any version, afterwards; my app 
works with TomEE-plus 1.5.1 SNAPSHOT (and all later versions).

If any, what JSF component library impl/version are you using?

PrimeFaces 3.5 release

Please provide any additional information below.

If you need me to attach any other XHTML file or .java, then please let me know.

Original issue reported on code.google.com by smithh03...@gmail.com on 16 Apr 2013 at 1:29

Attachments:

• 20130416_stackTrace01.txt
• index.xhtml
• 20130416_index_jsf_1.txt
• 20130416_ordersViewPriorToException.png
• pf_ViewAll.xhtml

[GoogleCodeExporter]

Will look at it when the time allows it.

Original comment by balusc on 16 Apr 2013 at 1:31

[GoogleCodeExporter]

FYI, I removed OmniFaces o:enableRestorableView from my index.xhtml, a few days 
ago, and I just duplicated the steps mentioned in OP, and I duplicated this 
issue. This 'may' be a MyFaces 2.1.11 issue or 'my' issue, since my converters 
are 'now' @Singleton beans marked with 
@FacesConverter(forClass=someClass.class). Earlier, each converter was defined 
as a 'public static' member of CDI @RequestScoped bean.

this issue only occurs when I press F5 key in Google Chrome, and this issue 
does not occur on every page, and sometimes, it does not happen on the page in 
the OP.

So, based on all of this, I am 'not' convinced that this is an OmniFaces issue. 
:)

Original comment by smithh03...@gmail.com on 18 Apr 2013 at 3:26

[GoogleCodeExporter]

This problem is indeed not related to o:enableRestorableView. The only 
occurrence in the stack trace is just the delegation to super (i.e. the process 
continues less or more as if the o:enableRestorableView was never involved):

    UIViewRoot restoredView = super.restoreView(context, viewId);

JSF converters should however not be EJB singletons by themselves. If you need 
EJB injection, better make them request or application scoped managed beans 
(either JSF or CDI, doesn't matter).

Original comment by balusc on 20 Apr 2013 at 12:49

• Changed state: Invalid

[GoogleCodeExporter]

Understood/agreed about marking this as invalid.

With regards to JSF-converter-should-not-be-EJB-singleton, I previously had 
converters defined as members of JSF @RequestScoped beans, and they were marked 
with @FacesConverter(forClass = someClass.class) and they were 'static'. Are 
the 'static' converters GC'ed well, or are they considered as long-living 
classes?

Can you please add a comment on the stackoverflow question (URL below), or 
respond here?

http://stackoverflow.com/questions/15987483/can-converter-facesconverterforclass
-someclass-class-be-implemented-as-sin

Original comment by smithh03...@gmail.com on 20 Apr 2013 at 2:00

[GoogleCodeExporter]

Mixing @ManagedBean with @FacesConverter has no special effect. You end up with 
a converter class which can be instantiated and used in 2 completely 
independent ways: 

- converter="converterName", which uses @FacesConverter part and doesn't 
support injection
- converter="#{converterName}", which uses @ManagedBean part and supports 
injection

If you need injection, just remove the @FacesConverter annotation. It would 
otherwise only lead to confusion. If your converter is stateless, I recommend 
@ApplicationScoped CDI or JSF bean, not a @Singleton EJB.

Original comment by balusc on 20 Apr 2013 at 9:05

[GoogleCodeExporter]

BalusC,

Interesting, understood, and noted, thanks.

Honestly, I prefer 'not' to specify 'converter="..."' throughout my app,
but when I added PrimeFaces p:picklist, it 'required'
converter="nameOfConverterClass" to be specified in xhtml. I think I
reported it in PrimeFaces issue tracker and in a forum topic, but now that
I think of it, I wish I reported it differently... seems to be a
requirement to specify converter="..." and
@FacesConverter(forClass=someClass.class) does not work at all, especially
when I migrated my JSF managed beans to CDI managed beans.

Noted, thanks for the recommendation; i will have to try that. I still find
it interesting that @Singleton EJB 'works' in a CDI/OpenWebBeans
environment/application. Earlier on, when I migrated from JSF to CDI
managed beans, IIRC, I was 'not' able to use
@FacesConverter(forClass=entityClass.class) on a CDI bean, and CODI
BeanManager was 'not' able to inject @Stateless EJB instead of the
converter class.

Migrating my public 'static' Converter classes (as members of JSF
@RequestScoped beans) to @Singleton EJB required that I reference
@Stateless EJB (from within the converter, to validate data in database)
via global portable JNDI name. Based on my experience, I am sure that I may
need to use JNDI, as well, to reference @Stateless EJB if converter is
defined as CDI @ApplicationScoped. Will have to try and see what's what.
Thank you!

Original comment by smithh03...@gmail.com on 20 Apr 2013 at 9:28

[GoogleCodeExporter]

Also, I guess you recommend CDI @ApplicationScoped, so the Converter will be 
long-lived and is thread-safe (can be accessed concurrently, just like a 
@Singleton @Lock(READ) can be accessed, concurrently, but I think the 
@Singleton EJB will return to EJB pool, and will be instantiated whenever 
referenced, right?).

Original comment by smithh03...@gmail.com on 20 Apr 2013 at 9:34

[GoogleCodeExporter]

2 or 3 weeks ago, I reverted to static @FacesConverter(forClass = 
someClass.class) as member of JSF managed @RequestScoped beans, and I still get 
this error.

I can duplicate this error with/via the following:

* OmniFaces versions 1.3, 1.4, and 1.5 snapshot (2013-04-22 and 2013-04-30)
* MyFaces 2.1.10 and MyFaces 2.1.11
* PrimeFaces 3.5 (OP) and PrimeFaces 4.0

I did not try to duplicate this with earlier versions of OmniFaces, MyFaces, 
and PrimeFaces than what is listed above.

Reported this against MyFaces project as JIRA, MYFACES-3720
https://issues.apache.org/jira/browse/MYFACES-3720

Original comment by smithh03...@gmail.com on 9 May 2013 at 1:05

[GoogleCodeExporter]

FYI: for <p:pickList> you can also use omnifaces.ListConverter which is 
available in current 1.5 snapshot: 
https://snapshot-omnifaces.rhcloud.com/converters/ListConverter

Original comment by balusc on 9 May 2013 at 1:08

[GoogleCodeExporter]

> FYI: for <p:pickList> you can also use omnifaces.ListConverter which is 
available in current 1.5 snapshot: 
https://snapshot-omnifaces.rhcloud.com/converters/ListConverter

Interesting. thanks for letting me know.

Original comment by smithh03...@gmail.com on 9 May 2013 at 1:19