Re: Remote services and Web Applications

[zoe slattery]

Hi Sergey - thanks - but that isn't the problem :-/. Using that port is 
fine but it's still the case that whatever is in CXF grabs port 8080 at 
the http service port.

I think there;s a property available there for ws services where you can
specify which port to listen upon,
probably "org.apache.cxf.ws.port"
cheers, Sergey

On Wed, Oct 27, 2010 at 2:28 PM, zoe slattery<zoe.slatt...@gmail.com>wrote:

Hi - I'm trying to use DOSGi for a remote service, the client side of my
application has a web bundle and pre-reqs the following:

pax-web-extender-war-0.7.2.jar
pax-web-jetty-bundle-0.7.2.jar
pax-web-jsp-0.7.2.jar

As part of the single bundle distribution I think you include:
org.ops4j.pax.web.service_0.5.1

So when I use the single bundle distribution I have two conflicting things
trying to use port 8080. After some hacking around I think I can use the
multiple bundle distribution and replace org.ops4j.pax.web.service_0.5.1
with the three pax web bundles and geronimo-servlet_3.0_spec-1.0.jar.

However there is another problem, in the version of CXF that I'm using
(revision 1027953) one of the cxf-dosgi-ri-dsw-cxf_1.3.0.SNAPSHOT bundle
won't start and gives the following error:

osgi>  start 36
org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Package uses conflict: Import-Package: org.apache.cxf;
version="2.2.0"
    at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
    at
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
    at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:309)
    at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280)
    at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:272)
    at
org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:253)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at
org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:155)
    at
org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:303)
    at
org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:288)
    at
org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:224)
    at java.lang.Thread.run(Thread.java:637)

So - questions:

1) Does the approach to dealing with the port 8080 conflict seem OK?
2) Any idea how to fix the issue with cxf-dosgi-ri-dsw-cxf_1.3.0.SNAPSHOT -
or - do I even need to? Can I just exclude it?

Zoe