On Mon, 2006-01-16 at 17:42 -0800, John Fallows wrote: > 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.
No, you can ensure that just one myfaces-commons.jar file is deployed, thus eliminating the duplication. > > Btw, what makes you say that this type of ClassCastException problem > is "not too serious"? The exception is serious. But fixing it is reasonably simple: delete one of the copies of myfaces-commons.jar. This may require unpacking the war file you're trying to deploy which is a nuisance but not impossible. > > 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 Yep. Better solutions would be very welcome I'm sure. However one that involves having dozens classes in both the impl and tomahawk trees, identical except for the package name, is probably not going to be accepted due to the maintenance issues. According to a quick count, myfaces-commons contains 87 classes. Not something I'd be fond of maintaining two copies of. > 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? I agree completely on this. I think servlet containers have got this horribly wrong, and that they should ensure that the only thing visible to deployed webapps are the official APIs defined in the servlet spec. And that there should be *no* "shared lib" mechanism whatsoever; if a webapp wants library X then it should deploy that library locally rather than in a shared location. Alternately, a system where containers provided "shared-api" and "shared-impl" directories would be at least an improvement; myfaces-api could go in the shared-api directory and be visible while myfaces-commons and myfaces-impl could go in the shared-impl and not be accessable from webapps. >From experience, however, very few people agree with me. And it's simply not going to happen. So for now we're stuck with trying to find a way of packaging myfaces code to avoid the worst of the classloader-related problems while not duplicating code between impl and tomahawk. Again, I'm sure improvements on the current solution would be very welcome indeed. Regards, Simon
