I have been doing a little more testing. I have an activator method like
this ...

Thread context = new Thread(()->{
Hashtable<String, Object> aDic = new Hashtable<>();
aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_NAME, "default");
aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_CONTEXT_PATH, "/");
aDic.put(Constants.SERVICE_RANKING,Integer.MAX_VALUE);
ctx.registerService(ServletContextHelper.class, new DefaultContxt(), aDic);

});

CountDownLatch latch = new CountDownLatch(1);
Thread s2 = new Thread(()->{

Hashtable<String, Object> aDic = new Hashtable<>();
aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_NAME, "test2");
aDic.put(HttpWhiteboardConstants.HTTP_WHITEBOARD_SERVLET_PATTERN, "/test2");
ctx.registerService(Servlet.class, new TestServlet("Test 2"), aDic);
latch.countDown();
});

s2.start();
latch.await();
Thread.sleep(400);
context.start();

On my machine any value where sleep is <400 the context is always started
first otherwise the servlet gets started first and gets unresgtered and
re-registered into the new context. I am guessing it takes longer to init
the servlet and I wonder if the Context is getting updated during the
servlet init process. (That is what it would seem like from the logs)...

Let me know if you need any more info ...


Dave



On Mon, Sep 19, 2022 at 12:52 PM Grzegorz Grzybek <gr.grzy...@gmail.com>
wrote:

> Hello
>
> It's all loosely coupled - a "servlet registration" knows the LDAP filter
> (by default "osgi.http.whiteboard.context.select=(
> osgi.http.whiteboard.context.name=default)") for it's contexts. And each
> time the new context is registered, the web elements with matching filter
> are being re-registered.
>
> The fact that you're overriding an "OSGi Context" (ServletContextHelper)
> within the same context path "/" means that the servlet context is
> restarted (because there's higher-ranked OsgiServletContext), but the
> servlet should be simply kept in existing "/" ServletContext. I know - lots
> of contexts.
>
> Today I was checking few other
> https://github.com/ops4j/org.ops4j.pax.web/issues, but I remember about
> your scenario - I should have an explanation tomorrow.
>
> regards
> Grzegorz Grzybek
>
> pon., 19 wrz 2022 o 19:42 dave....@candata.com <dave.sm...@candata.com>
> napisał(a):
>
>> Still trying to get a test case but I do believe it is a threading issue
>> ... What I find strange is the servlet that disappears gets registered like
>> this
>>
>> [paxweb-config-1-thread-1] INFO
>> org.ops4j.pax.web.service.internal.HttpServiceEnabled - Registering
>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]}
>> Receiving Batch{"Registration of
>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]}",
>> size=1}
>> Adding servlet
>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]}
>>
>> Now what is ODD is that OCM-2 is not registered yet!  It follows in the
>> logs
>>
>>  Receiving Batch{"Registration of
>> OsgiContextModel{WB,id=OCM-2,name='default',path='/',bundle=com.candatag.web.util,ref={org.osgi.service.http.context.ServletContextHelper}={
>> service.id=39, osgi.http.whiteboard.context.name=default,
>> service.bundleid=17, service.scope=bundle, service.ranking=2147483647,
>> component.name=com.candatag.web.util.zoo.impl.NoSecurityContextImpl,
>> osgi.http.whiteboard.context.path=/, component.id=1}}", size=1}
>>
>> So how does the servlet know that this new default context is coming?  In
>> my test harness I see the servlet unregistering and then registering again
>> when the context changes...
>>
>> It looks like we are half pregnant, somebody knows the context is  there
>> but it is in an unregistered state so the servlet modal does not get
>> attached.
>>
>> Dave
>>
>>
>>
>>
>> On Sunday, September 18, 2022 at 8:50:28 AM UTC-5 dave....@candata.com
>> wrote:
>>
>>> My other question would be if you are "Unregistering " the default
>>> context should it still show up in the
>>> HttpServiceRuntime.getRuntimeDTO().servletContextDTOs ? It does now
>>>
>>> Dave
>>>
>>>
>>> On Sunday, September 18, 2022 at 8:43:33 AM UTC-5 dave....@candata.com
>>> wrote:
>>>
>>>> It will be a little tricky to send my whole project in , let me see
>>>> what I can do , however I have reviewed the test cases in the link provided
>>>> and it looks like you are not covering my case ...
>>>>
>>>> I do not see a test where  ...
>>>>
>>>> Register the default handler ->   HttpContext defaultContext = wc.
>>>> createDefaultHttpContext(); , not sure if this also creates a 
>>>> ServletContextHelper
>>>> wrapper as well
>>>>
>>>> Then create a servlet that attaches to it , but do not call the servlet
>>>> , just check it is added
>>>>
>>>> Register the default override with a high service ranking .
>>>>
>>>> See if this happens
>>>> org.ops4j.pax.web.service.spi.servlet.OsgiServletContext - Unegistering
>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/'
>>>> org.ops4j.pax.web.service.spi.servlet.OsgiServletContext - Registering
>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-2,name='default',path='/',
>>>>
>>>> And then see if the servlet is in the new context ...
>>>>
>>>> The override testcases seem to all create the override first before the
>>>> first servlet is registered OR you are changing the path in the default
>>>> context ...
>>>>
>>>> Dave
>>>>
>>>>
>>>>
>>>> On Sun, Sep 18, 2022 at 8:06 AM Grzegorz Grzybek <gr.gr...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> Actually, the initial reason of entire Pax Web 8 refactoring was the
>>>>> context handling - ability to register one servlet into multiple contexts
>>>>> and multiple servlets into one context.
>>>>> There are really lot of integration tests that show exactly this.
>>>>>
>>>>> I'd have to see your example and check what's the problem there - you
>>>>> seem to correctly override "default" whiteboard context with "/" path and
>>>>> higher ranking, so it should work.
>>>>>
>>>>>
>>>>> https://github.com/ops4j/org.ops4j.pax.web/tree/web-8.0.9/samples/samples-whiteboard/whiteboard-ds
>>>>> is and example of SCR registration of multiple web elements and contexts.
>>>>>
>>>>> This integration test (
>>>>> https://github.com/ops4j/org.ops4j.pax.web/blob/web-8.0.9/pax-web-itest/pax-web-itest-server/src/test/java/org/ops4j/pax/web/itest/server/whiteboard/WhiteboardAndHttpServiceTest.java#L198)
>>>>> - overridenDefaultContextsWithWhiteboardServlet() shows how "default"
>>>>> + "/" context is overriden.
>>>>>
>>>>> Could you please share your project? It can be attached to an issue in
>>>>> https://github.com/ops4j/org.ops4j.pax.web/issues
>>>>>
>>>>> kind regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>> niedz., 18 wrz 2022 o 14:16 Dave Smith <dave....@candata.com>
>>>>> napisał(a):
>>>>>
>>>>>> What is the correct way to override the default servlet context? I am
>>>>>> doing this...
>>>>>>
>>>>>> @Component(service = ServletContextHelper.class,property = {
>>>>>> Constants.SERVICE_RANKING+":Integer="+Integer.MAX_VALUE})
>>>>>> @HttpWhiteboardContext(name = "default",path = "/")
>>>>>> public class NoSecurityContextImpl extends ServletContextHelper
>>>>>> {
>>>>>>
>>>>>> What I am seeing is if a servlet is registered BEFORE the new default
>>>>>> context it just seems to disappear, anything after gets put in the new
>>>>>> default. When I call HttpServiceRuntime.servletDTOs I see the original
>>>>>> default context with no servlets attached to it and my overridden one 
>>>>>> with
>>>>>> the servlets that were registered after.
>>>>>> failedServletDTOs,failedServletContextDTOs are empty. If I remove my
>>>>>> override the servlets appear.
>>>>>>
>>>>>> What is weird is it looks like the servlet is getting put into the
>>>>>> right context if I read the log correctly ...
>>>>>>
>>>>>> Registering
>>>>>> ServletModel{id=ServletModel-4,name='com.candatag.k8s.zoo.servlet.ReadyProbe',urlPatterns=[/osgi/started],contexts=[{WB,OCM-2,default,/}]}
>>>>>>
>>>>>> INFO org.ops4j.pax.web.service.spi.servlet.OsgiServletContext -
>>>>>> Unegistering
>>>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-1,name='default',path='/',bundle=org.ops4j.pax.web.pax-web-extender-whiteboard,context=(supplier)}}
>>>>>> as OSGi service for "/" context path
>>>>>>
>>>>>> Registering
>>>>>> OsgiServletContext{model=OsgiContextModel{WB,id=OCM-2,name='default',path='/',bundle=com.candatag.web.util,ref={org.osgi.service.http.context.ServletContextHelper}={
>>>>>> service.id=57, osgi.http.whiteboard.context.name=default,
>>>>>> service.bundleid=19, service.scope=bundle, service.ranking=2147483647
>>>>>> <(214)%20748-3647>, 
>>>>>> component.name=com.candatag.web.util.zoo.impl.NoSecurityContextImpl,
>>>>>> osgi.http.whiteboard.context.path=/, component.id=22}}} as OSGi
>>>>>> service for "/" context path
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> ------------------
>>>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com
>>>>>>
>>>>>> ---
>>>>>> 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 ops4j+un...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/ops4j/CA%2BFCLu2SbiSKmN7W3-ZQqHLYCA67vF104UCVWtU77-63tcarUA%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/ops4j/CA%2BFCLu2SbiSKmN7W3-ZQqHLYCA67vF104UCVWtU77-63tcarUA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>>> --
>>>>> ------------------
>>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com
>>>>>
>>>>> ---
>>>>> 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 ops4j+un...@googlegroups.com.
>>>>>
>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/ops4j/CAAdXmhrMU6_5ABFc0oxevK%2BjuZVhOzxdK0cqvyTz6pCWZAM7Yg%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/ops4j/CAAdXmhrMU6_5ABFc0oxevK%2BjuZVhOzxdK0cqvyTz6pCWZAM7Yg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>> --
>> ------------------
>> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>>
>> ---
>> 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 ops4j+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ops4j/e972d47a-f8b3-4dec-9ba1-94549e29a250n%40googlegroups.com
>> <https://groups.google.com/d/msgid/ops4j/e972d47a-f8b3-4dec-9ba1-94549e29a250n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> --
> ------------------
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> 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 ops4j+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ops4j/CAAdXmhqzknu%3DwfrL5d-hWbHe%2BGa%2Bazbx6Yg__OTuC683B8VbMA%40mail.gmail.com
> <https://groups.google.com/d/msgid/ops4j/CAAdXmhqzknu%3DwfrL5d-hWbHe%2BGa%2Bazbx6Yg__OTuC683B8VbMA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- 
------------------
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com

--- 
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 ops4j+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ops4j/CA%2BFCLu1OssPACzuqNDCpxT3AGz%3DRjarNubJUi%2BPXuog2D0aWMA%40mail.gmail.com.

Reply via email to