Calling Java - [xpconnect wrapped nsIFile]ReferenceError: java is not defined

[markus]

Hi,

actually I am writing on an extension for websecurify.

Inside of the JS component I would like to calling Java and own
implementations:

Components.utils.import('resource://gre/modules/XPCOMUtils.jsm');
...
var classLoaderJarpath = ...;
var myJarpath = ...;
var urlArray = []; // Build a regular JavaScript array (LiveConnect
will auto-convert to a Java array)
urlArray[0] = new java.net.URL(myJarpath);
urlArray[1] = new java.net.URL(classLoaderJarpath);
var cl = java.net.URLClassLoader.newInstance(urlArray);

Unfortunately I get this error message:
"[xpconnect wrapped nsIFile]ReferenceError: java is not defined."

What do I have to do for calling Java classes from an extension ?

Thank you and best regards,
Markus

[pdp]

This is how you usually do it. I don't know of any other way. However,
I am not quite sure what you are exactly trying to do. When I know
more I think I will be able to provide more feedback.

Although Java is great, it might be easier for you to integrate your
java code as a separate jar file which runs independent from
xulrunner.

[markus]

Thank you for the short reply.

I have written a Java component that creates pdf docs on base of
websecurify xml output structure with iText pdf library.
So I intend to write a PDF report extension that calls my Java
component inside of the WeaponryReportXXXExporter.js

Apart from that, what do you mean with:

"it might be easier for you to integrate your java code as a separate
jar

file which runs independent from xulrunner." ?

Many thanks

[pdp]

This will be quite nice feature. I've been thinking to integrate
something similar for a long time but what I have in mind is to use
either a JavaScript pdf writer (yep I found one) or something that I
can integrate at native level with jsctypes.

Although you can use live connect, with a bit of hacking, I think that
you may find that your code is difficult to maintain and perhaps a bit
unstable. I hear that live connect will go away with mozilla 2.0.

What might be a better solution is to write a thin wrapper around your
pdf exporting application. For example, you can generate the report
using whichever way you want and at the end you simply execute your
jar, as a separate process, with the xml input to create the final
report. Both solutions require java to be installed anyway so both a
valid but I tink that what I am proposing here might be easier to
implement and you can reuse the XML output plugin. Your plugin will be
only a few lines of code.

Another solution will be to use something more native with jctypes.
That will be more universal solution and wont require java to be
installed or any 3rd party library as long as you ship your library
bundled for the 3 OSes we currently support. Calling native functions
from js is relatively easy and also thread safe if you stick to using
ChromeWorkers.

Let me know what do you think. Perhaps we can provide something that
will make your plugin easier to implement.

[markus]

Yes you are right, the LiveConnect solution is a bit hacky and I also
read about the expiration in mozilla 2.0.

For now I prefer your wrapper solution considering my actual needs in
a project.
So I need a solution for generating pdf reports for our application
scanning process in the next few weeks and my Java pdf library is
ready to go.
Furthermore I could enhance this library to produce PDFs on base of a
PDF template so that other users can benefit of this solution.
How would this wrapper look like ? Does it mean the new plugin calls a
shell or system process ?
Btw, concerning JDK in OSes: MAC OS provides a JDK anyhow(Linux as
well as far as I know) and since few weeks the Windows Updater
includes the JDK also.

Despite this, the native JSctypes stuff sounds interesting but at the
moment it means to much effort to develop a C library that generates
pdf docs.

[pdp]

The wrapper is simple. You can even call the existing XML exporter to
write an XML file or XML string and use it with XSLT to transfer it to
whatever format you use before generating the PDF. The basic xml
exporter is located here:
http://code.google.com/p/websecurify/source/browse/trunk/xulrunner/websecurify/distribution/bundles/reports%40weaponry.gnucitizen.org/components/WeaponryReportXmlExporter.js.

Most of the code is there only to make it consistant with the rest of
the project. You can either modify this and create a new exporter or
you can just call this component from your own. In order to invoke a
process, check out the weaponryCommon library located here:
http://code.google.com/p/websecurify/source/browse/trunk/xulrunner/websecurify/distribution/bundles/common%40weaponry.gnucitizen.org/chrome/content/mod/weaponryCommon.jsm.

This library already contains many helper functions. Check
executeFile. After you import the module you can call the function
like this: weaponryCommon.executeFile(path, arg1, arg2, arg3,...).
weaponryCommon also contains functions to get relative paths to the
extension folder etc. It is really not very difficult.

You code will evolve around the following mechanism:

1. create custom component for exporting into your pdf format
2. write a file somewhere on the disc
3. find path to your jar
4. execute java to write the actual final format.

Let me know if I can help with anything.

[markus]

hi,

now I got it working. In the WeaponryReportXmlExporter.js I can call
the Java process like you have explained.
After that I wanted to introduce a new Exporter besides JSON, HTM, XML
and CSV.
Therefore I did the following steps:

- created a new WeaponryReportPDFExporter.js file with a new UUID and
a new 'reportFileType'
classID: Components.ID('{31f0a81c-
ee37-4dfc-8ed8-809a85af3f14}')
- registered it in the chrome manifest
component {31f0a81c-
ee37-4dfc-8ed8-809a85af3f14} components/
WeaponryReportPdfExporter.js
contract @reports.weaponry.gnucitizen.org/weaponry-
report-pdf-expoter;1 {31f0a81c-ee37-4dfc-8ed8-809a85af3f14}

Unfortunately the new Pdf component inside of the reports bundle is
not recognized by the "Export Report" task, so that it will not be
displayed
in the file picker dialog.

I've seen that there are also entries in the compreq.dat for the
single export types, but this file is generated.

what do i else have to do for registering a new exporter inside of the
reports bundle ?

Thanks in advance...

On Feb 12, 12:41 pm, pdp <pdp.gnuciti...@gmail.com> wrote:
> The wrapper is simple. You can even call the existing XML exporter to
> write an XML file or XML string and use it with XSLT to transfer it to
> whatever format you use before generating the PDF. The basic xml

> exporter is located here:http://code.google.com/p/websecurify/source/browse/trunk/xulrunner/we....

>
> Most of the code is there only to make it consistant with the rest of
> the project. You can either modify this and create a new exporter or
> you can just call this component from your own. In order to invoke a

> process, check out the weaponryCommon library located here:http://code.google.com/p/websecurify/source/browse/trunk/xulrunner/we....

[Petko D. Petkov]

You are using a non-development version. In practice there is no such thing as development/non-development but there are some options that make developing extensions easier with the development version. 

Anyway, the quick solution is to delete the comreg.dat file. When you start Websecurify it will reindex all components and hopefully your component will be now part of the report export dialog. The more time consuming but better solution, especially when you want to develop things in xulrunner and test them, is to install the development add-on which can be found here: http://code.google.com/p/websecurify/source/browse/#svn%2Ftrunk%2Fxulrunner%2Fwebsecurify%2Fextensions%2Fdevelopment%40weaponry.gnucitizen.org

Let me know if there are any other obstacles.

--

Petko D. Petkov | GNUCITIZEN.org

PGP Key ID: 0xF2FD757A

[markus]

So finally everything works fine.

My solution looks like as following:

- Java based program developed which generates a PDF on base of the
scan-results xml
- WeaponryReportPdfExporter.js implemented in Reports bundle:
- calls the existing XmlExporter for avoiding duplications
- after xml creation: calling 'weaponryCommon.executeFile' -->
Java component
- PdfExporter is parameterized by a properties file in chrome/
locale/en-US/com where the following things are configured:
. javaDirPath: there lies the jar file(s) and the shell script
. name of shell
. name of runnable jar
- chrome manifest enhanced
- deleted compreg and xpti in components and restarted websecurify

thanks again

On 15 Feb., 15:19, "Petko D. Petkov" <pdp.gnuciti...@gmail.com> wrote:
> You are using a non-development version. In practice there is no such thing as development/non-development but there are some options that make developing extensions easier with the development version.
>

> Anyway, the quick solution is to delete the comreg.dat file. When you start Websecurify it will reindex all components and hopefully your component will be now part of the report export dialog. The more time consuming but better solution, especially when you want to develop things in xulrunner and test them, is to install the development add-on which can be found here:http://code.google.com/p/websecurify/source/browse/#svn%2Ftrunk%2Fxul...

[Petko D. Petkov]

Thanks for making the addon. :) Is it private or will it be released publicly?

pdp

[markus]

I will clarify that point with my department head.
After that I come back to you for checking in my progress (maybe
directly in svn or forwarding it for your review via mail)

[Petko D. Petkov]

There is something that we are building at the moment which we want to expose to contributors like you (under the "network" tab). I will let you know as soon as we have something ready. In the meanwhile, we can statically expose your extension through this mechanism as long as you want to do that.

[markus]

Hello,

good news. I am allowed to provide my progress.
Please make a proposal how we proceed.

> ...
>
> Erfahren Sie mehr »

[Petko D. Petkov]

We just need to package it up and provide it on the site. Or you can host it yourself and we are going to provide the link :) How does that sound?

--