You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by am am <ak...@yahoo.com> on 2011/01/23 10:37:03 UTC
axis2 code generation stubs
Hi,
I am starting on axis2 (1.5.4). After doing a wsdl2java code generation, I was
looking into the artifacts.
For a service that accepts a String and returns a String an ADBean was generated
for the in-out params. The bean has some fields and booleans to indicate if the
value has been set for serialization/de-serialization, but could not understand
the following code:
/**
* Auto generated setter method
* @param param Value
*/
public void setValue(java.lang.String param){
if (param != null){
//update the setting tracker
localValueTracker = true;
} else {
localValueTracker = true;
}
this.localValue=param;
}
I mean localValueTracker is always set to true. Is this correct? I imagine that
for the case that param == null the localValueTracker would be set to false.
Thank you
Re: Axis2 and Same origin
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
any idea about this one? I will appreciate any feedback.
Thanks
On 1/24/2011 12:28 AM, Demetris wrote:
>
> HI all,
>
> do standalone instances of Axis2 deal with the same origin scenarios?
> If a remote client is running Ajax/XHR on a browser, there are cases taht
> that the browser will send a preflight OPTIONS request to the server
> before
> it can send the request. Does Axis2 deal with such a request or does
> an HTTP
> server need to be present to take care of this?
>
> Thanks
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Axis2 and Same origin
Posted by Demetris <de...@ece.neu.edu>.
HI all,
do standalone instances of Axis2 deal with the same origin scenarios?
If a remote client is running Ajax/XHR on a browser, there are cases taht
that the browser will send a preflight OPTIONS request to the server before
it can send the request. Does Axis2 deal with such a request or does an HTTP
server need to be present to take care of this?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org
Embedding Axis2 in a web app (Updated subject to Axis2 just in case)
Posted by am am <ak...@yahoo.com>.
Hi,
I am trying to embed axis2 in a web application. I found and followed this
article by Deepal Jayasinghe:
http://www.developer.com/services/article.php/3777111/Embedding-Apache-Axis2-into-Existing-Applications.htm
and by doing it exactly as is and placing an .aar service file in services, it
worked (I saw the WSDL in the browser).
My problem is the following: is this the only way to embed axis in a web-app?
I.e inside the WEB-INF of webapp I must copy /conf/axis2.xml, /modules, /lib
etc?
The reason I am asking is because I have seen an embedded app with the following
setup:
TOMCAT-HOME
/MyApplication
|
/WEB-INF
|
web.xml
services.xml ---> refers to
a service class e.g. com.x.y.z.serviceImp
axis2.xml
/lib
-axis and other jars
-myService.jar --->
Contains service com.x.y.z.serviceImp referred by services.xml
Other directories and files
This setup works and the only thing I noticed is that the web.xml contains the
following:
<servlet>
<servlet-name>SomeRandomWebService</servlet-name>
<servlet-class>
org.apache.axis.transport.http.AxisServlet
</servlet-class>
</servlet>
I mean that the servlet-class is NOT org.apache.axis2.transport.http.AxisServlet
(but plain axis). Does this mean axis1?
Anyway I tried to replicate this setup but it was impossible. I kept getting
either 404 errors or "org.apache.axis2.AxisFault: The AXIS engine could not find
a target service to invoke!"error by tweaking the setup in my attempt.
I think that I have big missunderstanding of axis concepts due to I am an axis
starter.
Could someone please help me on this one?
How come, I can not do the same setup? Any info on this is highly welcome.
Thank you
Axis2 deployment in POJO
Posted by am am <ak...@yahoo.com>.
Hi,
I am axis starter and I have the following question.
Most of the tutorials mention that to deploy a pojo, the pojo should be placed
under the pojo directory (and if it does not exist create it).
Additionally, pojos under a package, should be placed in a .jar and modify the
deployer in axis2.xml to point to pojo directory for jars.
But in official guide of axis2
http://axis.apache.org/axis2/java/core/docs/pojoguide.html there is no mention
of a need for pojo directory. Additionally I noticed that if I drop a jar in the
WEB-INF/lib the pojo deployment still works.
So, can someone please tell me if the pojo directory is needed or not? Or is the
pojo directory required, if you have no services.xml for the pojo?
Because for the case of
http://axis.apache.org/axis2/java/core/docs/pojoguide.html there is a
services.xml for the pojo.
I am trying to understand how axis2 deploys
Thank you
Embedding axis in a web app
Posted by am am <ak...@yahoo.com>.
Hi,
I am trying to embed axis2 in a web application. I found and followed this
article by Deepal Jayasinghe:
http://www.developer.com/services/article.php/3777111/Embedding-Apache-Axis2-into-Existing-Applications.htm
and by doing it exactly as is and placing an .aar service file in services, it
worked (I saw the WSDL in the browser).
My problem is the following: is this the only way to embed axis in a web-app?
I.e inside the WEB-INF of webapp I must copy /conf/axis2.xml, /modules, /lib
etc?
The reason I am asking is because I have seen an embedded app with the following
setup:
TOMCAT-HOME
/MyApplication
|
/WEB-INF
|
web.xml
services.xml ---> refers to
a service class e.g. com.x.y.z.serviceImp
axis2.xml
/lib
-axis and other jars
-myService.jar --->
Contains service com.x.y.z.serviceImp referred by services.xml
Other directories and files
This setup works and the only thing I noticed is that the web.xml contains the
following:
<servlet>
<servlet-name>SomeRandomWebService</servlet-name>
<servlet-class>
org.apache.axis.transport.http.AxisServlet
</servlet-class>
</servlet>
I mean that the servlet-class is NOT org.apache.axis2.transport.http.AxisServlet
(but plain axis). Does this mean axis1?
Anyway I tried to replicate this setup but it was impossible. I kept getting
either 404 errors or "org.apache.axis2.AxisFault: The AXIS engine could not find
a target service to invoke!"error by tweaking the setup in my attempt.
I think that I have big missunderstanding of axis concepts due to I am an axis
starter.
Could someone please help me on this one?
How come, I can not do the same setup? Any info on this is highly welcome.
Thank you
AW: AW: AW: axis2 session scopes
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
Hi
I am a bit confused about what you really want to do. But since you know now better what you can do please explain it again.
Why scope="transportsession" ? Why not scope="Soapsession"? Why scope="application"? Why not scope="requestsession"?
Now to your recent mail.
If you have the JSESSIONID=… returned by your first response header, then the client code needs to send it back with each request !
Why else should the server return this cookie? Think behind. What is the servers expectation or aim to return this cookie to the client?
Next: How can you make your client resend this cookie with each request, given the client has to belong to the same session,
. . . . . however you define a session might be another topic to discuss.
Answer: it depends on the client platform
For MS WCF Clients you need to have HttpTransportElement.AllowCookies = true AND
For Java Axis2 Clients you do so as Deepal said below :
when you use transport session you are required to send the cookies, which can also be done by setting the above property.
The cookie is to be re-sent because you don’t get back from the server an servicegroupId : Look further down.
How do you massage your http header: for MS .NET WCF Clients using C# language
I am using my own custom binding; A binding is a collection of Binding Elements (see MS MFC .NET documentation for that if required.
// 6.
// Create a Binding Element for the required Transport and define the proxy for TCP Monitoring
// *************************************************
HttpTransportBindingElement httpTransportBE = new HttpTransportBindingElement();
httpTransportBE.AllowCookies = true;
//httpTransport.KeepAliveEnabled = false;
if (theProxyAddress.Length > 0)
{
httpTransportBE.UseDefaultWebProxy = false;
httpTransportBE.ProxyAddress = new Uri(theProxyAddress);
} else {
httpTransportBE.UseDefaultWebProxy = true;
}
//httpTransportBE.AuthenticationScheme = System.Net.AuthenticationSchemes.Anonymous;
//httpTransportBE.AuthenticationScheme = AuthenticationSchemes.Negotiate;
//httpTransportBE.BypassProxyOnLocal = true;
//httpTransportBE.HostNameComparisonMode = HostNameComparisonMode.StrongWildcard;
//httpTransportBE.ManualAddressing = true;
//httpTransportBE.MaxBufferPoolSize = 4578812;
//httpTransportBE.MaxBufferSize = 45787;
//httpTransportBE.MaxReceivedMessageSize = 1245786;
//httpTransportBE.ProxyAuthenticationScheme = AuthenticationSchemes.Negotiate;
//httpTransportBE.Realm = "";
//httpTransportBE.TransferMode = TransferMode.Streamed;
//httpTransportBE.UnsafeConnectionNtlmAuthentication = true;
Later down in a method used to Authenticate I am about to massage my http header …
public TWS Authenticate(TWS wsinp, TWS wsout)
{
// output data from server
string token = "";
TPAYLOAD payout = new TPAYLOAD();
// input data to server
TPAYLOAD payin = new TPAYLOAD("SPS-Payload");
TWSCOL wscol = new TWSCOL("wscol");
payin.wscol = wscol;
wscol.Add(wsinp);
string userId = wsinp.eRet("USERNAME");
string password = wsinp.get_Item("PASSWORD").Fldval.ToString();
wscol.Add(wsout);
using (OperationContextScope scope = new OperationContextScope((IContextChannel)FKTmapManagerChannel))
{
//try
//{
HttpRequestMessageProperty reqProp;
if (OperationContext.Current.OutgoingMessageProperties.Count == 0)
{
reqProp = new HttpRequestMessageProperty();
OperationContext.Current.OutgoingMessageProperties.Add(HttpRequestMessageProperty.Name, reqProp);
}
else
{
reqProp = OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] as HttpRequestMessageProperty;
}
char quote = '"';
string strContentType = "application/soap+xml; charset=UTF-8; action=" + quote + "urn:login" + quote;
reqProp.Headers.Add(HttpRequestHeader.ContentType, strContentType);
reqProp.Headers.Add(HttpRequestHeader.UserAgent, "Axis2");
reqProp.Headers.Add(HttpRequestHeader.TransferEncoding, "chunked");
//reqProp.Headers.Add(HttpRequestHeader.Host, "alpha1:54887");
string cT = reqProp.Headers[HttpRequestHeader.ContentType];
string uA = reqProp.Headers[HttpRequestHeader.UserAgent];
string tE = reqProp.Headers[HttpRequestHeader.TransferEncoding];
//string hO = reqProp.Headers[HttpRequestHeader.Host];
Console.WriteLine();
Console.WriteLine("ProcessMessage: Content-Type: {0} User-Agent: {1} Transfer-Encoding:{2}", cT, uA, tE);
//}
//catch (Exception e)
//{
// Console.WriteLine("ProcessMessage: got exception: " + e.ToString());
//}
if (FKTmapManagerChannel.Authenticate(out token, out payout, userId, password, payin))
{
// Save context information for re use. This information will be used by the
// ClientMessageInspector class to inject the Token to the headers along with each request.
ClientContext.UserId = userId;
ClientContext.Token = token;
//safe the ClientContext to our own instance based context
getClientContext();
// Authenticate returns headers we must keep for each fktmap and logout
}
if (payout == null) return wsinp;
return payout.wscol.get_Item("wsout");
}
}
This is what you need to make your axis2 engine think in scope="soapsession" that the requestor (the UserAgent) is an axis2-client.
So again: it is simple to make axis2-client work in scope="soapsession" to always reach the same instance by turning the proper options on. It is much more problematic to make a MS C# WCF Client talk properly to an axis2 service in scope="soapsession".
Well here comes my Test Java Axis2 Client Program which works in scope="soapsession", which I use from my PC to test my axis2 web service running on OpenVMS in scope="soapsession"
I can run this program 5 times and I have 5 service objects instantiated and each program talks to its instantiated unique service providing object. 5 user client session threads ending each at its unique session thread object. Through this service providing objects in role of a place holder for a 5 legacy server processes my client thread talks to a dedicated openvms legacy process.
As Deepal said: you need to engage addressing.mod on the client (as shown in code) and on the server (not shown here)
/*
* SOAPSpezplaClient.java
*
* Created on 27. Juni 2007, 10:13
*/
package axawl.spezpla.clients;
import org.apache.axiom.om.OMNode;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.xpath.AXIOMXPath;
import org.apache.axiom.om.impl.builder.StAXOMBuilder;
import org.jaxen.JaxenException;
import javax.xml.stream.XMLStreamException;
import java.io.FileNotFoundException;
import java.util.List;
/**
*
* @author C770817
*/
import org.apache.axis2.context.ConfigurationContext;
import org.apache.axis2.context.ConfigurationContextFactory;
import org.apache.axis2.deployment.FileSystemConfigurator;
import org.apache.axis2.engine.AxisConfiguration;
import org.apache.axis2.AxisFault;
import org.apache.axis2.Constants;
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.*;
import org.apache.axis2.rpc.client.*;
import org.apache.axiom.soap.impl.llom.soap12.SOAP12Factory;
import org.apache.axiom.soap.SOAPFactory;
import org.apache.axiom.soap.SOAPEnvelope;
import org.apache.axiom.soap.SOAPHeader;
import org.apache.axiom.soap.SOAPHeaderBlock;
import org.apache.axiom.soap.SOAPBody;
import org.apache.axiom.soap.SOAPFault;
import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMText;
import org.apache.axiom.om.xpath.AXIOMXPath;
import org.apache.axiom.om.xpath.DocumentNavigator;
import org.apache.axiom.om.util.XPathEvaluator;
import org.apache.axiom.om.impl.llom.util.AXIOMUtil;
import javax.xml.stream.FactoryConfigurationError;
import javax.xml.stream.XMLOutputFactory;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamWriter;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.xpath.XPathConstants;
import javax.xml.namespace.QName;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.io.File;
import java.io.FileNotFoundException;
import java.util.*;
/**
* This is a Client progam that accesses 'SpezplaService' web service in Axis2 samples
*/
public class SOAPSpezplaClient {
private static final Log log = LogFactory.getLog(SOAPSpezplaClient.class);
private static String toEpr = "http://integ1:8080/axis2/services/SpezplaService";
private static int i = 0;
private static Integer intObj = new Integer(i);
public static void main(String[] args) throws AxisFault {
try {
Options options = new Options();
options.setManageSession(true);
options.setTo(new EndpointReference(toEpr));
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
//options.setProperty(Constants.Configuration.ENABLE_REST, Constants.VALUE_TRUE);
/**
* on OpenVMS user.home is dsa5:[stadelma]
* on windows user.home is C:\Documents and Settings\c770817
**/
String home = System.getProperty("user.home");
// create this folder at your home. This folder could be anything
//then create the "modules" folder
//copy the LoggingModule.mar to "modules" folder.
//copy the axis2.xml to the client-repository
//then modify the axis2.xml that is generating there according to
//phases that being included in the "module.xml"
/**
* on OpenVMS repository is dsa5:[stadelma.client-repository]
* on windows repository is C:\Documents and Settings\c770817\client-repository
**/
File repository = new File(home + File.separator + "client-repository");
if (!repository.exists()) {
throw new FileNotFoundException(repository.getAbsolutePath() + " does not Exist");
};
String str_axis2xml = repository.getAbsolutePath() + File.separator + "axis2.xml";
File axis2_xml = new File(str_axis2xml);
if (!axis2_xml.exists()) {
throw new FileNotFoundException(axis2_xml.getAbsolutePath() + " does not Exist");
};
FileSystemConfigurator fsc = new FileSystemConfigurator(
repository.getAbsolutePath(),
axis2_xml.getAbsolutePath());
AxisConfiguration er = fsc.getAxisConfig();
ConfigurationContext configContext =
ConfigurationContextFactory.createConfigurationContextFromFileSystem(
repository.getAbsolutePath(),
axis2_xml.getAbsolutePath()
);
//ServiceClient sender = new ServiceClient();
ServiceClient sender = new ServiceClient(configContext,null);
//sender.engageModule(new QName(Constants.MODULE_LOGGING));
sender.engageModule(new QName("SpezplaLogging-1.2"));
sender.engageModule(new QName(Constants.MODULE_ADDRESSING));
//sender.engageModule(new QName("addressing-1.2"));
//sender.engageModule(new QName(Constants.MODULE_SOAPMONITOR));
sender.engageModule(new QName("soapmonitor-1.2"));
options.setSoapVersionURI(org.apache.axiom.soap.SOAP12Constants.SOAP_ENVELOPE_NAMESPACE_URI);
// invoke the start method first using it's StartPaylod
options.setAction("urn:login");
sender.setOptions(options);
OMElement element = getLoginPayload(0);
/** now we know we can potentially succeed to create a OpenVmsLogin(u,p) **/
OMElement start = sender.sendReceive(element);
// from now on use this sender so that WS-address stuff i.e. ServiceGroupeContextID info is sent
// where in the dark of the code is that?
String s = intObj.toString(i);
System.out.print("No"+s);
XMLStreamWriter startWriter = XMLOutputFactory.newInstance().createXMLStreamWriter(System.out);
start.serialize(startWriter);
startWriter.flush(); // write every-thing out
System.out.println(""); // and add a CRLF
options.setAction("urn:fktmap");
sender.setOptions(options);
OMElement result = sender.sendReceive(getFktmapPayload(50));
for(int i=0;i<100;i++){
result = sender.sendReceive(getFktmapPayload_FKT_BATCH_LOG(20));
Thread.sleep(40000);
s = intObj.toString(i);
System.out.println("No"+s);
// XMLStreamWriter writer = XMLOutputFactory.newInstance().createXMLStreamWriter(System.out);
// result.serialize(writer);
// writer.flush(); // write every-thing out
// System.out.println(""); // and add a CRLF
if (i==100){
System.gc(); // do an explicit Garbage Collection and get it all back
}
if (0 == i % 100){
System.gc(); // do an explicit Garbage Collection once evry 100 loops-through
}
} // end-for - so do a cleanup now to give up sender resource
// invoke the logout method
options.setAction("urn:logout");
sender.setOptions(options);
result = sender.sendReceive(getLogoutPayload(0));
//sender.fireAndForget(getLogoutPayload());
// from now on use this sender so that WS-address stuff i.e. ServiceGroupeContextID info is sent
// where in the dark of the code is that?
/**
* We have to block this thread untill we send the request , the problem
* is if we go out of the main thread , then request wont send ,so
* you have to wait some time :)
*/
Thread.sleep(2500);
/**
* s = intObj.toString(i);
* System.out.print("No"+s);
*
* XMLStreamWriter pingWriter = XMLOutputFactory.newInstance().createXMLStreamWriter(System.out);
* ping.serialize(startWriter);
* pingWriter.flush(); // write every-thing out
* System.out.println(""); // and add a CRLF
**/
sender.cleanup(); // return resources .finalize would do more but is protected
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (XMLStreamException e) {
e.printStackTrace();
} catch (FactoryConfigurationError e) {
e.printStackTrace();
} catch (java.lang.Exception e) {
e.printStackTrace();
}
}
private static OMElement getLoginPayload(int lc) {
. . . .
return envelope;
}
private static OMElement getFktmapPayload(int lc) {
. . . .
return envelope;
}
private static OMElement getFktmapPayload_FKT_BATCH_LOG(int lc) {
int i = lc;
Integer intObj = new Integer(i);
String sDate = new Date().toString();
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace ns_axawl = fac.createOMNamespace("http://spezpla.axawl.ch","");
OMNamespace schemaInstance = fac.createOMNamespace("http://www.w3.org/2001/XMLSchema-instance", "i");
OMNamespace spsPayload = fac.createOMNamespace("SPS-Payload", "b");
OMNamespace col = fac.createOMNamespace("COL", "c");
OMNamespace dc = fac.createOMNamespace("http://schemas.datacontract.org/2004/07/WCFSpSe", "d");
OMNamespace ws = fac.createOMNamespace("WS", "e");
OMNamespace f = fac.createOMNamespace("feld", "f");
SOAP12Factory sfac = new SOAP12Factory();
SOAPEnvelope envelope = sfac.getDefaultEnvelope();
SOAPHeader header = envelope.getHeader();
SOAPBody body = envelope.getBody();
try {
// create an fktmap Payload"
OMElement root = fac.createOMElement("fktmap",null);
root.declareNamespace(ns_axawl);
OMElement payin = fac.createOMElement("payin",null);
payin.declareNamespace(spsPayload);
payin.declareNamespace(schemaInstance);
root.addChild(payin);
OMElement b_name = fac.createOMElement("Name",spsPayload);
OMText txt1 = fac.createOMText(b_name,"SPS-Payload");
payin.addChild(b_name);
OMElement b_wscol = fac.createOMElement("wscol",spsPayload);
b_wscol.declareNamespace("COL", "c");
payin.addChild(b_wscol);
OMElement c_name = fac.createOMElement("Name",col);
OMText txt2 = fac.createOMText(c_name,"wscol");
b_wscol.addChild(c_name);
OMElement c_Item = fac.createOMElement("Item",col);
// c_Item.declareNamespace("http://schemas.datacontract.org/2004/07/WCFSpSe", "d");
c_Item.declareNamespace(dc);
c_Item.declareNamespace(ws);
b_wscol.addChild(c_Item);
// wsinp
OMElement d_TWS = fac.createOMElement("TWS",dc);
c_Item.addChild(d_TWS);
OMElement e_name = fac.createOMElement("Name",ws);
OMText txt3 = fac.createOMText(e_name,"wsinp");
d_TWS.addChild(e_name);
OMElement e_Item = fac.createOMElement("Item",ws);
e_Item.declareNamespace("feld","f");
d_TWS.addChild(e_Item);
// for(i=0;i<4;i++){
OMElement d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
OMElement f_fldnam = fac.createOMElement("Fldnam",f);
OMText txt4 = fac.createOMText(f_fldnam,"TARGET");
d_TELEM.addChild(f_fldnam);
OMElement f_fldval = fac.createOMElement("Fldval",f);
OMText txt5 = fac.createOMText(f_fldval,"FKT_PUTFILE");
d_TELEM.addChild(f_fldval);
// }
d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
f_fldnam = fac.createOMElement("Fldnam",f);
txt4 = fac.createOMText(f_fldnam,"FILENAME");
d_TELEM.addChild(f_fldnam);
f_fldval = fac.createOMElement("Fldval",f);
txt5 = fac.createOMText(f_fldval,"SYS$LOGIN:SPEZPLA.LOG");
d_TELEM.addChild(f_fldval);
d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
f_fldnam = fac.createOMElement("Fldnam",f);
txt4 = fac.createOMText(f_fldnam,"MORE");
d_TELEM.addChild(f_fldnam);
f_fldval = fac.createOMElement("Fldval",f);
txt5 = fac.createOMText(f_fldval,"FALSE");
d_TELEM.addChild(f_fldval);
d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
f_fldnam = fac.createOMElement("Fldnam",f);
txt4 = fac.createOMText(f_fldnam,"START");
d_TELEM.addChild(f_fldnam);
f_fldval = fac.createOMElement("Fldval",f);
txt5 = fac.createOMText(f_fldval,"1");
d_TELEM.addChild(f_fldval);
d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
f_fldnam = fac.createOMElement("Fldnam",f);
txt4 = fac.createOMText(f_fldnam,"LAENGE");
d_TELEM.addChild(f_fldnam);
f_fldval = fac.createOMElement("Fldval",f);
txt5 = fac.createOMText(f_fldval,intObj.toString());
d_TELEM.addChild(f_fldval);
// wsold
d_TWS = fac.createOMElement("TWS",dc);
c_Item.addChild(d_TWS);
e_name = fac.createOMElement("Name",ws);
txt3 = fac.createOMText(e_name,"wsold");
d_TWS.addChild(e_name);
e_Item = fac.createOMElement("Item",ws);
e_Item.declareNamespace("feld","f");
d_TWS.addChild(e_Item);
// wsout
d_TWS = fac.createOMElement("TWS",dc);
c_Item.addChild(d_TWS);
e_name = fac.createOMElement("Name",ws);
txt3 = fac.createOMText(e_name,"wsout");
d_TWS.addChild(e_name);
e_Item = fac.createOMElement("Item",ws);
e_Item.declareNamespace("feld","f");
d_TWS.addChild(e_Item);
return root;
} catch (Exception ex) {
ex.printStackTrace();
System.out.println("Unknown Java exception took place within the client.");
}
return envelope;
}
private static OMElement getLogoutPayload(int lc) {
int i = 0;
Integer intObj = new Integer(i);
String sDate = new Date().toString();
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace ns_axawl = fac.createOMNamespace("http://spezpla.axawl.ch","");
OMNamespace schemaInstance = fac.createOMNamespace("http://www.w3.org/2001/XMLSchema-instance", "i");
OMNamespace spsPayload = fac.createOMNamespace("SPS-Payload", "b");
OMNamespace col = fac.createOMNamespace("COL", "c");
OMNamespace dc = fac.createOMNamespace("http://schemas.datacontract.org/2004/07/WCFSpSe", "d");
OMNamespace ws = fac.createOMNamespace("WS", "e");
OMNamespace f = fac.createOMNamespace("feld", "f");
SOAP12Factory sfac = new SOAP12Factory();
SOAPEnvelope envelope = sfac.getDefaultEnvelope();
SOAPHeader header = envelope.getHeader();
SOAPBody body = envelope.getBody();
try {
// create an fktmap Payload"
OMElement root = fac.createOMElement("logout",null);
root.declareNamespace(ns_axawl);
OMElement payin = fac.createOMElement("payin",null);
payin.declareNamespace(spsPayload);
payin.declareNamespace(schemaInstance);
root.addChild(payin);
OMElement b_name = fac.createOMElement("Name",spsPayload);
OMText txt1 = fac.createOMText(b_name,"SPS-Payload");
payin.addChild(b_name);
OMElement b_wscol = fac.createOMElement("wscol",spsPayload);
b_wscol.declareNamespace("COL", "c");
payin.addChild(b_wscol);
OMElement c_name = fac.createOMElement("Name",col);
OMText txt2 = fac.createOMText(c_name,"wscol");
b_wscol.addChild(c_name);
OMElement c_Item = fac.createOMElement("Item",col);
// c_Item.declareNamespace("http://schemas.datacontract.org/2004/07/WCFSpSe", "d");
c_Item.declareNamespace(dc);
c_Item.declareNamespace(ws);
b_wscol.addChild(c_Item);
// wsinp
OMElement d_TWS = fac.createOMElement("TWS",dc);
c_Item.addChild(d_TWS);
OMElement e_name = fac.createOMElement("Name",ws);
OMText txt3 = fac.createOMText(e_name,"wsinp");
d_TWS.addChild(e_name);
OMElement e_Item = fac.createOMElement("Item",ws);
e_Item.declareNamespace("feld","f");
d_TWS.addChild(e_Item);
// for(i=0;i<4;i++){
OMElement d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
OMElement f_fldnam = fac.createOMElement("Fldnam",f);
OMText txt4 = fac.createOMText(f_fldnam,"TARGET");
d_TELEM.addChild(f_fldnam);
OMElement f_fldval = fac.createOMElement("Fldval",f);
OMText txt5 = fac.createOMText(f_fldval,"FKT_BYE");
d_TELEM.addChild(f_fldval);
// }
d_TELEM = fac.createOMElement("TELEM",dc);
e_Item.addChild(d_TELEM);
f_fldnam = fac.createOMElement("Fldnam",f);
txt4 = fac.createOMText(f_fldnam,"SELECT");
d_TELEM.addChild(f_fldnam);
f_fldval = fac.createOMElement("Fldval",f);
txt5 = fac.createOMText(f_fldval,"");
d_TELEM.addChild(f_fldval);
return root;
} catch (Exception ex) {
ex.printStackTrace();
System.out.println("Unknown Java exception took place within the client.");
}
return envelope;
}
private static OMElement setErrorInElement(int SCODE, String ERRMSG, int SCODE2, String ERRMSG2, String COMPLETION) {
Integer scode = new Integer(SCODE);
Integer scode2= new Integer(SCODE2);
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace spspl = fac.createOMNamespace("SPS-Payload", "b");
OMNamespace col = fac.createOMNamespace("COL", "c");
OMNamespace ws = fac.createOMNamespace("WS", "d");
OMNamespace e = fac.createOMNamespace("feld", "e");
SOAP12Factory sfac = new SOAP12Factory();
SOAPEnvelope envelope = sfac.getDefaultEnvelope();
SOAPHeader header = envelope.getHeader();
SOAPBody body = envelope.getBody();
try {
// create a Payload collection "SPS-Payload"
OMElement root = fac.createOMElement("root",spspl);
root.declareNamespace(col);
root.declareNamespace(ws);
root.declareNamespace(e);
// create a workspace collection "col"
OMElement wscol = fac.createOMElement("col",col);
root.addChild(wscol);
// create the workspace "wsout"
OMElement wsout = fac.createOMElement("wsout",ws);
// add the workspace "wsout" to the workspace collection "wscol"
wscol.addChild(wsout);
OMElement fldnam = fac.createOMElement("SCODE",e);
// create fldval as "FKT_WMBCREATE" and link it to fldnam
OMText fldval = fac.createOMText(fldnam,scode.toString());
// add the workspace element TARGET to the workspace wsinp
wsout.addChild(fldnam);
// wsout.add("ERRMSG","")
fldnam = fac.createOMElement("ERRMSG",e);
fldval = fac.createOMText(fldnam,ERRMSG);
wsout.addChild(fldnam);
// wsout.add("SCODE2",SCODE2)
fldnam = fac.createOMElement("SCODE2",e);
fldval = fac.createOMText(fldnam,scode2.toString());
wsout.addChild(fldnam);
// wsout.add("ERRMSG2",ERRMSG2)
fldnam = fac.createOMElement("ERRMSG2",e);
fldval = fac.createOMText(fldnam,ERRMSG2);
wsout.addChild(fldnam);
// wsout.add("COMPLETION",COMPLETION)
fldnam = fac.createOMElement("COMPLETION",e);
fldval = fac.createOMText(fldnam,COMPLETION);
wsout.addChild(fldnam);
body.addChild(root);
return root;
} catch (Exception ex) {
ex.printStackTrace();
System.out.println("Unknown Java exception took place within the client.");
}
return envelope;
}
private static String getUsername(OMElement element){
try {
/**
* -TODO--
* deliver Username in a encrypted form; i.e. use a UUID
* better use Rampart and a WS-Security Modell / Policy over
* Transport Level Security such as HTTPS
**/
AXIOMXPath wPath = new AXIOMXPath("/*"); // this is used to find out about the root name spaces etc
OMElement r = (OMElement) wPath.selectSingleNode(element);
String s = " getUsername() xmlns="+r.getNamespace().getPrefix().toString()+"="+r.getNamespace().getNamespaceURI().toString();
log.info(s);
// AXIOMXPath xPath = new AXIOMXPath("/*); // this is used to find out about the root name spaces etc
AXIOMXPath xPath = new AXIOMXPath("/soapenv:Body/b:root/c:col/d:wsinp/e:USERNAME");
xPath.addNamespace("soapenv","http://www.w3.org/2003/05/soap-envelope");
// xPath.addNamespace("wsa","http://www.w3.org/2005/08/addressing");
xPath.addNamespace("b","SPS-Payload");
xPath.addNamespace("c","COL");
xPath.addNamespace("d","WS");
xPath.addNamespace("e","feld");
OMElement user = (OMElement) xPath.selectSingleNode(element);
return user.getText();
} catch (JaxenException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
return "";
}
private static String getPassword(OMElement element){
try {
/**
* -TODO--
* deliver Password in a encrypted form; i.e. use a UUID
* better use Rampart and a WS-Security Modell / Policy over
* Transport Level Security such as HTTPS
**/
// AXIOMXPath xPath = new AXIOMXPath("/*); // this is used to find out about the root name spaces etc
AXIOMXPath xPath = new AXIOMXPath("/soapenv:Body/b:root/c:col/d:wsinp/e:PASSWORD");
xPath.addNamespace("soapenv","http://www.w3.org/2003/05/soap-envelope");
// xPath.addNamespace("wsa","http://www.w3.org/2005/08/addressing");
xPath.addNamespace("b","SPS-Payload");
xPath.addNamespace("c","COL");
xPath.addNamespace("d","WS");
xPath.addNamespace("e","feld");
OMElement pass = (OMElement) xPath.selectSingleNode(element);
return pass.getText();
} catch (JaxenException e) {
e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates.
}
return "";
}
}
This client code is old – it would be designed and re-factored in a much better way today;
I was a Java novice when I developed it 4 years ago, but I am still happy with it, as it is straight forward spaghetti code easy to understand.
Please explain me again what you like to do.
I gave you how to make it work in a heterogeneous environment as well as in a homogeneous world (Java) to work in scope="soapsession".
If you want to work in scope="transportsession" then please say why?
use tcpmonitor all time to see what client and server is exchanging !
Josef.Stadelmann
@axa-winterthur.ch
Von: am am [mailto:akmeref@yahoo.com]
Gesendet: Donnerstag, 27. Januar 2011 18:00
An: java-user@axis.apache.org
Betreff: Re: AW: AW: axis2 session scopes
Hi Josef,
Thank you very much for your time spend in helping me understand this. The analysis was great!
I followed your tip, and tried to use tcpmon on transportsession but I saw that the only session info send to client was the JSESSIONID in the cookie (which is defined in sevlet spec). I.e. The HTTP response was this:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=1CE110EACECC0AE176C6610DA81D0446; Path=/axis2
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 27 Jan 2011 16:49:43 GMT
f3
10
0
So I am not sure how you worked arround this, in the example you mention on the MS WFC Client. You note:
>>Sending the request later by MS WCF Client without that cookie did not work.
>>I hade to add to the http-header all the same bit's as the axis2 java client was sending in scope="soapsession".
But I do not know how you got that info to send it. In the reply in my test, there is only the JSESSIONID send back to the client. And if I make a web service invocation by different instances of web service client, the object is re-instantiated on the server.
Thank you!!!
________________________________
From: Stadelmann Josef <jo...@axa-winterthur.ch>
To: java-user@axis.apache.org
Sent: Thu, January 27, 2011 12:29:50 PM
Subject: AW: AW: axis2 session scopes
To my understanding, the trick with servicegroupId in the soap address header makes only real sense in scope="soapsession".
Given we can have several transports one being http, another being RPC or JSM or whatever, I would want to have a solution selecting my service instance independent from transport protocol used. So I should avoid managing it on the transport level.
Managing how to reach the service providing object (instance) for a particular user session thread should go in my mind only to the SOAP/XML stack and avoid any transport level inclusion/cluttering.
That is the reason why I selected long lasting objects and have one user session thread ending in a instance of a service-class (an object) which gets is message via web service facilities. (just my view). And it works perfect, without any big overhead. It was that decision which allowed us to see an web service providing object as a holder of a HP-WSIT-JAVABEAN which keeps the IPC channel open (to send data from Java to the C-Wrapper-World) to an OpenVMS legacy process 80'000 LOC's of PASCAL plus Oracle DB. Saying, we have to integrate and speak to legacy server processes on a per user session thread basis. (which is overhead I know, but we do legacy-integration, and many old process is just not multi-threaded, or thread aware).
As long as a users client keeps the session/thread open to the service providing object, as long will each message reach the same object identified by the servicegroupId. (think of the servicegroupId as of an "object-identifier" very similar to an IOR in the CORBA world).
It's the server which must give you this object reference, and it's the responsibility of the client to re-use/re-ship it with each request to the axis2 engine to reach "the object".
What is a transport session? When does the transport session start and when does it end?
Now comes my weak bit! I never used scope="transportsession" So I have read this excellent article.
http://www.developer.com/open/print.php/3620661
(do me a favor and forget about the space in the scope=" transportsession" as shown in the article,
as it may lead to problems (somewhere there is a scope dispatcher in java if scope.compare("soapsession") then …-
so he looks at strings very carefully :-))
Given a user client has several transport sessions open, how does it chose about which one to use? Maybe you have 3 stubs?
Manage sessions by transport means:
Articel:
The lifetime of the session is controlled by the transport, not by Axis2;
If axis2 has no control over the session then we need to have our service instance identifying bits located somewhere else, maybe on the transport level, maybe inside the http-header, but for sure not a the soap/xml protocol level;
So it's very likely that a cookie is used for that service instance, and that the axis2 server has to return the cookie to the client as it creates the service instance, a cookie the client has to re-use again to hit the same service instance.
(very much like an IOR in CORAB)
That is when you have to start massaging your http header in the client and sniff in a cookie;
and you do it at the transport level and not at the soap/xml header.
Article:
One of the key advantages of the Transport session over other sessions is that you can talk to multiple service groups within one transport session
Where is the identifying bit selecting the service group wanted?
My learning with scope="soapsession" and long lasting session was:
I had to implement a MS WCF Client talking to an Apache Axis2 web service server with long lasting sessions (state full service providing objects)!
I had to fake axis2! I had to give the axis2 engine what it needs to think that an axis2 client is talking.
By a TCP Monitor or by Wireshark I figured out what axis2 engine expects.
Observation, and not expected at all but it was there on the wire: a http cookie was sent by the axis2 client.
Sending the request later by MS WCF Client without that cookie did not work.
I hade to add to the http-header all the same bit's as the axis2 java client was sending in scope="soapsession".
This http-header-massage in addition to the servicegroupId header on the soap/xml level made me build interceptors at the client which intercept each outgoing and incoming request, just to add/retrieve all required information to reuse them during the next send/request.
Josef
Von: am am [mailto:akmeref@yahoo.com]
Gesendet: Mittwoch, 26. Januar 2011 17:50
An: java-user@axis.apache.org
Betreff: Re: AW: axis2 session scopes
Hi Josef,
Thank you very much for the detailed analysis!!! Now it very clear in my mind.
This solves the soapsession.
I am wondering though, is the servicegroupId required in the transportsession as well?
In transport session, session info are send back-and-forth via cookies and so it is transparent to the programmer. The only thing needed is to setManageSession to true in client object.
At least this is what I understood from reading articles.
But trying it out, a new web service is created each time.
So now I am thinking if I need to send the servicegroupId in the transportsession as well.
- If yes, then how do I find it? Because the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
used for soapsession throws NPE for transportsession, which I guess makes sense since there is no addressing header in transportsession. But how do I find it, to send it in next request?
- If no, what am I doing wrong to observe this behavior? I.e. new instance of web service? I have set session to transportscope and the managesession to true in client. Isn't it enough?
Thanks!
________________________________
From: Stadelmann Josef <jo...@axa-winterthur.ch>
To: java-user@axis.apache.org
Sent: Wed, January 26, 2011 11:44:53 AM
Subject: AW: axis2 session scopes
We use scope="soapsession" in the following case
A: we have 3 different client programs running from the same PC each with the same WS stub.
B: Each one of the 3 client shall span one dedicated user session thread to a dedicated web service based object, which is an instance of your web service class.
(Think how a client-object finds its server-object via a strong link) cA talks to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or sC. Just a 1 to 1 object relation.
B: By using scope="soapsession" the initial call of cA to the web service creates for our service class a web service object sA (as instance) and it returns a servicegroupId Header to the calling client cA.
C: The client cA is now required to send his received servicegroupId in the addressing header with each request to the axis2 engine which dispatches the request to sA
D: that way we can guarantee you that each users client session thread i.e. cA, reaches always the same service object (instance) sA
E: and by adjusting a timeout in the client and the server we have long lasting objects, client and server side, objects talking to each other for hours. And we have no need to re-establish for each request a new stub or a new service providing object.
Josef
Von: am am [mailto:akmeref@yahoo.com]
Gesendet: Montag, 24. Januar 2011 17:47
An: java-user@axis.apache.org
Betreff: Re: axis2 session scopes
Ah, I see now.
So the idea is that either a single instance of a serviceClient is reused across calls or if new instances must be used it must be directed to the specific serviceGroupId. Right?
For soapSession scope as mentioned in the article we use the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
for transportSession what is the approach? The above method returns null (since there is no replyto header I guess) but on transport which is based on cookies, I set to client the managesession attribute to true, and still can not re-use session across different service clients objects. What is the approach on transport?
Thank you!
________________________________
From: Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 PM
Subject: Re: axis2 session scopes
The problem is not sending the servicegroupID or the session related information. When you keep sending request it always create a new instances, only way to stop is to copy the servicegroupID from the previous request and send it alone with the next request.
One another way to get this work is try following, then you will see the expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
The article describes how to keep session, without needing to reuse the same ServiceClient object. I.e. keep session using different ServiceClient objects.
My question was, why is the web service class being re-instantiated for each web service invocation for ALL scopes except application.
I have configured client to manage session (and engaged addressing for soapsession) and the web service class keeps-on re-instantiated for each web service call. So, I am not having a problem on keeping/using session (I am using messageContext and serviceContext for session related data).
I can not understand why the web service class is re-instantiated.
Is this a bug in Axis2? If not, what is the logic for this? I think that for enterprise level application this is too costly.
Is some sample code needed for this?
Thank you
________________________________
From: Deepal jayasinghe <de...@gmail.com> <ma...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:25:50 PM
Subject: Re: axis2 session scopes
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
Hi Deepal,
I have tried all scopes. In client side I have set manage session to true.
For instance. I set the session scope in services.xml to "transportsession".
In the web service I use
MessageContext messageContext = MessageContext.getCurrentMessageContext();
ServiceContext scontext = messageContext.getServiceContext();
To store values to last per session. e.g.
scontext.setProperty("SUM","" + sum); and I re-use sum across invocations.
Also in client I do:
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
I can see that the data I place in MessageContext persist across invocations but I also see that a new web service instance is created per invocation.
So my question is, that the session data will persist but I should expect the web service to be re-instantiated per invocation?
In the example of transport session I have in the web service:
public class MyLittleWebService{
publicMyLittleWebService(){
System.out.println("MyLittleService constructor called! New Instance created!");
}
And the constructor is being called across all invocations for all types of session except application.
So I understand I must use session data, but this is the expected behavior as well? Re-instantiate the WS per invocation? Isn't it expensive for enterprise level web services?
If I am confused on this, please help me out understand what am I doing wrong here.
Thank you
________________________________
From: Deepal Jayasinghe <de...@opensource.lk> <ma...@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 4:08:04 PM
Subject: Re: axis2 session scopes
On 1/23/2011 7:11 AM, am am wrote:
I am starting on axis2 (1.5.4).
I am looking into the various session scopes for web services (request, soapsession etc).
By experimenting, I notice that in all scopes except the application scope, there is a new instance of my web service being created per service call.
Only by setting the scope to "application" in the services.xml, the web service is instantiated only once, and being re-used across all web service calls.
My testing for this, was actually a print statement in the web service constructor. The constructor was called for scope="request" or scope="soapsession" or scope="transportsession" for each ws call.
So my question is the following: Is this the case in axis2? And if yes, for non-trivial web services, isn't it very costly (to re-instantiate per service call)?
Is the recommended approach to use application scope services? Or my understanding is wrong here?
Nope, this is not the way Axis2 does the session. As I can see you have not send session related information to manage the session. For example, when you use soapsession you need to send the session ID, which you can do simply by engaging addressing module to both client and server side and setting the setManageSession(true) in the option object. Similarly, when you use transport session you are required to send the cookies, which can also done by setting the above property. For the request session, it creates service instance for each invocation.
Deepal
Thank you!
Re: AW: AW: axis2 session scopes
Posted by am am <ak...@yahoo.com>.
Hi Josef,
Thank you very much for your time spend in helping me understand this. The
analysis was great!
I followed your tip, and tried to use tcpmon on transportsession but I saw that
the only session info send to client was the JSESSIONID in the cookie (which is
defined in sevlet spec). I.e. The HTTP response was this:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=1CE110EACECC0AE176C6610DA81D0446; Path=/axis2
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 27 Jan 2011 16:49:43 GMT
f3
10
0
So I am not sure how you worked arround this, in the example you mention on the
MS WFC Client. You note:
>>Sending the request later by MS WCF Client without that cookie did not work.
>>I hade to add to the http-header all the same bit's as the axis2 java client was
>>sending in scope="soapsession".
>>
But I do not know how you got that info to send it. In the reply in my test,
there is only the JSESSIONID send back to the client. And if I make a web
service invocation by different instances of web service client, the object is
re-instantiated on the server.
Thank you!!!
________________________________
From: Stadelmann Josef <jo...@axa-winterthur.ch>
To: java-user@axis.apache.org
Sent: Thu, January 27, 2011 12:29:50 PM
Subject: AW: AW: axis2 session scopes
To my understanding, the trick with servicegroupId in the soap address header
makes only real sense in scope="soapsession".
Given we can have several transports one being http, another being RPC or JSM or
whatever, I would want to have a solution selecting my service instance
independent from transport protocol used. So I should avoid managing it on the
transport level.
Managing how to reach the service providing object (instance) for a particular
user session thread should go in my mind only to the SOAP/XML stack and avoid
any transport level inclusion/cluttering.
That is the reason why I selected long lasting objects and have one user session
thread ending in a instance of a service-class (an object) which gets is message
via web service facilities. (just my view). And it works perfect, without any
big overhead. It was that decision which allowed us to see an web service
providing object as a holder of a HP-WSIT-JAVABEAN which keeps the IPC channel
open (to send data from Java to the C-Wrapper-World) to an OpenVMS legacy
process 80'000 LOC's of PASCAL plus Oracle DB. Saying, we have to integrate and
speak to legacy server processes on a per user session thread basis. (which is
overhead I know, but we do legacy-integration, and many old process is just not
multi-threaded, or thread aware).
As long as a users client keeps the session/thread open to the service
providing object, as long will each message reach the same object identified by
the servicegroupId. (think of the servicegroupId as of an "object-identifier"
very similar to an IOR in the CORBA world).
It's the server which must give you this object reference, and it's the
responsibility of the client to re-use/re-ship it with each request to the
axis2 engine to reach "the object".
What is a transport session? When does the transport session start and when does
it end?
Now comes my weak bit! I never used scope="transportsession" So I have read this
excellent article.
http://www.developer.com/open/print.php/3620661
(do me a favor and forget about the space in the scope=" transportsession" as
shown in the article,
as it may lead to problems (somewhere there is a scope dispatcher in java if
scope.compare("soapsession") then …-
so he looks at strings very carefully :-))
Given a user client has several transport sessions open, how does it chose about
which one to use? Maybe you have 3 stubs?
Manage sessions by transport means:
Articel:
The lifetime of the session is controlled by the transport, not by Axis2;
If axis2 has no control over the session then we need to have our service
instance identifying bits located somewhere else, maybe on the transport level,
maybe inside the http-header, but for sure not a the soap/xml protocol level;
So it's very likely that a cookie is used for that service instance, and that
the axis2 server has to return the cookie to the client as it creates the
service instance, a cookie the client has to re-use again to hit the same
service instance.
(very much like an IOR in CORAB)
That is when you have to start massaging your http header in the client and
sniff in a cookie;
and you do it at the transport level and not at the soap/xml header.
Article:
One of the key advantages of the Transport session over other sessions is that
you can talk to multiple service groups within one transport session
Where is the identifying bit selecting the service group wanted?
My learning with scope="soapsession" and long lasting session was:
I had to implement a MS WCF Client talking to an Apache Axis2 web service server
with long lasting sessions (state full service providing objects)!
I had to fake axis2! I had to give the axis2 engine what it needs to think that
an axis2 client is talking.
By a TCP Monitor or by Wireshark I figured out what axis2 engine expects.
Observation, and not expected at all but it was there on the wire: a http cookie
was sent by the axis2 client.
Sending the request later by MS WCF Client without that cookie did not work.
I hade to add to the http-header all the same bit's as the axis2 java client was
sending in scope="soapsession".
This http-header-massage in addition to the servicegroupId header on the
soap/xml level made me build interceptors at the client which intercept each
outgoing and incoming request, just to add/retrieve all required information to
reuse them during the next send/request.
Josef
Von:am am [mailto:akmeref@yahoo.com]
Gesendet: Mittwoch, 26. Januar 2011 17:50
An: java-user@axis.apache.org
Betreff: Re: AW: axis2 session scopes
Hi Josef,
Thank you very much for the detailed analysis!!! Now it very clear in my mind.
This solves the soapsession.
I am wondering though, is the servicegroupId required in the transportsession as
well?
In transport session, session info are send back-and-forth via cookies and so it
is transparent to the programmer. The only thing needed is to setManageSession
to true in client object.
At least this is what I understood from reading articles.
But trying it out, a new web service is created each time.
So now I am thinking if I need to send the servicegroupId in the
transportsession as well.
- If yes, then how do I find it? Because the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new
QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
used for soapsession throws NPE for transportsession, which I guess makes sense
since there is no addressing header in transportsession. But how do I find it,
to send it in next request?
- If no, what am I doing wrong to observe this behavior? I.e. new instance of
web service? I have set session to transportscope and the managesession to true
in client. Isn't it enough?
Thanks!
________________________________
From:Stadelmann Josef <jo...@axa-winterthur.ch>
To: java-user@axis.apache.org
Sent: Wed, January 26, 2011 11:44:53 AM
Subject: AW: axis2 session scopes
We use scope="soapsession" in the following case
A: we have 3 different client programs running from the same PC each with the
same WS stub.
B: Each one of the 3 client shall span one dedicated user session thread to a
dedicated web service based object, which is an instance of your web service
class.
(Think how a client-object finds its server-object via a strong link) cA talks
to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or sC. Just a 1
to 1 object relation.
B: By using scope="soapsession" the initial call of cA to the web service
creates for our service class a web service object sA (as instance) and it
returns a servicegroupId Header to the calling client cA.
C: The client cA is now required to send his received servicegroupId in the
addressing header with each request to the axis2 engine which dispatches the
request to sA
D: that way we can guarantee you that each users client session thread i.e. cA,
reaches always the same service object (instance) sA
E: and by adjusting a timeout in the client and the server we have long lasting
objects, client and server side, objects talking to each other for hours. And we
have no need to re-establish for each request a new stub or a new service
providing object.
Josef
Von:am am [mailto:akmeref@yahoo.com]
Gesendet: Montag, 24. Januar 2011 17:47
An: java-user@axis.apache.org
Betreff: Re: axis2 session scopes
Ah, I see now.
So the idea is that either a single instance of a serviceClient is reused across
calls or if new instances must be used it must be directed to the specific
serviceGroupId. Right?
For soapSession scope as mentioned in the article we use the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new
QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
for transportSession what is the approach? The above method returns null (since
there is no replyto header I guess) but on transport which is based on cookies,
I set to client the managesession attribute to true, and still can not re-use
session across different service clients objects. What is the approach on
transport?
Thank you!
________________________________
From:Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 PM
Subject: Re: axis2 session scopes
The problem is not sending the servicegroupID or the session related
information. When you keep sending request it always create a new instances,
only way to stop is to copy the servicegroupID from the previous request and
send it alone with the next request.
One another way to get this work is try following, then you will see the
expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
The article describes how to keep session, without needing to reuse the same
ServiceClient object. I.e. keep session using different ServiceClient objects.
My question was, why is the web service class being re-instantiated for each web
service invocation for ALL scopes except application.
I have configured client to manage session (and engaged addressing for
soapsession) and the web service class keeps-on re-instantiated for each web
service call. So, I am not having a problem on keeping/using session (I am using
messageContext and serviceContext for session related data).
I can not understand why the web service class is re-instantiated.
Is this a bug in Axis2? If not, what is the logic for this? I think that for
enterprise level application this is too costly.
Is some sample code needed for this?
Thank you
________________________________
From:Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:25:50 PM
Subject: Re: axis2 session scopes
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
Hi Deepal,
I have tried all scopes. In client side I have set manage session to true.
For instance. I set the session scope in services.xml to "transportsession".
In the web service I use
MessageContext messageContext = MessageContext.getCurrentMessageContext();
ServiceContext scontext = messageContext.getServiceContext();
To store values to last per session. e.g.
scontext.setProperty("SUM","" + sum); and I re-use sum across invocations.
Also in client I do:
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
I can see that the data I place in MessageContext persist across invocations but
I also see that a new web service instance is created per invocation.
So my question is, that the session data will persist but I should expect the
web service to be re-instantiated per invocation?
In the example of transport session I have in the web service:
public class MyLittleWebService{
publicMyLittleWebService(){
System.out.println("MyLittleService constructor called! New Instance
created!");
}
And the constructor is being called across all invocations for all types of
session except application.
So I understand I must use session data, but this is the expected behavior as
well? Re-instantiate the WS per invocation? Isn't it expensive for enterprise
level web services?
If I am confused on this, please help me out understand what am I doing wrong
here.
Thank you
________________________________
From:Deepal Jayasinghe <de...@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 4:08:04 PM
Subject: Re: axis2 session scopes
On 1/23/2011 7:11 AM, am am wrote:
I am starting on axis2 (1.5.4).
I am looking into the various session scopes for web services (request,
soapsession etc).
By experimenting, I notice that in all scopes except the application scope,
there is a new instance of my web service being created per service call.
Only by setting the scope to "application" in the services.xml, the web service
is instantiated only once, and being re-used across all web service calls.
My testing for this, was actually a print statement in the web service
constructor. The constructor was called for scope="request" or
scope="soapsession" or scope="transportsession" for each ws call.
So my question is the following: Is this the case in axis2? And if yes, for
non-trivial web services, isn't it very costly (to re-instantiate per service
call)?
Is the recommended approach to use application scope services? Or my
understanding is wrong here?
Nope, this is not the way Axis2 does the session. As I can see you have not send
session related information to manage the session. For example, when you use
soapsession you need to send the session ID, which you can do simply by
engaging addressing module to both client and server side and setting the
setManageSession(true) in the option object. Similarly, when you use transport
session you are required to send the cookies, which can also done by setting the
above property. For the request session, it creates service instance for each
invocation.
Deepal
Thank you!
AW: AW: axis2 session scopes
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
To my understanding, the trick with servicegroupId in the soap address
header makes only real sense in scope="soapsession".
Given we can have several transports one being http, another being RPC
or JSM or whatever, I would want to have a solution selecting my service
instance independent from transport protocol used. So I should avoid
managing it on the transport level.
Managing how to reach the service providing object (instance) for a
particular user session thread should go in my mind only to the SOAP/XML
stack and avoid any transport level inclusion/cluttering.
That is the reason why I selected long lasting objects and have one user
session thread ending in a instance of a service-class (an object) which
gets is message via web service facilities. (just my view). And it works
perfect, without any big overhead. It was that decision which allowed us
to see an web service providing object as a holder of a HP-WSIT-JAVABEAN
which keeps the IPC channel open (to send data from Java to the
C-Wrapper-World) to an OpenVMS legacy process 80'000 LOC's of PASCAL
plus Oracle DB. Saying, we have to integrate and speak to legacy server
processes on a per user session thread basis. (which is overhead I
know, but we do legacy-integration, and many old process is just not
multi-threaded, or thread aware).
As long as a users client keeps the session/thread open to the service
providing object, as long will each message reach the same object
identified by the servicegroupId. (think of the servicegroupId as of an
"object-identifier" very similar to an IOR in the CORBA world).
It's the server which must give you this object reference, and it's the
responsibility of the client to re-use/re-ship it with each request to
the axis2 engine to reach "the object".
What is a transport session? When does the transport session start and
when does it end?
Now comes my weak bit! I never used scope="transportsession" So I have
read this excellent article.
http://www.developer.com/open/print.php/3620661
(do me a favor and forget about the space in the scope="
transportsession" as shown in the article,
as it may lead to problems (somewhere there is a scope dispatcher in
java if scope.compare("soapsession") then ...-
so he looks at strings very carefully :-))
Given a user client has several transport sessions open, how does it
chose about which one to use? Maybe you have 3 stubs?
Manage sessions by transport means:
Articel:
The lifetime of the session is controlled by the transport, not by
Axis2;
If axis2 has no control over the session then we need to have our
service instance identifying bits located somewhere else, maybe on the
transport level, maybe inside the http-header, but for sure not a the
soap/xml protocol level;
So it's very likely that a cookie is used for that service instance, and
that the axis2 server has to return the cookie to the client as it
creates the service instance, a cookie the client has to re-use again to
hit the same service instance.
(very much like an IOR in CORAB)
That is when you have to start massaging your http header in the client
and sniff in a cookie;
and you do it at the transport level and not at the soap/xml header.
Article:
One of the key advantages of the Transport session over other sessions
is that you can talk to multiple service groups within one transport
session
Where is the identifying bit selecting the service group wanted?
My learning with scope="soapsession" and long lasting session was:
I had to implement a MS WCF Client talking to an Apache Axis2 web
service server with long lasting sessions (state full service providing
objects)!
I had to fake axis2! I had to give the axis2 engine what it needs to
think that an axis2 client is talking.
By a TCP Monitor or by Wireshark I figured out what axis2 engine
expects.
Observation, and not expected at all but it was there on the wire: a
http cookie was sent by the axis2 client.
Sending the request later by MS WCF Client without that cookie did not
work.
I hade to add to the http-header all the same bit's as the axis2 java
client was sending in scope="soapsession".
This http-header-massage in addition to the servicegroupId header on the
soap/xml level made me build interceptors at the client which intercept
each outgoing and incoming request, just to add/retrieve all required
information to reuse them during the next send/request.
Josef
Von: am am [mailto:akmeref@yahoo.com]
Gesendet: Mittwoch, 26. Januar 2011 17:50
An: java-user@axis.apache.org
Betreff: Re: AW: axis2 session scopes
Hi Josef,
Thank you very much for the detailed analysis!!! Now it very clear in my
mind.
This solves the soapsession.
I am wondering though, is the servicegroupId required in the
transportsession as well?
In transport session, session info are send back-and-forth via cookies
and so it is transparent to the programmer. The only thing needed is to
setManageSession to true in client object.
At least this is what I understood from reading articles.
But trying it out, a new web service is created each time.
So now I am thinking if I need to send the servicegroupId in the
transportsession as well.
- If yes, then how do I find it? Because the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().ge
t(new
QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
used for soapsession throws NPE for transportsession, which I guess
makes sense since there is no addressing header in transportsession. But
how do I find it, to send it in next request?
- If no, what am I doing wrong to observe this behavior? I.e. new
instance of web service? I have set session to transportscope and the
managesession to true in client. Isn't it enough?
Thanks!
________________________________
From: Stadelmann Josef <jo...@axa-winterthur.ch>
To: java-user@axis.apache.org
Sent: Wed, January 26, 2011 11:44:53 AM
Subject: AW: axis2 session scopes
We use scope="soapsession" in the following case
A: we have 3 different client programs running from the same PC each
with the same WS stub.
B: Each one of the 3 client shall span one dedicated user session thread
to a dedicated web service based object, which is an instance of your
web service class.
(Think how a client-object finds its server-object via a strong link) cA
talks to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or
sC. Just a 1 to 1 object relation.
B: By using scope="soapsession" the initial call of cA to the web
service creates for our service class a web service object sA (as
instance) and it returns a servicegroupId Header to the calling client
cA.
C: The client cA is now required to send his received servicegroupId in
the addressing header with each request to the axis2 engine which
dispatches the request to sA
D: that way we can guarantee you that each users client session thread
i.e. cA, reaches always the same service object (instance) sA
E: and by adjusting a timeout in the client and the server we have long
lasting objects, client and server side, objects talking to each other
for hours. And we have no need to re-establish for each request a new
stub or a new service providing object.
Josef
Von: am am [mailto:akmeref@yahoo.com]
Gesendet: Montag, 24. Januar 2011 17:47
An: java-user@axis.apache.org
Betreff: Re: axis2 session scopes
Ah, I see now.
So the idea is that either a single instance of a serviceClient is
reused across calls or if new instances must be used it must be directed
to the specific serviceGroupId. Right?
For soapSession scope as mentioned in the article we use the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().ge
t(new
QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
for transportSession what is the approach? The above method returns null
(since there is no replyto header I guess) but on transport which is
based on cookies, I set to client the managesession attribute to true,
and still can not re-use session across different service clients
objects. What is the approach on transport?
Thank you!
________________________________
From: Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 PM
Subject: Re: axis2 session scopes
The problem is not sending the servicegroupID or the session related
information. When you keep sending request it always create a new
instances, only way to stop is to copy the servicegroupID from the
previous request and send it alone with the next request.
One another way to get this work is try following, then you will see the
expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebServi
ce"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
The article describes how to keep session, without needing to reuse the
same ServiceClient object. I.e. keep session using different
ServiceClient objects.
My question was, why is the web service class being re-instantiated for
each web service invocation for ALL scopes except application.
I have configured client to manage session (and engaged addressing for
soapsession) and the web service class keeps-on re-instantiated for each
web service call. So, I am not having a problem on keeping/using session
(I am using messageContext and serviceContext for session related data).
I can not understand why the web service class is re-instantiated.
Is this a bug in Axis2? If not, what is the logic for this? I think that
for enterprise level application this is too costly.
Is some sample code needed for this?
Thank you
________________________________
From: Deepal jayasinghe <de...@gmail.com> <ma...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:25:50 PM
Subject: Re: axis2 session scopes
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
Hi Deepal,
I have tried all scopes. In client side I have set manage session to
true.
For instance. I set the session scope in services.xml to
"transportsession".
In the web service I use
MessageContext messageContext =
MessageContext.getCurrentMessageContext();
ServiceContext scontext = messageContext.getServiceContext();
To store values to last per session. e.g.
scontext.setProperty("SUM","" + sum); and I re-use sum across
invocations.
Also in client I do:
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebServi
ce"));
options.setManageSession(true);
client.setOptions(opts);
I can see that the data I place in MessageContext persist across
invocations but I also see that a new web service instance is created
per invocation.
So my question is, that the session data will persist but I should
expect the web service to be re-instantiated per invocation?
In the example of transport session I have in the web service:
public class MyLittleWebService{
publicMyLittleWebService(){
System.out.println("MyLittleService constructor called! New
Instance created!");
}
And the constructor is being called across all invocations for all types
of session except application.
So I understand I must use session data, but this is the expected
behavior as well? Re-instantiate the WS per invocation? Isn't it
expensive for enterprise level web services?
If I am confused on this, please help me out understand what am I doing
wrong here.
Thank you
________________________________
From: Deepal Jayasinghe <de...@opensource.lk>
<ma...@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 4:08:04 PM
Subject: Re: axis2 session scopes
On 1/23/2011 7:11 AM, am am wrote:
I am starting on axis2 (1.5.4).
I am looking into the various session scopes for web services (request,
soapsession etc).
By experimenting, I notice that in all scopes except the application
scope, there is a new instance of my web service being created per
service call.
Only by setting the scope to "application" in the services.xml, the web
service is instantiated only once, and being re-used across all web
service calls.
My testing for this, was actually a print statement in the web service
constructor. The constructor was called for scope="request" or
scope="soapsession" or scope="transportsession" for each ws call.
So my question is the following: Is this the case in axis2? And if yes,
for non-trivial web services, isn't it very costly (to re-instantiate
per service call)?
Is the recommended approach to use application scope services? Or my
understanding is wrong here?
Nope, this is not the way Axis2 does the session. As I can see you have
not send session related information to manage the session. For example,
when you use soapsession you need to send the session ID, which you can
do simply by engaging addressing module to both client and server side
and setting the setManageSession(true) in the option object. Similarly,
when you use transport session you are required to send the cookies,
which can also done by setting the above property. For the request
session, it creates service instance for each invocation.
Deepal
Thank you!
Re: AW: axis2 session scopes
Posted by am am <ak...@yahoo.com>.
Hi Josef,
Thank you very much for the detailed analysis!!! Now it very clear in my mind.
This solves the soapsession.
I am wondering though, is the servicegroupId required in the transportsession as
well?
In transport session, session info are send back-and-forth via cookies and so it
is transparent to the programmer. The only thing needed is to setManageSession
to true in client object.
At least this is what I understood from reading articles.
But trying it out, a new web service is created each time.
So now I am thinking if I need to send the servicegroupId in the
transportsession as well.
- If yes, then how do I find it? Because the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new
QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));used for
soapsession throws NPE for transportsession, which I guess makes sense since
there is no addressing header in transportsession. But how do I find it, to send
it in next request?
- If no, what am I doing wrong to observe this behavior? I.e. new instance of
web service? I have set session to transportscope and the managesession to true
in client. Isn't it enough?
Thanks!
________________________________
From: Stadelmann Josef <jo...@axa-winterthur.ch>
To: java-user@axis.apache.org
Sent: Wed, January 26, 2011 11:44:53 AM
Subject: AW: axis2 session scopes
We use scope="soapsession" in the following case
A: we have 3 different client programs running from the same PC each with the
same WS stub.
B: Each one of the 3 client shall span one dedicated user session thread to a
dedicated web service based object, which is an instance of your web service
class.
(Think how a client-object finds its server-object via a strong link) cA talks
to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or sC. Just a 1
to 1 object relation.
B: By using scope="soapsession" the initial call of cA to the web service
creates for our service class a web service object sA (as instance) and it
returns a servicegroupId Header to the calling client cA.
C: The client cA is now required to send his received servicegroupId in the
addressing header with each request to the axis2 engine which dispatches the
request to sA
D: that way we can guarantee you that each users client session thread i.e. cA,
reaches always the same service object (instance) sA
E: and by adjusting a timeout in the client and the server we have long lasting
objects, client and server side, objects talking to each other for hours. And we
have no need to re-establish for each request a new stub or a new service
providing object.
Josef
Von:am am [mailto:akmeref@yahoo.com]
Gesendet: Montag, 24. Januar 2011 17:47
An: java-user@axis.apache.org
Betreff: Re: axis2 session scopes
Ah, I see now.
So the idea is that either a single instance of a serviceClient is reused across
calls or if new instances must be used it must be directed to the specific
serviceGroupId. Right?
For soapSession scope as mentioned in the article we use the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new
QName("http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId"));
for transportSession what is the approach? The above method returns null (since
there is no replyto header I guess) but on transport which is based on cookies,
I set to client the managesession attribute to true, and still can not re-use
session across different service clients objects. What is the approach on
transport?
Thank you!
________________________________
From:Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 PM
Subject: Re: axis2 session scopes
The problem is not sending the servicegroupID or the session related
information. When you keep sending request it always create a new instances,
only way to stop is to copy the servicegroupID from the previous request and
send it alone with the next request.
One another way to get this work is try following, then you will see the
expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
The article describes how to keep session, without needing to reuse the same
ServiceClient object. I.e. keep session using different ServiceClient objects.
My question was, why is the web service class being re-instantiated for each web
service invocation for ALL scopes except application.
I have configured client to manage session (and engaged addressing for
soapsession) and the web service class keeps-on re-instantiated for each web
service call. So, I am not having a problem on keeping/using session (I am using
messageContext and serviceContext for session related data).
I can not understand why the web service class is re-instantiated.
Is this a bug in Axis2? If not, what is the logic for this? I think that for
enterprise level application this is too costly.
Is some sample code needed for this?
Thank you
________________________________
From:Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:25:50 PM
Subject: Re: axis2 session scopes
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
Hi Deepal,
I have tried all scopes. In client side I have set manage session to true.
For instance. I set the session scope in services.xml to "transportsession".
In the web service I use
MessageContext messageContext = MessageContext.getCurrentMessageContext();
ServiceContext scontext = messageContext.getServiceContext();
To store values to last per session. e.g.
scontext.setProperty("SUM","" + sum); and I re-use sum across invocations.
Also in client I do:
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
I can see that the data I place in MessageContext persist across invocations but
I also see that a new web service instance is created per invocation.
So my question is, that the session data will persist but I should expect the
web service to be re-instantiated per invocation?
In the example of transport session I have in the web service:
public class MyLittleWebService{
publicMyLittleWebService(){
System.out.println("MyLittleService constructor called! New Instance
created!");
}
And the constructor is being called across all invocations for all types of
session except application.
So I understand I must use session data, but this is the expected behavior as
well? Re-instantiate the WS per invocation? Isn't it expensive for enterprise
level web services?
If I am confused on this, please help me out understand what am I doing wrong
here.
Thank you
________________________________
From:Deepal Jayasinghe <de...@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 4:08:04 PM
Subject: Re: axis2 session scopes
On 1/23/2011 7:11 AM, am am wrote:
I am starting on axis2 (1.5.4).
I am looking into the various session scopes for web services (request,
soapsession etc).
By experimenting, I notice that in all scopes except the application scope,
there is a new instance of my web service being created per service call.
Only by setting the scope to "application" in the services.xml, the web service
is instantiated only once, and being re-used across all web service calls.
My testing for this, was actually a print statement in the web service
constructor. The constructor was called for scope="request" or
scope="soapsession" or scope="transportsession" for each ws call.
So my question is the following: Is this the case in axis2? And if yes, for
non-trivial web services, isn't it very costly (to re-instantiate per service
call)?
Is the recommended approach to use application scope services? Or my
understanding is wrong here?
Nope, this is not the way Axis2 does the session. As I can see you have not send
session related information to manage the session. For example, when you use
soapsession you need to send the session ID, which you can do simply by
engaging addressing module to both client and server side and setting the
setManageSession(true) in the option object. Similarly, when you use transport
session you are required to send the cookies, which can also done by setting the
above property. For the request session, it creates service instance for each
invocation.
Deepal
Thank you!
AW: axis2 session scopes
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
We use scope="soapsession" in the following case
A: we have 3 different client programs running from the same PC each
with the same WS stub.
B: Each one of the 3 client shall span one dedicated user session thread
to a dedicated web service based object, which is an instance of your
web service class.
(Think how a client-object finds its server-object via a strong link) cA
talks to sA, cB talks to sB, cC talks to sC, but never cA talks to sB or
sC. Just a 1 to 1 object relation.
B: By using scope="soapsession" the initial call of cA to the web
service creates for our service class a web service object sA (as
instance) and it returns a servicegroupId Header to the calling client
cA.
C: The client cA is now required to send his received servicegroupId in
the addressing header with each request to the axis2 engine which
dispatches the request to sA
D: that way we can guarantee you that each users client session thread
i.e. cA, reaches always the same service object (instance) sA
E: and by adjusting a timeout in the client and the server we have long
lasting objects, client and server side, objects talking to each other
for hours. And we have no need to re-establish for each request a new
stub or a new service providing object.
Josef
Von: am am [mailto:akmeref@yahoo.com]
Gesendet: Montag, 24. Januar 2011 17:47
An: java-user@axis.apache.org
Betreff: Re: axis2 session scopes
Ah, I see now.
So the idea is that either a single instance of a serviceClient is
reused across calls or if new instances must be used it must be directed
to the specific serviceGroupId. Right?
For soapSession scope as mentioned in the article we use the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().ge
t(new QName("http://ws.apache.org/namespaces/axis2","ServiceGroupId
<http://ws.apache.org/namespaces/axis2%22,%22ServiceGroupId> "));
for transportSession what is the approach? The above method returns null
(since there is no replyto header I guess) but on transport which is
based on cookies, I set to client the managesession attribute to true,
and still can not re-use session across different service clients
objects. What is the approach on transport?
Thank you!
________________________________
From: Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 PM
Subject: Re: axis2 session scopes
The problem is not sending the servicegroupID or the session related
information. When you keep sending request it always create a new
instances, only way to stop is to copy the servicegroupID from the
previous request and send it alone with the next request.
One another way to get this work is try following, then you will see the
expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebServi
ce"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
The article describes how to keep session, without needing to reuse the
same ServiceClient object. I.e. keep session using different
ServiceClient objects.
My question was, why is the web service class being re-instantiated for
each web service invocation for ALL scopes except application.
I have configured client to manage session (and engaged addressing for
soapsession) and the web service class keeps-on re-instantiated for each
web service call. So, I am not having a problem on keeping/using session
(I am using messageContext and serviceContext for session related data).
I can not understand why the web service class is re-instantiated.
Is this a bug in Axis2? If not, what is the logic for this? I think that
for enterprise level application this is too costly.
Is some sample code needed for this?
Thank you
________________________________
From: Deepal jayasinghe <de...@gmail.com> <ma...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:25:50 PM
Subject: Re: axis2 session scopes
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
Hi Deepal,
I have tried all scopes. In client side I have set manage session to
true.
For instance. I set the session scope in services.xml to
"transportsession".
In the web service I use
MessageContext messageContext =
MessageContext.getCurrentMessageContext();
ServiceContext scontext = messageContext.getServiceContext();
To store values to last per session. e.g.
scontext.setProperty("SUM","" + sum); and I re-use sum across
invocations.
Also in client I do:
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebServi
ce"));
options.setManageSession(true);
client.setOptions(opts);
I can see that the data I place in MessageContext persist across
invocations but I also see that a new web service instance is created
per invocation.
So my question is, that the session data will persist but I should
expect the web service to be re-instantiated per invocation?
In the example of transport session I have in the web service:
public class MyLittleWebService{
publicMyLittleWebService(){
System.out.println("MyLittleService constructor called! New
Instance created!");
}
And the constructor is being called across all invocations for all types
of session except application.
So I understand I must use session data, but this is the expected
behavior as well? Re-instantiate the WS per invocation? Isn't it
expensive for enterprise level web services?
If I am confused on this, please help me out understand what am I doing
wrong here.
Thank you
________________________________
From: Deepal Jayasinghe <de...@opensource.lk>
<ma...@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 4:08:04 PM
Subject: Re: axis2 session scopes
On 1/23/2011 7:11 AM, am am wrote:
I am starting on axis2 (1.5.4).
I am looking into the various session scopes for web services (request,
soapsession etc).
By experimenting, I notice that in all scopes except the application
scope, there is a new instance of my web service being created per
service call.
Only by setting the scope to "application" in the services.xml, the web
service is instantiated only once, and being re-used across all web
service calls.
My testing for this, was actually a print statement in the web service
constructor. The constructor was called for scope="request" or
scope="soapsession" or scope="transportsession" for each ws call.
So my question is the following: Is this the case in axis2? And if yes,
for non-trivial web services, isn't it very costly (to re-instantiate
per service call)?
Is the recommended approach to use application scope services? Or my
understanding is wrong here?
Nope, this is not the way Axis2 does the session. As I can see you have
not send session related information to manage the session. For example,
when you use soapsession you need to send the session ID, which you can
do simply by engaging addressing module to both client and server side
and setting the setManageSession(true) in the option object. Similarly,
when you use transport session you are required to send the cookies,
which can also done by setting the above property. For the request
session, it creates service instance for each invocation.
Deepal
Thank you!
Re: axis2 session scopes
Posted by am am <ak...@yahoo.com>.
Ah, I see now.
So the idea is that either a single instance of a serviceClient is reused across
calls or if new instances must be used it must be directed to the specific
serviceGroupId. Right?
For soapSession scope as mentioned in the article we use the
client.getServiceContext().getTargetEPR().getAllReferenceParameters().get(new
QName("http://ws.apache.org/namespaces/axis2","ServiceGroupId"));for
transportSession what is the approach? The above method returns null (since
there is no replyto header I guess) but on transport which is based on cookies,
I set to client the managesession attribute to true, and still can not re-use
session across different service clients objects. What is the approach on
transport?
Thank you!
________________________________
From: Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:51:51 PM
Subject: Re: axis2 session scopes
The problem is not sending the servicegroupID or the session related
information. When you keep sending request it always create a new instances,
only way to stop is to copy the servicegroupID from the previous request and
send it alone with the next request.
One another way to get this work is try following, then you will see the
expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
The article describes how to keep session, without needing to reuse the
same ServiceClient object. I.e. keep session using different
ServiceClient objects.
>My question was, why is the web service class being re-instantiated for
>each web service invocation for ALL scopes except application.
>I have configured client to manage session (and engaged addressing for
>soapsession) and the web service class keeps-on re-instantiated for each
>web service call. So, I am not having a problem on keeping/using session
>(I am using messageContext and serviceContext for session related data).
>I can not understand why the web service class is re-instantiated.
>Is this a bug in Axis2? If not, what is the logic for this? I think that
>for enterprise level application this is too costly.
>Is some sample code needed for this?
>
>Thank you
>
>
>
>
>
>
>
>
________________________________
From: Deepal jayasinghe <de...@gmail.com>
>To: java-user@axis.apache.org
>Sent: Sun, January 23, 2011 10:25:50 PM
>Subject: Re: axis2 session scopes
>
>Now, I got the point. For that you need to try the following.
>
>http://wso2.org/library/3184
>
>Deepal
>
>Hi Deepal,
>>
>>I have tried all scopes. In client side I have set manage
>>session to true.
>>For instance. I set the session scope in services.xml to
>>"transportsession".
>>In the web service I use
>>MessageContext messageContext =
>>MessageContext.getCurrentMessageContext();
>>ServiceContext scontext =
messageContext.getServiceContext();
>>To store values to last per session. e.g.
>>scontext.setProperty("SUM","" + sum); and I re-use sum across
>>invocations.
>>
>>Also in client I do:
>>ServiceClient client = new ServiceClient();
>>Options options = new Options();
>>options.setTo(new
>>EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
>>options.setManageSession(true);
>>client.setOptions(opts);
>>I can see that the data I place in MessageContext persist
>>across invocations but I also see that a new web service
>>instance is created per invocation.
>>
>>So my question is, that the session data will persist but I
>>should expect the web service to be re-instantiated per
>>invocation?
>>
>>In the example of transport session I have in the web
>service:
>>public class MyLittleWebService{
>>
>> publicMyLittleWebService(){
>> System.out.println("MyLittleService constructor
>>called! New Instance created!");
>> }
>>
>>And the constructor is being called across all invocations for
>>all types of session except application.
>>
>>So I understand I must use session data, but this is the
>>expected behavior as well? Re-instantiate the WS per
>>invocation? Isn't it expensive for enterprise level web
>>services?
>>If I am confused on this, please help me out understand what
>>am I doing wrong here.
>>
>>Thank you
>>
>>
>>
>>
________________________________
From: Deepal Jayasinghe <de...@opensource.lk>
>>To: java-user@axis.apache.org
>>Sent: Sun, January 23, 2011 4:08:04 PM
>>Subject: Re: axis2 session scopes
>>
>>
>>
>>On 1/23/2011 7:11 AM, am am wrote:
>>I am starting on axis2 (1.5.4).
>>>I am looking into the various session scopes for web
>>>services (request, soapsession etc).
>>>By experimenting, I notice that in all scopes except the
>>>application scope, there is a new instance of my web
>>>service being created per service call.
>>>Only by setting the scope to "application" in the
>>>services.xml, the web service is instantiated only once,
>>>and being re-used across all web service calls.
>>>My testing for this, was actually a print statement in
>>>the web service constructor. The constructor was called
>>>for scope="request" or scope="soapsession" or
>>>scope="transportsession" for each ws call.
>>>So my question is the following: Is this the case in
>>>axis2? And if yes, for non-trivial web services, isn't
>>>it very costly (to re-instantiate per service call)?
>>>Is the recommended approach to use application scope
>>>services? Or my understanding is wrong here?
>>>
Nope, this is not the way Axis2 does the session. As I can
see you have not send session related information to manage
the session. For example, when you use soapsession you need
to send the session ID, which you can do simply by engaging
addressing module to both client and server side and setting
the setManageSession(true) in the option object. Similarly,
when you use transport session you are required to send the
cookies, which can also done by setting the above property.
For the request session, it creates service instance for
each invocation.
>
>Deepal
>
>
>>Thank you!
>>
>>
>>
>>
>>
>>
>
Re: axis2 session scopes
Posted by Deepal jayasinghe <de...@gmail.com>.
The problem is not sending the servicegroupID or the session related
information. When you keep sending request it always create a new
instances, only way to stop is to copy the servicegroupID from the
previous request and send it alone with the next request.
One another way to get this work is try following, then you will see the
expected behavior.
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
client.invokeBlocking();
client.invokeBlocking();
client.invokeBlocking();
If we do the above, you only get one service instances.
Deepal
> The article describes how to keep session, without needing to reuse
> the same ServiceClient object. I.e. keep session using different
> ServiceClient objects.
> My question was, why is the web service class being re-instantiated
> for each web service invocation for ALL scopes except application.
> I have configured client to manage session (and engaged addressing for
> soapsession) and the web service class keeps-on re-instantiated for
> each web service call. So, I am not having a problem on keeping/using
> session (I am using messageContext and serviceContext for session
> related data).
> I can not understand why the web service class is re-instantiated.
> Is this a bug in Axis2? If not, what is the logic for this? I think
> that for enterprise level application this is too costly.
> Is some sample code needed for this?
>
> Thank you
>
>
>
>
> ------------------------------------------------------------------------
> *From:* Deepal jayasinghe <de...@gmail.com>
> *To:* java-user@axis.apache.org
> *Sent:* Sun, January 23, 2011 10:25:50 PM
> *Subject:* Re: axis2 session scopes
>
> Now, I got the point. For that you need to try the following.
>
> http://wso2.org/library/3184
>
> Deepal
>> Hi Deepal,
>>
>> I have tried all scopes. In client side I have set manage session to
>> true.
>> For instance. I set the session scope in services.xml to
>> "transportsession".
>> In the web service I use
>> MessageContext messageContext =
>> MessageContext.getCurrentMessageContext();
>> ServiceContext scontext = messageContext.getServiceContext();
>> To store values to last per session. e.g.
>> scontext.setProperty("SUM","" + sum); and I re-use sum across
>> invocations.
>> Also in client I do:
>> ServiceClient client = new ServiceClient();
>> Options options = new Options();
>> options.setTo(new
>> EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
>> options.setManageSession(true);
>> client.setOptions(opts);
>> I can see that the data I place in MessageContext persist across
>> invocations but I also see that a new web service instance is created
>> per invocation.
>> So my question is, that the session data will persist but I should
>> expect the web service to be re-instantiated per invocation?
>> In the example of transport session I have in the web service:
>> public class MyLittleWebService{
>>
>> publicMyLittleWebService(){
>> System.out.println("MyLittleService constructor called! New
>> Instance created!");
>> }
>>
>> And the constructor is being called across all invocations for all
>> types of session except application.
>> So I understand I must use session data, but this is the expected
>> behavior as well? Re-instantiate the WS per invocation? Isn't it
>> expensive for enterprise level web services?
>> If I am confused on this, please help me out understand what am I
>> doing wrong here.
>>
>> Thank you
>>
>> ------------------------------------------------------------------------
>> *From:* Deepal Jayasinghe <de...@opensource.lk>
>> *To:* java-user@axis.apache.org
>> *Sent:* Sun, January 23, 2011 4:08:04 PM
>> *Subject:* Re: axis2 session scopes
>>
>>
>>
>> On 1/23/2011 7:11 AM, am am wrote:
>>> I am starting on axis2 (1.5.4).
>>> I am looking into the various session scopes for web services
>>> (request, soapsession etc).
>>> By experimenting, I notice that in all scopes except the application
>>> scope, there is a new instance of my web service being created per
>>> service call.
>>> Only by setting the scope to "application" in the services.xml, the
>>> web service is instantiated only once, and being re-used across all
>>> web service calls.
>>> My testing for this, was actually a print statement in the web
>>> service constructor. The constructor was called for scope="request"
>>> or scope="soapsession" or scope="transportsession" for each ws call.
>>> So my question is the following: Is this the case in axis2? And if
>>> yes, for non-trivial web services, isn't it very costly (to
>>> re-instantiate per service call)?
>>> Is the recommended approach to use application scope services? Or my
>>> understanding is wrong here?
>> Nope, this is not the way Axis2 does the session. As I can see you
>> have not send session related information to manage the session. For
>> example, when you use soapsession you need to send the session ID,
>> which you can do simply by engaging addressing module to both client
>> and server side and setting the setManageSession(true) in the option
>> object. Similarly, when you use transport session you are required to
>> send the cookies, which can also done by setting the above property.
>> For the request session, it creates service instance for each
>> invocation.
>>
>> Deepal
>>>
>>> Thank you!
>>>
>>>
>>>
>>>
>>
>
>
Re: axis2 session scopes
Posted by am am <ak...@yahoo.com>.
Hi Deepal,
The article describes how to keep session, without needing to reuse the same
ServiceClient object. I.e. keep session using different ServiceClient objects.
My question was, why is the web service class being re-instantiated for each web
service invocation for ALL scopes except application.
I have configured client to manage session (and engaged addressing for
soapsession) and the web service class keeps-on re-instantiated for each web
service call. So, I am not having a problem on keeping/using session (I am using
messageContext and serviceContext for session related data).
I can not understand why the web service class is re-instantiated.
Is this a bug in Axis2? If not, what is the logic for this? I think that for
enterprise level application this is too costly.
Is some sample code needed for this?
Thank you
________________________________
From: Deepal jayasinghe <de...@gmail.com>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 10:25:50 PM
Subject: Re: axis2 session scopes
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
Hi Deepal,
>
>I have tried all scopes. In client side I have set manage session to
>true.
>For instance. I set the session scope in services.xml to
>"transportsession".
>In the web service I use
>MessageContext messageContext =
>MessageContext.getCurrentMessageContext();
>ServiceContext scontext = messageContext.getServiceContext();
>To store values to last per session. e.g.
>scontext.setProperty("SUM","" + sum); and I re-use sum across
>invocations.
>
>Also in client I do:
>ServiceClient client = new ServiceClient();
>Options options = new Options();
>options.setTo(new
>EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
>options.setManageSession(true);
>client.setOptions(opts);
>I can see that the data I place in MessageContext persist across
>invocations but I also see that a new web service instance is created
>per invocation.
>
>So my question is, that the session data will persist but I should
>expect the web service to be re-instantiated per invocation?
>
>In the example of transport session I have in the web service:
>public class MyLittleWebService{
>
> publicMyLittleWebService(){
> System.out.println("MyLittleService constructor called! New
>Instance created!");
> }
>
>And the constructor is being called across all invocations for all
>types of session except application.
>
>So I understand I must use session data, but this is the expected
>behavior as well? Re-instantiate the WS per invocation? Isn't it
>expensive for enterprise level web services?
>If I am confused on this, please help me out understand what am I
>doing wrong here.
>
>Thank you
>
>
>
>
________________________________
From: Deepal Jayasinghe <de...@opensource.lk>
>To: java-user@axis.apache.org
>Sent: Sun, January 23, 2011 4:08:04 PM
>Subject: Re: axis2 session scopes
>
>
>
>On 1/23/2011 7:11 AM, am am wrote:
>I am starting on axis2 (1.5.4).
>>I am looking into the various session scopes for web services
>>(request, soapsession etc).
>>By experimenting, I notice that in all scopes except the
>>application scope, there is a new instance of my web service
>>being created per service call.
>>Only by setting the scope to "application" in the services.xml,
>>the web service is instantiated only once, and being re-used
>>across all web service calls.
>>My testing for this, was actually a print statement in the web
>>service constructor. The constructor was called for
>>scope="request" or scope="soapsession" or
>>scope="transportsession" for each ws call.
>>So my question is the following: Is this the case in axis2? And
>>if yes, for non-trivial web services, isn't it very costly (to
>>re-instantiate per service call)?
>>Is the recommended approach to use application scope services?
>>Or my understanding is wrong here?
>>
Nope, this is not the way Axis2 does the session. As I can see you
have not send session related information to manage the session. For
example, when you use soapsession you need to send the session ID,
which you can do simply by engaging addressing module to both
client and server side and setting the setManageSession(true) in the
option object. Similarly, when you use transport session you are
required to send the cookies, which can also done by setting the
above property. For the request session, it creates service instance
for each invocation.
Deepal
>Thank you!
>
>
>
>
>
>
Re: axis2 session scopes
Posted by Deepal jayasinghe <de...@gmail.com>.
Now, I got the point. For that you need to try the following.
http://wso2.org/library/3184
Deepal
> Hi Deepal,
>
> I have tried all scopes. In client side I have set manage session to true.
> For instance. I set the session scope in services.xml to
> "transportsession".
> In the web service I use
> MessageContext messageContext = MessageContext.getCurrentMessageContext();
> ServiceContext scontext = messageContext.getServiceContext();
> To store values to last per session. e.g.
> scontext.setProperty("SUM","" + sum); and I re-use sum across
> invocations.
> Also in client I do:
> ServiceClient client = new ServiceClient();
> Options options = new Options();
> options.setTo(new
> EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
> options.setManageSession(true);
> client.setOptions(opts);
> I can see that the data I place in MessageContext persist across
> invocations but I also see that a new web service instance is created
> per invocation.
> So my question is, that the session data will persist but I should
> expect the web service to be re-instantiated per invocation?
> In the example of transport session I have in the web service:
> public class MyLittleWebService{
>
> publicMyLittleWebService(){
> System.out.println("MyLittleService constructor called! New
> Instance created!");
> }
>
> And the constructor is being called across all invocations for all
> types of session except application.
> So I understand I must use session data, but this is the expected
> behavior as well? Re-instantiate the WS per invocation? Isn't it
> expensive for enterprise level web services?
> If I am confused on this, please help me out understand what am I
> doing wrong here.
>
> Thank you
>
> ------------------------------------------------------------------------
> *From:* Deepal Jayasinghe <de...@opensource.lk>
> *To:* java-user@axis.apache.org
> *Sent:* Sun, January 23, 2011 4:08:04 PM
> *Subject:* Re: axis2 session scopes
>
>
>
> On 1/23/2011 7:11 AM, am am wrote:
>> I am starting on axis2 (1.5.4).
>> I am looking into the various session scopes for web services
>> (request, soapsession etc).
>> By experimenting, I notice that in all scopes except the application
>> scope, there is a new instance of my web service being created per
>> service call.
>> Only by setting the scope to "application" in the services.xml, the
>> web service is instantiated only once, and being re-used across all
>> web service calls.
>> My testing for this, was actually a print statement in the web
>> service constructor. The constructor was called for scope="request"
>> or scope="soapsession" or scope="transportsession" for each ws call.
>> So my question is the following: Is this the case in axis2? And if
>> yes, for non-trivial web services, isn't it very costly (to
>> re-instantiate per service call)?
>> Is the recommended approach to use application scope services? Or my
>> understanding is wrong here?
> Nope, this is not the way Axis2 does the session. As I can see you
> have not send session related information to manage the session. For
> example, when you use soapsession you need to send the session ID,
> which you can do simply by engaging addressing module to both client
> and server side and setting the setManageSession(true) in the option
> object. Similarly, when you use transport session you are required to
> send the cookies, which can also done by setting the above property.
> For the request session, it creates service instance for each invocation.
>
> Deepal
>>
>> Thank you!
>>
>>
>>
>>
>
Re: axis2 session scopes
Posted by am am <ak...@yahoo.com>.
Hi Deepal,
I have tried all scopes. In client side I have set manage session to true.
For instance. I set the session scope in services.xml to "transportsession".
In the web service I use
MessageContext messageContext = MessageContext.getCurrentMessageContext();
ServiceContext scontext = messageContext.getServiceContext();
To store values to last per session. e.g.
scontext.setProperty("SUM","" + sum); and I re-use sum across invocations.
Also in client I do:
ServiceClient client = new ServiceClient();
Options options = new Options();
options.setTo(new
EndpointReference("http://127.0.0.1:8080/axis2/services/MyLittleWebService"));
options.setManageSession(true);
client.setOptions(opts);
I can see that the data I place in MessageContext persist across invocations but
I also see that a new web service instance is created per invocation.
So my question is, that the session data will persist but I should expect the
web service to be re-instantiated per invocation?
In the example of transport session I have in the web service:
public class MyLittleWebService{
publicMyLittleWebService(){
System.out.println("MyLittleService constructor called! New Instance
created!");
}
And the constructor is being called across all invocations for all types of
session except application.
So I understand I must use session data, but this is the expected behavior as
well? Re-instantiate the WS per invocation? Isn't it expensive for enterprise
level web services?
If I am confused on this, please help me out understand what am I doing wrong
here.
Thank you
________________________________
From: Deepal Jayasinghe <de...@opensource.lk>
To: java-user@axis.apache.org
Sent: Sun, January 23, 2011 4:08:04 PM
Subject: Re: axis2 session scopes
On 1/23/2011 7:11 AM, am am wrote:
I am starting on axis2 (1.5.4).
>I am looking into the various session scopes for web services (request,
>soapsession etc).
>By experimenting, I notice that in all scopes except the application
>scope, there is a new instance of my web service being created per
>service call.
>Only by setting the scope to "application" in the services.xml, the web
>service is instantiated only once, and being re-used across all web
>service calls.
>My testing for this, was actually a print statement in the web service
>constructor. The constructor was called for scope="request" or
>scope="soapsession" or scope="transportsession" for each ws call.
>So my question is the following: Is this the case in axis2? And if yes,
>for non-trivial web services, isn't it very costly (to re-instantiate
>per service call)?
>Is the recommended approach to use application scope services? Or my
>understanding is wrong here?
>
Nope, this is not the way Axis2 does the session. As I can see you have not
send session related information to manage the session. For example, when
you use soapsession you need to send the session ID, which you can do
simply by engaging addressing module to both client and server side and
setting the setManageSession(true) in the option object. Similarly, when you
use transport session you are required to send the cookies, which can also
done by setting the above property. For the request session, it creates
service instance for each invocation.
Deepal
>Thank you!
>
>
>
>
>
Re: axis2 session scopes
Posted by Deepal Jayasinghe <de...@opensource.lk>.
On 1/23/2011 7:11 AM, am am wrote:
> I am starting on axis2 (1.5.4).
> I am looking into the various session scopes for web services
> (request, soapsession etc).
> By experimenting, I notice that in all scopes except the application
> scope, there is a new instance of my web service being created per
> service call.
> Only by setting the scope to "application" in the services.xml, the
> web service is instantiated only once, and being re-used across all
> web service calls.
> My testing for this, was actually a print statement in the web service
> constructor. The constructor was called for scope="request" or
> scope="soapsession" or scope="transportsession" for each ws call.
> So my question is the following: Is this the case in axis2? And if
> yes, for non-trivial web services, isn't it very costly (to
> re-instantiate per service call)?
> Is the recommended approach to use application scope services? Or my
> understanding is wrong here?
Nope, this is not the way Axis2 does the session. As I can see you have
not send session related information to manage the session. For example,
when you use soapsession you need to send the session ID, which you can
do simply by engaging addressing module to both client and server side
and setting the setManageSession(true) in the option object. Similarly,
when you use transport session you are required to send the cookies,
which can also done by setting the above property. For the request
session, it creates service instance for each invocation.
Deepal
>
> Thank you!
>
>
>
>
axis2 session scopes
Posted by am am <ak...@yahoo.com>.
I am starting on axis2 (1.5.4).
I am looking into the various session scopes for web services (request,
soapsession etc).
By experimenting, I notice that in all scopes except the application scope,
there is a new instance of my web service being created per service call.
Only by setting the scope to "application" in the services.xml, the web service
is instantiated only once, and being re-used across all web service calls.
My testing for this, was actually a print statement in the web service
constructor. The constructor was called for scope="request" or
scope="soapsession" or scope="transportsession" for each ws call.
So my question is the following: Is this the case in axis2? And if yes, for
non-trivial web services, isn't it very costly (to re-instantiate per service
call)?
Is the recommended approach to use application scope services? Or my
understanding is wrong here?
Thank you!
Re: axis2 code generation stubs
Posted by Andreas Veithen <an...@gmail.com>.
See AXIS2-4640 for a discussion about this.
Andreas
On Sun, Jan 23, 2011 at 10:37, am am <ak...@yahoo.com> wrote:
> Hi,
>
> I am starting on axis2 (1.5.4). After doing a wsdl2java code generation, I
> was looking into the artifacts.
> For a service that accepts a String and returns a String an ADBean was
> generated for the in-out params. The bean has some fields and booleans to
> indicate if the value has been set for serialization/de-serialization, but
> could not understand the following code:
> /**
> * Auto generated setter method
> * @param param Value
> */
> public void setValue(java.lang.String param){
>
> if (param != null){
> //update the setting tracker
> localValueTracker = true;
> } else {
> localValueTracker = true;
>
> }
>
> this.localValue=param;
>
>
> }
> I mean localValueTracker is always set to true. Is this correct? I imagine
> that for the case that param == null the localValueTracker would be set to
> false.
>
> Thank you
>
>