On 8/16/06, Joe Shevland <[EMAIL PROTECTED]> wrote:
Hi,
Sorry if this has been discussed but I haven't found a huge amount of
discussion on it, just a few comments describing that it was an
important and necessary change. Some time around Shale 1.0.3 changes
were introduced which meant you needed to deploy to a Servlet API 2.4
compliant container. This has left us in the difficult position of
either ripping out Shale or sticking with an increasingly dated version,
as unfortunately we're stuck with a 2.3 servlet container.
Since 1.0.2 there's already been a few patches we've needed, and I
suspect that'll increase as its given more of a workout (certainly the
validation area has needed a few backported patches, the JSF
filter/controller aspect is working fine). Where I'm heading with this
is has anyone tried any workarounds to get the latest release to deploy
under a Servlet 2.3 environment? Or are the changes fundamental in
nature... I was hoping someone had just packaged up a few of the
required javax.servlet classes into a minijar and voila. I'm guessing
not given the classes in question and the need for container support,
but thought I'd ask the question. Or I was going to ask whether its
feasible to implement the functionality provided by the 2.4 spec in a
different fashion, if the changes are fairly localized, we would happily
take the time to do that too if theres an indication its possible.
Cheers
Joe
The dependency that would be the hardest to try to work around is the use of a ServletRequestListener to fire init/destroy events for view controllers and related beans. This API did not exist in Servlet 2.3, although it *might* theoretically be possible ot use a Filter to do some of this stuff.
The other dependency, which I can't see any way around, is if you are using the application controller filter, and you want that to apply to RequestDispatcher.forward calls as well -- there's no way to emulate this technique in 2.3. But it's not necessarily something that would affect all users of Shale, the way the first issue is.
One of the hard parts about designing frameworks is deciding how to balance between supporting old APIs (to deal with users like you who are stuck and can't change) versus focus on enabling the use of new things. J2EE 1.4 (which includes Servlet 2.4) has been around for a couple of years now, and it would make building Shale a *lot* more complicated (plus limit what we can do) to support older revs, when the opportunities to improve ease of use through leveraging new APIs are there, and have been there for quite a while.
I really sympathize with your position, but I think Shale needs to maintain it's base platform dependencies including Servlet 2.4 in order to address the current and future needs.
Craig
