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