Closed GoogleCodeExporter closed 9 years ago
Will look at it when the time allows it.
Original comment by balusc
on 16 Apr 2013 at 1:31
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
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
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
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
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
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
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
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
> 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
Original issue reported on code.google.com by
smithh03...@gmail.com
on 16 Apr 2013 at 1:29Attachments: