I think a reference from a setup class to the converters like here is
not a problem. The bad part of the tangle
appears when for example DomConverter references the setup class likle
CorePackageScanResolver.
So to get rid of the tangles we have to work towards creating an API
that the implementations can use and avoid that implementations refer to
other implementations that they should not know about.
But that is hard work ... as Camel does not have a clean API right now.
Christian
Am 06.05.2011 11:02, schrieb Claus Ibsen:
Christian Schneider would not like this as the core type converters is
hardcoded, which means there would be package tangle ;)
As those hard coded type converters are in different packages.
public CorePackageScanClassResolver() {
converters.add(DomConverter.class);
converters.add(StaxConverter.class);
converters.add(StreamSourceConverter.class);
converters.add(XmlConverter.class);
converters.add(CamelConverter.class);
converters.add(CollectionConverter.class);
converters.add(IOConverter.class);
converters.add(NIOConverter.class);
converters.add(ObjectConverter.class);
converters.add(TimePatternConverter.class);
converters.add(StreamCacheConverter.class);
converters.add(BeanConverter.class);
converters.add(GenericFileConverter.class);
converters.add(FutureTypeConverter.class);
}
Likewise we could make camel-spring be able to add to those core type
converters, so we do not have to classpath scanning there as well.
This should cut down testing time as well.
Any thoughts?
--
Christian Schneider
http://www.liquid-reality.de
CXF and Camel Architect
SOPERA - The Application Integration Division of Talend
http://www.talend.com
