|
|
|
Re: Resource loading with HttpService [message #553611 is a reply to message #553593] |
Wed, 18 August 2010 08:14 |
|
Am 18.08.2010 09:04, schrieb Bob:
> I found out that the resource mapping is not resolved when using
> ServletContext#getResource. Nevertheless it is done when calling the
> resource via Browser URL by
> org.eclipse.equinox.http.servlet.internal.HttpServiceServlet .
When doing #registerResource you make a resource available to the
HttpService for accessing it via URLs. There is nothing in the spec that
implies that those mappings also work with ServletContext#getResource.
You need to implement your own HttpContext in order to allow such a
mapping facility.
> Even when I create a custom HttpContext I cannot properly resolve the
> mapping since both cases are handled by HttpContext in the end and it
> is not possible to determine whether to resolve the mapping or not.
What you mean by both cases? I think you are mixing resource
registrations with context mappings.
That's what you have:
> + Root
> +--+ bin
> +--+ META-INF
> +--+ resources
> +--+ WebContent
> +-- index.html
That's what you want:
> I want to get load resources by calling:
> servletContext.getResource("/index.html");
In order to do that you need to implement your own HttpContext which
knows that resources should be looked up from "/resource/WebContent".
If you also want to make stuff from "/resource/WebContent" public
available so that it can be accessed via "http://myhost/index.html" you
need to call registerResource the following way:
httpService.registerResource("/", "", theImplementedHttpContext);
Alternatively, you could also call:
httpService.registerResource("/", "/resource/WebContent", null);
This will create a default context that looks up resources from your
bundle. However, the context is just a default with no special mapping
logic.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
|
|
|
Re: Resource loading with HttpService [message #553937 is a reply to message #553926] |
Thu, 19 August 2010 13:17 |
|
Am 19.08.2010 14:44, schrieb Bob:
> This would mean the custom HttpContext has to know about the resource name.
Yes. That's the reason you have a _custom_ HttpContext (the other one
being security). Otherwise you would simply be happy with the mapping
and use the default one.
> What should the resource name be good for when it is not resolved correctly by default context and can you need to write your own context which takes care of the resource name instead?
This is what the JavaDoc says:
For example, suppose the resource name /tmp is registered to the alias
/files. A request for /files/foo.txt will map to the resource name
/tmp/foo.txt.
And this is exactly how it's implemented. The JavaDoc does not say
anything about the mapping being applied to "ServletContext" as well.
"registerResources" works for HTTP access only.
What you want is your own extensible HttpContext. You register your
servlets using this context and you register your resources with this
context as well. The extension registry version of the Equinox
HttpService does something like that.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
|
Re: Resource loading with HttpService [message #554030 is a reply to message #554001] |
Thu, 19 August 2010 18:17 |
|
Am 19.08.2010 17:59, schrieb Bob:
> Last try to convince you ;)
;)
> So I expect the default context to behave as defined in the Servlet spec without writing my own HttpContext.
The thing is that HttpContext != ServletContext. At least, I'm not aware
that the OSGi HttpService spec implies any guarantees on ServletContext
& Co. To my knowledge this was always something left to the container.
Another examples would be welcome files. The servlet spec talks about
them but not the OSGi HttpService. It really was not designed as a full
Servlet spec replacement.
FWIW, I also put some effort into writing my own stuff to compensate
such limitations. Another thing is, that everything registered with
HttpServices shares the same HttpSession. That might be ok if you end up
deploying your stuff as a WAR using the servlet bridge. However, it's
definitely not acceptable when running with different bundles in a
shared system.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05698 seconds