You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Steve Hardy <st...@connectux.com> on 2004/12/02 14:01:06 UTC

init() issues

Hi guys,

I may be completely wrong here, but what is the point of the init()
function on the webservice being called from the GetClassInstance in the
generated Wrapper classes, as well as being called directly from the
AxisEngine. I have been looking at the scoping and there doesn't seem to
be a difference in scoping as to when the init() function is called. Is
this by design or am I on completely the wrong track here?

My idea would have been that:

- Object is created when needed for the first time
- init() is called when the object is used in a new scope (so, at
load-time, at session switch time for session scope,
and before each invoke() for request scope)

As far as I can see, init() is now always called before each invoke().

Am I also correct in seeing that the session code is incomplete, although
there is quite some (untested?) code (like SessionScopeHandlerPool.cpp) to
handle session-based requests? Is anybody working on this at the moment?
If nobody is, are there any foreseeable problems with adding this support,
as it doesn't seem to be much work to me, and would definitely be a big
improvement ... ? I'd be glad to put in some work to get the session
scoping to work ...


Re: init() issues

Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Re init():
http://nagoya.apache.org/jira/browse/AXISCPP-282

This is an issue yet to be fixed.

Samisa...

--- sanjaya singharage <sa...@opensource.lk> wrote:

> I think this work is incomplete. The session stuff existing in the code
> (except for the new client side session stuff) were done with future needs
> in mind. Therefore any scoping on engine objects should be rethinked and
> redone if necessary in my opinion.
> 
> I have been working on the client side SOAP Header based sessions. The
> relevant sample can now talk with a session scoped Axis Java service (though
> there are some crashing problems on the c++ client). I would be making a
> post with how this was enabled and it needs to be improved. You might want
> to have a look at that sample to see what is needed to maintain
> interoperability with Axis Java Sessions.
> 
> sanjaya.
> 
> ----- Original Message -----
> From: "Steve Hardy" <st...@connectux.com>
> To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
> Sent: Thursday, December 02, 2004 7:01 PM
> Subject: init() issues
> 
> 
> > Hi guys,
> >
> > I may be completely wrong here, but what is the point of the init()
> > function on the webservice being called from the GetClassInstance in the
> > generated Wrapper classes, as well as being called directly from the
> > AxisEngine. I have been looking at the scoping and there doesn't seem to
> > be a difference in scoping as to when the init() function is called. Is
> > this by design or am I on completely the wrong track here?
> >
> > My idea would have been that:
> >
> > - Object is created when needed for the first time
> > - init() is called when the object is used in a new scope (so, at
> > load-time, at session switch time for session scope,
> > and before each invoke() for request scope)
> >
> > As far as I can see, init() is now always called before each invoke().
> >
> > Am I also correct in seeing that the session code is incomplete, although
> > there is quite some (untested?) code (like SessionScopeHandlerPool.cpp) to
> > handle session-based requests? Is anybody working on this at the moment?
> > If nobody is, are there any foreseeable problems with adding this support,
> > as it doesn't seem to be much work to me, and would definitely be a big
> > improvement ... ? I'd be glad to put in some work to get the session
> > scoping to work ...
> >
> >
> 
> 
> 



		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com 

Re: init() issues

Posted by sanjaya singharage <sa...@opensource.lk>.
I think this work is incomplete. The session stuff existing in the code
(except for the new client side session stuff) were done with future needs
in mind. Therefore any scoping on engine objects should be rethinked and
redone if necessary in my opinion.

I have been working on the client side SOAP Header based sessions. The
relevant sample can now talk with a session scoped Axis Java service (though
there are some crashing problems on the c++ client). I would be making a
post with how this was enabled and it needs to be improved. You might want
to have a look at that sample to see what is needed to maintain
interoperability with Axis Java Sessions.

sanjaya.

----- Original Message -----
From: "Steve Hardy" <st...@connectux.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Thursday, December 02, 2004 7:01 PM
Subject: init() issues


> Hi guys,
>
> I may be completely wrong here, but what is the point of the init()
> function on the webservice being called from the GetClassInstance in the
> generated Wrapper classes, as well as being called directly from the
> AxisEngine. I have been looking at the scoping and there doesn't seem to
> be a difference in scoping as to when the init() function is called. Is
> this by design or am I on completely the wrong track here?
>
> My idea would have been that:
>
> - Object is created when needed for the first time
> - init() is called when the object is used in a new scope (so, at
> load-time, at session switch time for session scope,
> and before each invoke() for request scope)
>
> As far as I can see, init() is now always called before each invoke().
>
> Am I also correct in seeing that the session code is incomplete, although
> there is quite some (untested?) code (like SessionScopeHandlerPool.cpp) to
> handle session-based requests? Is anybody working on this at the moment?
> If nobody is, are there any foreseeable problems with adding this support,
> as it doesn't seem to be much work to me, and would definitely be a big
> improvement ... ? I'd be glad to put in some work to get the session
> scoping to work ...
>
>