An update on this problem...
Problem #1 was not a problem but a bug in my code. I created the "//"
(double slash) all by myself. Sorry for the buzz.
Problem #2 however still exists. If I register resources on the root url
using
mWebService.registerResources("/", "/webroot", mHttpContext);
Then I cannot publish any resources using jetty.xml and org.eclipse.jetty.
server.handler.ResourceHandler.
Pax-Web's resource handler does not seem to pass the request on to the
handler I register in jetty.xml.
So my problem is that I need to accomplish both of these things at the same
time:
- Map "/logo" to a normal directory using jetty.xml and org.eclipse.jetty.
server.handler.ResourceHandler
- Map "/" to the "/webroot" directory in my bundle using the
registerResources() method.
How can I accomplish this?
I did try to use "insertRule" in my jetty.xml instead of "addHandler" since
I hoped that this would put the "/logo" rule first. However, this syntax
does not seem to be supported.
/Bengt
2016-11-09 8:58 GMT+01:00 Bengt Rodehav <[email protected]>:
> OK - thanks.
>
> Finally got you :-)
>
> /Bengt
>
> 2016-11-08 21:27 GMT+01:00 'Achim Nierbeck' via OPS4J <
> [email protected]>:
>
>> Hi
>>
>> regarding registering resources on "/" ... I'd expect it to work in the
>> way you describe it, but you might have found a bug there.
>> The thing about the "/" - context, is. It is special. Since all
>> HttpService registered "resources" are registered with this as the context
>> ... So it might be that an additional context from outside doesn't play
>> along. Will need to test.
>>
>> regards, Achim
>>
>>
>> 2016-11-08 8:58 GMT+01:00 Bengt Rodehav <[email protected]>:
>>
>>> 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.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: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(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.ja
>>> va: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.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: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(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.ja
>>> va: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-j
>>>> etty/src/test/java/org/ops4j/pax/web/itest/jetty/RootAliasIn
>>>> tegrationTest.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.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.inte
>>>>> rnal.HttpServiceStarted.registerResources(HttpServiceStarted.java:262)
>>>>> at org.ops4j.pax.web.service.inte
>>>>> rnal.HttpServiceProxy.registerResources(HttpServiceProxy.java:71)
>>>>> at org.ops4j.pax.web.service.WebC
>>>>> ontainer$$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.NativeMethodAccess
>>>>> orImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_74]
>>>>> at sun.reflect.DelegatingMethodAc
>>>>> cessorImpl.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.Ca
>>>>> llback.call(Callback.java:237)[50:org.apache.felix.ipojo:1.12.1]
>>>>> at org.apache.felix.ipojo.util.Ca
>>>>> llback.call(Callback.java:193)[50:org.apache.felix.ipojo:1.12.1]
>>>>> at org.apache.felix.ipojo.handler
>>>>> s.lifecycle.callback.LifecycleCallback.call(LifecycleCallbac
>>>>> k.java:86)[50:org.apache.felix.ipojo:1.12.1]
>>>>> at org.apache.felix.ipojo.handler
>>>>> s.lifecycle.callback.LifecycleCallbackHandler.__M_stateChang
>>>>> ed(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.
>>>
>>
>>
>>
>> --
>>
>> 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.
