nsIServiceManager.h and nsIComponentManager.h contains implementation code that makes inclusion into external component code (e.g. Java Plugin) problematic.
I've assigned it to myself for further investigation. CC'ing Stanley.
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.
Assignee: jeff.dyer → dp
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → M16
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.
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.
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.
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.
Target Milestone: M16 → M20
Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on sabbatical. rayw is now default assignee for these components.
Assignee: dp → rayw
Status: ASSIGNED → NEW
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.
Assigning rest of xpcom stuff to myself (from Ray).
Assignee: rayw → warren
Status: ASSIGNED → NEW
Target Milestone: M20 → mozilla1.0
Hi Warren, ANy chance of getting this in the trunk?
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: kandrot → scc
Target Milestone: mozilla1.0 → ---
reassign all kandrot xpcom bug.
Assignee: kandrot → 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..
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.