Hi,
My comment inline
On 2010-10-23, at 下午1:23, Kurt Westerfeld wrote:
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.
First of all, I hope you didn't miss my previous answer about how to
use cxf bus in smx-cxf-bc with smx4
About using cxf bus in smx-cxf component, take a look at discussion in
SMXCOMP-688[2]
[2]https://issues.apache.org/activemq/browse/SMXCOMP-688
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.
All cxf related jars(including cx-core you mentioned here) now are
merged into Apache CXF Bundle jar, and it should be wired up to the
servicemix-cxf-bc JBI component already, otherwise servicemix-cxf-bc
JBI component won't get started correctly. :-)
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.
As this jar already merged into Apache CXF Bundle jar, which by
default would be installed when you start smx4.
When you deploy JBI packaging artifacts into SMX4, there's a JBI
deployer come in and change your SA/SUs into bundles, actually in SMX4
which basically is OSGi container, every thing(JBI artifacts, spring
file, blueprint file, war) would be transform into OSGi bundles
underlying, but this process is automatically and so you're not aware
of it.
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.
In SMX4, log4j api and impl class should be provided by pax-logging-
api-1.5.3.jar and pax-logging-service-1.5.3.jar(which is installed by
default when you start smx4), so you needn't install extra log4j jar.
You mean log4j in your SA doesn't work anymore when run with 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.
And IMHO, the "Unable to locate Spring NamespaceHandler " is another
issue, Guillaume have written a very good blog to explain this [3],
you may need take a look at it.
[3]http://gnodet.blogspot.com/2010_03_01_archive.html
That said the "Unable to locate Spring NamespaceHandler" issue isn't
come from the library missing, it's actually from the defect that
spring-dm in OSGi container.
If you're using JBI packaging, the work around for this issue I can
come up with is that in your SU pom.xml, explicitly add cxf-core
dependency(or other cxf-* jar dependency if you need other Spring
NamespaceHandlers which in other cxf module).
Btw, besides JBI packaging, in SMX4 we also provide OSGi packaging for
JBI artifacts. The difference between OSGi packaging and JBI packaging
from my perspective isn't big, so you should easily transform your SA/
SUs into it if you want, and OSGi packaging IMHO is more natural when
deployed into OSGi container. Actually we have a cxf-wsdl-first-osgi-
package example shipped with smx4 kit, just in case you didn't look at
it.
So for the "Unable to locate Spring NamespaceHandler ", if you're
using OSGi packaging, then the solution is adding proper Import-
Packge, it's better following OSGi rule.
Hope this helps
Freeman
Does that make sense?
--
Freeman Fang
------------------------
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Open Source SOA: http://fusesource.com
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
