Smalltalk › Cincom › VisualWorks

[vwnc] Accessing header objects in WS

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Charles Johnson-10

[vwnc] Accessing header objects in WS

Hi.
Is there any way I can access objects instanciated in the headers processing (let's say, MyHeader>>processInputHeader:transport:) by my application ?

My problem is that I login somewhere with the auth data provided in the header and I must process these login results in the request message, but I can't find a place to store this data and passing it to the message without subclassifing OpenTalk.SOAPRequest.

Cheers.

CJ.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

kobetic

Re: [vwnc] Accessing header objects in WS

The easiest way is probably adding entries to the request/reply environment during header processing.

processInputHeader: aRequest transport: aTransport

aRequest environmentAt: #AuthData put: whatever.
...

Then when the application code runs, you can access these through the process environment

Processor activeProcess environmentAt: #AuthData

These environments are private to each processed request/reply, each is executed in the context of its own process by defauly. So you don't need to worry about concurrency issues with this, unless you're customizing the broker RequestDispatcher in a way where processes would get reused, in which case you may need to look at clearing the process environments between requests.

HTH,

Martin

Charles Johnson wrote:

> Hi.
> Is there any way I can access objects instanciated in the headers
> processing (let's say, MyHeader>>processInputHeader:transport:) by my
> application ?
>
> My problem is that I login somewhere with the auth data provided in the
> header and I must process these login results in the request message,
> but I can't find a place to store this data and passing it to the
> message without subclassifing OpenTalk.SOAPRequest.
>
> Cheers.
>
> CJ.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Charles Johnson-10

Re: [vwnc] Accessing header objects in WS

In reply to this post by Charles Johnson-10

Hi Martin,
Actually aRequest is aSOAPRequest not a aHTTPRequest.
Haven't checked if I can access it (theHTTPRequest) through the SOAPRQ, since we hacked it some other way.
We subclassified WebServices.SoapRequest with a class responsible of passing the data between the header and the rq.

Thank you.

CJ.

----- Original Message ----
From: Martin Kobetic <[hidden email]>
To: Charles Johnson <[hidden email]>
Cc: [hidden email]
Sent: Monday, June 30, 2008 5:32:18 PM
Subject: Re: [vwnc] Accessing header objects in WS

The easiest way is probably adding entries to the request/reply environment during header processing.

processInputHeader: aRequest transport: aTransport

    aRequest environmentAt: #AuthData put: whatever.
    ...

Then when the application code runs, you can access these through the process environment

    Processor activeProcess environmentAt: #AuthData

These environments are private to each processed request/reply, each is executed in the context of its own process by defauly. So you don't need to worry about concurrency issues with this, unless you're customizing the broker RequestDispatcher in a way where processes would get reused, in which case you may need to look at clearing the process environments between requests.

HTH,

Martin

Charles Johnson wrote:

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

kobetic

Re: [vwnc] Accessing header objects in WS

Charles Johnson wrote:
> Hi Martin,
> Actually aRequest is aSOAPRequest not a aHTTPRequest.
> Haven't checked if I can access it (theHTTPRequest) through the SOAPRQ,
> since we hacked it some other way.

Yes, that is as expected. If you look both SOAPRequest and SOAPReply add 'environment' to their superclass behavior. That's where I meant to put the additional objects during header processing. Later on just before they are evaluated their environment gets copied over to the Process environment (see XMLRequest>>evaluateFor:). So it should work.

> We subclassified WebServices.SoapRequest with a class responsible of
> passing the data between the header and the rq.

However WS.SoapRequest/SoapReply are not used in the context of the brokers. Those are used by the standalone SoapClient/WsdlClient. It's a bit confusing but there are two ways to do client side WS. There's WsdlClient and there's WSOpentalkClient. The first one is meant to be a simple, lightweight version which doesn't use as much infrastructure, but doesn't have the automated header processing facilities either. The Opentalk version is the big hammer which matches the WSOpentalkServer piece and provides the header processing stuff too. So extending WS.SoapRequest shouldn't have any impact on WSOpentalkClient/Server or any other setup relying on the Opentalk broker based Web Services.

HTH,

Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc