XPCom components with Java on mozilla, explained

"mperrone" <[email protected]>
Newsgroups gmane.comp.mozilla.devel.java
Message-ID <LOELLBDICOAGKLINAHBIKEBLCEAA.mperrone__951.094509992068$1144790985$gmane$org@certisign.com.br>
For Carles and anyone else interested:

It seems that JavaXPCOM is working fine for components running over
XulRunner. Good.
Though, Javier Pedemonte said the JavaXPCOM is not 100% ready for use in
mozilla (time is money, you know).
As a result (if I well understood), currently the component´s methods
can´t be called directly from something outside the component (following
xpidl defined interface), if under mozilla/firefox environment.
Still, you will be able to register java methods as handlers for specific
events (as described on attached message).

---

Meanwhile, I found "Java Firefox Extension": nothing more than a skeleton
that demonstrates a tricky way of enabling a javascript component to
communicate with Java using component side liveconnect. So a javascript
component will talk to javascript and can be a bridge.
Normally, liveconnect is only available on browser javascript side.
The "Java Firefox Extension" also shows that if the client (who uses the
component) is also javascript, then real java objects from component side
can be passed to client side. This is possible by accessing the
wrappedJSobject field from a javascript component from a javascript
client.

Though, "Java Firefox Extension" also does not make java acessible through
XPIDL interface. When wrappedJSobject is used, methods will be called with
java syntax. A property, for example, will be set by calling
"setMyProperty(value)" instead of "MyProperty = value".

Finally, I added a final trick myself so that Java objects would be used
on javascript client side just as defined on XPIDL.
I had to redefine all and every class method and property on javascript,
so that I got a javascript object encapsulating a java object. Example:

function Signer( signer ) {
        this.wrappedJSObject = this;     // old trick
        this.wrappedJavaObject = signer; // + my trick
}

Signer.prototype = {
     //attribute ICertificate Certificate;
     get Certificate ()
     {
       try
       {
         return new Certificate(
           this.wrappedJavaObject.getCertificate() );
       } catch (e) { handleException(e); }
     },
     set Certificate (val)
     {
       try
       {
         return this.wrappedJavaObject
           .setCertificate(val.wrappedJavaObject);
       } catch (e) { handleException(e); }
     },

    //readonly attribute long Count;
    get Count() {
      try { return this.wrappedJavaObject.getCount(); }
      catch (e) { handleException(e); }
    },

    //void Load (
    //    in string FileName,
    //    in string Password );
    Load : function (FileName, Password) {
      try { return this.wrappedJavaObject.load(FileName, Password); }
      catch (e) { handleException(e); }
    },

    QueryInterface : function (iid)
    {
       if (!iid.equals(Components.interfaces.ISigner) &&
           !iid.equals(Components.interfaces.ISigner2) &&
           !iid.equals(Components.interfaces.nsISupports) )
           throw Components.results.NS_ERROR_NO_INTERFACE;
           return this;
       }
    }
};

This class folows a pattern. Exept when native values are returned (such
as long or String), wrapping an unwrapping is required. As shown above,
this is done by calling the appropriate javascript wrapper (new
Certificates...) or passing the wrapped java object
(val.wrappedJavaObject).

A link to this javascript class is done by adding an extra else-if on main
component´s QueryInterface method:

XPCapicomComponent.prototype.QueryInterface = function(iid) {
        ...
	else if ( iid.equals(Components.interfaces.ISigner) ||
	iid.equals(Components.interfaces.ISigner2) )
	{
		classObj = new Signer(
			this._instantiate( className + ".Signer") );
	}
        ...
}

The _instantiate method will use liveconnect.

The handleException method can discover the exception type by calling
"e.getClass().getCanonicalName()".

Currently I am being compatible with JavaXPCom, so that my component will
be freed from this javascript bridge in near future, but I am not really
using JavaXPCom right now.

-----Mensagem original-----
Assunto: error in mozilla.initXPCOM method


Hello.
My Name is Carles Canellas, and I'm a member of a IT enterprise from
Spain.
Im writing you 'cause I've found this page in internet
http://article.gmane.org/gmane.comp.mozilla.devel.java/2082

in which you ask about help in a initXPCOM in a mixed system with
liveconnect and java xpcom.
We need to do the same, a mixed system with xulrunner, java xpcom and
liveconnect, the same way you do, and we have the same problem you said in
the mail to Javier Pedemonte.

org.mozilla.xpcom.XPCOMException: Failure in initXPCOM  (0x80004005)

I will be very happy if you can point how you resolved that issue, or if
mix java xpcom with liveconnect can't be done.

Thanks in advance,
Carles Canellas.

_______________________________________________
dev-tech-java mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-java
(unnamed) (message/rfc822, 3.7 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.