Menu
▾
▴
springframework-developer
|
From: Rob H. <ro...@ca...> - 2005-02-22 13:54:50
|
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 > > |
|
From: Martin K. <Mar...@St...> - 2005-02-22 14:07:16
|
>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 |
|
From: Steven D. <ste...@gm...> - 2005-02-22 14:12:38
|
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 > > |
|
From: Dmitriy K. <dko...@ru...> - 2005-02-22 14:29:11
|
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 > > |
|
From: Michael S. <mi...@sc...> - 2005-02-22 22:11:27
|
On Tuesday 22 February 2005 17:11, Martin Kersten wrote: > Also I would love to see Spring being applied to > the 'Interface belongs to the client' design principle. :-) A faithful of the church of (Uncle) Bob, or so it seems ;-) If I understand you correctly, you bemoan that currently abstractions, i.e. interfaces, and their implementations often live in the same package. This presumably results in these packages being off the mainline, meaning they are neither abstract and stable, nor concrete and instable. Your suggested solution is to move the abstractions to the packages where they are actually used. Thereby rendering their originating packages more concrete. Now, what would the outcome be? As most of the abstractions are used from multiple client packages, they can't be moved to any single one of them. Instead, new "abstract" packages would have to be created for them. Yes, this change would probably improve the scores on some design metric. Still, I'm somewhat sceptical if improvements of, say, learnability or maintainability would ensue. Also, as a matter of fact, Spring packages are not released individually, thus it is not very important to keep their interdependencies low. -- Your turn. Michael -- Michael Schuerig The more it stays the same, mailto:mi...@sc... The less it changes! http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock |
|
From: Martin K. <Mar...@St...> - 2005-02-22 22:49:29
|
>> Also I would love to see Spring being applied to >> the 'Interface belongs to the client' design principle. :-) > > A faithful of the church of (Uncle) Bob, or so it seems ;-) Who is Bob? :-) I am with Fowler and Kent! ;-) > If I understand you correctly, you bemoan that currently abstractions, > i.e. interfaces, and their implementations often live in the same > package. This presumably results in these packages being off the > mainline, meaning they are neither abstract and stable, nor concrete > and instable. > > Your suggested solution is to move the abstractions to the packages > where they are actually used. Thereby rendering their originating > packages more concrete. Now, what would the outcome be? As most of the > abstractions are used from multiple client packages, they can't be > moved to any single one of them. Instead, new "abstract" packages would > have to be created for them. Nope! Look at the ApplicationContext within the package *.context. Applying the interface belongs to the client is like this. The ApplicationContext for me is the core component of the springframework the way I used to use it. Define a context and off you go. So where does the ApplicationContext interface belongs to? Well it is about the org.springframework package. The springframework is the client being in need of the ApplicationContext to deliver use for the people. When defining a library the library root module becomes the client. It's that simple. In our example moving ApplicationContext to org.springframework where it belongs to, you state to the user of the framework that everything of the sub packages is somewhat related to this interface. So the whole context-subpackage becomes a package only existing to implement the features the application context promises the user of the framework. That's it. And when you do this consistently among the whole framework you wouldn't see this explosion of sub.packages. AOP is a real difficult modul. It is more like a utility modul I guess. It provides help everywhere. Thats the nature of aspect oriented programming, I guess. Also the seperation of subprojects becomes natural. For example if you try to pull out some client interfaces of the web modul and justify the existence within the org.springframework package, you simply fail. It's somewhat special. Thats the point to tip your toe and split the project into main and sub-project. > Yes, this change would probably improve the scores on some design > metric. Still, I'm somewhat sceptical if improvements of, say, > learnability or maintainability would ensue. Also, as a matter of fact, > Spring packages are not released individually, thus it is not very > important to keep their interdependencies low. -- Your turn. It is about focus of the people working within sub-projects. I often see usefull code being not pushed up the package hierarchie just because the lack of focus. It doesn't look like web push it up. Somewhere would be the right place. But this doesn't happen often when you deal with string manipulation etc. I dont know how it is in terms of Spring since it is only providing some kind of coupling and not implementation. Maybe the duplication in functionality (not code!) is not that bad. Martin (Kersten) PS: Nice reading section by the way. I would like to add that "Code Complete,2nd Edition"(++), "Mythical Man-Month"(+++), "Domain-Driven-Design" (+++!), "Death March" (++), "Software Project Survival Guide" (++) are also some great reads. PSS: Saidly but "Analyse Pattern" was the first and last book that Martin Fowler wrote about world analysation. I got a great lesson lately completly focused about analysation pattern and another one called requirement enginiering. That was mind altering, I can tell you! But there is no standard book about this! :-( > Michael Schuerig The more it stays the same, > mailto:mi...@sc... The less it changes! > http://www.schuerig.de/michael/ --Spinal Tap, The Majesty of Rock > > > ------------------------------------------------------- > 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 |
|
From: Michael S. <mi...@sc...> - 2005-02-23 00:02:52
|
On Tuesday 22 February 2005 23:47, Martin Kersten wrote: > >> Also I would love to see Spring being applied to > >> the 'Interface belongs to the client' design principle. :-) > > > > A faithful of the church of (Uncle) Bob, or so it seems ;-) > > Who is Bob? :-) I am with Fowler and Kent! ;-) I was pretty sure, but apparently wrong nonetheless, that you were referring to Robert C. Martin, aka Uncle Bob. In particular, I thought you had some of these principles in mind <http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles> > Applying the interface belongs to the client is like this. > The ApplicationContext for me is the core component of the > springframework the way I used to use it. Define a context and > off you go. So where does the ApplicationContext interface belongs > to? Well it is about the org.springframework package. The > springframework is the client being in need of the ApplicationContext > to deliver use for the people. I don't agree; at least I'm not convinced. For one thing, I've used parts of Spring without touching so much as a BeanFactory. To my mind, the Spring package structure is easy to follow. The level below org.springframework denotes some general concern that can be understood from the point of view of a developer using Spring. The packages below that are about more specific aspects or implementation. As is, the package structure appears to be "taxonomically-inspired", it hierarchically groups related pieces. Whereas what you suggest is a "usage-inspired" grouping, where things that likely to be used together are put nearby. > It is about focus of the people working within sub-projects. I often > see usefull code being not pushed up the package hierarchie just > because the lack of focus. Let me suggest that the reason is not lack of focus, but a fundamentally different mindset regarding where things belong. I don't share your view and judging from Spring as it is, neither does the Spring team. In particular, I don't share the assumption that the deeper down the package hierarchy a class is located the less significant it is. > PS: Nice reading section by the way. I would like to add that > "Code Complete,2nd Edition"(++), "Mythical Man-Month"(+++), > "Domain-Driven-Design" (+++!), "Death March" (++), > "Software Project Survival Guide" (++) are also some great reads. Except for "Death March" I've read them, DDD is actually there on the list and the others just didn't make it. > PSS: Saidly but "Analyse Pattern" was the first and last book > that Martin Fowler wrote about world analysation. I got a great > lesson lately completly focused about analysation pattern and > another one called requirement enginiering. That was mind > altering, I can tell you! But there is no standard book about this! > :-( I have "Data and Reality" by William Kent unread at arms length. It's approaching 30 years of age, but I've seen some recommendations recently. In general, though, I think software development should not try to mimick ontology. Epistemology may be more like it, thus modeling how we interact with the world instead of how it is in itself. Incidentally, we appear to exchange positions here. Where above I favored a roughly "ontological/taxonomical" approach, in this regard I prefer "epistemological/usage-based". But I fear that's just idle theory... Michael -- Michael Schuerig The Fifth Rider of the Apocalypse mailto:mi...@sc... is a programmer. http://www.schuerig.de/michael/ |
|
From: Martin K. <Mar...@St...> - 2005-02-23 10:58:24
|
>> >> Also I would love to see Spring being applied to >> >> the 'Interface belongs to the client' design principle. :-) >> > >> > A faithful of the church of (Uncle) Bob, or so it seems ;-) >> >> Who is Bob? :-) I am with Fowler and Kent! ;-) > > I was pretty sure, but apparently wrong nonetheless, that you were > referring to Robert C. Martin, aka Uncle Bob. Well, well, Mr Martin is for sure a person, I know about. But I never heared of Uncle Bob. But Martin's books are great stuff :-). > In particular, I thought you had some of these principles in mind > <http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles> Ok I read his works, so I know them. But 'Dont ask just tell' is another strong principle he don't refer to. I dont know how this matches his collection of favorite principles. >> Applying the interface belongs to the client is like this. >> The ApplicationContext for me is the core component of the >> springframework the way I used to use it. Define a context and >> off you go. So where does the ApplicationContext interface belongs >> to? Well it is about the org.springframework package. The >> springframework is the client being in need of the ApplicationContext >> to deliver use for the people. > > I don't agree; at least I'm not convinced. For one thing, I've used > parts of Spring without touching so much as a BeanFactory. To my mind, > the Spring package structure is easy to follow. The level below > org.springframework denotes some general concern that can be understood > from the point of view of a developer using Spring. The packages below > that are about more specific aspects or implementation. Thats how it is said to be thought of. But think about it, why does the *.web modul doesn't contain any type/classes? Wouldn't you expecting something going on here? > As is, the package structure appears to be "taxonomically-inspired", it > hierarchically groups related pieces. Whereas what you suggest is a > "usage-inspired" grouping, where things that likely to be used together > are put nearby. Well you are user centric anyways. Dont implement something that noone uses. So there is a usecase for everything within the spring framework. But use cases are about functionality and the main functionality should be expressed by the main modul/package. >> It is about focus of the people working within sub-projects. I often >> see usefull code being not pushed up the package hierarchie just >> because the lack of focus. > > Let me suggest that the reason is not lack of focus, but a fundamentally > different mindset regarding where things belong. I don't share your > view and judging from Spring as it is, neither does the Spring team. In > particular, I don't share the assumption that the deeper down the > package hierarchy a class is located the less significant it is. It's about specialisation. The deeper the module lays in the hierarchy the more special is the use case scenario. >> PS: Nice reading section by the way. I would like to add that >> "Code Complete,2nd Edition"(++), "Mythical Man-Month"(+++), >> "Domain-Driven-Design" (+++!), "Death March" (++), >> "Software Project Survival Guide" (++) are also some great reads. > > Except for "Death March" I've read them, DDD is actually there on the > list and the others just didn't make it. 'Death March' is a nice one. Alexander's pattern book should be read also ;-). 'Writing effective Usecases' is also a good one but its layout is flawed. But I guess this one you also read. Any recommondations beside the books you state in your book list (read most of them). >> PSS: Saidly but "Analyse Pattern" was the first and last book >> that Martin Fowler wrote about world analysation. I got a great >> lesson lately completly focused about analysation pattern and >> another one called requirement enginiering. That was mind >> altering, I can tell you! But there is no standard book about this! >> :-( > I have "Data and Reality" by William Kent unread at arms length. It's > approaching 30 years of age, but I've seen some recommendations > recently. In general, though, I think software development should not > try to mimick ontology. Epistemology may be more like it, thus modeling > how we interact with the world instead of how it is in itself. > Incidentally, we appear to exchange positions here. Where above I > favored a roughly "ontological/taxonomical" approach, in this regard I > prefer "epistemological/usage-based". But I fear that's just idle > theory... I guess this book was a base foundation of my lessons. Well I only go with the use-case centric approach. Everything is based on the usage experience of the user. Do the simpliest thing to satisfy the user. Supporting modules have to satisfy the needs of the parent modul. But how does the parent modul forumlate the requirements about the implementation? The parent provides the interfaces the sub-modul has to satisfy. That's all. Parent (Client) defines the needs by providing interfaces. That's why interfaces should belong to the client. That's why parent moduls are the client of sub-modules. And that's why I argue that way. Cheers, Martin (Kersten) > > > Michael > > -- > Michael Schuerig The Fifth Rider of the Apocalypse > mailto:mi...@sc... is a programmer. > http://www.schuerig.de/michael/ > > > ------------------------------------------------------- > 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 |
|
From: Colin S. <col...@ex...> - 2005-02-23 03:02:48
|
In fact, you can need cglib even without using the 'main' aop code, if
you use method injection in the core container...
Rob Harrop 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
|
|
From: Steven D. <ste...@gm...> - 2005-02-23 09:28:47
|
It's ok to think separate jars have merit, it's ok to stick to the
paritioning as it is but why not document the dependencies?
On Tue, 22 Feb 2005 22:02:29 -0500, Colin Sampaleanu <col...@ex...> wrote:
> In fact, you can need cglib even without using the 'main' aop code, if
> you use method injection in the core container...
>
>
> Rob Harrop 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
>
> -------------------------------------------------------
> 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
>
>
|
|
From: Michael S. <mi...@sc...> - 2005-02-23 11:23:25
|
On Wednesday 23 February 2005 11:55, Martin Kersten wrote: > Thats how it is said to be thought of. But think about it, why does > the *.web modul doesn't contain any type/classes? Wouldn't you > expecting something going on here? No, why should I? For my taste you're relying too much on principles. While these principles are certainly not bad, you have to show that they're pulling some weight in the cases where you suggest they be applied. Put up a web page with a class diagram of an alternative package structure and explain why -- in practical terms! -- it is superior. Michael -- Michael Schuerig Most people would rather die than think. mailto:mi...@sc... In fact, they do. http://www.schuerig.de/michael/ --Bertrand Russell |
|
From: Martin K. <Mar...@St...> - 2005-02-23 13:13:20
|
>> Thats how it is said to be thought of. But think about it, why does >> the *.web modul doesn't contain any type/classes? Wouldn't you >> expecting something going on here? > > No, why should I? For my taste you're relying too much on principles. > While these principles are certainly not bad, you have to show that > they're pulling some weight in the cases where you suggest they be > applied. Put up a web page with a class diagram of an alternative > package structure and explain why -- in practical terms! -- it is > superior. Principles are just concepts. But understanding the outcome (the reason), I can refer to priniples - which are only design advices/ ways to design/think - to talk about the use of these concepts. But of cause there is an underlying reason why the concepts exist / where identified by the contributors. That reason is the fun. Never the less. I am not quite familiar with the web application (I use the package of cause, but it's only for the descriptive task). One thing that I want you consider: You said you used the bean package just for your stuff. The rest you were not needing. But think of the ApplicationContext, it is the reason why the beans package is existing. ApplicationContext is the more abstract level. So you would be able to do your stuff with the application context, too. Using the ApplicationContext should be seen as the 'better' way to do things. I only used the ApplicationContext. The diffrence between my test cases and the product is the way I describe the ApplicationContext. And thats all. So in my oppinion the ApplicationContext should be placed in org.springframework since beans, aop and context are only exisiting to provide the functionality the ApplicationContext needs (or better an implementation of the interface needed). And check out the web package. Same pattern. WebApplicationContext could be placed in the *.web package since everything else is related to it. Check out the jsp tags - only providing to access the web application context. Sure you can rip of the package and use the bean implementation by yourself. Thats how it is ment to be. Part of, you know. If a part can meet your needs, than the whole will also do. For example, I am currently doing refactoring of the DefaultXmlBeanDefinitionParser implementation. This is part of bean.factory.xml. In my thinking this is wrong placement. The parser first of all should be in a modul about parsers. But beside this you read an application context definition file. Check out how the dtd of spring is defined. All about beans. To describe an application context you are referring to the dtd. -> Spring is about defining a application context for certain applications. That's what it makes superior. It makes the application center (opposite are Enterprise Java Beans). -> The sub-modules are only existing to provide good integration with common sub-domain specific needs like using JMX, java mail, web etc. Draw the UML-Class diagramm about the current Spring design and the way I would love it would be. When you draw in the dependencies (who needs who) than you will see that in a spring world you have dependencies among modules within the same level of structur. In my design the type dependencies go straight to the sub-modules and the implementation dependencies go straight up to the parent modul. That's what it makes it superior (in my view). Cheers, Martin (Kersten) PS: Maybe we simply should state that we disagree and well cut it off :-). |
|
From: Michael S. <mi...@sc...> - 2005-02-23 14:16:20
|
On Wednesday 23 February 2005 14:11, Martin Kersten wrote: > PS: Maybe we simply should state that we disagree and > well cut it off :-). Agreed. Michael -- Michael Schuerig This is not a false alarm mailto:mi...@sc... This is not a test http://www.schuerig.de/michael/ --Rush, Red Tide |
|
From: Martin K. <Mar...@St...> - 2005-02-23 15:00:18
|
Hi there,
since I am tackling the XmlBeanDefinitionParser implementation,
I found a simple solution to add contributional support to the Spring
framework, without breaking any backward compatibility on either
library nor dtd.
First of all I refactored the parser code and gained a very deep
understanding, about what actual happends on startup.
I also done a short analysation of the world part under discurse
and discovered that a contribution is nothing other
then a bean (specialisation of it). The concept the word
bean stands for covers contributional beans also. So my simple
solution will feel natural for any user of Spring (no new concept
to be introduced, just an additional way to use beans).
Bean: A instance (singleton or not etc.)
BeanDefinition: A bean definition describes requirements toward
a bean instance.
Contribution: Contribution of feature implementations
towards a certain extension point representable by a
bean.
ExtensionPoint: The extension point is the point of extention.
Extending can be done by contributing a
contribution.
ExtensionPointPolicy: Describes the requirements for a contribution
extending the extension point. (Compatibility,
Correctness)
ExtensionPoint Stakeholder: Controls the extension point requirements
and usage. (Declaration of the extension point and
its
requirements -> Declaration, Compatibility,
Lifecycle handling)
So how does this analysation fit within the way of Spring?
Push ability (wiring up beans)
<beans>
<bean id="name"> stuff</bean>
</beans>
Contribution: (pulling feature contributions on runtime)
<beans>
<contributions extension-point="extensionPoint">
<bean notNamed>stuff</bean>
</contributions>
</beans>
Usage:
Object contributions=
ApplicationContext.getContributions(
ExtensionPoint, ExtensionPointPolicy);
I guess this would be a great feature for the spring-framework.
It would combine the world of Spring (push) with the world
of Eclipse(pull) in a way that leaverage the use of Spring since
pulling and pushing dependencies apply to be diffrent sets of
problems.
Is it granted that this feature would make it to the spring
framework? Since this wont break any
backward-compatibility requirements, it can be introduced
in the next Spring 1.x release easily.
Cheers,
Martin (Kersten)
|
|
From: Steven D. <ste...@gm...> - 2005-02-23 15:07:55
|
Martin, I've been following this discussion but the concept of contribution, extension point, stakeholder doesn't mean anything to me. Could you please ellaborate for my understanding? Thanks Steven On Wed, 23 Feb 2005 15:58:02 +0100, Martin Kersten <Mar...@st...> wrote: > Hi there, > > since I am tackling the XmlBeanDefinitionParser implementation, > I found a simple solution to add contributional support to the Spring > framework, without breaking any backward compatibility on either > library nor dtd. > > First of all I refactored the parser code and gained a very deep > understanding, about what actual happends on startup. > I also done a short analysation of the world part under discurse > and discovered that a contribution is nothing other > then a bean (specialisation of it). The concept the word > bean stands for covers contributional beans also. So my simple > solution will feel natural for any user of Spring (no new concept > to be introduced, just an additional way to use beans). > > Bean: A instance (singleton or not etc.) > BeanDefinition: A bean definition describes requirements toward > a bean instance. > > Contribution: Contribution of feature implementations > towards a certain extension point representable by a > bean. > > ExtensionPoint: The extension point is the point of extention. > Extending can be done by contributing a > contribution. > ExtensionPointPolicy: Describes the requirements for a contribution > extending the extension point. (Compatibility, > Correctness) > ExtensionPoint Stakeholder: Controls the extension point requirements > and usage. (Declaration of the extension point and > its > requirements -> Declaration, Compatibility, > Lifecycle handling) > > So how does this analysation fit within the way of Spring? > > Push ability (wiring up beans) > > <beans> > <bean id="name"> stuff</bean> > </beans> > > Contribution: (pulling feature contributions on runtime) > > <beans> > <contributions extension-point="extensionPoint"> > <bean notNamed>stuff</bean> > </contributions> > </beans> > > Usage: > > Object contributions= > ApplicationContext.getContributions( > ExtensionPoint, ExtensionPointPolicy); > > I guess this would be a great feature for the spring-framework. > It would combine the world of Spring (push) with the world > of Eclipse(pull) in a way that leaverage the use of Spring since > pulling and pushing dependencies apply to be diffrent sets of > problems. > > Is it granted that this feature would make it to the spring > framework? Since this wont break any > backward-compatibility requirements, it can be introduced > in the next Spring 1.x release easily. > > 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 > > |
|
From: Martin K. <Mar...@St...> - 2005-02-23 15:58:17
|
Hi Steven, > I've been following this discussion but the concept of contribution, > extension point, stakeholder doesn't mean anything to me. Could you > please ellaborate for my understanding? Check out the spring framework support forum, architectural section. My topic about turning beans up side down. There you find an explaination. Cheers, Martin (Kersten) > On Wed, 23 Feb 2005 15:58:02 +0100, Martin Kersten > <Mar...@st...> wrote: >> Hi there, >> >> since I am tackling the XmlBeanDefinitionParser implementation, >> I found a simple solution to add contributional support to the Spring >> framework, without breaking any backward compatibility on either >> library nor dtd. >> >> First of all I refactored the parser code and gained a very deep >> understanding, about what actual happends on startup. >> I also done a short analysation of the world part under discurse >> and discovered that a contribution is nothing other >> then a bean (specialisation of it). The concept the word >> bean stands for covers contributional beans also. So my simple >> solution will feel natural for any user of Spring (no new concept >> to be introduced, just an additional way to use beans). >> >> Bean: A instance (singleton or not etc.) >> BeanDefinition: A bean definition describes requirements toward >> a bean instance. >> >> Contribution: Contribution of feature implementations >> towards a certain extension point representable by a >> bean. >> >> ExtensionPoint: The extension point is the point of extention. >> Extending can be done by contributing a >> contribution. >> ExtensionPointPolicy: Describes the requirements for a contribution >> extending the extension point. (Compatibility, >> Correctness) >> ExtensionPoint Stakeholder: Controls the extension point requirements >> and usage. (Declaration of the extension point >> and >> its >> requirements -> Declaration, Compatibility, >> Lifecycle handling) >> >> So how does this analysation fit within the way of Spring? >> >> Push ability (wiring up beans) >> >> <beans> >> <bean id="name"> stuff</bean> >> </beans> >> >> Contribution: (pulling feature contributions on runtime) >> >> <beans> >> <contributions extension-point="extensionPoint"> >> <bean notNamed>stuff</bean> >> </contributions> >> </beans> >> >> Usage: >> >> Object contributions= >> ApplicationContext.getContributions( >> ExtensionPoint, ExtensionPointPolicy); >> >> I guess this would be a great feature for the spring-framework. >> It would combine the world of Spring (push) with the world >> of Eclipse(pull) in a way that leaverage the use of Spring since >> pulling and pushing dependencies apply to be diffrent sets of >> problems. >> >> Is it granted that this feature would make it to the spring >> framework? Since this wont break any >> backward-compatibility requirements, it can be introduced >> in the next Spring 1.x release easily. >> >> 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 |
|
From: Juergen H. <ju...@in...> - 2005-02-26 20:17:05
|
Martin, <quote> So in my oppinion the ApplicationContext should be placed in org.springframework since beans, aop and context are only exisiting to provide the functionality the ApplicationContext needs (or better an implementation of the interface needed). </quote> In fact, the beans and aop packages do not only exist to serve the ApplicationContext. Spring is not a single system with a single entry point: In that respect, the Spring distribution is more similar to the JDK's structure than it is to Hibernate's, for example. The beans package is completely independent and can of course be used on its own, both at the BeanWrapper level and at the BeanFactory level. Some people happily do either of the two, and don't care about the context package (or any other Spring packages) at all. The beans package is also used internally by the JDBC support, the validation package and other parts of Spring. No ApplicationContext (or MessageSource etc) needed there, just low-level BeanWrapper and/or BeanFactory functionality. Quite a lot of people are using Spring's JDBC support completely outside a Spring application context, for example in custom DAOs or in custom EJBs. Also, parts of the web package are more reusable than you assume; the WebApplicationContext isn't really central to it. For example, Spring-style data binding can easily be used in a plain Servlet or any other web component built on a ServletRequest: simply take Spring's ServletRequestDataBinder (package web.bind) and use it in a library style. This is why spring-core.jar just contains the beans package, not the context package. Those spring-core.jar contents are perfectly sufficient for using the JDBC support (spring-dao.jar), or the web data binding in a library fashion (spring-web.jar). Such parts of Spring can be used in a library style, within any kind of architecture (for example, in custom frameworks or in EJB-centric applications). Only for applications that are fully architected on a Spring basis, an ApplicationContext will play a central role. This is significantly different from a single-purpose tool such as Hibernate, where the SessionFactory/Session combo plays a central role in all scenarios. <quote> For example, I am currently doing refactoring of the DefaultXmlBeanDefinitionParser implementation. This is part of bean.factory.xml. In my thinking this is wrong placement. The parser first of all should be in a modul about parsers. But beside this you read an application context definition file. Check out how the dtd of spring is defined. All about beans. To describe an application context you are referring to the dtd. </quote> Again, I tend to look at this from a different perspective: The BeanFactory stuff in the beans.factory package is the central part that deals with bean definitions. An ApplicationContext is "just" a higher-level facade for it, adding auto-detection for special beans and additional services like a MessageSource. Consequently, XML bean definition parsing does belong in the beans.factory package, as it is "just" a special variant of parsing bean definitions. XML bean definitions may be the current main format for defining application contexts, but from the framework point of view, it is just yet another bean definition format and by no means central to all other parts of Spring. Juergen |
|
From: Martin K. <Mar...@St...> - 2005-03-04 00:32:14
|
Hi Juergen, Thanks for your reply. It made some points more clear. > <quote> > So in my oppinion the ApplicationContext should be placed in > org.springframework since beans, aop and context are only > exisiting to provide the functionality the ApplicationContext > needs (or better an implementation of the interface needed). > </quote> > > In fact, the beans and aop packages do not only exist to serve the > ApplicationContext. Spring is not a single system with a single entry > point: > In that respect, the Spring distribution is more similar to the JDK's > structure than it is to Hibernate's, for example. What I was about is the dependencies that the Spring framework draws. When I look on the composition model I noticed that the application context draws in most of the capabilities the bean package provides (Application context implements five diffrent interfaces /types). So those packages point their fingers to the man in the middle. That the bean package has some advantage when being used independently isn't something that I can not understand. Let me show you this: interface ApplicationContext extends: ListableBeanFactory -> beans (friendly) HierarchicalBeanFactory -> beans (friendly) MessageSource -> context (same) ApplicationEventPublisher -> context (same) ResourcePatternResolver -> core.io.support (friendly) One major gap are the ListableBeanFactory and the HierarchicalBeanFactory interfaces. Looking on the resulting ApplicationContex two special methods are imposed 1. getParent() : ApplicationContext 2. getParentFactory() : BeanFactory I think this indicates a mixed thinking. Parent and parent factory, can be somewhat diffrent but the domain should be clear. Maybe the application context should not pretend to be a bean factory first place (trade polymorphism for composition and therefore for responsibility) That is, what I was referring to. ApplicationContext solves the same tasks, like an ordinary bean factory do because it is(!) actually a bean factory. So the question goes, if application solves the same tasks a bean factory can and even some more, isn't it logical to think that a factory is a realisation of a feature of an application context? And if yes, wouldn't it mean that every time a user of the spring framework goes for a bean factory instead of a context, that the context is harder to use or misses some more key features? I understand that while implementing some of the features context/bean factory needs, it may provide some general purpose features, that may be usable on their own. But this general purpose features are no reason to not consider the beans package as a realisation of some of the tasks the application context has to deal with? The same thinking goes to the web context as well. All the association arrows point to the web context as being the spider in the web. > The beans package is completely independent and can > of course be used on its own, both at the BeanWrapper > level and at the BeanFactory level. The bean factory level is - in my thinking - the application context level. > Some people happily do either of the two, and don't care > about the context package (or any other Spring packages) at all. > > The beans package is also used internally by the JDBC support, > the validation package and other parts of Spring. No ApplicationContext > (or MessageSource etc) needed there, just low-level BeanWrapper > and/or BeanFactory functionality. Well I agree with that. But you can use the collections framework of the Java JDK outside of Java by just applying the described logic to a diffrent language. The collections framework is purpose driven. It exists to serve the Java language, but is also capable to serve other languages as well. > Quite a lot of people are using Spring's JDBC > support completely outside a Spring application > context, for example in custom DAOs or in custom EJBs. Well that is a point. But again I wouldn't see this as an argument against it. The JDBC support is part of the application context usage domain as well. It would justify to consider JDBC as a sub-project but not to be more important than the context. It is just an aspect of a special kind of applications (realise a persistance layer) > Only for applications that are fully architected on a Spring basis, an > ApplicationContext will play a central role. This is significantly > different > from a single-purpose tool such as Hibernate, where the > SessionFactory/Session combo plays a central role in all scenarios. I understand. But think about the Eclipse platform. The Eclipse folks at IBM build the SWT/JFace packages to serve the needs of the platform. But this support got so usefull that they made it a sub-project to be used independently, too. The fun part of it is that this swt and jface are still considered to mainly serve the platform's needs and that their independent usage is just a result of the overlappings of requirements from a diffrent target audience. > <quote> > For example, I am currently doing refactoring of > the DefaultXmlBeanDefinitionParser implementation. > > This is part of bean.factory.xml. In my thinking this is > wrong placement. The parser first of all should be > in a modul about parsers. But beside this you read > an application context definition file. Check out how > the dtd of spring is defined. All about beans. To > describe an application context you are referring to > the dtd. > </quote> > > Again, I tend to look at this from a different perspective: The > BeanFactory > stuff in the beans.factory package is the central part that deals with > bean > definitions. An ApplicationContext is "just" a higher-level facade for it, > adding auto-detection for special beans and additional services like a > MessageSource. The misplacing was also ment in form of refering it as xml package. XML is just a way to specifiy a factory. That's why I consider this a view or translation related task. You translate something into something more usable. This is what a parser mainly does. It converts form one language into another one. Thats why I would like to add this at least to a parser package. It is just a way to view things. But again I would consider this to be a context related issue, since by using a xml file this would also be understandable by an application context. So there is a replication of functionality here. You can read a context or a more special form (bean factory) from the same source, but you use diffrent features the framework provides. I don't like this duplication in responsibility. > Consequently, XML bean definition parsing does belong in > the beans.factory package, as it is "just" a special variant of > parsing bean definitions. XML bean definitions may be the > current main format for defining application contexts, but from > the framework point of view, it is just yet another bean definition > format and by no means central to all other parts of Spring. Thats why I don't like the beans module as it is currently shaped. Since this are exchanges of thoughts, there is no guarantee that we will reach a consensus at this topic. I guess this isn't also needed. I enjoy using the Spring framework because it is so more simplier than the EJB framework but I guess there is some room for improvements. Something just don't feel right and if I see the dependency graph, it just looks a bit too complicated for my experience. Never the less, thanks for developing the Spring framework, it saved me countless hours of work! (it still does...) Thanks and cheers, Martin (Kersten) PS: Thanks for your extense answer, I also wrote a more extense reply to honor your afford and your will to make me understand your position. I don't know if I could provide you some additional informations about my point of view. Maybe we reached a point where I have to provide some kind of proof for my claims which I can not deliver yet (but soon I will - in some months at least) |
|
From: Dmitriy K. <dko...@ru...> - 2005-02-23 13:32:09
|
Colin Sampaleanu wrote: > In fact, you can need cglib even without using the 'main' aop code, if > you use method injection in the core container... > > ...or using Hibernate :-) |
