Actually, I have found a way to do that in OSGi, so I will only change that if performances are really bad, but as bundles are only scanned once when resolved, it should not be too bad.
On 9/20/07, James Strachan <[EMAIL PROTECTED]> wrote: > +1 - sounds fine to me. > > IIRC the current class=FooComponent properties file can also support > arbitrary property configuration too. So maybe > > scheme.class= FooComponent > > then > > scheme.foo = bar > > could be retained for configuring properties on the component. > > e.g. you could have a single class used for multiple schemes with some > minor configuration changes... > > direct.class = MyComponent > direct.name = Direct > > file.class = MyComponent > file.name = File > > > On 9/20/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > Currently the component discovery mechanism relies on a file inside > > META-INF/services/org/apache/camel/components/xxx > > where xxx is the uri protocol used by the component. > > This file is a properties file containing: > > class=xxx > > > > This kind of discovery makes optimization kinda hard because there is > > no simple way to know the components handled by a jar easily unless > > going through all the entries in the jar. > > > > Hence, I'd like to change the mechanism to have a single file named > > META-INF/services/org/apache/camel/components > > which would contain several entries > > pojo=org.apache.camel.components.pojo.PojoComponent > > direct=org.apache.camel.components.direct.DirectComponent > > > > This would be very usefull in OSGi instead of having to scan all the > > bundles each time a component has to be created. > > Thoughts ? > > > > > > -- > > Cheers, > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > > > > -- > James > ------- > http://macstrac.blogspot.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
