JSF 2.0 Discussion

Starting a new top-post for discussion about the JSF 2.0 specification.

In order to download the Early Draft of the JSF2.0 specification, it was necessary to agree to a Sun licence agreement. The terms of this license are not very nice.
== Issues
Term 1:
<quote>
no part of the Specification may be reproduced in any form by any means without the prior written authorization of Sun Microsystems, Inc
</quote>
It seems rather rude to ask for review and feedback which will be incorporated into a document that can only be reproduced by permission of Sun. This is a document created via an expert committee plus external contributors, and therefore should be freely available.
Term 2:
<quote>
Distribute implementations of the Specification to third parties for their testing and evaluation use, provided that any such implementation:
(i) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented;
(ii) is clearly and prominently marked with the word "UNTESTED" or "EARLY ACCESS" or "INCOMPATIBLE" or "UNSTABLE" or "BETA" in any list of available builds and in proximity to every link initiating its download, where the list or link is under Licensee's control; and
</quote>
If this is meant to assert copyright over the API defined by this specification, then I do not believe that Sun has the right to prevent anyone from implementing a class named "javax.faces.context.FacesContext". As far as I know, APIs cannot be copyrighted. Restricting the right of implementations to claim to be "a certified implementation" or "a Sun-approved implementation" is reasonable. Claiming exclusive right to the name "javax.faces.context.FacesContext" is not.
If this is instead intended to mean that Sun will refuse to grant a patent license to anyone who implements a class with that name but does not pass the secret Sun TCK, then please include in the specification a list of the patents that Sun is asserting apply to this specification.
== Questions
Is it intended for the finished specification to be issued under the same terms?
== Recommendations
* Remove term 1. This document is expected -- even intended -- to be widely read by anyone who contributes to the specification, implements the specification or even uses a JSF2.0 implementation. Forbidding distribution of this document by anyone but Sun is unreasonable.
* If term 2 is intended to claim copyright over an API, then remove it; this is probably not legally enforceable and is in any case unreasonable.
* If term 2 is intended to grant patent rights only to implementations that pass the TCK, then list those patents in the specification.

Similar Messages

Best site for JSF 2.0 Discussions?

Is this the replacement forum for http://forums.sun.com/forum.jspa?forumID=427 ? Or should we use http://forums.java.net/jive/forum.jspa?forumID=138 for JSF 2.0 discussions?
Cheers-
- Marty
JSF 2.0 Tutorial: (Moderator edit: signature link removed)
Edited by: Darryl Burke -- MartyHall, advertising is not permitted here. Please stop posting links to your site.

this certainly seems like the place for JSF 2.0 discussions, yes.
It seems so obvious, was this forum called something else when this was posted perhaps?

Best practice for JSF 2.0 composite component?

Following the various tutorials and blog entries I have found, I have managed to implement a few composite components. I want to do a more complex one, but haven't found and example yet to follow and my own proficiency in programming model isn't sufficient for me to determine the best way to do it.
What I would want to implement is something like the following example.
.. xmlns:mc="http://java.syn.com/jsf/composite/myComponent" ..
<mc:addTwo value="#{SomeBean.someProperty}" />The included component has two fields, which when the user inputs those the someProperty is set to some calculation of those two (for example adding them together). What I think I need to do is implement a backing bean for the "addTwo" component and do the calculation there. Then when that is done the composite backing bean needs to access the using page's SomeBean.someProperty setter. How is this done?
My actual intent is to make a component that looks up an entity in a data base based on a number of user inputs, then set the "someProperty" property to that value. If I could do the above example then I think I can apply the same principle, which is to have the composite component's backing bean access the someProperty property in the using page's bean via a #{cc.attrs.xxx} type reference. Am I on the right track?

this certainly seems like the place for JSF 2.0 discussions, yes.
It seems so obvious, was this forum called something else when this was posted perhaps?

How to get security roles in a JSF portlet

I need to get the LDAP user-roles available in the Sun Portal Server 7 in my JSF-168 portlet.
I've added the mapping file, updated the portlet.xml and web.xml, deployed the portlet (psconsole). But the portlet shows the "content not available" error with javax....title title.
I've probably messed up the descriptors, but I don't see what is wrong. Here they are:
roleMaps.properties
cn\=VSM.Administrator,dc\=neco,dc\=cz=Administrator
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4">
<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>server</param-value>
</context-param>
<context-param>
    <param-name>javax.faces.CONFIG_FILES</param-name>
    <param-value>/WEB-INF/navigation.xml,/WEB-INF/managed-beans.xml</param-value>
</context-param>
<context-param>
    <param-name>com.sun.faces.validateXml</param-name>
    <param-value>true</param-value>
</context-param>
<context-param>
    <param-name>com.sun.faces.verifyObjects</param-name>
    <param-value>false</param-value>
</context-param>
<filter>
    <filter-name>UploadFilter</filter-name>
    <filter-class>com.sun.rave.web.ui.util.UploadFilter</filter-class>
    <init-param>
      <description>
          The maximum allowed upload size in bytes. If this is set
          to a negative value, there is no maximum. The default
          value is 1000000.
        </description>
      <param-name>maxSize</param-name>
      <param-value>1000000</param-value>
    </init-param>
    <init-param>
      <description>
          The size (in bytes) of an uploaded file which, if it is
          exceeded, will cause the file to be written directly to
          disk instead of stored in memory. Files smaller than or
          equal to this size will be stored in memory. The default
          value is 4096.
        </description>
      <param-name>sizeThreshold</param-name>
      <param-value>4096</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>UploadFilter</filter-name>
    <servlet-name>Faces Servlet</servlet-name>
</filter-mapping>
<servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet>
    <servlet-name>ExceptionHandlerServlet</servlet-name>
    <servlet-class>com.sun.errorhandler.ExceptionHandler</servlet-class>
    <init-param>
      <param-name>errorHost</param-name>
      <param-value>localhost</param-value>
    </init-param>
    <init-param>
      <param-name>errorPort</param-name>
      <param-value>25444</param-value>
    </init-param>
</servlet>
<servlet>
    <servlet-name>ThemeServlet</servlet-name>
    <servlet-class>com.sun.rave.web.ui.theme.ThemeServlet</servlet-class>
</servlet>
<servlet>
    <description>Generated By Sun Java Studio Creator</description>
    <display-name>CreatorPortlet Wrapper</display-name>
    <servlet-name>VSMPortal</servlet-name>
    <servlet-class>org.apache.pluto.core.PortletServlet</servlet-class>
    <init-param>
      <param-name>portlet-class</param-name>
      <param-value>com.sun.faces.portlet.FacesPortlet</param-value>
    </init-param>
    <init-param>
      <param-name>portlet-guid</param-name>
      <param-value>VSMPortal.VSMPortal</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>ExceptionHandlerServlet</servlet-name>
    <url-pattern>/error/ExceptionHandler</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ThemeServlet</servlet-name>
    <url-pattern>/theme/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>VSMPortal</servlet-name>
    <url-pattern>/VSMPortal/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
    <welcome-file>faces/null</welcome-file>
</welcome-file-list>
<error-page>
    <exception-type>javax.servlet.ServletException</exception-type>
    <location>/error/ExceptionHandler</location>
</error-page>
<error-page>
    <exception-type>java.io.IOException</exception-type>
    <location>/error/ExceptionHandler</location>
</error-page>
<error-page>
    <exception-type>javax.faces.FacesException</exception-type>
    <location>/error/ExceptionHandler</location>
</error-page>
<error-page>
    <exception-type>com.sun.rave.web.ui.appbase.ApplicationException</exception-type>
    <location>/error/ExceptionHandler</location>
</error-page>
<jsp-config>
    <jsp-property-group>
      <url-pattern>*.jspf</url-pattern>
      <is-xml>true</is-xml>
    </jsp-property-group>
</jsp-config>
     <security-role>
          <role-name>Administrator</role-name>
     </security-role>
</web-app>
portlet.xml
<?xml version='1.0' encoding='UTF-8' ?>
<portlet-app xmlns='http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd                         http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd' version='1.0'>
     <portlet>
          <description>Created By Java Studio Creator</description>
          <portlet-name>VSMPortal</portlet-name>
          <display-name>VSMPortal Portlet</display-name>
          <portlet-class>com.sun.faces.portlet.FacesPortlet</portlet-class>
          <init-param>
               <name>com.sun.faces.portlet.INIT_VIEW</name>
               <value>/Uctarna.jsp</value>
          </init-param>
          <expiration-cache>0</expiration-cache>
          <supports>
               <mime-type>text/html</mime-type>
               <portlet-mode>VIEW</portlet-mode>
          </supports>
          <supported-locale>en</supported-locale>
          <portlet-info>
               <title>VSMPortal</title>
               <short-title>VSMPortal</short-title>
               <keywords>Creator</keywords>
          </portlet-info>
          <security-role-ref>
               <role-name>Administrator</role-name>
               <role-link>Administrator</role-link>
          </security-role-ref>
     </portlet>
</portlet-app>If I don't use the security-role and security-role-ref tags, the portlet works, and the isUserInRole method obviously doesn't.

Nobody uses the LDAP roles in a portlet? Anybody knows other thread discussing similar issue (I can't find anything)?

JSF Pages are not rendering correctly when loaded using Non JSF actions

Hi All,
This problem is irritating me and I am posting the same query for the third time here.
When I come from non jsf actions such as page submitting using Javascript, clicking anchor link, clicking normal Html submit button and so on my page is not rendering correctlly .
In other words, My first GET method/Post method works perfectly for the first time when the page is loaded.
But when we try to access the page for the second time, although logical work is perfect in bean, I am getting same old page.
How to resolve this issue?
or
Is this Bug of Sun's Implementation of JSF Framework.
Thanks,
Sudhakar

Hi Sudhakar,
There is a discussion about refreshing a page, Take a look at the below thread
http://swforum.sun.com/jive/thread.jspa?threadID=55660
Hope this what you are looking for
MJ

JSF - Best Practice For Using Managed Bean

I want to discuss what is the best practice for managed bean usage, especially using session scope or request scope to build database driven pages
---- Session Bean ----
- In the book Core Java Server Faces, the author mentioned that most of the cases session bean should be used, unless the processing is passed on to other handler. Since JSF can store the state on client side, i think storing everything in session is not a big memory concern. (can some expert confirm this is true?) Session objects are easy to manage and states can be shared across the pages. It can make programming easy.
In the case of a page binded to a resultset, the bean usually helds a java.util.List object for the result, which is intialized in the constructor by query the database first. However, this approach has a problem: when user navigates to other page and comes back, the data is not refreshed. You can of course solve the problem by issuing query everytime in your getXXX method. But you need to be very careful that you don't bind this XXX property too many times. In the case of querying in getXXX, setXXX is also tricky as you don't have a member to set. You usually don't want to persist the resultset changes in the setXXX as the changes may not be final, in stead, you want to handle in the actionlistener (like a save(actionevent)).
I would glad to see your thought on this.
--- Request Bean ---
request bean is initialized everytime a reuqest is made. It sometimes drove me nuts because JSF seems not to be every consistent in updating model values. Suppose you have a page showing parent-children a list of records from database, and you also allow user to change directly on the children. if I hbind the parent to a bean called #{Parent} and you bind the children to ADF table (value="#{Parent.children}" var="rowValue". If I set Parent as a request scope, the setChildren method is never called when I submit the form. Not sure if this is just for ADF or it is JSF problem. But if you change the bean to session scope, everything works fine.
I believe JSF doesn't update the bindings for all component attributes. It only update the input component value binding. Some one please verify this is true.
In many cases, i found request bean is very hard to work with if there are lots of updates. (I have lots of trouble with update the binding value for rendered attributes).
However, request bean is working fine for read only pages and simple binded forms. It definitely frees up memory quicker than session bean.
----- any comments or opinions are welcome!!! ------

I think it should be either Option 2 or Option 3.
Option 2 would be necessary if the bean data depends on some request parameters.
(Example: Getting customer bean for a particular customer id)
Otherwise Option 3 seems the reasonable approach.
But, I am also pondering on this issue. The above are just my initial thoughts.

When is it appropriate to use a servlet in a JSP/JSF environment?

I have inherited a fairly old JSP-based application. I know that I need to update its technologies, in particular the use of AJAX so that I don't need to keep refreshing the page each time I want more data from the server. The problem is that I don't know a great deal about other technologies. There seem to be so many conflicting opinions about the way to go regarding servlets and JSP and JSF (and possibly JavaBeans). I am probably going to start using JSF and AJAX. I mention this to give you some background info. My real question is: when is best/appropriate to use a servlet? From what I have seen I do not want to use a servlet for generating HTML output - that seem just so last decade! But do they still have a good use over more modern technologies? Also, when is it appropriate to use JavaBeans? Are JavaBeans a thing of the past (or just plain inappropriate) for web applications?
Regards,

I suggest going to the bookstore and looking for a book on JSF and reading it cover to cover. It may tell you where servlets come into the picture (if at all). I suggest paying attention to MVC design that it discusses, and working through the examples before working on your project (assuming you have the time). Then creating a simple project and refactor it over and over to meet MVC.
For your project, I suggest just doing ONE JSF page (and its underlying database access) and refactor it over and over again (MVC) before doing the other JSF pages. This way, you dont have to refactor 34 JSF pages to correct the same mistake appearing in all the pages (saves a LOT of time).
I don't know enough about AJAX to really comment on it. However, I would ask myself if refreshing the JSF page is really enough of a concern for your end-users to make it worth while to use AJAX on this project.

JSP ${} expressions in JSF tag attributes

Does anyone know why the expert group decided not to allow ${} style expressions within JSF tag attributes? I understand that a different syntax is needed to implement the 'late binding' #{} expressions used to link input controls to form beans, but not why the JSF tags actually prevent the use of immediately evaluated ${} expressions for accessing variables in the page scope in JSP 2.0.
I know there has been a lot of discussion about this and other threads mention a security loophole that would be opened up by allowing expressions like #{blah.${someProperty}}, but I'm not sure why this sort of thing would cause a problem. Is there any way to enable this behaviour, such as editing the JSF tag library descriptors to allow runtime expressions (horrible though that sounds)? Or perhaps another JSF implementation that supports both immediately evaluated and late-binding expressions? It seems a rather unnecessary restriction that is going to cause much confusion and mistyping for all...
Thanks in advance,
Keith.

Thanks Adam, I see the problem now. It's a fairly obscure loophole but serious nonetheless. Of course, this problem could also be avoided by not using request parameters within JSF tags as it doesn't affect the majority of legitimate uses for expressions.
I have to disagree with you about mixing ${} and #{} expressions though. The majority of developers will be used to writing ${} expressions in JSTL and JSP text and so will expect them to do work the same in JSF tags. Judging by the number of posts in this forum about being unable to use page scope variables in JSF tags this issue is already confusing a lot of people.
As a rule of thumb, "use ${} for expressions that are output to the page and #{} for binding controls to backing beans and invoking methods" (which perform clearly distinct functions) is a lot simpler and easier to learn IMHO than the current one, which is "use ${} for expressions that are output to the page except within a JSF tag, where you use #{} for the same thing and also to update form values and invoke action methods"! (OK, I'm exaggerating a little for effect, but you get the point... :-)
I agree that mixing both types of expression in the same attribute might be a little confusing, but this is an unlikely edge case that should probably be prevented in value binding or action attributes anyway. It's more of an issue for label values where mistyping one for the other is already very common and, although not especially difficult to debug, is just another pitfall awaiting the unwary JSP developer. I'm not sure that JSP expressions would be much more difficult to debug anyway as the value and method bindings will simply not work, which is pretty obvious as soon as you try and test the thing.
Is this something that the EG would be prepared to reconsider for the next release of JSF, or perhaps getting the security loophole addressed in the next JSP spec? In the meantime, is there any reason that developers shouldn't enable runtime expressions in the TLD file provided that they're willing to live with the consequences?
(Sorry to harp on about it, but I've already had several complaints about this after recommending JavaServer Faces for a major development project at ingenta.com.)
Many thanks,
Keith.

Error with JSF application on SAP NetWeaver App Server 7.3

Hello Gurus,
I have a JSF web application which I have deployed on the SAP NetWeaver Server 7.3 , but when trying to access the same I get the error
Cannot process an HTTP request to servlet [Faces Servlet] in [SecurePro] web application. [EXCEPTION] javax.servlet.ServletException: com.sap.engine.services.servlets_jsp.server.jsp.exceptions.CompilingException: Error in executing the compilation process: [ Compilation Failed! Exit Code=1
Has anybody else also got the same error earlier?, I am using Mojarra implementation for JSF.
I had earlier deployed the same application in an earlier JSF version and it worked on NWAS7.0 but Now I need to upgrade that, Please help
Thanks
Somil Agarwal

Hi Ingo,
Yes - Ive tried every possible combination and here is my findings...
I don't think the 32-bit version of the SAP Java Connector (2.1.8) works on a Windows 2003 x64 SAP J2EE 7.0, i.e. the sapjco.jar file. I created a directory and added it to the CLASSPATH of the J2EE server (server and instance) and I also added it to the Java classpath using: java -jar <path+sapjco.jar> -classpath. Executing this command brings up a SAP Java connector window where it displays information of the version, location of the sapjcorfc.dll file etc. This windows opens, but is not able to display the information. If I do exactly the same with the x64 bit version of the SAP Java connector (2.1.8) it displays the information correctly in the SAP Java connector popup. I've tried copying the sapjcorfc.dll and the librfc32.dll to both the /system32 and the SYSWOW64 directory on the server.
HOWEVER, in CMC the Role Import tab still does not work - I just get the text null (in red). Before adding the sapjco.jar to the java classpath I got another error on the Role import tab - something like /com/sap/mw/jco/$JCOFunction. So it seems like it is now able to find the sapjco.jar file, but can not use it properly.
The big question is now: Should the sapjco.jar file actually be on the Application server or on the BOE Server? I know it says on the application server in all documentation, but that generally assumes Tomcat and all installed on one server.
BOE uses the sapjco.jar file to connect to the BW system to import the roles and that must be the BOE server doing that job and not the Application server???
Just my thoughts - maybe we can discuss this at Teched in Phoenix? :o)
Best regards,
Jacob

JSF 1.1 and Tomcat 6

Hello,
I don't know if this issue was already discussed, but I'm porting my application from Tomcat 5.5.25 to Tomcat 6.0.26 and I'm using JSF 1.1.
I encountered problems when receiving events for Tree element. The return value for getSelected() method of Tree object is null. I tried to use other get methods from Tree class and all return null: getSubmittedValue(), getCookieSelectedTreeNode().
Did anyone encounter this problem?
Do you know if are there any incompatibility issues between Tomcat 6 and JSF1.1?
Thanks.

I had a similar problem on OC4J. For some crazy reason, Oracle still bundles their own XML parser (I say still. It's OC4J 10.1.3 we have in production, so we're just a wee bit behind the curve). At any rate, I had to tell OC4j not to use Oracle's XML parser and just the one bundle with the JRE (1.5). IIRC (and I should know this since I work on Mojarra :), that's caused by an older version of JAXB, so I think you're on the right track. You might check to see if Tomcat 6 bundles JAXB. If it does, you'll need to remove it or update it. If you're on 1.5 or greater, I don't think you need to have that in the app server lib anyway, as the JDK/JRE bundles it.
Hope that helps. :)

ANNOUNCE: Speed up your Data-Driven JSF/Seam Application by Two Orders of

Hello,
I am pleased to announce a new article on JSF Central. In the second installment of this two-part article, Dan Allen continues his discussion of some common performance problems you may encounter when using JSF components, Seam components, and the EL. You'll learn about the set of best practices for eliminating them that led to an improvement of two orders of magnitude in the performance of his application.
Here is an excerpt:
In the first part of this article, I began briefing you on optimizations I made to maximize the responsiveness of a JSF application that I developed out in the field. I cited performance problems caused by casually accessing components from a JSF view, then presented a set of best practices to eliminate this unnecessary overhead. Despite the progress made by the end of the first part, you had not yet witnessed the two orders of magnitude in performance improvement that was promised.
In this part, the additional gains will be achieved by leveraging partial page rendering-provided by the RichFaces JSF component library and by slimming the response. Partial page rendering cuts out the overhead of rerendering the entire page after each user interaction, which turns out to be the real bottleneck in most traditional web applications, and instead redraws only the areas of the page that have changed. Naturally, you want the replacement HTML source to be as condensed as possible. These optimizations allow the responsiveness of a web application to measure up to its desktop counterpart.
Read the full article here: [Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude Part 2|http://www.jsfcentral.com/articles/speed_up_your_jsf_app_2.html]
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99 http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3

Hi,
how can we ensure that every body define the id in jsf page. we are using the jsf 1.0 and I think this artical for jsf 1.2
with IBM extended JFS lib.
if we don't want to change the code of full application,is it possible to speed up the render time with the help of framework or some other way.

Using j_security_check container authentication with JSF

Hi All,
After quite a bit of looking around, we resorted to using a plain login JSP page with a ServletFilter on j_security_check to have container managed authentication in our JSF based web-site using IBM Websphere 5.1
So, basically every other page but the login page is JSF and just the login page is simple JSP with j_username & j_password.
Recently, I started looking in the direction of trying to directly/programmatically invoke j_security_check using URLConnection object. There are various discussions on this on google groups:
1. http://groups-beta.google.com/group/comp.lang.java.programmer/browse_thread/thread/1a2768da559e43ae/243982a33f02ab80?q=URLConnection%20j_security_check&_done=/groups?q=URLConnection%20j_security_check&hl=en&lr=&sa=N&tab=wg&&_doneTitle=Back%20to%20Search&d=&
2. http://groups-beta.google.com/group/weblogic.developer.interest.security/browse_thread/thread/a375370efec24566/b81dc8320bcbc304?q=URLConnection+j_security_check&_done=%2Fgroups%3Fq%3DURLConnection+j_security_check%26hl%3Den%26lr%3D%26sa%3DN%26tab%3Dwg%26&_doneTitle=Back+to+Search&&d#b81dc8320bcbc304
My current code snippet is as follows:     public String submit(){
          String retVal = "";
          String j_username = getUserId().getValue().toString();
          String j_password = getPassword().getValue().toString();
          ExternalContext externalContext = getFacesContext().getExternalContext();
          String jsessionid = ((HttpSession)externalContext.getSession(false)).getId();
          // Only if sanity checks and validations on j_username & j_password pass, proceed further.
          ApplicationParameter.getLogger().debug("Current jsessionid=" + jsessionid);
          ApplicationParameter.getLogger().debug("submitting login details (userId: " + j_username + " & password: " + j_password + ") to /j_security_check ...");
          try {
               URL jSecurityCheckURL = new URL("http://localhost:9080/raweb/j_security_check;jsessionid=0000" + jsessionid + ":-1&j_username=" + j_username + "&j_password" + j_password);
               HttpURLConnection jSecurityCheckURLConnection = (HttpURLConnection)jSecurityCheckURL.openConnection();
               jSecurityCheckURLConnection.setRequestMethod("POST");
               jSecurityCheckURLConnection.setInstanceFollowRedirects(false);
//               jSecurityCheckURLConnection.addRequestProperty("j_username", j_username);
//               jSecurityCheckURLConnection.addRequestProperty("j_password", j_password);
//               jSecurityCheckURLConnection.setRequestProperty("j_username", j_username);
//               jSecurityCheckURLConnection.setRequestProperty("j_password", j_password);
               jSecurityCheckURLConnection.connect();
               ApplicationParameter.getLogger().debug("j_security_check returned: " + jSecurityCheckURLConnection.getResponseCode() + ": " + jSecurityCheckURLConnection.getResponseCode());
               if (null != externalContext) {
                    String remoteUser = externalContext.getRemoteUser();
                    ApplicationParameter.getLogger().debug("Authenticated username: " + remoteUser);
                    HttpServletRequest httpServletRequest = (HttpServletRequest)externalContext.getRequest();
                    Principal principal = httpServletRequest.getUserPrincipal();
                    if (null != principal) {
                         String userName = principal.getName();
                         ApplicationParameter.getLogger().debug("Authenticated username: " + userName);
               } else {
                    ApplicationParameter.getLogger().debug("Unable to obtain Faces ExternalContext and hence the remote user details.");
          } catch (MalformedURLException ex) {
               ApplicationParameter.getLogger().error(ex);
               retVal = "";
          } catch (IOException ex) {
               ApplicationParameter.getLogger().error(ex);
               retVal = "";
          return retVal;
The above code yields the following output:[DEBUG]: (Newlogin.submit:81) - Current jsessionid=H1QMk3TuyW_W8nSPnOtW-xi
[DEBUG]: (Newlogin.submit:82) - submitting login details (userId: skhanna & password: password) to /j_security_check ...
[DEBUG]: (Newlogin.submit:93) - j_security_check returned: 302: 302
[DEBUG]: (Newlogin.submit:97) - Authenticated username: null
Anyone have any idea why j_security_check returns 302 and also the authenticated username seems to be null indicating that the authentication did not go through!
-Sandeep Khanna

Can you help me!
I try this for two days....
Tomcat 5.0.27
I get this:
Current jsessionid=00F61ABF316F9A1676A41A1EA05177B2
Submitting login details (userId: admin & password: admin) to /j_security_check!
java.net.ConnectException: Connection refused: connect
I have this code in backing bean:
import java.net.HttpURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
import java.security.Principal;
import javax.faces.context.ExternalContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
public String commandButton_action()
String retVal = "";
String j_username = inputText1.getValue().toString();
String j_password = this.inputSecret1.getValue().toString();
URL jSecurityCheckURL = null;
HttpURLConnection jSecurityCheckURLConnection = null;
ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();
String jsessionid = ((HttpSession)externalContext.getSession(false)).getId();
System.out.println("Current jsessionid=" + jsessionid);
System.out.println("Submitting login details (userId: " + j_username + " & password: " + j_password + ") to /j_security_check!");
try {
jSecurityCheckURL = new URL("http://localhost:9080/raweb/j_security_check;jsessionid=0000" + jsessionid + ":-1&j_username=" + j_username + "&j_password=" + j_password);
jSecurityCheckURLConnection = (HttpURLConnection)jSecurityCheckURL.openConnection();
jSecurityCheckURLConnection.setRequestMethod("POST");
jSecurityCheckURLConnection.setInstanceFollowRedirects(false);
jSecurityCheckURLConnection.connect();
System.out.println("j_security_check returned: " + jSecurityCheckURLConnection.getResponseCode());
//System.out.println("Current jsessionid=" + jsessionid);
if (null != externalContext) {
String remoteUser = externalContext.getRemoteUser();
System.out.println("Authenticated username: " + remoteUser);
HttpServletRequest httpServletRequest = (HttpServletRequest)externalContext.getRequest();
Principal principal = httpServletRequest.getUserPrincipal();
if (null != principal) {
String userName = principal.getName();
System.out.println("Authenticated username: " + userName);
} else {
System.out.println("Unable to obtain Faces ExternalContext and hence the remote user details.");
catch (MalformedURLException ex) {
System.out.println(ex);
jSecurityCheckURL = null;
jSecurityCheckURLConnection = null;
retVal = "";
catch (IOException ex) {
System.out.println(ex);
jSecurityCheckURL = null;
jSecurityCheckURLConnection = null;
retVal = "";
return retVal;
I try all this URL:
http://localhost:8080/jSecurityCheck/j_security_check?jsessionid=" + jsessionid + "&j_username=" + j_username + "&j_password=" + j_password
http://localhost:9080/raweb/j_security_check;jsessionid=0000" + jsessionid + ":-1&j_username=" + j_username + "&j_password=" + j_password
TWO DAYS ..... H E L P M E !!!

JSF 1.2 - Roundtrip just to create a simple Go Back link scenario

From what I've read, it seems JSF 1.2 treats everything as HTTP POST. Hence, doing a simple Go Back means one has to do a round trip to the backend database and back. Here's how I've done it:
1. Create a form and populate it with a list of information. For each line of info in the list, I define a h:outputLink that have four f:param directives to pass the parameters I want to a second form. Of course, the name/id of these params have to be unique. Say, if you want to create a second set of h:outputLink for the list, you have to define new unique name/id. Yuck! Why must name/id be unique? After all, they just going to become URL parameters.
2. To create a "Go Back" link on my second form, I define a h:outputLink with the same number of f:params deriving their values from the URL parameters received from the first form. I have tried the h:commandLink/h:commandButton without success - they just resubmitted the second form without redirecting back to the first form.
3. Once the "Go Back" link is clicked, I have to do a roundtrip to the backend database just to "refresh" the first form - and if I have multiple backing beans providing data for this form - this roundtrip can become quite expensive.
What I gather from doing the JSF for the last five weeks:
1. All requests are submitted as HTTP POSTs - this much is obvious. Thus, this will break the ability to do "light" navigation (such as a Go Back link), bookmarking and so forth due to the POST nature of JSF 1.2 or earlier. JSF 2.x might be different though - I may have to check the spec to confirm this. I have heard that one may need to use Facelets and not JSP as the view technology - otherwise certain features of this implementation will not be available.
2. To pass information as parameters means one has to validate URL parameters to prevent URL tampering from third parties.
3. I can use session scope for the form - but this is an "ugly" way of doing it i.e. If I move to a different area of the website and come back to the form, I can still see the previously generated data - until the session expired of course - then the form is reset to it's pre-submit status. I can appreciate the use of session scope in situation where one want to keep certain information active e.g. when a user logged into a forum or a secured session (HTTPS). To use session scope to just navigate between forms (while maintaining the status of the displayed data) is too much of an overkill.
If there are better ways of doing something trivial like a Go Back link or bookmarking then I'm all open ears. If not, I might have to ditch JSF 1.2 and investigate JSF 2.0. Hopefully, this release would be less painful.
Looking forward to JSF experts' comments surrounding this issue. I'm sure I'm not the first to complain about this framework and I won't be the last. Enough rant...
Edited by: icepax on 26/11/2009 11:32
Edited by: icepax on 29/11/2009 05:45

BalusC wrote:
First, outputlinks do not generate POST.Appreciate your reply. I stand corrected with this comment. But reading a few articles, for example: [JSF Discussions and Blogs|http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/], one has to wonder how JSF 1.x stacks up.
>
Second, how would you do it all in plain HTML/JSP/Servlet without JSF? If you tell how you would do it, then we can suggest the JSF way of it (but with the time you should probably already have realized that your concern/rant makes no sense).Sorry, Bauke, I went from Java straight to JSF for the past five weeks but if I have to guess one would use HttpServletRequest or HttpServletResponse in HTML-JSP-Servlet scenario. What I have done with the roundtrip actually works for me albeit I'm hitting the backend twice instead of once (there are pros and cons of doing it this way but I won't go into detail here). However, this still begs the question about doing something trivial like a Go Back link or bookmarking and why it's not so trivial in JSF.
>
At any way, you may find JBoss Seam interesting. It has an extra scope between request and session in: the conversation scope.Thanks. I could try it or move straight to JSF 2.0 or later.
Don't get me wrong, I love JSF. But I won't see its real potential until I move to JSF 2.x or later. Integrated Facelets support is something I'm looking forward to -:)

Building JSF 1.2 Custom Components with EL and standard components

Hi all,
I have built custom components in jsf 1.1 with great success but i am finding replicating the same functionality in jsf 1.2 very difficult. I have some conditions for my new custom component.
- Using jsf 1.2
- Must use unified EL, i am using a UIComponentELTag
- iam using jsf standard html components from javax.faces.component.html here in particular i wont HtmlCommandLink.
Essentially i am constructing a real time command menu. I have a backing bean from which i get command names and descriptions values. I wont to then in real time construct a table of links (using HtmlCommandLink) - all this work is to be processed by a custom component. Basically the commandLink issues a command in my backing bean, a parameter (param) is passed with the commandLink, this is later picked up in the backing bean method.
I can generate the table, and all the HtmlCommandLinks, i have simply looped throught and encoded each of them.
What i can do: i can see the table and the HtmlCommandLinks, but the links dont perform any action when i press them.
What i want help with:
I want to encode a HtmlCommandLink in my custom component with a param, traditionally i would set the action but this is now deprecated, and i need to use the setActionExpression method. I have tried to do this but the actions are note fired its simply doesnt function.
Note:
In jsf 1.1 I use to loop through all the HtmlCommandLink and peform their processDecodes method within my custom components very own processDecodes. The same in jsf 1.2 doesnt seem to yield any results.
Can someone give be an example or solution to this? I have read articles on the net and they seem to all discuss jsf 1.1 which i have done and it works, but i am using unifed EL and jsf 1.2 now.
Many Thanks,
Kev

Hi all,
I have built custom components in jsf 1.1 with great success but i am finding replicating the same functionality in jsf 1.2 very difficult. I have some conditions for my new custom component.
- Using jsf 1.2
- Must use unified EL, i am using a UIComponentELTag
- iam using jsf standard html components from javax.faces.component.html here in particular i wont HtmlCommandLink.
Essentially i am constructing a real time command menu. I have a backing bean from which i get command names and descriptions values. I wont to then in real time construct a table of links (using HtmlCommandLink) - all this work is to be processed by a custom component. Basically the commandLink issues a command in my backing bean, a parameter (param) is passed with the commandLink, this is later picked up in the backing bean method.
I can generate the table, and all the HtmlCommandLinks, i have simply looped throught and encoded each of them.
What i can do: i can see the table and the HtmlCommandLinks, but the links dont perform any action when i press them.
What i want help with:
I want to encode a HtmlCommandLink in my custom component with a param, traditionally i would set the action but this is now deprecated, and i need to use the setActionExpression method. I have tried to do this but the actions are note fired its simply doesnt function.
Note:
In jsf 1.1 I use to loop through all the HtmlCommandLink and peform their processDecodes method within my custom components very own processDecodes. The same in jsf 1.2 doesnt seem to yield any results.
Can someone give be an example or solution to this? I have read articles on the net and they seem to all discuss jsf 1.1 which i have done and it works, but i am using unifed EL and jsf 1.2 now.
Many Thanks,
Kev

JSF 1.2_13 (Mojarra) - h:selectOneMenu problem

I have this JSF tag in my JSP form:
<h:selectOneMenu id="selectLang" value="#{langList.selectedItem}">
      <f:selectItems value="#{langList.selectItems}" />
</h:selectOneMenu>and this backing bean:
     private List<SelectItem> selectItems;
     private String selectedItem;
        createList();
    // getter methods
    public List<SelectItem> getSelectItems() {
         return selectItems;
    public String getSelectedItem() {
         return selectedItem;
    // setter method
    public void setSelectedItem(String selectedItem) {
         this.selectedItem = selectedItem;
    private void createList()
        selectItems = new ArrayList<SelectItem>();
        selectItems.add(new SelectItem("1", "English"));
        selectItems.add(new SelectItem("2", "Français"));
    }I found that I can't change "selectedItem" and "selectItems" to say, for example "selectedLang" and "selectLangs" respectively in both the JSF tag and the matching backing bean method. How odd! It seems to me that the above definitions can't be changed. If I changed them to any name at all, I get the dreaded "JSF1054: (Phase ID: RENDER_RESPONSE 6..." error - which is not really helpful in identifying the problem.
I also have another problem with "h:selectOneMenu" but I guess I might to wait for your responses before I post the problem here or in another thread.
BTW, have search the forums for existing discussion but didn't find one resembling my problem. I have already lost two days trying to figure this problem out - but not successful. Maybe the solution might be really simple...
Can someone please help? Sorry if I make any mistake since this is my very first post - just joined about 30 minutes ago -:)
cheers and regards

Further to my reply above, I've tried Mojarra (1.2_12-b01-FCS) and the new Mojarra 2.0.0 (RC b16) releases and am able to replicate the same problem with these releases - one cannot rename "selectItems" and "selectedItem" in the JSF tag as well as the backing bean. Anyway, here is my full backing bean code in the hope that someone can see a problem with it:
package example;
import java.util.ArrayList;
import java.util.List;
import javax.faces.model.SelectItem;
public class LangGenerator
     private List<SelectItem> selectItems;
     private String selectedItem;
        createList();
    // getter methods
    public List<SelectItem> getSelectItems() {
         return selectItems;
    public String getSelectedItem() {
         return selectedItem;
    // setter method
    public void setSelectedItem(String selectedItem) {
         this.selectedItem = selectedItem;
    private void createList()
        selectItems = new ArrayList<SelectItem>();
        selectItems.add(new SelectItem("1", "English"));
        selectItems.add(new SelectItem("2", "Français"));
}and my TEST.JSP codes:
<%@ page contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" language="java" %>
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Example</title>
</head>
<body>
     <f:view>
          <h:form id="form1">
               <h:panelGrid>
                    <h:panelGroup>
                         <h:selectOneMenu id="selectLang" value="#{langList.selectedItem}">
                              <f:selectItems value="#{langList.selectItems}" />
                         </h:selectOneMenu>
                    </h:panelGroup>
               </h:panelGrid>
          </h:form>
     </f:view>
</body>
</html>The PROBLEM: If I left the names as "selectItems" and "selectedItem" it render the page fine. But if I change them to "selectLangs" and "selectedLang" respectively in both the JSF tag and the supporting backing bean - it will not work, period. I'm very confused now.
Is this a bug with the Mojarra JSF implementation?

JSF 2.0 Discussion

Similar Messages

Maybe you are looking for