Provide a soap connector jar without the embedded dependencies

[GoogleCodeExporter]

While working on syncope to switch from spring webservices to cxf we found that 
there are problems when cxf is used in syncope as well as in the soap connector.

It seems like the two versions of cxf are not completely isolated. I asked Dan 
Kulp if it should be possible to run two versions of cxf at the same time. He 
answered that it probably does not work and might lead to a lot of problems,

So I think the easiest way to support the soap connector in an environment 
where cxf already runs would be to not embed the cxf dependencies. So the user 
would have to make sure himself that the connector finds the required libs but 
would not have two cxf versions at the same time.

As of course other people depend on the embedded depdendencies to work it might 
be best to have two separate releases of the soap connector. One with the 
depdendencies and one without.

Additionally the release without the dependencies could later be made OSGi 
compatible as in OSGi it would also be not advisable to embed cxf.

Original issue reported on code.google.com by cschneid...@gmail.com on 18 Dec 2012 at 12:00

[GoogleCodeExporter]

Original comment by chicchiricco on 18 Dec 2012 at 3:22

• Added labels: Type-Task, Bundle-SOAP
• Removed labels: Type-Defect

[GoogleCodeExporter]

This issue is linked to Syncope's [1].
As already reported there, I am absolutely not sure that providing a bundle 
without external dependencies inside is the right solution.

By definition, a ConnId bundle has everything it needs for running inside the 
bundle itself, so providing a bundle without dependencies would virtually break 
the ConnId SPI contract.

I would, instead, investigate more about the way how Syncope is configuring 
class loading for bundles [2] or maybe by empowering a Java connector server 
(as already planned for Syncope [3]).

Let's wait to see if [1] can get solved in a different way and keep this issue 
as the latest possibility if no better option will have been found.

[1] https://issues.apache.org/jira/browse/SYNCOPE-251
[2] https://code.google.com/p/connid/wiki/ConnectorBundles#Class_Loading
[3] https://issues.apache.org/jira/browse/SYNCOPE-137

Original comment by chicchiricco on 18 Dec 2012 at 3:31

[GoogleCodeExporter]

How long would you need to create a release without the dependencies in case we 
need it? As soon as we introduce the cxf dependencies on syncope trunk we need 
a solution to this problem. 

We need to introduce these cxf depdencies starting with our next iteration on 
8th of January. So I hope we find a solution till then.

Original comment by cschneid...@gmail.com on 18 Dec 2012 at 4:08

[GoogleCodeExporter]

Providing a second assembly (besides existing [1]) is really straightforward: I 
object that I see this as a mere workaround, far from the actual solution.

Is it possible for you to try first to investigate in other, more proper, 
directions before recurring to this?

[1] 
https://code.google.com/p/connid/source/browse/bundles/soap/trunk/connector/src/
assemble/connector.xml

Original comment by chicchiricco on 18 Dec 2012 at 4:11

[GoogleCodeExporter]

I will investigate if there is another solution. Just wanted to know how much 
time you need for the release so I know when the deadline is. 

Original comment by cschneid...@gmail.com on 18 Dec 2012 at 4:16

[GoogleCodeExporter]

You can even provide a patch ;-)

Original comment by chicchiricco on 18 Dec 2012 at 4:17

[GoogleCodeExporter]

Ok

Original comment by cschneid...@gmail.com on 18 Dec 2012 at 4:24

[GoogleCodeExporter]

As per the already referenced SYNCOPE-251, there is no need to provide such 
"non-compliant" bundle for making the Apache Syncope CXF migration work.

Original comment by chicchiricco on 26 Dec 2012 at 3:46

• Changed state: WontFix