Currently, both namespaces would be available as OSGi services. This should mean that the namespace that has been registered first will be used (as both should be compatible with the blueprint bundle I suppose).
In this very case and in the current state of blueprint-spring, I think the spring one will be registered first, because it's registered when the BundleEvent.STARTING event is fired, while the cxf blueprint namespace will be registered just after by the activator. Do you foresee any problem with using one or the other namespace ? I could also add some tricks to make sure we select the "native" blueprint namespace in such cases. Guillaume 2015-11-23 18:35 GMT+01:00 Daniel Kulp <[email protected]>: > > Guillaume, > > Question: CXF uses the same namespace in some cases for both Blueprint > and Spring. Any idea on how this would handle that? Would it invoke the > Spring parser or the Blueprint parser? > > Dan > > > > > On Nov 23, 2015, at 9:13 AM, Guillaume Nodet <[email protected]> wrote: > > > > Yeah, it's not really needed. > > That's just what fileinstall does in karaf when dropping a single > blueprint > > xml in the deploy folder, and that's what I used during initial testing. > > For a real bundle, that's definitely not needed. > > I've committed a real integration test which demonstrates a better > scenario > > (which does not include the dynamic imports). > > > > Guillaume > > > > 2015-11-23 15:02 GMT+01:00 David Bosschaert <[email protected] > >: > > > >> Hi Guillaume, > >> > >> On 23 November 2015 at 04:03, Guillaume Nodet <[email protected]> > wrote: > >>> Good point, I haven't really tested this part specifically. > >>> I've used the spring deployer to deploy my test xml in karaf, so afaik, > >> it > >>> uses a dynamicimport-package=*, so I'm not sure about the exact > behaviour > >>> yet. > >> > >> Can we avoid dynamicimport-package=* somehow? Using that you really > >> throw all of the OSGi modularity out of the window. > >> dynamicimport-package=* should be avoided at all times IMHO... > >> > >> David > >> > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > >
