28660 - Interface headers contain implementation

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Jeff Dyer]

nsIServiceManager.h and nsIComponentManager.h contains implementation code that 
makes inclusion into external component code (e.g. Java Plugin) problematic.

Comment 1

[Jeff Dyer]

I've assigned it to myself for further investigation. CC'ing Stanley.

Comment 2

[Jeff Dyer]

Attachment: Fix

Comment 3

[Jeff Dyer]

Plugins must include nsIServiceManager.h and nsIComponentManager.h to get the 
corresponding interface definitions. Unfortunately, these files contain 
non-interface definitions which depend on implementation code outside of the 
included headers. There are two obvious solutions: 1. for plugins to link in as 
much of mozilla as is necessary to resolve all the external references; and 2. 
the interface header files to be restructured to contain interface definitions, 
with concrete classes, etc. included separately. I have posted a patch that does 
basically this, but without moving any code. I've wrapped the code with 
implementation dependencies in #ifndef USE_PURE_COM_INTERFACES ... #endif 
statements so that plugins that want just the interfaces can get only them by 
adding the statement #define USE_PURE_COM_INTERFACES before relevant include 
statements.

I'm reassigning to the module owner for review.

Comment 4

[edburns]

DP, do you have any status on this?

I've talked to Shaver about the matter of link-time dependencies on xpcom.lib 
and he feels it's downright impossible to avoid them, considering nsCOMPtr and 
all.  However, I still feel that nsServiceManager and nsComponentManager 
shouldn't be visible to #includers of nsIServiceManager, etc.

Can you please post some status, or at least take this out of the UNCONFIRMED 
state?

Thanks,

Ed

Comment 5

[Suresh Duddi (gone)]

Sorry. My query for looking at bugs missed all UNCONFIRMED bugs.

Shaver is right; we got to be clear on what you are trying to achieve. Can you 
be more clear on this.

Comment 6

[Suresh Duddi (gone)]

I dont see either of the nsIServiceManager.h or nsIComponentManager.h including
nsServiceManager.h and nsComponentManager.h  So I dont understand what you want
fixed here.

Comment 7

[edburns]

nsIComponentManager.h includes nsComponentManagerUtils.h, which declares
nsComponentManager.  

http://lxr.mozilla.org/mozilla/source/xpcom/components/nsIComponentManager.idl#98
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsComponentManagerUtils.h#68

So this is still a problem.

Please post if you need more info.

Comment 8

[Suresh Duddi (gone)]

I understand. Moving definition of the global nsComponentManager and
nsServiceManager out of the interface header paths is going to be costly tree
exercise. Nevertheless, I agree it is a good thing to do.

Comment 9

[leger]

Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on 
sabbatical.  rayw is now default assignee for these components.

Comment 10

[Ray Whitmer]

I hadn't realized before now that there was a patch with this.  I just got a 
message from Sun indicating a reliance on this and a need to get it fixed for 
OJI by beta3.

Comment 11

[Warren Harris]

Assigning rest of xpcom stuff to myself (from Ray).

Comment 12

[edburns]

Hi Warren, 

ANy chance of getting this in the trunk?

Comment 13

[Asa Dotzler [:asa]]

reasigning warren bugs to default component owners.

Comment 14

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 15

[Doug Turner (:dougt)]

Frozen interfaces will not have any implementation code unless completely
needed.  We are also wrapping this code with a MOZ_STRICT_API similar to what
you are suggesting.  

Marking this bug fixed since our standard operating procedure is to remove
implementation code from frozen iterfaces..