Bernhard Huemer schrieb:
Hi,
as I've announced something similar a few weeks ago (due to a disease,
however, I didn't have the time to contribute these changes yet), I'm
wondering how you implemented that with "some modifications"?
Hope you have recovered and all is well.
For example, Facelets built-in components (<h:form>, ...) didn't work
for me as Facelets doesn't know how to parse bundles. Of course, a
bundle is basically just a plain JAR file, but the resource URL of
those JAR files start with "bundle://" instead of "jar://" or
something similar which Facelets doesn't recognize properly, hence it
won't the taglibs. Additionally the default Facelets view resource
loader assumes that the views can be accessed using the
ExternalContext (i.e. it's assuming that it's deployed within a proper
WAR file, which isn't the case). Therefore I had to implement a custom
Facelets resource loader as well.
Here you are talking about using Facelets as a bundle, which is another story.
My mail referred to modifications to MyFaces Core and Trinidad.
My expression "some modifications" is related to MyFaces Core and Trinidad,
not Facelets.
I'm not sure what you mean with h:form is a built-in Facelets component?
I assume that you mean Facelets needs a way to parse taglibs from
other bundles like Myfaces Core and Trinidad. Just a short summary
of the way I deal with Facelets. First, I didn't find a bundled version
for Facelets version 1.1.14. So I re-package it myself adding the necessary
metadata.
Facelets uses the ContextClassLoader quite often. Luckily, there are
well defined entry points into the Facelets bundle which is the
FaceletViewHandler. I wrote a wrapper for FaceletViewHandler which sets
the ContextClassLoader of the current thread to an appropriate bundle
classloader. Hence, resources are loaded through this bundle classloader.
How do you know which bundle to use for class loading when parsing an
expression string like "#{bean.propery}", where bean is a managed
bean? Don't you map beans to bundles somehow? At least I assume that
you don't based on the statement that the class loading problem
requires just some "small modifications to ClassUtil".
Class loading for beans is done through the bundle classloader. If
you declare your bean packages properly in your MANIFEST.MF this
class loader will find it.
Additionally I've struggled with the dependencies of MyFaces as well,
for example, all those common-* projects, as they don't provide bundle
information within their manifest files and hence aren't recognized by
the OSGi container. However, somehow these classes have to be
accessible and therefore I have created another Maven plugin that
embeds these dependencies if the developer wants to create a OSGi
compatible MyFaces build. Basically it just creates a folder called
"/META-INF/lib/" similar to "/WEB-INF/lib/" and uses the manifest file
statement "Bundle-ClassPath" to load those libraries.
...
I use bundled versions of these libraries rather than embedding them
in my war bundle. You can find these bundles in various bundle repositories.
Don't get me wrong, if you really just require a few changes, then
feel free to contribute them, but I doubt that those changes are
sufficient. However, in order to ensure that we're not talking at
cross-purposes, please describe your execution environment a little
bit more. It seems that you're using Equinox, does Equinox provide an
OSGi HTTP service implementation on it's own? How does deployment
work, i.e does the OSGi HTTP service implementation know how to parse
a web.xml file, or do you have to register the FacesServlet
programmatically somehow?
Your question seems to be geared towards how to setup and run a working
OSGi environment. Despite this is probably not the right mailing list
just a few hints:
- Equinox as OSGi container
- HTTP service is provided by Tomcat. Could also be Jetty but
I didn't manage to setup a working environment in combination
with JSP (though PAX web apparently provides one).
- I use Spring DM tools for WAR deployment. A similar solution
exists from PAX Web for Jetty.
Actually, from my own experience, setting up a running OSGi environment
for your needs can be quite tricky and cumbersome.
- Felix
regards,
Bernhard
Am 9. Juli 2009 06:22 schrieb Felix Röthenbacher <[email protected]>:
Hi
I recently made some modifications to MyFaces Core and MyFaces Trinidad
to get it running in an OSGi container (Equinox) together with Facelets.
I wonder if there is any interest in adding bundle metadata to MyFaces
Core and Trinidad to make them runnable in an OSGi environment? If so,
I could finalize my modifications and submit a patch with the necessary
changes.
Basically, the changes include:
- adding bundle information in MANIFEST.MF (uses Maven bundle plugin)
- assure that classes and resources are loaded with proper class loaders
The changes to MyFaces core are minor, e.g. adding a bundle activator
and small modifications to ClassUtil for class loading.
Modifications to Trinidad comprise a systematic use of ClassLoaderUtils to
load classes and resources. Currently, often
Thread.currentThread.getContextClassLoader() is used directly, which doesn't
work well in an OSGi environment.
WDYT?
- Felix
