Menu
▾
▴
Re: [Springframework-developer] I don't like the DefaultXmlBeanDefinitionParser
|
From: Martin K. <Mar...@St...> - 2005-02-22 14:58:23
|
> 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
|
