Add XPCOM support for per application component registry

RESOLVED FIXED in mozilla1.1alpha

Status

()

Core
XPCOM
RESOLVED FIXED
17 years ago
16 years ago

People

(Reporter: Chak Nanga, Assigned: Chak Nanga)

Tracking

({topembed})

Trunk
mozilla1.1alpha
x86
All
topembed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [driver:scc])

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

17 years ago
This feature is needed to support MRE based embedding applications. The changes
involve the following:

1. Modify ComponentManager to look for XPCOM components in both the application
specific components directory and in the MRE specific component directory.
The component.reg file must be created in the mre *application*'s directory

2. Modify xptiInterfaceInfoManager to look for .xpt files in both the
application specific components directory and in the MRE specific component
directory. The xpti.dat file must be created in the mre *application*'s
"components" directory
(Assignee)

Updated

17 years ago
Blocks: 129573
(Assignee)

Comment 1

17 years ago
Created attachment 74335 [details] [diff] [review]
Patch to create app specific component registry

This patch addresses the two issues mentioned above in the intial bug report.

John : Doug's taken a look at this earlier. Could you please take a look at the
xptiInterfaceInfoManager changes and comment?

Thanks
Chak
(Assignee)

Comment 2

17 years ago
Hi John: 

Could you please review the patch above when you get a chance...

Thanks
Chak
Status: NEW → ASSIGNED

Comment 3

17 years ago
pushing milestone out based on requirement feedback from Chak and Jud.
Target Milestone: --- → mozilla1.1alpha

Comment 4

17 years ago
We tried using the patch. However, we could not get into a situation where
the xpti.dat in the MRE application components dir will contain the infromation
about the xpt files in Mozilla components dir. 

The second requirement in the bug description is "The xpti.dat file must be
created in the mre *application*'s "components" directory". This is not happening.


(Assignee)

Comment 5

16 years ago
Created attachment 85820 [details] [diff] [review]
Updated patch to work with the latest trunk...

Doug : We need to discuss the ordering issue as hilited below in the attached
patch:

+    
+    // Ordering is VERY important here and should be discussed.
+    // xxx
Attachment #74335 - Attachment is obsolete: true

Comment 6

16 years ago
Comment on attachment 85820 [details] [diff] [review]
Updated patch to work with the latest trunk...

remove that comment.  we discussed it.	with that, r=
Attachment #85820 - Flags: review+
(Assignee)

Comment 7

16 years ago
Created attachment 86502 [details] [diff] [review]
Updated patch to address dougt's comments above

Added some comments as well...
Attachment #85820 - Attachment is obsolete: true
(Assignee)

Comment 8

16 years ago
Comment on attachment 86502 [details] [diff] [review]
Updated patch to address dougt's comments above

Carrying over dougt's r=
Attachment #86502 - Flags: review+
Comment on attachment 86502 [details] [diff] [review]
Updated patch to address dougt's comments above

Please use sMRE_Directory and such, like you do with sOS_*.  With that change,
sr=shaver.
Attachment #86502 - Flags: superreview+
(Assignee)

Comment 10

16 years ago
Landed patch on the trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

16 years ago
*** Bug 130880 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Whiteboard: [driver:scc]

Comment 12

16 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed

Updated

16 years ago
Blocks: 176349
You need to log in before you can comment on or make changes to this bug.