At the same request property is instantiated and becomes null. Why?
posted 5 years ago
Hello!
I am completely confused - I can't do even the simplest in JSF!
Part of jsf page:
From this jsf page I can invoke method #{loginRegisterBacking.login()}. It instantiates property 'user' of managed bean with new instance.
Then I expect this condition to work and return true so that button Logout (<h:commandButton actionListener="#{loginRegisterBacking.logout()}") is displayed:
Whatever I try I fail because after I click Login button my 'when condition' returns false and I never see button 'Logout'.
At the same request I instantiate property 'user' by clicking 'Login' button(fact that it is not null is printed to server.log) and after that I check if it is null at rendering 'when condition' - <c:when test="#{loginRegisterBacking.userLoggedIn}">. And it always gives null which is printed to server.log when method isUserLoggedIn is invoked by 'when condition'
Head of my loginRegisterBacking is here:
I also decided to execute method annotated by @PostConstruct in LoginRegisterBacking bean. It turned out that this method
was runnning three times during one request (after I clicked button 'Login'). It means that my LoginRegisterBacking was created three times. Why? Or maybe I don't know something. This is unbearable!
I am completely confused - I can't do even the simplest in JSF!
Part of jsf page:
From this jsf page I can invoke method #{loginRegisterBacking.login()}. It instantiates property 'user' of managed bean with new instance.
Then I expect this condition to work and return true so that button Logout (<h:commandButton actionListener="#{loginRegisterBacking.logout()}") is displayed:
Whatever I try I fail because after I click Login button my 'when condition' returns false and I never see button 'Logout'.
At the same request I instantiate property 'user' by clicking 'Login' button(fact that it is not null is printed to server.log) and after that I check if it is null at rendering 'when condition' - <c:when test="#{loginRegisterBacking.userLoggedIn}">. And it always gives null which is printed to server.log when method isUserLoggedIn is invoked by 'when condition'
Head of my loginRegisterBacking is here:
I also decided to execute method annotated by @PostConstruct in LoginRegisterBacking bean. It turned out that this method
was runnning three times during one request (after I clicked button 'Login'). It means that my LoginRegisterBacking was created three times. Why? Or maybe I don't know something. This is unbearable!
To earn money on java go to upwork.com
posted 5 years ago
There are several things obviously wrong here.
The first one is that you're attempting to provide your own login code. The technical term for such code is "hacked". I've never seen a user-written security system that was actually secure in many, many years of working with all sorts of J2EE apps. J2EE has its own built-in security framework which is more portable, much more secure, and requires very little user coding to use.
The second one is that you're using JSTL on JSF View Definitions. This is a recipe for pain and suffering. JSF has native ways to do just about everything that JSTL can do and it does them in a way that fits in better with JSF.
The third one is that you're attempting to code a data template (View Definition) as though it was program code. The code should be in the backing beans. The View definition should simply reference it. For example: "#{loginRegisterBacking.login()}" isn't the proper way to reference the user-defined login action method. The proper syntax is simply "#{loginRegisterBacking.login}" because this is a reference to something that JSF calls for you and not a direct call you make yourself.
At a guess, a fourth one is that you're probably using a request-scope backing bean (I didn't check this, but people often do). Request scope in JSF is almost completely useless. Because JSF does postbacks and request-scope objects are created and destroyed on each postback operation, critical data gets destroyed as well.
The first one is that you're attempting to provide your own login code. The technical term for such code is "hacked". I've never seen a user-written security system that was actually secure in many, many years of working with all sorts of J2EE apps. J2EE has its own built-in security framework which is more portable, much more secure, and requires very little user coding to use.
The second one is that you're using JSTL on JSF View Definitions. This is a recipe for pain and suffering. JSF has native ways to do just about everything that JSTL can do and it does them in a way that fits in better with JSF.
The third one is that you're attempting to code a data template (View Definition) as though it was program code. The code should be in the backing beans. The View definition should simply reference it. For example: "#{loginRegisterBacking.login()}" isn't the proper way to reference the user-defined login action method. The proper syntax is simply "#{loginRegisterBacking.login}" because this is a reference to something that JSF calls for you and not a direct call you make yourself.
At a guess, a fourth one is that you're probably using a request-scope backing bean (I didn't check this, but people often do). Request scope in JSF is almost completely useless. Because JSF does postbacks and request-scope objects are created and destroyed on each postback operation, critical data gets destroyed as well.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
Hello!
Thank you for your reply!
I have found on the internet that FORM and BASIC authentication methods are not realy secure. But User Name- and Password-Based or certificate Mutual Authentication is much more secure. So I decided to use it. But it is not easy to find an example of User Name- and Password-Based Mutual Authentication on the Internet.
I have tried to implement certificate mutual authentication but it gives me that browser doesn't trust server's certificate.
Anyway I need example of User Name- and Password-Based Mutual Authentication. I didn't find that on the Internet so far. Maybe you can recommend some site or book.
Thank you!
Thank you for your reply!
I have found on the internet that FORM and BASIC authentication methods are not realy secure. But User Name- and Password-Based or certificate Mutual Authentication is much more secure. So I decided to use it. But it is not easy to find an example of User Name- and Password-Based Mutual Authentication on the Internet.
I have tried to implement certificate mutual authentication but it gives me that browser doesn't trust server's certificate.
Anyway I need example of User Name- and Password-Based Mutual Authentication. I didn't find that on the Internet so far. Maybe you can recommend some site or book.
Thank you!
To earn money on java go to upwork.com
posted 5 years ago
You can find a lot of things on the Internet. BASIC authentication isn't considered secure because the security tokens are weakly encrypted (unless transported via TLS). Plus the only real way to completely log out is to stop the client app.
FORM-based authentication is secure as long as the form is presented and returned via secure channels (TLS).
Security certs are a step further up because unlike the BASIC and FORM methods, it's not sufficient to know something, you have to possess something. And, of course, make sure it doesn't get stolen. The security certs are normally automatically presented on-demand from the server, so no login page is required or used. However, the server does have to be configured for this, and the client will require some prep work as well. At a minimum, the client's certificate must be installed in the client machine. Which brings up one problem with this approach - if the client machine breaks, you can't just swap over to another client machine (unless it, too has a security cert).
The most paranoid level of all (short of military-grade stuff) is when both client and server have to have certs.
By far, the most common way of securing Java webapps is via form-based security using TLS backed by a server certificate from an authentic Certificate Authority. For test purposes, you can create a self-signed certificate.
FORM-based authentication is secure as long as the form is presented and returned via secure channels (TLS).
Security certs are a step further up because unlike the BASIC and FORM methods, it's not sufficient to know something, you have to possess something. And, of course, make sure it doesn't get stolen. The security certs are normally automatically presented on-demand from the server, so no login page is required or used. However, the server does have to be configured for this, and the client will require some prep work as well. At a minimum, the client's certificate must be installed in the client machine. Which brings up one problem with this approach - if the client machine breaks, you can't just swap over to another client machine (unless it, too has a security cert).
The most paranoid level of all (short of military-grade stuff) is when both client and server have to have certs.
By far, the most common way of securing Java webapps is via form-based security using TLS backed by a server certificate from an authentic Certificate Authority. For test purposes, you can create a self-signed certificate.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
Hello!
I have read your replies at 'Starting with JSF Clearing login page'. They are really important. In fact almost all you tell is the other way around of what I studied
from 'JavaServer Faces 2.0: The Complete Reference' by Ed Burns Chris Schalk with Neil Griffin.
I have created my self-signed certificate and forced IE8 accept it. But I can't get Google Chrome accept self-signed certificate.
I don't do any actions submitting login form! For now login works well!
But I think about the following:
1. Can I use <f:ajax> in my login form (j_security_check)
2. Should I register with some special form as for login j_security_check
3. Now I'll use only jsf components but how to render with jsf this:
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <br />
- <title>
4. How to prohibit user to get to page via url typed in browser except inserting page WEB-INF folder?
My login j_username and j_password are on top of every page (because of template) in case user wants to login. Is it good approach or not?
I have read your replies at 'Starting with JSF Clearing login page'. They are really important. In fact almost all you tell is the other way around of what I studied
from 'JavaServer Faces 2.0: The Complete Reference' by Ed Burns Chris Schalk with Neil Griffin.
I have created my self-signed certificate and forced IE8 accept it. But I can't get Google Chrome accept self-signed certificate.
I don't do any actions submitting login form! For now login works well!
But I think about the following:
1. Can I use <f:ajax> in my login form (j_security_check)
2. Should I register with some special form as for login j_security_check
3. Now I'll use only jsf components but how to render with jsf this:
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <br />
- <title>
4. How to prohibit user to get to page via url typed in browser except inserting page WEB-INF folder?
My login j_username and j_password are on top of every page (because of template) in case user wants to login. Is it good approach or not?
To earn money on java go to upwork.com
posted 5 years ago
Almost every introductory J2EE book I've ever read - plus a lot of more specialized books, such as ones on JSF - illustrate how to setup security in web.xml
And THEN they go and screw it all up by following it up with a sample user-defined login process!!!
The reason I rant so much about this is because I really, truly have never seen a user-created security system that was secure. Most of them are about as secure as a wet tissue-paper box and that includes the ones where the resident corporate geniuses designed them.
No. "j_security_check" is not a URL. It's an identifier used by the webapp server to determine which form on a login page contains the userid and password data. Although good practice is that there shouldn't be any other forms or functions on a login screen. A user (and a webapp) can NEVER request the login page themselves, only the webapp server can do that and it does it automatically when it determines a login is required.
You cannot register a "special form" for j_security_check. The only forms that work this way are the login and loginfail pages defined in the webapp's web.xml.
I don't understand this question, but the login and loginfail pages cannot use JSF because JSF is handled in the webapp and the login pages are handled by the server.
You must distinguish between the resource and the URL. Resources are the "files" that are used to resolve URL requests. Clients have no direct access to resources. Clients make URL requests. What's dangerous about this is that in many cases, the default is that if you type in a resource path as a URL, the webapp's default behavior is to copy the resource back to the client. To avoid this, define a URL pattern to prohibit servicing URLs that look like resource paths. For example, block all ".xhtml" URLs, since they should never be directly referenced. Note that since it's URLs that are blocked and in JSF, URLs don't always match the resources being used, you need to use the "redirect" option when navigating to secured resources URLs.
That won't work in J2EE because the only time "j_username" and "j_password" have any special attributes are when they appear on a login/loginfail page being presented by the server.
In JEE an "authenticate()" method was added so that apps could run authentication without the server taking over. It won't work in older servers such as Tomcat6 or WAS 6.x. You don't need to name the userid and password fields "j_username" or "j_password", however, since the application logic is doing the work, and can therefore obtain (or synthesise) credentials from anywhere, not just "magic" form fields.
you should be very careful if you use the "authenticate" method, however, since the extra flexibility makes it possible to code logic where stuff that should only happen in a secured environment is executed before the user was authenticated. You also need to only do this on encrypted pages, since the danger exists of sending down security credentials in a form easily displayed on a network sniffer. For best results, if you put a login option on application pages, it should be managed by its own form and not be part of the form that does the page logic and display.
And THEN they go and screw it all up by following it up with a sample user-defined login process!!!
The reason I rant so much about this is because I really, truly have never seen a user-created security system that was secure. Most of them are about as secure as a wet tissue-paper box and that includes the ones where the resident corporate geniuses designed them.
1. Can I use <f:ajax> in my login form (j_security_check)
No. "j_security_check" is not a URL. It's an identifier used by the webapp server to determine which form on a login page contains the userid and password data. Although good practice is that there shouldn't be any other forms or functions on a login screen. A user (and a webapp) can NEVER request the login page themselves, only the webapp server can do that and it does it automatically when it determines a login is required.
2. Should I register with some special form as for login j_security_check
You cannot register a "special form" for j_security_check. The only forms that work this way are the login and loginfail pages defined in the webapp's web.xml.
3. Now I'll use only jsf components but how to render with jsf this:
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <br />
- <title>
I don't understand this question, but the login and loginfail pages cannot use JSF because JSF is handled in the webapp and the login pages are handled by the server.
You must distinguish between the resource and the URL. Resources are the "files" that are used to resolve URL requests. Clients have no direct access to resources. Clients make URL requests. What's dangerous about this is that in many cases, the default is that if you type in a resource path as a URL, the webapp's default behavior is to copy the resource back to the client. To avoid this, define a URL pattern to prohibit servicing URLs that look like resource paths. For example, block all ".xhtml" URLs, since they should never be directly referenced. Note that since it's URLs that are blocked and in JSF, URLs don't always match the resources being used, you need to use the "redirect" option when navigating to secured resources URLs.
That won't work in J2EE because the only time "j_username" and "j_password" have any special attributes are when they appear on a login/loginfail page being presented by the server.
In JEE an "authenticate()" method was added so that apps could run authentication without the server taking over. It won't work in older servers such as Tomcat6 or WAS 6.x. You don't need to name the userid and password fields "j_username" or "j_password", however, since the application logic is doing the work, and can therefore obtain (or synthesise) credentials from anywhere, not just "magic" form fields.
you should be very careful if you use the "authenticate" method, however, since the extra flexibility makes it possible to code logic where stuff that should only happen in a secured environment is executed before the user was authenticated. You also need to only do this on encrypted pages, since the danger exists of sending down security credentials in a form easily displayed on a network sniffer. For best results, if you put a login option on application pages, it should be managed by its own form and not be part of the form that does the page logic and display.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
Hello Tim!
I am thinking that JSF is bad completely because it doesn't do what it is told to do! There is no logical path to use jsf.
My first question is about login form(j_security_check identifier) to be included in template like this:
This is only the first part because of 400 Bad Request I get whole day!
Hello Tim!
I am thinking that JSF is bad completely because it doesn't do what it is told to do! There is no logical path to use jsf.
My first question is about login form(j_security_check identifier) to be included in template like this:
This is only the first part because of 400 Bad Request I get whole day!
To earn money on java go to upwork.com
posted 5 years ago
You cannot use j_security_check in a JSF View Definition. j_security_check is not run by application code.
The login and loginfail pages must be straight HTML or non-JSF JSP. That is because the application does not display or process them. They have no URLs and they do not go through the application's JSF processor. Instead, the application server displays and processes them automatically when a user requests an application URL that requires an authorized user. You do not program this. It is already programmed into the application server. This is true for any J2EE or JEE application using the container security system, not just JSF webapps.
The login and loginfail pages must be straight HTML or non-JSF JSP. That is because the application does not display or process them. They have no URLs and they do not go through the application's JSF processor. Instead, the application server displays and processes them automatically when a user requests an application URL that requires an authorized user. You do not program this. It is already programmed into the application server. This is true for any J2EE or JEE application using the container security system, not just JSF webapps.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
How user can request by url my .xhtml page if not typing URL like resource path. To access all past Olympic competitions user must type smth like this:
http://www.myhost:myport/pastCompetitions.xhtml - and this is resource path and URL! You told that all URLs that include '.xhtml' should never be referenced directly. How can user access my page with extension '.xhtml' without typing url that ends with '.xhtml' ???
You told to block all URLs that end with '.xhtml'!
default behavior is to copy the resource back to the client. To avoid this, define a URL pattern to prohibit servicing URLs that look like resource paths.For example, block all ".xhtml" URLs, since they should never be directly referenced.
How user can request by url my .xhtml page if not typing URL like resource path. To access all past Olympic competitions user must type smth like this:
http://www.myhost:myport/pastCompetitions.xhtml - and this is resource path and URL! You told that all URLs that include '.xhtml' should never be referenced directly. How can user access my page with extension '.xhtml' without typing url that ends with '.xhtml' ???
You told to block all URLs that end with '.xhtml'!
To earn money on java go to upwork.com
posted 5 years ago
You told that I should use mainly jsf components on page where I use jsf components and never JSTL. I found already two threads that approve this idea!
That's why I ask you how to replace on my jsf page HTML components:
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <br />
- <title>
I NEVER use in j_security_check form any jsf components!
Thank you for these replies!
PS Can you tell me how to block all urls that end with '.xhtml'?
That's why I ask you how to replace on my jsf page HTML components:
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <br />
- <title>
I NEVER use in j_security_check form any jsf components!
Thank you for these replies!
PS Can you tell me how to block all urls that end with '.xhtml'?
To earn money on java go to upwork.com
posted 5 years ago
Here is my register form:
CSS rule like #registerForm .greeting works well but #registerForm #regGrid .regSpan1 or #registerForm #regGrid #regSpan1 #regLabel1 or anything else
don't work at all. I have already no ideas how to style JSF components. Maybe it will be helpful that my css file is declared this way:
<ui:define name="head">
<h
utputStylesheet library="css" name="LogRegisterCSS.css" />
</ui:define>
Finally, all these questions may sound childish to you and believe me I have many of them - I can't style, all day I am working around <f:ajax>
and it does not work at all!!! I don't want to torture you!!!
Please, give me a link to real-world JSF if you know. Maybe you know which examples it is worthy to cover or books after all!
Thank you very much!
CSS rule like #registerForm .greeting works well but #registerForm #regGrid .regSpan1 or #registerForm #regGrid #regSpan1 #regLabel1 or anything else
don't work at all. I have already no ideas how to style JSF components. Maybe it will be helpful that my css file is declared this way:
<ui:define name="head">
<h
utputStylesheet library="css" name="LogRegisterCSS.css" />
</ui:define>
Finally, all these questions may sound childish to you and believe me I have many of them - I can't style, all day I am working around <f:ajax>
and it does not work at all!!! I don't want to torture you!!!
Please, give me a link to real-world JSF if you know. Maybe you know which examples it is worthy to cover or books after all!
Thank you very much!
To earn money on java go to upwork.com
posted 5 years ago
OK. You have about 3 sets of questions stacked up, and I'm sort of forgetful, but I'll try to answer them all.
First, on ".xhtml". XHTML files are resources, not URLs. The URL that JSF+Facelets will use is "http://www.myhost:myport/pastCompetitions.jsf" if you are using one of the most popular mapping schemes for JSF in your WEB-INF/web.xml file. The FacesServlet will reduce that to "/pastCompetitions.jsf" (assuming that your webpp is deployed under the root context), then the Facelets compiler will transform that to "/pastCompetitions.xhtml". If the user attempts to access ".xhtml" directly, the URL will not match the URL pattern that indicates routing to the FacesServlet, and instead of processing the xhtml through JSF, the default action of simply copying the raw xhtml back to the client will be done by the server's built-in default servlet. You don't want that.
You can safely use container security to forbid URLs with ".xhtml" on them, since that's not a valid URL, as explained above.
I don't care how many examples you find using JSTL in JSF, and that includes the ones at oracle.com. People who mix JSTL and JSF almost invariably end up regretting it. JSTL was designed for the JSP-style of processing where the page is processed as a linear (1-dimensional) sequence. JSF is processed 2-dimensionally. Additionally, the logic-like JSTL tags pollute the idea that in Model/View/Controller, the view should be a template, not code. Putting code in the View definition couples it too tightly to the Model and Controller, plus it means that to find where things are done, you have to figure out which file (View or Model) a given function is in, instead of being able to say "Model". Worse, if the coupling is really strong and the logic functionality is split between Model and View, it can be a real problem both in maintaining and in re-using components.
As I said earlier, most of what people use JSTL for has native JSF equivalents which are cleaner to use and are better integrated into JSF.
When applying CSS or javascript to JSF, you have to be aware that the JSF "id" attribute values don't always match the ids of the rendered HTML, and the CSS and JavaScript want the HTML IDs, not the JSF IDs. JSF has what are known as "naming containers", and the HTML IDs are concatenations of the container ID(s) plus the JSF ID. So, for example, the fullname control in your sample has a raw HTML ID of something like "registerForm:regGrid:fname".
Note that IDs containing the ":" are a problem with CSS. The proper style reference for fname is:
However, older versions of Internet Explorer will not handle this properly (you need at least IE 8). So on the whole, it's rarely worth the pain to setup ID-based CSS in JSF.
First, on ".xhtml". XHTML files are resources, not URLs. The URL that JSF+Facelets will use is "http://www.myhost:myport/pastCompetitions.jsf" if you are using one of the most popular mapping schemes for JSF in your WEB-INF/web.xml file. The FacesServlet will reduce that to "/pastCompetitions.jsf" (assuming that your webpp is deployed under the root context), then the Facelets compiler will transform that to "/pastCompetitions.xhtml". If the user attempts to access ".xhtml" directly, the URL will not match the URL pattern that indicates routing to the FacesServlet, and instead of processing the xhtml through JSF, the default action of simply copying the raw xhtml back to the client will be done by the server's built-in default servlet. You don't want that.
You can safely use container security to forbid URLs with ".xhtml" on them, since that's not a valid URL, as explained above.
I don't care how many examples you find using JSTL in JSF, and that includes the ones at oracle.com. People who mix JSTL and JSF almost invariably end up regretting it. JSTL was designed for the JSP-style of processing where the page is processed as a linear (1-dimensional) sequence. JSF is processed 2-dimensionally. Additionally, the logic-like JSTL tags pollute the idea that in Model/View/Controller, the view should be a template, not code. Putting code in the View definition couples it too tightly to the Model and Controller, plus it means that to find where things are done, you have to figure out which file (View or Model) a given function is in, instead of being able to say "Model". Worse, if the coupling is really strong and the logic functionality is split between Model and View, it can be a real problem both in maintaining and in re-using components.
As I said earlier, most of what people use JSTL for has native JSF equivalents which are cleaner to use and are better integrated into JSF.
When applying CSS or javascript to JSF, you have to be aware that the JSF "id" attribute values don't always match the ids of the rendered HTML, and the CSS and JavaScript want the HTML IDs, not the JSF IDs. JSF has what are known as "naming containers", and the HTML IDs are concatenations of the container ID(s) plus the JSF ID. So, for example, the fullname control in your sample has a raw HTML ID of something like "registerForm:regGrid:fname".
Note that IDs containing the ":" are a problem with CSS. The proper style reference for fname is:
However, older versions of Internet Explorer will not handle this properly (you need at least IE 8). So on the whole, it's rarely worth the pain to setup ID-based CSS in JSF.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
Hello Tim!
I realized what you told me about those URLs. If I have page say competition.xhtml and my FacesServlet only processes pages with .jsf end then I am in bad
situation if user types .../competition.xhtml because server takes and copies that page and sends to client without going through FacesServlet AS you told me!
Luckily it is not possible for me because my FacesServlet processes only pages that end with '.xhtml'. All pages I have end also with .xhtml!
I am not wise enough complaining on CSS and AJAX. At first it was needed to remove all mistakes from my logic and entities annotations!
Now I got it work well. I press one letter to fill email control and on the spot I have error message that email doesn't conform to pattern or even
User with such email already exists! just after the last letter is typed. The same I set for 'retype password'.
I use JPA annotations to validate values user enters in field and I don't know annotation which checks that user typed Short but not String. It gives error message if I type 'aa' which I want to replace but my own msg.
I want to upload photo to server. People say it is good to use some extension of JSF like MyFaces, PrimeFaces. Don't you know which JSF extension it is worthy
to take. I will appreciate this advise very much!
Thank you!
I realized what you told me about those URLs. If I have page say competition.xhtml and my FacesServlet only processes pages with .jsf end then I am in bad
situation if user types .../competition.xhtml because server takes and copies that page and sends to client without going through FacesServlet AS you told me!
Luckily it is not possible for me because my FacesServlet processes only pages that end with '.xhtml'. All pages I have end also with .xhtml!
I am not wise enough complaining on CSS and AJAX. At first it was needed to remove all mistakes from my logic and entities annotations!
Now I got it work well. I press one letter to fill email control and on the spot I have error message that email doesn't conform to pattern or even
User with such email already exists! just after the last letter is typed. The same I set for 'retype password'.
I use JPA annotations to validate values user enters in field and I don't know annotation which checks that user typed Short but not String. It gives error message if I type 'aa' which I want to replace but my own msg.
I want to upload photo to server. People say it is good to use some extension of JSF like MyFaces, PrimeFaces. Don't you know which JSF extension it is worthy
to take. I will appreciate this advise very much!
Thank you!
To earn money on java go to upwork.com
posted 5 years ago
I cannot help on the AJAX, since you didn't supply a sample of the AJAX, but it sounds like the validator is being applied before the value is fully entered. If possible, tie the validation to the control's onblur or onchange method.
All values on the displayed page (View) are text (String), because HTML is strictly text. The EL processor will attempt to convert when the target property is not a string. Built-in automatic converters are available for things like int and Long. Some external standard converters also come with the core package for things like convertDateTime. When none of those is sufficient, you can simply code your own converter and use it.
The extension packages for JSF can make a lot of work easier, including file uploads and auto-suggestion combobox controls. PrimeFaces and RichFaces are currently very popular among users of this forum, but there are also plenty of people who like MyFaces and Oracle ADF.
All values on the displayed page (View) are text (String), because HTML is strictly text. The EL processor will attempt to convert when the target property is not a string. Built-in automatic converters are available for things like int and Long. Some external standard converters also come with the core package for things like convertDateTime. When none of those is sufficient, you can simply code your own converter and use it.
The extension packages for JSF can make a lot of work easier, including file uploads and auto-suggestion combobox controls. PrimeFaces and RichFaces are currently very popular among users of this forum, but there are also plenty of people who like MyFaces and Oracle ADF.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
Hello!
Thank you for all your replies. They make me wiser!
I have really serious problem. Almost each component on page has <f:ajax> element.
Each time event 'blur' occurs on different components with <f:ajax> I get this error:
empty response: An empty response was received from the server. See server logs
Actually server log does not print anything of this error.
However if I put onerror attribute like this:
<f:ajax execute="@this" onerror="" event="blur" render="registerForm:fnameMsg" />
there is no already that stupid chrome' s dialog - 'empty response: An empty response was received from the server. See server logs'.
My problem is that <f:ajax> stopped working because it doesn't show me error message which is specified in annotation constraint @NotNull.
I found on the Internet this:
The "empty reply from server" error indicates that a zero length response was received - no HTTP headers or content, simply a closed TCP connection with no HTTP payload transmitted.
1. Unfortunately I don't know how to resolve completely empty response from server. Can you suggest something?
I have completed uploading files to my server. Once the image is uploaded it is stored in dedicated folder.
2. How can I compress uploaded images because they take much memory on server? I know only about GZIPOutputStream and GZIPInputStream.
Thank you for all your replies. They make me wiser!
I have really serious problem. Almost each component on page has <f:ajax> element.
Each time event 'blur' occurs on different components with <f:ajax> I get this error:
empty response: An empty response was received from the server. See server logs
Actually server log does not print anything of this error.
However if I put onerror attribute like this:
<f:ajax execute="@this" onerror="" event="blur" render="registerForm:fnameMsg" />
there is no already that stupid chrome' s dialog - 'empty response: An empty response was received from the server. See server logs'.
My problem is that <f:ajax> stopped working because it doesn't show me error message which is specified in annotation constraint @NotNull.
I found on the Internet this:
The "empty reply from server" error indicates that a zero length response was received - no HTTP headers or content, simply a closed TCP connection with no HTTP payload transmitted.
1. Unfortunately I don't know how to resolve completely empty response from server. Can you suggest something?
I have completed uploading files to my server. Once the image is uploaded it is stored in dedicated folder.
2. How can I compress uploaded images because they take much memory on server? I know only about GZIPOutputStream and GZIPInputStream.
To earn money on java go to upwork.com
posted 5 years ago
This usually means that the request code threw an Exception. The exception's stack trace should show in the server log. Unless you coded something like this:
Or, in other words, you threw away the Exception without giving it a chance to be intercepted and logged.
ALWAYS either handle an Exception or log it. NEVER just throw them away. You WILL regret it if you do.
An empty response was received from the server. See server logs
This usually means that the request code threw an Exception. The exception's stack trace should show in the server log. Unless you coded something like this:
Or, in other words, you threw away the Exception without giving it a chance to be intercepted and logged.
ALWAYS either handle an Exception or log it. NEVER just throw them away. You WILL regret it if you do.
An IDE is no substitute for an Intelligent Developer.
posted 5 years ago
Hi Tim,
are you suggesting that we should always use the 'styleClass' attribute of JSF components when working with an external CSS file? Therefore, the CSS file will only ever use the . (dot) operator to style components as opposed to the # operator, which links to id attributes of components. I have been using the components id attribute for use within CSS using the # operator to apply the style. I never thought to check what the id attribute renders.
Thanks,
Alan
Tim Holloway wrote:.... it's rarely worth the pain to setup ID-based CSS in JSF.
Hi Tim,
are you suggesting that we should always use the 'styleClass' attribute of JSF components when working with an external CSS file? Therefore, the CSS file will only ever use the . (dot) operator to style components as opposed to the # operator, which links to id attributes of components. I have been using the components id attribute for use within CSS using the # operator to apply the style. I never thought to check what the id attribute renders.
Thanks,
Alan
posted 5 years ago
I'm suggesting using styleClass no matter where you keep your CSS.
There are 2 problems with using ID-based styles.
1. For ANY CSS, regardless of JSF or not, there can be only 1 object with a given ID on a page. This is fine for things like "pageTitle" or "errorBox", but obviously useless for things like "paragraph".
2. For JSF, as I said, the actual ID as seen by CSS is a composite of the IDs of the naming container and the actual ID of the element in question. Since different versions of Internet Explorer are broken regarding the composite names, it's not usually worth fighting IE over.
In contrast, as many objects can have a given style class as want it, and there's no browser breakage.
There are 2 problems with using ID-based styles.
1. For ANY CSS, regardless of JSF or not, there can be only 1 object with a given ID on a page. This is fine for things like "pageTitle" or "errorBox", but obviously useless for things like "paragraph".
2. For JSF, as I said, the actual ID as seen by CSS is a composite of the IDs of the naming container and the actual ID of the element in question. Since different versions of Internet Explorer are broken regarding the composite names, it's not usually worth fighting IE over.
In contrast, as many objects can have a given style class as want it, and there's no browser breakage.
An IDE is no substitute for an Intelligent Developer.
| Don't get me started about those stupid light bulbs. |