code review and fixes (r=chouck@geocast.com). He needs this cuz he has no
knowledge of exact number of properties before new-style enumerating them.
- Patch up jsdbgapi.c a bit -- it needs to use OBJ_GET_ATTRIBUTES and new APIs
to do a better job describing properties to a debugger.
- Add JSMSG_CANT_DESCRIBE_PROPS for bogus non-native error case in jsdbgapi.c.
- Fix "Inappropriate" => "invalid" in JSMSG_BAD_ARRAY_LENGTH message.
Primarily fixes to properly handle nsIXPCSecurityManager vetos of
xpconnect activities.
- The code was not propagating security manager vetos of native wrapping up
through xpconnect internals. So, xpconnect was erroneously masking the
security exception with its own 'failed to convert param' exception.
This effects the signatures of nsXPCWrappedNative::GetNewOrUsedWrapper
and nsXPCWrappedJSClass::GetNewOrUsedClass.
- This propagation also helps with the problem that sometimes interfaces
are not set as [scriptable] and we did not make that clear as the source
of xpconnect's failure to convert a param in calling a method. Now this
specific class of exceptions is indicated in the JS exception object when
this happens.
- Added an explicit call to js_ForceGC on shutdown of xpcshell to aid in
avoiding 'false positives' in leak detection
- Return JS_FALSE rather than JS_TRUE when an exception is thrown in
xpcjsid to make the jsengine notices the exception.
- Move #includes that others added in xpcmodule.cpp to xpcprivate.h in
order to maintain the include conventions of this module.
- Avoid throwing an exception if it represents a security manager veto
and the security manager set an exception already.
- Replace uses of nsCOMTypeInfo<> added by scc with NS_GET_IID macros.
- Fixed a methodname misspelling because reviewers care about stuff
like that :)
Subject:
Re: another getClassLoader exception
Date:
Mon, 18 Oct 1999 22:01:24 -0400
From:
Andrew Wason <aw@softcom.com>
To:
norris@netscape.com (Norris Boyd)
CC:
Howard Lin <howard@softcom.com>
References:
1 , 2
At 05:03 PM 10/18/99 -0700, Norris Boyd wrote:
>Are you still seeing this problem?
Yes. I just did a CVS update to get the latest stuff and we still have
this problem.
I wrote a standalone sample program that duplicates the problem. Run
JSSupport and you should get this exception:
defineClass org.mozilla.javascript.gen.c2
Exception in thread "main" java.lang.NoClassDefFoundError:
org/mozilla/javascript/gen/c1
at java.lang.ClassLoader.resolveClass0(Native Method)
at java.lang.ClassLoader.resolveClass(ClassLoader.java:545)
at
JSSupport$MySecuritySupport$DataClassLoader.loadClass(JSSupport.java:89)
at JSSupport$MySecuritySupport.defineClass(JSSupport.java:47)
at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java,
Compiled Code)
at org.mozilla.javascript.Context.compile(Context.java:1761)
at org.mozilla.javascript.Context.compile(Context.java:1691)
at org.mozilla.javascript.Context.compileReader(Context.java:810)
at org.mozilla.javascript.Context.evaluateReader(Context.java:725)
at org.mozilla.javascript.Context.evaluateString(Context.java:692)
at JSSupport.<init>(JSSupport.java:20)
at JSSupport.main(JSSupport.java:9)
Andrew
>--N
>
>Andrew Wason wrote:
>
> > At 04:54 PM 10/12/99 -0700, Norris Boyd wrote:
> > >I just checked in changes so that the class calling ScriptRuntime (c5
> in your
> > >case) will load the class itself using the normal Java classloading
> mechanism
> > >rather than an explicit call to the class loader. I pushed the bits up
> to the
> > >ftp site, but it takes a bit to propagate.
> >
> > I get this exception now (debugging statements are from my code):
> >
> > SecuritySupport.defineClass org.mozilla.javascript.gen.c5
> > DataClassLoader.loadClass org.mozilla.javascript.gen.c5
> > DataClassLoader.loadClass org.mozilla.javascript.gen.c4
> > using default loader com.softcom.realjava.PluginClassLoader@da9486a0
> > java.lang.NoClassDefFoundError: org/mozilla/javascript/gen/c4
> > at java.lang.ClassLoader.resolveClass0(Native Method)
> > at java.lang.ClassLoader.resolveClass(ClassLoader.java:545)
> > at
> >
> com.softcom.realjava.plugins.RealJavaScript$RealJavaScriptSecuritySupport$Da
> > taClassLoader.loadClass(RealJavaScript.java:410)
> > at
> >
> com.softcom.realjava.plugins.RealJavaScript$RealJavaScriptSecuritySupport.de
> > fineClass(RealJavaScript.java:352)
> > at org.mozilla.javascript.optimizer.Codegen.compile(Codegen.java,
> > Compiled Code)
> > at org.mozilla.javascript.Context.compile(Context.java:1761)
> > at org.mozilla.javascript.Context.compile(Context.java:1691)
> > at org.mozilla.javascript.Context.compileReader(Context.java:810)
> >
> > So when c5 is being loaded by my SecuritySupport, it also needs to load c4.
> > I decompiled org.mozilla.javascript.gen.c5 and it's constant pool
> > references CLASS org.mozilla.javascript.gen.c4, so c5 is dependent on c4
> > being loadable. Is the problem that c5 is being loaded before the
> > optimizer has defined c4?
> >
> > I get the above exception for some classes and not others. It seems
> > consistent that I always get it for classes with dependencies on other
> > optimizer classes that haven't been generated yet.
> >
> > Andrew
> >
> > --
> > Andrew Wason
> > SoftCom, Inc.
> > aw@softcom.com
--
Andrew Wason
SoftCom, Inc.
aw@softcom.com
JSSupport.java
Name:
JSSupport.java
Type:
Java Source File (text/java)
Encoding:
base64
