Support Servlet 3.0 and 2.5 in the same plugin

[Francis Mckenzie]

Hi,

Would like some advice. For the gsp-resources plugin, I've created a class similar to grails.gsp.PageRenderer, to do the background compilation of GSPs (i.e. outside a real request/response).

The class creates a spoofed HttpServletRequest object - i.e. a class that implements all methods in the HttpServletRequest interface. Problem is, the set of methods in HttpServletRequest changes depending if the project is using Servlet 3.0 vs 2.5.

So in my plugin, if I implement my spoofed HttpServletRequest conforming to Servlet 2.5, then any user installing the plugin will see "missing method" compile errors if they're using Servlet 3.0. Likewise, if I implement all the Servlet 3.0 methods, any user installing the plugin will see "javax.servlet.AsyncContext class not found" compile errors if they're using Servlet 2.5.

I've got a workaround which is to dynamically create the HttpServletRequest class from a groovy String on the fly - i.e. it first checks the user's Servlet version, then parses the appropriate string script of the class. But this feels a bit like a hack. Are there any better options?

Cheers,

Francis

[Graeme Rocher-4]

You could build the class in a separate jar that your project depends
on. You can build against 3.0 and run with 2.5



On Fri, Mar 23, 2012 at 3:02 PM, Francis Mckenzie
<[hidden email]> wrote:

> Hi,
>
> Would like some advice. For the gsp-resources plugin, I've created a class
> similar to grails.gsp.PageRenderer, to do the background compilation of GSPs
> (i.e. outside a real request/response).
>
> The class creates a spoofed HttpServletRequest object - i.e. a class that
> implements all methods in the HttpServletRequest interface. Problem is, the
> set of methods in HttpServletRequest changes depending if the project is
> using Servlet 3.0 vs 2.5.
>
> So in my plugin, if I implement my spoofed HttpServletRequest conforming to
> Servlet 2.5, then any user installing the plugin will see "missing method"
> compile errors if they're using Servlet 3.0. Likewise, if I implement all
> the Servlet 3.0 methods, any user installing the plugin will see
> "javax.servlet.AsyncContext class not found" compile errors if they're using
> Servlet 2.5.
>
> I've got a workaround which is to dynamically create the HttpServletRequest
> class from a groovy String on the fly - i.e. it first checks the user's
> Servlet version, then parses the appropriate string script of the class. But
> this feels a bit like a hack. Are there any better options?
>
> Cheers,
>
> Francis

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Francis Mckenzie]

Hi,

Thanks Graeme, was considering that type of thing too. But didn't realise I could include a jar containing a 3.0 HttpServletRequest, in a 2.5 container - hopefully that works, I'll give it a try!

Cheers,

Francis

On 23 March 2012 16:03, Graeme Rocher <[hidden email]> wrote:

You could build the class in a separate jar that your project depends
on. You can build against 3.0 and run with 2.5

On Fri, Mar 23, 2012 at 3:02 PM, Francis Mckenzie
<[hidden email]> wrote:
> Hi,
>
> Would like some advice. For the gsp-resources plugin, I've created a class
> similar to grails.gsp.PageRenderer, to do the background compilation of GSPs
> (i.e. outside a real request/response).
>
> The class creates a spoofed HttpServletRequest object - i.e. a class that
> implements all methods in the HttpServletRequest interface. Problem is, the
> set of methods in HttpServletRequest changes depending if the project is
> using Servlet 3.0 vs 2.5.
>
> So in my plugin, if I implement my spoofed HttpServletRequest conforming to
> Servlet 2.5, then any user installing the plugin will see "missing method"
> compile errors if they're using Servlet 3.0. Likewise, if I implement all
> the Servlet 3.0 methods, any user installing the plugin will see
> "javax.servlet.AsyncContext class not found" compile errors if they're using
> Servlet 2.5.
>
> I've got a workaround which is to dynamically create the HttpServletRequest
> class from a groovy String on the fly - i.e. it first checks the user's
> Servlet version, then parses the appropriate string script of the class. But
> this feels a bit like a hack. Are there any better options?
>
> Cheers,
>
> Francis

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[burtbeckwith]

You could create a JDK proxy if you only need to implement a subset of the methods, and it would implement whatever version of the interface is currently loaded. See DummyRequestCreator and DummyResponseCreator here for an example: https://github.com/grails-plugins/grails-spring-security-core/blob/master/src/java/org/codehaus/groovy/grails/plugins/springsecurity/GrailsWebInvocationPrivilegeEvaluator.java

Burt

On Friday, March 23, 2012 03:02:21 PM Francis Mckenzie wrote:

> Hi,
>
> Would like some advice. For the gsp-resources plugin, I've created a class
> similar to grails.gsp.PageRenderer, to do the background compilation of
> GSPs (i.e. outside a real request/response).
>
> The class creates a spoofed HttpServletRequest object - i.e. a class that
> implements all methods in the HttpServletRequest interface. Problem is, the
> set of methods in HttpServletRequest changes depending if the project is
> using Servlet 3.0 vs 2.5.
>
> So in my plugin, if I implement my spoofed HttpServletRequest conforming to
> Servlet 2.5, then any user installing the plugin will see "missing method"
> compile errors if they're using Servlet 3.0. Likewise, if I implement all
> the Servlet 3.0 methods, any user installing the plugin will see
> "javax.servlet.AsyncContext class not found" compile errors if they're
> using Servlet 2.5.
>
> I've got a workaround which is to dynamically create the HttpServletRequest
> class from a groovy String on the fly - i.e. it first checks the user's
> Servlet version, then parses the appropriate string script of the class.
> But this feels a bit like a hack. Are there any better options?
>
> Cheers,
>
> Francis

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Francis Mckenzie]

Hi Burt,

Thanks very much - that's a really interesting method, I'll definitely use that in future!

Cheers,

Francis

On 24 March 2012 00:06, Burt Beckwith <[hidden email]> wrote:

You could create a JDK proxy if you only need to implement a subset of the methods, and it would implement whatever version of the interface is currently loaded. See DummyRequestCreator and DummyResponseCreator here for an example: https://github.com/grails-plugins/grails-spring-security-core/blob/master/src/java/org/codehaus/groovy/grails/plugins/springsecurity/GrailsWebInvocationPrivilegeEvaluator.java

Burt

On Friday, March 23, 2012 03:02:21 PM Francis Mckenzie wrote:
> Hi,
>
> Would like some advice. For the gsp-resources plugin, I've created a class
> similar to grails.gsp.PageRenderer, to do the background compilation of
> GSPs (i.e. outside a real request/response).
>
> The class creates a spoofed HttpServletRequest object - i.e. a class that
> implements all methods in the HttpServletRequest interface. Problem is, the
> set of methods in HttpServletRequest changes depending if the project is
> using Servlet 3.0 vs 2.5.
>
> So in my plugin, if I implement my spoofed HttpServletRequest conforming to
> Servlet 2.5, then any user installing the plugin will see "missing method"
> compile errors if they're using Servlet 3.0. Likewise, if I implement all
> the Servlet 3.0 methods, any user installing the plugin will see
> "javax.servlet.AsyncContext class not found" compile errors if they're
> using Servlet 2.5.
>
> I've got a workaround which is to dynamically create the HttpServletRequest
> class from a groovy String on the fly - i.e. it first checks the user's
> Servlet version, then parses the appropriate string script of the class.
> But this feels a bit like a hack. Are there any better options?
>
> Cheers,
>
> Francis

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email