I have a problem when trying to use
#ManagedBean, it appears like this :
#ManagedBean,
Check the image below :
here is a photo of the code
Yesterday, I could create a project and use it, but today I cannot, I don't know what happened , maybe because I changed GlassFish 4 to 5 , and PostgreSQL 9.3 to 10?
EDIT: I tried to see my others project, and they are all stricken out in #ManagedBean.
The crossed line (aka "strikethrough") on a class, method, or annotation means that it has been deprecated by the author and you should no longer use it. If you mouse over the annotation, it should give you some sort of explanation as to why it was deprecated, and what you should use instead.
In this case, the JSF #ManagedBean annotation was "strongly discouraged" in JSF 2.2, and officially deprecated in JSF 2.3 (hence the strikethrough in your IDE). Instead, you should use the #Named annotation which is provided by CDI and is a more standard way of creating a bean in Java EE.
Related
I use JSF 2.3 (Mojarra 2.3.3), Trinidad (2.2.1) and its file upload component (tr:inputFile) in a web.xml-version 3.1 on a Tomcat 8.5 server.
I get following exception and no valid uploaded file (i.e. the "value"-binded bean attribute remains null):
java.io.EOFException: null
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler._readLine(MultipartFormHandler.java:253) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler._readLine(MultipartFormHandler.java:237) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler._skipBoundary(MultipartFormHandler.java:223) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.<init>(MultipartFormHandler.java:102) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.<init>(MultipartFormHandler.java:75) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:139) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:763) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:244) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:178) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) [trinidad-api-2.2.1.jar:2.2.1]
(Info: The JSF 1.2 version with Trinidad 1.2.14 with web.xml-version 2.5 on Tomcat 6 or a Weblogic 10 does not have this problem.)
While searching for a solution I found that this seems to affect not only my concrete situation, but also:
ADF Faces (at least 12.x)
Trinidad 2.1
JSF 2.x in general
Wildfly (10.1)
Searching for an answer I developed a solution I want to share.
Use JSF's <h:inputFile> (since JSF 2.2) instead of <tr:inputFile>.
You may continue to use <tr:form usesUpload="true">, but see notes below.
In the backing bean you have to simply replace org.apache.myfaces.trinidad.model.UploadedFile with javax.servlet.http.Part and use getSubmittedFileName() instead of getFileName().
With this, file upload already works, but the EOFException still occurs and is logged (but ignored internally).
To prevent the needed TrinidadFilter (configured in web.xml) from processing the file upload, add your own javax.servlet.Filter (most apps will already have one, I guess) and put in its doFilter():
request.setAttribute("org.apache.myfaces.trinidadinternal.config.upload.FileUploadUtils.PROCESSED", Boolean.TRUE);
Of course, your filter must be executed before the TrinidadFilter, so either use a broader filter-mapping or place it before TrinidadFilter in your web.xml.
Additional notes:
When using <tr:form> the <h:inputFile> will output the wrong error/warning "File upload component requires a form with an enctype of multipart/form-data" via FacesMessage - but not for javax.faces.PROJECT_STAGE Production.
You may simply ignore it in development or use <h:form enctype="multipart/form-data"> instead. But note: <h:form> is a naming container and <tr:form> is not, so addressing input elements differs (hformId:inputId instead of simple inputId)
If your <tr:inputFile> is used inside a <tr:panelFormLayout>, put the <h:inputFile> inside a <tr:panelLabelAndMessage> and put the label there.
CSS styling for af|inputFile::content must also be done for input[type="file"].
See also:
https://stackoverflow.com/a/27681292/5074004
https://developer.jboss.org/thread/274824?_sscc=t
http://myfaces.10567.n7.nabble.com/Trinidad-File-upload-issue-td30231.html
As i am now working on jsf i want to know why we use the tag verbatim in jsf and what is the significance of it ?
Any help would be of great appreciation.
Since you've tagged your question with jsf-2 the answer is: you shouldn't use it.
It is deprecated in JSF 2.0. It was a part of JSF 1.X and used to hold plain HTML. See also this answer, the docs (since 2.1 there is an additional info: The use of this element has been deprecated in Facelets for JSF 2.0 and beyond) and the usage example.
I am trying to clone example here http://primefaces.org/showcase/ui/datatableRowSelectionRadioCheckbox.jsf
But Netbeans tell me that "type ListDataModel does not take parameters" at
public class CarDataModel extends ListDataModel<Car> implements SelectableDataModel<Car>
line at CarDataModel.java
If I remove Car parameter, like
public class CarDataModel extends ListDataModel implements SelectableDataModel<Car>
it compiles without any error and jsf page open with empty datatable.
what am I doing wrong?
Thanks for helping.
PM 4.0.4, Jboss 7.1.1
The error you've got implies that you're trying to indicate a type parameter on a class that's not generic, that is, the class that doesn't expect it.
Examination of past Java EE releases showed that within Java EE 5 the ListDataModel is non-generic, while in Java EE 6+ ListDataModel<E> indeed is.
As generics has become a Java artifact since Java SE 5 ages, Sun probably decided to leave a non-generic version of list model for Java EE 5.
As for the solution, look for old JSF libraries in your classpath and upgrade them to JSF 2+ (as of December 2013, the JSF version is 2.2). Alternatively, as application servers come bundled with JSF, and that you've got the most recent one, you can just as safely remove the webapp's JSF library altogether.
#ByPassInterceptor
annotation is removed from seam 3 that i know .
and as per CDI documentation ,
By default, a bean archive has no enabled interceptors bound via interceptor bindings.
so is it safe if i remove #BypassInterceptor annotation from project while migration from seam2 to seam 3 ?????
are there no default interceptors in seam 3 ??
i would appreciate an answer .
Thanks
Yep, you can safely remove those. The design between Seam 2 and CDI is completely different. If you don't want interceptors run either remove it from the beans.xml or the class.
I got this error when I upgraded from primefaces 3.0.M3 to 3.0.M4-SNAPSHOT
#60,114 Parent is not of type ActionSource, type is: javax.faces.component.html.HtmlForm#1d9c3e7
I understand that it is happening in other libraries like icefaces too, but I couldn't figure out how to fix it. Any help is appreciated.
The PrimeFaces tags/components are not been parsed at all and thus treated as plain HTML which caused that the real closest parent JSF component is a <h:form>.
This can have at least 2 causes:
You didn't update the taglib namespace URI from http://primefaces.prime.com.tr/ui to the new namespace http://primefaces.org/ui which was introduced in M4.
The PrimeFaces 3.0 M4 JAR file isn't in the webapp's runtime classpath. Verify if this is done right. This is to be achieved by dropping the JAR in /WEB-INF/lib, or if it's been dropped elsewhere, by including it in Deployment Assembly list in project's properties (assuming that you're using Eclipse).