As a result of this move I have to export one more data symbol
(SECAnyTemplate) from libnss3.so. :( Removed the temporary workaround
in coreconf/rules.mk.
Modified Files:
coreconf/rules.mk nss/lib/certhigh/manifest.mn
nss/lib/nss/mapfile nss/lib/nss/nss.def
nss/lib/pkcs7/manifest.mn
Added Files:
nss/lib/pkcs7/certread.c
Removed Files:
nss/lib/certhigh/certread.c
SECHashObjects[] is no longer exported.
New function HASH_GetHashObject returns pointer to selected const object.
SSL statistics are now in a structure whose address is obtained via a
call to SSL_GetStatistics().
On NT, the new symbol NSS_USE_STATIC_LIBS must be declared in programs
that use the static SSL library.
Also, propagate "const" declaration for SECHashObjects.
Subject:
Re: Rhino bug - Wrapper ??
Date:
Fri, 05 Jan 2001 03:46:11 +0530
From:
Mukund Balasubramanian <mukund@cs.stanford.edu>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
References:
1 , 2 , 3 , 4 , 5 , 6
That works too,
Should I assume that this would be a part of the next tip ? I agree with the
part about
overloading code too.
Anyways, thanks a load for your help and just tell me if I could be of any
help in any other
respects of the rhino project.
ThanX,
Mukund Balasubaramanian
Norris Boyd wrote:
> Actually, I was considering removing the unwrapping code from
NativeJavaConstructor. I was
> suprised that it was there. The code dates from before we implemented proper
method and
> constructor overloading in Rhino. It's the overloading code that should have
the responsibility
> for unwrapping.
>
> Does this patch work for you:
>
> Index: NativeJavaObject.java
> ===================================================================
> RCS file:
/cvsroot/mozilla/js/rhino/org/mozilla/javascript/NativeJavaObject.java
> ,v
> retrieving revision 1.29
> diff -u -r1.29 NativeJavaObject.java
> --- NativeJavaObject.java 2000/11/13 22:10:32 1.29
> +++ NativeJavaObject.java 2001/01/04 21:33:55
> @@ -673,6 +673,12 @@
>
> return Result;
> }
> + else if (value instanceof Wrapper) {
> + value = ((Wrapper)value).unwrap();
> + if (type.isInstance(value))
> + return value;
> + reportConversionError(value, type);
> + }
> else {
> reportConversionError(value, type);
> }
>
> This handles the case where the object is both a Scriptable and a Wrapper.
>
> --N
>
> Mukund Balasubramanian wrote:
>
> > Yes they do implement Scriptable.
> > From my preliminary inspection of the code, findFunction seems to be
preceediong the
> > coerceType call and I presume findFunction call is going to fail if the
arguments are
> > wrapped (bad types mismatching signature).
> > The constructor case DOES go through an explicit unwrapping stage as
shown by the cut
> > and paste code. My question is whether the same preamble in NativeJavaMethod
is a valid bug
> > fix.
> >
> > ThanX,
> >
> > Mukund Balasubramanian
> >
> > Norris Boyd wrote:
> >
> > > Do your objects that implement Wrapper also implement Scriptable? From
simple inspection
> > > of the code I'd think that both the constructor and method cases would go
through
> > > NativeJavaMethod.coerceType, which should unwrap. However, Scriptable
objects are picked
> > > off and handled before any unwrapping is considered.
> > >
> > > --N
> > >
> > > Mukund Balasubramanian wrote:
> > >
> > > > Yup,
> > > > Here it is - Line numbers 173-178 are cut and paste from
> > > > NativeJavaConstructor.java inside NativeJavaMethod.java
> > > >
> > > > /*** Call in NativeJavaMethod.java
> > > > public Object call(Context cx, Scriptable scope, Scriptable thisObj,
> > > > Object[] args)
> > > > throws JavaScriptException
> > > > {
> > > > // Eliminate useless args[0] and unwrap if required
> > > > for (int i = 0; i < args.length; i++) {
> > > > if (args[i] instanceof Wrapper) {
> > > > args[i] = ((Wrapper)args[i]).unwrap();
> > > > }
> > > > }
> > > >
> > > > // Find a method that matches the types given.
> > > > if (methods.length == 0) {
> > > > ****/
> > > >
> > > > Is this correct ? I presume it is because of the fact that the
constructor
> > > > does this.
> > > >
> > > > Any luck with my other question regarding generalizing the WrapHandler
to all
> > > > objects (including those returned by scriptable) and not only those
returned
> > > > through nativeJava***
> > > >
> > > > ThanX,
> > > >
> > > > Mukund Balasubramanian
> > > >
> > > > Norris Boyd wrote:
> > > >
> > > > > Could you post your proposed patch?
> > > > >
> > > > > Thanks,
> > > > > Norris
> > > > >
> > > > > Mukund Balasubramanian wrote:
> > > > >
> > > > > > Hi all,
> > > > > > I am trying to play around with writing a custom WrapHandler for
my
> > > > > > Java objects in Rhino. I found WrapHandler very useful.
> > > > > > Now I am stuck at a point where, even though my wrappers
implement
> > > > > > "Wrapper", they get unwrapped only on calles to Constructors using
> > > > > > Liveconnect. Normal methods dont seem to be doing any unwrapping.
> > > > > > Managed to build rhino with a bug fix (cut and paste code from
> > > > > > NativeJavaConstructor to NativeJavamethod), and it works.
> > > > > > Just wanted to verify if it is a known bug (while I wait for
> > > > > > bugzilla to mail me a passwd).
> > > > > >
> > > > > > BTW, also found something interesting, WrapHandler gets called only
when
> > > > > > the object is returned from NativeJava***, not ANY Object. Is that
the
> > > > > > way it is supposed to work ??
> > > > > >
> > > > > > ThanX for any help,
> > > > > >
> > > > > > Mukund Balasubramanian
coreconf/rules.mk has a temporary workaround for the dependency of
certread.c on some PKCS7 symbols.
Modified Files:
coreconf/rules.mk nss/lib/manifest.mn nss/lib/nss/config.mk
nss/lib/nss/mapfile nss/lib/nss/nss.def
nss/lib/smime/config.mk nss/lib/smime/mapfile
nss/lib/smime/smime.def
