You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Harmeet Bedi <ha...@intraspect.com> on 2000/06/29 05:39:11 UTC
Processing Requests with custom mapping types
I wanted to Extract a Request made by a SOAP Client. The SOAP client defines
its own Mapping.
The server side needs to specify the mapping at the request extraction time.
The way seems to be(from soaprouter.jsp)
Call call = Call.extractFromEnvelope(callEnv, serviceManager);
<Call> does not allow me to specify a custom mapping registry.
To specify the mapping registry I had to change
org.apache.soap.rpc.RPCMessage
from
protected static RPCMessage extractFromEnvelope(Envelope env,
ServiceManager svcMgr,
boolean isResponse,
SOAPMappingRegistry respSMR)
to
public static RPCMessage extractFromEnvelope(Envelope env,
ServiceManager svcMgr,
boolean isResponse,
SOAPMappingRegistry respSMR)
Then this invocation on the server side worked.
SOAPMappingRegistry smr = new SOAPMappingRegistry();
smr.mapTypes(....);
Call call = (Call)RPCMessage.extractFromEnvelope(callEnv, serviceManager,
false,smr)
Is there a way to do this in a better manner. I am new to SOAP, so may not
be doing something sensible(yet).
If what I am doing makes sense, would it be useful to change
<org.apache.soap.rpc.RPCMessage> to make <extractFromEnvelope> public.
thanks,
Harmeet
Re: Processing Requests with custom mapping types
Posted by Harmeet Bedi <ha...@intraspect.com>.
----- Original Message -----
From: "Kevin J. Mitchell" <ke...@xmls.com>
Subject: RE: Processing Requests with custom mapping types
> Actually, on the server side, the MR is supplied by the
DeploymentDescriptor
> object that is returned from the ServiceManager passed to
> extractFromEnvelope call. Take a look at RPCMessage.unmarshall...
I tried something like that. My approach was to change the access permission
of <setCachedSMR> method in class <DeploymentDescriptor>
I thought it was easier and possibly safer to change access permission on
<extractFromEnvelope> of RPCMessage. But now I realize it is not good as it
does not tie into the Service Mangager.
And I think your approach is very good. Is your fix availble via CVS ? I
just got the latest source code from /home/cvspublic. But could not find the
changed Deployment Desriptor file.
If the fix is not in the public domain, do you have a feel when it will be
available.
thanks,
Harmeet
>
> I actually had a need to make the server side use a customized subclass of
> SOAPMappingRegistry. The subclass does things like register mappings
common
> to many services, and perform "type of" based serializer/deserializer
> lookups (similar to what is done for Arrays) for Hashtables and
Exceptions.
> I did this by modifying the DeploymentDescriptor to have a "default" SMR
> class. The default SMR classname can be read from/written to the XML
version
> of the DeploymentDescriptor. If no default SMR is specified or the class
is
> not found, it falls back to SOAPMappingRegistry...
>
Re: Processing Requests with custom mapping types
Posted by Harmeet Bedi <ha...@intraspect.com>.
----- Original Message -----
From: "Kevin J. Mitchell" <ke...@xmls.com>
Subject: RE: Processing Requests with custom mapping types
> Actually, on the server side, the MR is supplied by the
DeploymentDescriptor
> object that is returned from the ServiceManager passed to
> extractFromEnvelope call. Take a look at RPCMessage.unmarshall...
I tried something like that. My approach was to change the access permission
of <setCachedSMR> method in class <DeploymentDescriptor>
I thought it was easier and possibly safer to change access permission on
<extractFromEnvelope> of RPCMessage. But now I realize it is not good as it
does not tie into the Service Mangager.
And I think your approach is very good. Is your fix availble via CVS ? I
just got the latest source code from /home/cvspublic. But could not find the
changed Deployment Desriptor file.
If the fix is not in the public domain, do you have a feel when it will be
available.
thanks,
Harmeet
>
> I actually had a need to make the server side use a customized subclass of
> SOAPMappingRegistry. The subclass does things like register mappings
common
> to many services, and perform "type of" based serializer/deserializer
> lookups (similar to what is done for Arrays) for Hashtables and
Exceptions.
> I did this by modifying the DeploymentDescriptor to have a "default" SMR
> class. The default SMR classname can be read from/written to the XML
version
> of the DeploymentDescriptor. If no default SMR is specified or the class
is
> not found, it falls back to SOAPMappingRegistry...
>
RE: Processing Requests with custom mapping types
Posted by "Kevin J. Mitchell" <ke...@xmls.com>.
Actually, on the server side, the MR is supplied by the DeploymentDescriptor
object that is returned from the ServiceManager passed to
extractFromEnvelope call. Take a look at RPCMessage.unmarshall...
I actually had a need to make the server side use a customized subclass of
SOAPMappingRegistry. The subclass does things like register mappings common
to many services, and perform "type of" based serializer/deserializer
lookups (similar to what is done for Arrays) for Hashtables and Exceptions.
I did this by modifying the DeploymentDescriptor to have a "default" SMR
class. The default SMR classname can be read from/written to the XML version
of the DeploymentDescriptor. If no default SMR is specified or the class is
not found, it falls back to SOAPMappingRegistry...
In case there is interest, here is the output of diff -u for the changes to
DeploymentDescriptor...
@@ -35,6 +35,7 @@
String[] methods;
TypeMapping[] mappings;
transient SOAPMappingRegistry cachedSMR;
+ Class defaultSMRClass = null;
/**
* Constructor.
@@ -56,6 +57,13 @@
return id;
}
+ public void setDefaultSMRClass(Class _defaultSMRClass) {
+ defaultSMRClass = _defaultSMRClass;
+ }
+
+ public Class getDefaultSMRClass() {
+ return defaultSMRClass;
+ }
/**
* Lifecyle of the object providing the service.
*/
@@ -196,7 +204,9 @@
pw.println (" </isd:provider>");
if (mappings != null) {
- pw.println (" <isd:mappings>");
+ pw.println (" <isd:mappings ");
+ if (defaultSMRClass != null) pw.print("defaultRegistryClass=\"" +
defaultSMRClass.getName() + "\">"); else pw.print(">");
+
for (int i = 0; i < mappings.length; i++) {
TypeMapping tm = mappings[i];
pw.print (" <isd:map encodingStyle=\"" + tm.encodingStyle +
@@ -345,6 +355,13 @@
}
if (nl.getLength () == 1) {
e = (Element) nl.item (0);
+ String className = e.getAttribute("defaultRegistryClass");
+ if (className != null) {
+ try {
+ dd.setDefaultSMRClass(Class.forName(className));
+ }
+ catch (Exception defSMRException) {}
+ }
nl = e.getElementsByTagNameNS (Constants.NS_URI_IBM_DEPLOYMENT,
"map");
int nmaps = nl.getLength ();
if (nmaps > 0) {
@@ -412,8 +429,19 @@
if (smr != null) {
return smr;
} else {
- smr = new SOAPMappingRegistry ();
+ if (dd.getDefaultSMRClass() != null) {
+ try {
+ smr = (SOAPMappingRegistry)dd.getDefaultSMRClass().newInstance();
+ }
+ catch (Exception e) {
+ smr = new SOAPMappingRegistry();
+ }
+ }
+ else {
+ smr = new SOAPMappingRegistry ();
+ }
}
+
if (maps != null) {
for (int i = 0; i < maps.length; i++) {
TypeMapping tm = maps[i];
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@intraspect.com]
Sent: Wednesday, June 28, 2000 11:39 PM
To: soap-dev@xml.apache.org
Subject: Processing Requests with custom mapping types
I wanted to Extract a Request made by a SOAP Client. The SOAP client defines
its own Mapping.
The server side needs to specify the mapping at the request extraction time.
The way seems to be(from soaprouter.jsp)
Call call = Call.extractFromEnvelope(callEnv, serviceManager);
<Call> does not allow me to specify a custom mapping registry.
To specify the mapping registry I had to change
org.apache.soap.rpc.RPCMessage
from
protected static RPCMessage extractFromEnvelope(Envelope env,
ServiceManager svcMgr,
boolean isResponse,
SOAPMappingRegistry respSMR)
to
public static RPCMessage extractFromEnvelope(Envelope env,
ServiceManager svcMgr,
boolean isResponse,
SOAPMappingRegistry respSMR)
Then this invocation on the server side worked.
SOAPMappingRegistry smr = new SOAPMappingRegistry();
smr.mapTypes(....);
Call call = (Call)RPCMessage.extractFromEnvelope(callEnv, serviceManager,
false,smr)
Is there a way to do this in a better manner. I am new to SOAP, so may not
be doing something sensible(yet).
If what I am doing makes sense, would it be useful to change
<org.apache.soap.rpc.RPCMessage> to make <extractFromEnvelope> public.
thanks,
Harmeet
RE: Processing Requests with custom mapping types
Posted by "Kevin J. Mitchell" <ke...@xmls.com>.
Actually, on the server side, the MR is supplied by the DeploymentDescriptor
object that is returned from the ServiceManager passed to
extractFromEnvelope call. Take a look at RPCMessage.unmarshall...
I actually had a need to make the server side use a customized subclass of
SOAPMappingRegistry. The subclass does things like register mappings common
to many services, and perform "type of" based serializer/deserializer
lookups (similar to what is done for Arrays) for Hashtables and Exceptions.
I did this by modifying the DeploymentDescriptor to have a "default" SMR
class. The default SMR classname can be read from/written to the XML version
of the DeploymentDescriptor. If no default SMR is specified or the class is
not found, it falls back to SOAPMappingRegistry...
In case there is interest, here is the output of diff -u for the changes to
DeploymentDescriptor...
@@ -35,6 +35,7 @@
String[] methods;
TypeMapping[] mappings;
transient SOAPMappingRegistry cachedSMR;
+ Class defaultSMRClass = null;
/**
* Constructor.
@@ -56,6 +57,13 @@
return id;
}
+ public void setDefaultSMRClass(Class _defaultSMRClass) {
+ defaultSMRClass = _defaultSMRClass;
+ }
+
+ public Class getDefaultSMRClass() {
+ return defaultSMRClass;
+ }
/**
* Lifecyle of the object providing the service.
*/
@@ -196,7 +204,9 @@
pw.println (" </isd:provider>");
if (mappings != null) {
- pw.println (" <isd:mappings>");
+ pw.println (" <isd:mappings ");
+ if (defaultSMRClass != null) pw.print("defaultRegistryClass=\"" +
defaultSMRClass.getName() + "\">"); else pw.print(">");
+
for (int i = 0; i < mappings.length; i++) {
TypeMapping tm = mappings[i];
pw.print (" <isd:map encodingStyle=\"" + tm.encodingStyle +
@@ -345,6 +355,13 @@
}
if (nl.getLength () == 1) {
e = (Element) nl.item (0);
+ String className = e.getAttribute("defaultRegistryClass");
+ if (className != null) {
+ try {
+ dd.setDefaultSMRClass(Class.forName(className));
+ }
+ catch (Exception defSMRException) {}
+ }
nl = e.getElementsByTagNameNS (Constants.NS_URI_IBM_DEPLOYMENT,
"map");
int nmaps = nl.getLength ();
if (nmaps > 0) {
@@ -412,8 +429,19 @@
if (smr != null) {
return smr;
} else {
- smr = new SOAPMappingRegistry ();
+ if (dd.getDefaultSMRClass() != null) {
+ try {
+ smr = (SOAPMappingRegistry)dd.getDefaultSMRClass().newInstance();
+ }
+ catch (Exception e) {
+ smr = new SOAPMappingRegistry();
+ }
+ }
+ else {
+ smr = new SOAPMappingRegistry ();
+ }
}
+
if (maps != null) {
for (int i = 0; i < maps.length; i++) {
TypeMapping tm = maps[i];
-----Original Message-----
From: Harmeet Bedi [mailto:harmeet@intraspect.com]
Sent: Wednesday, June 28, 2000 11:39 PM
To: soap-dev@xml.apache.org
Subject: Processing Requests with custom mapping types
I wanted to Extract a Request made by a SOAP Client. The SOAP client defines
its own Mapping.
The server side needs to specify the mapping at the request extraction time.
The way seems to be(from soaprouter.jsp)
Call call = Call.extractFromEnvelope(callEnv, serviceManager);
<Call> does not allow me to specify a custom mapping registry.
To specify the mapping registry I had to change
org.apache.soap.rpc.RPCMessage
from
protected static RPCMessage extractFromEnvelope(Envelope env,
ServiceManager svcMgr,
boolean isResponse,
SOAPMappingRegistry respSMR)
to
public static RPCMessage extractFromEnvelope(Envelope env,
ServiceManager svcMgr,
boolean isResponse,
SOAPMappingRegistry respSMR)
Then this invocation on the server side worked.
SOAPMappingRegistry smr = new SOAPMappingRegistry();
smr.mapTypes(....);
Call call = (Call)RPCMessage.extractFromEnvelope(callEnv, serviceManager,
false,smr)
Is there a way to do this in a better manner. I am new to SOAP, so may not
be doing something sensible(yet).
If what I am doing makes sense, would it be useful to change
<org.apache.soap.rpc.RPCMessage> to make <extractFromEnvelope> public.
thanks,
Harmeet