jakarta-bcel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <m.d...@4flow.de>
Subject AW: Heads-up / opinions? - BCEL -> tt-bytecode
Date Wed, 20 Feb 2002 13:39:18 GMT
Ok, I didn't think of that, but in that case the direct way of using
ClassParser(InputStream...) should do
 
Please try with the attached version. I'll check it into the repository
if it works.
 
Cheers
    Markus

-----Urspr√ľngliche Nachricht-----
Von: Glen Daniels [mailto:gdaniels@macromedia.com]
Gesendet: Mittwoch, 20. Februar 2002 14:29
An: Markus Dahm; bcel-dev@jakarta.apache.org
Cc: Glen Daniels
Betreff: RE: Heads-up / opinions? - BCEL -> tt-bytecode


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> > 


Mime
View raw message