Hi Steve and all, in fact our problem with HP Endpoint today was not with the "/". We were using the correct URL. When we tried again after the meeting it worked and 45% of the tests we had implemented have passed. Before that, the exception we had was a connection time out that I don't know why it happened. Maybe the server was being updated, I don't know. Ayla Steve Loughran wrote:
Milojicic, Dejan S (HP Labs) wrote:
Attendees: Ayla, Guilherme, Flavio, and Dejan. Jun in Japan at GGF, Stuart and Steve were missing.
sorry for missing this, I was distracted with other things (Jena User Conference, logging) and assumed that with GGF on the conf wasnt going through.
The important piece missing was / at the end of the URL. This was missing in Steve's implementation, then Steve pointed this out, after that Satish was able to run test property etc. Some of the basic tests were otherwise failing.
Can I take this opportunity to resend the original announcement of the endpoint. Please note that not only did I include a trailing slash at the end of the URL, I -
1. warned callers to leave it in "the servlet is unforgiving" 2. mentioned that if you point your browsers at the URL, you get a hello message, thus giving everyone an easy test for the URL being valid.
I will happily accept all responsibility from not being able to implement SOAP, WSA, WSRF and WSDM correctly, but not for omitting to give people the correct URL to my endpoint. That I did do correctly.
Steve.
-------- Original Message -------- Subject: [cddlm] A new endpoint! Date: Fri, 28 Apr 2006 21:51:03 +0100 From: Steve Loughran <steve_loughran@hpl.hp.com> To: 'cddlm-wg@ggf.org' <cddlm-wg@ggf.org>
I am pleased to announce the availability of the HP CDDLM endpoint, public beta release
The URL for the portal is :- http://deployapi.iseran.com:8080/alpine/portal/
It is visible through the (three) firewalls, and has been tested remotely. A GET will return a short note confirming the endpoint's existence. Make sure you have the trailing / as the servlet is unforgiving. If the connection is refused, the endpoint is probably down.
Notes -this is a new SOAP stack with its own WSA and WSRF implementation. It only implements the subset we need, and those are not adequately interop tested. please mail your results to the group or direct to me.
-deployment is not working. I will find out why next week, but will then have to actually implement security on the endpoint before deploying a fixed version
-System:addFile is not finished, and when it is it will initially only support inline (base 64) content, not attachments. MTOM Is not on the todo list.
-WS-Notification has not even begun; I dont even implement the properties that list supported topics. Frankly, I'm not overwhelmingly motivated to implement WS-N.
-It's hosted on a laptop on the WLAN somewhere in my house. It needs more memory. Please be gentle with it :)
Monday in the UK is a holiday (May 1st, Socialist Unity Day!), so there is no likelihood of any changes to the stack being made before Tuesday. I'll field basic interop problems first (namespaces, WSA headers, SOAPAction), then worry about
-better fault reporting -automating a checkout, rebuild and redeploy early every morning.
-testing Alpine's WSA impl. against the .NET 2.0 endpoints
-making the server-side logs public by logging to log4j's HTML logger and serving those pages up somewhere.
-have the server host the deployapi tests for our client and run them against all public stacks, again serving the data up for browsing.
Clearly not all of these can be achieved in the finite time before GGF17, but we should be able to make progress along both the interop and functionality axes. Now if you'll excuse me, I have an extended weekend to attend to.
Steve