- object delegation (like JSCreateObject) Perl->JS
- ParlValue handles PerlObject correctly
- undef values handled correctly (in both directions)
- JS arrays may be tied to perl arrays
- error handlers supported on Perl side
- no globals
- several minor fixes
This patch teaches XPConnected objects to look in their JavaScript __proto__ chain for any names they can't resolve themselves. The rest of the fix to this bug sets the original DOM node object as the prototype of a new xpconnect-exposed plugin object, so javascript accesses will see names from both objects.
r=jst,brendan
a=beard
Commit the following contributions:
* Andi Vajda's changes to allow embedders to capture the generated bytecode (and thus control
generated class names).
* Marshall Cline's changes to allow embedders to override the default Java object wrapping
behavior
* Kurt Westerfeld's change to handle calling static methods better
Subject:
Odd behaviour on placement of .jar files?!
Date:
Mon, 05 Jun 2000 10:46:08 -0700
From:
John Raykowski <xski@xski.org>
To:
nboyd@atg.com
Hello,
I didn't want to post this directly as a rhino bug 'coz I think it may
be more of a JDK thing, but I thought I'd toss it to you as well.
The goal is to create a JavaScript object that implements a Java
interface. Straightforward enough and the example on the page using
ActionListener works without a hitch. However, when I try to do the
same with my own interface, I get an error message: error instantiating
({0}): class {1} is interface or abstract (coming from
NativeJavaClass.construct).
Here's where it gets a bit strange. Normally, I run with the jar files
in jre/lib/ext. When I remove the rhino files from jre/lib/ext and
reference them explicitly on the commandline with the -cp option, it
works as expected and my script can implement the interface just fine.
Go figure.
Anyhoo, there ya go. Like I said, I think its a JDK issue, but I
thought you'd be interested. The attached zipfile contains a set of
sample code to demonstrate this problem.
Thanks heaps,
-jmr
Be conservative in handling the lifetime of the safe context created by XPConnect to execute JS Components, and save it off to be destroyed at cleanup time, even if some other safe context is registered with XPConnect via SetSafeJSContext.
r=vishy, a=brendan
a=brendan
bug: 27362
This fix makes it so nsCLiveconnect.cpp doesn't #include
files within an extern "C" {} block. To make this work, I
simply moved the extern "C" {} to the minimum necessary
range. This required placing an "ifdef __cplusplus extern "C""
block in jsj_private.h, since nsCLiveconnect.cpp is the only
c++ file that includes jsj_private.h.
