On Thu, 30 Dec 2004 18:54:41 +0100, Alessandro Polverini
<[EMAIL PROTECTED]> wrote:
> I've read and understood the documents Martin Cooper in another mail
> pointed me at (thanks), anyway, this is what I read on the JSF specs,
> paragraph 10.2.5 and 10.2.6:
>
> "These classes and resources comprise the implementation of the JSF APIs
> that is provided by a JSF implementor. Typically, such classes will be
> provided in the form of one or more JAR files, which can be either
> installed with the container s shared class facility, or included in
> the /WEB-INF/lib directory of a web application archive."
>
> So, if I'm not mistaken, the specs explicitly says that those jar can be
> shared among all applications.
>
The spec does indeed *allow* for a JSF implementation to be shared in
such a manner, placing it in a shared parent class loader. This will
be important, for example, in the J2EE 5.0 platform, of which JSF 1.1
will be a required part (so applications will be able to assume that
it's built in, just like the servlet and JSP APIs are).
What the spec does not cover (because it's an implementation issue) is
that the *implementation* is responsible for making itself actually
work when it is deployed in such a way. The most common issue is
where the framework needs to instantiate an object of some class (such
as a UIComponent) that is provided by the application. You need to
load the class from the *application* class loader, rather than the
class loader that loaded your framework, in order for these classes to
be accessible.
Fortunately, the server provides you convenient access to the webapp's
class loader, so you can do things like this:
String className = ...; // Name of some application provided class
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Class clazz = cl.loadClass(className);
UIComponent component = (UIComponent) clazz.newInstance();
But the framework (in this cases, the MyFaces implementation of JSF)
must be specifically programmed to do this kind of thing.
Craig
