springframework-developer

[Springframework-developer] Please check these two things

[Dave B. <dbr...@qi...>]

These may be problems, and then again maybe not. But they seem odd/wrong =
to me


1) In org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

in method invoke

uses wait on 'this'

In my mind you are exposing your synchronization strategies as a public =
artifact, which leaves this class open to failure due to client code.=20
The client code may unwittingly us an instance of this class to do it's =
own synchronization, and totally screw up this class.
I would recommend doing synchronizations (especially the use of =
wait/notify) on a private member so client code can not effect it.



2) In org.springframework.jdbc.object.BatchSqlUpdate

in method update, you do

  if (!this.parameterQueue.isEmpty() && =
args.equals(this.parameterQueue.getLast())) {

this is the same as using     args =3D=3D this.parameterQueue.getLast()

or in other words, are these objects the same object. I assume you want =
to compare the elements of the array?

Re: [Springframework-developer] Please check these two things

[Juergen H. <ju...@in...>]

Well-spotted!

ConcurrencyThrottleInterceptor should indeed use an internal monitor to
avoid any potential for side effects. I doubt that this has caused any issue
in practice, but it's nevertheless cleaner.

That check in BatchSqlUpdate is not supposed to compare the elements but
just the array reference: Repeated update invocations should not pass-in the
same array instance repeatedly, with modified elements. Of course, a ==
check would be sufficient for this. I've reworked that part a bit
differently, though: BatchSqlUpdate stores a clone of the passed-in array
now, so there shouldn't be a need for such a check anymore.

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Dave Brosius
  Sent: Tuesday, February 22, 2005 8:08 AM
  To: spr...@li...
  Subject: [Springframework-developer] Please check these two things


  These may be problems, and then again maybe not. But they seem odd/wrong
to me


  1) In org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

  in method invoke

  uses wait on 'this'

  In my mind you are exposing your synchronization strategies as a public
artifact, which leaves this class open to failure due to client code.
  The client code may unwittingly us an instance of this class to do it's
own synchronization, and totally screw up this class.
  I would recommend doing synchronizations (especially the use of
wait/notify) on a private member so client code can not effect it.



  2) In org.springframework.jdbc.object.BatchSqlUpdate

  in method update, you do

    if (!this.parameterQueue.isEmpty() &&
args.equals(this.parameterQueue.getLast())) {

  this is the same as using     args == this.parameterQueue.getLast()

  or in other words, are these objects the same object. I assume you want to
compare the elements of the array?

Re: [Springframework-developer] Please check these two things

[Martin K. <Mar...@St...>]

But isn't this bogus thinking? I mean replacing .equals with =3D=3D =
makes=20
the implementation more strickt and reduces semantical informations.
We are thinking about objects and there is no performance gap
to justify this modification.

I wouldn't do it. I just would ensure that equals implementations=20
start with if(this=3D=3Dobject) return true;. How huge is the estimated
performance gain?


Cheers,

Martin (Kersten)
  ----- Original Message -----=20
  From: Juergen Hoeller=20
  To: spr...@li...=20
  Sent: Tuesday, February 22, 2005 10:06 AM
  Subject: Re: [Springframework-developer] Please check these two things


  Well-spotted!

  ConcurrencyThrottleInterceptor should indeed use an internal monitor =
to avoid any potential for side effects. I doubt that this has caused =
any issue in practice, but it's nevertheless cleaner.

  That check in BatchSqlUpdate is not supposed to compare the elements =
but just the array reference: Repeated update invocations should not =
pass-in the same array instance repeatedly, with modified elements. Of =
course, a =3D=3D check would be sufficient for this. I've reworked that =
part a bit differently, though: BatchSqlUpdate stores a clone of the =
passed-in array now, so there shouldn't be a need for such a check =
anymore.

  Juergen


    -----Original Message-----
    From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dave Brosius
    Sent: Tuesday, February 22, 2005 8:08 AM
    To: spr...@li...
    Subject: [Springframework-developer] Please check these two things


    These may be problems, and then again maybe not. But they seem =
odd/wrong to me


    1) In =
org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

    in method invoke

    uses wait on 'this'

    In my mind you are exposing your synchronization strategies as a =
public artifact, which leaves this class open to failure due to client =
code.=20
    The client code may unwittingly us an instance of this class to do =
it's own synchronization, and totally screw up this class.
    I would recommend doing synchronizations (especially the use of =
wait/notify) on a private member so client code can not effect it.



    2) In org.springframework.jdbc.object.BatchSqlUpdate

    in method update, you do

      if (!this.parameterQueue.isEmpty() && =
args.equals(this.parameterQueue.getLast())) {

    this is the same as using     args =3D=3D =
this.parameterQueue.getLast()

    or in other words, are these objects the same object. I assume you =
want to compare the elements of the array?

Re: [Springframework-developer] Please check these two things

[Juergen H. <ju...@in...>]

Actually, I have *not* replaced this with a == comparison of the arrays:
Instead, BatchSqlUpdate is storing clones of the passed-in arrays now, for
execution on flush. This avoids any side effects in the first place (even if
the passed-in arrays are changed afterwards or reused for multiple update
inovcations), and the overhead of cloning an array should be acceptable
(after all, we're talking about database update operations here).

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Martin Kersten
  Sent: Tuesday, February 22, 2005 12:04 PM
  To: spr...@li...
  Subject: Re: [Springframework-developer] Please check these two things


  But isn't this bogus thinking? I mean replacing .equals with == makes
  the implementation more strickt and reduces semantical informations.
  We are thinking about objects and there is no performance gap
  to justify this modification.

  I wouldn't do it. I just would ensure that equals implementations
  start with if(this==object) return true;. How huge is the estimated
  performance gain?


  Cheers,

  Martin (Kersten)
    ----- Original Message -----
    From: Juergen Hoeller
    To: spr...@li...
    Sent: Tuesday, February 22, 2005 10:06 AM
    Subject: Re: [Springframework-developer] Please check these two things


    Well-spotted!

    ConcurrencyThrottleInterceptor should indeed use an internal monitor to
avoid any potential for side effects. I doubt that this has caused any issue
in practice, but it's nevertheless cleaner.

    That check in BatchSqlUpdate is not supposed to compare the elements but
just the array reference: Repeated update invocations should not pass-in the
same array instance repeatedly, with modified elements. Of course, a ==
check would be sufficient for this. I've reworked that part a bit
differently, though: BatchSqlUpdate stores a clone of the passed-in array
now, so there shouldn't be a need for such a check anymore.

    Juergen


      -----Original Message-----
      From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Dave Brosius
      Sent: Tuesday, February 22, 2005 8:08 AM
      To: spr...@li...
      Subject: [Springframework-developer] Please check these two things


      These may be problems, and then again maybe not. But they seem
odd/wrong to me


      1) In
org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

      in method invoke

      uses wait on 'this'

      In my mind you are exposing your synchronization strategies as a
public artifact, which leaves this class open to failure due to client code.
      The client code may unwittingly us an instance of this class to do
it's own synchronization, and totally screw up this class.
      I would recommend doing synchronizations (especially the use of
wait/notify) on a private member so client code can not effect it.



      2) In org.springframework.jdbc.object.BatchSqlUpdate

      in method update, you do

        if (!this.parameterQueue.isEmpty() &&
args.equals(this.parameterQueue.getLast())) {

      this is the same as using     args == this.parameterQueue.getLast()

      or in other words, are these objects the same object. I assume you
want to compare the elements of the array?

Re: [Springframework-developer] Please check these two things

[Martin K. <Mar...@St...>]

Sorry, thought the agreement goes with the callee.=20
Ok :-) sorry was a strange day for me, I guess.

Thanks,

Martin (Kersten)
----- Original Message -----=20
  From: Juergen Hoeller=20
  To: spr...@li...=20
  Sent: Tuesday, February 22, 2005 12:13 PM
  Subject: Re: [Springframework-developer] Please check these two things


  Actually, I have *not* replaced this with a =3D=3D comparison of the =
arrays: Instead, BatchSqlUpdate is storing clones of the passed-in =
arrays now, for execution on flush. This avoids any side effects in the =
first place (even if the passed-in arrays are changed afterwards or =
reused for multiple update inovcations), and the overhead of cloning an =
array should be acceptable (after all, we're talking about database =
update operations here).

  Juergen


    -----Original Message-----
    From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Martin Kersten
    Sent: Tuesday, February 22, 2005 12:04 PM
    To: spr...@li...
    Subject: Re: [Springframework-developer] Please check these two =
things


    But isn't this bogus thinking? I mean replacing .equals with =3D=3D =
makes=20
    the implementation more strickt and reduces semantical informations.
    We are thinking about objects and there is no performance gap
    to justify this modification.

    I wouldn't do it. I just would ensure that equals implementations=20
    start with if(this=3D=3Dobject) return true;. How huge is the =
estimated
    performance gain?


    Cheers,

    Martin (Kersten)
      ----- Original Message -----=20
      From: Juergen Hoeller=20
      To: spr...@li...=20
      Sent: Tuesday, February 22, 2005 10:06 AM
      Subject: Re: [Springframework-developer] Please check these two =
things


      Well-spotted!

      ConcurrencyThrottleInterceptor should indeed use an internal =
monitor to avoid any potential for side effects. I doubt that this has =
caused any issue in practice, but it's nevertheless cleaner.

      That check in BatchSqlUpdate is not supposed to compare the =
elements but just the array reference: Repeated update invocations =
should not pass-in the same array instance repeatedly, with modified =
elements. Of course, a =3D=3D check would be sufficient for this. I've =
reworked that part a bit differently, though: BatchSqlUpdate stores a =
clone of the passed-in array now, so there shouldn't be a need for such =
a check anymore.

      Juergen


        -----Original Message-----
        From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dave Brosius
        Sent: Tuesday, February 22, 2005 8:08 AM
        To: spr...@li...
        Subject: [Springframework-developer] Please check these two =
things


        These may be problems, and then again maybe not. But they seem =
odd/wrong to me


        1) In =
org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

        in method invoke

        uses wait on 'this'

        In my mind you are exposing your synchronization strategies as a =
public artifact, which leaves this class open to failure due to client =
code.=20
        The client code may unwittingly us an instance of this class to =
do it's own synchronization, and totally screw up this class.
        I would recommend doing synchronizations (especially the use of =
wait/notify) on a private member so client code can not effect it.



        2) In org.springframework.jdbc.object.BatchSqlUpdate

        in method update, you do

          if (!this.parameterQueue.isEmpty() && =
args.equals(this.parameterQueue.getLast())) {

        this is the same as using     args =3D=3D =
this.parameterQueue.getLast()

        or in other words, are these objects the same object. I assume =
you want to compare the elements of the array?

[Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

Hi folks,
=20
   I am currently trying to extend the framework by supporting =
contributions.=20
Just to see how it feels.

So I made some investigations in the sourcecode. I don't want to start a =
war=20
about proper design rules, since I am a believer in 'Interface belongs =
to the
client' stuff and you are appearently not, but this isn't the issue I =
want to
talk about.

Th implementation I hate most on first sight is the=20
XMLBeanDefinitionParser. I know it does what it should but you can read =
this:

 /**
  * Make the horrible DOM API slightly more bearable:
  * get the text value we know this element contains.
  */

Well I would agree but it's a bit wired also. You think the DOM API is =
horrible
and you are still using it? You know what it means to use a=20
horrible API? You write a horrible implementation! And thats how it =
looks.=20
It took me more then a gaze to catch the meaning of the parser and I =
also
got blown by the code duplication. Since I am in need to extend this =
class,

So I would like to ask if I may refactor it and commit you a patch (or =
maybe
a complete reimplementation)?


Cheers,

Martin (Kersten)

PS: By the way, how about 'Hidding 3rd party library behind single =
interface?'
  ----- Original Message -----=20
  From: Martin Kersten=20
  To: spr...@li...=20
  Sent: Tuesday, February 22, 2005 12:46 PM
  Subject: Re: [Springframework-developer] Please check these two things


  Sorry, thought the agreement goes with the callee.=20
  Ok :-) sorry was a strange day for me, I guess.

  Thanks,

  Martin (Kersten)
  ----- Original Message -----=20
    From: Juergen Hoeller=20
    To: spr...@li...=20
    Sent: Tuesday, February 22, 2005 12:13 PM
    Subject: Re: [Springframework-developer] Please check these two =
things


    Actually, I have *not* replaced this with a =3D=3D comparison of the =
arrays: Instead, BatchSqlUpdate is storing clones of the passed-in =
arrays now, for execution on flush. This avoids any side effects in the =
first place (even if the passed-in arrays are changed afterwards or =
reused for multiple update inovcations), and the overhead of cloning an =
array should be acceptable (after all, we're talking about database =
update operations here).

    Juergen


      -----Original Message-----
      From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Martin Kersten
      Sent: Tuesday, February 22, 2005 12:04 PM
      To: spr...@li...
      Subject: Re: [Springframework-developer] Please check these two =
things


      But isn't this bogus thinking? I mean replacing .equals with =
=3D=3D makes=20
      the implementation more strickt and reduces semantical =
informations.
      We are thinking about objects and there is no performance gap
      to justify this modification.

      I wouldn't do it. I just would ensure that equals implementations=20
      start with if(this=3D=3Dobject) return true;. How huge is the =
estimated
      performance gain?


      Cheers,

      Martin (Kersten)
        ----- Original Message -----=20
        From: Juergen Hoeller=20
        To: spr...@li...=20
        Sent: Tuesday, February 22, 2005 10:06 AM
        Subject: Re: [Springframework-developer] Please check these two =
things


        Well-spotted!

        ConcurrencyThrottleInterceptor should indeed use an internal =
monitor to avoid any potential for side effects. I doubt that this has =
caused any issue in practice, but it's nevertheless cleaner.

        That check in BatchSqlUpdate is not supposed to compare the =
elements but just the array reference: Repeated update invocations =
should not pass-in the same array instance repeatedly, with modified =
elements. Of course, a =3D=3D check would be sufficient for this. I've =
reworked that part a bit differently, though: BatchSqlUpdate stores a =
clone of the passed-in array now, so there shouldn't be a need for such =
a check anymore.

        Juergen


          -----Original Message-----
          From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dave Brosius
          Sent: Tuesday, February 22, 2005 8:08 AM
          To: spr...@li...
          Subject: [Springframework-developer] Please check these two =
things


          These may be problems, and then again maybe not. But they seem =
odd/wrong to me


          1) In =
org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

          in method invoke

          uses wait on 'this'

          In my mind you are exposing your synchronization strategies as =
a public artifact, which leaves this class open to failure due to client =
code.=20
          The client code may unwittingly us an instance of this class =
to do it's own synchronization, and totally screw up this class.
          I would recommend doing synchronizations (especially the use =
of wait/notify) on a private member so client code can not effect it.



          2) In org.springframework.jdbc.object.BatchSqlUpdate

          in method update, you do

            if (!this.parameterQueue.isEmpty() && =
args.equals(this.parameterQueue.getLast())) {

          this is the same as using     args =3D=3D =
this.parameterQueue.getLast()

          or in other words, are these objects the same object. I assume =
you want to compare the elements of the array?

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Erwin V. <erw...@er...>]

I think the main reason to use the W3C DOM API directly is to avoid the =
need for an extra dependency (e.g. JDOM) just to parse the XML bean =
definitions. You end up with an "less than elegant" implementation in =
DefaultXmlBeanDefinitionParser, but in this case the benifits outweigh =
the costs.

Erwin Vervaet
erw...@er...
  ----- Original Message -----=20
  From: Martin Kersten=20
  To: spr...@li...=20
  Sent: Tuesday, February 22, 2005 1:21 PM
  Subject: [Springframework-developer] I don't like the =
DefaultXmlBeanDefinitionParser


  Hi folks,

     I am currently trying to extend the framework by supporting =
contributions.=20
  Just to see how it feels.

  So I made some investigations in the sourcecode. I don't want to start =
a war=20
  about proper design rules, since I am a believer in 'Interface belongs =
to the
  client' stuff and you are appearently not, but this isn't the issue I =
want to
  talk about.

  Th implementation I hate most on first sight is the=20
  XMLBeanDefinitionParser. I know it does what it should but you can =
read this:

   /**
    * Make the horrible DOM API slightly more bearable:
    * get the text value we know this element contains.
    */

  Well I would agree but it's a bit wired also. You think the DOM API is =
horrible
  and you are still using it? You know what it means to use a=20
  horrible API? You write a horrible implementation! And thats how it =
looks.=20
  It took me more then a gaze to catch the meaning of the parser and I =
also
  got blown by the code duplication. Since I am in need to extend this =
class,

  So I would like to ask if I may refactor it and commit you a patch (or =
maybe
  a complete reimplementation)?


  Cheers,

  Martin (Kersten)

  PS: By the way, how about 'Hidding 3rd party library behind single =
interface?'
    ----- Original Message -----=20
    From: Martin Kersten=20
    To: spr...@li...=20
    Sent: Tuesday, February 22, 2005 12:46 PM
    Subject: Re: [Springframework-developer] Please check these two =
things


    Sorry, thought the agreement goes with the callee.=20
    Ok :-) sorry was a strange day for me, I guess.

    Thanks,

    Martin (Kersten)
    ----- Original Message -----=20
      From: Juergen Hoeller=20
      To: spr...@li...=20
      Sent: Tuesday, February 22, 2005 12:13 PM
      Subject: Re: [Springframework-developer] Please check these two =
things


      Actually, I have *not* replaced this with a =3D=3D comparison of =
the arrays: Instead, BatchSqlUpdate is storing clones of the passed-in =
arrays now, for execution on flush. This avoids any side effects in the =
first place (even if the passed-in arrays are changed afterwards or =
reused for multiple update inovcations), and the overhead of cloning an =
array should be acceptable (after all, we're talking about database =
update operations here).

      Juergen


        -----Original Message-----
        From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Martin Kersten
        Sent: Tuesday, February 22, 2005 12:04 PM
        To: spr...@li...
        Subject: Re: [Springframework-developer] Please check these two =
things


        But isn't this bogus thinking? I mean replacing .equals with =
=3D=3D makes=20
        the implementation more strickt and reduces semantical =
informations.
        We are thinking about objects and there is no performance gap
        to justify this modification.

        I wouldn't do it. I just would ensure that equals =
implementations=20
        start with if(this=3D=3Dobject) return true;. How huge is the =
estimated
        performance gain?


        Cheers,

        Martin (Kersten)
          ----- Original Message -----=20
          From: Juergen Hoeller=20
          To: spr...@li...=20
          Sent: Tuesday, February 22, 2005 10:06 AM
          Subject: Re: [Springframework-developer] Please check these =
two things


          Well-spotted!

          ConcurrencyThrottleInterceptor should indeed use an internal =
monitor to avoid any potential for side effects. I doubt that this has =
caused any issue in practice, but it's nevertheless cleaner.

          That check in BatchSqlUpdate is not supposed to compare the =
elements but just the array reference: Repeated update invocations =
should not pass-in the same array instance repeatedly, with modified =
elements. Of course, a =3D=3D check would be sufficient for this. I've =
reworked that part a bit differently, though: BatchSqlUpdate stores a =
clone of the passed-in array now, so there shouldn't be a need for such =
a check anymore.

          Juergen


            -----Original Message-----
            From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Dave Brosius
            Sent: Tuesday, February 22, 2005 8:08 AM
            To: spr...@li...
            Subject: [Springframework-developer] Please check these two =
things


            These may be problems, and then again maybe not. But they =
seem odd/wrong to me


            1) In =
org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

            in method invoke

            uses wait on 'this'

            In my mind you are exposing your synchronization strategies =
as a public artifact, which leaves this class open to failure due to =
client code.=20
            The client code may unwittingly us an instance of this class =
to do it's own synchronization, and totally screw up this class.
            I would recommend doing synchronizations (especially the use =
of wait/notify) on a private member so client code can not effect it.



            2) In org.springframework.jdbc.object.BatchSqlUpdate

            in method update, you do

              if (!this.parameterQueue.isEmpty() && =
args.equals(this.parameterQueue.getLast())) {

            this is the same as using     args =3D=3D =
this.parameterQueue.getLast()

            or in other words, are these objects the same object. I =
assume you want to compare the elements of the array?

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Steven D. <ste...@gm...>]

I don't think we have heard from Martin why he wants to extend
DefaultXmlBeanDefinitionParser. We don't know if it's in the intrest
of Spring to change something or not.


On Tue, 22 Feb 2005 13:48:46 +0100, Erwin Vervaet
<erw...@er...> wrote:
>  
> I think the main reason to use the W3C DOM API directly is to avoid the need
> for an extra dependency (e.g. JDOM) just to parse the XML bean definitions.
> You end up with an "less than elegant" implementation in
> DefaultXmlBeanDefinitionParser, but in this case the benifits outweigh the
> costs. 
>   
> Erwin Vervaet
> erw...@er... 
>  
> ----- Original Message ----- 
> From: Martin Kersten 
> To: spr...@li... 
>  
> Sent: Tuesday, February 22, 2005 1:21 PM 
> Subject: [Springframework-developer] I don't like the
> DefaultXmlBeanDefinitionParser 
> 
>  
> Hi folks, 
>   
>    I am currently trying to extend the framework by supporting
> contributions. 
> Just to see how it feels. 
>   
> So I made some investigations in the sourcecode. I don't want to start a war
> about proper design rules, since I am a believer in 'Interface belongs to
> the 
> client' stuff and you are appearently not, but this isn't the issue I want
> to 
> talk about. 
>   
> Th implementation I hate most on first sight is the 
> XMLBeanDefinitionParser. I know it does what it should but you can read
> this: 
>   
>  /**
>   * Make the horrible DOM API slightly more bearable:
>   * get the text value we know this element contains.
>   */ 
>   
> Well I would agree but it's a bit wired also. You think the DOM API is
> horrible 
> and you are still using it? You know what it means to use a 
> horrible API? You write a horrible implementation! And thats how it looks. 
> It took me more then a gaze to catch the meaning of the parser and I also 
> got blown by the code duplication. Since I am in need to extend this class, 
>   
> So I would like to ask if I may refactor it and commit you a patch (or maybe
> a complete reimplementation)? 
>   
>   
> Cheers, 
>   
> Martin (Kersten) 
>   
> PS: By the way, how about 'Hidding 3rd party library behind single
> interface?' 
>  
> ----- Original Message ----- 
> From: Martin Kersten 
> To: spr...@li... 
> Sent: Tuesday, February 22, 2005 12:46 PM 
> Subject: Re: [Springframework-developer] Please check these two things 
> 
>  
> Sorry, thought the agreement goes with the callee.  
> Ok :-) sorry was a strange day for me, I guess. 
>   
> Thanks, 
>   
> Martin (Kersten) 
> ----- Original Message ----- 
>  
> From: Juergen Hoeller 
> To: spr...@li... 
> Sent: Tuesday, February 22, 2005 12:13 PM 
> Subject: Re: [Springframework-developer] Please check these two things 
> 
>  
> Actually, I have *not* replaced this with a == comparison of the arrays:
> Instead, BatchSqlUpdate is storing clones of the passed-in arrays now, for
> execution on flush. This avoids any side effects in the first place (even if
> the passed-in arrays are changed afterwards or reused for multiple update
> inovcations), and the overhead of cloning an array should be acceptable
> (after all, we're talking about database update operations here). 
>   
> Juergen 
>   
>   
>  
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Martin Kersten
> Sent: Tuesday, February 22, 2005 12:04 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Please check these two things
> 
>  
> But isn't this bogus thinking? I mean replacing .equals with == makes 
> the implementation more strickt and reduces semantical informations. 
> We are thinking about objects and there is no performance gap 
> to justify this modification. 
>   
> I wouldn't do it. I just would ensure that equals implementations 
> start with if(this==object) return true;. How huge is the estimated 
> performance gain? 
>   
> 
> Cheers, 
>   
> Martin (Kersten) 
>  
> ----- Original Message ----- 
> From: Juergen Hoeller 
> To: spr...@li... 
> Sent: Tuesday, February 22, 2005 10:06 AM 
> Subject: Re: [Springframework-developer] Please check these two things 
> 
>  
> Well-spotted! 
>   
> ConcurrencyThrottleInterceptor should indeed use an internal monitor to
> avoid any potential for side effects. I doubt that this has caused any issue
> in practice, but it's nevertheless cleaner. 
>   
> That check in BatchSqlUpdate is not supposed to compare the elements but
> just the array reference: Repeated update invocations should not pass-in the
> same array instance repeatedly, with modified elements. Of course, a ==
> check would be sufficient for this. I've reworked that part a bit
> differently, though: BatchSqlUpdate stores a clone of the passed-in array
> now, so there shouldn't be a need for such a check anymore. 
>   
> Juergen 
>   
>   
>  
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Dave Brosius
> Sent: Tuesday, February 22, 2005 8:08 AM
> To: spr...@li...
> Subject: [Springframework-developer] Please check these two things
> 
>  
> These may be problems, and then again maybe not. But they seem odd/wrong to
> me 
>   
>   
> 1) In org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor 
>   
> in method invoke 
>   
> uses wait on 'this' 
>   
> In my mind you are exposing your synchronization strategies as a public
> artifact, which leaves this class open to failure due to client code. 
> The client code may unwittingly us an instance of this class to do it's own
> synchronization, and totally screw up this class. 
> I would recommend doing synchronizations (especially the use of wait/notify)
> on a private member so client code can not effect it. 
>   
>   
>   
> 2) In org.springframework.jdbc.object.BatchSqlUpdate 
>   
> in method update, you do 
>   
>   if (!this.parameterQueue.isEmpty() &&
> args.equals(this.parameterQueue.getLast())) { 
>   
> this is the same as using     args == this.parameterQueue.getLast() 
>   
> or in other words, are these objects the same object. I assume you want to
> compare the elements of the array? 
>   
>   
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

>I don't think we have heard from Martin why he wants to extend
> DefaultXmlBeanDefinitionParser. We don't know if it's in the intrest
> of Spring to change something or not.

I stated that I was reviewing to understand what's going on.
Also I said that I want to add support for contributions to string
(at least to see how it goes and if it would be suitable at least
for the RPC subproject).

>> I think the main reason to use the W3C DOM API directly is to avoid the 
>> need
>> for an extra dependency (e.g. JDOM) just to parse the XML bean 
>> definitions.
>> You end up with an "less than elegant" implementation in
>> DefaultXmlBeanDefinitionParser, but in this case the benifits outweigh 
>> the
>> costs.
>>
>> Erwin Vervaet
>> erw...@er...
>>
>> ----- Original Message ----- 
>> From: Martin Kersten
>> To: spr...@li...
>>
>> Sent: Tuesday, February 22, 2005 1:21 PM
>> Subject: [Springframework-developer] I don't like the
>> DefaultXmlBeanDefinitionParser
>>
>>
>> Hi folks,
>>
>>    I am currently trying to extend the framework by supporting
>> contributions.
>> Just to see how it feels.
>>
>> So I made some investigations in the sourcecode. I don't want to start a 
>> war
>> about proper design rules, since I am a believer in 'Interface belongs to
>> the
>> client' stuff and you are appearently not, but this isn't the issue I 
>> want
>> to
>> talk about.
>>
>> Th implementation I hate most on first sight is the
>> XMLBeanDefinitionParser. I know it does what it should but you can read
>> this:
>>
>>  /**
>>   * Make the horrible DOM API slightly more bearable:
>>   * get the text value we know this element contains.
>>   */
>>
>> Well I would agree but it's a bit wired also. You think the DOM API is
>> horrible
>> and you are still using it? You know what it means to use a
>> horrible API? You write a horrible implementation! And thats how it 
>> looks.
>> It took me more then a gaze to catch the meaning of the parser and I also
>> got blown by the code duplication. Since I am in need to extend this 
>> class,
>>
>> So I would like to ask if I may refactor it and commit you a patch (or 
>> maybe
>> a complete reimplementation)?
>>
>>
>> Cheers,
>>
>> Martin (Kersten)
>>
>> PS: By the way, how about 'Hidding 3rd party library behind single
>> interface?' 

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

> I think the main reason to use the W3C DOM API directly is to 
> avoid the need for an extra dependency (e.g. JDOM) just to 
> parse the XML bean definitions. You end up with an 
> "less than elegant" implementation in DefaultXmlBeanDefinitionParser, 
> but in this case the benifits outweigh the costs.

I don't talk about using JDOM. There is no need to change to another
library. I just talking about plain and simply refactoring.

The cost would be about two or three man hours. 
I document this refactoring for later review for my own, so I would take
as double that long. The good news is that I have a set of test cases to
test against. So it will be real fast. So hopefully in a couple of hours
I can show you the result and you can compare.


Cheers,

Martin (Kersten)

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Juergen H. <ju...@in...>]

OK, that's perfectly reasonable. It sounded like you wanted to get away from
DOM completely; if all you want to do is a refactoring, then you're welcome
to do so :-) I'll consider including this in Spring 1.2 RC1, provided that
we agree on the design.

So do I understand correctly that you intend to introduce some DOM
abstraction to make the actual XML bean definition parsing code nicer? I
guess a full abstraction would be overkill; some DOM helper stuff should be
sufficient, IMO.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Martin Kersten
Sent: Tuesday, February 22, 2005 2:28 PM
To: spr...@li...
Subject: Re: [Springframework-developer] I don't like the
DefaultXmlBeanDefinitionParser


> I think the main reason to use the W3C DOM API directly is to
> avoid the need for an extra dependency (e.g. JDOM) just to
> parse the XML bean definitions. You end up with an
> "less than elegant" implementation in DefaultXmlBeanDefinitionParser,
> but in this case the benifits outweigh the costs.

I don't talk about using JDOM. There is no need to change to another
library. I just talking about plain and simply refactoring.

The cost would be about two or three man hours.
I document this refactoring for later review for my own, so I would take
as double that long. The good news is that I have a set of test cases to
test against. So it will be real fast. So hopefully in a couple of hours
I can show you the result and you can compare.


Cheers,

Martin (Kersten)


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

> So do I understand correctly that you intend to introduce some DOM
> abstraction to make the actual XML bean definition parsing code nicer? I
> guess a full abstraction would be overkill; some DOM helper stuff should 
> be
> sufficient, IMO.

Nope, wrong. I am not abstracting the DOM API, I am about to hide it from
the parser thats all. Also I am trying to get away from the string constants
and string attributes.

Also I noticed you folks stored parameters as attributes to save
parameters... .:-(


Cheers,

Martin (Kersten)

>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On Behalf
> Of Martin Kersten
> Sent: Tuesday, February 22, 2005 2:28 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] I don't like the
> DefaultXmlBeanDefinitionParser
>
>
>> I think the main reason to use the W3C DOM API directly is to
>> avoid the need for an extra dependency (e.g. JDOM) just to
>> parse the XML bean definitions. You end up with an
>> "less than elegant" implementation in DefaultXmlBeanDefinitionParser,
>> but in this case the benifits outweigh the costs.
>
> I don't talk about using JDOM. There is no need to change to another
> library. I just talking about plain and simply refactoring.
>
> The cost would be about two or three man hours.
> I document this refactoring for later review for my own, so I would take
> as double that long. The good news is that I have a set of test cases to
> test against. So it will be real fast. So hopefully in a couple of hours
> I can show you the result and you can compare.
>
>
> Cheers,
>
> Martin (Kersten)
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Rob H. <ro...@ca...>]

My thoughts exactly :). We have enough dependencies already.

Erwin Vervaet wrote:

> I think the main reason to use the W3C DOM API directly is to avoid 
> the need for an extra dependency (e.g. JDOM) just to parse the XML 
> bean definitions. You end up with an "less than elegant" 
> implementation in DefaultXmlBeanDefinitionParser, but in this case the 
> benifits outweigh the costs.
>  
> Erwin Vervaet
> erw...@er... <mailto:erw...@er...>
>
>     ----- Original Message -----
>     *From:* Martin Kersten
>     <mailto:Mar...@St...>
>     *To:* spr...@li...
>     <mailto:spr...@li...>
>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>     *Subject:* [Springframework-developer] I don't like the
>     DefaultXmlBeanDefinitionParser
>
>     Hi folks,
>      
>        I am currently trying to extend the framework by supporting
>     contributions.
>     Just to see how it feels.
>      
>     So I made some investigations in the sourcecode. I don't want to
>     start a war
>     about proper design rules, since I am a believer in 'Interface
>     belongs to the
>     client' stuff and you are appearently not, but this isn't the
>     issue I want to
>     talk about.
>      
>     Th implementation I hate most on first sight is the
>     XMLBeanDefinitionParser. I know it does what it should but you can
>     read this:
>      
>      /**
>       * Make the horrible DOM API slightly more bearable:
>       * get the text value we know this element contains.
>       */
>      
>     Well I would agree but it's a bit wired also. You think the DOM
>     API is horrible
>     and you are still using it? You know what it means to use a
>     horrible API? You write a horrible implementation! And thats how
>     it looks.
>     It took me more then a gaze to catch the meaning of the parser and
>     I also
>     got blown by the code duplication. Since I am in need to extend
>     this class,
>      
>     So I would like to ask if I may refactor it and commit you a patch
>     (or maybe
>     a complete reimplementation)?
>      
>      
>     Cheers,
>      
>     Martin (Kersten)
>      
>     PS: By the way, how about 'Hidding 3rd party library behind single
>     interface?'
>
>         ----- Original Message -----
>         *From:* Martin Kersten
>         <mailto:Mar...@St...>
>         *To:* spr...@li...
>         <mailto:spr...@li...>
>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>         *Subject:* Re: [Springframework-developer] Please check these
>         two things
>
>         Sorry, thought the agreement goes with the callee. 
>         Ok :-) sorry was a strange day for me, I guess.
>          
>         Thanks,
>          
>         Martin (Kersten)
>         ----- Original Message -----
>
>             *From:* Juergen Hoeller <mailto:ju...@in...>
>             *To:* spr...@li...
>             <mailto:spr...@li...>
>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>             *Subject:* Re: [Springframework-developer] Please check
>             these two things
>
>             Actually, I have *not* replaced this with a == comparison
>             of the arrays: Instead, BatchSqlUpdate is storing clones
>             of the passed-in arrays now, for execution on flush. This
>             avoids any side effects in the first place (even if the
>             passed-in arrays are changed afterwards or reused for
>             multiple update inovcations), and the overhead of cloning
>             an array should be acceptable (after all, we're talking
>             about database update operations here).
>              
>             Juergen
>              
>              
>
>                 -----Original Message-----
>                 *From:*
>                 spr...@li...
>                 [mailto:spr...@li...]*On
>                 Behalf Of *Martin Kersten
>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>                 *To:* spr...@li...
>                 *Subject:* Re: [Springframework-developer] Please
>                 check these two things
>
>                 But isn't this bogus thinking? I mean replacing
>                 .equals with == makes
>                 the implementation more strickt and reduces semantical
>                 informations.
>                 We are thinking about objects and there is no
>                 performance gap
>                 to justify this modification.
>                  
>                 I wouldn't do it. I just would ensure that equals
>                 implementations
>                 start with if(this==object) return true;. How huge is
>                 the estimated
>                 performance gain?
>                  
>
>                 Cheers,
>                  
>                 Martin (Kersten)
>
>                     ----- Original Message -----
>                     *From:* Juergen Hoeller
>                     <mailto:ju...@in...>
>                     *To:*
>                     spr...@li...
>                     <mailto:spr...@li...>
>
>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>                     *Subject:* Re: [Springframework-developer] Please
>                     check these two things
>
>                     Well-spotted!
>                      
>                     ConcurrencyThrottleInterceptor should indeed use
>                     an internal monitor to avoid any potential for
>                     side effects. I doubt that this has caused any
>                     issue in practice, but it's nevertheless cleaner.
>                      
>                     That check in BatchSqlUpdate is not supposed to
>                     compare the elements but just the array reference:
>                     Repeated update invocations should not pass-in the
>                     same array instance repeatedly, with modified
>                     elements. Of course, a == check would be
>                     sufficient for this. I've reworked that part a bit
>                     differently, though: BatchSqlUpdate stores a clone
>                     of the passed-in array now, so there shouldn't be
>                     a need for such a check anymore.
>                      
>                     Juergen
>                      
>                      
>
>                         -----Original Message-----
>                         *From:*
>                         spr...@li...
>                         [mailto:spr...@li...]*On
>                         Behalf Of *Dave Brosius
>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>                         *To:*
>                         spr...@li...
>                         *Subject:* [Springframework-developer] Please
>                         check these two things
>
>                         These may be problems, and then again maybe
>                         not. But they seem odd/wrong to me
>                          
>                          
>                         1) In
>                         org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>                          
>                         in method invoke
>                          
>                         uses wait on 'this'
>                          
>                         In my mind you are exposing your
>                         synchronization strategies as a public
>                         artifact, which leaves this class open to
>                         failure due to client code.
>                         The client code may unwittingly us an instance
>                         of this class to do it's own synchronization,
>                         and totally screw up this class.
>                         I would recommend doing synchronizations
>                         (especially the use of wait/notify) on a
>                         private member so client code can not effect it.
>                          
>                          
>                          
>                         2) In
>                         org.springframework.jdbc.object.BatchSqlUpdate
>                          
>                         in method update, you do
>                          
>                           if (!this.parameterQueue.isEmpty() &&
>                         args.equals(this.parameterQueue.getLast())) {
>                          
>                         this is the same as using     args ==
>                         this.parameterQueue.getLast()
>                          
>                         or in other words, are these objects the same
>                         object. I assume you want to compare the
>                         elements of the array?
>                          
>                          
>                          
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

> My thoughts exactly :). We have enough dependencies already.

You should break up your framework anyways.

You are currently providing a 'Jack of all trades' API. A solution
for everything but nothing in particular.

Don't get mad :-) Here is what I mean:

Spring adapts services for many diffrent situations:
  You having a web application, fine download the
      default spring framework,
  You have a command line application, fine download
       the default spring framework

  If it's not in the framework, we dont support it.

Thats what I mean. Download the framework and be happy.

It's like java, download the SE and you have all the stuff those
folks think some (!) people might(!) wanna have.

How about making a core framework and having extensions.

So you go for a normal application, just download the core
framework. You want to go for a web application, download
the core framework and download the web extension.

You know I am currently trying to get my visions into the RPC
sub project. And when you start to develop your own
rich client(!) guess what, you have code for setting up a web
application right out of the box!

Imagen what a relieve it would be for all of you folks to speak
about extensions and the core project, manage the dependencies
for those individually. Imagen having more then one swing reference
documentation. One for the core, one for the web, one for RPC and
so on. Boy I would be lucky if I were you :-).


Martin (Kersten)

PS: Just a hint! ;-)

> Erwin Vervaet wrote:
>
>> I think the main reason to use the W3C DOM API directly is to avoid the 
>> need for an extra dependency (e.g. JDOM) just to parse the XML bean 
>> definitions. You end up with an "less than elegant" implementation in 
>> DefaultXmlBeanDefinitionParser, but in this case the benifits outweigh 
>> the costs.
>>  Erwin Vervaet
>> erw...@er... <mailto:erw...@er...>
>>
>>     ----- Original Message -----
>>     *From:* Martin Kersten
>>     <mailto:Mar...@St...>
>>     *To:* spr...@li...
>>     <mailto:spr...@li...>
>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>>     *Subject:* [Springframework-developer] I don't like the
>>     DefaultXmlBeanDefinitionParser
>>
>>     Hi folks,
>>      I am currently trying to extend the framework by supporting
>>     contributions.
>>     Just to see how it feels.
>>      So I made some investigations in the sourcecode. I don't want to
>>     start a war
>>     about proper design rules, since I am a believer in 'Interface
>>     belongs to the
>>     client' stuff and you are appearently not, but this isn't the
>>     issue I want to
>>     talk about.
>>      Th implementation I hate most on first sight is the
>>     XMLBeanDefinitionParser. I know it does what it should but you can
>>     read this:
>>      /**
>>       * Make the horrible DOM API slightly more bearable:
>>       * get the text value we know this element contains.
>>       */
>>      Well I would agree but it's a bit wired also. You think the DOM
>>     API is horrible
>>     and you are still using it? You know what it means to use a
>>     horrible API? You write a horrible implementation! And thats how
>>     it looks.
>>     It took me more then a gaze to catch the meaning of the parser and
>>     I also
>>     got blown by the code duplication. Since I am in need to extend
>>     this class,
>>      So I would like to ask if I may refactor it and commit you a patch
>>     (or maybe
>>     a complete reimplementation)?
>>      Cheers,
>>      Martin (Kersten)
>>      PS: By the way, how about 'Hidding 3rd party library behind single
>>     interface?'
>>
>>         ----- Original Message -----
>>         *From:* Martin Kersten
>>         <mailto:Mar...@St...>
>>         *To:* spr...@li...
>>         <mailto:spr...@li...>
>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>>         *Subject:* Re: [Springframework-developer] Please check these
>>         two things
>>
>>         Sorry, thought the agreement goes with the callee. Ok :-) sorry 
>> was a strange day for me, I guess.
>>          Thanks,
>>          Martin (Kersten)
>>         ----- Original Message -----
>>
>>             *From:* Juergen Hoeller <mailto:ju...@in...>
>>             *To:* spr...@li...
>>             <mailto:spr...@li...>
>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>>             *Subject:* Re: [Springframework-developer] Please check
>>             these two things
>>
>>             Actually, I have *not* replaced this with a == comparison
>>             of the arrays: Instead, BatchSqlUpdate is storing clones
>>             of the passed-in arrays now, for execution on flush. This
>>             avoids any side effects in the first place (even if the
>>             passed-in arrays are changed afterwards or reused for
>>             multiple update inovcations), and the overhead of cloning
>>             an array should be acceptable (after all, we're talking
>>             about database update operations here).
>>              Juergen
>>
>>                 -----Original Message-----
>>                 *From:*
>>                 spr...@li...
>> 
>> [mailto:spr...@li...]*On
>>                 Behalf Of *Martin Kersten
>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>>                 *To:* spr...@li...
>>                 *Subject:* Re: [Springframework-developer] Please
>>                 check these two things
>>
>>                 But isn't this bogus thinking? I mean replacing
>>                 .equals with == makes
>>                 the implementation more strickt and reduces semantical
>>                 informations.
>>                 We are thinking about objects and there is no
>>                 performance gap
>>                 to justify this modification.
>>                  I wouldn't do it. I just would ensure that equals
>>                 implementations
>>                 start with if(this==object) return true;. How huge is
>>                 the estimated
>>                 performance gain?
>>
>>                 Cheers,
>>                  Martin (Kersten)
>>
>>                     ----- Original Message -----
>>                     *From:* Juergen Hoeller
>>                     <mailto:ju...@in...>
>>                     *To:*
>>                     spr...@li...
>> 
>> <mailto:spr...@li...>
>>
>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>>                     *Subject:* Re: [Springframework-developer] Please
>>                     check these two things
>>
>>                     Well-spotted!
>>                      ConcurrencyThrottleInterceptor should indeed use
>>                     an internal monitor to avoid any potential for
>>                     side effects. I doubt that this has caused any
>>                     issue in practice, but it's nevertheless cleaner.
>>                      That check in BatchSqlUpdate is not supposed to
>>                     compare the elements but just the array reference:
>>                     Repeated update invocations should not pass-in the
>>                     same array instance repeatedly, with modified
>>                     elements. Of course, a == check would be
>>                     sufficient for this. I've reworked that part a bit
>>                     differently, though: BatchSqlUpdate stores a clone
>>                     of the passed-in array now, so there shouldn't be
>>                     a need for such a check anymore.
>>                      Juergen
>>
>>                         -----Original Message-----
>>                         *From:*
>> 
>> spr...@li...
>> 
>> [mailto:spr...@li...]*On
>>                         Behalf Of *Dave Brosius
>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>>                         *To:*
>>                         spr...@li...
>>                         *Subject:* [Springframework-developer] Please
>>                         check these two things
>>
>>                         These may be problems, and then again maybe
>>                         not. But they seem odd/wrong to me
>>                          1) In
>> 
>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>                          in method invoke
>>                          uses wait on 'this'
>>                          In my mind you are exposing your
>>                         synchronization strategies as a public
>>                         artifact, which leaves this class open to
>>                         failure due to client code.
>>                         The client code may unwittingly us an instance
>>                         of this class to do it's own synchronization,
>>                         and totally screw up this class.
>>                         I would recommend doing synchronizations
>>                         (especially the use of wait/notify) on a
>>                         private member so client code can not effect it.
>>                          2) In
>>                         org.springframework.jdbc.object.BatchSqlUpdate
>>                          in method update, you do
>>                          if (!this.parameterQueue.isEmpty() &&
>>                         args.equals(this.parameterQueue.getLast())) {
>>                          this is the same as using     args ==
>>                         this.parameterQueue.getLast()
>>                          or in other words, are these objects the same
>>                         object. I assume you want to compare the
>>                         elements of the array?
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Rob H. <ro...@ca...>]

The distribution comes with different JARs for different circumstances, 
but it might be nice to be able to download them separately as well.

Rob

Martin Kersten wrote:

>> My thoughts exactly :). We have enough dependencies already.
>
>
> You should break up your framework anyways.
>
> You are currently providing a 'Jack of all trades' API. A solution
> for everything but nothing in particular.
>
> Don't get mad :-) Here is what I mean:
>
> Spring adapts services for many diffrent situations:
>  You having a web application, fine download the
>      default spring framework,
>  You have a command line application, fine download
>       the default spring framework
>
>  If it's not in the framework, we dont support it.
>
> Thats what I mean. Download the framework and be happy.
>
> It's like java, download the SE and you have all the stuff those
> folks think some (!) people might(!) wanna have.
>
> How about making a core framework and having extensions.
>
> So you go for a normal application, just download the core
> framework. You want to go for a web application, download
> the core framework and download the web extension.
>
> You know I am currently trying to get my visions into the RPC
> sub project. And when you start to develop your own
> rich client(!) guess what, you have code for setting up a web
> application right out of the box!
>
> Imagen what a relieve it would be for all of you folks to speak
> about extensions and the core project, manage the dependencies
> for those individually. Imagen having more then one swing reference
> documentation. One for the core, one for the web, one for RPC and
> so on. Boy I would be lucky if I were you :-).
>
>
> Martin (Kersten)
>
> PS: Just a hint! ;-)
>
>> Erwin Vervaet wrote:
>>
>>> I think the main reason to use the W3C DOM API directly is to avoid 
>>> the need for an extra dependency (e.g. JDOM) just to parse the XML 
>>> bean definitions. You end up with an "less than elegant" 
>>> implementation in DefaultXmlBeanDefinitionParser, but in this case 
>>> the benifits outweigh the costs.
>>>  Erwin Vervaet
>>> erw...@er... <mailto:erw...@er...>
>>>
>>>     ----- Original Message -----
>>>     *From:* Martin Kersten
>>>     <mailto:Mar...@St...>
>>>     *To:* spr...@li...
>>>     <mailto:spr...@li...>
>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>     *Subject:* [Springframework-developer] I don't like the
>>>     DefaultXmlBeanDefinitionParser
>>>
>>>     Hi folks,
>>>      I am currently trying to extend the framework by supporting
>>>     contributions.
>>>     Just to see how it feels.
>>>      So I made some investigations in the sourcecode. I don't want to
>>>     start a war
>>>     about proper design rules, since I am a believer in 'Interface
>>>     belongs to the
>>>     client' stuff and you are appearently not, but this isn't the
>>>     issue I want to
>>>     talk about.
>>>      Th implementation I hate most on first sight is the
>>>     XMLBeanDefinitionParser. I know it does what it should but you can
>>>     read this:
>>>      /**
>>>       * Make the horrible DOM API slightly more bearable:
>>>       * get the text value we know this element contains.
>>>       */
>>>      Well I would agree but it's a bit wired also. You think the DOM
>>>     API is horrible
>>>     and you are still using it? You know what it means to use a
>>>     horrible API? You write a horrible implementation! And thats how
>>>     it looks.
>>>     It took me more then a gaze to catch the meaning of the parser and
>>>     I also
>>>     got blown by the code duplication. Since I am in need to extend
>>>     this class,
>>>      So I would like to ask if I may refactor it and commit you a patch
>>>     (or maybe
>>>     a complete reimplementation)?
>>>      Cheers,
>>>      Martin (Kersten)
>>>      PS: By the way, how about 'Hidding 3rd party library behind single
>>>     interface?'
>>>
>>>         ----- Original Message -----
>>>         *From:* Martin Kersten
>>>         <mailto:Mar...@St...>
>>>         *To:* spr...@li...
>>>         <mailto:spr...@li...>
>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>         *Subject:* Re: [Springframework-developer] Please check these
>>>         two things
>>>
>>>         Sorry, thought the agreement goes with the callee. Ok :-) 
>>> sorry was a strange day for me, I guess.
>>>          Thanks,
>>>          Martin (Kersten)
>>>         ----- Original Message -----
>>>
>>>             *From:* Juergen Hoeller <mailto:ju...@in...>
>>>             *To:* spr...@li...
>>>             <mailto:spr...@li...>
>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>             *Subject:* Re: [Springframework-developer] Please check
>>>             these two things
>>>
>>>             Actually, I have *not* replaced this with a == comparison
>>>             of the arrays: Instead, BatchSqlUpdate is storing clones
>>>             of the passed-in arrays now, for execution on flush. This
>>>             avoids any side effects in the first place (even if the
>>>             passed-in arrays are changed afterwards or reused for
>>>             multiple update inovcations), and the overhead of cloning
>>>             an array should be acceptable (after all, we're talking
>>>             about database update operations here).
>>>              Juergen
>>>
>>>                 -----Original Message-----
>>>                 *From:*
>>>                 spr...@li...
>>>
>>> [mailto:spr...@li...]*On
>>>                 Behalf Of *Martin Kersten
>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>                 *To:* spr...@li...
>>>                 *Subject:* Re: [Springframework-developer] Please
>>>                 check these two things
>>>
>>>                 But isn't this bogus thinking? I mean replacing
>>>                 .equals with == makes
>>>                 the implementation more strickt and reduces semantical
>>>                 informations.
>>>                 We are thinking about objects and there is no
>>>                 performance gap
>>>                 to justify this modification.
>>>                  I wouldn't do it. I just would ensure that equals
>>>                 implementations
>>>                 start with if(this==object) return true;. How huge is
>>>                 the estimated
>>>                 performance gain?
>>>
>>>                 Cheers,
>>>                  Martin (Kersten)
>>>
>>>                     ----- Original Message -----
>>>                     *From:* Juergen Hoeller
>>>                     <mailto:ju...@in...>
>>>                     *To:*
>>>                     spr...@li...
>>>
>>> <mailto:spr...@li...>
>>>
>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>                     *Subject:* Re: [Springframework-developer] Please
>>>                     check these two things
>>>
>>>                     Well-spotted!
>>>                      ConcurrencyThrottleInterceptor should indeed use
>>>                     an internal monitor to avoid any potential for
>>>                     side effects. I doubt that this has caused any
>>>                     issue in practice, but it's nevertheless cleaner.
>>>                      That check in BatchSqlUpdate is not supposed to
>>>                     compare the elements but just the array reference:
>>>                     Repeated update invocations should not pass-in the
>>>                     same array instance repeatedly, with modified
>>>                     elements. Of course, a == check would be
>>>                     sufficient for this. I've reworked that part a bit
>>>                     differently, though: BatchSqlUpdate stores a clone
>>>                     of the passed-in array now, so there shouldn't be
>>>                     a need for such a check anymore.
>>>                      Juergen
>>>
>>>                         -----Original Message-----
>>>                         *From:*
>>>
>>> spr...@li...
>>>
>>> [mailto:spr...@li...]*On
>>>                         Behalf Of *Dave Brosius
>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>                         *To:*
>>>                         spr...@li...
>>>                         *Subject:* [Springframework-developer] Please
>>>                         check these two things
>>>
>>>                         These may be problems, and then again maybe
>>>                         not. But they seem odd/wrong to me
>>>                          1) In
>>>
>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>                          in method invoke
>>>                          uses wait on 'this'
>>>                          In my mind you are exposing your
>>>                         synchronization strategies as a public
>>>                         artifact, which leaves this class open to
>>>                         failure due to client code.
>>>                         The client code may unwittingly us an instance
>>>                         of this class to do it's own synchronization,
>>>                         and totally screw up this class.
>>>                         I would recommend doing synchronizations
>>>                         (especially the use of wait/notify) on a
>>>                         private member so client code can not effect 
>>> it.
>>>                          2) In
>>>                         org.springframework.jdbc.object.BatchSqlUpdate
>>>                          in method update, you do
>>>                          if (!this.parameterQueue.isEmpty() &&
>>>                         args.equals(this.parameterQueue.getLast())) {
>>>                          this is the same as using     args ==
>>>                         this.parameterQueue.getLast()
>>>                          or in other words, are these objects the same
>>>                         object. I assume you want to compare the
>>>                         elements of the array?
>>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

> The distribution comes with different JARs for different circumstances, 
> but it might be nice to be able to download them separately as well.

How does web fits the vision of the core framework? It's really an
issue. Would you also like to deliver the rich client platform
and it's dependency also within the framework?

But downloading the required jars based on the case scenario
the user has would be a great improvement anyways. For my
current research I would like to had the option to get a
web free, jdbc free, jms free, mail free, orm free, remoting free,
transaction free Spring version.

If I would be in charge I would split it up the following way:

core, web, j2ee, persistence, later rpc.


Cheers,

Martin (Kersten)


>
> Rob
>
> Martin Kersten wrote:
>
>>> My thoughts exactly :). We have enough dependencies already.
>>
>>
>> You should break up your framework anyways.
>>
>> You are currently providing a 'Jack of all trades' API. A solution
>> for everything but nothing in particular.
>>
>> Don't get mad :-) Here is what I mean:
>>
>> Spring adapts services for many diffrent situations:
>>  You having a web application, fine download the
>>      default spring framework,
>>  You have a command line application, fine download
>>       the default spring framework
>>
>>  If it's not in the framework, we dont support it.
>>
>> Thats what I mean. Download the framework and be happy.
>>
>> It's like java, download the SE and you have all the stuff those
>> folks think some (!) people might(!) wanna have.
>>
>> How about making a core framework and having extensions.
>>
>> So you go for a normal application, just download the core
>> framework. You want to go for a web application, download
>> the core framework and download the web extension.
>>
>> You know I am currently trying to get my visions into the RPC
>> sub project. And when you start to develop your own
>> rich client(!) guess what, you have code for setting up a web
>> application right out of the box!
>>
>> Imagen what a relieve it would be for all of you folks to speak
>> about extensions and the core project, manage the dependencies
>> for those individually. Imagen having more then one swing reference
>> documentation. One for the core, one for the web, one for RPC and
>> so on. Boy I would be lucky if I were you :-).
>>
>>
>> Martin (Kersten)
>>
>> PS: Just a hint! ;-)
>>
>>> Erwin Vervaet wrote:
>>>
>>>> I think the main reason to use the W3C DOM API directly is to avoid the 
>>>> need for an extra dependency (e.g. JDOM) just to parse the XML bean 
>>>> definitions. You end up with an "less than elegant" implementation in 
>>>> DefaultXmlBeanDefinitionParser, but in this case the benifits outweigh 
>>>> the costs.
>>>>  Erwin Vervaet
>>>> erw...@er... <mailto:erw...@er...>
>>>>
>>>>     ----- Original Message -----
>>>>     *From:* Martin Kersten
>>>>     <mailto:Mar...@St...>
>>>>     *To:* spr...@li...
>>>>     <mailto:spr...@li...>
>>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>>     *Subject:* [Springframework-developer] I don't like the
>>>>     DefaultXmlBeanDefinitionParser
>>>>
>>>>     Hi folks,
>>>>      I am currently trying to extend the framework by supporting
>>>>     contributions.
>>>>     Just to see how it feels.
>>>>      So I made some investigations in the sourcecode. I don't want to
>>>>     start a war
>>>>     about proper design rules, since I am a believer in 'Interface
>>>>     belongs to the
>>>>     client' stuff and you are appearently not, but this isn't the
>>>>     issue I want to
>>>>     talk about.
>>>>      Th implementation I hate most on first sight is the
>>>>     XMLBeanDefinitionParser. I know it does what it should but you can
>>>>     read this:
>>>>      /**
>>>>       * Make the horrible DOM API slightly more bearable:
>>>>       * get the text value we know this element contains.
>>>>       */
>>>>      Well I would agree but it's a bit wired also. You think the DOM
>>>>     API is horrible
>>>>     and you are still using it? You know what it means to use a
>>>>     horrible API? You write a horrible implementation! And thats how
>>>>     it looks.
>>>>     It took me more then a gaze to catch the meaning of the parser and
>>>>     I also
>>>>     got blown by the code duplication. Since I am in need to extend
>>>>     this class,
>>>>      So I would like to ask if I may refactor it and commit you a patch
>>>>     (or maybe
>>>>     a complete reimplementation)?
>>>>      Cheers,
>>>>      Martin (Kersten)
>>>>      PS: By the way, how about 'Hidding 3rd party library behind single
>>>>     interface?'
>>>>
>>>>         ----- Original Message -----
>>>>         *From:* Martin Kersten
>>>>         <mailto:Mar...@St...>
>>>>         *To:* spr...@li...
>>>>         <mailto:spr...@li...>
>>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>>         *Subject:* Re: [Springframework-developer] Please check these
>>>>         two things
>>>>
>>>>         Sorry, thought the agreement goes with the callee. Ok :-) sorry 
>>>> was a strange day for me, I guess.
>>>>          Thanks,
>>>>          Martin (Kersten)
>>>>         ----- Original Message -----
>>>>
>>>>             *From:* Juergen Hoeller <mailto:ju...@in...>
>>>>             *To:* spr...@li...
>>>>             <mailto:spr...@li...>
>>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>>             *Subject:* Re: [Springframework-developer] Please check
>>>>             these two things
>>>>
>>>>             Actually, I have *not* replaced this with a == comparison
>>>>             of the arrays: Instead, BatchSqlUpdate is storing clones
>>>>             of the passed-in arrays now, for execution on flush. This
>>>>             avoids any side effects in the first place (even if the
>>>>             passed-in arrays are changed afterwards or reused for
>>>>             multiple update inovcations), and the overhead of cloning
>>>>             an array should be acceptable (after all, we're talking
>>>>             about database update operations here).
>>>>              Juergen
>>>>
>>>>                 -----Original Message-----
>>>>                 *From:*
>>>>                 spr...@li...
>>>>
>>>> [mailto:spr...@li...]*On
>>>>                 Behalf Of *Martin Kersten
>>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>>                 *To:* spr...@li...
>>>>                 *Subject:* Re: [Springframework-developer] Please
>>>>                 check these two things
>>>>
>>>>                 But isn't this bogus thinking? I mean replacing
>>>>                 .equals with == makes
>>>>                 the implementation more strickt and reduces semantical
>>>>                 informations.
>>>>                 We are thinking about objects and there is no
>>>>                 performance gap
>>>>                 to justify this modification.
>>>>                  I wouldn't do it. I just would ensure that equals
>>>>                 implementations
>>>>                 start with if(this==object) return true;. How huge is
>>>>                 the estimated
>>>>                 performance gain?
>>>>
>>>>                 Cheers,
>>>>                  Martin (Kersten)
>>>>
>>>>                     ----- Original Message -----
>>>>                     *From:* Juergen Hoeller
>>>>                     <mailto:ju...@in...>
>>>>                     *To:*
>>>>                     spr...@li...
>>>>
>>>> <mailto:spr...@li...>
>>>>
>>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>>                     *Subject:* Re: [Springframework-developer] Please
>>>>                     check these two things
>>>>
>>>>                     Well-spotted!
>>>>                      ConcurrencyThrottleInterceptor should indeed use
>>>>                     an internal monitor to avoid any potential for
>>>>                     side effects. I doubt that this has caused any
>>>>                     issue in practice, but it's nevertheless cleaner.
>>>>                      That check in BatchSqlUpdate is not supposed to
>>>>                     compare the elements but just the array reference:
>>>>                     Repeated update invocations should not pass-in the
>>>>                     same array instance repeatedly, with modified
>>>>                     elements. Of course, a == check would be
>>>>                     sufficient for this. I've reworked that part a bit
>>>>                     differently, though: BatchSqlUpdate stores a clone
>>>>                     of the passed-in array now, so there shouldn't be
>>>>                     a need for such a check anymore.
>>>>                      Juergen
>>>>
>>>>                         -----Original Message-----
>>>>                         *From:*
>>>>
>>>> spr...@li...
>>>>
>>>> [mailto:spr...@li...]*On
>>>>                         Behalf Of *Dave Brosius
>>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>>                         *To:*
>>>>                         spr...@li...
>>>>                         *Subject:* [Springframework-developer] Please
>>>>                         check these two things
>>>>
>>>>                         These may be problems, and then again maybe
>>>>                         not. But they seem odd/wrong to me
>>>>                          1) In
>>>>
>>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>                          in method invoke
>>>>                          uses wait on 'this'
>>>>                          In my mind you are exposing your
>>>>                         synchronization strategies as a public
>>>>                         artifact, which leaves this class open to
>>>>                         failure due to client code.
>>>>                         The client code may unwittingly us an instance
>>>>                         of this class to do it's own synchronization,
>>>>                         and totally screw up this class.
>>>>                         I would recommend doing synchronizations
>>>>                         (especially the use of wait/notify) on a
>>>>                         private member so client code can not effect 
>>>> it.
>>>>                          2) In
>>>>                         org.springframework.jdbc.object.BatchSqlUpdate
>>>>                          in method update, you do
>>>>                          if (!this.parameterQueue.isEmpty() &&
>>>>                         args.equals(this.parameterQueue.getLast())) {
>>>>                          this is the same as using     args ==
>>>>                         this.parameterQueue.getLast()
>>>>                          or in other words, are these objects the same
>>>>                         object. I assume you want to compare the
>>>>                         elements of the array?
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Rob H. <ro...@ca...>]

Its already split up as core, web, mvc, jdbc, orm and aop.

Rob

Martin Kersten wrote:

>> The distribution comes with different JARs for different 
>> circumstances, but it might be nice to be able to download them 
>> separately as well.
>
>
> How does web fits the vision of the core framework? It's really an
> issue. Would you also like to deliver the rich client platform
> and it's dependency also within the framework?
>
> But downloading the required jars based on the case scenario
> the user has would be a great improvement anyways. For my
> current research I would like to had the option to get a
> web free, jdbc free, jms free, mail free, orm free, remoting free,
> transaction free Spring version.
>
> If I would be in charge I would split it up the following way:
>
> core, web, j2ee, persistence, later rpc.
>
>
> Cheers,
>
> Martin (Kersten)
>
>
>>
>> Rob
>>
>> Martin Kersten wrote:
>>
>>>> My thoughts exactly :). We have enough dependencies already.
>>>
>>>
>>>
>>> You should break up your framework anyways.
>>>
>>> You are currently providing a 'Jack of all trades' API. A solution
>>> for everything but nothing in particular.
>>>
>>> Don't get mad :-) Here is what I mean:
>>>
>>> Spring adapts services for many diffrent situations:
>>>  You having a web application, fine download the
>>>      default spring framework,
>>>  You have a command line application, fine download
>>>       the default spring framework
>>>
>>>  If it's not in the framework, we dont support it.
>>>
>>> Thats what I mean. Download the framework and be happy.
>>>
>>> It's like java, download the SE and you have all the stuff those
>>> folks think some (!) people might(!) wanna have.
>>>
>>> How about making a core framework and having extensions.
>>>
>>> So you go for a normal application, just download the core
>>> framework. You want to go for a web application, download
>>> the core framework and download the web extension.
>>>
>>> You know I am currently trying to get my visions into the RPC
>>> sub project. And when you start to develop your own
>>> rich client(!) guess what, you have code for setting up a web
>>> application right out of the box!
>>>
>>> Imagen what a relieve it would be for all of you folks to speak
>>> about extensions and the core project, manage the dependencies
>>> for those individually. Imagen having more then one swing reference
>>> documentation. One for the core, one for the web, one for RPC and
>>> so on. Boy I would be lucky if I were you :-).
>>>
>>>
>>> Martin (Kersten)
>>>
>>> PS: Just a hint! ;-)
>>>
>>>> Erwin Vervaet wrote:
>>>>
>>>>> I think the main reason to use the W3C DOM API directly is to 
>>>>> avoid the need for an extra dependency (e.g. JDOM) just to parse 
>>>>> the XML bean definitions. You end up with an "less than elegant" 
>>>>> implementation in DefaultXmlBeanDefinitionParser, but in this case 
>>>>> the benifits outweigh the costs.
>>>>>  Erwin Vervaet
>>>>> erw...@er... <mailto:erw...@er...>
>>>>>
>>>>>     ----- Original Message -----
>>>>>     *From:* Martin Kersten
>>>>>     <mailto:Mar...@St...>
>>>>>     *To:* spr...@li...
>>>>>     <mailto:spr...@li...>
>>>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>>>     *Subject:* [Springframework-developer] I don't like the
>>>>>     DefaultXmlBeanDefinitionParser
>>>>>
>>>>>     Hi folks,
>>>>>      I am currently trying to extend the framework by supporting
>>>>>     contributions.
>>>>>     Just to see how it feels.
>>>>>      So I made some investigations in the sourcecode. I don't want to
>>>>>     start a war
>>>>>     about proper design rules, since I am a believer in 'Interface
>>>>>     belongs to the
>>>>>     client' stuff and you are appearently not, but this isn't the
>>>>>     issue I want to
>>>>>     talk about.
>>>>>      Th implementation I hate most on first sight is the
>>>>>     XMLBeanDefinitionParser. I know it does what it should but you 
>>>>> can
>>>>>     read this:
>>>>>      /**
>>>>>       * Make the horrible DOM API slightly more bearable:
>>>>>       * get the text value we know this element contains.
>>>>>       */
>>>>>      Well I would agree but it's a bit wired also. You think the DOM
>>>>>     API is horrible
>>>>>     and you are still using it? You know what it means to use a
>>>>>     horrible API? You write a horrible implementation! And thats how
>>>>>     it looks.
>>>>>     It took me more then a gaze to catch the meaning of the parser 
>>>>> and
>>>>>     I also
>>>>>     got blown by the code duplication. Since I am in need to extend
>>>>>     this class,
>>>>>      So I would like to ask if I may refactor it and commit you a 
>>>>> patch
>>>>>     (or maybe
>>>>>     a complete reimplementation)?
>>>>>      Cheers,
>>>>>      Martin (Kersten)
>>>>>      PS: By the way, how about 'Hidding 3rd party library behind 
>>>>> single
>>>>>     interface?'
>>>>>
>>>>>         ----- Original Message -----
>>>>>         *From:* Martin Kersten
>>>>>         <mailto:Mar...@St...>
>>>>>         *To:* spr...@li...
>>>>>         <mailto:spr...@li...>
>>>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>>>         *Subject:* Re: [Springframework-developer] Please check these
>>>>>         two things
>>>>>
>>>>>         Sorry, thought the agreement goes with the callee. Ok :-) 
>>>>> sorry was a strange day for me, I guess.
>>>>>          Thanks,
>>>>>          Martin (Kersten)
>>>>>         ----- Original Message -----
>>>>>
>>>>>             *From:* Juergen Hoeller <mailto:ju...@in...>
>>>>>             *To:* spr...@li...
>>>>>             <mailto:spr...@li...>
>>>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>>>             *Subject:* Re: [Springframework-developer] Please check
>>>>>             these two things
>>>>>
>>>>>             Actually, I have *not* replaced this with a == comparison
>>>>>             of the arrays: Instead, BatchSqlUpdate is storing clones
>>>>>             of the passed-in arrays now, for execution on flush. This
>>>>>             avoids any side effects in the first place (even if the
>>>>>             passed-in arrays are changed afterwards or reused for
>>>>>             multiple update inovcations), and the overhead of cloning
>>>>>             an array should be acceptable (after all, we're talking
>>>>>             about database update operations here).
>>>>>              Juergen
>>>>>
>>>>>                 -----Original Message-----
>>>>>                 *From:*
>>>>>                 spr...@li...
>>>>>
>>>>> [mailto:spr...@li...]*On
>>>>>                 Behalf Of *Martin Kersten
>>>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>>>                 *To:* spr...@li...
>>>>>                 *Subject:* Re: [Springframework-developer] Please
>>>>>                 check these two things
>>>>>
>>>>>                 But isn't this bogus thinking? I mean replacing
>>>>>                 .equals with == makes
>>>>>                 the implementation more strickt and reduces 
>>>>> semantical
>>>>>                 informations.
>>>>>                 We are thinking about objects and there is no
>>>>>                 performance gap
>>>>>                 to justify this modification.
>>>>>                  I wouldn't do it. I just would ensure that equals
>>>>>                 implementations
>>>>>                 start with if(this==object) return true;. How huge is
>>>>>                 the estimated
>>>>>                 performance gain?
>>>>>
>>>>>                 Cheers,
>>>>>                  Martin (Kersten)
>>>>>
>>>>>                     ----- Original Message -----
>>>>>                     *From:* Juergen Hoeller
>>>>>                     <mailto:ju...@in...>
>>>>>                     *To:*
>>>>>                     spr...@li...
>>>>>
>>>>> <mailto:spr...@li...>
>>>>>
>>>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>>>                     *Subject:* Re: [Springframework-developer] Please
>>>>>                     check these two things
>>>>>
>>>>>                     Well-spotted!
>>>>>                      ConcurrencyThrottleInterceptor should indeed use
>>>>>                     an internal monitor to avoid any potential for
>>>>>                     side effects. I doubt that this has caused any
>>>>>                     issue in practice, but it's nevertheless cleaner.
>>>>>                      That check in BatchSqlUpdate is not supposed to
>>>>>                     compare the elements but just the array 
>>>>> reference:
>>>>>                     Repeated update invocations should not pass-in 
>>>>> the
>>>>>                     same array instance repeatedly, with modified
>>>>>                     elements. Of course, a == check would be
>>>>>                     sufficient for this. I've reworked that part a 
>>>>> bit
>>>>>                     differently, though: BatchSqlUpdate stores a 
>>>>> clone
>>>>>                     of the passed-in array now, so there shouldn't be
>>>>>                     a need for such a check anymore.
>>>>>                      Juergen
>>>>>
>>>>>                         -----Original Message-----
>>>>>                         *From:*
>>>>>
>>>>> spr...@li...
>>>>>
>>>>> [mailto:spr...@li...]*On
>>>>>                         Behalf Of *Dave Brosius
>>>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>>>                         *To:*
>>>>>                         
>>>>> spr...@li...
>>>>>                         *Subject:* [Springframework-developer] Please
>>>>>                         check these two things
>>>>>
>>>>>                         These may be problems, and then again maybe
>>>>>                         not. But they seem odd/wrong to me
>>>>>                          1) In
>>>>>
>>>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>>                          in method invoke
>>>>>                          uses wait on 'this'
>>>>>                          In my mind you are exposing your
>>>>>                         synchronization strategies as a public
>>>>>                         artifact, which leaves this class open to
>>>>>                         failure due to client code.
>>>>>                         The client code may unwittingly us an 
>>>>> instance
>>>>>                         of this class to do it's own synchronization,
>>>>>                         and totally screw up this class.
>>>>>                         I would recommend doing synchronizations
>>>>>                         (especially the use of wait/notify) on a
>>>>>                         private member so client code can not 
>>>>> effect it.
>>>>>                          2) In
>>>>>                         
>>>>> org.springframework.jdbc.object.BatchSqlUpdate
>>>>>                          in method update, you do
>>>>>                          if (!this.parameterQueue.isEmpty() &&
>>>>>                         args.equals(this.parameterQueue.getLast())) {
>>>>>                          this is the same as using     args ==
>>>>>                         this.parameterQueue.getLast()
>>>>>                          or in other words, are these objects the 
>>>>> same
>>>>>                         object. I assume you want to compare the
>>>>>                         elements of the array?
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real 
>>> users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer 
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Steven D. <ste...@gm...>]

And what jars do I require to use the aop part, for example?


On Tue, 22 Feb 2005 15:20:55 +0000, Rob Harrop <ro...@ca...> wrote:
> Its already split up as core, web, mvc, jdbc, orm and aop.
> 
> Rob
> 
> Martin Kersten wrote:
> 
> >> The distribution comes with different JARs for different
> >> circumstances, but it might be nice to be able to download them
> >> separately as well.
> >
> >
> > How does web fits the vision of the core framework? It's really an
> > issue. Would you also like to deliver the rich client platform
> > and it's dependency also within the framework?
> >
> > But downloading the required jars based on the case scenario
> > the user has would be a great improvement anyways. For my
> > current research I would like to had the option to get a
> > web free, jdbc free, jms free, mail free, orm free, remoting free,
> > transaction free Spring version.
> >
> > If I would be in charge I would split it up the following way:
> >
> > core, web, j2ee, persistence, later rpc.
> >
> >
> > Cheers,
> >
> > Martin (Kersten)
> >
> >
> >>
> >> Rob
> >>
> >> Martin Kersten wrote:
> >>
> >>>> My thoughts exactly :). We have enough dependencies already.
> >>>
> >>>
> >>>
> >>> You should break up your framework anyways.
> >>>
> >>> You are currently providing a 'Jack of all trades' API. A solution
> >>> for everything but nothing in particular.
> >>>
> >>> Don't get mad :-) Here is what I mean:
> >>>
> >>> Spring adapts services for many diffrent situations:
> >>>  You having a web application, fine download the
> >>>      default spring framework,
> >>>  You have a command line application, fine download
> >>>       the default spring framework
> >>>
> >>>  If it's not in the framework, we dont support it.
> >>>
> >>> Thats what I mean. Download the framework and be happy.
> >>>
> >>> It's like java, download the SE and you have all the stuff those
> >>> folks think some (!) people might(!) wanna have.
> >>>
> >>> How about making a core framework and having extensions.
> >>>
> >>> So you go for a normal application, just download the core
> >>> framework. You want to go for a web application, download
> >>> the core framework and download the web extension.
> >>>
> >>> You know I am currently trying to get my visions into the RPC
> >>> sub project. And when you start to develop your own
> >>> rich client(!) guess what, you have code for setting up a web
> >>> application right out of the box!
> >>>
> >>> Imagen what a relieve it would be for all of you folks to speak
> >>> about extensions and the core project, manage the dependencies
> >>> for those individually. Imagen having more then one swing reference
> >>> documentation. One for the core, one for the web, one for RPC and
> >>> so on. Boy I would be lucky if I were you :-).
> >>>
> >>>
> >>> Martin (Kersten)
> >>>
> >>> PS: Just a hint! ;-)
> >>>
> >>>> Erwin Vervaet wrote:
> >>>>
> >>>>> I think the main reason to use the W3C DOM API directly is to
> >>>>> avoid the need for an extra dependency (e.g. JDOM) just to parse
> >>>>> the XML bean definitions. You end up with an "less than elegant"
> >>>>> implementation in DefaultXmlBeanDefinitionParser, but in this case
> >>>>> the benifits outweigh the costs.
> >>>>>  Erwin Vervaet
> >>>>> erw...@er... <mailto:erw...@er...>
> >>>>>
> >>>>>     ----- Original Message -----
> >>>>>     *From:* Martin Kersten
> >>>>>     <mailto:Mar...@St...>
> >>>>>     *To:* spr...@li...
> >>>>>     <mailto:spr...@li...>
> >>>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
> >>>>>     *Subject:* [Springframework-developer] I don't like the
> >>>>>     DefaultXmlBeanDefinitionParser
> >>>>>
> >>>>>     Hi folks,
> >>>>>      I am currently trying to extend the framework by supporting
> >>>>>     contributions.
> >>>>>     Just to see how it feels.
> >>>>>      So I made some investigations in the sourcecode. I don't want to
> >>>>>     start a war
> >>>>>     about proper design rules, since I am a believer in 'Interface
> >>>>>     belongs to the
> >>>>>     client' stuff and you are appearently not, but this isn't the
> >>>>>     issue I want to
> >>>>>     talk about.
> >>>>>      Th implementation I hate most on first sight is the
> >>>>>     XMLBeanDefinitionParser. I know it does what it should but you
> >>>>> can
> >>>>>     read this:
> >>>>>      /**
> >>>>>       * Make the horrible DOM API slightly more bearable:
> >>>>>       * get the text value we know this element contains.
> >>>>>       */
> >>>>>      Well I would agree but it's a bit wired also. You think the DOM
> >>>>>     API is horrible
> >>>>>     and you are still using it? You know what it means to use a
> >>>>>     horrible API? You write a horrible implementation! And thats how
> >>>>>     it looks.
> >>>>>     It took me more then a gaze to catch the meaning of the parser
> >>>>> and
> >>>>>     I also
> >>>>>     got blown by the code duplication. Since I am in need to extend
> >>>>>     this class,
> >>>>>      So I would like to ask if I may refactor it and commit you a
> >>>>> patch
> >>>>>     (or maybe
> >>>>>     a complete reimplementation)?
> >>>>>      Cheers,
> >>>>>      Martin (Kersten)
> >>>>>      PS: By the way, how about 'Hidding 3rd party library behind
> >>>>> single
> >>>>>     interface?'
> >>>>>
> >>>>>         ----- Original Message -----
> >>>>>         *From:* Martin Kersten
> >>>>>         <mailto:Mar...@St...>
> >>>>>         *To:* spr...@li...
> >>>>>         <mailto:spr...@li...>
> >>>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
> >>>>>         *Subject:* Re: [Springframework-developer] Please check these
> >>>>>         two things
> >>>>>
> >>>>>         Sorry, thought the agreement goes with the callee. Ok :-)
> >>>>> sorry was a strange day for me, I guess.
> >>>>>          Thanks,
> >>>>>          Martin (Kersten)
> >>>>>         ----- Original Message -----
> >>>>>
> >>>>>             *From:* Juergen Hoeller <mailto:ju...@in...>
> >>>>>             *To:* spr...@li...
> >>>>>             <mailto:spr...@li...>
> >>>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
> >>>>>             *Subject:* Re: [Springframework-developer] Please check
> >>>>>             these two things
> >>>>>
> >>>>>             Actually, I have *not* replaced this with a == comparison
> >>>>>             of the arrays: Instead, BatchSqlUpdate is storing clones
> >>>>>             of the passed-in arrays now, for execution on flush. This
> >>>>>             avoids any side effects in the first place (even if the
> >>>>>             passed-in arrays are changed afterwards or reused for
> >>>>>             multiple update inovcations), and the overhead of cloning
> >>>>>             an array should be acceptable (after all, we're talking
> >>>>>             about database update operations here).
> >>>>>              Juergen
> >>>>>
> >>>>>                 -----Original Message-----
> >>>>>                 *From:*
> >>>>>                 spr...@li...
> >>>>>
> >>>>> [mailto:spr...@li...]*On
> >>>>>                 Behalf Of *Martin Kersten
> >>>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
> >>>>>                 *To:* spr...@li...
> >>>>>                 *Subject:* Re: [Springframework-developer] Please
> >>>>>                 check these two things
> >>>>>
> >>>>>                 But isn't this bogus thinking? I mean replacing
> >>>>>                 .equals with == makes
> >>>>>                 the implementation more strickt and reduces
> >>>>> semantical
> >>>>>                 informations.
> >>>>>                 We are thinking about objects and there is no
> >>>>>                 performance gap
> >>>>>                 to justify this modification.
> >>>>>                  I wouldn't do it. I just would ensure that equals
> >>>>>                 implementations
> >>>>>                 start with if(this==object) return true;. How huge is
> >>>>>                 the estimated
> >>>>>                 performance gain?
> >>>>>
> >>>>>                 Cheers,
> >>>>>                  Martin (Kersten)
> >>>>>
> >>>>>                     ----- Original Message -----
> >>>>>                     *From:* Juergen Hoeller
> >>>>>                     <mailto:ju...@in...>
> >>>>>                     *To:*
> >>>>>                     spr...@li...
> >>>>>
> >>>>> <mailto:spr...@li...>
> >>>>>
> >>>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
> >>>>>                     *Subject:* Re: [Springframework-developer] Please
> >>>>>                     check these two things
> >>>>>
> >>>>>                     Well-spotted!
> >>>>>                      ConcurrencyThrottleInterceptor should indeed use
> >>>>>                     an internal monitor to avoid any potential for
> >>>>>                     side effects. I doubt that this has caused any
> >>>>>                     issue in practice, but it's nevertheless cleaner.
> >>>>>                      That check in BatchSqlUpdate is not supposed to
> >>>>>                     compare the elements but just the array
> >>>>> reference:
> >>>>>                     Repeated update invocations should not pass-in
> >>>>> the
> >>>>>                     same array instance repeatedly, with modified
> >>>>>                     elements. Of course, a == check would be
> >>>>>                     sufficient for this. I've reworked that part a
> >>>>> bit
> >>>>>                     differently, though: BatchSqlUpdate stores a
> >>>>> clone
> >>>>>                     of the passed-in array now, so there shouldn't be
> >>>>>                     a need for such a check anymore.
> >>>>>                      Juergen
> >>>>>
> >>>>>                         -----Original Message-----
> >>>>>                         *From:*
> >>>>>
> >>>>> spr...@li...
> >>>>>
> >>>>> [mailto:spr...@li...]*On
> >>>>>                         Behalf Of *Dave Brosius
> >>>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
> >>>>>                         *To:*
> >>>>>
> >>>>> spr...@li...
> >>>>>                         *Subject:* [Springframework-developer] Please
> >>>>>                         check these two things
> >>>>>
> >>>>>                         These may be problems, and then again maybe
> >>>>>                         not. But they seem odd/wrong to me
> >>>>>                          1) In
> >>>>>
> >>>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
> >>>>>                          in method invoke
> >>>>>                          uses wait on 'this'
> >>>>>                          In my mind you are exposing your
> >>>>>                         synchronization strategies as a public
> >>>>>                         artifact, which leaves this class open to
> >>>>>                         failure due to client code.
> >>>>>                         The client code may unwittingly us an
> >>>>> instance
> >>>>>                         of this class to do it's own synchronization,
> >>>>>                         and totally screw up this class.
> >>>>>                         I would recommend doing synchronizations
> >>>>>                         (especially the use of wait/notify) on a
> >>>>>                         private member so client code can not
> >>>>> effect it.
> >>>>>                          2) In
> >>>>>
> >>>>> org.springframework.jdbc.object.BatchSqlUpdate
> >>>>>                          in method update, you do
> >>>>>                          if (!this.parameterQueue.isEmpty() &&
> >>>>>                         args.equals(this.parameterQueue.getLast())) {
> >>>>>                          this is the same as using     args ==
> >>>>>                         this.parameterQueue.getLast()
> >>>>>                          or in other words, are these objects the
> >>>>> same
> >>>>>                         object. I assume you want to compare the
> >>>>>                         elements of the array?
> >>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> SF email is sponsored by - The IT Product Guide
> >>>> Read honest & candid reviews on hundreds of IT Products from real
> >>>> users.
> >>>> Discover which products truly live up to the hype. Start reading now.
> >>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>> _______________________________________________
> >>>> Springframework-developer mailing list
> >>>> Spr...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF email is sponsored by - The IT Product Guide
> >>> Read honest & candid reviews on hundreds of IT Products from real
> >>> users.
> >>> Discover which products truly live up to the hype. Start reading now.
> >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>> _______________________________________________
> >>> Springframework-developer mailing list
> >>> Spr...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> SF email is sponsored by - The IT Product Guide
> >> Read honest & candid reviews on hundreds of IT Products from real users.
> >> Discover which products truly live up to the hype. Start reading now.
> >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Rob H. <ro...@ca...>]

Just spring-aop.jar plus the aopalliance.jar. You will need 
spring-core.jar if you want to use a BeanFactory.

Rob

Steven Devijver wrote:

>And what jars do I require to use the aop part, for example?
>
>
>On Tue, 22 Feb 2005 15:20:55 +0000, Rob Harrop <ro...@ca...> wrote:
>  
>
>>Its already split up as core, web, mvc, jdbc, orm and aop.
>>
>>Rob
>>
>>Martin Kersten wrote:
>>
>>    
>>
>>>>The distribution comes with different JARs for different
>>>>circumstances, but it might be nice to be able to download them
>>>>separately as well.
>>>>        
>>>>
>>>How does web fits the vision of the core framework? It's really an
>>>issue. Would you also like to deliver the rich client platform
>>>and it's dependency also within the framework?
>>>
>>>But downloading the required jars based on the case scenario
>>>the user has would be a great improvement anyways. For my
>>>current research I would like to had the option to get a
>>>web free, jdbc free, jms free, mail free, orm free, remoting free,
>>>transaction free Spring version.
>>>
>>>If I would be in charge I would split it up the following way:
>>>
>>>core, web, j2ee, persistence, later rpc.
>>>
>>>
>>>Cheers,
>>>
>>>Martin (Kersten)
>>>
>>>
>>>      
>>>
>>>>Rob
>>>>
>>>>Martin Kersten wrote:
>>>>
>>>>        
>>>>
>>>>>>My thoughts exactly :). We have enough dependencies already.
>>>>>>            
>>>>>>
>>>>>
>>>>>You should break up your framework anyways.
>>>>>
>>>>>You are currently providing a 'Jack of all trades' API. A solution
>>>>>for everything but nothing in particular.
>>>>>
>>>>>Don't get mad :-) Here is what I mean:
>>>>>
>>>>>Spring adapts services for many diffrent situations:
>>>>> You having a web application, fine download the
>>>>>     default spring framework,
>>>>> You have a command line application, fine download
>>>>>      the default spring framework
>>>>>
>>>>> If it's not in the framework, we dont support it.
>>>>>
>>>>>Thats what I mean. Download the framework and be happy.
>>>>>
>>>>>It's like java, download the SE and you have all the stuff those
>>>>>folks think some (!) people might(!) wanna have.
>>>>>
>>>>>How about making a core framework and having extensions.
>>>>>
>>>>>So you go for a normal application, just download the core
>>>>>framework. You want to go for a web application, download
>>>>>the core framework and download the web extension.
>>>>>
>>>>>You know I am currently trying to get my visions into the RPC
>>>>>sub project. And when you start to develop your own
>>>>>rich client(!) guess what, you have code for setting up a web
>>>>>application right out of the box!
>>>>>
>>>>>Imagen what a relieve it would be for all of you folks to speak
>>>>>about extensions and the core project, manage the dependencies
>>>>>for those individually. Imagen having more then one swing reference
>>>>>documentation. One for the core, one for the web, one for RPC and
>>>>>so on. Boy I would be lucky if I were you :-).
>>>>>
>>>>>
>>>>>Martin (Kersten)
>>>>>
>>>>>PS: Just a hint! ;-)
>>>>>
>>>>>          
>>>>>
>>>>>>Erwin Vervaet wrote:
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>I think the main reason to use the W3C DOM API directly is to
>>>>>>>avoid the need for an extra dependency (e.g. JDOM) just to parse
>>>>>>>the XML bean definitions. You end up with an "less than elegant"
>>>>>>>implementation in DefaultXmlBeanDefinitionParser, but in this case
>>>>>>>the benifits outweigh the costs.
>>>>>>> Erwin Vervaet
>>>>>>>erw...@er... <mailto:erw...@er...>
>>>>>>>
>>>>>>>    ----- Original Message -----
>>>>>>>    *From:* Martin Kersten
>>>>>>>    <mailto:Mar...@St...>
>>>>>>>    *To:* spr...@li...
>>>>>>>    <mailto:spr...@li...>
>>>>>>>    *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>>>>>    *Subject:* [Springframework-developer] I don't like the
>>>>>>>    DefaultXmlBeanDefinitionParser
>>>>>>>
>>>>>>>    Hi folks,
>>>>>>>     I am currently trying to extend the framework by supporting
>>>>>>>    contributions.
>>>>>>>    Just to see how it feels.
>>>>>>>     So I made some investigations in the sourcecode. I don't want to
>>>>>>>    start a war
>>>>>>>    about proper design rules, since I am a believer in 'Interface
>>>>>>>    belongs to the
>>>>>>>    client' stuff and you are appearently not, but this isn't the
>>>>>>>    issue I want to
>>>>>>>    talk about.
>>>>>>>     Th implementation I hate most on first sight is the
>>>>>>>    XMLBeanDefinitionParser. I know it does what it should but you
>>>>>>>can
>>>>>>>    read this:
>>>>>>>     /**
>>>>>>>      * Make the horrible DOM API slightly more bearable:
>>>>>>>      * get the text value we know this element contains.
>>>>>>>      */
>>>>>>>     Well I would agree but it's a bit wired also. You think the DOM
>>>>>>>    API is horrible
>>>>>>>    and you are still using it? You know what it means to use a
>>>>>>>    horrible API? You write a horrible implementation! And thats how
>>>>>>>    it looks.
>>>>>>>    It took me more then a gaze to catch the meaning of the parser
>>>>>>>and
>>>>>>>    I also
>>>>>>>    got blown by the code duplication. Since I am in need to extend
>>>>>>>    this class,
>>>>>>>     So I would like to ask if I may refactor it and commit you a
>>>>>>>patch
>>>>>>>    (or maybe
>>>>>>>    a complete reimplementation)?
>>>>>>>     Cheers,
>>>>>>>     Martin (Kersten)
>>>>>>>     PS: By the way, how about 'Hidding 3rd party library behind
>>>>>>>single
>>>>>>>    interface?'
>>>>>>>
>>>>>>>        ----- Original Message -----
>>>>>>>        *From:* Martin Kersten
>>>>>>>        <mailto:Mar...@St...>
>>>>>>>        *To:* spr...@li...
>>>>>>>        <mailto:spr...@li...>
>>>>>>>        *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>>>>>        *Subject:* Re: [Springframework-developer] Please check these
>>>>>>>        two things
>>>>>>>
>>>>>>>        Sorry, thought the agreement goes with the callee. Ok :-)
>>>>>>>sorry was a strange day for me, I guess.
>>>>>>>         Thanks,
>>>>>>>         Martin (Kersten)
>>>>>>>        ----- Original Message -----
>>>>>>>
>>>>>>>            *From:* Juergen Hoeller <mailto:ju...@in...>
>>>>>>>            *To:* spr...@li...
>>>>>>>            <mailto:spr...@li...>
>>>>>>>            *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>>>>>            *Subject:* Re: [Springframework-developer] Please check
>>>>>>>            these two things
>>>>>>>
>>>>>>>            Actually, I have *not* replaced this with a == comparison
>>>>>>>            of the arrays: Instead, BatchSqlUpdate is storing clones
>>>>>>>            of the passed-in arrays now, for execution on flush. This
>>>>>>>            avoids any side effects in the first place (even if the
>>>>>>>            passed-in arrays are changed afterwards or reused for
>>>>>>>            multiple update inovcations), and the overhead of cloning
>>>>>>>            an array should be acceptable (after all, we're talking
>>>>>>>            about database update operations here).
>>>>>>>             Juergen
>>>>>>>
>>>>>>>                -----Original Message-----
>>>>>>>                *From:*
>>>>>>>                spr...@li...
>>>>>>>
>>>>>>>[mailto:spr...@li...]*On
>>>>>>>                Behalf Of *Martin Kersten
>>>>>>>                *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>>>>>                *To:* spr...@li...
>>>>>>>                *Subject:* Re: [Springframework-developer] Please
>>>>>>>                check these two things
>>>>>>>
>>>>>>>                But isn't this bogus thinking? I mean replacing
>>>>>>>                .equals with == makes
>>>>>>>                the implementation more strickt and reduces
>>>>>>>semantical
>>>>>>>                informations.
>>>>>>>                We are thinking about objects and there is no
>>>>>>>                performance gap
>>>>>>>                to justify this modification.
>>>>>>>                 I wouldn't do it. I just would ensure that equals
>>>>>>>                implementations
>>>>>>>                start with if(this==object) return true;. How huge is
>>>>>>>                the estimated
>>>>>>>                performance gain?
>>>>>>>
>>>>>>>                Cheers,
>>>>>>>                 Martin (Kersten)
>>>>>>>
>>>>>>>                    ----- Original Message -----
>>>>>>>                    *From:* Juergen Hoeller
>>>>>>>                    <mailto:ju...@in...>
>>>>>>>                    *To:*
>>>>>>>                    spr...@li...
>>>>>>>
>>>>>>><mailto:spr...@li...>
>>>>>>>
>>>>>>>                    *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>>>>>                    *Subject:* Re: [Springframework-developer] Please
>>>>>>>                    check these two things
>>>>>>>
>>>>>>>                    Well-spotted!
>>>>>>>                     ConcurrencyThrottleInterceptor should indeed use
>>>>>>>                    an internal monitor to avoid any potential for
>>>>>>>                    side effects. I doubt that this has caused any
>>>>>>>                    issue in practice, but it's nevertheless cleaner.
>>>>>>>                     That check in BatchSqlUpdate is not supposed to
>>>>>>>                    compare the elements but just the array
>>>>>>>reference:
>>>>>>>                    Repeated update invocations should not pass-in
>>>>>>>the
>>>>>>>                    same array instance repeatedly, with modified
>>>>>>>                    elements. Of course, a == check would be
>>>>>>>                    sufficient for this. I've reworked that part a
>>>>>>>bit
>>>>>>>                    differently, though: BatchSqlUpdate stores a
>>>>>>>clone
>>>>>>>                    of the passed-in array now, so there shouldn't be
>>>>>>>                    a need for such a check anymore.
>>>>>>>                     Juergen
>>>>>>>
>>>>>>>                        -----Original Message-----
>>>>>>>                        *From:*
>>>>>>>
>>>>>>>spr...@li...
>>>>>>>
>>>>>>>[mailto:spr...@li...]*On
>>>>>>>                        Behalf Of *Dave Brosius
>>>>>>>                        *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>>>>>                        *To:*
>>>>>>>
>>>>>>>spr...@li...
>>>>>>>                        *Subject:* [Springframework-developer] Please
>>>>>>>                        check these two things
>>>>>>>
>>>>>>>                        These may be problems, and then again maybe
>>>>>>>                        not. But they seem odd/wrong to me
>>>>>>>                         1) In
>>>>>>>
>>>>>>>org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>>>>                         in method invoke
>>>>>>>                         uses wait on 'this'
>>>>>>>                         In my mind you are exposing your
>>>>>>>                        synchronization strategies as a public
>>>>>>>                        artifact, which leaves this class open to
>>>>>>>                        failure due to client code.
>>>>>>>                        The client code may unwittingly us an
>>>>>>>instance
>>>>>>>                        of this class to do it's own synchronization,
>>>>>>>                        and totally screw up this class.
>>>>>>>                        I would recommend doing synchronizations
>>>>>>>                        (especially the use of wait/notify) on a
>>>>>>>                        private member so client code can not
>>>>>>>effect it.
>>>>>>>                         2) In
>>>>>>>
>>>>>>>org.springframework.jdbc.object.BatchSqlUpdate
>>>>>>>                         in method update, you do
>>>>>>>                         if (!this.parameterQueue.isEmpty() &&
>>>>>>>                        args.equals(this.parameterQueue.getLast())) {
>>>>>>>                         this is the same as using     args ==
>>>>>>>                        this.parameterQueue.getLast()
>>>>>>>                         or in other words, are these objects the
>>>>>>>same
>>>>>>>                        object. I assume you want to compare the
>>>>>>>                        elements of the array?
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>users.
>>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>_______________________________________________
>>>>>>Springframework-developer mailing list
>>>>>>Spr...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>>            
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>SF email is sponsored by - The IT Product Guide
>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>users.
>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>>Spr...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>-------------------------------------------------------
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>_______________________________________________
>>>>Springframework-developer mailing list
>>>>Spr...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>        
>>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>      
>>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Steven D. <ste...@gm...>]

cglib?


On Tue, 22 Feb 2005 15:56:04 +0000, Rob Harrop <ro...@ca...> wrote:
> Just spring-aop.jar plus the aopalliance.jar. You will need
> spring-core.jar if you want to use a BeanFactory.
> 
> Rob
> 
> Steven Devijver wrote:
> 
> >And what jars do I require to use the aop part, for example?
> >
> >
> >On Tue, 22 Feb 2005 15:20:55 +0000, Rob Harrop <ro...@ca...> wrote:
> >
> >
> >>Its already split up as core, web, mvc, jdbc, orm and aop.
> >>
> >>Rob
> >>
> >>Martin Kersten wrote:
> >>
> >>
> >>
> >>>>The distribution comes with different JARs for different
> >>>>circumstances, but it might be nice to be able to download them
> >>>>separately as well.
> >>>>
> >>>>
> >>>How does web fits the vision of the core framework? It's really an
> >>>issue. Would you also like to deliver the rich client platform
> >>>and it's dependency also within the framework?
> >>>
> >>>But downloading the required jars based on the case scenario
> >>>the user has would be a great improvement anyways. For my
> >>>current research I would like to had the option to get a
> >>>web free, jdbc free, jms free, mail free, orm free, remoting free,
> >>>transaction free Spring version.
> >>>
> >>>If I would be in charge I would split it up the following way:
> >>>
> >>>core, web, j2ee, persistence, later rpc.
> >>>
> >>>
> >>>Cheers,
> >>>
> >>>Martin (Kersten)
> >>>
> >>>
> >>>
> >>>
> >>>>Rob
> >>>>
> >>>>Martin Kersten wrote:
> >>>>
> >>>>
> >>>>
> >>>>>>My thoughts exactly :). We have enough dependencies already.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>You should break up your framework anyways.
> >>>>>
> >>>>>You are currently providing a 'Jack of all trades' API. A solution
> >>>>>for everything but nothing in particular.
> >>>>>
> >>>>>Don't get mad :-) Here is what I mean:
> >>>>>
> >>>>>Spring adapts services for many diffrent situations:
> >>>>> You having a web application, fine download the
> >>>>>     default spring framework,
> >>>>> You have a command line application, fine download
> >>>>>      the default spring framework
> >>>>>
> >>>>> If it's not in the framework, we dont support it.
> >>>>>
> >>>>>Thats what I mean. Download the framework and be happy.
> >>>>>
> >>>>>It's like java, download the SE and you have all the stuff those
> >>>>>folks think some (!) people might(!) wanna have.
> >>>>>
> >>>>>How about making a core framework and having extensions.
> >>>>>
> >>>>>So you go for a normal application, just download the core
> >>>>>framework. You want to go for a web application, download
> >>>>>the core framework and download the web extension.
> >>>>>
> >>>>>You know I am currently trying to get my visions into the RPC
> >>>>>sub project. And when you start to develop your own
> >>>>>rich client(!) guess what, you have code for setting up a web
> >>>>>application right out of the box!
> >>>>>
> >>>>>Imagen what a relieve it would be for all of you folks to speak
> >>>>>about extensions and the core project, manage the dependencies
> >>>>>for those individually. Imagen having more then one swing reference
> >>>>>documentation. One for the core, one for the web, one for RPC and
> >>>>>so on. Boy I would be lucky if I were you :-).
> >>>>>
> >>>>>
> >>>>>Martin (Kersten)
> >>>>>
> >>>>>PS: Just a hint! ;-)
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Erwin Vervaet wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>I think the main reason to use the W3C DOM API directly is to
> >>>>>>>avoid the need for an extra dependency (e.g. JDOM) just to parse
> >>>>>>>the XML bean definitions. You end up with an "less than elegant"
> >>>>>>>implementation in DefaultXmlBeanDefinitionParser, but in this case
> >>>>>>>the benifits outweigh the costs.
> >>>>>>> Erwin Vervaet
> >>>>>>>erw...@er... <mailto:erw...@er...>
> >>>>>>>
> >>>>>>>    ----- Original Message -----
> >>>>>>>    *From:* Martin Kersten
> >>>>>>>    <mailto:Mar...@St...>
> >>>>>>>    *To:* spr...@li...
> >>>>>>>    <mailto:spr...@li...>
> >>>>>>>    *Sent:* Tuesday, February 22, 2005 1:21 PM
> >>>>>>>    *Subject:* [Springframework-developer] I don't like the
> >>>>>>>    DefaultXmlBeanDefinitionParser
> >>>>>>>
> >>>>>>>    Hi folks,
> >>>>>>>     I am currently trying to extend the framework by supporting
> >>>>>>>    contributions.
> >>>>>>>    Just to see how it feels.
> >>>>>>>     So I made some investigations in the sourcecode. I don't want to
> >>>>>>>    start a war
> >>>>>>>    about proper design rules, since I am a believer in 'Interface
> >>>>>>>    belongs to the
> >>>>>>>    client' stuff and you are appearently not, but this isn't the
> >>>>>>>    issue I want to
> >>>>>>>    talk about.
> >>>>>>>     Th implementation I hate most on first sight is the
> >>>>>>>    XMLBeanDefinitionParser. I know it does what it should but you
> >>>>>>>can
> >>>>>>>    read this:
> >>>>>>>     /**
> >>>>>>>      * Make the horrible DOM API slightly more bearable:
> >>>>>>>      * get the text value we know this element contains.
> >>>>>>>      */
> >>>>>>>     Well I would agree but it's a bit wired also. You think the DOM
> >>>>>>>    API is horrible
> >>>>>>>    and you are still using it? You know what it means to use a
> >>>>>>>    horrible API? You write a horrible implementation! And thats how
> >>>>>>>    it looks.
> >>>>>>>    It took me more then a gaze to catch the meaning of the parser
> >>>>>>>and
> >>>>>>>    I also
> >>>>>>>    got blown by the code duplication. Since I am in need to extend
> >>>>>>>    this class,
> >>>>>>>     So I would like to ask if I may refactor it and commit you a
> >>>>>>>patch
> >>>>>>>    (or maybe
> >>>>>>>    a complete reimplementation)?
> >>>>>>>     Cheers,
> >>>>>>>     Martin (Kersten)
> >>>>>>>     PS: By the way, how about 'Hidding 3rd party library behind
> >>>>>>>single
> >>>>>>>    interface?'
> >>>>>>>
> >>>>>>>        ----- Original Message -----
> >>>>>>>        *From:* Martin Kersten
> >>>>>>>        <mailto:Mar...@St...>
> >>>>>>>        *To:* spr...@li...
> >>>>>>>        <mailto:spr...@li...>
> >>>>>>>        *Sent:* Tuesday, February 22, 2005 12:46 PM
> >>>>>>>        *Subject:* Re: [Springframework-developer] Please check these
> >>>>>>>        two things
> >>>>>>>
> >>>>>>>        Sorry, thought the agreement goes with the callee. Ok :-)
> >>>>>>>sorry was a strange day for me, I guess.
> >>>>>>>         Thanks,
> >>>>>>>         Martin (Kersten)
> >>>>>>>        ----- Original Message -----
> >>>>>>>
> >>>>>>>            *From:* Juergen Hoeller <mailto:ju...@in...>
> >>>>>>>            *To:* spr...@li...
> >>>>>>>            <mailto:spr...@li...>
> >>>>>>>            *Sent:* Tuesday, February 22, 2005 12:13 PM
> >>>>>>>            *Subject:* Re: [Springframework-developer] Please check
> >>>>>>>            these two things
> >>>>>>>
> >>>>>>>            Actually, I have *not* replaced this with a == comparison
> >>>>>>>            of the arrays: Instead, BatchSqlUpdate is storing clones
> >>>>>>>            of the passed-in arrays now, for execution on flush. This
> >>>>>>>            avoids any side effects in the first place (even if the
> >>>>>>>            passed-in arrays are changed afterwards or reused for
> >>>>>>>            multiple update inovcations), and the overhead of cloning
> >>>>>>>            an array should be acceptable (after all, we're talking
> >>>>>>>            about database update operations here).
> >>>>>>>             Juergen
> >>>>>>>
> >>>>>>>                -----Original Message-----
> >>>>>>>                *From:*
> >>>>>>>                spr...@li...
> >>>>>>>
> >>>>>>>[mailto:spr...@li...]*On
> >>>>>>>                Behalf Of *Martin Kersten
> >>>>>>>                *Sent:* Tuesday, February 22, 2005 12:04 PM
> >>>>>>>                *To:* spr...@li...
> >>>>>>>                *Subject:* Re: [Springframework-developer] Please
> >>>>>>>                check these two things
> >>>>>>>
> >>>>>>>                But isn't this bogus thinking? I mean replacing
> >>>>>>>                .equals with == makes
> >>>>>>>                the implementation more strickt and reduces
> >>>>>>>semantical
> >>>>>>>                informations.
> >>>>>>>                We are thinking about objects and there is no
> >>>>>>>                performance gap
> >>>>>>>                to justify this modification.
> >>>>>>>                 I wouldn't do it. I just would ensure that equals
> >>>>>>>                implementations
> >>>>>>>                start with if(this==object) return true;. How huge is
> >>>>>>>                the estimated
> >>>>>>>                performance gain?
> >>>>>>>
> >>>>>>>                Cheers,
> >>>>>>>                 Martin (Kersten)
> >>>>>>>
> >>>>>>>                    ----- Original Message -----
> >>>>>>>                    *From:* Juergen Hoeller
> >>>>>>>                    <mailto:ju...@in...>
> >>>>>>>                    *To:*
> >>>>>>>                    spr...@li...
> >>>>>>>
> >>>>>>><mailto:spr...@li...>
> >>>>>>>
> >>>>>>>                    *Sent:* Tuesday, February 22, 2005 10:06 AM
> >>>>>>>                    *Subject:* Re: [Springframework-developer] Please
> >>>>>>>                    check these two things
> >>>>>>>
> >>>>>>>                    Well-spotted!
> >>>>>>>                     ConcurrencyThrottleInterceptor should indeed use
> >>>>>>>                    an internal monitor to avoid any potential for
> >>>>>>>                    side effects. I doubt that this has caused any
> >>>>>>>                    issue in practice, but it's nevertheless cleaner.
> >>>>>>>                     That check in BatchSqlUpdate is not supposed to
> >>>>>>>                    compare the elements but just the array
> >>>>>>>reference:
> >>>>>>>                    Repeated update invocations should not pass-in
> >>>>>>>the
> >>>>>>>                    same array instance repeatedly, with modified
> >>>>>>>                    elements. Of course, a == check would be
> >>>>>>>                    sufficient for this. I've reworked that part a
> >>>>>>>bit
> >>>>>>>                    differently, though: BatchSqlUpdate stores a
> >>>>>>>clone
> >>>>>>>                    of the passed-in array now, so there shouldn't be
> >>>>>>>                    a need for such a check anymore.
> >>>>>>>                     Juergen
> >>>>>>>
> >>>>>>>                        -----Original Message-----
> >>>>>>>                        *From:*
> >>>>>>>
> >>>>>>>spr...@li...
> >>>>>>>
> >>>>>>>[mailto:spr...@li...]*On
> >>>>>>>                        Behalf Of *Dave Brosius
> >>>>>>>                        *Sent:* Tuesday, February 22, 2005 8:08 AM
> >>>>>>>                        *To:*
> >>>>>>>
> >>>>>>>spr...@li...
> >>>>>>>                        *Subject:* [Springframework-developer] Please
> >>>>>>>                        check these two things
> >>>>>>>
> >>>>>>>                        These may be problems, and then again maybe
> >>>>>>>                        not. But they seem odd/wrong to me
> >>>>>>>                         1) In
> >>>>>>>
> >>>>>>>org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
> >>>>>>>                         in method invoke
> >>>>>>>                         uses wait on 'this'
> >>>>>>>                         In my mind you are exposing your
> >>>>>>>                        synchronization strategies as a public
> >>>>>>>                        artifact, which leaves this class open to
> >>>>>>>                        failure due to client code.
> >>>>>>>                        The client code may unwittingly us an
> >>>>>>>instance
> >>>>>>>                        of this class to do it's own synchronization,
> >>>>>>>                        and totally screw up this class.
> >>>>>>>                        I would recommend doing synchronizations
> >>>>>>>                        (especially the use of wait/notify) on a
> >>>>>>>                        private member so client code can not
> >>>>>>>effect it.
> >>>>>>>                         2) In
> >>>>>>>
> >>>>>>>org.springframework.jdbc.object.BatchSqlUpdate
> >>>>>>>                         in method update, you do
> >>>>>>>                         if (!this.parameterQueue.isEmpty() &&
> >>>>>>>                        args.equals(this.parameterQueue.getLast())) {
> >>>>>>>                         this is the same as using     args ==
> >>>>>>>                        this.parameterQueue.getLast()
> >>>>>>>                         or in other words, are these objects the
> >>>>>>>same
> >>>>>>>                        object. I assume you want to compare the
> >>>>>>>                        elements of the array?
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>-------------------------------------------------------
> >>>>>>SF email is sponsored by - The IT Product Guide
> >>>>>>Read honest & candid reviews on hundreds of IT Products from real
> >>>>>>users.
> >>>>>>Discover which products truly live up to the hype. Start reading now.
> >>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>>>_______________________________________________
> >>>>>>Springframework-developer mailing list
> >>>>>>Spr...@li...
> >>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>-------------------------------------------------------
> >>>>>SF email is sponsored by - The IT Product Guide
> >>>>>Read honest & candid reviews on hundreds of IT Products from real
> >>>>>users.
> >>>>>Discover which products truly live up to the hype. Start reading now.
> >>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>>_______________________________________________
> >>>>>Springframework-developer mailing list
> >>>>>Spr...@li...
> >>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>-------------------------------------------------------
> >>>>SF email is sponsored by - The IT Product Guide
> >>>>Read honest & candid reviews on hundreds of IT Products from real users.
> >>>>Discover which products truly live up to the hype. Start reading now.
> >>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>_______________________________________________
> >>>>Springframework-developer mailing list
> >>>>Spr...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>
> >>>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>SF email is sponsored by - The IT Product Guide
> >>>Read honest & candid reviews on hundreds of IT Products from real users.
> >>>Discover which products truly live up to the hype. Start reading now.
> >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>_______________________________________________
> >>>Springframework-developer mailing list
> >>>Spr...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>
> >>>
> >>>
> >>>
> >>-------------------------------------------------------
> >>SF email is sponsored by - The IT Product Guide
> >>Read honest & candid reviews on hundreds of IT Products from real users.
> >>Discover which products truly live up to the hype. Start reading now.
> >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Rob H. <ro...@ca...>]

Only if you use class proxies. If you stick to JDK proxies you can leave 
CGLIB out.

Rob

Steven Devijver wrote:

>cglib?
>
>
>On Tue, 22 Feb 2005 15:56:04 +0000, Rob Harrop <ro...@ca...> wrote:
>  
>
>>Just spring-aop.jar plus the aopalliance.jar. You will need
>>spring-core.jar if you want to use a BeanFactory.
>>
>>Rob
>>
>>Steven Devijver wrote:
>>
>>    
>>
>>>And what jars do I require to use the aop part, for example?
>>>
>>>
>>>On Tue, 22 Feb 2005 15:20:55 +0000, Rob Harrop <ro...@ca...> wrote:
>>>
>>>
>>>      
>>>
>>>>Its already split up as core, web, mvc, jdbc, orm and aop.
>>>>
>>>>Rob
>>>>
>>>>Martin Kersten wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>>The distribution comes with different JARs for different
>>>>>>circumstances, but it might be nice to be able to download them
>>>>>>separately as well.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>How does web fits the vision of the core framework? It's really an
>>>>>issue. Would you also like to deliver the rich client platform
>>>>>and it's dependency also within the framework?
>>>>>
>>>>>But downloading the required jars based on the case scenario
>>>>>the user has would be a great improvement anyways. For my
>>>>>current research I would like to had the option to get a
>>>>>web free, jdbc free, jms free, mail free, orm free, remoting free,
>>>>>transaction free Spring version.
>>>>>
>>>>>If I would be in charge I would split it up the following way:
>>>>>
>>>>>core, web, j2ee, persistence, later rpc.
>>>>>
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Martin (Kersten)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Rob
>>>>>>
>>>>>>Martin Kersten wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>My thoughts exactly :). We have enough dependencies already.
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>You should break up your framework anyways.
>>>>>>>
>>>>>>>You are currently providing a 'Jack of all trades' API. A solution
>>>>>>>for everything but nothing in particular.
>>>>>>>
>>>>>>>Don't get mad :-) Here is what I mean:
>>>>>>>
>>>>>>>Spring adapts services for many diffrent situations:
>>>>>>>You having a web application, fine download the
>>>>>>>    default spring framework,
>>>>>>>You have a command line application, fine download
>>>>>>>     the default spring framework
>>>>>>>
>>>>>>>If it's not in the framework, we dont support it.
>>>>>>>
>>>>>>>Thats what I mean. Download the framework and be happy.
>>>>>>>
>>>>>>>It's like java, download the SE and you have all the stuff those
>>>>>>>folks think some (!) people might(!) wanna have.
>>>>>>>
>>>>>>>How about making a core framework and having extensions.
>>>>>>>
>>>>>>>So you go for a normal application, just download the core
>>>>>>>framework. You want to go for a web application, download
>>>>>>>the core framework and download the web extension.
>>>>>>>
>>>>>>>You know I am currently trying to get my visions into the RPC
>>>>>>>sub project. And when you start to develop your own
>>>>>>>rich client(!) guess what, you have code for setting up a web
>>>>>>>application right out of the box!
>>>>>>>
>>>>>>>Imagen what a relieve it would be for all of you folks to speak
>>>>>>>about extensions and the core project, manage the dependencies
>>>>>>>for those individually. Imagen having more then one swing reference
>>>>>>>documentation. One for the core, one for the web, one for RPC and
>>>>>>>so on. Boy I would be lucky if I were you :-).
>>>>>>>
>>>>>>>
>>>>>>>Martin (Kersten)
>>>>>>>
>>>>>>>PS: Just a hint! ;-)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Erwin Vervaet wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>>>I think the main reason to use the W3C DOM API directly is to
>>>>>>>>>avoid the need for an extra dependency (e.g. JDOM) just to parse
>>>>>>>>>the XML bean definitions. You end up with an "less than elegant"
>>>>>>>>>implementation in DefaultXmlBeanDefinitionParser, but in this case
>>>>>>>>>the benifits outweigh the costs.
>>>>>>>>>Erwin Vervaet
>>>>>>>>>erw...@er... <mailto:erw...@er...>
>>>>>>>>>
>>>>>>>>>   ----- Original Message -----
>>>>>>>>>   *From:* Martin Kersten
>>>>>>>>>   <mailto:Mar...@St...>
>>>>>>>>>   *To:* spr...@li...
>>>>>>>>>   <mailto:spr...@li...>
>>>>>>>>>   *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>>>>>>>   *Subject:* [Springframework-developer] I don't like the
>>>>>>>>>   DefaultXmlBeanDefinitionParser
>>>>>>>>>
>>>>>>>>>   Hi folks,
>>>>>>>>>    I am currently trying to extend the framework by supporting
>>>>>>>>>   contributions.
>>>>>>>>>   Just to see how it feels.
>>>>>>>>>    So I made some investigations in the sourcecode. I don't want to
>>>>>>>>>   start a war
>>>>>>>>>   about proper design rules, since I am a believer in 'Interface
>>>>>>>>>   belongs to the
>>>>>>>>>   client' stuff and you are appearently not, but this isn't the
>>>>>>>>>   issue I want to
>>>>>>>>>   talk about.
>>>>>>>>>    Th implementation I hate most on first sight is the
>>>>>>>>>   XMLBeanDefinitionParser. I know it does what it should but you
>>>>>>>>>can
>>>>>>>>>   read this:
>>>>>>>>>    /**
>>>>>>>>>     * Make the horrible DOM API slightly more bearable:
>>>>>>>>>     * get the text value we know this element contains.
>>>>>>>>>     */
>>>>>>>>>    Well I would agree but it's a bit wired also. You think the DOM
>>>>>>>>>   API is horrible
>>>>>>>>>   and you are still using it? You know what it means to use a
>>>>>>>>>   horrible API? You write a horrible implementation! And thats how
>>>>>>>>>   it looks.
>>>>>>>>>   It took me more then a gaze to catch the meaning of the parser
>>>>>>>>>and
>>>>>>>>>   I also
>>>>>>>>>   got blown by the code duplication. Since I am in need to extend
>>>>>>>>>   this class,
>>>>>>>>>    So I would like to ask if I may refactor it and commit you a
>>>>>>>>>patch
>>>>>>>>>   (or maybe
>>>>>>>>>   a complete reimplementation)?
>>>>>>>>>    Cheers,
>>>>>>>>>    Martin (Kersten)
>>>>>>>>>    PS: By the way, how about 'Hidding 3rd party library behind
>>>>>>>>>single
>>>>>>>>>   interface?'
>>>>>>>>>
>>>>>>>>>       ----- Original Message -----
>>>>>>>>>       *From:* Martin Kersten
>>>>>>>>>       <mailto:Mar...@St...>
>>>>>>>>>       *To:* spr...@li...
>>>>>>>>>       <mailto:spr...@li...>
>>>>>>>>>       *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>>>>>>>       *Subject:* Re: [Springframework-developer] Please check these
>>>>>>>>>       two things
>>>>>>>>>
>>>>>>>>>       Sorry, thought the agreement goes with the callee. Ok :-)
>>>>>>>>>sorry was a strange day for me, I guess.
>>>>>>>>>        Thanks,
>>>>>>>>>        Martin (Kersten)
>>>>>>>>>       ----- Original Message -----
>>>>>>>>>
>>>>>>>>>           *From:* Juergen Hoeller <mailto:ju...@in...>
>>>>>>>>>           *To:* spr...@li...
>>>>>>>>>           <mailto:spr...@li...>
>>>>>>>>>           *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>>>>>>>           *Subject:* Re: [Springframework-developer] Please check
>>>>>>>>>           these two things
>>>>>>>>>
>>>>>>>>>           Actually, I have *not* replaced this with a == comparison
>>>>>>>>>           of the arrays: Instead, BatchSqlUpdate is storing clones
>>>>>>>>>           of the passed-in arrays now, for execution on flush. This
>>>>>>>>>           avoids any side effects in the first place (even if the
>>>>>>>>>           passed-in arrays are changed afterwards or reused for
>>>>>>>>>           multiple update inovcations), and the overhead of cloning
>>>>>>>>>           an array should be acceptable (after all, we're talking
>>>>>>>>>           about database update operations here).
>>>>>>>>>            Juergen
>>>>>>>>>
>>>>>>>>>               -----Original Message-----
>>>>>>>>>               *From:*
>>>>>>>>>               spr...@li...
>>>>>>>>>
>>>>>>>>>[mailto:spr...@li...]*On
>>>>>>>>>               Behalf Of *Martin Kersten
>>>>>>>>>               *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>>>>>>>               *To:* spr...@li...
>>>>>>>>>               *Subject:* Re: [Springframework-developer] Please
>>>>>>>>>               check these two things
>>>>>>>>>
>>>>>>>>>               But isn't this bogus thinking? I mean replacing
>>>>>>>>>               .equals with == makes
>>>>>>>>>               the implementation more strickt and reduces
>>>>>>>>>semantical
>>>>>>>>>               informations.
>>>>>>>>>               We are thinking about objects and there is no
>>>>>>>>>               performance gap
>>>>>>>>>               to justify this modification.
>>>>>>>>>                I wouldn't do it. I just would ensure that equals
>>>>>>>>>               implementations
>>>>>>>>>               start with if(this==object) return true;. How huge is
>>>>>>>>>               the estimated
>>>>>>>>>               performance gain?
>>>>>>>>>
>>>>>>>>>               Cheers,
>>>>>>>>>                Martin (Kersten)
>>>>>>>>>
>>>>>>>>>                   ----- Original Message -----
>>>>>>>>>                   *From:* Juergen Hoeller
>>>>>>>>>                   <mailto:ju...@in...>
>>>>>>>>>                   *To:*
>>>>>>>>>                   spr...@li...
>>>>>>>>>
>>>>>>>>><mailto:spr...@li...>
>>>>>>>>>
>>>>>>>>>                   *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>>>>>>>                   *Subject:* Re: [Springframework-developer] Please
>>>>>>>>>                   check these two things
>>>>>>>>>
>>>>>>>>>                   Well-spotted!
>>>>>>>>>                    ConcurrencyThrottleInterceptor should indeed use
>>>>>>>>>                   an internal monitor to avoid any potential for
>>>>>>>>>                   side effects. I doubt that this has caused any
>>>>>>>>>                   issue in practice, but it's nevertheless cleaner.
>>>>>>>>>                    That check in BatchSqlUpdate is not supposed to
>>>>>>>>>                   compare the elements but just the array
>>>>>>>>>reference:
>>>>>>>>>                   Repeated update invocations should not pass-in
>>>>>>>>>the
>>>>>>>>>                   same array instance repeatedly, with modified
>>>>>>>>>                   elements. Of course, a == check would be
>>>>>>>>>                   sufficient for this. I've reworked that part a
>>>>>>>>>bit
>>>>>>>>>                   differently, though: BatchSqlUpdate stores a
>>>>>>>>>clone
>>>>>>>>>                   of the passed-in array now, so there shouldn't be
>>>>>>>>>                   a need for such a check anymore.
>>>>>>>>>                    Juergen
>>>>>>>>>
>>>>>>>>>                       -----Original Message-----
>>>>>>>>>                       *From:*
>>>>>>>>>
>>>>>>>>>spr...@li...
>>>>>>>>>
>>>>>>>>>[mailto:spr...@li...]*On
>>>>>>>>>                       Behalf Of *Dave Brosius
>>>>>>>>>                       *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>>>>>>>                       *To:*
>>>>>>>>>
>>>>>>>>>spr...@li...
>>>>>>>>>                       *Subject:* [Springframework-developer] Please
>>>>>>>>>                       check these two things
>>>>>>>>>
>>>>>>>>>                       These may be problems, and then again maybe
>>>>>>>>>                       not. But they seem odd/wrong to me
>>>>>>>>>                        1) In
>>>>>>>>>
>>>>>>>>>org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>>>>>>                        in method invoke
>>>>>>>>>                        uses wait on 'this'
>>>>>>>>>                        In my mind you are exposing your
>>>>>>>>>                       synchronization strategies as a public
>>>>>>>>>                       artifact, which leaves this class open to
>>>>>>>>>                       failure due to client code.
>>>>>>>>>                       The client code may unwittingly us an
>>>>>>>>>instance
>>>>>>>>>                       of this class to do it's own synchronization,
>>>>>>>>>                       and totally screw up this class.
>>>>>>>>>                       I would recommend doing synchronizations
>>>>>>>>>                       (especially the use of wait/notify) on a
>>>>>>>>>                       private member so client code can not
>>>>>>>>>effect it.
>>>>>>>>>                        2) In
>>>>>>>>>
>>>>>>>>>org.springframework.jdbc.object.BatchSqlUpdate
>>>>>>>>>                        in method update, you do
>>>>>>>>>                        if (!this.parameterQueue.isEmpty() &&
>>>>>>>>>                       args.equals(this.parameterQueue.getLast())) {
>>>>>>>>>                        this is the same as using     args ==
>>>>>>>>>                       this.parameterQueue.getLast()
>>>>>>>>>                        or in other words, are these objects the
>>>>>>>>>same
>>>>>>>>>                       object. I assume you want to compare the
>>>>>>>>>                       elements of the array?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>>>>>-------------------------------------------------------
>>>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>>>users.
>>>>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>>_______________________________________________
>>>>>>>>Springframework-developer mailing list
>>>>>>>>Spr...@li...
>>>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>
>>>>>>>-------------------------------------------------------
>>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>>users.
>>>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>_______________________________________________
>>>>>>>Springframework-developer mailing list
>>>>>>>Spr...@li...
>>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>_______________________________________________
>>>>>>Springframework-developer mailing list
>>>>>>Spr...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>-------------------------------------------------------
>>>>>SF email is sponsored by - The IT Product Guide
>>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>>Discover which products truly live up to the hype. Start reading now.
>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>_______________________________________________
>>>>>Springframework-developer mailing list
>>>>>Spr...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>-------------------------------------------------------
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>_______________________________________________
>>>>Springframework-developer mailing list
>>>>Spr...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>      
>>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Steven D. <ste...@gm...>]

I know. The point is although there are different jars the
distribution doesn't help users in detemining which jar has which
dependency. Changing you Spring config can suddenly enable the CGLIB
requirement without notification.


On Tue, 22 Feb 2005 16:08:10 +0000, Rob Harrop <ro...@ca...> wrote:
> Only if you use class proxies. If you stick to JDK proxies you can leave
> CGLIB out.
> 
> Rob
> 
> Steven Devijver wrote:
> 
> >cglib?
> >
> >
> >On Tue, 22 Feb 2005 15:56:04 +0000, Rob Harrop <ro...@ca...> wrote:
> >
> >
> >>Just spring-aop.jar plus the aopalliance.jar. You will need
> >>spring-core.jar if you want to use a BeanFactory.
> >>
> >>Rob
> >>
> >>Steven Devijver wrote:
> >>
> >>
> >>
> >>>And what jars do I require to use the aop part, for example?
> >>>
> >>>
> >>>On Tue, 22 Feb 2005 15:20:55 +0000, Rob Harrop <ro...@ca...> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Its already split up as core, web, mvc, jdbc, orm and aop.
> >>>>
> >>>>Rob
> >>>>
> >>>>Martin Kersten wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>The distribution comes with different JARs for different
> >>>>>>circumstances, but it might be nice to be able to download them
> >>>>>>separately as well.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>How does web fits the vision of the core framework? It's really an
> >>>>>issue. Would you also like to deliver the rich client platform
> >>>>>and it's dependency also within the framework?
> >>>>>
> >>>>>But downloading the required jars based on the case scenario
> >>>>>the user has would be a great improvement anyways. For my
> >>>>>current research I would like to had the option to get a
> >>>>>web free, jdbc free, jms free, mail free, orm free, remoting free,
> >>>>>transaction free Spring version.
> >>>>>
> >>>>>If I would be in charge I would split it up the following way:
> >>>>>
> >>>>>core, web, j2ee, persistence, later rpc.
> >>>>>
> >>>>>
> >>>>>Cheers,
> >>>>>
> >>>>>Martin (Kersten)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Rob
> >>>>>>
> >>>>>>Martin Kersten wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>My thoughts exactly :). We have enough dependencies already.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>You should break up your framework anyways.
> >>>>>>>
> >>>>>>>You are currently providing a 'Jack of all trades' API. A solution
> >>>>>>>for everything but nothing in particular.
> >>>>>>>
> >>>>>>>Don't get mad :-) Here is what I mean:
> >>>>>>>
> >>>>>>>Spring adapts services for many diffrent situations:
> >>>>>>>You having a web application, fine download the
> >>>>>>>    default spring framework,
> >>>>>>>You have a command line application, fine download
> >>>>>>>     the default spring framework
> >>>>>>>
> >>>>>>>If it's not in the framework, we dont support it.
> >>>>>>>
> >>>>>>>Thats what I mean. Download the framework and be happy.
> >>>>>>>
> >>>>>>>It's like java, download the SE and you have all the stuff those
> >>>>>>>folks think some (!) people might(!) wanna have.
> >>>>>>>
> >>>>>>>How about making a core framework and having extensions.
> >>>>>>>
> >>>>>>>So you go for a normal application, just download the core
> >>>>>>>framework. You want to go for a web application, download
> >>>>>>>the core framework and download the web extension.
> >>>>>>>
> >>>>>>>You know I am currently trying to get my visions into the RPC
> >>>>>>>sub project. And when you start to develop your own
> >>>>>>>rich client(!) guess what, you have code for setting up a web
> >>>>>>>application right out of the box!
> >>>>>>>
> >>>>>>>Imagen what a relieve it would be for all of you folks to speak
> >>>>>>>about extensions and the core project, manage the dependencies
> >>>>>>>for those individually. Imagen having more then one swing reference
> >>>>>>>documentation. One for the core, one for the web, one for RPC and
> >>>>>>>so on. Boy I would be lucky if I were you :-).
> >>>>>>>
> >>>>>>>
> >>>>>>>Martin (Kersten)
> >>>>>>>
> >>>>>>>PS: Just a hint! ;-)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Erwin Vervaet wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>I think the main reason to use the W3C DOM API directly is to
> >>>>>>>>>avoid the need for an extra dependency (e.g. JDOM) just to parse
> >>>>>>>>>the XML bean definitions. You end up with an "less than elegant"
> >>>>>>>>>implementation in DefaultXmlBeanDefinitionParser, but in this case
> >>>>>>>>>the benifits outweigh the costs.
> >>>>>>>>>Erwin Vervaet
> >>>>>>>>>erw...@er... <mailto:erw...@er...>
> >>>>>>>>>
> >>>>>>>>>   ----- Original Message -----
> >>>>>>>>>   *From:* Martin Kersten
> >>>>>>>>>   <mailto:Mar...@St...>
> >>>>>>>>>   *To:* spr...@li...
> >>>>>>>>>   <mailto:spr...@li...>
> >>>>>>>>>   *Sent:* Tuesday, February 22, 2005 1:21 PM
> >>>>>>>>>   *Subject:* [Springframework-developer] I don't like the
> >>>>>>>>>   DefaultXmlBeanDefinitionParser
> >>>>>>>>>
> >>>>>>>>>   Hi folks,
> >>>>>>>>>    I am currently trying to extend the framework by supporting
> >>>>>>>>>   contributions.
> >>>>>>>>>   Just to see how it feels.
> >>>>>>>>>    So I made some investigations in the sourcecode. I don't want to
> >>>>>>>>>   start a war
> >>>>>>>>>   about proper design rules, since I am a believer in 'Interface
> >>>>>>>>>   belongs to the
> >>>>>>>>>   client' stuff and you are appearently not, but this isn't the
> >>>>>>>>>   issue I want to
> >>>>>>>>>   talk about.
> >>>>>>>>>    Th implementation I hate most on first sight is the
> >>>>>>>>>   XMLBeanDefinitionParser. I know it does what it should but you
> >>>>>>>>>can
> >>>>>>>>>   read this:
> >>>>>>>>>    /**
> >>>>>>>>>     * Make the horrible DOM API slightly more bearable:
> >>>>>>>>>     * get the text value we know this element contains.
> >>>>>>>>>     */
> >>>>>>>>>    Well I would agree but it's a bit wired also. You think the DOM
> >>>>>>>>>   API is horrible
> >>>>>>>>>   and you are still using it? You know what it means to use a
> >>>>>>>>>   horrible API? You write a horrible implementation! And thats how
> >>>>>>>>>   it looks.
> >>>>>>>>>   It took me more then a gaze to catch the meaning of the parser
> >>>>>>>>>and
> >>>>>>>>>   I also
> >>>>>>>>>   got blown by the code duplication. Since I am in need to extend
> >>>>>>>>>   this class,
> >>>>>>>>>    So I would like to ask if I may refactor it and commit you a
> >>>>>>>>>patch
> >>>>>>>>>   (or maybe
> >>>>>>>>>   a complete reimplementation)?
> >>>>>>>>>    Cheers,
> >>>>>>>>>    Martin (Kersten)
> >>>>>>>>>    PS: By the way, how about 'Hidding 3rd party library behind
> >>>>>>>>>single
> >>>>>>>>>   interface?'
> >>>>>>>>>
> >>>>>>>>>       ----- Original Message -----
> >>>>>>>>>       *From:* Martin Kersten
> >>>>>>>>>       <mailto:Mar...@St...>
> >>>>>>>>>       *To:* spr...@li...
> >>>>>>>>>       <mailto:spr...@li...>
> >>>>>>>>>       *Sent:* Tuesday, February 22, 2005 12:46 PM
> >>>>>>>>>       *Subject:* Re: [Springframework-developer] Please check these
> >>>>>>>>>       two things
> >>>>>>>>>
> >>>>>>>>>       Sorry, thought the agreement goes with the callee. Ok :-)
> >>>>>>>>>sorry was a strange day for me, I guess.
> >>>>>>>>>        Thanks,
> >>>>>>>>>        Martin (Kersten)
> >>>>>>>>>       ----- Original Message -----
> >>>>>>>>>
> >>>>>>>>>           *From:* Juergen Hoeller <mailto:ju...@in...>
> >>>>>>>>>           *To:* spr...@li...
> >>>>>>>>>           <mailto:spr...@li...>
> >>>>>>>>>           *Sent:* Tuesday, February 22, 2005 12:13 PM
> >>>>>>>>>           *Subject:* Re: [Springframework-developer] Please check
> >>>>>>>>>           these two things
> >>>>>>>>>
> >>>>>>>>>           Actually, I have *not* replaced this with a == comparison
> >>>>>>>>>           of the arrays: Instead, BatchSqlUpdate is storing clones
> >>>>>>>>>           of the passed-in arrays now, for execution on flush. This
> >>>>>>>>>           avoids any side effects in the first place (even if the
> >>>>>>>>>           passed-in arrays are changed afterwards or reused for
> >>>>>>>>>           multiple update inovcations), and the overhead of cloning
> >>>>>>>>>           an array should be acceptable (after all, we're talking
> >>>>>>>>>           about database update operations here).
> >>>>>>>>>            Juergen
> >>>>>>>>>
> >>>>>>>>>               -----Original Message-----
> >>>>>>>>>               *From:*
> >>>>>>>>>               spr...@li...
> >>>>>>>>>
> >>>>>>>>>[mailto:spr...@li...]*On
> >>>>>>>>>               Behalf Of *Martin Kersten
> >>>>>>>>>               *Sent:* Tuesday, February 22, 2005 12:04 PM
> >>>>>>>>>               *To:* spr...@li...
> >>>>>>>>>               *Subject:* Re: [Springframework-developer] Please
> >>>>>>>>>               check these two things
> >>>>>>>>>
> >>>>>>>>>               But isn't this bogus thinking? I mean replacing
> >>>>>>>>>               .equals with == makes
> >>>>>>>>>               the implementation more strickt and reduces
> >>>>>>>>>semantical
> >>>>>>>>>               informations.
> >>>>>>>>>               We are thinking about objects and there is no
> >>>>>>>>>               performance gap
> >>>>>>>>>               to justify this modification.
> >>>>>>>>>                I wouldn't do it. I just would ensure that equals
> >>>>>>>>>               implementations
> >>>>>>>>>               start with if(this==object) return true;. How huge is
> >>>>>>>>>               the estimated
> >>>>>>>>>               performance gain?
> >>>>>>>>>
> >>>>>>>>>               Cheers,
> >>>>>>>>>                Martin (Kersten)
> >>>>>>>>>
> >>>>>>>>>                   ----- Original Message -----
> >>>>>>>>>                   *From:* Juergen Hoeller
> >>>>>>>>>                   <mailto:ju...@in...>
> >>>>>>>>>                   *To:*
> >>>>>>>>>                   spr...@li...
> >>>>>>>>>
> >>>>>>>>><mailto:spr...@li...>
> >>>>>>>>>
> >>>>>>>>>                   *Sent:* Tuesday, February 22, 2005 10:06 AM
> >>>>>>>>>                   *Subject:* Re: [Springframework-developer] Please
> >>>>>>>>>                   check these two things
> >>>>>>>>>
> >>>>>>>>>                   Well-spotted!
> >>>>>>>>>                    ConcurrencyThrottleInterceptor should indeed use
> >>>>>>>>>                   an internal monitor to avoid any potential for
> >>>>>>>>>                   side effects. I doubt that this has caused any
> >>>>>>>>>                   issue in practice, but it's nevertheless cleaner.
> >>>>>>>>>                    That check in BatchSqlUpdate is not supposed to
> >>>>>>>>>                   compare the elements but just the array
> >>>>>>>>>reference:
> >>>>>>>>>                   Repeated update invocations should not pass-in
> >>>>>>>>>the
> >>>>>>>>>                   same array instance repeatedly, with modified
> >>>>>>>>>                   elements. Of course, a == check would be
> >>>>>>>>>                   sufficient for this. I've reworked that part a
> >>>>>>>>>bit
> >>>>>>>>>                   differently, though: BatchSqlUpdate stores a
> >>>>>>>>>clone
> >>>>>>>>>                   of the passed-in array now, so there shouldn't be
> >>>>>>>>>                   a need for such a check anymore.
> >>>>>>>>>                    Juergen
> >>>>>>>>>
> >>>>>>>>>                       -----Original Message-----
> >>>>>>>>>                       *From:*
> >>>>>>>>>
> >>>>>>>>>spr...@li...
> >>>>>>>>>
> >>>>>>>>>[mailto:spr...@li...]*On
> >>>>>>>>>                       Behalf Of *Dave Brosius
> >>>>>>>>>                       *Sent:* Tuesday, February 22, 2005 8:08 AM
> >>>>>>>>>                       *To:*
> >>>>>>>>>
> >>>>>>>>>spr...@li...
> >>>>>>>>>                       *Subject:* [Springframework-developer] Please
> >>>>>>>>>                       check these two things
> >>>>>>>>>
> >>>>>>>>>                       These may be problems, and then again maybe
> >>>>>>>>>                       not. But they seem odd/wrong to me
> >>>>>>>>>                        1) In
> >>>>>>>>>
> >>>>>>>>>org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
> >>>>>>>>>                        in method invoke
> >>>>>>>>>                        uses wait on 'this'
> >>>>>>>>>                        In my mind you are exposing your
> >>>>>>>>>                       synchronization strategies as a public
> >>>>>>>>>                       artifact, which leaves this class open to
> >>>>>>>>>                       failure due to client code.
> >>>>>>>>>                       The client code may unwittingly us an
> >>>>>>>>>instance
> >>>>>>>>>                       of this class to do it's own synchronization,
> >>>>>>>>>                       and totally screw up this class.
> >>>>>>>>>                       I would recommend doing synchronizations
> >>>>>>>>>                       (especially the use of wait/notify) on a
> >>>>>>>>>                       private member so client code can not
> >>>>>>>>>effect it.
> >>>>>>>>>                        2) In
> >>>>>>>>>
> >>>>>>>>>org.springframework.jdbc.object.BatchSqlUpdate
> >>>>>>>>>                        in method update, you do
> >>>>>>>>>                        if (!this.parameterQueue.isEmpty() &&
> >>>>>>>>>                       args.equals(this.parameterQueue.getLast())) {
> >>>>>>>>>                        this is the same as using     args ==
> >>>>>>>>>                       this.parameterQueue.getLast()
> >>>>>>>>>                        or in other words, are these objects the
> >>>>>>>>>same
> >>>>>>>>>                       object. I assume you want to compare the
> >>>>>>>>>                       elements of the array?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>-------------------------------------------------------
> >>>>>>>>SF email is sponsored by - The IT Product Guide
> >>>>>>>>Read honest & candid reviews on hundreds of IT Products from real
> >>>>>>>>users.
> >>>>>>>>Discover which products truly live up to the hype. Start reading now.
> >>>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>>>>>_______________________________________________
> >>>>>>>>Springframework-developer mailing list
> >>>>>>>>Spr...@li...
> >>>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>-------------------------------------------------------
> >>>>>>>SF email is sponsored by - The IT Product Guide
> >>>>>>>Read honest & candid reviews on hundreds of IT Products from real
> >>>>>>>users.
> >>>>>>>Discover which products truly live up to the hype. Start reading now.
> >>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>>>>_______________________________________________
> >>>>>>>Springframework-developer mailing list
> >>>>>>>Spr...@li...
> >>>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>-------------------------------------------------------
> >>>>>>SF email is sponsored by - The IT Product Guide
> >>>>>>Read honest & candid reviews on hundreds of IT Products from real users.
> >>>>>>Discover which products truly live up to the hype. Start reading now.
> >>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>>>_______________________________________________
> >>>>>>Springframework-developer mailing list
> >>>>>>Spr...@li...
> >>>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>-------------------------------------------------------
> >>>>>SF email is sponsored by - The IT Product Guide
> >>>>>Read honest & candid reviews on hundreds of IT Products from real users.
> >>>>>Discover which products truly live up to the hype. Start reading now.
> >>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>>_______________________________________________
> >>>>>Springframework-developer mailing list
> >>>>>Spr...@li...
> >>>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>-------------------------------------------------------
> >>>>SF email is sponsored by - The IT Product Guide
> >>>>Read honest & candid reviews on hundreds of IT Products from real users.
> >>>>Discover which products truly live up to the hype. Start reading now.
> >>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>>_______________________________________________
> >>>>Springframework-developer mailing list
> >>>>Spr...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>-------------------------------------------------------
> >>>SF email is sponsored by - The IT Product Guide
> >>>Read honest & candid reviews on hundreds of IT Products from real users.
> >>>Discover which products truly live up to the hype. Start reading now.
> >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>>_______________________________________________
> >>>Springframework-developer mailing list
> >>>Spr...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>-------------------------------------------------------
> >>SF email is sponsored by - The IT Product Guide
> >>Read honest & candid reviews on hundreds of IT Products from real users.
> >>Discover which products truly live up to the hype. Start reading now.
> >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >
> >
> >-------------------------------------------------------
> >SF email is sponsored by - The IT Product Guide
> >Read honest & candid reviews on hundreds of IT Products from real users.
> >Discover which products truly live up to the hype. Start reading now.
> >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
>

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

> And what jars do I require to use the aop part, for example?

In another post I did a quick user group analysation and I noticed
that AOP seams to be general user related stuff and should
move to the core package. Like context should.

I would slice your package structur this way:

CoreProject:
  core, core.aop, core.context
WebProject
  web
ORM
  orm
...

Also I would love to see Spring being applied to
the 'Interface belongs to the client' design principle. :-)

But this is another story. Maybe I should move some
interfaces around to show you. But packaging is an
issue for Spring 2.x. So we can delay this discussion.

Maybe I can talk Keth into this :-).


Cheers,

Martin

>> Its already split up as core, web, mvc, jdbc, orm and aop.
>>
>> Rob
>>
>> Martin Kersten wrote:
>>
>> >> The distribution comes with different JARs for different
>> >> circumstances, but it might be nice to be able to download them
>> >> separately as well.
>> >
>> >
>> > How does web fits the vision of the core framework? It's really an
>> > issue. Would you also like to deliver the rich client platform
>> > and it's dependency also within the framework?
>> >
>> > But downloading the required jars based on the case scenario
>> > the user has would be a great improvement anyways. For my
>> > current research I would like to had the option to get a
>> > web free, jdbc free, jms free, mail free, orm free, remoting free,
>> > transaction free Spring version.
>> >
>> > If I would be in charge I would split it up the following way:
>> >
>> > core, web, j2ee, persistence, later rpc.
>> >
>> >
>> > Cheers,
>> >
>> > Martin (Kersten)
>> >
>> >
>> >>
>> >> Rob
>> >>
>> >> Martin Kersten wrote:
>> >>
>> >>>> My thoughts exactly :). We have enough dependencies already.
>> >>>
>> >>>
>> >>>
>> >>> You should break up your framework anyways.
>> >>>
>> >>> You are currently providing a 'Jack of all trades' API. A solution
>> >>> for everything but nothing in particular.
>> >>>
>> >>> Don't get mad :-) Here is what I mean:
>> >>>
>> >>> Spring adapts services for many diffrent situations:
>> >>>  You having a web application, fine download the
>> >>>      default spring framework,
>> >>>  You have a command line application, fine download
>> >>>       the default spring framework
>> >>>
>> >>>  If it's not in the framework, we dont support it.
>> >>>
>> >>> Thats what I mean. Download the framework and be happy.
>> >>>
>> >>> It's like java, download the SE and you have all the stuff those
>> >>> folks think some (!) people might(!) wanna have.
>> >>>
>> >>> How about making a core framework and having extensions.
>> >>>
>> >>> So you go for a normal application, just download the core
>> >>> framework. You want to go for a web application, download
>> >>> the core framework and download the web extension.
>> >>>
>> >>> You know I am currently trying to get my visions into the RPC
>> >>> sub project. And when you start to develop your own
>> >>> rich client(!) guess what, you have code for setting up a web
>> >>> application right out of the box!
>> >>>
>> >>> Imagen what a relieve it would be for all of you folks to speak
>> >>> about extensions and the core project, manage the dependencies
>> >>> for those individually. Imagen having more then one swing reference
>> >>> documentation. One for the core, one for the web, one for RPC and
>> >>> so on. Boy I would be lucky if I were you :-).
>> >>>
>> >>>
>> >>> Martin (Kersten)
>> >>>
>> >>> PS: Just a hint! ;-)
>> >>>
>> >>>> Erwin Vervaet wrote:
>> >>>>
>> >>>>> I think the main reason to use the W3C DOM API directly is to
>> >>>>> avoid the need for an extra dependency (e.g. JDOM) just to parse
>> >>>>> the XML bean definitions. You end up with an "less than elegant"
>> >>>>> implementation in DefaultXmlBeanDefinitionParser, but in this case
>> >>>>> the benifits outweigh the costs.
>> >>>>>  Erwin Vervaet
>> >>>>> erw...@er... <mailto:erw...@er...>
>> >>>>>
>> >>>>>     ----- Original Message -----
>> >>>>>     *From:* Martin Kersten
>> >>>>>     <mailto:Mar...@St...>
>> >>>>>     *To:* spr...@li...
>> >>>>>     <mailto:spr...@li...>
>> >>>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>> >>>>>     *Subject:* [Springframework-developer] I don't like the
>> >>>>>     DefaultXmlBeanDefinitionParser
>> >>>>>
>> >>>>>     Hi folks,
>> >>>>>      I am currently trying to extend the framework by supporting
>> >>>>>     contributions.
>> >>>>>     Just to see how it feels.
>> >>>>>      So I made some investigations in the sourcecode. I don't want 
>> >>>>> to
>> >>>>>     start a war
>> >>>>>     about proper design rules, since I am a believer in 'Interface
>> >>>>>     belongs to the
>> >>>>>     client' stuff and you are appearently not, but this isn't the
>> >>>>>     issue I want to
>> >>>>>     talk about.
>> >>>>>      Th implementation I hate most on first sight is the
>> >>>>>     XMLBeanDefinitionParser. I know it does what it should but you
>> >>>>> can
>> >>>>>     read this:
>> >>>>>      /**
>> >>>>>       * Make the horrible DOM API slightly more bearable:
>> >>>>>       * get the text value we know this element contains.
>> >>>>>       */
>> >>>>>      Well I would agree but it's a bit wired also. You think the 
>> >>>>> DOM
>> >>>>>     API is horrible
>> >>>>>     and you are still using it? You know what it means to use a
>> >>>>>     horrible API? You write a horrible implementation! And thats 
>> >>>>> how
>> >>>>>     it looks.
>> >>>>>     It took me more then a gaze to catch the meaning of the parser
>> >>>>> and
>> >>>>>     I also
>> >>>>>     got blown by the code duplication. Since I am in need to extend
>> >>>>>     this class,
>> >>>>>      So I would like to ask if I may refactor it and commit you a
>> >>>>> patch
>> >>>>>     (or maybe
>> >>>>>     a complete reimplementation)?
>> >>>>>      Cheers,
>> >>>>>      Martin (Kersten)
>> >>>>>      PS: By the way, how about 'Hidding 3rd party library behind
>> >>>>> single
>> >>>>>     interface?'
>> >>>>>
>> >>>>>         ----- Original Message -----
>> >>>>>         *From:* Martin Kersten
>> >>>>>         <mailto:Mar...@St...>
>> >>>>>         *To:* spr...@li...
>> >>>>>         <mailto:spr...@li...>
>> >>>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>> >>>>>         *Subject:* Re: [Springframework-developer] Please check 
>> >>>>> these
>> >>>>>         two things
>> >>>>>
>> >>>>>         Sorry, thought the agreement goes with the callee. Ok :-)
>> >>>>> sorry was a strange day for me, I guess.
>> >>>>>          Thanks,
>> >>>>>          Martin (Kersten)
>> >>>>>         ----- Original Message -----
>> >>>>>
>> >>>>>             *From:* Juergen Hoeller 
>> >>>>> <mailto:ju...@in...>
>> >>>>>             *To:* spr...@li...
>> >>>>> 
>> >>>>> <mailto:spr...@li...>
>> >>>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>> >>>>>             *Subject:* Re: [Springframework-developer] Please check
>> >>>>>             these two things
>> >>>>>
>> >>>>>             Actually, I have *not* replaced this with a == 
>> >>>>> comparison
>> >>>>>             of the arrays: Instead, BatchSqlUpdate is storing 
>> >>>>> clones
>> >>>>>             of the passed-in arrays now, for execution on flush. 
>> >>>>> This
>> >>>>>             avoids any side effects in the first place (even if the
>> >>>>>             passed-in arrays are changed afterwards or reused for
>> >>>>>             multiple update inovcations), and the overhead of 
>> >>>>> cloning
>> >>>>>             an array should be acceptable (after all, we're talking
>> >>>>>             about database update operations here).
>> >>>>>              Juergen
>> >>>>>
>> >>>>>                 -----Original Message-----
>> >>>>>                 *From:*
>> >>>>> 
>> >>>>> spr...@li...
>> >>>>>
>> >>>>> [mailto:spr...@li...]*On
>> >>>>>                 Behalf Of *Martin Kersten
>> >>>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>> >>>>>                 *To:* 
>> >>>>> spr...@li...
>> >>>>>                 *Subject:* Re: [Springframework-developer] Please
>> >>>>>                 check these two things
>> >>>>>
>> >>>>>                 But isn't this bogus thinking? I mean replacing
>> >>>>>                 .equals with == makes
>> >>>>>                 the implementation more strickt and reduces
>> >>>>> semantical
>> >>>>>                 informations.
>> >>>>>                 We are thinking about objects and there is no
>> >>>>>                 performance gap
>> >>>>>                 to justify this modification.
>> >>>>>                  I wouldn't do it. I just would ensure that equals
>> >>>>>                 implementations
>> >>>>>                 start with if(this==object) return true;. How huge 
>> >>>>> is
>> >>>>>                 the estimated
>> >>>>>                 performance gain?
>> >>>>>
>> >>>>>                 Cheers,
>> >>>>>                  Martin (Kersten)
>> >>>>>
>> >>>>>                     ----- Original Message -----
>> >>>>>                     *From:* Juergen Hoeller
>> >>>>>                     <mailto:ju...@in...>
>> >>>>>                     *To:*
>> >>>>>                     spr...@li...
>> >>>>>
>> >>>>> <mailto:spr...@li...>
>> >>>>>
>> >>>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>> >>>>>                     *Subject:* Re: [Springframework-developer] 
>> >>>>> Please
>> >>>>>                     check these two things
>> >>>>>
>> >>>>>                     Well-spotted!
>> >>>>>                      ConcurrencyThrottleInterceptor should indeed 
>> >>>>> use
>> >>>>>                     an internal monitor to avoid any potential for
>> >>>>>                     side effects. I doubt that this has caused any
>> >>>>>                     issue in practice, but it's nevertheless 
>> >>>>> cleaner.
>> >>>>>                      That check in BatchSqlUpdate is not supposed 
>> >>>>> to
>> >>>>>                     compare the elements but just the array
>> >>>>> reference:
>> >>>>>                     Repeated update invocations should not pass-in
>> >>>>> the
>> >>>>>                     same array instance repeatedly, with modified
>> >>>>>                     elements. Of course, a == check would be
>> >>>>>                     sufficient for this. I've reworked that part a
>> >>>>> bit
>> >>>>>                     differently, though: BatchSqlUpdate stores a
>> >>>>> clone
>> >>>>>                     of the passed-in array now, so there shouldn't 
>> >>>>> be
>> >>>>>                     a need for such a check anymore.
>> >>>>>                      Juergen
>> >>>>>
>> >>>>>                         -----Original Message-----
>> >>>>>                         *From:*
>> >>>>>
>> >>>>> spr...@li...
>> >>>>>
>> >>>>> [mailto:spr...@li...]*On
>> >>>>>                         Behalf Of *Dave Brosius
>> >>>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>> >>>>>                         *To:*
>> >>>>>
>> >>>>> spr...@li...
>> >>>>>                         *Subject:* [Springframework-developer] 
>> >>>>> Please
>> >>>>>                         check these two things
>> >>>>>
>> >>>>>                         These may be problems, and then again maybe
>> >>>>>                         not. But they seem odd/wrong to me
>> >>>>>                          1) In
>> >>>>>
>> >>>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>> >>>>>                          in method invoke
>> >>>>>                          uses wait on 'this'
>> >>>>>                          In my mind you are exposing your
>> >>>>>                         synchronization strategies as a public
>> >>>>>                         artifact, which leaves this class open to
>> >>>>>                         failure due to client code.
>> >>>>>                         The client code may unwittingly us an
>> >>>>> instance
>> >>>>>                         of this class to do it's own 
>> >>>>> synchronization,
>> >>>>>                         and totally screw up this class.
>> >>>>>                         I would recommend doing synchronizations
>> >>>>>                         (especially the use of wait/notify) on a
>> >>>>>                         private member so client code can not
>> >>>>> effect it.
>> >>>>>                          2) In
>> >>>>>
>> >>>>> org.springframework.jdbc.object.BatchSqlUpdate
>> >>>>>                          in method update, you do
>> >>>>>                          if (!this.parameterQueue.isEmpty() &&
>> >>>>>                         args.equals(this.parameterQueue.getLast())) 
>> >>>>> {
>> >>>>>                          this is the same as using     args ==
>> >>>>>                         this.parameterQueue.getLast()
>> >>>>>                          or in other words, are these objects the
>> >>>>> same
>> >>>>>                         object. I assume you want to compare the
>> >>>>>                         elements of the array?
>> >>>>>
>> >>>>
>> >>>>
>> >>>> -------------------------------------------------------
>> >>>> SF email is sponsored by - The IT Product Guide
>> >>>> Read honest & candid reviews on hundreds of IT Products from real
>> >>>> users.
>> >>>> Discover which products truly live up to the hype. Start reading 
>> >>>> now.
>> >>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> >>>> _______________________________________________
>> >>>> Springframework-developer mailing list
>> >>>> Spr...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> -------------------------------------------------------
>> >>> SF email is sponsored by - The IT Product Guide
>> >>> Read honest & candid reviews on hundreds of IT Products from real
>> >>> users.
>> >>> Discover which products truly live up to the hype. Start reading now.
>> >>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> >>> _______________________________________________
>> >>> Springframework-developer mailing list
>> >>> Spr...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> >>>
>> >>>
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> SF email is sponsored by - The IT Product Guide
>> >> Read honest & candid reviews on hundreds of IT Products from real 
>> >> users.
>> >> Discover which products truly live up to the hype. Start reading now.
>> >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> >> _______________________________________________
>> >> Springframework-developer mailing list
>> >> Spr...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> >
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > SF email is sponsored by - The IT Product Guide
>> > Read honest & candid reviews on hundreds of IT Products from real 
>> > users.
>> > Discover which products truly live up to the hype. Start reading now.
>> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> > _______________________________________________
>> > Springframework-developer mailing list
>> > Spr...@li...
>> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
>> >
>> >
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Martin K. <Mar...@St...>]

> Its already split up as core, web, mvc, jdbc, orm and aop.

But not by the project statement. I argue that the project
statement (or the project mission of each project) is not
focused. Web is unrelated to jdbc, so why should the core
care?

It is a design issue, so we should stop arguing.

But! ;-)

Who is the client of core? General user.
Who is the client of web? Web developer.
Who is the client of JDBC+ORM? DB dealing general user.
Who is the client of AOP? General user.
      (aop seams to be core stuff -> core.aop)
Who is the client of Spring RPC? GUI client developer.

You see what I mean. Diffrent user groups diffrent API.
A general one and a bunch of special API for the special people.
And that should be reflected by deviding the project in a main project
and sub projects. Other sub-project other target audience,
other sub project mission statement, other focus of the developer.
Also seperation of dependencies,
also easy to communicate to the Spring user.


Cheers,

Martin (Kersten)

>>> The distribution comes with different JARs for different circumstances, 
>>> but it might be nice to be able to download them separately as well.
>>
>>
>> How does web fits the vision of the core framework? It's really an
>> issue. Would you also like to deliver the rich client platform
>> and it's dependency also within the framework?
>>
>> But downloading the required jars based on the case scenario
>> the user has would be a great improvement anyways. For my
>> current research I would like to had the option to get a
>> web free, jdbc free, jms free, mail free, orm free, remoting free,
>> transaction free Spring version.
>>
>> If I would be in charge I would split it up the following way:
>>
>> core, web, j2ee, persistence, later rpc.
>>
>>
>> Cheers,
>>
>> Martin (Kersten)
>>
>>
>>>
>>> Rob
>>>
>>> Martin Kersten wrote:
>>>
>>>>> My thoughts exactly :). We have enough dependencies already.
>>>>
>>>>
>>>>
>>>> You should break up your framework anyways.
>>>>
>>>> You are currently providing a 'Jack of all trades' API. A solution
>>>> for everything but nothing in particular.
>>>>
>>>> Don't get mad :-) Here is what I mean:
>>>>
>>>> Spring adapts services for many diffrent situations:
>>>>  You having a web application, fine download the
>>>>      default spring framework,
>>>>  You have a command line application, fine download
>>>>       the default spring framework
>>>>
>>>>  If it's not in the framework, we dont support it.
>>>>
>>>> Thats what I mean. Download the framework and be happy.
>>>>
>>>> It's like java, download the SE and you have all the stuff those
>>>> folks think some (!) people might(!) wanna have.
>>>>
>>>> How about making a core framework and having extensions.
>>>>
>>>> So you go for a normal application, just download the core
>>>> framework. You want to go for a web application, download
>>>> the core framework and download the web extension.
>>>>
>>>> You know I am currently trying to get my visions into the RPC
>>>> sub project. And when you start to develop your own
>>>> rich client(!) guess what, you have code for setting up a web
>>>> application right out of the box!
>>>>
>>>> Imagen what a relieve it would be for all of you folks to speak
>>>> about extensions and the core project, manage the dependencies
>>>> for those individually. Imagen having more then one swing reference
>>>> documentation. One for the core, one for the web, one for RPC and
>>>> so on. Boy I would be lucky if I were you :-).
>>>>
>>>>
>>>> Martin (Kersten)
>>>>
>>>> PS: Just a hint! ;-)
>>>>
>>>>> Erwin Vervaet wrote:
>>>>>
>>>>>> I think the main reason to use the W3C DOM API directly is to avoid 
>>>>>> the need for an extra dependency (e.g. JDOM) just to parse the XML 
>>>>>> bean definitions. You end up with an "less than elegant" 
>>>>>> implementation in DefaultXmlBeanDefinitionParser, but in this case 
>>>>>> the benifits outweigh the costs.
>>>>>>  Erwin Vervaet
>>>>>> erw...@er... <mailto:erw...@er...>
>>>>>>
>>>>>>     ----- Original Message -----
>>>>>>     *From:* Martin Kersten
>>>>>>     <mailto:Mar...@St...>
>>>>>>     *To:* spr...@li...
>>>>>>     <mailto:spr...@li...>
>>>>>>     *Sent:* Tuesday, February 22, 2005 1:21 PM
>>>>>>     *Subject:* [Springframework-developer] I don't like the
>>>>>>     DefaultXmlBeanDefinitionParser
>>>>>>
>>>>>>     Hi folks,
>>>>>>      I am currently trying to extend the framework by supporting
>>>>>>     contributions.
>>>>>>     Just to see how it feels.
>>>>>>      So I made some investigations in the sourcecode. I don't want to
>>>>>>     start a war
>>>>>>     about proper design rules, since I am a believer in 'Interface
>>>>>>     belongs to the
>>>>>>     client' stuff and you are appearently not, but this isn't the
>>>>>>     issue I want to
>>>>>>     talk about.
>>>>>>      Th implementation I hate most on first sight is the
>>>>>>     XMLBeanDefinitionParser. I know it does what it should but you 
>>>>>> can
>>>>>>     read this:
>>>>>>      /**
>>>>>>       * Make the horrible DOM API slightly more bearable:
>>>>>>       * get the text value we know this element contains.
>>>>>>       */
>>>>>>      Well I would agree but it's a bit wired also. You think the DOM
>>>>>>     API is horrible
>>>>>>     and you are still using it? You know what it means to use a
>>>>>>     horrible API? You write a horrible implementation! And thats how
>>>>>>     it looks.
>>>>>>     It took me more then a gaze to catch the meaning of the parser 
>>>>>> and
>>>>>>     I also
>>>>>>     got blown by the code duplication. Since I am in need to extend
>>>>>>     this class,
>>>>>>      So I would like to ask if I may refactor it and commit you a 
>>>>>> patch
>>>>>>     (or maybe
>>>>>>     a complete reimplementation)?
>>>>>>      Cheers,
>>>>>>      Martin (Kersten)
>>>>>>      PS: By the way, how about 'Hidding 3rd party library behind 
>>>>>> single
>>>>>>     interface?'
>>>>>>
>>>>>>         ----- Original Message -----
>>>>>>         *From:* Martin Kersten
>>>>>>         <mailto:Mar...@St...>
>>>>>>         *To:* spr...@li...
>>>>>>         <mailto:spr...@li...>
>>>>>>         *Sent:* Tuesday, February 22, 2005 12:46 PM
>>>>>>         *Subject:* Re: [Springframework-developer] Please check these
>>>>>>         two things
>>>>>>
>>>>>>         Sorry, thought the agreement goes with the callee. Ok :-) 
>>>>>> sorry was a strange day for me, I guess.
>>>>>>          Thanks,
>>>>>>          Martin (Kersten)
>>>>>>         ----- Original Message -----
>>>>>>
>>>>>>             *From:* Juergen Hoeller <mailto:ju...@in...>
>>>>>>             *To:* spr...@li...
>>>>>>             <mailto:spr...@li...>
>>>>>>             *Sent:* Tuesday, February 22, 2005 12:13 PM
>>>>>>             *Subject:* Re: [Springframework-developer] Please check
>>>>>>             these two things
>>>>>>
>>>>>>             Actually, I have *not* replaced this with a == comparison
>>>>>>             of the arrays: Instead, BatchSqlUpdate is storing clones
>>>>>>             of the passed-in arrays now, for execution on flush. This
>>>>>>             avoids any side effects in the first place (even if the
>>>>>>             passed-in arrays are changed afterwards or reused for
>>>>>>             multiple update inovcations), and the overhead of cloning
>>>>>>             an array should be acceptable (after all, we're talking
>>>>>>             about database update operations here).
>>>>>>              Juergen
>>>>>>
>>>>>>                 -----Original Message-----
>>>>>>                 *From:*
>>>>>>                 spr...@li...
>>>>>>
>>>>>> [mailto:spr...@li...]*On
>>>>>>                 Behalf Of *Martin Kersten
>>>>>>                 *Sent:* Tuesday, February 22, 2005 12:04 PM
>>>>>>                 *To:* spr...@li...
>>>>>>                 *Subject:* Re: [Springframework-developer] Please
>>>>>>                 check these two things
>>>>>>
>>>>>>                 But isn't this bogus thinking? I mean replacing
>>>>>>                 .equals with == makes
>>>>>>                 the implementation more strickt and reduces 
>>>>>> semantical
>>>>>>                 informations.
>>>>>>                 We are thinking about objects and there is no
>>>>>>                 performance gap
>>>>>>                 to justify this modification.
>>>>>>                  I wouldn't do it. I just would ensure that equals
>>>>>>                 implementations
>>>>>>                 start with if(this==object) return true;. How huge is
>>>>>>                 the estimated
>>>>>>                 performance gain?
>>>>>>
>>>>>>                 Cheers,
>>>>>>                  Martin (Kersten)
>>>>>>
>>>>>>                     ----- Original Message -----
>>>>>>                     *From:* Juergen Hoeller
>>>>>>                     <mailto:ju...@in...>
>>>>>>                     *To:*
>>>>>>                     spr...@li...
>>>>>>
>>>>>> <mailto:spr...@li...>
>>>>>>
>>>>>>                     *Sent:* Tuesday, February 22, 2005 10:06 AM
>>>>>>                     *Subject:* Re: [Springframework-developer] Please
>>>>>>                     check these two things
>>>>>>
>>>>>>                     Well-spotted!
>>>>>>                      ConcurrencyThrottleInterceptor should indeed use
>>>>>>                     an internal monitor to avoid any potential for
>>>>>>                     side effects. I doubt that this has caused any
>>>>>>                     issue in practice, but it's nevertheless cleaner.
>>>>>>                      That check in BatchSqlUpdate is not supposed to
>>>>>>                     compare the elements but just the array 
>>>>>> reference:
>>>>>>                     Repeated update invocations should not pass-in 
>>>>>> the
>>>>>>                     same array instance repeatedly, with modified
>>>>>>                     elements. Of course, a == check would be
>>>>>>                     sufficient for this. I've reworked that part a 
>>>>>> bit
>>>>>>                     differently, though: BatchSqlUpdate stores a 
>>>>>> clone
>>>>>>                     of the passed-in array now, so there shouldn't be
>>>>>>                     a need for such a check anymore.
>>>>>>                      Juergen
>>>>>>
>>>>>>                         -----Original Message-----
>>>>>>                         *From:*
>>>>>>
>>>>>> spr...@li...
>>>>>>
>>>>>> [mailto:spr...@li...]*On
>>>>>>                         Behalf Of *Dave Brosius
>>>>>>                         *Sent:* Tuesday, February 22, 2005 8:08 AM
>>>>>>                         *To:*
>>>>>> 
>>>>>> spr...@li...
>>>>>>                         *Subject:* [Springframework-developer] Please
>>>>>>                         check these two things
>>>>>>
>>>>>>                         These may be problems, and then again maybe
>>>>>>                         not. But they seem odd/wrong to me
>>>>>>                          1) In
>>>>>>
>>>>>> org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>>>                          in method invoke
>>>>>>                          uses wait on 'this'
>>>>>>                          In my mind you are exposing your
>>>>>>                         synchronization strategies as a public
>>>>>>                         artifact, which leaves this class open to
>>>>>>                         failure due to client code.
>>>>>>                         The client code may unwittingly us an 
>>>>>> instance
>>>>>>                         of this class to do it's own synchronization,
>>>>>>                         and totally screw up this class.
>>>>>>                         I would recommend doing synchronizations
>>>>>>                         (especially the use of wait/notify) on a
>>>>>>                         private member so client code can not effect 
>>>>>> it.
>>>>>>                          2) In
>>>>>> 
>>>>>> org.springframework.jdbc.object.BatchSqlUpdate
>>>>>>                          in method update, you do
>>>>>>                          if (!this.parameterQueue.isEmpty() &&
>>>>>>                         args.equals(this.parameterQueue.getLast())) {
>>>>>>                          this is the same as using     args ==
>>>>>>                         this.parameterQueue.getLast()
>>>>>>                          or in other words, are these objects the 
>>>>>> same
>>>>>>                         object. I assume you want to compare the
>>>>>>                         elements of the array?
>>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> SF email is sponsored by - The IT Product Guide
>>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>>> users.
>>>>> Discover which products truly live up to the hype. Start reading now.
>>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>> _______________________________________________
>>>>> Springframework-developer mailing list
>>>>> Spr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> SF email is sponsored by - The IT Product Guide
>>>> Read honest & candid reviews on hundreds of IT Products from real 
>>>> users.
>>>> Discover which products truly live up to the hype. Start reading now.
>>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>> _______________________________________________
>>>> Springframework-developer mailing list
>>>> Spr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>>
>>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF email is sponsored by - The IT Product Guide
>>> Read honest & candid reviews on hundreds of IT Products from real users.
>>> Discover which products truly live up to the hype. Start reading now.
>>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer 

Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser

[Juergen H. <ju...@in...>]

Still having a strange day? ;-)

I'm not sure what you mean with "interface belongs to the client", BTW:
Spring uses interfaces at all levels, both for client APIs and for internal
strategies. That seems perfectly feasible to me.

Anyway, regarding DefaultXmlBeanDefinitionParser's implementation, in
particular the use of the DOM API: As Erwin correctly assumed, the main
reason is simply that DOM is part of the JDK. A special XML parser with a
nicer API (like JDOM or DOM4J) would introduce a new required dependency -
even when not using XML bean definitions directly (for example, JdbcTemplate
uses a default SQLErrorCodesFactory that reads internal XML bean definitions
from sql-error-codes.xml).

Admittedly, DefaultXmlBeanDefinitionParser has not really been designed for
extensibility; there is certainly potential for making it more convenient to
subclass. However, I strongly object to introducing a third-party XML
parsing API: the library dependencies of Spring's core have to remain
minimal. This only leaves DOM and SAX, as included in the JDK.

Juergen


  -----Original Message-----
  From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Martin Kersten
  Sent: Tuesday, February 22, 2005 1:22 PM
  To: spr...@li...
  Subject: [Springframework-developer] I don't like the
DefaultXmlBeanDefinitionParser


  Hi folks,

     I am currently trying to extend the framework by supporting
contributions.
  Just to see how it feels.

  So I made some investigations in the sourcecode. I don't want to start a
war
  about proper design rules, since I am a believer in 'Interface belongs to
the
  client' stuff and you are appearently not, but this isn't the issue I want
to
  talk about.

  Th implementation I hate most on first sight is the
  XMLBeanDefinitionParser. I know it does what it should but you can read
this:

   /**
    * Make the horrible DOM API slightly more bearable:
    * get the text value we know this element contains.
    */

  Well I would agree but it's a bit wired also. You think the DOM API is
horrible
  and you are still using it? You know what it means to use a
  horrible API? You write a horrible implementation! And thats how it looks.
  It took me more then a gaze to catch the meaning of the parser and I also
  got blown by the code duplication. Since I am in need to extend this
class,

  So I would like to ask if I may refactor it and commit you a patch (or
maybe
  a complete reimplementation)?


  Cheers,

  Martin (Kersten)

  PS: By the way, how about 'Hidding 3rd party library behind single
interface?'
    ----- Original Message -----
    From: Martin Kersten
    To: spr...@li...
    Sent: Tuesday, February 22, 2005 12:46 PM
    Subject: Re: [Springframework-developer] Please check these two things


    Sorry, thought the agreement goes with the callee.
    Ok :-) sorry was a strange day for me, I guess.

    Thanks,

    Martin (Kersten)
    ----- Original Message -----
      From: Juergen Hoeller
      To: spr...@li...
      Sent: Tuesday, February 22, 2005 12:13 PM
      Subject: Re: [Springframework-developer] Please check these two things


      Actually, I have *not* replaced this with a == comparison of the
arrays: Instead, BatchSqlUpdate is storing clones of the passed-in arrays
now, for execution on flush. This avoids any side effects in the first place
(even if the passed-in arrays are changed afterwards or reused for multiple
update inovcations), and the overhead of cloning an array should be
acceptable (after all, we're talking about database update operations here).

      Juergen


        -----Original Message-----
        From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Martin Kersten
        Sent: Tuesday, February 22, 2005 12:04 PM
        To: spr...@li...
        Subject: Re: [Springframework-developer] Please check these two
things


        But isn't this bogus thinking? I mean replacing .equals with ==
makes
        the implementation more strickt and reduces semantical informations.
        We are thinking about objects and there is no performance gap
        to justify this modification.

        I wouldn't do it. I just would ensure that equals implementations
        start with if(this==object) return true;. How huge is the estimated
        performance gain?


        Cheers,

        Martin (Kersten)
          ----- Original Message -----
          From: Juergen Hoeller
          To: spr...@li...
          Sent: Tuesday, February 22, 2005 10:06 AM
          Subject: Re: [Springframework-developer] Please check these two
things


          Well-spotted!

          ConcurrencyThrottleInterceptor should indeed use an internal
monitor to avoid any potential for side effects. I doubt that this has
caused any issue in practice, but it's nevertheless cleaner.

          That check in BatchSqlUpdate is not supposed to compare the
elements but just the array reference: Repeated update invocations should
not pass-in the same array instance repeatedly, with modified elements. Of
course, a == check would be sufficient for this. I've reworked that part a
bit differently, though: BatchSqlUpdate stores a clone of the passed-in
array now, so there shouldn't be a need for such a check anymore.

          Juergen


            -----Original Message-----
            From: spr...@li...
[mailto:spr...@li...]On Behalf Of
Dave Brosius
            Sent: Tuesday, February 22, 2005 8:08 AM
            To: spr...@li...
            Subject: [Springframework-developer] Please check these two
things


            These may be problems, and then again maybe not. But they seem
odd/wrong to me


            1) In
org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor

            in method invoke

            uses wait on 'this'

            In my mind you are exposing your synchronization strategies as a
public artifact, which leaves this class open to failure due to client code.
            The client code may unwittingly us an instance of this class to
do it's own synchronization, and totally screw up this class.
            I would recommend doing synchronizations (especially the use of
wait/notify) on a private member so client code can not effect it.



            2) In org.springframework.jdbc.object.BatchSqlUpdate

            in method update, you do

              if (!this.parameterQueue.isEmpty() &&
args.equals(this.parameterQueue.getLast())) {

            this is the same as using     args ==
this.parameterQueue.getLast()

            or in other words, are these objects the same object. I assume
you want to compare the elements of the array?