| serlvet bridge HTTP service and supported methods [message #66046] |
Wed, 03 May 2006 15:15  |
Eclipse User |
|
|
|
Hi,
trying to use the HTTP bundle and the servlet bridge in order to deploy
a Wicket servlet in Tomcat, it seems that servlet.getServletName() is
not supported.
How is the strategy on supporting later servlet API's for the time
being? I'm not able to change the Wicket code according to Simons
recommendations on not using these things as it is central in there.
/peter
--
|
|
|
|
|
|
|
|
| Re: serlvet bridge HTTP service and supported methods [message #67740 is a reply to message #66127] |
Fri, 19 May 2006 13:52  |
| Eclipse User |
|
|
|
Originally posted by: simon.kaegi.cognos.com
Update on supported methods.
--
I've added ServletContext.getResourcePaths(...) support in
"org.eclipse.equinox.servlet.bridge.http". (e.g. adds support for embedded
jetty and the regular servlet bridge). Previously this method always
returned null.
Keep in mind that the OSGi HttpService currently does not provide direct
support for this method. (Perhaps this is because it was specified in the
Servlet 2.1 timeframe and this method was added for 2.3(?))
The OSGi HttpContext interface does have a getResource(...) method and
advises that ServletContext.getResource(...) and
ServletContext.getResourceStream(...) should be supported by using it.
To support "getResourcePaths(...) this implementation uses reflection to
check for and then call the associated HttpContext.getResourcePaths(...)
method opportunistically. As before null is returned if the method is not
present or fails.
--
Further Note:
The OSGi HttpService specifies that the "Default Http Context" should use
Bundle.getResource(...) as the implementation for
HttpContext.getResource(...). Bundle.getResource(...) uses the bundle's
classloader to support the call and makes it very difficult to support
"getResourcePaths(...) in a consistent manner. Subsequently, the "Default
Http Context" as implemented "does not" support
ServletContext.getResourcePaths(...) and will simply return null.
R4 added Bundle.getEntry(...) and Bundle.getEntryPaths(...) which will only
search the immediate bundle however are frequently all that's really needed
and also allow consistent support for a getResourcePaths(...) method. The
HttpContext implementations for "org.eclipse.equinox.http.registry" uses
this approach (and as a result support getResourcePaths(...)).
If you're registering Servlets and Resources manually here's an example that
you can use or customize.
--
public class EntryBasedHttpContext implements HttpContext {
private Bundle bundle;
private HttpContext delegate;
public EntryBasedHttpContext(Bundle bundle, HttpService httpService) {
this.bundle = bundle;
delegate = httpService.createDefaultHttpContext();
}
public String getMimeType(String arg0) {
return delegate.getMimeType(arg0);
}
public boolean handleSecurity(HttpServletRequest arg0, HttpServletResponse
arg1) throws IOException {
return delegate.handleSecurity(arg0, arg1);
}
public URL getResource(String resourceName) {
return bundle.getEntry(resourceName);
}
public Set getResourcePaths(String path) {
Enumeration entryPaths = bundle.getEntryPaths(path);
if (entryPaths == null)
return null;
Set result = new HashSet();
while (entryPaths.hasMoreElements())
result.add(entryPaths.nextElement());
return result;
}
}
--
I'll eventually put this up on the website or perhaps the Wiki.
-Simon
"Simon Kaegi" <skaegi@sympatico.ca> wrote in message
news:e3bs2s$prl$1@utils.eclipse.org...
> Hi Peter,
>
> I'm definitely ok with being pragmatic in the servlet bridge in terms of
> providing support for later versions of the Servlet API in some manner.
>
> --
> getServletName() support can be added easily enough through a specially
> named init parameter.
> getNamedDispatcher(...) can then also be added although it's a bit more
> work.
> getResourcesPaths() I think I've mentioned I'd like to support perhaps
> using
> reflection to make the call when the relevant HttpContext has an
> implementation of the method.
>
> Would adding a useful implementation for these methods cover your
> requirements?
> Are there any other parts of the servlet API that you'll need to complete
> your integration?
> --
>
> In terms of strategy I think we can look to more fully support the methods
> on existing parts of the Servlet API exposed in the Http Service. That
> said,
> I am a little wary of new objects. I think we can experiment with adding
> Filter and Listener support in the incubator however at some point I
> suspect
> a new spec is required.
>
> -Simon
>
> "Peter Neubauer" <peter@neubauer.se> wrote in message
> news:e3avhe$3sr$2@utils.eclipse.org...
>>
>> Hi,
>> trying to use the HTTP bundle and the servlet bridge in order to deploy
>> a Wicket servlet in Tomcat, it seems that servlet.getServletName() is
>> not supported.
>> How is the strategy on supporting later servlet API's for the time
>> being? I'm not able to change the Wicket code according to Simons
>> recommendations on not using these things as it is central in there.
>> /peter
>>
>> --
>>
>>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.04270 seconds
Home