Frequently Asked Questions about Mojarra (Oracle's JSF implementation)This Wiki page is for questions about Mojarra (Oracle's JSF implementation). General FAQs about the JSF Specification are covered in The FAQ for the JSF Specification. Table of Contents:
Access to the source code for Oracle's implementation of the JCP JSF Specification is subject to the terms of either the GNU Refer to the version control instructions for details on configuring your client. If you don't have a java.net ID, you can check out the source anonymously by using the guest account. The version control instructions also contains information pertaining What are the tags for the current releases of Mojarra?
No, though we don't use Maven, we do have a system in place to download all the necessary dependencies How do I build the Mojarra sources?Assuming SOURCE_HOME is the directory containing the javaserverfaces-sources...
Note: The first time you build you should use ant main clean main. After that use ant clean main as mentioned above. The jsf-api.jar will be in SOURCE_HOME/jsf-api/build/lib and jsf-impl.jar will be in SOURCE_HOME/jsf-ri/build/lib. How do I run the automated tests?There are two major sets of tests in the source tree. One set for the API, and the other Ed Burns wrote a blog entry about the tests. See <http://www.java.net/blog/edburns/archive/2011/03/15/summary-mojarra-hudson-jobs-and-automated-tests-they-run>. How can I contribute?Please note the following:
oracle-ca_us [at] oracle [dot] com If you wish to fax the form, ask for the fax number by sending an email to the preceding address. For more information on the OCA, see the FAQ. Follow the instructions in How do I prepare a change bundle? for quick acceptance of your patch. If your patch doesn't include a test case, we would have to create or update an existing test for it which would delay the acceptance of your patch. If you are unable to do so, you can do the following: The developer responsible for the section of code affected should either apply the patch and mark the issue FIXED; or add a comment with an objection if the patch does not seem safe, does not appear to fix the problem, or there is not really a problem to begin with. Developers must also confirm that the contributor has filled in and submitted a JCA before commiting their patch. Notifications of any changes to Issue Tracking, as well as CVS checkins, are automatically sent to the appropriate bug and CVS mailing lists, so you can monitor if the patch has really been applied. Make sure you subscribe to at least the CVS and bug mailing lists for the module you are working on - see the mailing lists page for details. How do we avoid svn error "svn: E155017: Checksum mismatch while updating..."This error happens when svn merge is allowed to create directories. If you are merging using svn and you see that files have been added as a result of the merge, DO NOT COMMIT. Instead, save aside the now files, svn revert them locally, replace the new files and then svn add them. How do I create a Short Self-contained Correct (Compilable) Example for a bug report?
mvn archetype:generate -DarchetypeGroupId=com.sun.faces \ -DarchetypeArtifactId=faces-2.1-test-war-archetype \ -DarchetypeVersion=0.1 \ -DarchetypeCatalog=https://maven.java.net/content/repositories/releases/archetype-catalog.xml For JSF 2.2 use mvn archetype:generate -DarchetypeGroupId=com.sun.faces \ -DarchetypeArtifactId=faces-2.2-test-war-archetype \ -DarchetypeVersion=0.1 \ -DarchetypeCatalog=https://maven.java.net/content/repositories/releases/archetype-catalog.xml After answering the questions, add the necessary content to the webapp and build with the -Pfaces-test profile enabled. If this profile is omitted, the project will not build. How do we triage and assign bugs?Bugs filed in the Mojarra Issue Tracker are triaged by the Mojarra team with the goal of maximizing the number of bugs resolved and minimizing the effort taken to resolve them. The most important ingredient to achieve this goal is responsiveness: first on the part of the Mojarra team and second on the part of the reporter. The Mojarra team will do its best to respond to all bugs within four weeks of filing, and to take some concrete action towards resolving the bug at least once every four weeks. The remainder of this answer will describe the lifetime of a bug in two scenarios.
What Fix Version/s do I set when I close an issue?For work on the trunk, set the Fix Version/s to be the next milestone, such as 2.3.0-m02 and also the next release, such as 2.3.0. How do I prepare a change bundle?The JavaServer Faces team practices Test Driven Design. All code checked in must be accompanied by a new automated testcase that exercises that code, or changes to an existing automated testcase that exercises the code. When writing your code, you have the choice of whether a unit test or a system test would be more appropriate to verify the correctness of your code. Unit tests live in the jsf-ri/test directory, and system tests live in the jsf-ri/systest directory. Please read this article, or other literature for an introduction to Test Driven Design.
ant cb
Please refer to the issue "id" in the bundle and in the subject of your email.
For example: Looks good, r=edburns
What is the code checkin procedure?Once you have completed the review process, please follow this process to ensure a smooth checkin that doesn't break the tree.
cvs -n update -d -P
cvs commit Type in your log message, or import it from a message file via cut and past or some such. How do I become a committer?Follow How can I contribute? and start contributing enough [#HowToBundle]solid patches] that get accepted into the codebase so that we can get a feel for the quality of your code. Contributors who give frequent and valuable contributions will be nominated for "developer" role if they desire. We would appreciate if commiters could abide by the code review and test driven development process we use. If you think this process is too onerous, please send your comments to project owner. How do I make sure that changes to the spec have the correct version changebar attributions?This answer was taken from an email sent to one of the engineers working on Mojarra in response to a similar question. There's another question that covers the css attributes that make the changebars in the generated portions of the specification work. Here we show how to use them. The attributes are applied to three levels of documentation, and they all need to be updated as the spec is edited. For all levels, there are two kinds of attributions. "First Word" attributions. This kind of attribution makes the first word of the level show the, "changed" attribution. It's called "first word" because only the first word is marked to give the reader a quick notice that "something changed in this" section of the spec, where section is spec section, package, class, etc. "body text" attributions This kind of attribution marks the whole of the changed section with the appropriate attribution, "changed", "modified", or "deleted". Level 1: jsf-api/src/main/resources/overview.html Add "first word" attributions for all sections of the spec that changed within a spec iteration. For example, at this point in JSF 2.2, all spec sections except for the JSP Taglibrary docs have been changed. Therefore, the table titled "The Java Server Faces Specification is composed of several documents:" shows changed_modified_2_2 first word attributions for all those sections. Level 2: package.html Add "first word" attribution for each package that changed within a spec iteration. Level 3: Compilation Unit level Add "first word" attribution for each Class/Interface/TagHandler/Renderer/JavaScriptObject that changed during a spec iteration. Level 4: Leaf level Add "first" word attribution on the individual method, etc, and also add "body text" attribution. This last bit is the really important part, because all the other levels simply point to "body text" attributions. Here is some example text. Finally, to let the developer know that ResourceHandler was modified during JSF 2.1, make it so the very first word in the javadoc for the class has the changed_modified_2_1 CSS attribute. In the case of ResourceHandler.java, this means adding the changed_modified_2_1 CSS class to the value of the "class" attribute on the <strong> element that wraps the word "ResourceHandler". To see your change in action, note which class has the CSS changes you expect then cd to jsf-api and do "ant javadocs". Look at the build output to see where the javadocs are generated. Open up the top level index.html file in a browser, navigate to the javadoc for the class that has the changes, and verify that the color coding is correct as you expect. What files need to be modified to affect changes in the CSS for the generated portions of the specification.Look at this log message when these changes were made for JSF 2.1. Create CSS and images for 2.1 changebars. M jsf-tools/src/main/resources/com/sun/faces/generate/facesdoc/stylesheet.css A jsf-api/doc/changed_added_2_1.png A jsf-api/doc/changed_modified_2_1_cursor.cur A jsf-api/doc/changed_added_2_1_cursor.cur A jsf-api/doc/changed_deleted_2_1.png A jsf-api/doc/changed_deleted_2_1_cursor.cur A jsf-api/doc/changed_modified_2_1.png M jsf-api/src/main/resources/jsf-api.css M jsf-ri/conf/share/tlddoc-resources/stylesheet.css M jsf-api/doc/jsdoc-template/static/default.css Note: the changebars that apply to the generated documentation for the XSD files are handled using CSS selectors in the jsf-api.css file. Questions pertaining only to Oracle's implementation of the JSF specification
FACES_LOGGER=javax.enterprise.resource.webcontainer.jsf |
| Parameter name | Description | Default Value | Introduced in Version |
|---|---|---|---|
| com.sun.faces.allowTextChildren | If true, allow children of h:inputText and h:outputText to be rendered. In 1.2, they would always be rendered before the value of tag. In 2.0, they will not be rendered at all unless this flag is set. | false |
2.2 |
| com.sun.faces.annotationScanPackages |
The value of this context init parameter is a whitespace separated list of values that control which class packages are scanned for annotations. To restrict which jars/packages are scanned, use the following entry format: jar:<jar name>:<comma separated list of packages> So an example would be: jar:a.jar:com.acme.package1,com.acme.package2 | "" |
2.0 |
| com.sun.faces.autoCompleteOffOnViewState | If false, don't use autocomplete="off" when saving view state. | true |
2.0 |
| com.sun.faces.cacheResourceModificationTimestamp | If true, cache the modification time of the resource and use the cached time to tell if the resource needs to be refreshed |
false |
2.0 |
| com.sun.faces.numberOfViewsInSession | (note the implementation unintentionally has swapped the meaning, as we cannot change this without breaking what people have become used to we have updated this here) | 15 | 1.2 |
| com.sun.faces.numberOfLogicalViews | Defines the maximum number of serialized views stored in the session. Works with server state saving (note the implementation unintentionally has swapped the meaning, as we cannot change this without breaking what people have become used to we have updated this here) | 15 | 1.2 |
| com.sun.faces.preferXHTML | For the case where a browser supports xhtml and html without a quality. When enabled and this case occurs, then xhtml will be set as the content type. | false | 1.2 |
| com.sun.faces.compressViewState | When true the view is compressed after it is serialized and before base64 encoded. Works with client state saving. As of 1.2_09, this option also impacts server side state saving when com.sun.faces.serializeServerState is set to true (this has a large impact of the size of the state in the session when using this option, at the expense of more CPU of course) | true | 1.2 |
| com.sun.faces.disableVersionTracking | Version tracking detects 1.1 artifacts (FacesContext or Application implementations as an example) within the 1.2 runtime. If you have a pure 1.2 environment, then you could disable it. | false | 1.2 |
| com.sun.faces.enableMissingResourceLibraryDetection | If enabled, the runtime will check for the existence of a resource library before checking for the resource itself. If not found, an appropriate error message will be included in the log and in the view if ProjectStage is Development. |
false |
2.1 |
| com.sun.faces.sendPoweredByHeader | The servlet specification defines an optional header that can be sent by a container to communicate the version of the JSP/Servlet the response was generated by. If this is enabled, then JSF/1.2 is included in this header. | true | 1.2 |
| com.sun.faces.verifyObjects | When true JSF makes sure all managed beans components,validators, etc can be instantiated by the runtime | false | 1.2 |
| com.sun.faces.validateXml | When true JSF validates the configuration files. | false | 1.2 |
| com.sun.faces.displayConfiguration | If true then all web configuration information (context initialization parameters and environment entries) will be written to the log. This is useful during development to confirm your application is configured as expected. Valid values for this parameter are true and false | false | 1.2_01 |
| com.sun.faces.injectionProvider | This parameter specifies a class that implements the InjectionProvider for more details | NONE | 1.2_01 |
| com.sun.faces.serializationProvider | This parameter specifies a class that implements the SerializationProvider SPI. This implementation represents a hook the JSF implementation will use in order to allow the use of alternate Serialization implementations. See the documentation of the interface for more details | NONE | 1.2_01 |
| com.sun.faces.responseBufferSize | This parameter specifies the size, in bytes, of the buffer that is used to write all generated content excluding state. | 4096 | 1.2_01 |
| com.sun.faces.clientStateWriteBufferSize | This parameter specifies the size, in bytes, of the buffer that is used to write client state. It should be noted, that the buffer used is split - half is for raw bytes, the other half is for the Base64 encoded characters of said bytes. So, for example, if the default, 8192, is used, then 4096 of that is used for the bytes, and the other 4096 is used for the Base64 encoded characters. | 8192 | 1.2_01 |
| com.sun.faces.compressJavaScript | If true, then the JavaScript rendered by h:commandLink will be compressed to reduce the amount of whitespace transmitted in the response. If false then the JavaScript will be rendered to the client in a well formatted manner. | true | 1.2_02 |
| com.sun.faces.externalizeJavaScript | When true a script element with a src attribute. This allows browsers to cache the JS resource instead of having to write it each time the page is accessed. | false | 1.2_03 |
| com.sun.faces.enabledJSStyleHiding | If true, inlined JavaScript rendered by the HTML ResponseWriter implementation will be rendered so that the script is hidden from older browser implementations. | false | 1.2_03 |
| com.sun.faces.writeStateAtFormEnd | Per the renderkit doc specification, the state information for the view will be written out prior to closing the form tag. However, it may be desirable to have the state information written out after the opening form tag. If this is the case, specifiy this parameter in the web.xml with a value of false. | false | 1.2_04 |
| com.sun.faces.enableLazyBeanValidation | If true, managed beans will be scurtinized when first created. If false, managed beans will be validated when the application is started, at the expense of a slightly slower start time. | true | 1.2_05 |
| com.sun.faces.enabledLoadBundle11Compatibility | See Issue 577 for details. When this flag is true, The f:loadBundle will behave as it did in JSF 1.1. If you've migrated from 1.1 to 1.2, and haven't had any issues with f:loadBundle it is safe to ignore this option. | false | 1.2_05 |
| com.sun.faces.clientStateTimeout | This specifies the maximum time (in seconds) that client state will be considered valid by the default StateManager/ResponseStateManager implementations. If the time between requests exceeds the configured time, a javax.faces.application.ViewExpiredException. will be thrown. It is important to note that if this feature is enabled, and client requests are recieved with view state produced from a previous version, the ViewExpiredException will be thrown immediately. | NONE | 1.2_05 |
| com.sun.faces.serializeServerState | If enabled the component state (not the tree) will be serialized before being stored in the session. This may be desirable for applications that may have issues with view state being sensitive to model changes. | false | 1.2_05 |
| com.sun.faces.enableViewStateIdRendering | If true, the view state hidden field will be rendered with both the id and name attributes having the value of "javax.faces.ViewState".This is what the spec requires, however, if there are multiple forms within a view and the response content-type is XHTML, the result will be XHTML that will fail validation due to multiple ID attributes with the same value: javax.faces.ViewState. Setting this parameter to false will result in the ID attribute not being rendered. Keep in mind however, that doing this may break integration with AJAX frameworks that get the state field via ID. See issue 433 for details. | true | 1.2_08 |
| com.sun.faces.enableScriptsInAttributeValues | If false, attribute values with javascript: or script: will not be rendered within attribute values to prevent potential XSS attacks. | true | 1.2_08 |
| com.sun.faces.disableUnicodeEscaping | By default any characters above a certain range will be escaped as either an HTML entity or a decimal reference. This behavior is not always desirable. To allow more flexibility how content is rendered to a client, this option was introduced. Valid configuration values are: false, true, and auto with false being the default. When the option value is false, Mojarra will continue to escaped no matter the response encoding type. If the configuration value is true, Then no escaping will occur assuming that the response encoding can properly handle all characters. If the configuration option is auto then the response encoding will be checked. If the encoding is of the UTF family of encodings no unicode or html entity encoding will occur, however, if the response stream encoding is ISO-8859-1 then the ISO characters above a certain range will be encoded as HTML entities and any characters above that range will be written as decimal references. | false | 1.2_09 |
| com.sun.faces.developmentMode | When true, class caching is disabled so that dynamic loading of Groovy artifacts can take place. (Groovy artifacts must be placed in WEB-INF/groovy, and groovy-all-1.6.9.jar must be in the classpath). Additionally, any changes made to WEB-INF/faces-config.xml or any configuration resource referenced by the javax.faces.CONFIG_FILES context parameter will cause the JSF application to reload itself (without re-deploying). | false | 1.2_09 |
| com.sun.faces.enableMultiThreadedStartup | By default, Mojarra starts threads at startup, for a faster startup time. Because generating threads is forbidden in Google App Engine, this option must be set to false when deploying to GAE. | true | 1.2_13 |
| javax.faces.LIFECYCLE_ID |
Context initialization parameter name for the lifecycle identifier of the Lifecycle instance to be utilized | "" |
1.0 |
In addition to the above context parameters, the following JNDI environment entries are available
| JNDI Environment Entry Name |
Description |
Default Value |
Version introduced |
|---|---|---|---|
| java:comp/env/jsf/ClientSideSecretKey | The value of this entry is passed through DatatypeConverter.parseBase64Binary() and then passed as the first argument to SecretKeySpec(byte [], "AES"). This secret key is used to encrypt the view state. |
If not specified, KeyGenerator.generateKey() is used to generate the Secret Key. |
2.2.7 |
| java:comp/env/jsf/FlashSecretKey | The value of this entry is passed through DataTypeConverter.parseBase64Binary() and then passed as the first argument to SecretKeySpec(byte [], "AES"). This secret key is used to encrypt the value of the flash cookie. |
If not specified, KeyGenerator.generateKey() is used to generate the Secret Key. | 2.2.7 |
This is not necessary if you're using a milestone build of GlassFish UR1 or GlassFish V2. Edit your APPSERV_HOME/domains/<domain-name>/config/default-web.xml and add the following context init parameter:
<context-param> <param-name>com.sun.faces.injectionProvider</param-name> <param-value>com.sun.faces.vendor.GlassFishInjectionProvider</param-value> </context-param>
This isn't a bug in JSF state saving. In fact, serialization of anonymous class instances is discouraged due to
several known complications. These are spelled out in section 1.10 of the serialization specification.
This has been raised as an issue with the JVM team, but closed as NOT A BUG. Please see bug 4862448 for further details.
As of 1.2_05, there is only one listener - com.sun.faces.config.ConfigureListener.
One of your Tomcat applications has no web.xml in its WAR file / directory structure. A work-around for this problem is to ship Mojarra in each of your JSF applications, or to add a valid web.xml to the offending application.
The problem is that Mojarra (JSF 2 RI) scans three places for classes annotated with @ManagedBean:
Since Jetty reads the class files from target/classes in embedded mode, JSF 2 doesn't know to scan them there (unless META-INF/faces-config.xml is present). Basically, instead of just scanning all classpath entries, Mojarra is very specific.
If you really want to get productive with JSF 2 right out of the box w/ embedded Jetty, I recommend looking into the weld-jsf-servlet-minimal artifact, which prepares a JSF 2.0 and CDI 1.0 application for you.
http://tinyurl.com/weld-archetypes
If you use @Named classes (from CDI) rather than @ManagedBean (from JSF 2), a substitue I recommend anyway, then you can get the productive you want.
Here is the workaround with Mojarra with regard to the scanning: http://java.net/jira/browse/JAVASERVERFACES-1111. If you put faces-config.xml in src/main/resources/META-INF, then it will find the classes you want.
Here is a dump of Ed's collected Frame Crib Sheet
Launch frame by double clicking on the book. Then open all the chapters.
Update dates. On TitlePage .fm update the expert draft version.
Make sure page numbers are updated. File->Edit->Update Book, make sure all boxes are checked.
File->Save as Book. Choose PDF type and location, and accept defaults in setting window, pressing Set on that window.
It's in the Settings window:
Cannot resolve external resource into attachment.
How to get rid of them.
Format->Document->Change Bars. Do this for each chapter.
When all of the work for a spec revision has been completed, check the work in, tag the workspace, then clear the changebars in all the chapters, and re-check in the files so they're ready for more revisions.
The character catalog is accessed with the little "f" icon in the upper right hand corner of the inividual MDI window. The Default Font mode is the normal mode. The code mode is for code. The emphasis mode is for italics. Don't use the Italic button.
The paragraph catalog is like the character catalog, but it's a paragraph symbol that accesses it. Commonly used ones are:
Paragraph is the default
Code Bullet 1 is when quoting the API method and signature
Bullet 1 is a bulletted list.
*Codeline is nice for showing XML code. You have to hit the tab key one more time than you think.
Tables
Like word, but not as nice.
Make sure the both the source and target documents are loaded into Frame.
Go to where you want to put the "source" of the reference, and usually, you type "please see". Right click and choose "Cross-Reference".
In the "Cross-Reference" dialog, twiddle the "Document:" drop-down to choose the document in which the target resides.
Twiddle the "Source Type" widget to say "Paragraphs"
Twiddle the "Paragraph Tags" option list to choose the paragraph type, say "Head2" to which you want to refer. As you choose different paragraph types, the section headers should show up in the "Paragraphs" list, to the right. Choose the one you want!
Twiddle the "Format" widget to show the right style, usually "SectionNumber&Title".
Press Insert.
If you can re-create those images as PCX files, you can import them in to the document and they should look good.
Here are the tags and their order:
TitleText .ChapTitle .ChapTitleC .ChapTitleP ..Head1 ..Head1P ...Head2 ...Head2P ....Head3 ....Head3P
To reorder them:
Frame doesn't strip it out, but you can show/hide conditional text before you generate the PDF.
The Show Condition Indicators checkbox toggles whether conditional text should use colors 
or be black 
. For instance, the Comment conditional text setting makes the text red and underlined when Show Condition Indicators is checked.
A tip on hiding all conditional text in a book:
If you are marking an entire paragraph as conditional text, make sure you select the paragraph marker (viewable when you select View>Text Symbols). If you don't, there will be empty lines in the book when you turn off the conditional text.
WLS 12.1.1 has Mojarra 2.0.4-b07. Here's how to run it.
- JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.endorsed.dirs=${JAVA_HOME}/jre/lib/endorsed${PATHSEP}${MODULES_DIR}/endorsed"
+ JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.endorsed.dirs=/home/ejburns/Documents/JavaEE/workareas/mojarra-1HEAD/glassfish-3.1.2/glassfish3/glassfish/modules/endorsed"
--- setDomainEnv.sh~ 2012-07-31 11:52:47.343586000 -0700
+++ setDomainEnv.sh 2012-07-31 12:05:07.122841000 -0700
@@ -71,6 +71,8 @@
BEA_JAVA_HOME=""
export BEA_JAVA_HOME
+debugFlag="true"
+
SUN_JAVA_HOME="/scratch/ejburns/SunOS_5.10_i86pc/usr/jdk/instances/jdk1.6.0"
export SUN_JAVA_HOME
@@ -341,6 +343,8 @@
JAVA_DEBUG=""
export JAVA_DEBUG
+debugFlag="true"
+
if [ "${debugFlag}" = "true" ] ; then
JAVA_DEBUG="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=${DEBUG_PORT},server=y,suspend=n -Djava.compiler=NONE"
export JAVA_DEBUG
Once this is done, the debugging port is 8543 by default.
This varies from release to release, but in 12.1.1, for JSF 2.0.4-b07, jsf-api.jar is <install_dir>/modules/javax.jsf_1.0.0.0_2-0.jar and jsf-ri.jar is <install_dir>/modules/glassfish.jsf_1.0.0.0_2-0-4.jar. These files can be patched with updated .class files as necessary for debugging purposes.
Component writing can be, at least at first, an almost overwhelming task. To make things a bit simpler, Mojarra committer Jason Lee has written a quick check list of things to do when writing components, with special attention paid to those areas where the 1.1 and 1.2 specs differ.
Maven 2 Repository for JSF 2.0 and Later
<repository>
<id>java.net</id>
<name>java.net</name>
<url>http://download.java.net/maven/2</url>
</repository>
Maven 1 Repository for JSF 1.2 and Earlier
<repository>
<id>java.net.maven1</id>
<name>java.net</name>
<url>http://download.java.net/maven/1</url>
</repository>
The EL jars are also available via java.net's Maven repository.
Server side state saving is where the component tree and all component state are stored within
the user's session. This entry within the session is tracked by writing a key in the response
that is used to lookup the entry on subsequent post-backs.
Client side state saving doesn't leverage the server side session mechanism at all, instead,
the component tree and state will be serialized using Java Serialization, GZIP compressed
(at least that is the default), Base64 encoded, and written to the response. When a post-back
occurs, the encoding process will be reversed which will result in the tree and state we started
with.
As to the benefits/drawbacks, review the following table.
| State Saving Method | Server Side Memory Usage | CPU Usage | Bandwidth Usage |
|---|---|---|---|
| Server without compression | High | Low | Low |
| Server with compression | Low/Medium | High | Low |
| Client with compression | Low | High | Medium |
| Client without compression | Low | Med | High |
Mojarra has three context initialization parameters that affect client side state saving:
There are four context initialization parameters for server side state saving:
A comment on the numberOfXXX parameters. Logical views are best defined as top level view that may have one or more actual views inside
of it. A new logical view entry will be created any time a GET occurs (a new request, a frameset, two browser windows...). The value
of this logical entry is another Map that will be used to store the view information (i.e. the structure and state). As a user progresses
through an application using standard JSF navigation mechanisms, additional view state will be added to the Map associated with a single
logical view.
As an example, using the jsf-guessNumber application.
By default, view state will not be encrypted. However, there is a way to do this within the Mojarra.
Specify a environment entry like so:
<env-entry>
<env-entry-name>jsf/ClientSideSecretKey</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>[SOME VALUE]</env-entry-value>
</env-entry>
The presence of this JNDI entry will cause the state to be encrypted using
the specified password. We realize this isn't the most secure way of conveying
a password, however, this cannot be accessed easily without having code executed
on the server side.
This is most probably caused by a request going to your server but not being picked up by the FacesServlet. Make sure you have properly mapped the FacesServlet. You need to follow the insructions in Writing the web.xml File and Invoking the FacesServlet in the JavaServer Faces Tutorial.
This occurs because security constraints aren't applied by the container when using
RequestDispatcher.forward() as the default NavigationHandler implementation will do.
In order to overcome this, you must configure the navigation to perform a redirect instead.
You can do this by adding an empty redirect element to the rule.
If you're using JSPs for your view descriptions, then yes, you will need to use a
JSP 2.1/Servlet 2.5 compliant container. However, if you're using another view
technology, such as Facelets or JSFTemplating, you can run JSF 1.2 within a Servlet
2.4 container with out issue.
First, some general webtier resource injection information can be found here. This documents what all EE5 containers will provide at the webtier level. This provides some basic examples that should get the typical application developer started.
Mojarra doesn't provide it's own resource injection mechanism. Instead, it exposes an InjectionProvider SPI that container vendors can
implement which will allow Mojarra to take advantage of the container's resource injection mechanisms. This blog entry covers the details of the SPI and how it works.
That said, Mojarra includes InjectionProviders for the following containers: GlassFish, Tomcat 6, and Jetty 6.
It should be noted that in all cases what can be injected in a ManagedBean is purely a semantic of what the host
container supports. If you're application was written with JavaEE 5 in mind, the application would be portable to
all EE5 compliant containers, but may not run in, say, Tomcat 6 or Jetty 6. In those two cases, we only inject
what the container itself supports.
There are instructions for this at this site.
You must update three jar files in the GlassFish modules directory.
All of these are in the Maven Central repository.
Include a sun-web.xml file in the war that has the following lines:
<class-loader delegate="false"/> <property name="useBundledJsf" value="true" />
and bundle Mojarra 1.2 into the WAR as well, and it should work.
For a per-app basis, do this:
Include a sun-web.xml file in the war that has the following lines:
<sun-web-app> <class-loader delegate="false"/> <property name="useMyFaces" value="true"/> </sun-web-app>
and bundle Mojarra 2.0 into the WAR as well, and it should work.
For upgrading the whole app server to Mojarra 2.0, see the release notes
Please see Cay's blog on the topic
Make sure your -Xmx is high enough. 4096 works. Also, I've seen the need to add ulimit -h 4096 to the system.