10561 - Component manager takes paths for granted.

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[edburns]

In trying to embed mozilla in java, we have run into the problem where the
registry cannot be opened due to the fact that mozilla uses the path of the
current binary to find the components.reg file and the components directory.
To illustrate the problem, I would suggest making the following modifications:

In xpcom\components\nsRegistry.cpp, in
nsRegistry::OpenWellKnownRegistry(), right before the line

    if (foundReg == PR_FALSE) {
        return NS_ERROR_REG_BADTYPE;
    }

add

printf("debug: edburns: OpenWellKnownRegistry(): %s\n",
       registryLocation->GetCString());

Then, in xpcom/reflect/xptinfo/src/nsInterfaceInfoManager.cpp, right
before

        for (nsDirectoryIterator i(sysdir); i.Exists(); i++) {

Add

printf("debug: edburns: initInterfaceTables(): %s\n",
       sysdir.GetCString());

This should give you the directory in which mozilla looks for the
components.reg file and components directory.  The problem is that when the
current binary is JAVA.EXE (or anything other than apprunner in the bin
directory) the registry is not found.

This is causing the wrapper project (and any other embedding project whose
binary doesn't live in dist\*\bin) to have to copy the components.reg file and
the components directory to the above printed out directory.

Comment 1

[Suresh Duddi (gone)]

We went back on forth in where to put the components registry. For mozilla,
putting it along with the executable and having it updated  only at install time
is the way we are going.

I see your issue. Where is the components registry in you senario ? Rather where
would you like to have it.

Comment 2

[edburns]

dp wrote:

> We went back on forth in where to put the components registry. For mozilla,
> putting it along with the executable and having it updated  only at install
> time is the way we are going.

> I see your issue. Where is the components registry in you senario ?
> Rather where would you like to have it.

We would like to use "the real" components registry.  That is, we don't plan on
having our own registry, at this point, I'd rather just use yours.  So, can you
modify the code so that it uses something other than the directory of the
executable to find the registry file?

Comment 3

[drapeau]

How about having the component registry look in a standard place for components,
in the same manner that the Plug-in code tries to look in a standard place for
components?  For example, examining the value of the variable MOZILLA_FIVE_HOME
and using that directory as a starting place from which to find other components
would help.

By the way, on the Windows platform, the Mozilla plugin code (class
nsPluginsDir,
file /export/home/drapeau/mozilla/modules/plugin/nglsrc/nsPluginsDirWin.cpp)
tries to find plugins first in the place where the executable is.  If that
fails, the code then looks in where it thinks Netscape is installed.

The Solaris implementation of the same thing tries to examine the
MOZILLA_FIVE_HOME environment variable.  If the component registry did something
like this, I think Ed's problem would be addressed sufficiently.

By the way, the Plugins source uses a class called "nsSpecialSystemDirectory",
which I think could be augmented to provide just the kind of functionality
I'm talking about.  Instead of using the enum value
"nsSpecialSystemDirectory::OS_CurrentProcessDirectory", there could be a new
enum value "nsSpecialSystemDirectory::OS_BrowserBaseDirectory" or something like
that which would indicate where the browser was installed, and serve as the
starting point for searching for plugins, components, etc.

Does this line of reasoning seem reasonable?  Do-able?

Comment 4

[Suresh Duddi (gone)]

Ed, when you say "I would like to use yours", there is a big perception problem
with "yours".

This is XPCOM loading components. Your java app somehow has xpcom in the same
process space. In the absense of a component registry that is global to the
machine, there is no other "yours" other than the process itself.

Refer to the component-registration document:

http://lxr.mozilla.org/seamonkey/source/xpcom/doc/xpcom-component-registration.html

Comment 5

[edburns]

dp wrote:

> This is XPCOM loading components. Your java app somehow has xpcom in the same
> process space. In the absense of a component registry that is global to the
> machine, there is no other "yours" other than the process itself.

> Refer to the component-registration document:

So in this document, you say:

> The embedding procedure should create a App-Component-Reqistry for the
> embedding application that should contain all the components from
> different apps this app would like to use.

Do you mean that the java webclient cannot rely on the installed mozilla's
registry?  Are you saying we must create our own?  Has this been tested?

Ed

Comment 6

[Suresh Duddi (gone)]

Component registry does relative paths now.

The last part is to let NS_InitXPCOM() to take a component regsitry location and
make nsSystemSpecialDirectory to return appropriate values. Ed is working on the
code. Reassigning to Ed Burns.

Ed creat an attachment once you are done and reassign to me.

Comment 7

[edburns]

Attachment sent via email to dp.

Comment 8

[Suresh Duddi (gone)]

Added the extra parameters to NS_InitXPCOM().

Ed Burns would be the right person to verify this bug. Ed, the process of
verification is
1. TEST to make sure the concern is addressed
2. Mark the bug verified.

Comment 9

[edburns]

I tried to test verify this fix, but came across two more bugs, both of which I
posted patches to fix.  15132 has been fixed, but 14891 is still pending.