springframework-developer

RE: [Springframework-developer] Is it worth keeping BCEL around a t all?

[Kopylenko, D. <dko...@ac...>]

Mark,

Would it be feasible to create another Attributes impl such as
JavassistAttributes ?

Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Monday, November 17, 2003 9:26 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around a t
all?


We use Javassist at work in an internal project. I think it's great. I=20
don't know how it compares in speed to the using cglib on top of ASM=20
though; we picked Javassist for this applicaiton mainly because it=20
allows you to write in real Java code which gets parsed and inserted at =

runtime...




Kopylenko, Dmitry wrote:

>Has anyone had any experience wit Javassist? Any thoughts/comments?
>
>Regards,
>Dmitriy.
>
>-----Original Message-----
>From: j=FCrgen h=F6ller [werk3AT] [mailto:jue...@we...]
>Sent: Sunday, November 16, 2003 3:59 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around at
>all?
>
>
>+1 - the Hibernate guys typically know what they're doing, so I trust
>+them when they switched to ASM :-)
>
>________________________________
>
>Von: spr...@li... im Auftrag=20
>von Alef Arendsen (JTeam)
>Gesendet: So 16.11.2003 19:17
>An: spr...@li...
>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL=20
>around at all?
>
>
>
>+1
>
>Just get rid of if, What Mark is saying about the side file approach=20
>indeed sounds like the best approach...
>
>Alef
>
>
> =20
>
>>Hi,
>>
>>I vote to get rid of BCEL as well.  It always seemed large to me.  =
The
>>ASM api indicates it supports attribute manipulation in the bytecode=20
>>so I
>>should be able to port the bcel package to asm.   This
>>feature bytecode
>>libraries might not be that important anyway since the default =
storage=20
>>mechanism for attributes will likely switch to side files instead of=20
>>putting it in the bytecode.
>>
>>Mark
>>   =20
>>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from =

>any Web browser or wireless device. Click here to Try it Free!=20
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.t=
mp
>l
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from =

>any Web browser or wireless device. Click here to Try it Free!=20
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.t=
mp
>l
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>This SF. Net email is sponsored by: GoToMyPC
>GoToMyPC is the fast, easy and secure way to access your computer from =

>any Web browser or wireless device. Click here to Try it Free!=20
>https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3D/g22lp.tmp=
l
>_______________________________________________
>Springframework-developer mailing list=20
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> =20
>




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from =
any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tm=
pl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] Is it worth keeping BCEL around a t all?

[Kopylenko, D. <dko...@ac...>]

Colin,

Thanks for your answer.

Dmitriy.

-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]=20
Sent: Monday, November 17, 2003 1:38 PM
To: spr...@li...
Cc: 'mpo...@sp...'
Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around a t
all?


I can actually answer that, to the extent that looking at the existing=20
code in BcelAttributes and BcelAttributeWriter, I don't see anything at =

all in there that you couldn't do with Javassist.

As to this is in any way preferable to using an ASM/cglib combination,=20
that's harder to answer. Javassist would probably be a more direct=20
replacement on a line by line basis, since it's fundamental approach is =

fairly similar; you work with objects representing the bytecode=20
elements. It definitely runs faster than BCEL, and uses less memory, =
but=20
my feeling is that for raw speed and memory usage, ASM's 'visitor'=20
approach would win out.



Kopylenko, Dmitry wrote:

>Mark,
>
>Would it be feasible to create another Attributes impl such as=20
>JavassistAttributes ?
>
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Monday, November 17, 2003 9:26 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL =
around a
t
>all?
>
>
>We use Javassist at work in an internal project. I think it's great. I
>don't know how it compares in speed to the using cglib on top of ASM=20
>though; we picked Javassist for this applicaiton mainly because it=20
>allows you to write in real Java code which gets parsed and inserted =
at=20
>runtime...
>
>
>
>
>Kopylenko, Dmitry wrote:
>
> =20
>
>>Has anyone had any experience wit Javassist? Any thoughts/comments?
>>
>>Regards,
>>Dmitriy.
>>
>>-----Original Message-----
>>From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
>>Sent: Sunday, November 16, 2003 3:59 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Is it worth keeping BCEL=20
>>around at all?
>>
>>
>>+1 - the Hibernate guys typically know what they're doing, so I trust =

>>+them when they switched to ASM :-)
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag
>>von Alef Arendsen (JTeam)
>>Gesendet: So 16.11.2003 19:17
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL=20
>>around at all?
>>
>>
>>
>>+1
>>
>>Just get rid of if, What Mark is saying about the side file approach
>>indeed sounds like the best approach...
>>
>>Alef
>>
>>
>>=20
>>
>>   =20
>>
>>>Hi,
>>>
>>>I vote to get rid of BCEL as well.  It always seemed large to me. =20
>>>The ASM api indicates it supports attribute manipulation in the=20
>>>bytecode so I
>>>should be able to port the bcel package to asm.   This
>>>feature bytecode
>>>libraries might not be that important anyway since the default=20
>>>storage
>>>mechanism for attributes will likely switch to side files instead of =

>>>putting it in the bytecode.
>>>
>>>Mark
>>>     =20
>>>




-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from =
any
Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3Dmm/g22lp.tm=
pl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Is it worth keeping BCEL around a t all?

[Colin S. <col...@ex...>]

I can actually answer that, to the extent that looking at the existing 
code in BcelAttributes and BcelAttributeWriter, I don't see anything at 
all in there that you couldn't do with Javassist.

As to this is in any way preferable to using an ASM/cglib combination, 
that's harder to answer. Javassist would probably be a more direct 
replacement on a line by line basis, since it's fundamental approach is 
fairly similar; you work with objects representing the bytecode 
elements. It definitely runs faster than BCEL, and uses less memory, but 
my feeling is that for raw speed and memory usage, ASM's 'visitor' 
approach would win out.



Kopylenko, Dmitry wrote:

>Mark,
>
>Would it be feasible to create another Attributes impl such as
>JavassistAttributes ?
>
>Dmitriy.
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...] 
>Sent: Monday, November 17, 2003 9:26 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Is it worth keeping BCEL around a t
>all?
>
>
>We use Javassist at work in an internal project. I think it's great. I 
>don't know how it compares in speed to the using cglib on top of ASM 
>though; we picked Javassist for this applicaiton mainly because it 
>allows you to write in real Java code which gets parsed and inserted at 
>runtime...
>
>
>
>
>Kopylenko, Dmitry wrote:
>
>  
>
>>Has anyone had any experience wit Javassist? Any thoughts/comments?
>>
>>Regards,
>>Dmitriy.
>>
>>-----Original Message-----
>>From: jürgen höller [werk3AT] [mailto:jue...@we...]
>>Sent: Sunday, November 16, 2003 3:59 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Is it worth keeping BCEL around at
>>all?
>>
>>
>>+1 - the Hibernate guys typically know what they're doing, so I trust
>>+them when they switched to ASM :-)
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag 
>>von Alef Arendsen (JTeam)
>>Gesendet: So 16.11.2003 19:17
>>An: spr...@li...
>>Betreff: RE: [Springframework-developer] Is it worth keeping BCEL 
>>around at all?
>>
>>
>>
>>+1
>>
>>Just get rid of if, What Mark is saying about the side file approach 
>>indeed sounds like the best approach...
>>
>>Alef
>>
>>
>> 
>>
>>    
>>
>>>Hi,
>>>
>>>I vote to get rid of BCEL as well.  It always seemed large to me.  The
>>>ASM api indicates it supports attribute manipulation in the bytecode 
>>>so I
>>>should be able to port the bcel package to asm.   This
>>>feature bytecode
>>>libraries might not be that important anyway since the default storage 
>>>mechanism for attributes will likely switch to side files instead of 
>>>putting it in the bytecode.
>>>
>>>Mark
>>>      
>>>

[Springframework-developer] Re: Is it worth keeping BCEL around a t all?

[Chris N. <ch...@si...>]

Colin Sampaleanu wrote:
> I can actually answer that, to the extent that looking at the existing
> code in BcelAttributes and BcelAttributeWriter, I don't see anything at
> all in there that you couldn't do with Javassist.

I like the idea of Javassist but in practice it seems to result in messy
StringBuffer code to build up the Java pseudocode. At some point dealing
with the raw bytecodes almost seems easier (but maybe I have been looking
at bytecode for too long :-)
 
> As to this is in any way preferable to using an ASM/cglib combination,
> that's harder to answer. Javassist would probably be a more direct
> replacement on a line by line basis, since it's fundamental approach is
> fairly similar; you work with objects representing the bytecode
> elements. It definitely runs faster than BCEL, and uses less memory, but
> my feeling is that for raw speed and memory usage, ASM's 'visitor'
> approach would win out.

ASM will always win out unless you need to keep a lot of state while
visiting (for things such as code flow analysis), and maybe even then. For
your application of just reading and writing an attribute it is definitely
the way to go.

In CGLIB2 we also have some Ant tasks which should make porting easier. If I
have some spare time I may port the BCEL stuff as an example.

FYI Hibernate 2.1 will use CGLIB2 which means Spring will need to upgrade at
the same time. I can supply you with a patch when you want to do this.

Chris

[Springframework-developer] reloading/hot swapping of beans

[Colin S. <col...@ex...>]

This is only of use in certain scenarios, but we should maybe examine 
the possibilities w/regards to unloading and reloading of beans. Both 
HiveMind and now Pico
  http://www.picocontainer.org/hotswapping.html
allow reloading of a bean/component returned from the container, due to 
the fact they they automatically introduce a dynamic proxy for the 
object returned form the container.

This has a slight performance impact, but is probably the easiest way to 
handle reloading. Now how much additional 
complexity/variability/breakage this could introduce is I think pretty 
hard to figure out, given the amount of stuff you can do now with things 
like the BeanPostProcessor which can affect the lifecycle of a bunch of 
things in the container.

Re: [Springframework-developer] reloading/hot swapping of beans

[Rod J. <rod...@in...>]

Yes, I think we could do this pretty easily. But I wouldn't want it to be
the default.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, November 17, 2003 8:21 PM
Subject: [Springframework-developer] reloading/hot swapping of beans


> This is only of use in certain scenarios, but we should maybe examine
> the possibilities w/regards to unloading and reloading of beans. Both
> HiveMind and now Pico
>   http://www.picocontainer.org/hotswapping.html
> allow reloading of a bean/component returned from the container, due to
> the fact they they automatically introduce a dynamic proxy for the
> object returned form the container.
>
> This has a slight performance impact, but is probably the easiest way to
> handle reloading. Now how much additional
> complexity/variability/breakage this could introduce is I think pretty
> hard to figure out, given the amount of stuff you can do now with things
> like the BeanPostProcessor which can affect the lifecycle of a bunch of
> things in the container.
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] reloading/hot swapping of beans

[Rob B. <rob...@ve...>]

While your on the topic of reloading / hot swapping of beans, what are your
thoughts on JMX?  Reloading / hot swapping of beans & JMX would go nicely
together.

I've been thinking a bit about Spring & JMX lately.  My original plan was to
implement some sort of a custom configuration repository that the JMX Mbeans
could update.  A database or the like.

Once the configuation changes were made, I would somehow signal my app.  The
app would load a second instance of spring, and then "swap" it with the
original at the appropriate time in the applications cycle.  Spring would be
used as a "factory" for all the objects in the application, and thus when
the new spring instance was loaded the new configuration would be used.  I
would use some sort of unit of work pattern to maintain a reference to the
"old" spring instance until that unit of work was completed so there would
be no issues with the config changing halfway through.

The primary issue I had with this setup is singletons.  If I have two
instances of Spring, then I don't have a true singleton anymore (I could
always revert to the "singleton" pattern if need be - yuck).  This may be
fine in some situations, but not ok in others.  Also, I would like some way
to "copy" state from the old singleton into the new one built into the
framework.

I just wanted to get this out there to see what people think about how to go
about JMX enabling spring.  Rod had said he had some thoughts on it a while
ago (or in his book?).

I haven't done a very good job of explaining this, but I think this would
work.  I can explain it better later if this is an area of interest to
people.

Later
Rob

> Yes, I think we could do this pretty easily. But I wouldn't want it to be
> the default.
>
> Regards,
> Rod
>

Re: [Springframework-developer] reloading/hot swapping of beans

[Rod J. <rod...@in...>]

I've just added a HotSwappableInvokerInterceptor that allows such swapping
for advised objects. I think it's better to do this via AOP than via an ad
hoc DP solution. This way it will work for classes proxied by CGLIB also.

As I said in a previous message, I don't think this should be the default.

I'm thinking of ways to enable this. A BeanPostProcessor is the obvious
approach.

Regards,
Rod

----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Monday, November 17, 2003 8:21 PM
Subject: [Springframework-developer] reloading/hot swapping of beans


> This is only of use in certain scenarios, but we should maybe examine
> the possibilities w/regards to unloading and reloading of beans. Both
> HiveMind and now Pico
>   http://www.picocontainer.org/hotswapping.html
> allow reloading of a bean/component returned from the container, due to
> the fact they they automatically introduce a dynamic proxy for the
> object returned form the container.
>
> This has a slight performance impact, but is probably the easiest way to
> handle reloading. Now how much additional
> complexity/variability/breakage this could introduce is I think pretty
> hard to figure out, given the amount of stuff you can do now with things
> like the BeanPostProcessor which can affect the lifecycle of a bunch of
> things in the container.
>
>
>
>
>
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] reloading/hot swapping of beans

[Colin S. <col...@ex...>]

There are two aspects related to the fact that you wrap an object in a 
dynamic proxy (java or cglib generated) like this. I only mentioned 
hotswapping in the message below, but I had talked about the other in a 
previous message, that is the fact that you can effectively accomplis 
lazy loading of the bean, or set of beans, very easily.

Because this is so much related to lifecycle, there are arguments for 
making this a standard part of the bean definition in the context (i.e. 
part of the dtd). The only issue right now is that there is a shared dtd 
for bean factories and contexts.

My gut feeling is that some things are very well handled by 
BeanPostProcessor, when it's doing something orthogonal to the bean 
lifecycle, but when the lifecycle of the bean is being touched like 
this, it's at least worth thinking about if the container should be 
involved...



Rod Johnson wrote:

>I've just added a HotSwappableInvokerInterceptor that allows such swapping
>for advised objects. I think it's better to do this via AOP than via an ad
>hoc DP solution. This way it will work for classes proxied by CGLIB also.
>
>As I said in a previous message, I don't think this should be the default.
>
>I'm thinking of ways to enable this. A BeanPostProcessor is the obvious
>approach.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Colin Sampaleanu" <col...@ex...>
>To: <spr...@li...>
>Sent: Monday, November 17, 2003 8:21 PM
>Subject: [Springframework-developer] reloading/hot swapping of beans
>
>
>  
>
>>This is only of use in certain scenarios, but we should maybe examine
>>the possibilities w/regards to unloading and reloading of beans. Both
>>HiveMind and now Pico
>>  http://www.picocontainer.org/hotswapping.html
>>allow reloading of a bean/component returned from the container, due to
>>the fact they they automatically introduce a dynamic proxy for the
>>object returned form the container.
>>
>>This has a slight performance impact, but is probably the easiest way to
>>handle reloading. Now how much additional
>>complexity/variability/breakage this could introduce is I think pretty
>>hard to figure out, given the amount of stuff you can do now with things
>>like the BeanPostProcessor which can affect the lifecycle of a bunch of
>>things in the container.
>>    
>>

Re: [Springframework-developer] reloading/hot swapping of beans

[Rod J. <rod...@in...>]

> There are two aspects related to the fact that you wrap an object in a
> dynamic proxy (java or cglib generated) like this. I only mentioned
> hotswapping in the message below, but I had talked about the other in a
> previous message, that is the fact that you can effectively accomplis
> lazy loading of the bean, or set of beans, very easily.
>
> Because this is so much related to lifecycle, there are arguments for
> making this a standard part of the bean definition in the context (i.e.
> part of the dtd). The only issue right now is that there is a shared dtd
> for bean factories and contexts.

The only issue is that it could make the container dependent on AOP. I think
AOP is pretty core, so that doesn't offend me as much as it once did. It
could also perhaps be implemented using reflection, so that if the AOP
framework wasn't found on the classpath it treated a "hotswap" attribute as
an error.

Regards,
Rod

[Springframework-developer] Re: reloading/hot swapping of beans

[Chris N. <ch...@si...>]

Rod Johnson wrote:
> I've just added a HotSwappableInvokerInterceptor that allows such swapping
> for advised objects. I think it's better to do this via AOP than via an ad
> hoc DP solution. This way it will work for classes proxied by CGLIB also.

Hot-swapping is a pretty specialized case in that it doesn't require a
Method object or a boxed argument array, just a reference to the object to
delegate to. CGLIB2 has different interceptor types that can take advantage
of this, so you may not want to be reusing the generic AOP code anyway.

Chris