The problem is that the code in Repository.lookup() relies on using your current (or a specified)
classpath to look for the class file. In Axis we use custom classloaders to get classes which
have been compiled on the fly into a directory which doesn't appear on any explicit classpath,
instead it's just the ClassLoader who knows where to look for them. So being able to get
a JavaClass by using myClass.getResourceAsStream(myClassName) would solve this problem for
us, because the custom classloader correctly overrides getResourceAsStream() to keep a pointer
to the real class file wherever it lives. I would think this would be applicable to many
situations where there are custom classloaders involved (dynamically generated classes, etc).
Make sense?
Thanks,
--Glen
-----Original Message-----
From: m.dahm@4flow.de [mailto:m.dahm@4flow.de]
Sent: Wednesday, February 20, 2002 3:58 AM
To: bcel-dev@jakarta.apache.org
Cc: gdaniels@macromedia.com
Subject: AW: Heads-up / opinions? - BCEL -> tt-bytecode
In fact I don't see a feature missing here, since all you have to do
is Repository.lookup(foo.getClass().getName()). That's not true for
1.3 Proxy classes, but who cares ...
> -----Ursprungliche Nachricht-----
> Von: Sam Ruby [ mailto:rubys@us.ibm.com <mailto:rubys@us.ibm.com> ]
> Gesendet: Dienstag, 19. Februar 2002 21:42
> An: bcel-dev@jakarta.apache.org
> Cc: axis-dev@xml.apache.org
> Betreff: Heads-up / opinions? - BCEL -> tt-bytecode
>
>
> Comments?
>
> Glen - a pet peeve of mine is Apache projects who don't talk to one
> another.... Grrr.
>
> - Sam Ruby
> ---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 02/19/2002
> 03:40 PM ---------------------------
>
> Glen Daniels <gdaniels@macromedia.com> on 02/18/2002 06:50:07 PM
>
> Please respond to axis-dev@xml.apache.org
>
> To: "Axis-Dev (E-mail)" <axis-dev@xml.apache.org>
> cc:
> Subject: Heads-up / opinions? - BCEL -> tt-bytecode
>
>
>
>
> Hi all.
>
> So, while looking into some reported problems with BCEL, I ran into a
> couple of difficulties with the library. In particular,
> there is no way to
> get BCEL to make you a JavaClass from a java.lang.Class, so
> it tries to
> load the class, which was failing to work with JWS files on my home
> machine.
>
> As an alternative, I switched over the code to use the
> tt-bytecode library
> from SourceForge ( http://tt-bytecode.sf.net/ <http://tt-bytecode.sf.net/> ), which
has the following
> benefits:
>
> 1) The jar is much smaller (128k vs. 335k)
>
> 2) It has an easy to use API for creating a new BClass with a Class
> parameter, solving the classloader issue
>
> This is a BSD style license jar file.
>
> I'm going to commit my changes, which also make sure that JWS
> files are
> compiled in debug mode (at least for javac), and leave the
> bcel.jar there
> for now as well. If everyone's good with this switchover
> tomorrow, I'll
> remove bcel, if not I can roll back the change.
>
> --Glen
>
>
>
>
>
> --
> To unsubscribe, e-mail:
< mailto:bcel-dev-unsubscribe@jakarta.apache.org <mailto:bcel-dev-unsubscribe@jakarta.apache.org>
>
For additional commands, e-mail: < mailto:bcel-dev-help@jakarta.apache.org <mailto:bcel-dev-help@jakarta.apache.org>
>
|