343039 - expose XRE_main

Status: RESOLVED WONTFIX

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Michal Ceresna]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 pango-text
Build Identifier: 

separated from bug #342691

Reproducible: Always

Comment 1

[Michal Ceresna]

Attachment: expose XRE_main

This patch makes available the method XRE_main to Java embedders.

It allows to correctly start XUL application from java. See the attached
testcase which launches ChatZilla.

The code from
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM
does not worl if the XUL application provides own components or extensions.

Note, that the XRE_main method itself initializes XPCOM, so I had to add
some help methods (initJavaXPCOM, shutdownJavaXPCOM) to initialize only
the javaXPCOM layer.

Comment 2

[Michal Ceresna]

Attachment: testcase

This patch makes available the method XRE_main to Java embedders.

It allows to correctly start XUL application from java. See the attached
testcase which launches ChatZilla.

The code from
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM
does not worl if the XUL application provides own components or extensions.

Note, that the XRE_main method itself initializes XPCOM, so I had to add
some help methods (initJavaXPCOM, shutdownJavaXPCOM) to initialize only
the javaXPCOM layer.

Comment 3

[Michal Ceresna]

> That's a different issue and should be in a different bug... running XRE_main
> from Java is "interesting", but I'm not convinced how useful it is in the real
> world

This is the scenario I use it for:

An XUL application which operates as slave for my Java application.

The application has a JS (IDL) component which serves as a gateway and
is I access it via Java interface thanks to javaxpcom.

I send there commands such as "load", "openTab" etc. and once loaded 
I receive back nsIDOMDocument(s) which are used for further processing.

> since XRE_main is synchronous and Java wouldn't have control of the
> eventloop.
ATM, I use thread proxy (nsIProxyObjectManager). 
Other option could be e.g. to add new GSource* into gtk event loop.


> I receive back nsIDOMDocument(s) which are used for further processing.
processing of the nsIDOMDocument(s) is quite intensive, I'm running some
machine learning (ML) algorithms on it. Therefore, I need to run mozilla
in-process.

The computation works as a smart crawler doing something similiar as:

load document
(ML processing)
choose link to follow
(ML processing)
return back
(ML processing)
choose other link to follow

Comment 4

[Michal Ceresna]

no response :((

Ideal solution would be to introduce in the public xulrunner api two methods XRE_start, XRE_shutdown. Then XRE_main would look like:
XRE_Main() {
  XRE_Start();
  //spin event loop here
  appShell->Run();
  XRE_Shutdown();
}

This would allow embeders to initialize the xulrunnner and spin the event loop by embedding application.

If I would would volunteer to implement such patches for XULRunner API
and javaxpcom would there be a willingness to merge it in? :)

On java embedding mailing list, already several other people asked
how to run extensions under java-embedding application and this patch
would be a solution for that.

Comment 5

[Benjamin Smedberg]

Please make design proposals in the mozilla.dev.platform newsgroup. I'm pretty sure that the "embedder in charge of eventloop" and "toolkit in charge of eventloop" cases have to be handled very differently (as they are by the current XRE_main and XRE_InitEmbedding APIs). I don't think there is going to be a good way for embedding applications to use the builtin extension-manager and auto-update functionality provided by XRE_main.

Comment 6

[Mike Hommey [:glandium]]

JavaXPCOM was removed in bug 648593.