How to define multiple resource bundle in faces-config.xml in jsf 2.0 ?
I have searched on various blogposts but every post talks about using only one resource bundle.
I am new to JSF .Any help on any resource would be of great help.
Related
According with log4j and log4j2 documentation it's work well using tld with jsp pages.
http://logging.apache.org/log4j/2.x/manual/webapp.html
http://logging.apache.org/log4j/2.x/log4j-taglib/tagreference.html#log.tld
It is possible to be used with xmlns:log="http://logging.apache.org/log4j/tld/log" within jsp 2 xhtml page ?
My java faces web-app 3.0 catch the following error.
This page calls for XML namespace http://logging.apache.org/log4j/tld/log declared with prefix log but no taglibrary exists for that namespace.
My web environment is:
Java 1.6.0_38
Tomcat 7.0.50
Mojarra JSF 2.2.4
Primefaces RC 4.0
log4j2-beta9 (/web-INF/lib/ with log4j-1.2-api-2.0-beta9.jar,log4j-api-2.0-beta9.jar,log4j-core-2.0-beta9.jar,log4j-taglib-2.0-beta9.jar)
Any feedback it's appreciated.
Would you mind raising this on the Log4j2 issue tracker?
https://issues.apache.org/jira/browse/LOG4J2
I have a modular JSF application. Facelets are stored in the module in META-INF/resources. I added a custom FaceletsResourceResolver (as demonstrated in this post How to create a modular JSF 2.0 application?) and all of this works well with .xhtml - Files. Now I am trying to add other resources in the same fashion and it's not working.
Let's say I have this structure in the module:
/META-INF/resources
/META-INF/resources/foo
/META-INF/resources/foo/bar.xhtml
/META-INF/resources/foo/bar.js
Now the application resolves /foo/bar.xhtml just fine. But attempts to fetch /foo/bar.js simply fail with 404. I tried using
<h:outputScript library="modulename" name="foo/bar.js" />
as well as direct reference
<script language="text/javascript" src="/context/foo/bar.js"/>
both to no avail. I feel I am missing something. Can someone help me?
PS: using Apache Tomcat 6 and Eclipse-Juno for development.
I'll ignore the fact that the mentioned versions in your question in its current form is confusing. JSF 2.2 (as you tagged) requires a minimum of Servlet 3.0. Tomcat 6 (as you mentioned) is a Servlet 2.5 container (and a quite old one either). This is not going to work together. Also noted should be that the FaceletsResourceResolver which you found there is only necessary when you're using Servlet 2.5 or are using a very early JBoss AS 6 version.
The library name does here not represent the JAR file name, but the subfolder where all of those resources commonly belong to. So when you have a
<h:outputScript library="modulename" name="foo/bar.js" />
then the following structure is expected in the JAR:
/META-INF/resources/modulename
/META-INF/resources/modulename/foo
/META-INF/resources/modulename/foo/bar.xhtml
/META-INF/resources/modulename/foo/bar.js
Alternatively, you can keep your original structure and use
<h:outputScript library="foo" name="bar.js" />
depending on the meaning of the actual value of foo.
See also:
Packaging Facelets files (templates, includes, composites) in a JAR
Does anyone have the URL to the Mojara JSF 2 components API.
I seem to have lost it and cannot seem to find them via Oracle's site.
There's no such thing as "components API". Perhaps you meant the JSF 2 tag library documentation?
The JSF 2.x tag library documentations are available here:
JSF 2.0: http://docs.oracle.com/javaee/6/javaserverfaces/2.0/docs/pdldocs/facelets/
JSF 2.1: http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/
I'm currently upgrading an application from JSF 1.2 and Richfaces 3.3 to JSF 2 and Richfaces 4.
I'm having issues getting my application to include stylesheets using JSF2's new h:outputStylesheet component
Here is my old code:
<a4j:loadStyle src="resource:///com/testing/test/html/css/style.xcss" />
And here is what I have for my new code (Not working):
<h:outputStylesheet library="resource:///com/testing/test/html/css/" name="style.xcss" />
I've tried various variations but none have worked.
I get a message saying RES_NOT_FOUND when using firebugs css tab.
Any ideas?
Thanks
<h:outputStylesheet library="resource:///com/testing/test/html/css/" name="style.xcss" />
will not work for one reason - the library name is not the location of the resource, rather it is used to determine the location of the resource.
The manner in which the JSF runtime serves resources is detailed in the JSF 2.0 specification in chapter 2 titled "Request Processing Lifecyle". Resource handling is performed outside the confines of the usual Execute and Render lifecyle of JSF (that is used to service View requests). At runtime, a ResourceHandler associated with the Application is responsible for serving Resource requests.
The ResourceHandler uses a path based approach for looking up requests. The default implementation allows for resources to be placed in two locations:
In the Web-Application Root. Resources with identifier have to be placed in the /resources directory under the Web Application root, as /resources/<resourceIdentifier>.
In the Classpath. Resources with identifier must be present in the Classpath under the META-INF/resources directory, again as META-INF/resources/<resourceIdentifier>. In a web application, I've noticed that the directory should be the Web Application Root/WEB-INF/classes/META-INF/resources directory or a META-INF/resources directory under one of the directories in the parent classloader(s), or even in a JAR present in the Classpath. Apparently, the last option is the one undertaken by JSF 2 libraries/frameworks like PrimeFaces.
The JSF specification also specifies how the <resourceIdentifier> may consist of locales, library versions and resource versions, apart from the resource name itself. This is dealt with in a concise manner, in the ResourceHandler API documentation:
Packaging Resources
ResourceHandler defines a path based packaging convention for
resources. The default implementation of ResourceHandler must support
packaging resources in the classpath or in the web application root.
See section JSF.2.6.1 of the spec prose document linked in the
overview summary for the normative specification of packaging
resources.
Briefly, The default implementation must support packaging resources
in the web application root under the path
resources/<resourceIdentifier>
relative to the web app root.
For the default implementation, resources packaged in the classpath
must reside under the JAR entry name
META-INF/resources/<resourceIdentifier>
consists of several segments, specified as
follows.
[localePrefix/][libraryName/][libraryVersion/]resourceName[/resourceVersion]
None of the segments in the resourceIdentifier may be relative paths,
such as ‘../otherLibraryName’. The implementation is not required to
support the libraryVersion and resourceVersion segments for the JAR
packaging case.
Note that resourceName is the only required segment.
Going by the above, the following may work:
<h:outputStylesheet library="com/testing/test/html/css" name="style.xcss" />
provided that the stylesheet style.xcss is present in the directory structure com/testing/test/html/css located in either of the two areas mentioned above. Going by your need to place it outside the context root, the only possible option would be Web Application Root/WEB-INF/classes/META-INF/resources or any of the other suitable directory/JAR in the classpath (containing a META-INF/resources directory. This is of course, assuming that RichFaces does not provide it's own implementation of a ResourceHandler; if it does provide one, you should be looking at how it extends the default implementation to allow for resources to be placed elsewhere.
In Mojarra, the com.sun.faces.application.resource.ResourceHandlerImpl class extends the ResourceHandler class. ResourceHanderImpl uses the com.sun.faces.application.resource.ResourceManager class for finding resources. In turn, the ResourceManager delegates the loading of resources to the com.sun.faces.application.resource.WebappResourceHelper and com.sun.faces.application.resource.ClasspathResourceHelper classes. As their names imply, the former is responsible for looking up resources in the Web Application root, while the former is responsible for loading resources from the classpath. Going through these classes, one would find that failed attempts to load libraries get logged in the server's log; the RES_NOT_FOUND value is not generated by these classes, rather it is due to the renderer responsible for generating the page output.
I started web development using JSF, after studying JSP and Servlets for a while.
When you create a JSF web application you always(may be often but I am not sure if it always or not) have to create beans.xml and you don't write anything in it. But, if that file doesn't exist the JSF web app will not work.
What is the reason behind that?
Why we need that file?
Please, detailed explanation.
Adding to the answer of Micheal; CDI is not only useful in combination with JSF because of the injection support, but also because of its support to be used with EL (expression language). This is a feature JSF heavily depends upon.
In fact, CDI beans can almost entirely replace JSF managed beans and therefor you'll find lots of examples using them and a good amount of JSF books advising their use. For JSF applications CDI beans have e.g. the following advantages:
Can inject smaller scopes into larger scopes. E.g. request scoped GET parameters can be injected into a session scoped bean. This is not possible with JSF managed beans.
Can take advantage of the conversation scope; a scope that spawns multiple different pages.
Very unfortunate is that in JSF 2.0 and 2.1 the extremely handy view scope is not supported by CDI beans by default, although extensions like Seam can add these. (update: in JSF 2.2 there's a new view scope that does work with CDI beans)
All in all the confusion between JSF Managed beans and CDI beans is such that there's a JSF spec issue for this, see http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-976
The presence of a beans.xml file signals the servlet container that the application uses JSR-299 (Contexts and Dependency Injection) - without it, the application's classes will not be scanned for CDI annotations either and dependency injection will not be performed. If you don't use CDI (e.g. you only use plain JSF managed beans), you don't need beans.xml. If you do, you can use the file (instead of annotations) to define CDI configurations - this allows you, for example, to provide a test configuration where some dependencies are replaced with mocks.
From Getting Started with Contexts and Dependency Injection and JSF 2.x
When the application is deployed the server looks for CDI managed beans. In a Java EE 7 application, the classes on the path are scanned for CDI annotations by default. In a Java EE 6 application, the classes are scanned for CDI annotations if the module contains a beans.xml file.