Am 10.12.2012 19:05, schrieb Christian Schneider:
One possibility is to update the soap connector to the current cxf
version. This will probably work until we upgrade the cxf version again.
Another possibility would be to remove the libs from the connector and
rely on people adding the libs in another way. As far as I understood
the idea of the connectors is that they simply work without additional
libs so I am not sure if this is an option. I also do not yet understand
how the classloading in the connectors works. Can someone explain this?
I did investigate a little further on this topic and here is my current
problem analyses:
1. org.connid.bundles.soap has a normal maven dependency to CXF [1],
which is absolutely fine and not the root cause of our issue here.
2. Syncope uses maven-dependency-plugin to download ConnID Bundles and
place them into a specific folder. The problem is excactly here, because
"copy" goal of maven-dependency-plugin does not support any exclusions
of transetive dependencies and thus includes all dependencies into a lib
folder of our ConnID Bundle artefacts.
3. Syncope and SOAP ConnID Bundle both use the same CXF Default Bus. The
CXF Bus is usually instantiated with Syncope CXF Dependencies, and as
soon as the SOAP ConnID Bundle is used we run into Class Cast
exceptions, because our CXF Bus has a different Classloader as the CXF
components instantiated by the SOAP ConnID Bundle.
From my point of view, there could be two solutions for this problem.
1. Find a way to exclude CXF dependencies from SOAP ConnID Bundle (a
different maven plugin must be used)
2. Syncope does not use the default CXF Bus, but instead creates it's
own (none default) Bus
I expect the first solution to be the best choice (if we can find a
maven plugin matching our needs), because the same classloading issues
could appear in an OSGi environment where other bundles also use CXF.
WDYT?
Best regards
Jan
[1]
http://connid.googlecode.com/svn-history/r368/bundles/soap/trunk/connector/pom.xml
