Closed Bug 45029 Opened 24 years ago Closed 23 years ago

remove Component manager contractID

Categories

(Core :: XPCOM, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla1.0

People

(Reporter: braden, Assigned: dougt)

References

Details

(Keywords: arch)

While a progID for the component manager has been defined
(<http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsComponentManagerUtils.h#61>),
it doesn't look like this ever gets registered. Thus attempts to get this
service via its progID fail.
*** Bug 44979 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Depends on: 46768
I am trying to figure out which XPCOM methods need to be exported.  I assume 
that this should be the only method exported from XPCOM to get the component 
manager, right?  If so, I nominate this for nsbeta3.  If not, then it doesn't 
seem very important.
Keywords: nsbeta3
Whiteboard: [nsbeta3+]
Would whoever marked this nsbeta3+ please supply a simple use case why this 
particular progid needs to be registered in component manager?
Could you please explain why you want to get the component manager via its 
progid?  I can think of a reason or two you might want to do this, but it seems 
that the component manager is readily available without being registered.  Might 
the real solution not be just delete the definition?

It is also not clear that this is a nsbeta3 bug.
nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
Edward: Welcome to xpcom!
Status: ASSIGNED → NEW
QA Contact: leger → rayw
Target Milestone: M18 → mozilla1.0
Once again... attempting to reassign from Ray to Edward.
Assignee: rayw → kandrot
Keywords: arch
Since rayw's comments on 2000-08-31, there was no response as to why this is 
needed.  I agree, and am therefore closing this bug.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: nsbeta3
QA Contact: rayw → scc
Resolution: --- → INVALID
Whiteboard: [nsbeta3-]
Edward, rayw did not suggest that this bug was invalid. Rather, he suggested
that a possible solution would be deleting the definition of the contractID.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
To be clear, I don't see any problem with rayw's recommendation. But it is silly
to have a contractID defined that never gets registered.
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Status: REOPENED → NEW
Target Milestone: mozilla1.0 → ---
Target Milestone: --- → mozilla1.0
Keywords: mozilla1.0
I am marking this as wont fix.  Currently, if you have the service manager, you
should be able to qi it to the component manager.

Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WONTFIX
WONTFIX doesn't make sense here. If the verdict is, as you say, that the
contractID should not exist, then the fix is simply to eliminate it. Keeping the
contractID around when it's never registered is just confusing.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Component manager progID never registered → Component manager contractID never registered
agreed.
Summary: Component manager contractID never registered → remove Component manager contractID
This has been removed.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.