On Mon, 2006-01-16 at 11:50 -0800, John Fallows wrote:
> Sorry, I meant what is the purpose of having a core module at all?
> (not, why is it structured in this way)
>
> In other words, who is going to use this module. Why does it need to
> exist?
> I'll try to clarify.
I think what Sean's "core" is meant to be is simply an "assembly"
project, where myfaces-commons.jar, myfaces-api.jar and myfaces-impl.jar
get bundled into a myfaces.tar.gz or myfaces.zip file.
I don't quite know why this can't be done in the myfaces-impl.jar
project but I guess there's some technical maven reason.
I think this is a stylistic reason rather than a technical reason.
This is *not* like the old "share" module which contained java classes
that was then inserted into multiple jars; as you say that causes nasty
issues when the jars are deployed via different classloaders. The common
code now goes into "myfaces-commons.jar", which must be deployed *once
only* in the classpath.
There is a slight gotcha with the "myfaces-commons.jar" approach.
Imaging someone preparing a webapp using tomahawk that may be deployed
on a container that bundles Sun RI, or may be deployed on a container
that bundles myfaces-commons.jar and myfaces-api.jar. If they don't
bundle myfaces-commons.jar, then the app won't work on Sun RI. If they
do, then on the myfaces-based container they have duplicated
myfaces-commons.jar , and therefore (if child-first classloading is
selected) will get the ClassCastException problem. However it's not too
serious a problem and I can't see any better solution other than some of
the early complicated proposals that included automated renaming of all
the "commons" classes so they could be bundled with both impl and
tomahawk without conflict.
The problem has been repackaged, but the only difference between the old "share" module approach and this "commons" approach is that now you can choose which version of the overlapping code takes precedence.
Btw, what makes you say that this type of ClassCastException problem is "not too serious"?
When the application developer encounters this problem, what are his options?
a) upgrade the container version of myfaces-commons.jar and hope it is compatible with the runtime (assuming he is allowed do this)
b) remove myfaces-commons.jar from his webapp and hope the container version is compatible
c) switch to using the Sun RI
Anyway, my question was more along the lines of JSF 1.2, as I was wondering if the ClassLoaders could be arranged in the Application Server to avoid the two different versions of myfaces-commons.jar from colliding. I don't think that Web Applications (should?) have access to every class used by the implementation of the Application Server, right?
Kind Regards,
John Fallows.
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
