RE: [Springframework-developer] RE: Class file manipulation with BCEL safe?

[Mark P. <mar...@co...>]

Hi,

Interesting indeed, I never though of that.

I think the "side" file approach is also valid...it really tends to be a
matter of taste. I believe the JSR175 committe also debated long and
hard about where to put the attributes and ended up putting it in the
bytecode.

I'm curious if CGLIB would behave the way suggested. Java already stores
a custom attribute in the bytecode, the 'depreacted' attribute. CGLIB
might strip this out as well. It needs some investigation, I'll look
into it. If it does strip out attributes there are probably implications
for jdk1.5 based code.

Should I provide the "side file" or "side class" approach (ala BeanInfo)
as well? There is a need for side-files anyway if someone wants to
over-ride the settings in an existing class without having to
subclass... JSR181 has a thread on this over ridding stuff, I'll read up
on it.

The side-file approach does feel better to people, those who typically
dislike anything touching their bytecode and it does mean you don't have
to copy the bcel.jar into ANT_HOME/lib, so it feels more lightweight. 

I guess there is a danger of offering too many possiblities for storing
the attributes instead of presenting a "best of breed" solution. If we
offer side file support, then aside from the plugability issue, we start
to look very much like the current attributes-commons stuff. Of course,
plugability is important if we want to co-exist with the avalance of
jdk1.5 attributes that are sure to come.

Cheers,
Mark

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Chris Nokleberg
Sent: Thursday, October 23, 2003 2:42 AM
To: spr...@li...
Subject: [Springframework-developer] RE: Class file manipulation with
BCEL safe?


Alef Arendsen (JTeam) wrote:
> In a Spring Validator, I'm retrieving the attributes using 
> BcelAttributes and then inspect the class... Works kind of neat,
>  
> but still, won't this conflict with the ASM way hibernate does things?

In short, no. Hibernate uses CGLIB mostly for generating lazy-loading
proxies. Since the proxies are subclasses of the mapped classes, you
should be able to retrieve your attribute data from the superclass of
the proxy. You can tell a proxy from a non proxy by seeing if your
object is an instanceof net.sf.cglib.Factory.

If a framework ends up using CGLIB or something like it to actually
transform your classes at build time or run time you will have to be
careful. It is likely that any attributes in the original class would be
stripped out. For this reason I would suggest storing the attribute
metadata outside of the classfile. Personally I have had good success
using QDox to parse the source files, generating a .attributes
properties file per class.

Chris




-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what
you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer