Bernhard Huemer schrieb:
Hi again,
Hope you have recovered and all is well.
Thanks, I'm fine at the moment. :-D
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.
Neither have I changed anything about Facelets, but somehow one has to
adapt its usage in an OSGi container, because it won't work without.
However, if I'm not mistaken you are using Facelets as a bundle since
you've repackaged it in order to add the necessary metadata, but
nevermind.
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.
Okay, that's something I've missed so far, however, as I've already
mentioned there is another problem. Even if Facelets uses the correct
bundle classloader it won't find any taglibs because of the resource
URL format. I don't know if this is standard OSGi behaviour or not,
but resources within an OSGi bundle start with "bundle://" instead of
"jar://" which Facelets doesn't recognize and hence doesn't parse (at
least that's the case for Apache Felix). That's what I've meant by
saying that those built-in components didn't work for me as Facelets
wasn't even able to parse its internal taglib files and so the HTML
output contained non-processed "<h:form>" tags and so on.
The schemes for bundle entry URLs are implementation dependent
according to the spec. For Equinox it's bundle:// as well and they
are loaded successfully in my setup.
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.
Let's clarify this, please. First of all I assume that there are
separate bundles for the MyFaces API, the MyFaces implementation and
your web application (Facelets, etc. doesn't matter in this case). The
MyFaces implementation bundle is responsible for instantiating the
beans, but which bundle classloader are you talking about then?
- The web application bundle classloader: During start-up the web
application bundle somehow initializes MyFaces and in the course of
this the web application somehow "injects" its own bundle classloader
to, among others, the managed bean facility so that it has got access
to the bean classes. However, if that would be the case, there's no
need to declare anything in the manifest file, hence I doubt that
you've chosen this approach. If I'm mistaken, please feel free to
correct me, then we can discuss this approach in more detail (Btw.
I've chosen this approach).
- The MyFaces implementation bundle classloader: The managed bean
facility, again amongst others, uses the bundle classloader of its own
bundle. In doing so it has got access only to the classes within the
implementation bundle - which doesn't help at all regarding managed
beans - and to packages being exported by other bundles. That would
explain your need for declaring bean packages properly in the manifest
file. However, again, if I'm not mistaken exporting packages is not
sufficient as MyFaces will have to import them as well. Are you
suggesting that web application developers have to "customize" the
MyFaces implementation bundle by adapting the imports every time they
create new managed beans?
I use fragment bundles to make my custom component libraries and
Facelets available to MyFaces. So there is no need to "customize"
the bundles. The same applies for the bundle containing your managed
beans and myfaces-impl bundle. It's always the bundle's class loader
that is used to load classes and resources.
- 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.
So, you don't use the OSGi HTTP service API [1] at all? Seems that
your OSGi environment is capable of parsing a web.xml file, which I
think isn't standard behaviour. However, I think it's acceptable if it
works for major OSGi containers (haven't tried Equinox and the Spring
DM tools yet).
Tomcat is registered as a HTTP service. The same applies for ready-made
Jetty bundles. Spring helps deploying a web app bundle to Tomcat.
PAX Web does the same for Jetty with support for filters etc.
Additionally it seems that you're more or less talking about the
deployment of a WAR file, i.e. the whole web application consists of a
single archive file with the only difference that you don't have to
embed the dependencies within it as OSGi is responsible for resolving
dependencies. However, I've intended to adapt MyFaces in a way so that
it's possible to split even the web application into separate bundles,
where each bundle is able to define its own JSF configuration file,
etc. In doing so, each bundle provides just a part of the resulting
web application, which means that you can reuse these parts in
different web applications. However, I'm not too sure if such a
feature is really required or if I've over-engineered the whole OSGi
support thingy a little bit.
Not sure wether that works how MyFaces is currently implemented. But it's
certainly possible to re-use services provided by other bundles in different
web applications.
- Felix
regards,
Bernhard
[1]: http://www.osgi.org/javadoc/r4v41/org/osgi/service/http/HttpService.html
Am 10. Juli 2009 03:20 schrieb Felix Röthenbacher <[email protected]>:
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
