springframework-developer — Spring Framework developers list

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

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

I guess I just don't grasp it, but what benefit do contributions give my 
application as opposed to the current configuration mechanism? Can you 
give me a use case comparing the use of contributions to that of 
standard DI configuration?

Rob

Martin Kersten 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.
>
>
> 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

[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

[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...>]

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

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?

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

[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

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

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

[Springframework-developer] DeadlockLoserDataAccessException vs CannotAcquireLockException

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

Thomas, everybody,

Please have a look at the following JIRA issue:
http://opensource.atlassian.com/projects/spring/browse/SPR-733

I agree that DeadlockLoserDataAccessException should be a subclass of
ConcurrencyFailureException (which has been introduced in Spring 1.1), and
have already changed this locally.

However, DeadlockLoserDataAccessException isn't thrown anywhere;
SQLErrorCodes does not support it. So as indicated in SPR-733, should we
generally throw CannotAcquireLockException in such a case (which currently
seems to happen for some databases, as defined in sql-error-codes.xml)?
What's the semantic difference between those two exceptions, and is it worth
keeping both?

Juergen

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?

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?

[Springframework-developer] Re: CVS (again)

[katentim <kat...@ho...>]

My update gets stuck at (after a few spaced attempts):
cvs update: [11:06:28] waiting for anoncvs_springframework's lock in 
/cvsroot/springframework/spring/autobuilds/apps/ejbtest/src/application/META-INF

Darren Davison wrote:
> On Tue, February 22, 2005 9:40, Rob Harrop said:
> 
>>I always have problems with the CVS
>>
>>Darren Davison wrote:
>>
>>
>>>the performance of CVS seems so awful I can't even get updates properly now
>>
>>>from the SSH servers.  Anyone else having difficulty?
> 
> 
> at least we're not the only ones.  There are loads of recent support issues
> logged https://sourceforge.net/tracker/?group_id=1&atid=200001 - including one
> or two from frustrated users saying they're going to move from SF if they
> don't fix it properly this time or provide subversion instead.
> 
> I've now got a completely borked local tree due to several failed updates this
> morning :(
> 

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] CVS (again)

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

>>>the performance of CVS seems so awful I can't even get updates properly 
>>>now
>>>from the SSH servers.  Anyone else having difficulty?

>> I always have problems with the CVS

> at least we're not the only ones.  There are loads of recent support 
> issues
> logged https://sourceforge.net/tracker/?group_id=1&atid=200001 - including 
> one
> or two from frustrated users saying they're going to move from SF if they
>don't fix it properly this time or provide subversion instead.

> I've now got a completely borked local tree due to several failed updates 
> this
> morning :(

How about moving to codehaus.org? :-)


Cheers,

Martin (Kersten) 

Re: [Springframework-developer] CVS (again)

[Darren D. <da...@da...>]

On Tue, February 22, 2005 9:40, Rob Harrop said:
> I always have problems with the CVS
>
> Darren Davison wrote:
>
>>the performance of CVS seems so awful I can't even get updates properly=
 now
>>from the SSH servers.  Anyone else having difficulty?

at least we're not the only ones.  There are loads of recent support issu=
es
logged https://sourceforge.net/tracker/?group_id=3D1&atid=3D200001 - incl=
uding one
or two from frustrated users saying they're going to move from SF if they
don't fix it properly this time or provide subversion instead.

I've now got a completely borked local tree due to several failed updates=
 this
morning :(

--=20
Darren Davison
Public Key: #DD356B0D

Re: [Springframework-developer] CVS (again)

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

I always have problems with the CVS

Darren Davison wrote:

>the performance of CVS seems so awful I can't even get updates properly now
>from the SSH servers.  Anyone else having difficulty?
>
>  
>

[Springframework-developer] CVS (again)

[Darren D. <da...@da...>]

the performance of CVS seems so awful I can't even get updates properly n=
ow
from the SSH servers.  Anyone else having difficulty?

--=20
Darren Davison
Public Key: #DD356B0D

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?

[Springframework-developer] AOP Cache

[Pieter C. <pie...@on...>]

Hi,

Some time ago I've implemented an AOP Cache which can easily be used in
Spring.  It's ridiculously simple but very useful.  More info is in the
Spring Wiki:
http://opensource.atlassian.com/confluence/spring/display/DISC/AOP+Cache

It has support for OSCache, EHCache and SwarmCache.  I already got some
feedback from users who believe it is an interesting idea.  If there is
interest in it, I would like to add it to the sandbox since it is too
small to create a separate Sourceforge project for it.  I have no idea
about how to do this or if this is even meant for things like this.  Now
it is a bit lost inside the Wiki pages.

Maybe this is something for https://springmodules.dev.java.net/?

Any feedback is welcome,

Pieter

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

[Springframework-developer] Adding Contribution support

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

Hi developers,

   I am still dreaming about Spring supporting contributions
right out of the box. I posted an article in the architectural section
of the forum. I guess I found a quite good and sound implementation.

This is the short form:

1. new contribution tag features the same things bean also does.

<contribution extension-point="extensionPoint id" class="MyClass">
   same as bean
</contribution>

2. A extension point is constructed by the application hosting it.
type ExtensionPoint {
   //nothing just for identification
   //maybe hidden storing of the extension point id for semantic equal 
checking
}

3. Add support to the ApplicationContext for pulling the contributions

Object [] successfullInstanciatedContributions=
    ApplicationContext.instanciateContributions(ExtensionPoint, 
ExtensionPointPolicy);

4. ExtensionPointPolicy is about finishing the init process of a 
contribution
since some not hardwired dependencies have to be set by the stakeholder
of the contribution and can not be described within the contribution 
definition.

type ExtensionPointPolicy {
    boolean isCompatibleContribution(ContributionDefinition);
    injectAdditionalDependecies(Object contributionInstance);
}

So loading contributed toolbar actions may look like this:
MyApplication.loadToolBarActions{
     Object [] toolBarActions=
         applicationContext.instanciateContributions(toolbarActionsExtensionPoint,
           new ToolBarActionsExtensionPointPolicy());
}

private class ToolBarActionsExtensionPointPolicy
                       implements ExtensionPointPolicy {
      boolean isCompatibleContribution(ContributionDefinition) {
           Class 
contributionalType=contributionDefinition.getContributionType();
           return contributionalType.isCompatible(ToolBarAction.class);
           //no additional checking in this example
      }

      injectAdditionalDependencies(Object contributionInstance) {
          ((ToolBarAction)contributionInstance).setEnabled(true); //just to 
be scenceless
      }
}

Thats all. I guess this can be added quite cleanly. And I would enjoy doing
it myself :-).

It would provide great help I guess. The Spring RPC currently suffering
of the lack of defining contributions and using an extension point 
mechanism.

All is described in more detail within the forum article.


Cheers,

Martin (Kersten)

----- Original Message ----- 
From: "Jean-Philippe Gariepy" <ga...@ya...>
To: <spr...@li...>
Sent: Monday, February 21, 2005 4:47 PM
Subject: RE: [Springframework-developer] Custom bean instantiation language?


>
> I choose the { and } characters for the lists and [ ] for the maps.
>
> So instead of...
>
> <bean id="myBean" class="example.MyClass">
>  <property name="someList">
>    <list>
>      <value>item value</value>
>      <ref bean="beanReference"/>
>    </list>
>  </property>
>
>  <property name="someMap">
>    <map>
>      <entry key="key1">
>        <value>value1</value>
>      </entry>
>      <entry key="key2">
>        <value>value2</value>
>      </entry>
>    </map>
>  </property>
> </bean>
>
> ...I have...
>
> <myBean class="example.MyClass">
>  <someList>{item value, @beanReference}</someList>
>  <someMap>[key1=value1, key2=value2]</someMap>
> </myBean>
>
> Note that I've allowed bean references to be keys.  Hence, the following 
> is
> legal:
>
> <myBean class="example.MyClass">
>  <someList>{item value, @beanReference}</someList>
>  <someMap>[@beanReference=value1, key2=value2]</someMap>
> </myBean>
>
> Of course, when a meta-character (@ , [ ] { } =) is part of the key or 
> value,
> an escape character is required:
>
> <myBean class="example.MyClass">
>  <emailAddresses>{user1\@domain1.com, user2\@domain2.com}</emailAddresses>
> </myBean>
>
> Jean-Philippe
>
> --- Cameron Braid <ca...@br...> wrote:
>
>> > -----Original Message-----
>> > From: spr...@li...
>> > [mailto:spr...@li...] On 
>> > Behalf
>> > Of Jean-Philippe Gariepy
>> > Sent: Monday, 21 February 2005 12:29 PM
>> > To: spr...@li...
>> > Subject: Re: [Springframework-developer] Custom bean instantiation
>> > language?
>> >
>> > (This is an opportunity for me to share my thoughts about the bean
>> > factory.)
>>
>> --SNIP--
>>
>> > I've added other lightweight syntaxes for lists and maps.
>> >
>>
>> Can you please share them too. I like the look of this :)
>>
>>
>> Thanks,
>>
>> Cameron
>>
>
>
> =====
> ---------------------------------------
> Jean-Philippe Gariépy (ga...@ya...)
>
> "Quand l'appétit va, tout va."
>                       -Obélix
>
>
>
> __________________________________
> Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
> http://promotions.yahoo.com/new_mail
>
>
> -------------------------------------------------------
> 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] Custom bean instantiation language?

[Jean-Philippe G. <ga...@ya...>]

I choose the { and } characters for the lists and [ ] for the maps.

So instead of...

<bean id="myBean" class="example.MyClass">
  <property name="someList">
    <list>
      <value>item value</value>
      <ref bean="beanReference"/>
    </list>    
  </property>

  <property name="someMap">
    <map>
      <entry key="key1">
        <value>value1</value>
      </entry>
      <entry key="key2">
        <value>value2</value>
      </entry>
    </map>
  </property>
</bean>

...I have...

<myBean class="example.MyClass">
  <someList>{item value, @beanReference}</someList>
  <someMap>[key1=value1, key2=value2]</someMap>
</myBean>

Note that I've allowed bean references to be keys.  Hence, the following is
legal:

<myBean class="example.MyClass">
  <someList>{item value, @beanReference}</someList>
  <someMap>[@beanReference=value1, key2=value2]</someMap>
</myBean>

Of course, when a meta-character (@ , [ ] { } =) is part of the key or value,
an escape character is required:

<myBean class="example.MyClass">
  <emailAddresses>{user1\@domain1.com, user2\@domain2.com}</emailAddresses>
</myBean>

Jean-Philippe

--- Cameron Braid <ca...@br...> wrote:
 
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> > Of Jean-Philippe Gariepy
> > Sent: Monday, 21 February 2005 12:29 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] Custom bean instantiation
> > language?
> > 
> > (This is an opportunity for me to share my thoughts about the bean
> > factory.)
> 
> --SNIP--
> 
> > I've added other lightweight syntaxes for lists and maps.
> > 
> 
> Can you please share them too. I like the look of this :)
> 
> 
> Thanks,
> 
> Cameron
> 


=====
---------------------------------------
Jean-Philippe Gariépy (ga...@ya...)

"Quand l'appétit va, tout va." 
                       -Obélix


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

Re: [Springframework-developer] DelegatingActionProxy & setServlet()

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

The setServlet() call should happen through the ContextLoaderPlugIn that the
Actions have been loaded with; there should also be a setServlet(null) call
on shutdown. This allows, for example, multiple DelegatingActionProxy
definition in struts-config to point to the same Spring-managed Action bean,
without repeated setServlet() calls on the same instance.

Are you maybe defining your Struts Actions in Spring's root application
context? I would strongly recommend defining them in a separate
ContextLoaderPlugIn contexts, which in turn can reference midle tier beans
in the root application context (because the ContextLoaderPlugIn context
will automatically be a child of the root context, with all beans in the
root context being visible).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of John Georgiadis
Sent: Sunday, February 20, 2005 8:50 PM
To: spr...@li...
Subject: [Springframework-developer] DelegatingActionProxy &
setServlet()


Hi,

Actions wrapped by DelegatingActionProxy never have their setServlet()
method called. Does the following patch make sense?

	John

--- src/org/springframework/web/struts/DelegatingActionProxy.java.orig
2004-12-11 15:47:46.000000000 +0200
+++ src/org/springframework/web/struts/DelegatingActionProxy.java
2005-02-20 21:18:37.647013908 +0200
@@ -117,8 +117,10 @@
         */
        protected Action getDelegateAction(ActionMapping mapping) throws
BeansException {
                WebApplicationContext wac =
getWebApplicationContext(getServlet(), mapping.getModuleConfig());
-               String beanName = determineActionBeanName(mapping);
-               return (Action) wac.getBean(beanName, Action.class);
+               String beanName = determineActionBeanName(mapping);
+               Action action = (Action) wac.getBean(beanName,
Action.class);
+               action.setServlet(getServlet());
+               return action;
        }

        /**




-------------------------------------------------------
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] Preparing for 1.1.5

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

OK, that's fine!

If you've got some minor amounts of time left - test, test, test the current
codebase in real life scenarios :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rob Harrop
Sent: Monday, February 21, 2005 1:38 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.1.5


Not sure whether I'll finish it time. Plus something just landed on my
desk :(.

I'll put it in for 1.2. That'll give some more time to work on it.

Rob

Juergen Hoeller wrote:

>Hmmm, if it's not too invasive and you manage to get it in by tomorrow
>morning, then go for it - let's include it in 1.1.5.
>
>I'll leave for Ulm tomorrow afternoon, for a 3-day workshop; I'd like to go
>through the 1.1.5 codebase in the evenings there.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Rob Harrop
>Sent: Monday, February 21, 2005 12:43 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Preparing for 1.1.5
>
>
>I guess I should leave the MIME type support out for this release then?
>
>Rob
>
>Juergen Hoeller wrote:
>
>
>
>>Spring developers, everybody,
>>
>>I intend to release Spring 1.1.5 this Sunday (hard deadline). We need to
go
>>for Spring 1.2 RC1 right afterwards, releasing JMX support and Hibernate3
>>support, so we shouldn't lose any time. So please, test the current CVS
>>contents (or a current nightly snapshot) thoroughly, and refrain from
>>non-trivial code changes!
>>
>>One area worth re-testing, for example, is JDBC/Hibernate resource
>>management: There have been some recent changes, in particular affecting a
>>combination of  DataSourceTransactionManager/HibernateTransactionManager
>>
>>
>and
>
>
>>TransactionAwareDataSourceProxy. Of course, it's also important to check
>>that typical DataSourceTransactionManager/HibernateTransactionManager
usage
>>still works properly, not causing resource leaks in any scenario.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Juergen Hoeller
>>Sent: Wednesday, February 16, 2005 8:20 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] Preparing for 1.1.5
>>
>>
>>Everybody,
>>
>>I've committed lots of minor fixes and enhancements that I've implemented
>>
>>
>in
>
>
>>the past two weeks (most of them driven by JIRA issues). See the changelog
>>for details. The most important changes are:
>>
>>* I've added a "getBeanNamesForType" method to the ListableBeanFactory
>>interface, also checking FactoryBeans and manual singletons (in contrast
to
>>"getBeanDefinitionNames"). This is an alternative to "getBeansOfType" that
>>avoids creating prototype instances (assuming that all that is needed are
>>the names).
>>
>>* TransactionSynchronization objects can influence their execution order
>>through implementing the Ordered interface. This is used to always perform
>>JDBC Connection cleanup last, for example after Hibernate Session cleanup
>>(if any), and to always perform LobCreator cleanup first (while the JDBC
>>Connection is still active).
>>
>>* I've introduced the C3P0 0.8.5 ComboPooledDataSource as connection pool
>>for Image Database, to show an alternative to Commons DBCP. I've also
added
>>a C3P0NativeJdbcExtractor for C3P0 0.8.5 and later; for earlier C3P0
>>versions, SimpleNativeJdbcExtractor is sufficient.
>>
>>* I've upgraded MockHttpServletRequest to Servlet API 2.4 and
>>MockPageContext to JSP API 2.0. An enhancement enabled by compiling
against
>>JSP 2.0 is that JSP EL expressions in Spring's JSP tags will be parsed
with
>>the JSP 2.0 ExpressionEvaluator on JSP 2.0, falling back to Jakarta JSTL
>>
>>
>for
>
>
>>earlier JSP versions.
>>
>>* I've reworked JasperReportsMultiFormatView, in particular the
>>initialization code. I've also renamed its "discriminatorKey" property to
>>"formatKey", as a more expressive name and following the
>>AbstractJasperReportsView naming conventions ("reportDataKey" etc).
>>
>>Note that because of the upgrade to Servlet 2.4 and JSP 2.0, servlet.jar
>>
>>
>has
>
>
>>been replaced with servlet-api.jar and jsp-api.jar. I've also upgraded EJB
>>to 2.1 to raise all versions to J2EE 1.4, having replaced EJB 2.0's
ejb.jar
>>with EJB 2.1's ejb-api.jar. I've adapted all references that I could find
>>(build.xml etc).
>>
>>Juergen
>>
>>
>>
>>-------------------------------------------------------
>>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