Hi again Achim,
I'm not exactly sure how you mean. The way I register my resources is via
the WebContainer (which I get with iPojo) as follows:
private HttpContext mHttpContext;
@Requires
private WebContainer mWebService;
...
mHttpContext = mWebService.createDefaultHttpContext();
mWebService.registerResources("/", "/webroot", mHttpContext);
The above will get me the double slash problem. If I instead do:
mWebService.registerResources("", "/webroot", mHttpContext);
Then I get:
Caused by: java.lang.IllegalArgumentException: Alias does not start with
slash (/)
at
org.ops4j.pax.web.service.spi.model.ServletModel.validateAlias(ServletModel.java:169)
at
org.ops4j.pax.web.service.spi.model.ServletModel.<init>(ServletModel.java:53)
at
org.ops4j.pax.web.service.spi.model.ResourceModel.<init>(ResourceModel.java:29)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerResources(HttpServiceStarted.java:262)
at
org.ops4j.pax.web.service.internal.HttpServiceProxy.registerResources(HttpServiceProxy.java:71)
at
org.ops4j.pax.web.service.WebContainer$$Proxy.registerResources(Unknown
Source)
at se.digia.hp.web.HpWebService.__M_init(HpWebService.java:134)
at se.digia.hp.web.HpWebService.init(HpWebService.java)
at se.digia.hp.web.HpWebService.__M_starting(HpWebService.java:47)
at se.digia.hp.web.HpWebService.starting(HpWebService.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.8.0_74]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_74]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_74]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_74]
at
org.apache.felix.ipojo.util.Callback.call(Callback.java:237)[50:org.apache.felix.ipojo:1.12.1]
at
org.apache.felix.ipojo.util.Callback.call(Callback.java:193)[50:org.apache.felix.ipojo:1.12.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)[50:org.apache.felix.ipojo:1.12.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:162)[50:org.apache.felix.i
pojo:1.12.1]
Specifying null does not work either. If I do
mWebService.registerResources(null, "/webroot", mHttpContext);
Then I get:
Caused by: java.lang.IllegalArgumentException: Alias does not start with
slash (/)
at
org.ops4j.pax.web.service.spi.model.ServletModel.validateAlias(ServletModel.java:169)
at
org.ops4j.pax.web.service.spi.model.ServletModel.<init>(ServletModel.java:53)
at
org.ops4j.pax.web.service.spi.model.ResourceModel.<init>(ResourceModel.java:29)
at
org.ops4j.pax.web.service.internal.HttpServiceStarted.registerResources(HttpServiceStarted.java:262)
at
org.ops4j.pax.web.service.internal.HttpServiceProxy.registerResources(HttpServiceProxy.java:71)
at
org.ops4j.pax.web.service.WebContainer$$Proxy.registerResources(Unknown
Source)
at se.digia.hp.web.HpWebService.__M_init(HpWebService.java:134)
at se.digia.hp.web.HpWebService.init(HpWebService.java)
at se.digia.hp.web.HpWebService.__M_starting(HpWebService.java:47)
at se.digia.hp.web.HpWebService.starting(HpWebService.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.8.0_74]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_74]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_74]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_74]
at
org.apache.felix.ipojo.util.Callback.call(Callback.java:237)[50:org.apache.felix.ipojo:1.12.1]
at
org.apache.felix.ipojo.util.Callback.call(Callback.java:193)[50:org.apache.felix.ipojo:1.12.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.call(LifecycleCallback.java:86)[50:org.apache.felix.ipojo:1.12.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:162)[50:org.apache.felix.i
pojo:1.12.1]
It looks like the code you are referring to registers a Servlet which I do
not do directly for these resources (although Pax-Web ResourceServlet is
probably used under the hood).
Perhaps I'd better give you the overall picture...
I have a web application consisting of html/javascript/css files. These are
included in my app and will reside in my bundle. They are located in my
bundle directory "\webroot". I want "\webroot" to correspond to the root
("\") context path.
I also have a couple of Servlets providing services for my javascript files:
- One using the context path "\api" that provides general services.
- One using the context path "\admin\login" for logging in. Shiro is
automatically implementing "\admin\logout" since I specify in my shiro.ini
that this should be the logout page.
In addition to the above, I need to externalize some of my resources to a
normal directory in the file system. My web application uses different
logos for the different clients and they can upload their logos on their
own so they cannot be a static part of the web application.
So I need something like this:
a) The bundle's "\webroot" mapped to "\"
b) Servlet mapped to "\api"
c) Serlvet mapped to "\admin\login" (and "\admin\logout" via Shiro)
d) Normal directory mapped to "\logo".
I can get the individual pieces working but not together. If I put
everything under "\hp" instead of under "\" then it works fine but that
context part is not acceptable. I need to put it under "\" since there are
existing URL's on the public site that must remain as today.
Might sound a bit complicated but I don't think it's an unusual setup.
/Bengt
2016-11-07 20:09 GMT+01:00 'Achim Nierbeck' via OPS4J <
[email protected]>:
> Hi Bengt,
>
> regarding issue #1 ... could you try to do something as "documented" in
> this[1] integration test?
> If you abandon the first parameter, with only the alias, it's always bound
> to the root "/".
>
> regarding issue#2 ... I'm not sure yet, but might be solved with #1 done
> right ;)
>
> regards, Achim
>
> [1] - https://github.com/ops4j/org.ops4j.pax.web/blob/master/
> pax-web-itest/pax-web-itest-container/pax-web-itest-
> container-jetty/src/test/java/org/ops4j/pax/web/itest/jetty/
> RootAliasIntegrationTest.java
>
>
> 2016-11-07 17:40 GMT+01:00 Bengt Rodehav <[email protected]>:
>
>> I'm using Pax-Web in Karaf 4.0.7.
>>
>> I have two problems with aliases:
>>
>> *Problem #1*
>>
>> If I register resources for the context path "/" (i e the root) as
>> follows:
>>
>> mWebService.registerResources("/", "/webroot", mHttpContext);
>>
>> Then my application is reachable at:
>>
>> http://localhost:8183//admin/login
>>
>> but not at:
>>
>> http://localhost:8183/admin/login
>>
>> I want to get rid of the double slash. However if I try this instead:
>>
>> mWebService.registerResources("", "/webroot", mHttpContext);
>>
>> Then I get:
>>
>> Caused by: java.lang.IllegalArgumentException: Alias does not start with
>> slash (/)
>> at org.ops4j.pax.web.service.spi.model.ServletModel.validateAli
>> as(ServletModel.java:169)
>> at org.ops4j.pax.web.service.spi.model.ServletModel.<init>(Serv
>> letModel.java:53)
>> at org.ops4j.pax.web.service.spi.model.ResourceModel.<init>(Res
>> ourceModel.java:29)
>> at org.ops4j.pax.web.service.internal.HttpServiceStarted.regist
>> erResources(HttpServiceStarted.java:262)
>> at org.ops4j.pax.web.service.internal.HttpServiceProxy.register
>> Resources(HttpServiceProxy.java:71)
>> at
>> org.ops4j.pax.web.service.WebContainer$$Proxy.registerResources(Unknown
>> Source)
>> at se.digia.hp.web.HpWebService.__M_init(HpWebService.java:133)
>> at se.digia.hp.web.HpWebService.init(HpWebService.java)
>> at se.digia.hp.web.HpWebService.__M_starting(HpWebService.java:
>> 47)
>> at se.digia.hp.web.HpWebService.starting(HpWebService.java)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)[:1.8.0_74]
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)[:1.8.0_74]
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)[:1.8.0_74]
>> at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_74]
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:237)
>> [50:org.apache.felix.ipojo:1.12.1]
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:193)
>> [50:org.apache.felix.ipojo:1.12.1]
>> at org.apache.felix.ipojo.handlers.lifecycle.callback.Lifecycle
>> Callback.call(LifecycleCallback.java:86)[50:org.apache.
>> felix.ipojo:1.12.1]
>> at org.apache.felix.ipojo.handlers.lifecycle.callback.Lifecycle
>> CallbackHandler.__M_stateChanged(LifecycleCallbackHandler.
>> java:162)[50:org.apache.felix.i
>> pojo:1.12.1]
>>
>> How can I get rid of the "double slash"?
>>
>> *Problem #2*
>>
>> Assume that my web application resides at the context url:
>>
>> http://localhost:8183/hp
>>
>> I also register a separate resource directory directly in jetty with the
>> following configuration (as I was helped by Achim on this forum):
>>
>> <?xml version="1.0"?>
>> <!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "
>> http://www.eclipse.org/jetty/configure_9_0.dtd";>
>>
>> <Configure id="Server" class="org.eclipse.jetty.server.Server">
>> <Get name="handler">
>> <Call name="addHandler">
>> <Arg>
>> <New class="org.eclipse.jetty.server.handler.ContextHandler">
>> <Set name="contextPath">/logo</Set>
>> <Set name="handler">
>> <New class="org.eclipse.jetty.serve
>> r.handler.ResourceHandler">
>> <Set name="resourceBase">../../common/etc/logo</Set>
>> <Set name="directoriesListed">true</Set>
>> </New>
>> </Set>
>> </New>
>> </Arg>
>> </Call>
>> </Get>
>> </Configure>
>>
>> This works fine. But when I try to move the application up to the root
>> (which has the double slash problem as described in Problem #1) to the
>> following url:
>>
>> http://localhost:8183//
>>
>> Then the separate resource via my jetty.xml does not work. It seems that
>> it cannot be a descendant of the context path I use for my web application.
>> But, since this is a public web application, with a predetermined url, it
>> must reside at the root. Then there is no context path that works for my
>> separate resource directory since all paths are descendants of root.
>>
>> This seems a bit weird...
>>
>> /Bengt
>>
>>
>>
>> --
>> --
>> ------------------
>> OPS4J - http://www.ops4j.org - [email protected]
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "OPS4J" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>
> Software Architect / Project Manager / Scrum Master
>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - [email protected]
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
--
------------------
OPS4J - http://www.ops4j.org - [email protected]
---
You received this message because you are subscribed to the Google Groups
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
