RE: [SPAM_EMAIL] - Using global variables in Axis (HttpSession andServletContext) - Email has different SMTP TO: and MIME TO: fields in the email addresses

["Mohit.Gupta" <Mo...@india.rsystems.com>]

Hi,

Solution is purely dependent on your requirements and the scenarios.

If you are not using the thread pools:
	
- Install a handler on your request path.
- Maintain a InheritableThreadLocal with this handler.
- Set the session to this thread local variable whenever a request is received by this  handler.
- Expose a method to get the session - getSession.
- Now the main thread and all its child thread can access this property.


But if you are using thread pools, then the problem is complicate. And the possible solution  is 

- Maintain a Inheritable thread local variable i.e. property store in every component or  taskwhich can be started in a new thread.
- Modify the thread pool in such a way that any parameter can be passed to the thread pool.
- Use this parameter to set the thread local variable of the task i.e. the component, after  starting the task in a thread.
- This may help you to get the access for this property.

Thanks
Mohit.

-----Original Message-----
From: Juha Kononen [mailto:Juha.Kononen@savonia-amk.fi]
Sent: Wednesday, August 17, 2005 3:58 PM
To: axis-user@ws.apache.org
Subject: [SPAM_EMAIL] - Using global variables in Axis (HttpSession
andServletContext) - Email has different SMTP TO: and MIME TO: fields in
the email addresses


Thanks for advise!

 Too bad that it's not possible to get an access to MessageContext in
user's own threads.
Does this mean that the session mechanism can be used only partially in
axis (because there is no
way to get HttpSession in threads)? I had an idea to use HttpSession as
a global variable in each session where to
store session-specific information (data sent by a client) for each
client. This global
session-specific storage would help me to get data directly instead of
passing it
to objects and threads via many function parameters (in contrast to
HttpSession I use ServletContext as a global variable
for storing a reference to a database pool). Of course, I could get the
data sent by a client via a static class variable
in my DSServiceSOAPBindingImpl class. But unfortunately class variables
are shared with all sessions, so that will not work if
I want my class variables to be session-spefic. So is there any way I
can use a global, session-specific variable anywhere in
my server-side code (including those threads)? Java doesn't have global
variables, but don't we still need them? :)

Juha

>>> jgreif@alumni.princeton.edu 08/16 4:18  >>>
The message context returned from this method is held in a thread-local

variable of the thread handling the web service request.  This is the
way a 
static method can be used to return a message context correctly for 
simultaneously-handled web service requests of various kinds.  However,
it 
only works in the request-handling threads (i.e., the ones in which the

implementation method of the web service operation is called).

Jeff
----- Original Message ----- 
From: Juha Kononen
To: axis-user@ws.apache.org 
Sent: Tuesday, August 16, 2005 4:03 AM
Subject: The static MessageContext.getCurrentContext method
doesn'twork


Hi, I have a problem with using the MessageContext.getCurrentContext
method 
in my server-side code.
I would like to get the current context to able to get an access to the

current session. Well, everything works just fine if I use the 
getCurrentContext method in one of my own objects, but something
strange 
happends when I'm trying to use this method inside a thread. Everytime
I 
call the MessageContext.getCurrentContext method in a thread it returns
only 
null. Is this a bug? As I told, the the
MessageContext.getCurrentContext 
method works great, I can get my MessageContext object, if I don't use
the 
method in threads. Have you guys got this method working in threads?
Even if 
I can pass a MessageContext reference into a thread via a static
variable 
the getCurrentContext doesn't work. There's got to be something wrong
with 
this method. Because of this problem it's impossible to make use of the

session mechanism in threads.