Well, you really didn't dig into the issue :-)
BeansWrapper first introspects the class using java.beans.Introspector -
so far so good. However, if the class isn't public, a special algorithm
kicks in. Frankly, I'd believe this algorithm should be already present in
java.beans.Introspector, but unfortunately it isn't, so we have to do it
on our own. This algorithm does what you write about: dinamically finds
the public superclasses/interfaces and extracts the public methods from
them. Unfortunately, it uses Class.getMethods() on the original,
non-public class first and that's where the security exception is thrown.
I've analyzed the problem, and I *can* rewrite it so that
Class.getMethods() is only called on public classes and interfaces. I
think it'll be a little less efficient in general case, though, but it'll
avoid tripping accross security checks.
(I'm glad this came up - another opportunity for making FM play more
nicely in security-restrained environments).
Stay tuned :-)
Attila.
BTW, aren't you glad I ditched Outlook Express? :-)
On Thu, 22 Apr 2004 21:00:46 +0200, Daniel Dekany <ddekany@...>
wrote:
> Wednesday, April 21, 2004, 10:34:16 PM, Attila Szegedi wrote:
>
[snip]
>
> Maybe I'm saying a stupid thing as I didn't dig into this issue, but, is
> it a possible solution that: if a security exception occurs then the
> wrapper tries to read the list of methods only through the java.** and
> javax.** classes/interfaces that the examined object extends/implements?
> After all, it really should not expose the implementation specific
> details of the Servlet related objects, because if somebody would
> utilize that, then his software was not portable between Servlet
> implementations.
>
|