[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Eureka!
Hi David, yes I changed it today morning.
But I give it a new try in a few minutes just to be really sure.
Could be that you restarted your JVM after I did the reconnect, I don't
know.
Concerning the namespace params you're right. Our implementation currently
needs to do this because of the way the JSR ref impl works currently. We
need to wait for the JSR folks here to do that change.
So this is definitly an open issue but needs to be handled on our side.
Concerning the IBM producer: why not, let's give it a try. Hope we don't
have to many user's because it's a small machine and the persistence is
based on xml files :-)
We could talk about that in today's call.
Meanwhile I reconnected again: we are now at: 80.138.186.177
I checked your portal and it works!
Btw. could you report today about that problem and your circumvention, so
we can pass it to the primer editor's?
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/18/2003 01:17 |
| | PM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Richard Jacob/Germany/IBM@IBMDE |
| cc: wsrp-interop@lists.oasis-open.org |
| Subject: Re: [wsrp-interop] Eureka! |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
That's good news! So you definitely changed the IP address from yesterday?
It seems to be working for me too.
About the namespaced form parameters - is this behaviour something the spec
dictates? The last time we consulted the spec on this, we believed it meant
that the consumer would handle all namespacing of url parameters and form
fields transparently, and the producer wouldn't have to add its own prefix.
By the way, how would you feel about us exposing the IBM producer as a
pre-registered producer to all users?
Thanks
David
Richard Jacob wrote:
Hi David,
seems to work now?
I was able to put IBM's portlets on your portal and access them.
Will check the communication log.
I encountered a problem sending the form data.
Seems to be the namespace token issue here, will check that.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Richard |
| | Jacob/Germany/IBM|
| | @IBMDE |
| | |
| | 06/18/2003 10:41 |
| | AM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: David Ward <david.ward@oracle.com>
|
| cc: wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop] Eureka!
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
ok done,
we are now at: 80.138.191.123, internet DNS servers checked, resolve
correctly
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/17/2003 08:23 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard Jacob/Germany/IBM@IBMDE
|
| cc: wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop] Eureka!
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Either way, our Java client was still timing out.
I'm not sure I configured it right last time. This time I've set the
System
property as a JVM command line option, so if it doesn't work this
time,
something somewhere else in our system is still caching the IP
address.
I've checked the most likely source code and still can't find the
culprit.
So could you do another random reconnect tomorrow and I'll see if it
recovers this time.
Thanks
Dave
Richard Jacob wrote:
oops, sorry.
Seems that all the monitor instances crashed somehow (perhaps I
need
a
watchdog here)
Now they are up again.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/17/2003 06:42 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard Jacob/Germany/IBM@IBMDE
|
| cc: wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop] Eureka!
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Port 8083 doesn't seem to be up!
Richard Jacob wrote:
done,
we are now on: 80.138.161.43, nameservers are adjusted
accordingly
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/17/2003 05:29 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard Jacob/Germany/IBM@IBMDE
|
| cc: wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop] Eureka!
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Thanks again. In the interests of interoperability, could
you
try
forcing a
reconnect now, and we'll see whether our JVM recovers or
not!
I assume our registration handle will still be valid (but
the
session
won't).
Dave
Richard Jacob wrote:
So we had two good guesses today :-)
In general dyndns is simple: you have one
registered
hostname.domain.
Everytime we get a new IP address associated we ask
the
dyndns
server
(which is an implementation of dynamicDNS) to
update our
IP
Address,
i.e.
the A record in the DNS database (we could also do
it for
MX
records
and so
on).
Why we need this is because we have a standard
internet
provider over
adsl
which disconnects us after being online for 24
hours,
thanks to
some
linux
scripts :-) we discover that and reconnect
immediatly -
that's
the
time
when we get a new address assigned.
I wonder that the JDK implementation doesn't handle
the
standard way
of
expiration handling in the domain name system. At
dyndns
we
have a
very
short expiry set on our records so that secondary
and
caching
name
servers
(and resolvers) drop that record and retrieve it
again
from the
authoritative DNS of the dyndns.org domain.
I can force a disconnect/reconnect if you want to
test
this
now, just
let
me know...
This is a good point for the primer again, I think!
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward |
| | <david.ward@oracl|
| | e.com> |
| | |
| | 06/17/2003 04:21 |
| | PM |
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: David Ward
<david.ward@oracle.com>
|
| cc: Richard
Jacob/Germany/IBM@IBMDE,
wsrp-interop@lists.oasis-open.org
|
| Subject: [wsrp-interop] Eureka!
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
The problem was that the java.net.InetAddress class
by
default
caches
IP
addresses forever once it has resolved them once.
With a
dynamic name
like
wsrp.dyndns.org, this was bound to cause problems -
I
gather
that
your
server reassociates itself with a new IP address
every so
often.
(Don't
know exactly how dyndns works!)
If we were running on JDK 1.4, it appears we would
be
able to
control
the
"time to live" for cached IP addresses through a
security
policy.
However,
it seems that the 'private' sun.net.inetaddr.ttl
System
property
mentioned
here also has the same effect on JDK 1.3.
I have restarted our servlet container JVM with the
sun.net.inetaddr.ttl
System property set to 120 (2 minutes). So far, the
producer
seems to
be
running fine on portalstandards.oracle.com. We'll
just
need to
wait
and see
whether it remains so when you next acquire a new
IP
address!
I don't know whether it would be worthwhile
including
this
useful gem
of
information in any of the WSRP literature - if you
want
your
Java
consumer
to work with producers with dynamic IP addresses,
be
aware of
these
settings.
Thanks
Dave
David Ward wrote:
Hi Richard
Thanks for investigating this. I've just
realised
how
cool the
WS-I
testing tool is (the log file looked great
once I
installed all
the
XSL). I'll try to look into getting it
installed on
our
environment.
If you saw my previous message, you'll know
that
your
theory
was
correct, and our proxy was the source of the
problems we
were
having
when the HTTP 1.0 Keep-Alive header was sent.
It's
only
our
runtime
component that uses connection persistence
(for the
initCookie
/
getMarkup / performBlockingAction) calls, and
it's
only
in our
internal testing environment where we need to
use a
proxy
for
this
component. In the portalstandards.oracle.com
environment,
these
calls
do not need to be proxied.
The successful calls you have in your log
file
where the
connection
actually was persisted were made from the
portalstandards
environment. Here we are experiencing a
different
problem
- the
calls
only work when we register with an IP address
rather than
a
domain
name. This is weird, because I can ping and
telnet
to the
domain name
from the same machine with no problems. Any
ideas?
Thanks again
Dave
Richard Jacob wrote:
Hi David,
what you state concerning HTTP
keep-alive is
correct.
I'll try
to summerize
and reword to check if we have the same
understanding:
HTTP 1.0 is by default request/response
oriented
without
keeping the
connection open, thus every new request
opens
a new
socket and
closes this
after the resonse is received.
To keep the connection open among the
request/response
messages, the HTTP
1.0 client sends a connection:
keep-alive
header.
If the
server
supports
this it send a connection: keep-alive
in the
response to
indicate that the
connection is not closed and can be
reused.
HTTP 1.1 remains the connection open by
default.
The
connection: keep-alive
is nearly meaningless in HTTP 1.1.
If the server wants to close the
connection
it
sends
connection: close in
its response. If it doesn't do so, the
connection
is kept
open.
I checked the log files which monitored
the
conversation
between our
producer and your consumer and between
our
producer
and
Citrix's consumer
(thanks Andre for driving that test).
See attached files, 8082 is Citrix,
8083 is
Oracle.
(See attached file: log8082.xml)(See
attached
file:
log8083.xml)
In Citrix's case the keep-alive seem to
work.
Andre's
messages
start with
message 13, which is conversation 12.
As you
can
see all
the
request/response up to message 66 are
in the
same
conversation,
i.e.
connection.
67 starts a new conversation (maybe
because
the
client or
server decided to
close the connection in between).
In Oracle's case we see a lot of
different
connections
for each
request/response.
But interestingly messages 135-138 and
141-144
share the
same
connection.
Looking at 1-134 it seems that you use
a
proxy in
between
for
the
conversation, see header:
Via: 1.1 inet-nc02 (NetCache
NetApp/5.3.1R3)
In 135 you are using a direct
connection (no
via:
header).
That's a guess but maybe the proxy in
between
doesn't
support
keep-alive?
or is a 1.0 server?
Currently I have no idea why the
connection
is
closed
after 138
and
reopened for 139/140 and then again for
141...
Mit freundlichen Gruessen / best
regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server
Development
Phone: ++49 7031 16-3469 - Fax: ++49
7031
16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward
|
| |
<david.ward@oracl|
| | e.com>
|
| |
|
| | 06/16/2003 10:12
|
| | PM
|
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard
Jacob/Germany/IBM@IBMDE
|
| cc:
wsrp-interop@lists.oasis-open.org
|
| Subject: Re: [wsrp-interop]
Verify
interoperability
with Oracle Portal
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Richard
I am attaching the trace I got from a
TCP
tunnel
when our
Portal tries to
make consecutive initCookie and
getMarkup
requests
through the
same pooled
TCP connection. After further
investigation,
I
found that
the
"Keep-Alive"
value we send in the Connection header
of the
first
request is
actually
HTTP 1.0 semantics that can be ignored
by an
HTTP
1.1
server.
That's why it
doesn't appear in the second request.
An HTTP
1.1
server
would
return
Connection: close if it doesn't want
the
connection
to be
kept
open, since
the default is that the connection is
kept
alive.
An HTTP
1.0
server would
set the Keep-Alive header on the
response if
it
wanted
the
connection to be
kept open. Because we get an HTTP 1.1
response with
no
Connection close
header, our client assumes it can keep
the
connection
open and
send another
request on it, but this doesn't seem to
be
working.
We are using the same HTTPClient
library we
have
relied
on for
years (not
that that means it might not have
bugs!). You
can
force
your
JVM to use it
instead of the regular JDK
HttpURLConnection
by
setting
the
java.protocol.handler.pkgs system
property to
HTTPClient.
Thanks
Dave
David Ward wrote:
Hi David, thanks.
1. yes we have this namespacing
issue
still
open
due to
the JSR168
container reference
implementation.
Once this is changed on the
container
side we
can
skip
the
namespacing
here.
2. strange, we tested with both
AXIS
HTTP1.0
-> no
keep
alive and
with
.NETs HTTP1.1 and keep alive set.
Citrix's consumer also sets the
keep-alive
flag.
Andre, can you confirm please,
and
rerun your
consumer
against our
producer
over the monitoring port (8082).
David could you also try to
connect via
the
monitoring
port 8083,
please.
Maybe we discover something.
I'll attach one WSI-monitor file
showing a
conversation
between
Citrix and
IBM, here the keep alive seem to
work.
You
should
have
the xsl files
(from
the WS-I monitor) placed in the
directory
"../xsl"
relative to your
log
file directory to generate a
user-friedly
output.
(See attached file:
log8082.xml.030606150200.xml)(See
attached file:
assertions.xsl)(See attached
file:
common.xsl)(See
attached file:
log.xsl)
(See attached file: report.xsl)
Mit freundlichen Gruessen / best
regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal
Server
Development
Phone: ++49 7031 16-3469 - Fax:
++49
7031
16-4888
Email:
mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David Ward
|
| |
<david.ward@oracl|
| | e.com>
|
| |
|
| | 06/16/2003
11:37
|
| | AM
|
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Richard
Jacob/Germany/IBM@IBMDE
|
| cc:
wsrp-interop@lists.oasis-open.org
|
| Subject: Re:
[wsrp-interop]
Verify
interoperability with
Oracle Portal |
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
Thanks
I have altered our WSDL to
reference
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl
in the import, and will make this
fix
available
when we
next patch
our
site!
We got the IBM portlet
displaying, but
there's a
few
glitches I want
to
talk about. I'll investigate
further as
soon
as I
get the
chance,
but:
The portlet seems to be
namespacing the
input
fields in its
form. Is
this required?
The producer can't seem to
cope
with
HTTP 1.1
keep
alive
behaviour -
we can only register the
producer
when
we
turn off
connection
pooling
Regards
David
Richard Jacob wrote:
Hi David,
there is an absolut
location for
the
wsdl.
You can find them here:
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_types.xsd
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_interfaces.wsdl
http://www.oasis-open.org/committees/wsrp/specifications/version1/wsrp_v1_bindings.wsdl
See chapter 14 of the
spec or
the
wsrp
group's
home page.
Mit freundlichen Gruessen /
best
regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal
Server
Development
Phone: ++49 7031 16-3469 -
Fax:
++49
7031
16-4888
Email:
mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | David
Ward
|
| |
<david.ward@oracl|
| |
e.com>
|
| |
|
| |
06/12/2003
02:21
|
| | PM
|
|---------+---------------------------->
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Peter
Fischer3/Germany/IBM@IBMDE
|
| cc: Michael
Freedman
<Michael.Freedman@oracle.com>,
wsrp-interop
<wsrp-interop@lists.oasis-open.org>
|
| Subject: Re:
[wsrp-interop]
Verify
interoperability
with
Oracle Portal
|
>
--------------------------------------------------------------------------------------------------------------------------------------------------|
This is indeed a bug. We
will
need to
fix the
WSDL
we return so
that
the
imports actually resolve to
a
location
on our
webserver.
It would be useful if there
was
an
absolute
location on OASIS
that
everyone
could use in their imports.
Regards
David
Peter Fischer3 wrote:
Hi Mike,
our consumer is
having
problems
reading
the
wsdl you
provided.
It imports the
binding wsdl
like
this:
<import namespace
="urn:oasis:names:tc:wsrp:v1:bind"
location="
wsrp_v1_bindings.wsdl" />
but at this location
(realtive to
http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL
)no
such
document
can be
found.
Should a WSRP
consumer be
able to
handle that
by using a
local
version of
the wsdl or must the
producer
provide a
correct /
complete
wsdl?
Mit freundlichen
Grüßen /
Best
Regards
Peter
"Don't think of the
problem
-
think of
the
solution!" ;-)
___________________________________________________________________
IBM WebSphere Portal
Development
Boeblingen,
Germany
Phone:
++49-7031-16-4497
eMail:
peter.fischer@de.ibm.com
|---------+----------------------------->
| |
Michael
Freedman
|
| |
<Michael.Freedman@|
| |
oracle.com>
|
| |
|
| |
06/10/2003
07:45
|
| |
PM
|
| |
|
|---------+----------------------------->
>
-----------------------------------------------------------------------------------------------------------------------------|
|
|
| To:
WSRP
<wsrp@lists.oasis-open.org>,
wsrp-interop
<wsrp-interop@lists.oasis-open.org>
|
| cc:
|
| Subject:
[wsrp-interop]
Verify
interoperability with
Oracle Portal
|
|
|
|
|
>
-----------------------------------------------------------------------------------------------------------------------------|
As of yesterday,
Monday
June9th,
Oracle
is
publically
hosting a
pre-release version
of its
portal
implementing the TC 1.0
WSRP
specification so
other
vendors/customers can
verify their
implementations
interoperate with
Oracle. By
making this
publically
available we hope to
accelerate
the use
and
implementation of
interoperable WSRP
producers. The
site
is
available at:
http://portalstandards.oracle.com.
Additonal supporting
information
is
available if you
click on
the "Go
back
to
Oracle9iAS
Portal
Center"
link
on this sites welcome
page.
To
use the
site
[to test
your
producer]
you
must be a logged in
"Oracle
Technology
Network" user.
Login
accounts
are free and
available to
all.
Merely
click
on the
"login"
link in
the
upper right corner
and
either
login to
an
existing
account or
sign up
for a new one. Once
logged
in
you will
be
able to
register
your
producer(s) with the
Oracle
Portal and
add
portlets from
this
producer
to your own sandboxed
portal
page. The
site
contains
instructions on
how to do this as
well as
an
existing
sample
page
containing
portlets
from the Oracle WSRP
Sample
Producer.
This
later is also
hosted
publically so other
WSRP
consumers can
test
if they
work/interoperate
with Oracle's
WSRP/JSR 168
container.
The
WSDL for this
producer is
available at
http://portalstandards.oracle.com/wsrp/jaxrpc?WSDL
.
Though the site
requests
problems/support
issues be
directed
to
discussion
lists/support,
we
prefer you
use
the
wsrp-interop@lists.oasis-open.org
mailing
list to
communicate
questions/issues/problems.
Dave
and I
track
this list
more
closely
ensuring faster turn
around
on
reported
issues.
-Mike-
You may leave a
Technical
Committee at
any
time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
You may leave a
Technical
Committee at
any
time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|--------------------+---------------------------+-----------------------|
| |
|
|
| David Ward |
Oracle
European
|
|
| Principal |
Development
Centre
|
|
| Software Engineer | 520
Oracle
Parkway
|
Email: |
| Oracle Portal |
Thames
Valley
Park
|
david |
| |
Reading
|
.ward |
| |
Berkshire
RG6
1RA
|
@orac |
| | UK
|
le.co |
| |
|
m
|
| |
|
Tel: |
| |
|
+44 |
| |
|
118 |
| |
|
924 |
| |
|
5079 |
| |
|
Fax: |
| |
|
+44 |
| |
|
118 |
| |
|
924 |
| |
|
5005 |
| |
|
|
| |
|
|
|--------------------+---------------------------+-----------------------|
You may leave a Technical
Committee at
any
time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|--------------------+---------------------------+-----------------------|
| |
|
|
| David Ward | Oracle
European
|
|
| Principal |
Development
Centre
|
|
| Software Engineer | 520
Oracle
Parkway
|
Email: |
| Oracle Portal | Thames
Valley
Park
|
david |
| | Reading
|
.ward |
| | Berkshire
RG6
1RA
|
@orac |
| | UK
|
le.co |
| |
|
m
|
| |
|
Tel: |
| |
|
+44 |
| |
|
118 |
| |
|
924 |
| |
|
5079 |
| |
|
Fax: |
| |
|
+44 |
| |
|
118 |
| |
|
924 |
| |
|
5005 |
| |
|
|
| |
|
|
|--------------------+---------------------------+-----------------------|
--
|--------------------+---------------------------+-----------------------|
| |
|
|
| David Ward | Oracle European
|
|
| Principal | Development
Centre
|
|
| Software Engineer | 520 Oracle
Parkway
|
Email: |
| Oracle Portal | Thames Valley
Park
|
david |
| | Reading
|
.ward |
| | Berkshire RG6
1RA
|
@orac |
| | UK
|
le.co |
| |
|
m |
| |
|
Tel: |
| |
|
+44 |
| |
|
118 |
| |
|
924 |
| |
|
5079 |
| |
|
Fax: |
| |
|
+44 |
| |
|
118 |
| |
|
924 |
| |
|
5005 |
| |
|
|
| |
|
|
|--------------------+---------------------------+-----------------------|
Listen Port: 2222
Target Host: wsrp.dyndns.org
Target Port: 8083
==== Request ====
POST /wsrp/wsrp4j/WSRPBaseService
HTTP/1.1
Host: ukp16267.uk.oracle.com:2222
Connection: Keep-Alive, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3
Oracle-ECID:
1055791210625ApplicationServerThread
SOAPAction:
"urn:oasis:names:tc:wsrp:v1:initCookie"
Accept-Encoding: deflate, gzip, x-gzip,
compress,
x-compress
Content-type: text/xml; charset="utf-8"
Content-length: 452
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns0
="urn:oasis:names:tc:wsrp:v1:types">
<env:Body>
<ns0:initCookie>
<ns0:registrationContext>
<ns0:registrationHandle>192.168.200.1_1055790421716_9</ns0:registrationHandle>
</ns0:registrationContext>
</ns0:initCookie>
</env:Body>
</env:Envelope>
POST /wsrp/wsrp4j/WSRPBaseService
HTTP/1.1
Host: ukp16267.uk.oracle.com:2222
Connection: TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3
Oracle-ECID:
1055791210625ApplicationServerThread
Cookie:
JSESSIONID=5934EF2F75DD19FA504553E09B8C2527
SOAPAction:
"urn:oasis:names:tc:wsrp:v1:getMarkup"
Accept-Encoding: deflate, gzip, x-gzip,
compress,
x-compress
Content-type: text/xml; charset="utf-8"
Content-length: 2360
<?xml version="1.0" encoding
="UTF-8"?>
<env:Envelope xmlns:env="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns0
="urn:oasis:names:tc:wsrp:v1:types">
<env:Body>
<ns0:getMarkup>
<ns0:registrationContext>
<ns0:registrationHandle>192.168.200.1_1055790421716_9</ns0:registrationHandle>
</ns0:registrationContext>
<ns0:portletContext>
<ns0:portletHandle>0.192.168.200.1_1055790532049_10</ns0:portletHandle>
<ns0:portletState/>
</ns0:portletContext>
<ns0:runtimeContext>
<ns0:userAuthentication>wsrp:password</ns0:userAuthentication>
<ns0:portletInstanceKey>253_34169_253_1_1</ns0:portletInstanceKey>
<ns0:namespacePrefix>
__ns253_34169_253_1_1_</ns0:namespacePrefix>
</ns0:runtimeContext>
<ns0:userContext>
<ns0:userContextKey>DXWARD4[1]</ns0:userContextKey>
</ns0:userContext>
<ns0:markupParams>
<ns0:secureClientCommunication>false</ns0:secureClientCommunication>
<ns0:locales>en-gb</ns0:locales>
<ns0:mimeTypes>text/html</ns0:mimeTypes>
<ns0:mimeTypes>text/xml</ns0:mimeTypes>
<ns0:mimeTypes>text/vnd.oracle.mobilexml</ns0:mimeTypes>
<ns0:mode>wsrp:view</ns0:mode>
<ns0:windowState>wsrp:normal</ns0:windowState>
<ns0:clientData>
<ns0:userAgent>Mozilla/4.0
(compatible;
MSIE 6.0;
Windows NT 5.0; Q312461)
RPT-HTTPClient/0.3-3</ns0:userAgent>
<ns0:extensions>
<oracle:GenericExtension
xmlns:oracle="
http://xmlns.oracle.com/portal/wsrp/v1"
>
<ns0:NamedString
name
="X-Oracle-Device.Orientation">
<ns0:value>landscape</ns0:value>
</ns0:NamedString>
<ns0:NamedString
name
="X-Oracle-Device.MaxDocSize">
<ns0:value>0</ns0:value>
</ns0:NamedString>
<ns0:NamedString
name
="X-Oracle-Device.Class">
<ns0:value>pcbrowser</ns0:value>
</ns0:NamedString>
<ns0:NamedString
name
="X-Oracle-Device.Secure">
<ns0:value>false</ns0:value>
</ns0:NamedString>
</oracle:GenericExtension>
</ns0:extensions>
</ns0:clientData>
<ns0:navigationalState></ns0:navigationalState>
<ns0:markupCharacterSets>utf-8</ns0:markupCharacterSets>
<ns0:validNewModes>wsrp:view</ns0:validNewModes>
<ns0:validNewModes>wsrp:edit</ns0:validNewModes>
<ns0:validNewModes>wsrp:help</ns0:validNewModes>
<ns0:validNewWindowStates>wsrp:normal</ns0:validNewWindowStates>
<ns0:validNewWindowStates>wsrp:maximized</ns0:validNewWindowStates>
<ns0:validNewWindowStates>wsrp:minimized</ns0:validNewWindowStates>
</ns0:markupParams>
</ns0:getMarkup>
</env:Body>
</env:Envelope>
==== Response ====
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Mon, 16 Jun 2003 19:18:53 GMT
Content-Type: text/xml; charset=utf-8
Set-Cookie:
JSESSIONID=5934EF2F75DD19FA504553E09B8C2527;
Path=/wsrp
Server: Apache Coyote/1.0
Via: 1.1 inet-nc01 (NetCache
NetApp/5.3.1R3)
14c
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="
http://www.w3.org/2001/XMLSchema"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<initCookieResponse xmlns
="urn:oasis:names:tc:wsrp:v1:types"/>
</soapenv:Body>
</soapenv:Envelope>
0
HTTP/1.1 500 Server Error
Date: Mon, 16 Jun 2003 19:18:54 GMT
Content-Length: 263
Content-Type: text/html
Server: NetCache appliance
(NetApp/5.3.1R3)
<HTML>
<!-- $Id:
//depot/prod/ontap/Rbrutus/prod/netcache/errors/500.html#1
$ -->
<HEAD>
<TITLE>500 Server
Error</TITLE>
</HEAD>
<BODY>
<H1>Server Error</H1>
<H4>The following error
occurred:
<P>Bad URL</H4>
<HR>Please contact the
administrator.</BODY>
</HTML>
You may leave a Technical Committee at
any
time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
You may leave a Technical Committee at
any
time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | |
m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | |
m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
You may leave a Technical Committee at any time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | |
m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
You may leave a Technical Committee at any time by
visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | |
m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
--
|--------------------+---------------------------+-----------------------|
| | |
|
| David Ward | Oracle European |
|
| Principal | Development Centre |
|
| Software Engineer | 520 Oracle Parkway |
Email: |
| Oracle Portal | Thames Valley Park |
david |
| | Reading |
.ward |
| | Berkshire RG6 1RA |
@orac |
| | UK |
le.co |
| | | m
|
| | |
Tel: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5079 |
| | |
Fax: |
| | |
+44 |
| | |
118 |
| | |
924 |
| | |
5005 |
| | |
|
| | |
|
|--------------------+---------------------------+-----------------------|
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
--
|--------------------+---------------------------+-----------------------|
| | | |
| David Ward | Oracle European | |
| Principal | Development Centre | |
| Software Engineer | 520 Oracle Parkway | Email: |
| Oracle Portal | Thames Valley Park | david |
| | Reading | .ward |
| | Berkshire RG6 1RA | @orac |
| | UK | le.co |
| | | m |
| | | Tel: |
| | | +44 |
| | | 118 |
| | | 924 |
| | | 5079 |
| | | Fax: |
| | | +44 |
| | | 118 |
| | | 924 |
| | | 5005 |
| | | |
| | | |
|--------------------+---------------------------+-----------------------|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]