springframework-developer — Spring Framework developers list

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

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

> Which sounds similar to the contents of the current spring-core.jar to me,
> although there you get only the beanfactory support. For application 
> contexts,
> you have to use the spring-context.jar, which has a bunch of other,
> related stuff in it (ejb, jms etc.).

> The problem is, your definition of how to split modules is unlikely to
> be the same as mine, and mine will doubtless differ from the next x
> users you happen to ask.

That's the problem but one reason to split is target domain. Web is 
considered
to be a domain. Also I am quite sure orm should be replaced to
persisting/persistence. ORM is a certain kind of a solution and so is JDBC.
So we are talking about two solutions of the persistance problem.

-> *.persistence.jdbc, *.persistence.orm (or database or whatever)

-> Subproject: Web, Persistence (DB), Rich Client,
    J2EE (considered to be a special domain by Sun, J2SE vs J2EE).

> Where is AOP in your scenario?
Part of all worlds. Aspect orientated programming is a way of thinking and
about seperation of concerns -> Just addition to java. General audiance.->
main project.

> JDO but not HIbernate?
When you try to hire a developer for JDO or Hibernate task,
what would you request? General Java developer?

> Spring is already divided into 8 smaller jars, which seem to
> have a reasonable compromise of grouped related features.

The dependencies arnt. And so why don't you want to have
1Main + 3 sub projects? What do you want to do if Spring RPC is

I can't really comment on this as all I use is spring.jar, but doubtless 
they are ideal for some users and useless for others, but I don't see a huge 
amount of value in hashing and rehashing what should and shouldn't be in 
them. I do think those jars should maybe be made available for download 
separately, rather than having to get the whole spring distribution, source 
and all, just to get hold of eg. spring-core.jar.

Thanks,
-Dave

________________________________

From: spr...@li... on behalf of 
Martin Kersten
Sent: Tue 22/02/2005 14:56
To: spr...@li...
Subject: Re: [Springframework-developer] I don't like the 
DefaultXmlBeanDefinitionParser



> 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

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________



________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________ 

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

[Andy D. <an...@ma...>]

I sometimes wonder if sourceforge is headed toward failure (I've always 
wondered how they make enough revenue).  They seem to be giving off warning 
signs - reminds me of a failing hard drive - when you start to lose your 
sector remapping pool and hear an occasional click, it's time to get your 
replacement ready. :)

  - Andy

On Tuesday 22 February 2005 02:16 am, Darren Davison wrote:
>
> 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] 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

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

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] Adding Contribution support

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

>I think my understanding is a little skewed. Does the extension point id 
>match with multiple contributions?

The extension point is definied by the extension point stakeholder.
Therefore imagen an application window you want to contribute
actions for.

<contribution extension-point="org.springXX.rpc.ui.toolBar"
     class="MyContributedAction"/>

<contribution extension-point="org.springXX.rpc.ui.toolBar"
     class="MyOtherContributedAction"/>

The RPC ApplicationWindow would hold this extension point
and it will be the ApplicationWindow which will pull the actions
and place it within its toolbar.

That's how contribution works. Contributions are nameless little
fellows contributing to features the extension-point stakeholder
would love to be extended.

Also applying this to the Hibernate core:

 currently you provide the session factory with the mapping files directly.

But why not the reversed way?

<bean id="sessionFactory" ...../>

<contribution extension-point="org.springframework.orm.hibernate.mapping"/>
    <mapping>Here goes my MappingFile.xml</mapping>
</contribution>


I plan to add an image repository system and extend the context processing
by adding intelligent dependency injection.


Cheers,

Martin (Kersten)



Martin Kersten wrote:

>> Couldn't this be done without the <contribution> tag - that is to say 
>> just use the <bean> tag and then do:
>
>
>> ListableBeanFactory.getBeansOfType(Contribution.class);
>
>
> Wouldn't you think that would blow up your thinking?
> You know a bean is a bean but a contribution is something diffrent.
> It's the reverse way. You dont identify a contribution by its name or
> id (to abuse id here). It's about I want to take part. It's not I am
> what I am. It's a complete diffrent concept.
>
>> Then post process them. You could actually add this support as a 
>> BeanFactoryPostProcessor, since all you are really doing is chucking in 
>> some additional dependencies based on the policies.
>
>
> Would be working in an implementation way but the
> descriptive language the xml configuration compose gets malformed.
> It is like implementing a List by hacking a provided Set implementation.
> Can be done but I wont use it.
>
>> Applications can then lookup the contributions they want through some 
>> kind of ContributionManager interface.
>
>
> Would be possible but this is ApplicationContext related stuff so I
> would have to change this too.
>
>> Basically, I think you can add this support without the need to tweak the 
>> underlying Spring configuration format.
>
>
> It would not be possible because contributions shouldn't have an id or
> name.
>
>
> Let's see how easy it gets. The support wont break the API but
> if you are not yet convinced, I guess the main benifit it provides to
> the rich client project will do (and adding something like that to
> the rich client project does not need to effect the framework API).
>
>
> Cheers,
>
> Martin (Kersten)
>
> Martin Kersten wrote:
>
>> 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
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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

[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] is LazyInitTargetSource on factories possible?

[Scott B. <sco...@ru...>]

Juergen Hoeller wrote:

>BTW, why do you prefer your JaxRpcPortProxyFactoryBean to be lazily
>initialized? To avoid checking the WSDL at startup? It would maybe make
>sense to add a lazy initialization option to Spring's
>JaxRpcPortProxyFactoryBean itself in this case (I'll consider this).
>  
>
We've had to use the lazy-init on the JaxRpcPortProxyFactoryBean in 
order avoid checking the WSDL at start up in the case where the client 
of the web service is deployed in the same Tomcat instance as the web 
service itself (maybe there's a better way to handle this situation 
though...).

-Scott

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

[David H. <dh...@ob...>]

Which=20sounds=20similar=20to=20the=20contents=20of=20the=20current=20spri=
ng-core.jar=20to=20me,=20although=20there=20you=20get=20only=20the=20beanf=
actory=20support.=20For=20application=20contexts,=20you=20have=20to=20use=20=
the=20spring-context.jar,=20which=20has=20a=20bunch=20of=20other,=20relate=
d=20stuff=20in=20it=20(ejb,=20jms=20etc.).
=20
The=20problem=20is,=20your=20definition=20of=20how=20to=20split=20modules=20=
is=20unlikely=20to=20be=20the=20same=20as=20mine,=20and=20mine=20will=20do=
ubtless=20differ=20from=20the=20next=20x=20users=20you=20happen=20to=20ask=
.=20Where=20is=20AOP=20in=20your=20scenario?=20Is=20that=20part=20of=20cor=
e?=20What=20if=20I=20want=20a=20version=20without=20AOP?=20What=20if=20I=20=
want=20JMS,=20but=20not=20EJB?=20JDO=20but=20not=20HIbernate?=20The=20temp=
lating=20support=20really=20calls=20for=20its=20own=20spring-ui.jar.=20How=
=20about=20the=20struts=20integration?=20You=20certainly=20don't=20want=20=
all=20the=20spring=20web=20mvc=20support=20if=20you're=20just=20using=20th=
e=20struts=20integration.=20The=20only=20way=20to=20please=20both=20of=20u=
s=20would=20be=20to=20have=20around=2020=20different=20jar=20distributions=
,=20one=20for=20each=20major=20top=20level=20package.=20And=20what=20does=20=
that=20gain?
=20
Spring=20is=20already=20divided=20into=208=20smaller=20jars,=20which=20see=
m=20to=20have=20a=20reasonable=20compromise=20of=20grouped=20related=20fea=
tures.=20I=20can't=20really=20comment=20on=20this=20as=20all=20I=20use=20i=
s=20spring.jar,=20but=20doubtless=20they=20are=20ideal=20for=20some=20user=
s=20and=20useless=20for=20others,=20but=20I=20don't=20see=20a=20huge=20amo=
unt=20of=20value=20in=20hashing=20and=20rehashing=20what=20should=20and=20=
shouldn't=20be=20in=20them.=20I=20do=20think=20those=20jars=20should=20may=
be=20be=20made=20available=20for=20download=20separately,=20rather=20than=20=
having=20to=20get=20the=20whole=20spring=20distribution,=20source=20and=20=
all,=20just=20to=20get=20hold=20of=20eg.=20spring-core.jar.
=20
Thanks,
-Dave

________________________________

From:=20s...@li...=20on=20behal=
f=20of=20Martin=20Kersten
Sent:=20Tue=2022/02/2005=2014:56
To:=20s...@li...
Subject:=20Re:=20[Springframework-developer]=20I=20don't=20like=20the=20De=
faultXmlBeanDefinitionParser



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

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

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

If=20I=20would=20be=20in=20charge=20I=20would=20split=20it=20up=20the=20fo=
llowing=20way:

core,=20web,=20j2ee,=20persistence,=20later=20rpc.


Cheers,

Martin=20(Kersten)


>
>=20Rob
>
>=20Martin=20Kersten=20wrote:
>
>>>=20My=20thoughts=20exactly=20:).=20We=20have=20enough=20dependencies=20=
already.
>>
>>
>>=20You=20should=20break=20up=20your=20framework=20anyways.
>>
>>=20You=20are=20currently=20providing=20a=20'Jack=20of=20all=20trades'=20=
API.=20A=20solution
>>=20for=20everything=20but=20nothing=20in=20particular.
>>
>>=20Don't=20get=20mad=20:-)=20Here=20is=20what=20I=20mean:
>>
>>=20Spring=20adapts=20services=20for=20many=20diffrent=20situations:
>>=20=20You=20having=20a=20web=20application,=20fine=20download=20the
>>=20=20=20=20=20=20default=20spring=20framework,
>>=20=20You=20have=20a=20command=20line=20application,=20fine=20download
>>=20=20=20=20=20=20=20the=20default=20spring=20framework
>>
>>=20=20If=20it's=20not=20in=20the=20framework,=20we=20dont=20support=20it=
.
>>
>>=20Thats=20what=20I=20mean.=20Download=20the=20framework=20and=20be=20ha=
ppy.
>>
>>=20It's=20like=20java,=20download=20the=20SE=20and=20you=20have=20all=20=
the=20stuff=20those
>>=20folks=20think=20some=20(!)=20people=20might(!)=20wanna=20have.
>>
>>=20How=20about=20making=20a=20core=20framework=20and=20having=20extensio=
ns.
>>
>>=20So=20you=20go=20for=20a=20normal=20application,=20just=20download=20t=
he=20core
>>=20framework.=20You=20want=20to=20go=20for=20a=20web=20application,=20do=
wnload
>>=20the=20core=20framework=20and=20download=20the=20web=20extension.
>>
>>=20You=20know=20I=20am=20currently=20trying=20to=20get=20my=20visions=20=
into=20the=20RPC
>>=20sub=20project.=20And=20when=20you=20start=20to=20develop=20your=20own=

>>=20rich=20client(!)=20guess=20what,=20you=20have=20code=20for=20setting=20=
up=20a=20web
>>=20application=20right=20out=20of=20the=20box!
>>
>>=20Imagen=20what=20a=20relieve=20it=20would=20be=20for=20all=20of=20you=20=
folks=20to=20speak
>>=20about=20extensions=20and=20the=20core=20project,=20manage=20the=20dep=
endencies
>>=20for=20those=20individually.=20Imagen=20having=20more=20then=20one=20s=
wing=20reference
>>=20documentation.=20One=20for=20the=20core,=20one=20for=20the=20web,=20o=
ne=20for=20RPC=20and
>>=20so=20on.=20Boy=20I=20would=20be=20lucky=20if=20I=20were=20you=20:-).
>>
>>
>>=20Martin=20(Kersten)
>>
>>=20PS:=20Just=20a=20hint!=20;-)
>>
>>>=20Erwin=20Vervaet=20wrote:
>>>
>>>>=20I=20think=20the=20main=20reason=20to=20use=20the=20W3C=20DOM=20API=20=
directly=20is=20to=20avoid=20the
>>>>=20need=20for=20an=20extra=20dependency=20(e.g.=20JDOM)=20just=20to=20=
parse=20the=20XML=20bean
>>>>=20definitions.=20You=20end=20up=20with=20an=20"less=20than=20elegant"=
=20implementation=20in
>>>>=20DefaultXmlBeanDefinitionParser,=20but=20in=20this=20case=20the=20be=
nifits=20outweigh
>>>>=20the=20costs.
>>>>=20=20Erwin=20Vervaet
>>>>=20e...@er...=20<mailto:erw...@er...>
>>>>
>>>>=20=20=20=20=20-----=20Original=20Message=20-----
>>>>=20=20=20=20=20*From:*=20Martin=20Kersten
>>>>=20=20=20=20=20<mailto:Mar...@St...>
>>>>=20=20=20=20=20*To:*=20s...@li...=

>>>>=20=20=20=20=20<mailto:spr...@li...=
>
>>>>=20=20=20=20=20*Sent:*=20Tuesday,=20February=2022,=202005=201:21=20PM
>>>>=20=20=20=20=20*Subject:*=20[Springframework-developer]=20I=20don't=20=
like=20the
>>>>=20=20=20=20=20DefaultXmlBeanDefinitionParser
>>>>
>>>>=20=20=20=20=20Hi=20folks,
>>>>=20=20=20=20=20=20I=20am=20currently=20trying=20to=20extend=20the=20fr=
amework=20by=20supporting
>>>>=20=20=20=20=20contributions.
>>>>=20=20=20=20=20Just=20to=20see=20how=20it=20feels.
>>>>=20=20=20=20=20=20So=20I=20made=20some=20investigations=20in=20the=20s=
ourcecode.=20I=20don't=20want=20to
>>>>=20=20=20=20=20start=20a=20war
>>>>=20=20=20=20=20about=20proper=20design=20rules,=20since=20I=20am=20a=20=
believer=20in=20'Interface
>>>>=20=20=20=20=20belongs=20to=20the
>>>>=20=20=20=20=20client'=20stuff=20and=20you=20are=20appearently=20not,=20=
but=20this=20isn't=20the
>>>>=20=20=20=20=20issue=20I=20want=20to
>>>>=20=20=20=20=20talk=20about.
>>>>=20=20=20=20=20=20Th=20implementation=20I=20hate=20most=20on=20first=20=
sight=20is=20the
>>>>=20=20=20=20=20XMLBeanDefinitionParser.=20I=20know=20it=20does=20what=20=
it=20should=20but=20you=20can
>>>>=20=20=20=20=20read=20this:
>>>>=20=20=20=20=20=20/**
>>>>=20=20=20=20=20=20=20*=20Make=20the=20horrible=20DOM=20API=20slightly=20=
more=20bearable:
>>>>=20=20=20=20=20=20=20*=20get=20the=20text=20value=20we=20know=20this=20=
element=20contains.
>>>>=20=20=20=20=20=20=20*/
>>>>=20=20=20=20=20=20Well=20I=20would=20agree=20but=20it's=20a=20bit=20wi=
red=20also.=20You=20think=20the=20DOM
>>>>=20=20=20=20=20API=20is=20horrible
>>>>=20=20=20=20=20and=20you=20are=20still=20using=20it?=20You=20know=20wh=
at=20it=20means=20to=20use=20a
>>>>=20=20=20=20=20horrible=20API?=20You=20write=20a=20horrible=20implemen=
tation!=20And=20thats=20how
>>>>=20=20=20=20=20it=20looks.
>>>>=20=20=20=20=20It=20took=20me=20more=20then=20a=20gaze=20to=20catch=20=
the=20meaning=20of=20the=20parser=20and
>>>>=20=20=20=20=20I=20also
>>>>=20=20=20=20=20got=20blown=20by=20the=20code=20duplication.=20Since=20=
I=20am=20in=20need=20to=20extend
>>>>=20=20=20=20=20this=20class,
>>>>=20=20=20=20=20=20So=20I=20would=20like=20to=20ask=20if=20I=20may=20re=
factor=20it=20and=20commit=20you=20a=20patch
>>>>=20=20=20=20=20(or=20maybe
>>>>=20=20=20=20=20a=20complete=20reimplementation)?
>>>>=20=20=20=20=20=20Cheers,
>>>>=20=20=20=20=20=20Martin=20(Kersten)
>>>>=20=20=20=20=20=20PS:=20By=20the=20way,=20how=20about=20'Hidding=203rd=
=20party=20library=20behind=20single
>>>>=20=20=20=20=20interface?'
>>>>
>>>>=20=20=20=20=20=20=20=20=20-----=20Original=20Message=20-----
>>>>=20=20=20=20=20=20=20=20=20*From:*=20Martin=20Kersten
>>>>=20=20=20=20=20=20=20=20=20<mailto:Mar...@St...-Magdebur=
g.DE>
>>>>=20=20=20=20=20=20=20=20=20*To:*=20s...@li...=
rceforge.net
>>>>=20=20=20=20=20=20=20=20=20<mailto:spr...@li...=
rceforge.net>
>>>>=20=20=20=20=20=20=20=20=20*Sent:*=20Tuesday,=20February=2022,=202005=20=
12:46=20PM
>>>>=20=20=20=20=20=20=20=20=20*Subject:*=20Re:=20[Springframework-develop=
er]=20Please=20check=20these
>>>>=20=20=20=20=20=20=20=20=20two=20things
>>>>
>>>>=20=20=20=20=20=20=20=20=20Sorry,=20thought=20the=20agreement=20goes=20=
with=20the=20callee.=20Ok=20:-)=20sorry
>>>>=20was=20a=20strange=20day=20for=20me,=20I=20guess.
>>>>=20=20=20=20=20=20=20=20=20=20Thanks,
>>>>=20=20=20=20=20=20=20=20=20=20Martin=20(Kersten)
>>>>=20=20=20=20=20=20=20=20=20-----=20Original=20Message=20-----
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20*From:*=20Juergen=20Hoeller=20<=
mailto:ju...@in...>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20*To:*=20springframework-develop=
er...@li...
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20<mailto:springframework-develop=
er...@li...>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20*Sent:*=20Tuesday,=20February=20=
22,=202005=2012:13=20PM
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20*Subject:*=20Re:=20[Springframe=
work-developer]=20Please=20check
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20these=20two=20things
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20Actually,=20I=20have=20*not*=20=
replaced=20this=20with=20a=20=3D=3D=20comparison
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20of=20the=20arrays:=20Instead,=20=
BatchSqlUpdate=20is=20storing=20clones
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20of=20the=20passed-in=20arrays=20=
now,=20for=20execution=20on=20flush.=20This
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20avoids=20any=20side=20effects=20=
in=20the=20first=20place=20(even=20if=20the
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20passed-in=20arrays=20are=20chan=
ged=20afterwards=20or=20reused=20for
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20multiple=20update=20inovcations=
),=20and=20the=20overhead=20of=20cloning
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20an=20array=20should=20be=20acce=
ptable=20(after=20all,=20we're=20talking
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20about=20database=20update=20ope=
rations=20here).
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20Juergen
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20-----Original=20Mes=
sage-----
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*From:*
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20springframework-dev=
elo...@li...
>>>>
>>>>=20[mailto:spr...@li...]*On
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Behalf=20Of=20*Mart=
in=20Kersten
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*Sent:*=20Tuesday,=20=
February=2022,=202005=2012:04=20PM
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*To:*=20springframe=
wor...@li...
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*Subject:*=20Re:=20=
[Springframework-developer]=20Please
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20check=20these=20two=
=20things
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20But=20isn't=20this=20=
bogus=20thinking?=20I=20mean=20replacing
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20.equals=20with=20=3D=
=3D=20makes
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20implementatio=
n=20more=20strickt=20and=20reduces=20semantical
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20informations.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20We=20are=20thinking=
=20about=20objects=20and=20there=20is=20no
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20performance=20gap
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20to=20justify=20this=
=20modification.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20I=20wouldn't=20d=
o=20it.=20I=20just=20would=20ensure=20that=20equals
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20implementations
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20start=20with=20if(t=
his=3D=3Dobject)=20return=20true;.=20How=20huge=20is
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20the=20estimated
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20performance=20gain?=

>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Cheers,
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Martin=20(Kerste=
n)
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20-----=20=
Original=20Message=20-----
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*From:*=
=20Juergen=20Hoeller
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20<mailto=
:ju...@in...>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*To:*
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20springf=
ram...@li...
>>>>
>>>>=20<mailto:spr...@li...>
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*Sent:*=
=20Tuesday,=20February=2022,=202005=2010:06=20AM
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20*Subjec=
t:*=20Re:=20[Springframework-developer]=20Please
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20check=20=
these=20two=20things
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Well-sp=
otted!
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Conc=
urrencyThrottleInterceptor=20should=20indeed=20use
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20an=20in=
ternal=20monitor=20to=20avoid=20any=20potential=20for
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20side=20=
effects.=20I=20doubt=20that=20this=20has=20caused=20any
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20issue=20=
in=20practice,=20but=20it's=20nevertheless=20cleaner.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20That=
=20check=20in=20BatchSqlUpdate=20is=20not=20supposed=20to
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20compare=
=20the=20elements=20but=20just=20the=20array=20reference:
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Repeate=
d=20update=20invocations=20should=20not=20pass-in=20the
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20same=20=
array=20instance=20repeatedly,=20with=20modified
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20element=
s.=20Of=20course,=20a=20=3D=3D=20check=20would=20be
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20suffici=
ent=20for=20this.=20I've=20reworked=20that=20part=20a=20bit
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20differe=
ntly,=20though:=20BatchSqlUpdate=20stores=20a=20clone
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20of=20th=
e=20passed-in=20array=20now,=20so=20there=20shouldn't=20be
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20a=20nee=
d=20for=20such=20a=20check=20anymore.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Juer=
gen
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20-----Original=20Message-----
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20*From:*
>>>>
>>>>=20s...@li...
>>>>
>>>>=20[mailto:spr...@li...]*On
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20Behalf=20Of=20*Dave=20Brosius
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20*Sent:*=20Tuesday,=20February=2022,=202005=208:08=20AM
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20*To:*
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20s...@li...
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20*Subject:*=20[Springframework-developer]=20Please
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20check=20these=20two=20things
>>>>
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20These=20may=20be=20problems,=20and=20then=20again=20maybe
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20not.=20But=20they=20seem=20odd/wrong=20to=20me
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=201)=20In
>>>>
>>>>=20org.springframework.aop.interceptor.ConcurrencyThrottleInterceptor
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20in=20method=20invoke
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20uses=20wait=20on=20'this'
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20In=20my=20mind=20you=20are=20exposing=20your
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20synchronization=20strategies=20as=20a=20public
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20artifact,=20which=20leaves=20this=20class=20open=20to
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20failure=20due=20to=20client=20code.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20The=20client=20code=20may=20unwittingly=20us=20an=20instance
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20of=20this=20class=20to=20do=20it's=20own=20synchronization,
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20and=20totally=20screw=20up=20this=20class.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20I=20would=20recommend=20doing=20synchronizations
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20(especially=20the=20use=20of=20wait/notify)=20on=20a
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20private=20member=20so=20client=20code=20can=20not=20effect
>>>>=20it.
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=202)=20In
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20org.springframework.jdbc.object.BatchSqlUpdate
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20in=20method=20update,=20you=20do
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20if=20(!this.parameterQueue.isEmpty()=20&&
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20args.equals(this.parameterQueue.getLast()))=20{
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20this=20is=20the=20same=20as=20using=20=20=20=20=20args=20=3D=3D
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20this.parameterQueue.getLast()
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20or=20in=20other=20words,=20are=20these=20objects=20the=20same
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20object.=20I=20assume=20you=20want=20to=20compare=20the
>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20elements=20of=20the=20array?
>>>>
>>>
>>>
>>>=20-------------------------------------------------------
>>>=20SF=20email=20is=20sponsored=20by=20-=20The=20IT=20Product=20Guide
>>>=20Read=20honest=20&=20candid=20reviews=20on=20hundreds=20of=20IT=20Pro=
ducts=20from=20real=20users.
>>>=20Discover=20which=20products=20truly=20live=20up=20to=20the=20hype.=20=
Start=20reading=20now.
>>>=20http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>>>=20_______________________________________________
>>>=20Springframework-developer=20mailing=20list
>>>=20S...@li...
>>>=20https://lists.sourceforge.net/lists/listinfo/springframework-develop=
er
>>
>>
>>
>>
>>=20-------------------------------------------------------
>>=20SF=20email=20is=20sponsored=20by=20-=20The=20IT=20Product=20Guide
>>=20Read=20honest=20&=20candid=20reviews=20on=20hundreds=20of=20IT=20Prod=
ucts=20from=20real=20users.
>>=20Discover=20which=20products=20truly=20live=20up=20to=20the=20hype.=20=
Start=20reading=20now.
>>=20http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>>=20_______________________________________________
>>=20Springframework-developer=20mailing=20list
>>=20S...@li...
>>=20https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
>>
>>
>
>
>=20-------------------------------------------------------
>=20SF=20email=20is=20sponsored=20by=20-=20The=20IT=20Product=20Guide
>=20Read=20honest=20&=20candid=20reviews=20on=20hundreds=20of=20IT=20Produ=
cts=20from=20real=20users.
>=20Discover=20which=20products=20truly=20live=20up=20to=20the=20hype.=20S=
tart=20reading=20now.
>=20http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
>=20_______________________________________________
>=20Springframework-developer=20mailing=20list
>=20S...@li...
>=20https://lists.sourceforge.net/lists/listinfo/springframework-developer=




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

________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________



________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________

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] Adding Contribution support

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

I think my understanding is a little skewed. Does the extension point id 
match with multiple contributions?

Rob

Martin Kersten wrote:

>> Couldn't this be done without the <contribution> tag - that is to say 
>> just use the <bean> tag and then do:
>
>
>> ListableBeanFactory.getBeansOfType(Contribution.class);
>
>
> Wouldn't you think that would blow up your thinking?
> You know a bean is a bean but a contribution is something diffrent.
> It's the reverse way. You dont identify a contribution by its name or
> id (to abuse id here). It's about I want to take part. It's not I am
> what I am. It's a complete diffrent concept.
>
>> Then post process them. You could actually add this support as a 
>> BeanFactoryPostProcessor, since all you are really doing is chucking 
>> in some additional dependencies based on the policies.
>
>
> Would be working in an implementation way but the
> descriptive language the xml configuration compose gets malformed.
> It is like implementing a List by hacking a provided Set implementation.
> Can be done but I wont use it.
>
>> Applications can then lookup the contributions they want through some 
>> kind of ContributionManager interface.
>
>
> Would be possible but this is ApplicationContext related stuff so I
> would have to change this too.
>
>> Basically, I think you can add this support without the need to tweak 
>> the underlying Spring configuration format.
>
>
> It would not be possible because contributions shouldn't have an id or
> name.
>
>
> Let's see how easy it gets. The support wont break the API but
> if you are not yet convinced, I guess the main benifit it provides to
> the rich client project will do (and adding something like that to
> the rich client project does not need to effect the framework API).
>
>
> Cheers,
>
> Martin (Kersten)
>
> Martin Kersten wrote:
>
>> 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
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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

[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] Adding Contribution support

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

> Couldn't this be done without the <contribution> tag - that is to say just 
> use the <bean> tag and then do:

> ListableBeanFactory.getBeansOfType(Contribution.class);

Wouldn't you think that would blow up your thinking?
You know a bean is a bean but a contribution is something diffrent.
It's the reverse way. You dont identify a contribution by its name or
id (to abuse id here). It's about I want to take part. It's not I am
what I am. It's a complete diffrent concept.

> Then post process them. You could actually add this support as a 
> BeanFactoryPostProcessor, since all you are really doing is chucking in 
> some additional dependencies based on the policies.

Would be working in an implementation way but the
descriptive language the xml configuration compose gets malformed.
It is like implementing a List by hacking a provided Set implementation.
Can be done but I wont use it.

> Applications can then lookup the contributions they want through some kind 
> of ContributionManager interface.

Would be possible but this is ApplicationContext related stuff so I
would have to change this too.

> Basically, I think you can add this support without the need to tweak the 
> underlying Spring configuration format.

It would not be possible because contributions shouldn't have an id or
name.


Let's see how easy it gets. The support wont break the API but
if you are not yet convinced, I guess the main benifit it provides to
the rich client project will do (and adding something like that to
the rich client project does not need to effect the framework API).


Cheers,

Martin (Kersten)

Martin Kersten wrote:

> 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
>
>
>
>
> -------------------------------------------------------
> 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] Potentialt dangerous hibernate Session reuse

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

Hi folks,

Sorry to bring this back up again. What are your thoughts on defining
in the transaction demarcation whether sessions need to be kept open
for the benefit of rendering the view?

I can imagine that for some calls through the tx layer there's not
need to keep those sessions open. This would allow users to tweak the
OSIV pattern to there own needs.

Steven


On Mon, 21 Feb 2005 11:54:28 +0100, Steven Devijver
<ste...@gm...> wrote:
> A possible solution could be to define in the transaction demarcation
> setup if sessions need to kept open until the end of the request.
> 
> 
> On Mon, 21 Feb 2005 09:28:41 +0100, Per Olesen <po...@no...> wrote:
> >
> > >
> > > Yes, that's exactly how it would work, if you did indeed call down into
> > > the tx wrapped service layer multiple times. Of course, it's usually not
> > > appropriate to combine data from multiple transactions anyway, but one
> > > common case of this is where you call down to get the form backing
> > > object contents, and then later call down again with the modified
> > > object. The deferred close strategy blows up in this scenario. One
> > > workaround which Spring MVC makes pretty easy is to keep your form
> > > backing object in the session session, from the previous get. Then you
> > > end up only doing one call down into tx layer to apply changes.   But
> > > this _is_ a limitation, of course.
> > >
> >
> > Hmm yeah, we did think about that too. Actually, we thought about it before
> > deciding to use OpenSessionInView pattern, as using this pattern is exactly
> > about accepting multiple calls into the tx layer to get more easy view
> > development.
> >
> > This is also why I cannot see how the deferred close option will be an option
> > for anyone to solve this problem, cause all using OpenSessionInView will have
> > multiple calls from their view to back forms. This is one of the central
> > ideas of using OpenSessionInView.
> >
> > Regards, Per
> >
> >
> > -------------------------------------------------------
> > 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] Adding Contribution support

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

Couldn't this be done without the <contribution> tag - that is to say 
just use the <bean> tag and then do:

ListableBeanFactory.getBeansOfType(Contribution.class);

Then post process them. You could actually add this support as a 
BeanFactoryPostProcessor, since all you are really doing is chucking in 
some additional dependencies based on the policies.

Applications can then lookup the contributions they want through some 
kind of ContributionManager interface.

Basically, I think you can add this support without the need to tweak 
the underlying Spring configuration format.

Rob

Martin Kersten wrote:

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

[Dmitriy K. <dko...@ru...>]

Refactoring to improve the design of the existing code (maintainability, 
readability, etc.) is always good, iMO, provided that there is a 
comprehensive test suite to bullet proof the refactoring. I say go 
ahead, do it, and post it for the peer review.

Regards,
Dmitriy.


Steven Devijver wrote:

>During my many quest (sorry for the WoW terminology) of understanding
>Spring I endeavoured into the DefaultXmlBeanDefinitionParser code more
>than once. It's very hard to understand exactly what happens in there.
>
>Some refactoring could make it easier for clever people to tweak the
>Spring config format to their own needs. While the need for these
>tweaks may not be obvious to anyone of us there's nothing wrong with
>that. Supporting this can only improve the product. I don't think
>there's any need to anxiety since changes to the Spring core are
>thoroughly vetted.
>
>
>On Tue, 22 Feb 2005 13:54:48 +0000, Rob Harrop <ro...@ca...> wrote:
>  
>
>>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
>>>
>>>
>>>      
>>>
>>-------------------------------------------------------
>>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...>]

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

> 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

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

During my many quest (sorry for the WoW terminology) of understanding
Spring I endeavoured into the DefaultXmlBeanDefinitionParser code more
than once. It's very hard to understand exactly what happens in there.

Some refactoring could make it easier for clever people to tweak the
Spring config format to their own needs. While the need for these
tweaks may not be obvious to anyone of us there's nothing wrong with
that. Supporting this can only improve the product. I don't think
there's any need to anxiety since changes to the Spring core are
thoroughly vetted.


On Tue, 22 Feb 2005 13:54:48 +0000, Rob Harrop <ro...@ca...> wrote:
> 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
> >
> >
> 
> -------------------------------------------------------
> 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 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?

I posted a mail on this usegroup about some hours ago.
It's named 'Adding Contribution Support'.


Cheers,

Martin (Kersten)

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

[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] is LazyInitTargetSource on factories possible?

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

This is not a general problem with LazyInitTargetSource on a FactoryBean:
It's rather a problem with LazyInitTargetSource on a JDK proxy as target, if
no proxy interfaces have been specified. Try specifying an appropriate
interface on your ProxyFactoryBean definition (via the "proxyInterfaces"
bean property); this should automatically lead to a JDK proxy being
generated there too.

BTW, why do you prefer your JaxRpcPortProxyFactoryBean to be lazily
initialized? To avoid checking the WSDL at startup? It would maybe make
sense to add a lazy initialization option to Spring's
JaxRpcPortProxyFactoryBean itself in this case (I'll consider this).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Kristof Jozsa
Sent: Thursday, February 17, 2005 3:45 PM
To: spr...@li...
Subject: [Springframework-developer] is LazyInitTargetSource on
factories possible?


Hi,

do I see it right that LazyInitTargetSource with Spring 1.4 cannot be
applied to factory objects? Concretely, I'd want to initialize the
configured JaxRpcPortProxyFactoryBean in a lazy way and it both looks
like it *is* getting initalized on startup and it throws an exception
about trying to subclass a final class.. (see the exception at the end).

I'd need to figure out that issue as soon as possible, so any help's
greatly appreciated. Any workarounds might also help..

thanks much in advance,

Kristof

org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'rasPublicService' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Initialization of bean failed; nested
exception is org.aopalliance.aop.AspectException: null
java.lang.IllegalArgumentException: Cannot subclass final class class
$Proxy0
	at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:438)
	at
net.sf.cglib.transform.TransformingClassGenerator.generateClass(Transforming
ClassGenerator.java:33)
	at
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy
.java:25)
	at
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:
215)
	at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:368)
	at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:280)
	at
org.springframework.aop.framework.Cglib2AopProxy.getProxy(Cglib2AopProxy.jav
a:176)
	at
org.springframework.aop.framework.Cglib2AopProxy.getProxy(Cglib2AopProxy.jav
a:137)
	at
org.springframework.aop.framework.ProxyFactoryBean.getSingletonInstance(Prox
yFactoryBean.java:241)
	at
org.springframework.aop.framework.ProxyFactoryBean.setBeanFactory(ProxyFacto
ryBean.java:201)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:338)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:260)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:221)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:145)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.autowireByName(AbstractAutowireCapableBeanFactory.java:700)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.populateBean(AbstractAutowireCapableBeanFactory.java:668)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:325)
	at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.createBean(AbstractAutowireCapableBeanFactory.java:260)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:221)
	at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abstra
ctBeanFactory.java:145)
	at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInst
antiateSingletons(DefaultListableBeanFactory.java:282)
	at
org.springframework.context.support.AbstractApplicationContext.refresh(Abstr
actApplicationContext.java:317)
	at
org.springframework.web.context.support.AbstractRefreshableWebApplicationCon
text.refresh(AbstractRefreshableWebApplicationContext.java:131)
	at
org.springframework.web.struts.ContextLoaderPlugIn.createWebApplicationConte
xt(ContextLoaderPlugIn.java:352)
	at
org.springframework.web.struts.ContextLoaderPlugIn.initWebApplicationContext
(ContextLoaderPlugIn.java:295)
	at
org.springframework.web.struts.ContextLoaderPlugIn.init(ContextLoaderPlugIn.
java:224)
	at
org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.java:
839)
	at org.apache.struts.action.ActionServlet.init(ActionServlet.java:332)
	at javax.servlet.GenericServlet.init(GenericServlet.java:256)
	at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:220)
	at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.j
ava:445)
	at
org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplic
ationHandler.java:150)
	at
org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.
java:458)
	at org.mortbay.http.HttpServer.start(HttpServer.java:663)
	at com.iw.plugins.jettyrunner.PluginRunner.launch(PluginRunner.java:282)
	at com.iw.plugins.jettyrunner.PluginRunner.launch(PluginRunner.java:104)
	at com.iw.plugins.jettyrunner.PluginRunner.main(PluginRunner.java:75)


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