Re: [Springframework-developer] Re: feature request

[Guillaume P. <gpo...@sy...>]

You can also use

<bean class="java.util.LinkedList">
  <constructor-arg>
    <list/>
  </constructor-arg>
</bean>

I find that syntax to be much less verbose than to use a 
ListFactoryBean.  Of course, a type attribute would be even less verbose 
than those two options.

Guillaume


Juergen Hoeller wrote:

> Well, note the kind of default collection implementations that Spring 
> uses: It prefers ordered Maps and Sets if available, which also means 
> that source Maps specified on the FactoryBeans will preserve their 
> order. You don't need to do anything other than run on JDK 1.4+ (or 
> with Commons Collections on the classpath) to get this behavior for 
> standard <map> / <set> / <list> tags. No need to specify any special 
> collection implementations for that.
>  
> For the LinkedList case (which I suppose is rather rare), why not 
> simply use ListFactoryBean with targetListClass=java.util.LinkedList?
>  
> Juergen
>  
>
> ------------------------------------------------------------------------
> *From:* spr...@li... 
> [mailto:spr...@li...] *On 
> Behalf Of *Crater, Jon (EDS)
> *Sent:* Tuesday, July 19, 2005 8:26 PM
> *To:* spr...@li...
> *Subject:* [Springframework-developer] Re: feature request
>
> Thanks for your reply.  I wasn't aware of the various factory bean 
> classes you mentioned, so this thread has already been useful.  What I 
> really need, though, is the ability to override the default 
> Map/List/Set implementation class on an as-needed basis.  So, for 
> example, one of the properties of one of my Spring-managed beans is a 
> Map that needs to retain the order in which it's configured, so I'd 
> like to inject an instance of SequencedHashMap, but I don't have a way 
> to do that without extensions.  Using a MapFactoryBean won't help me 
> in this case because the order will not be preserved, as the source 
> map is required to have been created.
>  
> In another case, I may need to inject an instance of LinkedList, etc.  
> So, I don't want to override every single one, just the ones where my 
> needs diverge from what is built-in.  If a "type" attribute isn't 
> justified, is there another way?
>  ________________________________ 
>
> Actually, this can already be achieved through using MapFactoryBean,
> ListFactoryBean and SetFactoryBean, respectively - passing a source <map> /
> <list> / <set> in and specifying the desired "targetMapClass" /
> "targetListClass" / "targetSetClass".
> 
> I don"t see much advantage in a "type" attribute on the corresponding tags
> directly, actually. It"s not that common to override the collection
> implementations on a per-collection basis to justify a special shortcut for
> this, IMO.
> 
> Or are you trying to centrally override the default Map / List / Set
> implementations that Spring uses for <map> / <list> / <set>? Specifying
> those implementation classes _once_ rather than repeating them for every
> single collection definition?
> 
> Juergen
>  
> 
> ________________________________
> 
> From: springframework-developer-admin@li...
> [mailto:springframework-developer-admin@li...] On Behalf Of
> Crater, Jon (EDS)
> Sent: Tuesday, July 19, 2005 5:34 PM
> To: springframework-developer@li...
> Subject: [Springframework-developer] feature request
> 
> 
> i currently have a need to customize the implementation classes created when
> spring parses the definitions for properties containing <map>, <list>, etc.
> elements.  currently i have to subclass AbstractXmlApplicationContext and
> override initBeanDefinitionReader(XmlBeanDefinitionReader r) to call
> setParserClass(Class c) with my own subclass of BeanDefinitionParser, which
> in turn overrides parseMapElement, etc.  i was hoping that future releases
> of spring could support this situation via out of the box configuration.  it
> seems like it would be fairly straightforward to respect a "type" attribute
> of the <map> and <list> (and any other) elements to support customization of
> the Map/Collection implementation without requiring custom extensions.
>  
> if there"s sufficient interest, i"d be happy to contribute.
>  
> jon
>