CXF endpoint problems on remote installation

[markk]

I have built a small demo with CXF and camel.  When I run it locally the CXF browser at http://localhost:8181/cxf properly shows the endpoint as:

-

---

Endpoint address: http://127.0.0.1:8181/cxf/PersonService

WSDL : PersonService

Target namespace: http://testwsosgi.examples.foo.com/

But, when I transfer the jar to the remote server, the CXF browser displays the info as:

-

---

Endpoint address: http://10.40.40.40:8181/cxfhttp://localhost:8181/cxf/PersonService

WSDL : PersonService

Target namespace: http://testwsosgi.examples.foo.com/

The WSDL link leads to the incorrect place and I get an HTML page error instead of a WSDL file.  What could possibly cause this?  Do I have to build all deployable code on the destination server?

Update: using "links" to browse the cxf info page on the remote server with "http://localhost:8181/" gives the properly formatted URL.  So, it's only accessing the cxf page from another host.

Edited by: markk on Oct 17, 2011 11:25 PM

[ffang]

Hi,

I'm not sure I understand your question here, is it a problem to access the endpoint from local host or remote host?

Anyway, generally you should specify your endpint like 0.0.0.0:port but not the localhost:port, the 0.0.0.0 pattern can bind all available network interface on the machine where you deploy the bundle.

Freeman

[markk]

I'm not sure where I would use 0.0.0.0 or localhost.  The endpoint is defined like this:

    <jaxws:endpoint id="HTTPEndpoint"

        implementor="com.foo.examples.testwsosgi.PersonImpl"

        address="/PersonService"/>

This is exactly like the cxf-osgi demo which defines their endpoint like this:

    <jaxws:endpoint id="helloWorld"

                    implementor="org.apache.servicemix.examples.cxf.HelloWorldImpl"

                    address="/HelloWorld"/>

The cxf-osgi demo shows up properly in the cxf list.

[ffang]

Hi,

Do you mean the cxf-osgi example shows up properly in the cxf list even on the remote host but your bundle doesn't?

Freeman

[markk]

Yes, cxf-osgi listing was fine on the remote server yesterday, now it is bad.  I have found that this problem exists on both my local machine and the remote deployment machine.

Using http://127.0.0.1/cxf/

results in Endpoint address:

http://127.0.0.1:8181/cxf/HelloWorld

http://127.0.0.1:8181/cxfhttp://localhost:8181/cxf/PersonService

Using http://localhost/cxf/

results in Endpoint address:

http://localhost:8181/cxfhttp://127.0.0.1:8181/cxf/HelloWorld

http://localhost:8181/cxf/PersonService

The results are definitely changing.  I just restarted the remote server and the 10.40.40.40/cxf/ listing is back to normal and my localhost/127.0.0.1 is back to normal for a few page refreshes, then it starts messing up again.

Edited by: markk on Oct 18, 2011 2:13 PM

Edited by: markk on Oct 18, 2011 2:20 PM

[ffang]

Hi,

Sorry I'm still a little bit confused.

Let's say you only install the cxf-osgi example from kit, you can see the problem?

Or after you install your bundle(so two cxf endpoint now) you can see the problem?

Which exact FUSE ESB version you're using?

Freeman

[markk]

Yes, the problem exists with only the cxf-osgi example.

features:install examples-cxf-osgi

http://localhost:8181/cxf/

Click the link that shows you the WSDL file

click back

enter the URL:

http://127.0.0.1:8181/cxf/

click back (so you are now at localhost:8181)

refresh

Eventually your endpoint will be messed up.

Endpoint address: http://127.0.0.7:8181/cxfhttp://localhost:8181/cxf/HelloWorld

I'm not sure if this affects any internal CXF or Camel components, but I did see some log errors about unexpected HTML tags in my WSDL files when trying to post to a self made SOAP service.

Version is the one from the website: apache-servicemix-4.4.1-fuse-00-08

(corrected: features:install cxf-osgi  to features:install examples-cxf-osgi)

Edited by: markk on Oct 19, 2011 5:00 PM

[ffang]

Hi,

Thanks for the detailed description.

Yeah, I can reproduce it, will work on a fix.

FYI, even the "CXF- Service list" page messed up, it won't affect the webservice real function, you can still invoke the service there.

Again, thanks for pointing out this issue.

Freeman