Home » Eclipse Projects » Equinox » Startup order effecting servlet registration classloader
| Startup order effecting servlet registration classloader [message #77396] |
Thu, 16 November 2006 20:55  |
Eclipse User |
|
|
|
Hey,
I have a servlet that I'm trying to run under equinox but it's behaving
differently on two separate servers.
The difference between the two seems to be with the startup ordering of
the org.eclipse.equinox.servlet.bridge.http bundle and the servlet bundle.
Depending on which one starts first the servlet will either be
registered with a
org.eclipse.core.runtime.internal.adaptor.ContextFinder class loader or
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.
The ContextFinder if the servlet bundle is started first, and
DefaultClassLoader if the bridge is started first.
It appears that the servlet can't find some resources when starting with
the DefaultClassLoader but it can when started with the ContextFinder so
it's running into problems.
Is this the correct way for the class loaders to work in this situation?
Or is the servlet doing something it shouldn't?
Cheers,
Shaun
PS. I guess I'll try the latest equinox builds to see if they're different
|
|
| | |
| Re: Startup order effecting servlet registration classloader [message #77747 is a reply to message #77452] |
Mon, 20 November 2006 18:47  |
| Eclipse User |
|
|
|
Hey Simon,
Something setting the context class loader, but it's not me.
At the moment I'm using the embedded Jetty service.
org.eclipse.equinox.http.registry (dev.eclipse.org/HEAD),
org.eclipse.equinox.http.servlet (dev.eclipse.org/HEAD),
org.eclipse.equinox.jetty.http (dev.eclipse.org/HEAD) and
org.mortbay.jetty (dev.eclipse.org/v5_1_11).
And I have two scenarios depending on the start order:
1. Doesn't work when I need the resources later
org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
and IExtensionRegistry services and when it has both creates a
HttpServiceTracker
org.eclipse.equinox.http.registry.internal.Activator.addingS ervice is
triggered (twice) and creates a HttpServiceTracker
org.eclipse.equinox.http.servlet.internal.Activator starts
HttpServiceProxy by registering any HttpServices is knows about (there
are none)
org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
new HttpServer
HttpServiceTracker.addingService(for HttpService) is triggered and
creates a new ServletManager (and HttpContextManager and ResourceManager)
ServletManager.added(IExtension) is triggered which creates a new
ServletRegistration with a
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader as the
registeredContextClassLoader
2. Does work when I need the resources
org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
new HttpServer
org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
and IExtensionRegistry services and when it has both creates a
HttpServiceTracker
org.eclipse.equinox.http.servlet.internal.Activator starts
HttpServiceProxy by registering any HttpServices is knows about (this
time there is one)
HttpServiceTracker.addingService(for HttpService) is triggered and
creates a new ServletManager (and HttpContextManager and ResourceManager)
ServletManager.added(IExtension) is triggered which creates a new
ServletRegistration with a
org.eclipse.core.runtime.internal.adaptor.ContextFinder as the
registeredContextClassLoader
So something in there is changing the thread context class loader
I don't know if this is the expected behaviour.
As for the code that's trying to access the resources, it's using JAXB
with the JAXB generated classes in one bundle and another bundle trying
to access these classes with JAXBContext.newInstance(contextPath), for
example
client.servlet bundle contains a servlet that uses
JAXBContext ctx = JAXBContext.newInstance("client.bind");
and has a required dependency in the manifest for client.bind
client.bind bundle contains the JAXB generated classes, including
client.bind.ObjectFactory.class (which is the resource the
JAXB.newInstance() fails on)
JAXBContext.newInstance uses the thread context class loader specified
in the servlet registration to find the ObjectFactory class, which fails
with the DefaultContextLoader but succeeds with the ContextFinder.
Not sure which class loader is supposed to be used, or if JAXB is
supported in this way.
Cheers,
Shaun
Simon Kaegi wrote:
> Hi Shaun,
>
> That sounds strange -- you shouldn't have to mess with the start levels and
> unless you're explicitly setting a thread context class loader the
> ContextFinder shouldn't really enter into the picture.
> Are you running in an appserver (e.g. with bridge.war) or using the embedded
> Jetty HttpService?
>
> You mentioned updating to the latest code and that's probably a good idea.
> There's a couple of documents on http://www.eclipse.org/equinox/server that
> should help setting up.
>
> If you're still having problems can you tell a bit more about how your
> Servlet is looking up resources.
>
> -Simon
>
>
>
> "Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
> news:ejj7tl$cdi$1@utils.eclipse.org...
>> I've found that putting org.eclipse.equinox.jetty.http to start level 2,
>> so it starts before org.eclipse.equinox.servlet.bridge.http stops the
>> problem, but I'm not convinced that the displayed behaviour is correct.
>>
>> Cheers
>>
>> Shaun Forbes wrote:
>>> Hey,
>>>
>>> I have a servlet that I'm trying to run under equinox but it's behaving
>>> differently on two separate servers.
>>>
>>> The difference between the two seems to be with the startup ordering of
>>> the org.eclipse.equinox.servlet.bridge.http bundle and the servlet
> bundle.
>>> Depending on which one starts first the servlet will either be
>>> registered with a
>>> org.eclipse.core.runtime.internal.adaptor.ContextFinder class loader or
>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.
>>>
>>> The ContextFinder if the servlet bundle is started first, and
>>> DefaultClassLoader if the bridge is started first.
>>>
>>>
>>> It appears that the servlet can't find some resources when starting with
>>> the DefaultClassLoader but it can when started with the ContextFinder so
>>> it's running into problems.
>>>
>>>
>>> Is this the correct way for the class loaders to work in this situation?
>>> Or is the servlet doing something it shouldn't?
>>>
>>> Cheers,
>>> Shaun
>>>
>>> PS. I guess I'll try the latest equinox builds to see if they're
> different
>
>
|
|
|
| Re: Startup order effecting servlet registration classloader [message #77764 is a reply to message #77747] |
Mon, 20 November 2006 22:19 |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
Thanks Shaun!
Great job tracking this down. That's not the intended behaviour and is
definitely a bug.
The TCCL should be restored to ContextFinder regardless of start order.
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=165273 to track
the issue.
-Simon
"Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
news:45623E97.3080909@sforbes.myip.org...
> Hey Simon,
>
> Something setting the context class loader, but it's not me.
>
> At the moment I'm using the embedded Jetty service.
> org.eclipse.equinox.http.registry (dev.eclipse.org/HEAD),
> org.eclipse.equinox.http.servlet (dev.eclipse.org/HEAD),
> org.eclipse.equinox.jetty.http (dev.eclipse.org/HEAD) and
> org.mortbay.jetty (dev.eclipse.org/v5_1_11).
>
> And I have two scenarios depending on the start order:
>
> 1. Doesn't work when I need the resources later
>
> org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
> and IExtensionRegistry services and when it has both creates a
> HttpServiceTracker
> org.eclipse.equinox.http.registry.internal.Activator.addingS ervice is
> triggered (twice) and creates a HttpServiceTracker
> org.eclipse.equinox.http.servlet.internal.Activator starts
> HttpServiceProxy by registering any HttpServices is knows about (there
> are none)
> org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
> new HttpServer
> HttpServiceTracker.addingService(for HttpService) is triggered and
> creates a new ServletManager (and HttpContextManager and ResourceManager)
> ServletManager.added(IExtension) is triggered which creates a new
> ServletRegistration with a
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader as the
> registeredContextClassLoader
>
> 2. Does work when I need the resources
>
> org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
> new HttpServer
> org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
> and IExtensionRegistry services and when it has both creates a
> HttpServiceTracker
> org.eclipse.equinox.http.servlet.internal.Activator starts
> HttpServiceProxy by registering any HttpServices is knows about (this
> time there is one)
> HttpServiceTracker.addingService(for HttpService) is triggered and
> creates a new ServletManager (and HttpContextManager and ResourceManager)
> ServletManager.added(IExtension) is triggered which creates a new
> ServletRegistration with a
> org.eclipse.core.runtime.internal.adaptor.ContextFinder as the
> registeredContextClassLoader
>
> So something in there is changing the thread context class loader
> I don't know if this is the expected behaviour.
>
>
> As for the code that's trying to access the resources, it's using JAXB
> with the JAXB generated classes in one bundle and another bundle trying
> to access these classes with JAXBContext.newInstance(contextPath), for
> example
>
> client.servlet bundle contains a servlet that uses
> JAXBContext ctx = JAXBContext.newInstance("client.bind");
> and has a required dependency in the manifest for client.bind
>
> client.bind bundle contains the JAXB generated classes, including
> client.bind.ObjectFactory.class (which is the resource the
> JAXB.newInstance() fails on)
>
>
> JAXBContext.newInstance uses the thread context class loader specified
> in the servlet registration to find the ObjectFactory class, which fails
> with the DefaultContextLoader but succeeds with the ContextFinder.
>
>
>
> Not sure which class loader is supposed to be used, or if JAXB is
> supported in this way.
>
> Cheers,
> Shaun
>
> Simon Kaegi wrote:
> > Hi Shaun,
> >
> > That sounds strange -- you shouldn't have to mess with the start levels
and
> > unless you're explicitly setting a thread context class loader the
> > ContextFinder shouldn't really enter into the picture.
> > Are you running in an appserver (e.g. with bridge.war) or using the
embedded
> > Jetty HttpService?
> >
> > You mentioned updating to the latest code and that's probably a good
idea.
> > There's a couple of documents on http://www.eclipse.org/equinox/server
that
> > should help setting up.
> >
> > If you're still having problems can you tell a bit more about how your
> > Servlet is looking up resources.
> >
> > -Simon
> >
> >
> >
> > "Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
> > news:ejj7tl$cdi$1@utils.eclipse.org...
> >> I've found that putting org.eclipse.equinox.jetty.http to start level
2,
> >> so it starts before org.eclipse.equinox.servlet.bridge.http stops the
> >> problem, but I'm not convinced that the displayed behaviour is correct.
> >>
> >> Cheers
> >>
> >> Shaun Forbes wrote:
> >>> Hey,
> >>>
> >>> I have a servlet that I'm trying to run under equinox but it's
behaving
> >>> differently on two separate servers.
> >>>
> >>> The difference between the two seems to be with the startup ordering
of
> >>> the org.eclipse.equinox.servlet.bridge.http bundle and the servlet
> > bundle.
> >>> Depending on which one starts first the servlet will either be
> >>> registered with a
> >>> org.eclipse.core.runtime.internal.adaptor.ContextFinder class loader
or
> >>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.
> >>>
> >>> The ContextFinder if the servlet bundle is started first, and
> >>> DefaultClassLoader if the bridge is started first.
> >>>
> >>>
> >>> It appears that the servlet can't find some resources when starting
with
> >>> the DefaultClassLoader but it can when started with the ContextFinder
so
> >>> it's running into problems.
> >>>
> >>>
> >>> Is this the correct way for the class loaders to work in this
situation?
> >>> Or is the servlet doing something it shouldn't?
> >>>
> >>> Cheers,
> >>> Shaun
> >>>
> >>> PS. I guess I'll try the latest equinox builds to see if they're
> > different
> >
> >
|
|
|
| Re: Startup order effecting servlet registration classloader [message #77891 is a reply to message #77764] |
Wed, 22 November 2006 22:58 |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
Fixed in org.eclipse.equinox.http.jetty HEAD.
Thanks Shaun
"Simon Kaegi" <skaegi@sympatico.ca> wrote in message
news:ejtr7m$fa7$1@utils.eclipse.org...
> Thanks Shaun!
>
> Great job tracking this down. That's not the intended behaviour and is
> definitely a bug.
> The TCCL should be restored to ContextFinder regardless of start order.
>
> I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=165273 to track
> the issue.
> -Simon
>
> "Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
> news:45623E97.3080909@sforbes.myip.org...
> > Hey Simon,
> >
> > Something setting the context class loader, but it's not me.
> >
> > At the moment I'm using the embedded Jetty service.
> > org.eclipse.equinox.http.registry (dev.eclipse.org/HEAD),
> > org.eclipse.equinox.http.servlet (dev.eclipse.org/HEAD),
> > org.eclipse.equinox.jetty.http (dev.eclipse.org/HEAD) and
> > org.mortbay.jetty (dev.eclipse.org/v5_1_11).
> >
> > And I have two scenarios depending on the start order:
> >
> > 1. Doesn't work when I need the resources later
> >
> > org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
> > and IExtensionRegistry services and when it has both creates a
> > HttpServiceTracker
> > org.eclipse.equinox.http.registry.internal.Activator.addingS ervice is
> > triggered (twice) and creates a HttpServiceTracker
> > org.eclipse.equinox.http.servlet.internal.Activator starts
> > HttpServiceProxy by registering any HttpServices is knows about (there
> > are none)
> > org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
> > new HttpServer
> > HttpServiceTracker.addingService(for HttpService) is triggered and
> > creates a new ServletManager (and HttpContextManager and
ResourceManager)
> > ServletManager.added(IExtension) is triggered which creates a new
> > ServletRegistration with a
> > org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader as the
> > registeredContextClassLoader
> >
> > 2. Does work when I need the resources
> >
> > org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
> > new HttpServer
> > org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
> > and IExtensionRegistry services and when it has both creates a
> > HttpServiceTracker
> > org.eclipse.equinox.http.servlet.internal.Activator starts
> > HttpServiceProxy by registering any HttpServices is knows about (this
> > time there is one)
> > HttpServiceTracker.addingService(for HttpService) is triggered and
> > creates a new ServletManager (and HttpContextManager and
ResourceManager)
> > ServletManager.added(IExtension) is triggered which creates a new
> > ServletRegistration with a
> > org.eclipse.core.runtime.internal.adaptor.ContextFinder as the
> > registeredContextClassLoader
> >
> > So something in there is changing the thread context class loader
> > I don't know if this is the expected behaviour.
> >
> >
> > As for the code that's trying to access the resources, it's using JAXB
> > with the JAXB generated classes in one bundle and another bundle trying
> > to access these classes with JAXBContext.newInstance(contextPath), for
> > example
> >
> > client.servlet bundle contains a servlet that uses
> > JAXBContext ctx = JAXBContext.newInstance("client.bind");
> > and has a required dependency in the manifest for client.bind
> >
> > client.bind bundle contains the JAXB generated classes, including
> > client.bind.ObjectFactory.class (which is the resource the
> > JAXB.newInstance() fails on)
> >
> >
> > JAXBContext.newInstance uses the thread context class loader specified
> > in the servlet registration to find the ObjectFactory class, which fails
> > with the DefaultContextLoader but succeeds with the ContextFinder.
> >
> >
> >
> > Not sure which class loader is supposed to be used, or if JAXB is
> > supported in this way.
> >
> > Cheers,
> > Shaun
> >
> > Simon Kaegi wrote:
> > > Hi Shaun,
> > >
> > > That sounds strange -- you shouldn't have to mess with the start
levels
> and
> > > unless you're explicitly setting a thread context class loader the
> > > ContextFinder shouldn't really enter into the picture.
> > > Are you running in an appserver (e.g. with bridge.war) or using the
> embedded
> > > Jetty HttpService?
> > >
> > > You mentioned updating to the latest code and that's probably a good
> idea.
> > > There's a couple of documents on http://www.eclipse.org/equinox/server
> that
> > > should help setting up.
> > >
> > > If you're still having problems can you tell a bit more about how your
> > > Servlet is looking up resources.
> > >
> > > -Simon
> > >
> > >
> > >
> > > "Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
> > > news:ejj7tl$cdi$1@utils.eclipse.org...
> > >> I've found that putting org.eclipse.equinox.jetty.http to start level
> 2,
> > >> so it starts before org.eclipse.equinox.servlet.bridge.http stops the
> > >> problem, but I'm not convinced that the displayed behaviour is
correct.
> > >>
> > >> Cheers
> > >>
> > >> Shaun Forbes wrote:
> > >>> Hey,
> > >>>
> > >>> I have a servlet that I'm trying to run under equinox but it's
> behaving
> > >>> differently on two separate servers.
> > >>>
> > >>> The difference between the two seems to be with the startup ordering
> of
> > >>> the org.eclipse.equinox.servlet.bridge.http bundle and the servlet
> > > bundle.
> > >>> Depending on which one starts first the servlet will either be
> > >>> registered with a
> > >>> org.eclipse.core.runtime.internal.adaptor.ContextFinder class loader
> or
> > >>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.
> > >>>
> > >>> The ContextFinder if the servlet bundle is started first, and
> > >>> DefaultClassLoader if the bridge is started first.
> > >>>
> > >>>
> > >>> It appears that the servlet can't find some resources when starting
> with
> > >>> the DefaultClassLoader but it can when started with the
ContextFinder
> so
> > >>> it's running into problems.
> > >>>
> > >>>
> > >>> Is this the correct way for the class loaders to work in this
> situation?
> > >>> Or is the servlet doing something it shouldn't?
> > >>>
> > >>> Cheers,
> > >>> Shaun
> > >>>
> > >>> PS. I guess I'll try the latest equinox builds to see if they're
> > > different
> > >
> > >
>
>
|
|
|
| Re: Startup order effecting servlet registration classloader [message #77906 is a reply to message #77891] |
Thu, 23 November 2006 00:53 |
| Eclipse User |
|
|
|
Looks good, thanks for the quick turn around.
Cheers
Simon Kaegi wrote:
> Fixed in org.eclipse.equinox.http.jetty HEAD.
> Thanks Shaun
>
> "Simon Kaegi" <skaegi@sympatico.ca> wrote in message
> news:ejtr7m$fa7$1@utils.eclipse.org...
>> Thanks Shaun!
>>
>> Great job tracking this down. That's not the intended behaviour and is
>> definitely a bug.
>> The TCCL should be restored to ContextFinder regardless of start order.
>>
>> I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=165273 to track
>> the issue.
>> -Simon
>>
>> "Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
>> news:45623E97.3080909@sforbes.myip.org...
>>> Hey Simon,
>>>
>>> Something setting the context class loader, but it's not me.
>>>
>>> At the moment I'm using the embedded Jetty service.
>>> org.eclipse.equinox.http.registry (dev.eclipse.org/HEAD),
>>> org.eclipse.equinox.http.servlet (dev.eclipse.org/HEAD),
>>> org.eclipse.equinox.jetty.http (dev.eclipse.org/HEAD) and
>>> org.mortbay.jetty (dev.eclipse.org/v5_1_11).
>>>
>>> And I have two scenarios depending on the start order:
>>>
>>> 1. Doesn't work when I need the resources later
>>>
>>> org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
>>> and IExtensionRegistry services and when it has both creates a
>>> HttpServiceTracker
>>> org.eclipse.equinox.http.registry.internal.Activator.addingS ervice is
>>> triggered (twice) and creates a HttpServiceTracker
>>> org.eclipse.equinox.http.servlet.internal.Activator starts
>>> HttpServiceProxy by registering any HttpServices is knows about (there
>>> are none)
>>> org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
>>> new HttpServer
>>> HttpServiceTracker.addingService(for HttpService) is triggered and
>>> creates a new ServletManager (and HttpContextManager and
> ResourceManager)
>>> ServletManager.added(IExtension) is triggered which creates a new
>>> ServletRegistration with a
>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader as the
>>> registeredContextClassLoader
>>>
>>> 2. Does work when I need the resources
>>>
>>> org.eclipse.equinox.jetty.http.internal.Activator constructs and starts
>>> new HttpServer
>>> org.eclipse.equinox.http.registry.internal.Activator tracks PackageAdmin
>>> and IExtensionRegistry services and when it has both creates a
>>> HttpServiceTracker
>>> org.eclipse.equinox.http.servlet.internal.Activator starts
>>> HttpServiceProxy by registering any HttpServices is knows about (this
>>> time there is one)
>>> HttpServiceTracker.addingService(for HttpService) is triggered and
>>> creates a new ServletManager (and HttpContextManager and
> ResourceManager)
>>> ServletManager.added(IExtension) is triggered which creates a new
>>> ServletRegistration with a
>>> org.eclipse.core.runtime.internal.adaptor.ContextFinder as the
>>> registeredContextClassLoader
>>>
>>> So something in there is changing the thread context class loader
>>> I don't know if this is the expected behaviour.
>>>
>>>
>>> As for the code that's trying to access the resources, it's using JAXB
>>> with the JAXB generated classes in one bundle and another bundle trying
>>> to access these classes with JAXBContext.newInstance(contextPath), for
>>> example
>>>
>>> client.servlet bundle contains a servlet that uses
>>> JAXBContext ctx = JAXBContext.newInstance("client.bind");
>>> and has a required dependency in the manifest for client.bind
>>>
>>> client.bind bundle contains the JAXB generated classes, including
>>> client.bind.ObjectFactory.class (which is the resource the
>>> JAXB.newInstance() fails on)
>>>
>>>
>>> JAXBContext.newInstance uses the thread context class loader specified
>>> in the servlet registration to find the ObjectFactory class, which fails
>>> with the DefaultContextLoader but succeeds with the ContextFinder.
>>>
>>>
>>>
>>> Not sure which class loader is supposed to be used, or if JAXB is
>>> supported in this way.
>>>
>>> Cheers,
>>> Shaun
>>>
>>> Simon Kaegi wrote:
>>>> Hi Shaun,
>>>>
>>>> That sounds strange -- you shouldn't have to mess with the start
> levels
>> and
>>>> unless you're explicitly setting a thread context class loader the
>>>> ContextFinder shouldn't really enter into the picture.
>>>> Are you running in an appserver (e.g. with bridge.war) or using the
>> embedded
>>>> Jetty HttpService?
>>>>
>>>> You mentioned updating to the latest code and that's probably a good
>> idea.
>>>> There's a couple of documents on http://www.eclipse.org/equinox/server
>> that
>>>> should help setting up.
>>>>
>>>> If you're still having problems can you tell a bit more about how your
>>>> Servlet is looking up resources.
>>>>
>>>> -Simon
>>>>
>>>>
>>>>
>>>> "Shaun Forbes" <sforbes@sforbes.myip.org> wrote in message
>>>> news:ejj7tl$cdi$1@utils.eclipse.org...
>>>>> I've found that putting org.eclipse.equinox.jetty.http to start level
>> 2,
>>>>> so it starts before org.eclipse.equinox.servlet.bridge.http stops the
>>>>> problem, but I'm not convinced that the displayed behaviour is
> correct.
>>>>> Cheers
>>>>>
>>>>> Shaun Forbes wrote:
>>>>>> Hey,
>>>>>>
>>>>>> I have a servlet that I'm trying to run under equinox but it's
>> behaving
>>>>>> differently on two separate servers.
>>>>>>
>>>>>> The difference between the two seems to be with the startup ordering
>> of
>>>>>> the org.eclipse.equinox.servlet.bridge.http bundle and the servlet
>>>> bundle.
>>>>>> Depending on which one starts first the servlet will either be
>>>>>> registered with a
>>>>>> org.eclipse.core.runtime.internal.adaptor.ContextFinder class loader
>> or
>>>>>> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.
>>>>>>
>>>>>> The ContextFinder if the servlet bundle is started first, and
>>>>>> DefaultClassLoader if the bridge is started first.
>>>>>>
>>>>>>
>>>>>> It appears that the servlet can't find some resources when starting
>> with
>>>>>> the DefaultClassLoader but it can when started with the
> ContextFinder
>> so
>>>>>> it's running into problems.
>>>>>>
>>>>>>
>>>>>> Is this the correct way for the class loaders to work in this
>> situation?
>>>>>> Or is the servlet doing something it shouldn't?
>>>>>>
>>>>>> Cheers,
>>>>>> Shaun
>>>>>>
>>>>>> PS. I guess I'll try the latest equinox builds to see if they're
>>>> different
>>>>
>>>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Tue Nov 04 00:34:29 EST 2025
Powered by FUDForum. Page generated in 0.04977 seconds |
Home