Freeman, thanks a lot for responding to the issue....and apologies in advance for this lengthy email. I hope my issue is clear by the end of it. :-)
You wrote: > If you're using JBI pakcaging, then there's no big difference between > SMX3 and SMX4, you can take a look at cxf-wsdl-fisrt example we > shipped with smx4 kit, it's pretty much same as it's counterpart in > smx3. :-) That's an example I definitely know, and we used this and other servicemix-cxf* examples to generate the JBI artifacts that run on SMX3. The issue I'm having is, the core libraries provided with the servicemix-cxf-bc component do not have all of the cxf "core", including the [http://cxf.apache.org/core] mapping we use to configure the bus. The servicemix-cxf-bc component has a feature to configure the bus from an external spring mapping file, used with the busCfg= attribute: <cxfbc:consumer wsdl="classpath:Some.wsdl" locationURI="http://${HttpDefaultHost}:${HttpDefaultPort}/SomeEndPoint"; targetService="somens:SomeService" targetInterface="somens:SomeService" busCfg="/identity-server-bus-beans.xml" /> This busCfg= attribute is documented in the servicemix-cxf-bc.xsd as "the location of the CXF configuration file used to configure the CXF bus. This allows you to configure features like WS-RM and JMS runtime behavior." We use the cxf: prefix to create a bus, configure it how we want it, and it is then used as the cxf bus for the endpoint (in this case, a consumer of a servicemix-cxf-se component). I got the idea on how to do this by looking over servicemix 3 source code unit tests (see: http://svn.apache.org/repos/asf/servicemix/components/bindings/servicemix-cxf-bc/tags/servicemix-cxf-bc-2010.01/src/test/resources/org/apache/servicemix/cxfbc/provider/xbean_provider_with_bus_logger_feature.xml ). We adapted this use-case to allow our interceptor configuration for all of our endpoints to be centralized on one set of spring configuration files--which is quite nice. In looking over the libraries provided in the servicemix-cxf-bc component on SMX3, the cxf-rt-core-2.2.6.jar library is provided to provide this cxf bus configuration capability. This jar is provided in the form of a OSGi feature bundle, but this bundle does not seem to be connected to the servicemix-cxf-bc component when using SMX4. Doing a little digging, it looks like the osgi bundle "Apache CXF Bundle Jar (2.2.10.fuse-00-00)", is not wired up to the servicemix-cxf-bc JBI component on SMX4. I don't know if this is intentional or oversight. Another piece of evidence here is that the servicemix-cxf-bc META-INF/DEPENDENCIES file indicates: - Apache CXF Runtime Core (http://cxf.apache.org) org.apache.cxf:cxf-rt-core:jar:2.2.10-fuse-00-00 License: The Apache Software License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt) Which is the exact jar I would expect to provide the feature we're finding missing. So, is this a bug or is there a feature or bundle I must enable/install within servicemix to cause this connection to happen? I am admittedly a newbie for OSGi, but in this case we're not tackling OSGi yet, we're just trying to run our SMX3 SAs on SMX4. On the topic of logging, it is implied by the URL (http://wiki.ops4j.org/display/paxlogging/Pax+Logging) that Log4J API as well as back-end should be supported. I think it's probably a gray area that in our case, we're using JBI packaging, which doesn't make this same connection. Again, on SMX3 the java code we deploy does not provide a copy of log4j (which would be duplicated all over the place as well as duplicate of the SMX3 core libraries), so while not a big deal, the expectation I have is that this same code would deploy and run on SMX4. I see these two issues as one-and-the-same, namely, that the core libraries that a SMX3 JBI component expects are not wired up on SMX4. I know that SMX4 has these libraries installed--they just aren't connected to the JBI deployment infrastructure. Does that make sense?
