springframework-developer — Spring Framework developers list

Re: [Springframework-developer] How hard is is to add support for list inside of a list, in an XML beanfactory def?

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

W/regards to doing proper method matching based on argument types in 
MethodInvokingFactoryBean, there are a few different levels it can be 
taken to. The current code is pretty dumb, it uses reflection to try to 
find a target method with the exact same argument types as the supplied 
arguments. This won't even work for calling methods which take arguments 
which are superclasses of the specified arguments. What would be pretty 
easy to do is to rip out the MethodUtils class from Apache BeanUtils, 
which can do proper method matching via a method called 
getMatchingAccessibleMethod(). The main downside to this is that 
MethodUtils compiles to about 7.5k of bytecode. This could probably be 
whittled down to about 5k by stripping out some items, but still, it 
would increase the base bean handling code by that amount. The third 
level would be to do coercion on the level of List -> Array, etc.

I don't think the latter is worth it, but I am wondering about the 2nd...


Rod Johnson wrote:

>This is excellent. We had a question about this on the forums recently. It's
>pretty powerful to be able to do arbitrary nesting.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Wednesday, November 26, 2003 4:37 PM
>Subject: RE: [Springframework-developer] How hard is is to add support for
>list inside of a list, in an XML beanfactory def?
>
>
>This is actually pretty simple: We just need to allow for <list> (and <map>)
>as sub-element of <list> in the DTD - the bean factory can already handle
>any kind of nested element! I've just patched the DTD accordingly and
>committed it; a corresponding unit test passes (not committed yet due to
>other work).
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, November 26, 2003 5:15 PM
>To: spr...@li...
>Subject: [Springframework-developer] How hard is is to add support for
>list inside of a list, in an XML beanfactory def?
>
>
>Right now in a bean factory xml definition, a list can not contain a
>list. Can somebody who is more familiar with the bean wrapping estimate
>how big a deal this would be to add?
>
>The issue comes in using the MethodInvokingFactoryBean to invoke a
>method which takes an array or list as an argument. Right now there is
>no way to do it unfortunately.
>  
>

Re: [Springframework-developer] How hard is is to add support for list inside of a list, in an XML beanfactory def?

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

This is excellent. We had a question about this on the forums recently. It's
pretty powerful to be able to do arbitrary nesting.

Regards,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, November 26, 2003 4:37 PM
Subject: RE: [Springframework-developer] How hard is is to add support for
list inside of a list, in an XML beanfactory def?


This is actually pretty simple: We just need to allow for <list> (and <map>)
as sub-element of <list> in the DTD - the bean factory can already handle
any kind of nested element! I've just patched the DTD accordingly and
committed it; a corresponding unit test passes (not committed yet due to
other work).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, November 26, 2003 5:15 PM
To: spr...@li...
Subject: [Springframework-developer] How hard is is to add support for
list inside of a list, in an XML beanfactory def?


Right now in a bean factory xml definition, a list can not contain a
list. Can somebody who is more familiar with the bean wrapping estimate
how big a deal this would be to add?

The issue comes in using the MethodInvokingFactoryBean to invoke a
method which takes an array or list as an argument. Right now there is
no way to do it unfortunately.





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] How hard is is to add support for list inside of a list, in an XML beanfactory def?

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

Thanks. I guess the contained list is going to come in just as a 
ManagedList instance. I think I'm still going to have to do some 
additional work in MethodInvokingFactoryBean to coerce that passed in 
ManagedList to the target method argument type.

jürgen höller [werk3AT] wrote:

>This is actually pretty simple: We just need to allow for <list> (and <map>) as sub-element of <list> in the DTD - the bean factory can already handle any kind of nested element! I've just patched the DTD accordingly and committed it; a corresponding unit test passes (not committed yet due to other work).
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Colin Sampaleanu
>Sent: Wednesday, November 26, 2003 5:15 PM
>To: spr...@li...
>Subject: [Springframework-developer] How hard is is to add support for
>list inside of a list, in an XML beanfactory def?
>
>
>Right now in a bean factory xml definition, a list can not contain a 
>list. Can somebody who is more familiar with the bean wrapping estimate 
>how big a deal this would be to add?
>
>The issue comes in using the MethodInvokingFactoryBean to invoke a 
>method which takes an array or list as an argument. Right now there is 
>no way to do it unfortunately.
>  
>

RE: [Springframework-developer] How hard is is to add support for list inside of a list, in an XML beanfactory def?

[<jue...@we...>]

This is actually pretty simple: We just need to allow for <list> (and =
<map>) as sub-element of <list> in the DTD - the bean factory can =
already handle any kind of nested element! I've just patched the DTD =
accordingly and committed it; a corresponding unit test passes (not =
committed yet due to other work).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, November 26, 2003 5:15 PM
To: spr...@li...
Subject: [Springframework-developer] How hard is is to add support for
list inside of a list, in an XML beanfactory def?


Right now in a bean factory xml definition, a list can not contain a=20
list. Can somebody who is more familiar with the bean wrapping estimate=20
how big a deal this would be to add?

The issue comes in using the MethodInvokingFactoryBean to invoke a=20
method which takes an array or list as an argument. Right now there is=20
no way to do it unfortunately.





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] How hard is is to add support for list inside of a list, in an XML beanfactory def?

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

Right now in a bean factory xml definition, a list can not contain a 
list. Can somebody who is more familiar with the bean wrapping estimate 
how big a deal this would be to add?

The issue comes in using the MethodInvokingFactoryBean to invoke a 
method which takes an array or list as an argument. Right now there is 
no way to do it unfortunately.

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

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] CVS problem

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

SF have fixed the problems and I've checked in the hot swapper.

I'm impressed with the quick turnaround!

Regards,
Rod

----- Original Message ----- 
From: "Rod Johnson" <rod...@in...>
To: <spr...@li...>
Sent: Wednesday, November 26, 2003 1:42 PM
Subject: Re: [Springframework-developer] CVS problem


> Done.
> ----- Original Message ----- 
> From: "jürgen höller [werk3AT]" <jue...@we...>
> To: <spr...@li...>
> Sent: Wednesday, November 26, 2003 1:08 PM
> Subject: RE: [Springframework-developer] CVS problem
>
>
> Rod, could you please contact SF support to resolve both issues? I guess
we
> can wait with checking in HotSwappableInvokerInterceptor until then.
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Colin Sampaleanu
> Sent: Wednesday, November 26, 2003 1:54 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] CVS problem
>
>
> I have seen this before. There will either be a variation of the same
> file in the Attic, on the server, that differs only by case. or there
> will be a lock file or some other metadata turd sitting around on the
> server. It needs to be resolved on the server unfortunately.   W/regards
> to the case issue, it doesn't matter if the server is not Win32. The
> problem is that the server is Unix, and makes a distinction between
> case, but the win32 client makes no distinction.
>
> What I would suggest doing is adding in the file with something like a
> '2' added to the end of the classname, then asking sf to fix up the
> repo, and then refactor the name. I have a feeling they will take a
> while to respond, so this is probably the easiest way to proceed.
>
> You can tell there is bad data on the server for this, when you do an
> update now in the src folder you now get this message:
>   cvs server: nothing known about
>
src/org/springframework/aop/interceptor/HotSwappableInvokerInterceptor.java
> We also have an existing issue in the test folder
>   cvs server: nothing known about
>
test/org/springframework/transaction/interceptor/MatchAllwaysTransactionAttr
> ibuteSourceTest.java
>
> These can only be resolved by SF.
>
>
> Rod Johnson wrote:
>
> >I'm sure there are some OS X users or Linux users among Spring
developers,
> >so we soon should be able to see...
> >
> >----- Original Message ----- 
> >From: "jürgen höller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Wednesday, November 26, 2003 11:50 AM
> >Subject: RE: [Springframework-developer] CVS problem
> >
> >
> >IntelliJ IDEA just delegates to cvs.exe, so this seems to be a problem
with
> >the Win32 version of the CVS client.
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...]On Behalf
> >Of Rod Johnson
> >Sent: Wednesday, November 26, 2003 12:49 PM
> >To: spr...@li...
> >Subject: [Springframework-developer] CVS problem
> >
> >
> >I've managed to commit the tests for this but I can't commit the class
> >itself despite repeated efforts. So our test suite is currently broken
:-(
> >
> >Juergen has encountered the same problem, with IntelliJ rather than
Eclipse
> >(see his message below).
> >
> >I've been having lots of problems with CVS lately.
> >
> >Can anyone shed any light on this--and hopefully commit it--or do we have
> to
> >contact SF support?
> >
> >Thanks,
> >Rod
> >
> >----- Original Message ----- 
> >From: "jürgen höller [werk3AT]" <jue...@we...>
> >To: "Rod Johnson" <rod...@in...>
> >Sent: Wednesday, November 26, 2003 11:31 AM
> >Subject: RE: Emailing: HotSwappableInvokerInterceptor.java
> >
> >
> >Seems to be a CVS bug. I get the following error message on commit:
> >
> >  cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
> >
> >I did a quick google search: That message is supposed to be caused by an
> >existing file with same name but different case on Win32. But there is no
> >such file in CVS, and the SourceForge servers are not running Windows,
are
> >they? So I guess it has something to do with the CVS client running on
> >Windows.
> >
> >I've also asked our CVS administrator at werk3AT; he couldn't help
either.
> >
> >Juergen
> >
> >
> >-----Original Message-----
> >From: Rod Johnson [mailto:rod...@in...]
> >Sent: Wednesday, November 26, 2003 11:47 AM
> >To: jürgen höller [werk3AT]
> >Subject: Emailing: HotSwappableInvokerInterceptor.java
> >
> >
> >
> >Juergen,
> >
> >Can you please try to commit this? I can't and I wonder whether it's an
> >Eclipse problem (I don't think it is).
> >
> >Unfortunately I succeeded in committing the tests, so the test suite now
> >fails :-(
> >
> >Thanks,
> >Rod
> >
> >
> >
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] CVS problem

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

Done.
----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, November 26, 2003 1:08 PM
Subject: RE: [Springframework-developer] CVS problem


Rod, could you please contact SF support to resolve both issues? I guess we
can wait with checking in HotSwappableInvokerInterceptor until then.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, November 26, 2003 1:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] CVS problem


I have seen this before. There will either be a variation of the same
file in the Attic, on the server, that differs only by case. or there
will be a lock file or some other metadata turd sitting around on the
server. It needs to be resolved on the server unfortunately.   W/regards
to the case issue, it doesn't matter if the server is not Win32. The
problem is that the server is Unix, and makes a distinction between
case, but the win32 client makes no distinction.

What I would suggest doing is adding in the file with something like a
'2' added to the end of the classname, then asking sf to fix up the
repo, and then refactor the name. I have a feeling they will take a
while to respond, so this is probably the easiest way to proceed.

You can tell there is bad data on the server for this, when you do an
update now in the src folder you now get this message:
  cvs server: nothing known about
src/org/springframework/aop/interceptor/HotSwappableInvokerInterceptor.java
We also have an existing issue in the test folder
  cvs server: nothing known about
test/org/springframework/transaction/interceptor/MatchAllwaysTransactionAttr
ibuteSourceTest.java

These can only be resolved by SF.


Rod Johnson wrote:

>I'm sure there are some OS X users or Linux users among Spring developers,
>so we soon should be able to see...
>
>----- Original Message ----- 
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Wednesday, November 26, 2003 11:50 AM
>Subject: RE: [Springframework-developer] CVS problem
>
>
>IntelliJ IDEA just delegates to cvs.exe, so this seems to be a problem with
>the Win32 version of the CVS client.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Wednesday, November 26, 2003 12:49 PM
>To: spr...@li...
>Subject: [Springframework-developer] CVS problem
>
>
>I've managed to commit the tests for this but I can't commit the class
>itself despite repeated efforts. So our test suite is currently broken :-(
>
>Juergen has encountered the same problem, with IntelliJ rather than Eclipse
>(see his message below).
>
>I've been having lots of problems with CVS lately.
>
>Can anyone shed any light on this--and hopefully commit it--or do we have
to
>contact SF support?
>
>Thanks,
>Rod
>
>----- Original Message ----- 
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: "Rod Johnson" <rod...@in...>
>Sent: Wednesday, November 26, 2003 11:31 AM
>Subject: RE: Emailing: HotSwappableInvokerInterceptor.java
>
>
>Seems to be a CVS bug. I get the following error message on commit:
>
>  cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
>
>I did a quick google search: That message is supposed to be caused by an
>existing file with same name but different case on Win32. But there is no
>such file in CVS, and the SourceForge servers are not running Windows, are
>they? So I guess it has something to do with the CVS client running on
>Windows.
>
>I've also asked our CVS administrator at werk3AT; he couldn't help either.
>
>Juergen
>
>
>-----Original Message-----
>From: Rod Johnson [mailto:rod...@in...]
>Sent: Wednesday, November 26, 2003 11:47 AM
>To: jürgen höller [werk3AT]
>Subject: Emailing: HotSwappableInvokerInterceptor.java
>
>
>
>Juergen,
>
>Can you please try to commit this? I can't and I wonder whether it's an
>Eclipse problem (I don't think it is).
>
>Unfortunately I succeeded in committing the tests, so the test suite now
>fails :-(
>
>Thanks,
>Rod
>
>
>





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] CVS problem

[<jue...@we...>]

Rod, could you please contact SF support to resolve both issues? I guess =
we can wait with checking in HotSwappableInvokerInterceptor until then.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, November 26, 2003 1:54 PM
To: spr...@li...
Subject: Re: [Springframework-developer] CVS problem


I have seen this before. There will either be a variation of the same=20
file in the Attic, on the server, that differs only by case. or there=20
will be a lock file or some other metadata turd sitting around on the=20
server. It needs to be resolved on the server unfortunately.   W/regards =

to the case issue, it doesn't matter if the server is not Win32. The=20
problem is that the server is Unix, and makes a distinction between=20
case, but the win32 client makes no distinction.

What I would suggest doing is adding in the file with something like a=20
'2' added to the end of the classname, then asking sf to fix up the=20
repo, and then refactor the name. I have a feeling they will take a=20
while to respond, so this is probably the easiest way to proceed.

You can tell there is bad data on the server for this, when you do an=20
update now in the src folder you now get this message:
  cvs server: nothing known about=20
src/org/springframework/aop/interceptor/HotSwappableInvokerInterceptor.ja=
va
We also have an existing issue in the test folder
  cvs server: nothing known about=20
test/org/springframework/transaction/interceptor/MatchAllwaysTransactionA=
ttributeSourceTest.java

These can only be resolved by SF.


Rod Johnson wrote:

>I'm sure there are some OS X users or Linux users among Spring =
developers,
>so we soon should be able to see...
>
>----- Original Message -----=20
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Wednesday, November 26, 2003 11:50 AM
>Subject: RE: [Springframework-developer] CVS problem
>
>
>IntelliJ IDEA just delegates to cvs.exe, so this seems to be a problem =
with
>the Win32 version of the CVS client.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Wednesday, November 26, 2003 12:49 PM
>To: spr...@li...
>Subject: [Springframework-developer] CVS problem
>
>
>I've managed to commit the tests for this but I can't commit the class
>itself despite repeated efforts. So our test suite is currently broken =
:-(
>
>Juergen has encountered the same problem, with IntelliJ rather than =
Eclipse
>(see his message below).
>
>I've been having lots of problems with CVS lately.
>
>Can anyone shed any light on this--and hopefully commit it--or do we =
have to
>contact SF support?
>
>Thanks,
>Rod
>
>----- Original Message -----=20
>From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
>To: "Rod Johnson" <rod...@in...>
>Sent: Wednesday, November 26, 2003 11:31 AM
>Subject: RE: Emailing: HotSwappableInvokerInterceptor.java
>
>
>Seems to be a CVS bug. I get the following error message on commit:
>
>  cvs: hash.c:312: findnode: Assertion `key !=3D ((void *)0)' failed.
>
>I did a quick google search: That message is supposed to be caused by =
an
>existing file with same name but different case on Win32. But there is =
no
>such file in CVS, and the SourceForge servers are not running Windows, =
are
>they? So I guess it has something to do with the CVS client running on
>Windows.
>
>I've also asked our CVS administrator at werk3AT; he couldn't help =
either.
>
>Juergen
>
>
>-----Original Message-----
>From: Rod Johnson [mailto:rod...@in...]
>Sent: Wednesday, November 26, 2003 11:47 AM
>To: j=FCrgen h=F6ller [werk3AT]
>Subject: Emailing: HotSwappableInvokerInterceptor.java
>
>
>
>Juergen,
>
>Can you please try to commit this? I can't and I wonder whether it's an
>Eclipse problem (I don't think it is).
>
>Unfortunately I succeeded in committing the tests, so the test suite =
now
>fails :-(
>
>Thanks,
>Rod
>
> =20
>





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] CVS problem

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

I have seen this before. There will either be a variation of the same 
file in the Attic, on the server, that differs only by case. or there 
will be a lock file or some other metadata turd sitting around on the 
server. It needs to be resolved on the server unfortunately.   W/regards 
to the case issue, it doesn't matter if the server is not Win32. The 
problem is that the server is Unix, and makes a distinction between 
case, but the win32 client makes no distinction.

What I would suggest doing is adding in the file with something like a 
'2' added to the end of the classname, then asking sf to fix up the 
repo, and then refactor the name. I have a feeling they will take a 
while to respond, so this is probably the easiest way to proceed.

You can tell there is bad data on the server for this, when you do an 
update now in the src folder you now get this message:
  cvs server: nothing known about 
src/org/springframework/aop/interceptor/HotSwappableInvokerInterceptor.java
We also have an existing issue in the test folder
  cvs server: nothing known about 
test/org/springframework/transaction/interceptor/MatchAllwaysTransactionAttributeSourceTest.java

These can only be resolved by SF.


Rod Johnson wrote:

>I'm sure there are some OS X users or Linux users among Spring developers,
>so we soon should be able to see...
>
>----- Original Message ----- 
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: <spr...@li...>
>Sent: Wednesday, November 26, 2003 11:50 AM
>Subject: RE: [Springframework-developer] CVS problem
>
>
>IntelliJ IDEA just delegates to cvs.exe, so this seems to be a problem with
>the Win32 version of the CVS client.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rod Johnson
>Sent: Wednesday, November 26, 2003 12:49 PM
>To: spr...@li...
>Subject: [Springframework-developer] CVS problem
>
>
>I've managed to commit the tests for this but I can't commit the class
>itself despite repeated efforts. So our test suite is currently broken :-(
>
>Juergen has encountered the same problem, with IntelliJ rather than Eclipse
>(see his message below).
>
>I've been having lots of problems with CVS lately.
>
>Can anyone shed any light on this--and hopefully commit it--or do we have to
>contact SF support?
>
>Thanks,
>Rod
>
>----- Original Message ----- 
>From: "jürgen höller [werk3AT]" <jue...@we...>
>To: "Rod Johnson" <rod...@in...>
>Sent: Wednesday, November 26, 2003 11:31 AM
>Subject: RE: Emailing: HotSwappableInvokerInterceptor.java
>
>
>Seems to be a CVS bug. I get the following error message on commit:
>
>  cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.
>
>I did a quick google search: That message is supposed to be caused by an
>existing file with same name but different case on Win32. But there is no
>such file in CVS, and the SourceForge servers are not running Windows, are
>they? So I guess it has something to do with the CVS client running on
>Windows.
>
>I've also asked our CVS administrator at werk3AT; he couldn't help either.
>
>Juergen
>
>
>-----Original Message-----
>From: Rod Johnson [mailto:rod...@in...]
>Sent: Wednesday, November 26, 2003 11:47 AM
>To: jürgen höller [werk3AT]
>Subject: Emailing: HotSwappableInvokerInterceptor.java
>
>
>
>Juergen,
>
>Can you please try to commit this? I can't and I wonder whether it's an
>Eclipse problem (I don't think it is).
>
>Unfortunately I succeeded in committing the tests, so the test suite now
>fails :-(
>
>Thanks,
>Rod
>
>  
>

Re: [Springframework-developer] CVS problem

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

I'm sure there are some OS X users or Linux users among Spring developers,
so we soon should be able to see...

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Wednesday, November 26, 2003 11:50 AM
Subject: RE: [Springframework-developer] CVS problem


IntelliJ IDEA just delegates to cvs.exe, so this seems to be a problem with
the Win32 version of the CVS client.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, November 26, 2003 12:49 PM
To: spr...@li...
Subject: [Springframework-developer] CVS problem


I've managed to commit the tests for this but I can't commit the class
itself despite repeated efforts. So our test suite is currently broken :-(

Juergen has encountered the same problem, with IntelliJ rather than Eclipse
(see his message below).

I've been having lots of problems with CVS lately.

Can anyone shed any light on this--and hopefully commit it--or do we have to
contact SF support?

Thanks,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Rod Johnson" <rod...@in...>
Sent: Wednesday, November 26, 2003 11:31 AM
Subject: RE: Emailing: HotSwappableInvokerInterceptor.java


Seems to be a CVS bug. I get the following error message on commit:

  cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.

I did a quick google search: That message is supposed to be caused by an
existing file with same name but different case on Win32. But there is no
such file in CVS, and the SourceForge servers are not running Windows, are
they? So I guess it has something to do with the CVS client running on
Windows.

I've also asked our CVS administrator at werk3AT; he couldn't help either.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, November 26, 2003 11:47 AM
To: jürgen höller [werk3AT]
Subject: Emailing: HotSwappableInvokerInterceptor.java



Juergen,

Can you please try to commit this? I can't and I wonder whether it's an
Eclipse problem (I don't think it is).

Unfortunately I succeeded in committing the tests, so the test suite now
fails :-(

Thanks,
Rod


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] CVS problem

[<jue...@we...>]

IntelliJ IDEA just delegates to cvs.exe, so this seems to be a problem =
with the Win32 version of the CVS client.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Wednesday, November 26, 2003 12:49 PM
To: spr...@li...
Subject: [Springframework-developer] CVS problem


I've managed to commit the tests for this but I can't commit the class
itself despite repeated efforts. So our test suite is currently broken =
:-(

Juergen has encountered the same problem, with IntelliJ rather than =
Eclipse
(see his message below).

I've been having lots of problems with CVS lately.

Can anyone shed any light on this--and hopefully commit it--or do we =
have to
contact SF support?

Thanks,
Rod

----- Original Message -----=20
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: "Rod Johnson" <rod...@in...>
Sent: Wednesday, November 26, 2003 11:31 AM
Subject: RE: Emailing: HotSwappableInvokerInterceptor.java


Seems to be a CVS bug. I get the following error message on commit:

  cvs: hash.c:312: findnode: Assertion `key !=3D ((void *)0)' failed.

I did a quick google search: That message is supposed to be caused by an
existing file with same name but different case on Win32. But there is =
no
such file in CVS, and the SourceForge servers are not running Windows, =
are
they? So I guess it has something to do with the CVS client running on
Windows.

I've also asked our CVS administrator at werk3AT; he couldn't help =
either.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, November 26, 2003 11:47 AM
To: j=FCrgen h=F6ller [werk3AT]
Subject: Emailing: HotSwappableInvokerInterceptor.java



Juergen,

Can you please try to commit this? I can't and I wonder whether it's an
Eclipse problem (I don't think it is).

Unfortunately I succeeded in committing the tests, so the test suite now
fails :-(

Thanks,
Rod

[Springframework-developer] CVS problem

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

I've managed to commit the tests for this but I can't commit the class
itself despite repeated efforts. So our test suite is currently broken :-(

Juergen has encountered the same problem, with IntelliJ rather than Eclipse
(see his message below).

I've been having lots of problems with CVS lately.

Can anyone shed any light on this--and hopefully commit it--or do we have to
contact SF support?

Thanks,
Rod

----- Original Message ----- 
From: "jürgen höller [werk3AT]" <jue...@we...>
To: "Rod Johnson" <rod...@in...>
Sent: Wednesday, November 26, 2003 11:31 AM
Subject: RE: Emailing: HotSwappableInvokerInterceptor.java


Seems to be a CVS bug. I get the following error message on commit:

  cvs: hash.c:312: findnode: Assertion `key != ((void *)0)' failed.

I did a quick google search: That message is supposed to be caused by an
existing file with same name but different case on Win32. But there is no
such file in CVS, and the SourceForge servers are not running Windows, are
they? So I guess it has something to do with the CVS client running on
Windows.

I've also asked our CVS administrator at werk3AT; he couldn't help either.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Wednesday, November 26, 2003 11:47 AM
To: jürgen höller [werk3AT]
Subject: Emailing: HotSwappableInvokerInterceptor.java



Juergen,

Can you please try to commit this? I can't and I wonder whether it's an
Eclipse problem (I don't think it is).

Unfortunately I succeeded in committing the tests, so the test suite now
fails :-(

Thanks,
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] SVG editor??? (and documentation)

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

Alef Arendsen (JTeam) wrote:

> All,
>
> Does anybody know a good SVG editor. I don't want to buy Illustrator 
> or Fireworks or something, just because I want to create a simple SVG 
> diagram.
>
> OpenOffice has SVG support, but it does not seem to be compliant 
> somehow (I'm getting errors when I'm putting an OpenOffice generated 
> SVG in a PDF using FOP). For UML stuff, I'm using ArgoUML, which is 
> quite ok, but for overview diagrams and stuff. Any ideas?
>
> Oh, and I've committed a little update on the reference docs. Did a 
> lot of work on the mvc controllers, pertty much covers everthing 
> except some examples and more detailed explanation on the form- and 
> commandcontrollers… It's getting somewhere I think :)
>
> Alef
>
> P.s. Trying out docbook internally now to do design docs (instead of 
> word). Works great (in the cvs, integrated into the CI build, 
> simultaneously working on designs is much easier now, while still 
> being able to maintain one document for a customer)…
>
Alef,

Depending on how complicated your documents are, you might want to take 
a look at Python's reStructructuredText (reST) library. I find it a lot 
easier to work with than something like DocBook, especially for 
something like design documentation.

You have a very easy to write source that has minimal markup, which is 
then transformed into HTML or PDF. Here's some samples from the Python 
PEPs (Python Enhancement Proposal)

the final HTML:
http://www.python.org/peps/pep-0321.html
the source:
http://www.python.org/peps/pep-0321.txt

the final HTML:
http://www.python.org/peps/pep-0012.html
the source:
http://www.python.org/peps/pep-0012.txt

Here's some info on reStructuredText:
http://docutils.sourceforge.net/docs/rst/quickstart.html
http://docutils.sourceforge.net/docs/rst/quickref.html
http://docutils.sourceforge.net/spec/rst/reStructuredText.html

If you use ZWiki, which is a Zope implementation of Wiki, it even 
supports reStructuredText as page types (does the output generation as 
soon as you look at the page), so you can author the documents 
collaboratively.

Regards,
Colin

RE: [Springframework-developer] Re: Spring Framework 1.0 M3 released

[Alef A. \(JTeam\) <al...@jt...>]

> So at this point it looks like as of the next release of 
> Hibernate 2.1 
> (beta or final, whatever it is), we have no choice but to 
> target either 
> Hibernate 2.0 (with cglib1), or Hibernate 2.1 (with cglib2), without 
> some extra effort.

I think I have to consider my last email as _not sent_ after reading
Chris' mail :))

[Springframework-developer] Re: Spring Framework 1.0 M3 released

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

Chris Nokleberg wrote:
> The original plan was for CGLIB 1.0 and 2.0 to be able to coexist
> peacefully. This was enabled by moving all of the net.sf.cglib.* classes
> into a new package (net.sf.cglib.proxy). However, we recently switched
> CGLIB 2.0 to use ASM 1.4, which is *not* binary compatible with ASM 1.3
> (which CGLIB 1.0 uses). This means that you can no longer use CGLIB 1.0
> and 2.0 in the same environment.

Actually there are two possibilities, if you need to support Hibernate 2.0
and 2.1 simultaneously, or just want to use CGLIB 1.0 for AOP but CGLIB 2.0
for Hib2.1:

a) Use the BCEL version of CGLIB 1.0. This adds an extra 350K, is slower to
generate classes, and has some thread safety issues. Also, many other
projects use BCEL so you are bound to run into some version conflicts here
anyway.

b) Fork the CGLIB 1.0 and ASM 1.3 sources, repackage ASM (e.g.
"org.springframework.asm") and change the CGLIB source to use the forked
package. It's easier than it sounds, but I'd still avoid it if possible.

Chris

[Springframework-developer] SVG editor??? (and documentation)

[Alef A. \(JTeam\) <al...@jt...>]

All,

Does anybody know a good SVG editor. I don't want to buy Illustrator or
Fireworks or something, just because I want to create a simple SVG
diagram.

OpenOffice has SVG support, but it does not seem to be compliant somehow
(I'm getting errors when I'm putting an OpenOffice generated SVG in a
PDF using FOP). For UML stuff, I'm using ArgoUML, which is quite ok, but
for overview diagrams and stuff. Any ideas?

Oh, and I've committed a little update on the reference docs. Did a lot
of work on the mvc controllers, pertty much covers everthing except some
examples and more detailed explanation on the form- and
commandcontrollers. It's getting somewhere I think :)

Alef

P.s. Trying out docbook internally now to do design docs (instead of
word). Works great (in the cvs, integrated into the CI build,
simultaneously working on designs is much easier now, while still being
able to maintain one document for a customer).

Re: [Springframework-developer] Re: Spring Framework 1.0 M3 released

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

Chris Nokleberg wrote:

>Colin Sampaleanu wrote:
>  
>
>>The issue is that Hibernate 2.1 is still in beta. So while it's
>>hopefully ok for them to go to cglib 2 in their beta, the same thing
>>does not necessarilly apply to us in our 1.0 RC and final releases. That
>>is, I don't personally know what state cglib 2 is right now. We have to
>>look at it ourselves. Even if we do go to cglib2, I think that may kill
>>our ability to work with Hibernate 2.0, if cglib2 is not totally upwards
>>compatible with cglib1. This is important to figure out...
>>    
>>
>
>I'm happy to answer any questions, but here is the current state of things.
>
>CGLIB 2.0 is currently released as beta1. Beta2 will be released "any day
>now". I don't anticipate many changes between beta2 and final.
>
>Hibernate 2.1 beta 6 (the latest release) still uses CGLIB 1.0. Hibernate
>2.1 CVS uses CGLIB from CVS (equivalent to upcoming beta2 code).
>
>I imagine that Hibernate 2.1 final will use whatever release of CGLIB is
>available at the time. It may be possible for us to release 2.0 final in
>tandem with Hibernate 2.1, but I'm not positive.
>
>The original plan was for CGLIB 1.0 and 2.0 to be able to coexist
>peacefully. This was enabled by moving all of the net.sf.cglib.* classes
>into a new package (net.sf.cglib.proxy). However, we recently switched
>CGLIB 2.0 to use ASM 1.4, which is *not* binary compatible with ASM 1.3
>(which CGLIB 1.0 uses). This means that you can no longer use CGLIB 1.0 and
>2.0 in the same environment.
>
>Practically, this means that you must upgrade to CGLIB 2.0 when you switch
>to supporting Hibernate 2.1. I really don't see a way around this. However,
>I've looked at your use of CGLIB and the changes are trivial, just renaming
>a few import statements. I can supply you with a patch when the time comes. 
>I would not worry about stability--your use of CGLIB is very simple, and in
>any case will be heavily tested by inclusion with Hibernate 2.1. 
>
>  
>
>>I'm actually unclear on why cglib embeds ASM themselves. It's a little
>>bit annoying, as I use AMS outside of cglib, and that fact that it's in
>>the cglib jar means I am tied to that version unless I want to do some
>>surgery.
>>    
>>
>
>Our build.xml creates two jar files, one that includes the ASM classes (the
>"full" version) and one that doesn't. Both versions are also available for
>download. Feel free to use the separate one. FYI at times CGLIB has
>depended on a CVS version of ASM but currently it is in sync with ASM 1.4. 
>
>Chris
>
>  
>
Thanks Chris. That clarifies things.

So at this point it looks like as of the next release of Hibernate 2.1 
(beta or final, whatever it is), we have no choice but to target either 
Hibernate 2.0 (with cglib1), or Hibernate 2.1 (with cglib2), without 
some extra effort.

We don't do an incredible amount with cglib, so we could possibly 
support both Hibernate versions by accessing cglib through some sort of 
wrapper. I'm not incredibly fond of this idea, especially as cglib2 and 
the newer asm look to offer some really nice capabilities, but it's an 
option...

Now taking a second look at your statements more carefully.

Colin

RE: [Springframework-developer] Spring Framework 1.0 M3 released

[Alef A. \(JTeam\) <al...@jt...>]

> or if we want to stick with=20
> Hibernate 2.0=20
> for a bit longer.
I don't know. Personally I don't think we will have much problem with
the transition to 2.1, but I don't know about other people. Are there
any significant differences between Hibernate 2.1 and 2.0 that would
convince us to switch, besides the CGLIB stuff? If there aren't any
major compatibility-issues I would prefer checking both CGLIB1 and 2
(thus supporting both Hib 2.0 and 2.1), but that might generatea lot of
work... It would however allow people having Spring mX in production
already to change to Spring 1.0 without changing Hibernate version...

Just some thougts...


> Regards,
> Colin
>=20
> Colin Sampaleanu wrote:
>=20
> > The issue is that Hibernate 2.1 is still in beta. So while it's
> > hopefully ok for them to go to cglib 2 in their beta, the=20
> same thing=20
> > does not necessarilly apply to us in our 1.0 RC and final releases.=20
> > That is, I don't personally know what state cglib 2 is=20
> right now. We=20
> > have to look at it ourselves. Even if we do go to cglib2, I=20
> think that=20
> > may kill our ability to work with Hibernate 2.0, if cglib2 is not=20
> > totally upwards compatible with cglib1. This is important to figure=20
> > out...
> >
> > I'm actually unclear on why cglib embeds ASM themselves.=20
> It's a little
> > bit annoying, as I use AMS outside of cglib, and that fact=20
> that it's=20
> > in the cglib jar means I am tied to that version unless I=20
> want to do=20
> > some surgery.
> >
> >
> > j=FCrgen h=F6ller [werk3AT] wrote:
> >
> >> Looking forward, I'm keen on getting out RC1 in December, right
> >> before Christmas if necessary - the goal as I see it is=20
> "this year".=20
> >> Our main concern will be documentation, I guess, as=20
> everything else=20
> >> should just be about bug-fixing and refining. If anyone=20
> wants to add=20
> >> a major new feature, feel free to go ahead but please tell=20
> the group=20
> >> and hurry up ;-)
> >>
> >> One point to get right for RC1 is correct packaging of third-party
> >> libraries. Like Hibernate, we should include the licenses of all=20
> >> packages that we ship. And we should update to the current=20
> versions=20
> >> of all libs. In particular, we need to pay attention to Hibernate=20
> >> 2.1: IIRC, they switched to CGLIB2 in the 2.1 tree, so we should=20
> >> check if our AOP framework can work with that too. After=20
> all, we have=20
> >> numerous users combining Hibernate and Spring's declarative=20
> >> transaction management.
> >>
> >> Agreement? Wishes? Complaints?
> >>
> >> Juergen
> >>
> >>
> >> ________________________________
> >>
> >> Von: spr...@li...=20
> im Auftrag
> >> von j=FCrgen h=F6ller [werk3AT]
> >> Gesendet: Di 25.11.2003 12:47
> >> An: spr...@li...;=20
> >> spr...@li...
> >> Betreff: [Springframework-developer] Spring Framework 1.0=20
> M3 released
> >>
> >>
> >>
> >> Hello everybody,
> >>
> >> I'm pleased to announce the release of Spring Framework=20
> 1.0 M3. This
> >> is the fifth public release towards 1.0 final.  As you can=20
> see in the=20
> >> changelog, there have been lots of changes in this iteration. The=20
> >> next release will be 1.0 RC1; we do not plan any further milestone=20
> >> releases.
> >>
> >> M3 introduces significant new features and enhancements,=20
> among them:
> >> - Type 3 IoC support in the bean factory (constructor resolution)
> >> - bean factory SPI interfaces (package bean.factory.config)
> >> - redesigned AOP API (more flexible pointcut handling etc)
> >> - reworked and optimized transaction manager implementations
> >> - fine-grained JDBC exception handling in the Hibernate support
> >> - reworked JDO support with a new JdoDialect strategy
> >> - reworked exception handling in the web framework
> >> - working Tiles example application included
> >>
> >> Some of the changes will need migration of existing code, most=20
> >> notably:
> >> - Controllers are now allowed to throw Exception (affecting=20
> >> BaseCommandController and AbstractFormController)
> >> - some of BeanCommandController's methods have been renamed
> >> - ServletRequestDataBinder contains a BindException now instead of=20
> >> deriving from it
> >>
> >> Typical application code should not be affected as we have kept
> >> deprecated methods. We recommend to migrate promptly though, as we=20
> >> intend to drop the deprecated methods before 1.0 final. See=20
> >> changes-M2-M3.txt for details.
> >>
> >> Regards,
> >> Juergen
> >>  =20
> >
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it=20
> help you create better code?  SHARE THE LOVE, and help us=20
> help YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] Service Data Objects

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

On the Hibernate mailing list, I saw a reference to a new joint JSR 
proposal (by IBM and BEA) for something called Service Data Objects. 
Looks pretty interesting actually, and has some potential future 
implications for Spring.

http://www-106.ibm.com/developerworks/library/j-commonj-sdowmt/
http://siliconvalley.internet.com/news/article.php/3113361
ftp://www6.software.ibm.com/software/developer/library/j-commonj-sdowmt/Next-Gen-Data-Programming-Whitepaper.doc

Here's Gavin's email:
-----
From: Gavin King <gavin@hi...>
* Re: "service data objects"?* 
<http://sourceforge.net/mailarchive/message.php?msg_id=6621942>  
2003-11-25 16:13

 Nah this is way more ambitious. This looks a little bit like carrierwave 
 plus some other ideas. Read the whitepaper:
 
 http://www-106.ibm.com/developerworks/library/j-commonj-sdowmt/
 
 The even mention Hibernate twice.
 
 Very interesting stuff. They are talking about externalizable object 
 graphs and re-synchronizing with optimistic semantics, which is a HUGE 
 validation of what we've been doing for the past two years. ;)
 
 On the surface it looks almost a little bit like OFBiz + carrierwave + 
 some XML stuff. I need to get a feel for how (if) it all hangs together.
 
 Christian Bauer wrote:
 > On 26 Nov (02:51), Gavin King wrote:
 > 
 > 
 >>http://siliconvalley.internet.com/news/article.php/3113361
 > 
 > 
 > I remember BEA opening some of their code lately, and if I'm correct, it
 > was some XML data binding framework stuff.
 > 
----- 

[Springframework-developer] Re: Spring Framework 1.0 M3 released

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

Colin Sampaleanu wrote:
> The issue is that Hibernate 2.1 is still in beta. So while it's
> hopefully ok for them to go to cglib 2 in their beta, the same thing
> does not necessarilly apply to us in our 1.0 RC and final releases. That
> is, I don't personally know what state cglib 2 is right now. We have to
> look at it ourselves. Even if we do go to cglib2, I think that may kill
> our ability to work with Hibernate 2.0, if cglib2 is not totally upwards
> compatible with cglib1. This is important to figure out...

I'm happy to answer any questions, but here is the current state of things.

CGLIB 2.0 is currently released as beta1. Beta2 will be released "any day
now". I don't anticipate many changes between beta2 and final.

Hibernate 2.1 beta 6 (the latest release) still uses CGLIB 1.0. Hibernate
2.1 CVS uses CGLIB from CVS (equivalent to upcoming beta2 code).

I imagine that Hibernate 2.1 final will use whatever release of CGLIB is
available at the time. It may be possible for us to release 2.0 final in
tandem with Hibernate 2.1, but I'm not positive.

The original plan was for CGLIB 1.0 and 2.0 to be able to coexist
peacefully. This was enabled by moving all of the net.sf.cglib.* classes
into a new package (net.sf.cglib.proxy). However, we recently switched
CGLIB 2.0 to use ASM 1.4, which is *not* binary compatible with ASM 1.3
(which CGLIB 1.0 uses). This means that you can no longer use CGLIB 1.0 and
2.0 in the same environment.

Practically, this means that you must upgrade to CGLIB 2.0 when you switch
to supporting Hibernate 2.1. I really don't see a way around this. However,
I've looked at your use of CGLIB and the changes are trivial, just renaming
a few import statements. I can supply you with a patch when the time comes. 
I would not worry about stability--your use of CGLIB is very simple, and in
any case will be heavily tested by inclusion with Hibernate 2.1. 

> I'm actually unclear on why cglib embeds ASM themselves. It's a little
> bit annoying, as I use AMS outside of cglib, and that fact that it's in
> the cglib jar means I am tied to that version unless I want to do some
> surgery.

Our build.xml creates two jar files, one that includes the ASM classes (the
"full" version) and one that doesn't. Both versions are also available for
download. Feel free to use the separate one. FYI at times CGLIB has
depended on a CVS version of ASM but currently it is in sync with ASM 1.4. 

Chris

Re: [Springframework-developer] Spring Framework 1.0 M3 released

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

According to this email:
  
http://sourceforge.net/mailarchive/forum.php?thread_id=3471802&forum_id=7517
the Hibernate team is aiming for a Hibernate 2.1 release before Dec. 14th.

Assuming that does go through, that makes the decision process a bit 
simpler for us; we just have to decide if we are targetting the released 
Hibernate 2.1 and its cglib, or if we want to stick with Hibernate 2.0 
for a bit longer. Personally I favour the former, in that I'm already 
using Hibernate 2.1beta6 with Spring right now, but other people may 
have other opinions...

Regards,
Colin

Colin Sampaleanu wrote:

> The issue is that Hibernate 2.1 is still in beta. So while it's 
> hopefully ok for them to go to cglib 2 in their beta, the same thing 
> does not necessarilly apply to us in our 1.0 RC and final releases. 
> That is, I don't personally know what state cglib 2 is right now. We 
> have to look at it ourselves. Even if we do go to cglib2, I think that 
> may kill our ability to work with Hibernate 2.0, if cglib2 is not 
> totally upwards compatible with cglib1. This is important to figure 
> out...
>
> I'm actually unclear on why cglib embeds ASM themselves. It's a little 
> bit annoying, as I use AMS outside of cglib, and that fact that it's 
> in the cglib jar means I am tied to that version unless I want to do 
> some surgery.
>
>
> jürgen höller [werk3AT] wrote:
>
>> Looking forward, I'm keen on getting out RC1 in December, right 
>> before Christmas if necessary - the goal as I see it is "this year". 
>> Our main concern will be documentation, I guess, as everything else 
>> should just be about bug-fixing and refining. If anyone wants to add 
>> a major new feature, feel free to go ahead but please tell the group 
>> and hurry up ;-)
>>
>> One point to get right for RC1 is correct packaging of third-party 
>> libraries. Like Hibernate, we should include the licenses of all 
>> packages that we ship. And we should update to the current versions 
>> of all libs. In particular, we need to pay attention to Hibernate 
>> 2.1: IIRC, they switched to CGLIB2 in the 2.1 tree, so we should 
>> check if our AOP framework can work with that too. After all, we have 
>> numerous users combining Hibernate and Spring's declarative 
>> transaction management.
>>
>> Agreement? Wishes? Complaints?
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag 
>> von jürgen höller [werk3AT]
>> Gesendet: Di 25.11.2003 12:47
>> An: spr...@li...; 
>> spr...@li...
>> Betreff: [Springframework-developer] Spring Framework 1.0 M3 released
>>
>>
>>
>> Hello everybody,
>>
>> I'm pleased to announce the release of Spring Framework 1.0 M3. This 
>> is the fifth public release towards 1.0 final.  As you can see in the 
>> changelog, there have been lots of changes in this iteration. The 
>> next release will be 1.0 RC1; we do not plan any further milestone 
>> releases.
>>
>> M3 introduces significant new features and enhancements, among them:
>> - Type 3 IoC support in the bean factory (constructor resolution)
>> - bean factory SPI interfaces (package bean.factory.config)
>> - redesigned AOP API (more flexible pointcut handling etc)
>> - reworked and optimized transaction manager implementations
>> - fine-grained JDBC exception handling in the Hibernate support
>> - reworked JDO support with a new JdoDialect strategy
>> - reworked exception handling in the web framework
>> - working Tiles example application included
>>
>> Some of the changes will need migration of existing code, most notably:
>> - Controllers are now allowed to throw Exception (affecting 
>> BaseCommandController and AbstractFormController)
>> - some of BeanCommandController's methods have been renamed
>> - ServletRequestDataBinder contains a BindException now instead of 
>> deriving from it
>>
>> Typical application code should not be affected as we have kept 
>> deprecated methods. We recommend to migrate promptly though, as we 
>> intend to drop the deprecated methods before 1.0 final. See 
>> changes-M2-M3.txt for details.
>>
>> Regards,
>> Juergen
>>   
>

Re: [Springframework-developer] Spring Framework 1.0 M3 released

[<jue...@we...>]

I rather meant that we should check whether CGLIB2 is compatible with =
our current AOP framework. CGLIB2 is still in beta, so we shouldn't rely =
on it, I agree. But we need to figure out a way to work with both =
Hibernate 2.1 and our AOP framework in the same application, as this =
will be a common combo at the time of our 1.0 final.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Di 25.11.2003 22:09
An: spr...@li...
Betreff: Re: [Springframework-developer] Spring Framework 1.0 M3 =
released



The issue is that Hibernate 2.1 is still in beta. So while it's
hopefully ok for them to go to cglib 2 in their beta, the same thing
does not necessarilly apply to us in our 1.0 RC and final releases. That
is, I don't personally know what state cglib 2 is right now. We have to
look at it ourselves. Even if we do go to cglib2, I think that may kill
our ability to work with Hibernate 2.0, if cglib2 is not totally upwards
compatible with cglib1. This is important to figure out...

I'm actually unclear on why cglib embeds ASM themselves. It's a little
bit annoying, as I use AMS outside of cglib, and that fact that it's in
the cglib jar means I am tied to that version unless I want to do some
surgery.


j=FCrgen h=F6ller [werk3AT] wrote:

>Looking forward, I'm keen on getting out RC1 in December, right before =
Christmas if necessary - the goal as I see it is "this year". Our main =
concern will be documentation, I guess, as everything else should just =
be about bug-fixing and refining. If anyone wants to add a major new =
feature, feel free to go ahead but please tell the group and hurry up =
;-)
>
>One point to get right for RC1 is correct packaging of third-party =
libraries. Like Hibernate, we should include the licenses of all =
packages that we ship. And we should update to the current versions of =
all libs. In particular, we need to pay attention to Hibernate 2.1: =
IIRC, they switched to CGLIB2 in the 2.1 tree, so we should check if our =
AOP framework can work with that too. After all, we have numerous users =
combining Hibernate and Spring's declarative transaction management.
>
>Agreement? Wishes? Complaints?
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
>Gesendet: Di 25.11.2003 12:47
>An: spr...@li...; =
spr...@li...
>Betreff: [Springframework-developer] Spring Framework 1.0 M3 released
>
>
>
>Hello everybody,
>
>I'm pleased to announce the release of Spring Framework 1.0 M3. This is =
the fifth public release towards 1.0 final.  As you can see in the =
changelog, there have been lots of changes in this iteration. The next =
release will be 1.0 RC1; we do not plan any further milestone releases.
>
>M3 introduces significant new features and enhancements, among them:
>- Type 3 IoC support in the bean factory (constructor resolution)
>- bean factory SPI interfaces (package bean.factory.config)
>- redesigned AOP API (more flexible pointcut handling etc)
>- reworked and optimized transaction manager implementations
>- fine-grained JDBC exception handling in the Hibernate support
>- reworked JDO support with a new JdoDialect strategy
>- reworked exception handling in the web framework
>- working Tiles example application included
>
>Some of the changes will need migration of existing code, most notably:
>- Controllers are now allowed to throw Exception (affecting =
BaseCommandController and AbstractFormController)
>- some of BeanCommandController's methods have been renamed
>- ServletRequestDataBinder contains a BindException now instead of =
deriving from it
>
>Typical application code should not be affected as we have kept =
deprecated methods. We recommend to migrate promptly though, as we =
intend to drop the deprecated methods before 1.0 final. See =
changes-M2-M3.txt for details.
>
>Regards,
>Juergen
>=20
>




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer