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.
Related
I'm playing around the idea of a very huge vaadin application, which consists of a skeleton (providing the ui framework) and hundreds of functional units (providing the specific vaadin views).
The main architectural point is to let the skeleton be agnostic about the functional units, so not a single java dependency to a functional unit should be injected into skeleton. Every single functional unit has to be in it's own distinct JAR.
The vaadin container is started by the skeleton-module. It is perfectly possible to build a navigation with all the necessary routes to the functional units (/routeToView001.../routeToView999) without having further details about them.
However, I don't see, how the started vaadin spring boot container would load the java classes from the independent JARs when navigation occurs in browser. Practical attempts failed. Any ideas?
The Spring Boot integration is by default looking for #Route classes within the Java package that contains the #SpringBootApplication class. This can be further configured by passing package names to the #EnableVaadin annotation.
I haven't tested this in practice, but it might be possible to have a multiple #EnableVaadin annotations so that there would be one in each module and through that also provide multiple locations to look for #Route classes from. In that case, the #EnableVaadin class in each module would also have to register itself in the same way as any other #Configuration by using the regular Spring Boot autoconfiguration mechanism.
Another alternative is that you register route classes manually to the application's route registry (accessed using ApplicationRouteRegistry.getInstance(new VaadinServletContext(servletContext))). In that case, you might still need to have at least a dummy #Route in the base module since Vaadin might not automatically enable itself in a Spring Boot environment unless at least one #Route class is discovered in the regular way.
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
Is it possible to access non shared resources (web application resources XHTML / CSS ) from shared resource which is packaged as JAR file and placed inside WEB-INF/lib folder.
Eg.
App
--views
---layout
----template.xhtml
--WEB-INF
----lib
------jar1
--- ----META-INF
----------resource
------------views
--------------index.xhtml
In the above structure can index.xhtml reuse template.xhtml? I wanted to have application specific template rather than using it from shared template.
#Partlov,
As I mentioned earlier, Have solved by providing relative path starting from app context rather then from current folder.
In facelet tag declaration have used template=/views/layout/template.xhtml instead of template=layout/template.xhtml in WEB-INF/lib/jar1/Index.xhtml
#BalusC, Thanks for your note. I do agree your comment.
I am working on minifying js and css files in grails application. My original plan is to use the resources plugin to minify the resources (also had a look at jawr and performance-ui, but resources seems to be de facto standard these days).
Resources makes it easy to minify individual CSS files using YUI, but we have over 40 JS files, which we'd like to concatenate into a single file (and the files will need to be concatenated in the right order too) I haven't seen anything suggesting that Resources supports this out of the box, these are the approaches we have planned so far :
Add new grails taglib to concatenate the js and css files to create one js and one css file and minify using the resources plugin. A naive implementation will mean the yui-minify runs every time the page is served (!!) so we'd need to inytroduce caching somehow.
Use the BuildConfig 's grails.war.resources to minify the js and css. This would get round the caching issue, as the resource would only bebuilt and minified at build time, but will require us to use grails run-war to test locally, hence any minification-related errors won't get caught until later in the dev cycle.
This must be a fairly common problem. What are other people doing? Would like to hear about any other approaches or best practices I can use.
You can make all your resources using the same bundle, with this, you will have only one merged js. Example:
main {
resource id: 'mainjs', url: 'js/main.js'
defaultBundle: 'mybundle'
}
second {
resource id: 'secondjs', url: 'js/second.js'
defaultBundle: 'mybundle'
}
According to the docs:
The "bundle" mapper adds together resources of the same type to reduce
the number of files your client pages request.
The "bundle" mapper looks at the value of the "bundle" property on
resources and if found, will add the resource to a new synthetic
aggregated resource.
This aggregated resource is itself processed through mappers, so it is
subject to the other optimisations you apply to the kind of resource
the bundle is aggregating.
Bundles are always in the base directory of the static resources
folder - which means references to files inside the bundle must be
re-adjusted so they continue to refer to the same files. This is made
possible for CSS files by the csspreprocessor and cssrewriter mappers.
Does there exist a method when publishing an ASP.NET MVC application to completely remove the .aspx view files (and if possible .master too) by compiling them into the application DLL as resources?
The published application would just be the /bin folder, Global.asax and web.config, a default.aspx if needed, and whatever is in the /Content folder. All the views would be contained in the MyProject.dll file.
To clarify I don't mean where every .aspx is overwritten with a 1 line dummy file referencing the correct resource, but where those files can be eliminated entirely in the published app.
The goal here is to simply change management and all the auditing and layers of people surrounding it - one file gets deployed, that file replaces the existing file, and no messing around with a stack of .aspx files that have to be added/removed/updated (yes, SVN or a similar solution handle that problem instead, but management politics prevent this).
Is this what you are looking for?
It's possible with the web forms view engine but you'll have to extend the path provider yourself.
Here is a question here at SO about the same thing:
Using VirtualPathProvider to load ASP.NET MVC views from DLLs
If you use the Spark view engine, it already has additional path providers built in.
The documentation can be found here:
Adding a view folder to config
It allows you to locate your views inside a DLL as an embedded resource, somewhere else on the file system, using the default virtual directories, or plug in your own custom provider.