Home » Eclipse Projects » Equinox » When is an HttpServlet not an HttpServlet?
|
| Re: When is an HttpServlet not an HttpServlet? [message #80482 is a reply to message #80467] |
Tue, 09 January 2007 02:17   |
Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
Hi John,
That does sound strange. My guess would have been different class loaders
however maybe something else is going on.
Can you post the contents of an "ss" in the console.
You might also try using the "bundle" (or "b") command to track down where
your imports are coming from.
-Simon
"JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
news:enunp7$hm5$1@utils.eclipse.org...
> Ok, I am completely lost. I thought I followed the equinox recipes, but
> I must have missed some ingredients.
>
> In one bundle (er plugin, whatever), I created an HttpServlet (class
> FileSystemServlet). I tell equinox this is a service:
>
> this.bundleContext.registerService(HttpServlet.class.getName (),
> servlet, configuration);
>
> In another bundle I listen for service registrations and sure enough my
> servlet comes along. I grab if from the service reference sr:
>
> Object servlet = bundleContext.getService(sr);
>
> First thing I want to do is use the object as a HttpServlet:
>
> if (servlet instanceof HttpServlet) { ... do great work....
>
> But my servlet fails this test.
>
> The only reason I can come up with is that the HttpServlet interface I
> am using for type testing is loaded by a different class loader from the
> one used when I created the servlet. It can't be so or equinox would
> never work.
>
> Any hints?
>
> John.
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #80554 is a reply to message #80482] |
Tue, 09 January 2007 21:26 |
 John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Hi Simon. I found my mistake: I had my service-providing plugin
dependent on one HttpServlet class file and the service-listener plugin
dependent upon another one. That's not a good thing ;-). Both plugins
compiled and ran, but the type tests failed at runtime.
Solving this problem was harder than I expected. I had
org.eclipse.equinox.servlet.api and another plugin called javax.servlet.
Which to pick? I tried org.eclipse.equinox.servlet.api but it failed.
So I tried javax.servlet (2.4); it worked. Just trial and error, no way
to decide this by logic.
Here's my theory for what goes on:
Eclipse has a tree of class loaders.
At the root of the tree are exposed packages.
Each bundle is a branch.
Packages loaded into one branch create objects with a different runtime
type from objects on another branch.
Type tests that compile in one branch will fail at runtime because of
the invisible class-loader type-dependency.
If so in my opinion the equinox story has a hole: when we issue
registerSevice the first argument should be some combination of
classname and class loader. Then my problem cannot happen I guess.
Thanks,
John.
Simon Kaegi wrote:
> Hi John,
>
> That does sound strange. My guess would have been different class loaders
> however maybe something else is going on.
> Can you post the contents of an "ss" in the console.
> You might also try using the "bundle" (or "b") command to track down where
> your imports are coming from.
>
> -Simon
>
> "JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
> news:enunp7$hm5$1@utils.eclipse.org...
>
>>Ok, I am completely lost. I thought I followed the equinox recipes, but
>>I must have missed some ingredients.
>>
>>In one bundle (er plugin, whatever), I created an HttpServlet (class
>>FileSystemServlet). I tell equinox this is a service:
>>
>> this.bundleContext.registerService(HttpServlet.class.getName (),
>>servlet, configuration);
>>
>>In another bundle I listen for service registrations and sure enough my
>>servlet comes along. I grab if from the service reference sr:
>>
>>Object servlet = bundleContext.getService(sr);
>>
>>First thing I want to do is use the object as a HttpServlet:
>>
>>if (servlet instanceof HttpServlet) { ... do great work....
>>
>>But my servlet fails this test.
>>
>>The only reason I can come up with is that the HttpServlet interface I
>>am using for type testing is loaded by a different class loader from the
>>one used when I created the servlet. It can't be so or equinox would
>>never work.
>>
>>Any hints?
>>
>>John.
>
>
>
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #80569 is a reply to message #80554] |
Wed, 10 January 2007 07:36 |
Danail Nachev
Messages: 110
Registered: July 2009 |
Senior Member |
|
|
Hi, John
The more correct representation of the class loader hierarchy is a
graph. The class loader of one bundle is one node of the graph. If the
class is from imported package, then between this node and the node of
the bundle, which provides the class will be created an arc. Now, the
first class loader will delegate the loading to the other class loader.
In OSGi it is very important that you don't have duplicate classes or
you have to guarantee that this will not cause any problems (like
ClassCastException's)
In your case it seems that HttpServlet class was loaded by the first
bundle from one place. The bundle (second one), which registered the
service, has loaded HttpServlet from different place. So, when you
retrieve the service in the first bundle, it will different class than
the one you expect, because the classes which are used by the two
bundles are from different class loaders, although they have the same
fully qualified name.
Danail
JOHN J. BARTON wrote:
> Hi Simon. I found my mistake: I had my service-providing plugin
> dependent on one HttpServlet class file and the service-listener plugin
> dependent upon another one. That's not a good thing ;-). Both plugins
> compiled and ran, but the type tests failed at runtime.
>
> Solving this problem was harder than I expected. I had
> org.eclipse.equinox.servlet.api and another plugin called javax.servlet.
> Which to pick? I tried org.eclipse.equinox.servlet.api but it failed.
> So I tried javax.servlet (2.4); it worked. Just trial and error, no way
> to decide this by logic.
>
> Here's my theory for what goes on:
> Eclipse has a tree of class loaders.
> At the root of the tree are exposed packages.
> Each bundle is a branch.
> Packages loaded into one branch create objects with a different
> runtime type from objects on another branch.
> Type tests that compile in one branch will fail at runtime because
> of the invisible class-loader type-dependency.
>
> If so in my opinion the equinox story has a hole: when we issue
> registerSevice the first argument should be some combination of
> classname and class loader. Then my problem cannot happen I guess.
>
> Thanks,
> John.
>
>
>
> Simon Kaegi wrote:
>> Hi John,
>>
>> That does sound strange. My guess would have been different class loaders
>> however maybe something else is going on.
>> Can you post the contents of an "ss" in the console.
>> You might also try using the "bundle" (or "b") command to track down
>> where
>> your imports are coming from.
>>
>> -Simon
>>
>> "JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
>> news:enunp7$hm5$1@utils.eclipse.org...
>>
>>> Ok, I am completely lost. I thought I followed the equinox recipes, but
>>> I must have missed some ingredients.
>>>
>>> In one bundle (er plugin, whatever), I created an HttpServlet (class
>>> FileSystemServlet). I tell equinox this is a service:
>>>
>>> this.bundleContext.registerService(HttpServlet.class.getName (),
>>> servlet, configuration);
>>>
>>> In another bundle I listen for service registrations and sure enough my
>>> servlet comes along. I grab if from the service reference sr:
>>>
>>> Object servlet = bundleContext.getService(sr);
>>>
>>> First thing I want to do is use the object as a HttpServlet:
>>>
>>> if (servlet instanceof HttpServlet) { ... do great work....
>>>
>>> But my servlet fails this test.
>>>
>>> The only reason I can come up with is that the HttpServlet interface I
>>> am using for type testing is loaded by a different class loader from the
>>> one used when I created the servlet. It can't be so or equinox would
>>> never work.
>>>
>>> Any hints?
>>>
>>> John.
>>
>>
>>
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #80600 is a reply to message #80569] |
Wed, 10 January 2007 18:35 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Danail Nachev wrote:
> Hi, John
>
> The more correct representation of the class loader hierarchy is a
> graph. The class loader of one bundle is one node of the graph. If the
Thanks Danail. Unfortunately this explanation only creates more
questions (with my guesses)
-- Directed graph? (yes)
-- No cycles? (yes)
-- Are all arcs identical? (no, eg what does "imported" mean?)
-- How is this graph creates (by an ill-defined combination of rules
for MANIFEST.MF and the registry of eclipse).
Maybe this is all explained somewhere?
I'm beginning to understand that eclipse has evolved beyond plugins, but
that its tooling, the PDE, has not kept up. The PDE works great for one
plugin extending eclipse, but its not ready for OSGi and multi-bundle
development. Getting a clear picture of the class loading/bundle
story would be a good starting point.
John.
> class is from imported package, then between this node and the node of
> the bundle, which provides the class will be created an arc. Now, the
> first class loader will delegate the loading to the other class loader.
> In OSGi it is very important that you don't have duplicate classes or
> you have to guarantee that this will not cause any problems (like
> ClassCastException's)
>
> In your case it seems that HttpServlet class was loaded by the first
> bundle from one place. The bundle (second one), which registered the
> service, has loaded HttpServlet from different place. So, when you
> retrieve the service in the first bundle, it will different class than
> the one you expect, because the classes which are used by the two
> bundles are from different class loaders, although they have the same
> fully qualified name.
>
> Danail
>
> JOHN J. BARTON wrote:
>
>>Hi Simon. I found my mistake: I had my service-providing plugin
>>dependent on one HttpServlet class file and the service-listener plugin
>>dependent upon another one. That's not a good thing ;-). Both plugins
>>compiled and ran, but the type tests failed at runtime.
>>
>>Solving this problem was harder than I expected. I had
>>org.eclipse.equinox.servlet.api and another plugin called javax.servlet.
>> Which to pick? I tried org.eclipse.equinox.servlet.api but it failed.
>>So I tried javax.servlet (2.4); it worked. Just trial and error, no way
>>to decide this by logic.
>>
>>Here's my theory for what goes on:
>> Eclipse has a tree of class loaders.
>> At the root of the tree are exposed packages.
>> Each bundle is a branch.
>> Packages loaded into one branch create objects with a different
>>runtime type from objects on another branch.
>> Type tests that compile in one branch will fail at runtime because
>>of the invisible class-loader type-dependency.
>>
>>If so in my opinion the equinox story has a hole: when we issue
>>registerSevice the first argument should be some combination of
>>classname and class loader. Then my problem cannot happen I guess.
>>
>>Thanks,
>>John.
>>
>>
>>
>>Simon Kaegi wrote:
>>
>>>Hi John,
>>>
>>>That does sound strange. My guess would have been different class loaders
>>>however maybe something else is going on.
>>>Can you post the contents of an "ss" in the console.
>>>You might also try using the "bundle" (or "b") command to track down
>>>where
>>>your imports are coming from.
>>>
>>>-Simon
>>>
>>>"JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
>>>news:enunp7$hm5$1@utils.eclipse.org...
>>>
>>>
>>>>Ok, I am completely lost. I thought I followed the equinox recipes, but
>>>>I must have missed some ingredients.
>>>>
>>>>In one bundle (er plugin, whatever), I created an HttpServlet (class
>>>>FileSystemServlet). I tell equinox this is a service:
>>>>
>>>> this.bundleContext.registerService(HttpServlet.class.getName (),
>>>>servlet, configuration);
>>>>
>>>>In another bundle I listen for service registrations and sure enough my
>>>>servlet comes along. I grab if from the service reference sr:
>>>>
>>>>Object servlet = bundleContext.getService(sr);
>>>>
>>>>First thing I want to do is use the object as a HttpServlet:
>>>>
>>>>if (servlet instanceof HttpServlet) { ... do great work....
>>>>
>>>>But my servlet fails this test.
>>>>
>>>>The only reason I can come up with is that the HttpServlet interface I
>>>>am using for type testing is loaded by a different class loader from the
>>>>one used when I created the servlet. It can't be so or equinox would
>>>>never work.
>>>>
>>>>Any hints?
>>>>
>>>>John.
>>>
>>>
>>>
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #80615 is a reply to message #80600] |
Wed, 10 January 2007 19:16 |
Simon Kaegi
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
John,
If you're really interested in understanding this I think the best place to
look is the "Module Layer" chapter in the OSGi Spec.
{3.4} in particular deals with the class loading architecture. It's quite
well written and obviously the authoritive source.
---
The other problem you mentioned (the one that started this thread) shouldn't
really be possible as before returning a reference to a service an
"instanceof" check is done. (See BundleContext.getServiceReferences(...) as
that's what ends up getting called)
Is it possible that something else is going on? If not you should log a bug
with a testcase.
-Simon
"JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
news:eo3bl4$ecc$1@utils.eclipse.org...
> Danail Nachev wrote:
>> Hi, John
>>
>> The more correct representation of the class loader hierarchy is a
>> graph. The class loader of one bundle is one node of the graph. If the
>
> Thanks Danail. Unfortunately this explanation only creates more questions
> (with my guesses)
> -- Directed graph? (yes)
> -- No cycles? (yes)
> -- Are all arcs identical? (no, eg what does "imported" mean?)
> -- How is this graph creates (by an ill-defined combination of rules for
> MANIFEST.MF and the registry of eclipse).
>
> Maybe this is all explained somewhere?
>
> I'm beginning to understand that eclipse has evolved beyond plugins, but
> that its tooling, the PDE, has not kept up. The PDE works great for one
> plugin extending eclipse, but its not ready for OSGi and multi-bundle
> development. Getting a clear picture of the class loading/bundle
> story would be a good starting point.
>
> John.
>
>
>> class is from imported package, then between this node and the node of
>> the bundle, which provides the class will be created an arc. Now, the
>> first class loader will delegate the loading to the other class loader.
>> In OSGi it is very important that you don't have duplicate classes or
>> you have to guarantee that this will not cause any problems (like
>> ClassCastException's)
>>
>> In your case it seems that HttpServlet class was loaded by the first
>> bundle from one place. The bundle (second one), which registered the
>> service, has loaded HttpServlet from different place. So, when you
>> retrieve the service in the first bundle, it will different class than
>> the one you expect, because the classes which are used by the two
>> bundles are from different class loaders, although they have the same
>> fully qualified name.
>>
>> Danail
>>
>> JOHN J. BARTON wrote:
>>
>>>Hi Simon. I found my mistake: I had my service-providing plugin
>>>dependent on one HttpServlet class file and the service-listener plugin
>>>dependent upon another one. That's not a good thing ;-). Both plugins
>>>compiled and ran, but the type tests failed at runtime.
>>>
>>>Solving this problem was harder than I expected. I had
>>>org.eclipse.equinox.servlet.api and another plugin called javax.servlet.
>>> Which to pick? I tried org.eclipse.equinox.servlet.api but it failed.
>>>So I tried javax.servlet (2.4); it worked. Just trial and error, no way
>>>to decide this by logic.
>>>
>>>Here's my theory for what goes on:
>>> Eclipse has a tree of class loaders.
>>> At the root of the tree are exposed packages.
>>> Each bundle is a branch.
>>> Packages loaded into one branch create objects with a different
>>>runtime type from objects on another branch.
>>> Type tests that compile in one branch will fail at runtime because
>>>of the invisible class-loader type-dependency.
>>>
>>>If so in my opinion the equinox story has a hole: when we issue
>>>registerSevice the first argument should be some combination of
>>>classname and class loader. Then my problem cannot happen I guess.
>>>
>>>Thanks,
>>>John.
>>>
>>>
>>>
>>>Simon Kaegi wrote:
>>>
>>>>Hi John,
>>>>
>>>>That does sound strange. My guess would have been different class
>>>>loaders
>>>>however maybe something else is going on.
>>>>Can you post the contents of an "ss" in the console.
>>>>You might also try using the "bundle" (or "b") command to track down
>>>>where
>>>>your imports are coming from.
>>>>
>>>>-Simon
>>>>
>>>>"JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
>>>>news:enunp7$hm5$1@utils.eclipse.org...
>>>>
>>>>
>>>>>Ok, I am completely lost. I thought I followed the equinox recipes,
>>>>>but
>>>>>I must have missed some ingredients.
>>>>>
>>>>>In one bundle (er plugin, whatever), I created an HttpServlet (class
>>>>>FileSystemServlet). I tell equinox this is a service:
>>>>>
>>>>> this.bundleContext.registerService(HttpServlet.class.getName (),
>>>>>servlet, configuration);
>>>>>
>>>>>In another bundle I listen for service registrations and sure enough my
>>>>>servlet comes along. I grab if from the service reference sr:
>>>>>
>>>>>Object servlet = bundleContext.getService(sr);
>>>>>
>>>>>First thing I want to do is use the object as a HttpServlet:
>>>>>
>>>>>if (servlet instanceof HttpServlet) { ... do great work....
>>>>>
>>>>>But my servlet fails this test.
>>>>>
>>>>>The only reason I can come up with is that the HttpServlet interface I
>>>>>am using for type testing is loaded by a different class loader from
>>>>>the
>>>>>one used when I created the servlet. It can't be so or equinox would
>>>>>never work.
>>>>>
>>>>>Any hints?
>>>>>
>>>>>John.
>>>>
>>>>
>>>>
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #80660 is a reply to message #80615] |
Thu, 11 January 2007 02:00 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Thanks for the pointer Simon. This document explains how equinox must
work with my plugin. I'm sure with a few days study I could guess at how
to apply it to my problem which is the opposite: how do I work with
equinox. Is there any such reverse document? This one does give a place
of last resort for puzzling stuff out.
I'll pass on making the testcase. I was assured on one of my bug reports
that every eclipse developer has read all documentation and understood
class loading in detail; anyone lesser should not report bugs.
John.
Simon Kaegi wrote:
> John,
>
> If you're really interested in understanding this I think the best place to
> look is the "Module Layer" chapter in the OSGi Spec.
> {3.4} in particular deals with the class loading architecture. It's quite
> well written and obviously the authoritive source.
> ---
> The other problem you mentioned (the one that started this thread) shouldn't
> really be possible as before returning a reference to a service an
> "instanceof" check is done. (See BundleContext.getServiceReferences(...) as
> that's what ends up getting called)
> Is it possible that something else is going on? If not you should log a bug
> with a testcase.
>
> -Simon
>
> "JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
> news:eo3bl4$ecc$1@utils.eclipse.org...
>
>>Danail Nachev wrote:
>>
>>>Hi, John
>>>
>>>The more correct representation of the class loader hierarchy is a
>>>graph. The class loader of one bundle is one node of the graph. If the
>>
>>Thanks Danail. Unfortunately this explanation only creates more questions
>>(with my guesses)
>> -- Directed graph? (yes)
>> -- No cycles? (yes)
>> -- Are all arcs identical? (no, eg what does "imported" mean?)
>> -- How is this graph creates (by an ill-defined combination of rules for
>>MANIFEST.MF and the registry of eclipse).
>>
>>Maybe this is all explained somewhere?
>>
>>I'm beginning to understand that eclipse has evolved beyond plugins, but
>>that its tooling, the PDE, has not kept up. The PDE works great for one
>>plugin extending eclipse, but its not ready for OSGi and multi-bundle
>>development. Getting a clear picture of the class loading/bundle
>>story would be a good starting point.
>>
>>John.
>>
>>
>>
>>>class is from imported package, then between this node and the node of
>>>the bundle, which provides the class will be created an arc. Now, the
>>>first class loader will delegate the loading to the other class loader.
>>>In OSGi it is very important that you don't have duplicate classes or
>>>you have to guarantee that this will not cause any problems (like
>>>ClassCastException's)
>>>
>>>In your case it seems that HttpServlet class was loaded by the first
>>>bundle from one place. The bundle (second one), which registered the
>>>service, has loaded HttpServlet from different place. So, when you
>>>retrieve the service in the first bundle, it will different class than
>>>the one you expect, because the classes which are used by the two
>>>bundles are from different class loaders, although they have the same
>>>fully qualified name.
>>>
>>>Danail
>>>
>>>JOHN J. BARTON wrote:
>>>
>>>
>>>>Hi Simon. I found my mistake: I had my service-providing plugin
>>>>dependent on one HttpServlet class file and the service-listener plugin
>>>>dependent upon another one. That's not a good thing ;-). Both plugins
>>>>compiled and ran, but the type tests failed at runtime.
>>>>
>>>>Solving this problem was harder than I expected. I had
>>>>org.eclipse.equinox.servlet.api and another plugin called javax.servlet.
>>>>Which to pick? I tried org.eclipse.equinox.servlet.api but it failed.
>>>>So I tried javax.servlet (2.4); it worked. Just trial and error, no way
>>>>to decide this by logic.
>>>>
>>>>Here's my theory for what goes on:
>>>> Eclipse has a tree of class loaders.
>>>> At the root of the tree are exposed packages.
>>>> Each bundle is a branch.
>>>> Packages loaded into one branch create objects with a different
>>>>runtime type from objects on another branch.
>>>> Type tests that compile in one branch will fail at runtime because
>>>>of the invisible class-loader type-dependency.
>>>>
>>>>If so in my opinion the equinox story has a hole: when we issue
>>>>registerSevice the first argument should be some combination of
>>>>classname and class loader. Then my problem cannot happen I guess.
>>>>
>>>>Thanks,
>>>>John.
>>>>
>>>>
>>>>
>>>>Simon Kaegi wrote:
>>>>
>>>>
>>>>>Hi John,
>>>>>
>>>>>That does sound strange. My guess would have been different class
>>>>>loaders
>>>>>however maybe something else is going on.
>>>>>Can you post the contents of an "ss" in the console.
>>>>>You might also try using the "bundle" (or "b") command to track down
>>>>>where
>>>>>your imports are coming from.
>>>>>
>>>>>-Simon
>>>>>
>>>>>"JOHN J. BARTON" <johnjbarton@johnjbarton.com> wrote in message
>>>>>news:enunp7$hm5$1@utils.eclipse.org...
>>>>>
>>>>>
>>>>>
>>>>>>Ok, I am completely lost. I thought I followed the equinox recipes,
>>>>>>but
>>>>>>I must have missed some ingredients.
>>>>>>
>>>>>>In one bundle (er plugin, whatever), I created an HttpServlet (class
>>>>>>FileSystemServlet). I tell equinox this is a service:
>>>>>>
>>>>>> this.bundleContext.registerService(HttpServlet.class.getName (),
>>>>>>servlet, configuration);
>>>>>>
>>>>>>In another bundle I listen for service registrations and sure enough my
>>>>>>servlet comes along. I grab if from the service reference sr:
>>>>>>
>>>>>>Object servlet = bundleContext.getService(sr);
>>>>>>
>>>>>>First thing I want to do is use the object as a HttpServlet:
>>>>>>
>>>>>>if (servlet instanceof HttpServlet) { ... do great work....
>>>>>>
>>>>>>But my servlet fails this test.
>>>>>>
>>>>>>The only reason I can come up with is that the HttpServlet interface I
>>>>>>am using for type testing is loaded by a different class loader from
>>>>>>the
>>>>>>one used when I created the servlet. It can't be so or equinox would
>>>>>>never work.
>>>>>>
>>>>>>Any hints?
>>>>>>
>>>>>>John.
>>>>>
>>>>>
>>>>>
>
>
|
|
| | |
| Re: When is an HttpServlet not an HttpServlet? [message #81007 is a reply to message #80992] |
Sat, 13 January 2007 02:19 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
In trying to isolate the problem I noticed something odd.
This is the MANIFEST.MF for org.eclipse.equinox.servlet.api:
Manifest-Version: 1.0
Bundle-Name: %pluginName
Bundle-Vendor: %providerName
Bundle-ManifestVersion: 2
Bundle-Localization: plugin
Bundle-SymbolicName: org.eclipse.equinox.servlet.api
Export-Package: javax.servlet; version=2.3,javax.servlet.http; version
=2.3,javax.servlet.jsp; version=1.2,javax.servlet.jsp.resources; vers
ion=1.2,javax.servlet.jsp.tagext; version=1.2,javax.servlet.resources
; version=2.3
Bundle-Version: 1.0.0.v20060601
My MANIFEST.MF says:
Require-Bundle:
....
org.eclipse.equinox.servlet.api,
javax.servlet
Eclipse-LazyStart: true
Bundle-ClassPath: bin/,
.,
lib/mozdom4java-1.0/mozdom4java.jar,
lib/servlets-default.jar
Export-Package: com.ibm.research.ajaxproxy
Import-Package: javax.servlet;version="2.4.0"
So my guess is that this is Tom's scenario with
- Bundle servlet.api exports HttpServlet; version=2.3
- Bundle javax.servlet exports HttpServlet; version=2.4
- Bundle My imports HttpServlet; version=2.3 from Bundle servlet.api
- Bundle My registers a service MyHttpServlet
- Bundle Y imports HttpServlet; version=2.4 from Bundle javax.servlet
- Bundle Y looks for a service MyHttpServlet
And finds none.
For me this is clearly a bug: no compile or run time warnings and the
code fails, only considerable analysis uncovers the problem. Is a test
case useful?
John.
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #81108 is a reply to message #81007] |
Mon, 15 January 2007 15:23 |
Thomas Watson
Messages: 503
Registered: July 2009 |
Senior Member |
|
|
JOHN J. BARTON wrote:
> In trying to isolate the problem I noticed something odd.
>
> This is the MANIFEST.MF for org.eclipse.equinox.servlet.api:
>
> Manifest-Version: 1.0
> Bundle-Name: %pluginName
> Bundle-Vendor: %providerName
> Bundle-ManifestVersion: 2
> Bundle-Localization: plugin
> Bundle-SymbolicName: org.eclipse.equinox.servlet.api
> Export-Package: javax.servlet; version=2.3,javax.servlet.http; version
> =2.3,javax.servlet.jsp; version=1.2,javax.servlet.jsp.resources; vers
> ion=1.2,javax.servlet.jsp.tagext; version=1.2,javax.servlet.resources
> ; version=2.3
> Bundle-Version: 1.0.0.v20060601
>
> My MANIFEST.MF says:
> Require-Bundle:
> ...
> org.eclipse.equinox.servlet.api,
> javax.servlet
> Eclipse-LazyStart: true
> Bundle-ClassPath: bin/,
> .,
> lib/mozdom4java-1.0/mozdom4java.jar,
> lib/servlets-default.jar
> Export-Package: com.ibm.research.ajaxproxy
> Import-Package: javax.servlet;version="2.4.0"
>
> So my guess is that this is Tom's scenario with
>
> - Bundle servlet.api exports HttpServlet; version=2.3
> - Bundle javax.servlet exports HttpServlet; version=2.4
> - Bundle My imports HttpServlet; version=2.3 from Bundle servlet.api
> - Bundle My registers a service MyHttpServlet
> - Bundle Y imports HttpServlet; version=2.4 from Bundle javax.servlet
> - Bundle Y looks for a service MyHttpServlet
>
> And finds none.
>
> For me this is clearly a bug: no compile or run time warnings and the
> code fails, only considerable analysis uncovers the problem. Is a test
> case useful?
>
> John.
Your manifest uses Require-Bundle to get two versions of javax.servlet
from two different bundles
> Require-Bundle:
> ...
> org.eclipse.equinox.servlet.api,
> javax.servlet
I can think of no need to require both.
You also use Import-Package to get the javax.servlet package. This ends
up being a pretty big mess of the javax.servlet class space. In OSGi
Import-Package dependencies override any packages you get with with
Require-Bundle. You import a higher version of javax.servlet than what
is offered by org.eclipse.equinox.servlet.api (Import-Package:
javax.servlet;version="2.4.0"). This forces this package to be wired to
the ones offered by the javax.servlet bundle (I'm assuming this is the
orbit javax.servlet bundle that offers version 2.4 of the API).
Now your going to say, but shouldn't OSGi warn me of this crazy
situation and prevent me from running? The answer is yes, but we are
missing a key ingredient to making this work. That is the "uses"
directive of Export-Package statements. This directive is helpful in
directing the framework to resolve a consistent class space. See the
OSGi R4 specification for the details (also bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167968 would be interesting).
As for bug 169396, Not really sure how that translated into "I was
assured on one of my bug reports that every eclipse developer has read
all documentation and understood class loading in detail; anyone lesser
should not report bugs". I can say that I don't pretend to know every
little detail about class loading and it really REALLY helps out when
the community can work with the Equinox team to sort through any class
loading issues that the core platform may have.
Thanks for you time.
Tom.
|
|
|
| Re: When is an HttpServlet not an HttpServlet? [message #81152 is a reply to message #81108] |
Mon, 15 January 2007 21:50 |
John J. Barton
Messages: 311
Registered: July 2009 |
Senior Member |
|
|
Thanks Tom. I wonder if the introduction of more features in the
MANIFEST.MF is sufficient to solve these problems. (I am including
the one described here with the one from bug 169396 and any number
of posts to this newsgroup and eclipse.platform). I think the PDE needs
new support for dealing with equinox.
Equinox operates on a key assumption: bundles share a classloader node
common to all plugins. This public-interface node is the reference for
the class names used in registering services. But the PDE has no way to
view this node nor to manipulate its contents. More control over the
MANIFEST.MF for each individual plugin won't help unless I can
understand how the plugins fit together to create an application.
Even within the current PDE the user interface is not consistent with
the MANIFEST.MF, but more important the meaning of the possible
operations is unclear. The terms "import", "export", "dependent",
"classpath", "visible", "hidden", and "lazy" are all relative to a
model that is not expressed clearly. Or to be precise its not clear
to me so I assume that it is not clear to many users.
I believe that if the model were clearly explained then the PDE could be
changed to help developers make the right choices. Well assuming the
PDE team is willing.
John.
Tom Watson wrote:
> JOHN J. BARTON wrote:
>
>> In trying to isolate the problem I noticed something odd.
>>
>> This is the MANIFEST.MF for org.eclipse.equinox.servlet.api:
>>
>> Manifest-Version: 1.0
>> Bundle-Name: %pluginName
>> Bundle-Vendor: %providerName
>> Bundle-ManifestVersion: 2
>> Bundle-Localization: plugin
>> Bundle-SymbolicName: org.eclipse.equinox.servlet.api
>> Export-Package: javax.servlet; version=2.3,javax.servlet.http; version
>> =2.3,javax.servlet.jsp; version=1.2,javax.servlet.jsp.resources; vers
>> ion=1.2,javax.servlet.jsp.tagext; version=1.2,javax.servlet.resources
>> ; version=2.3
>> Bundle-Version: 1.0.0.v20060601
>>
>> My MANIFEST.MF says:
>> Require-Bundle:
>> ...
>> org.eclipse.equinox.servlet.api,
>> javax.servlet
>> Eclipse-LazyStart: true
>> Bundle-ClassPath: bin/,
>> .,
>> lib/mozdom4java-1.0/mozdom4java.jar,
>> lib/servlets-default.jar
>> Export-Package: com.ibm.research.ajaxproxy
>> Import-Package: javax.servlet;version="2.4.0"
>>
>> So my guess is that this is Tom's scenario with
>>
>> - Bundle servlet.api exports HttpServlet; version=2.3
>> - Bundle javax.servlet exports HttpServlet; version=2.4
>> - Bundle My imports HttpServlet; version=2.3 from Bundle servlet.api
>> - Bundle My registers a service MyHttpServlet
>> - Bundle Y imports HttpServlet; version=2.4 from Bundle javax.servlet
>> - Bundle Y looks for a service MyHttpServlet
>>
>> And finds none.
>>
>> For me this is clearly a bug: no compile or run time warnings and the
>> code fails, only considerable analysis uncovers the problem. Is a
>> test case useful?
>>
>> John.
>
>
> Your manifest uses Require-Bundle to get two versions of javax.servlet
> from two different bundles
>
> > Require-Bundle:
> > ...
> > org.eclipse.equinox.servlet.api,
> > javax.servlet
>
> I can think of no need to require both.
>
> You also use Import-Package to get the javax.servlet package. This ends
> up being a pretty big mess of the javax.servlet class space. In OSGi
> Import-Package dependencies override any packages you get with with
> Require-Bundle. You import a higher version of javax.servlet than what
> is offered by org.eclipse.equinox.servlet.api (Import-Package:
> javax.servlet;version="2.4.0"). This forces this package to be wired to
> the ones offered by the javax.servlet bundle (I'm assuming this is the
> orbit javax.servlet bundle that offers version 2.4 of the API).
>
> Now your going to say, but shouldn't OSGi warn me of this crazy
> situation and prevent me from running? The answer is yes, but we are
> missing a key ingredient to making this work. That is the "uses"
> directive of Export-Package statements. This directive is helpful in
> directing the framework to resolve a consistent class space. See the
> OSGi R4 specification for the details (also bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=167968 would be interesting).
>
> As for bug 169396, Not really sure how that translated into "I was
> assured on one of my bug reports that every eclipse developer has read
> all documentation and understood class loading in detail; anyone lesser
> should not report bugs". I can say that I don't pretend to know every
> little detail about class loading and it really REALLY helps out when
> the community can work with the Equinox team to sort through any class
> loading issues that the core platform may have.
>
> Thanks for you time.
>
> Tom.
|
|
|
Goto Forum:
Current Time: Fri Apr 26 14:18:41 GMT 2024
Powered by FUDForum. Page generated in 0.04035 seconds |
] 
Search
Help
Register
Login
Home
