Rich, Me and Chris are on the same team :). I have once suggested to reconcile Emitter and SOAP pipeline as far as handling default bean mappings (http://marc.theaimsgroup.com/?l=axis-dev&m=101320802717644&w=2) for making it simple to deploy a set of well defined java classes (those not resulting in any type mapping ambiguity). It wasn't coherently +1 :), so we started building those default beanmappings automatically at deploy time. It's not a big deal really, but I still think it could better be part of Axis runtime.
>1) Why don't you use the WSDL2Java tool to discover which <typeMapping> elements are >needed? It is really the reverse that we're doing... >2) How are you determining the qnames for the mapping ? Two options: a simple xmlns:my-package-app="urn:my.package.app" and qname="my-package-app:myClass" Or the one compliant with existing Emitter (i.e. http://app.package.my kinda thing). This can be easily changed when there is a standard. >4) Your code will need to recoginize JAX-RPC compliant enum classes. Good point. What does the Emitter do for these? >6) Remember that some types (java.math.BigDecimal) are defined as 'basic types'. >-I was unaware of this. Is there a resource for this type of thing in the code base? Chris, I believe these are handled (according to DefaultTypeMappingImpl) java.lang.String.class, java.lang.Boolean.class, java.lang.Double.class, java.lang.Float.class, java.lang.Integer.class, java.math.BigInteger.class, java.math.BigDecimal.class, java.lang.Long.class, java.lang.Short.class, java.lang.Byte.class, byte[].class, java.lang.Byte[].class, javax.xml.rpc.namespace.QName.class, java.lang.Object.class, ?? No ser/deser, is it useful?? java.util.Date.class, Hex.class, java.util.Hashtable.class, java.util.Map.class, java.util.HashMap.class, org.w3c.dom.Element.class, java.util.Vector.class, java.util.List.class, java.util.ArrayList.class, Emitter knows this too via type mapping registry. -- Igor Sedukhin .. ([EMAIL PROTECTED]) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Peake, Chris Sent: Tuesday, February 19, 2002 12:21 PM To: [EMAIL PROTECTED] Subject: RE: <typeMapping> determination programmatically Richard, I am still new to Axis so please excuse the follow on questions. Also, Richard will you look at the comments I have in your questions for me. Thanks so much and for your patience. So, you are saying that if I am trying to create a WS service (WSDDService), I should: 1-I have a java service to deploy 2-then create the WSDL (via JAVA2WSDL) 3-then feed that into WSDL2Java with the options -d Session 4-And some of this output I can inspect prgramatically, then pass this '<typeMappings>' to the WSDDService via the 'new WSDDTypeMapping()' and WSDDService.addTypeMapping(). I obviously don't know axis too well yet. But my task is to create a proper service deployment to be later consumed by a .Net or another consumer type. Please read the following comments too. thanks, chris -----Original Message----- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 16, 2002 11:00 AM To: [EMAIL PROTECTED] Cc: "[EMAIL PROTECTED]" Subject: Re: <typeMapping> determination programmatically 1) Why don't you use the WSDL2Java tool to discover which <typeMapping> elements are needed? Run it with -d Session. -I didn't think about this, so I am studying now 2) How are you determining the qnames for the mapping ? -I don't have a plan at this moment. do you suggest taking them from the generated WSDL? 3) If you are dealing with non-axis clients/servers, it is possible that arrays can be received that use the type="qname of array" format instead of the normal type="soapenc:Array" encoding. To support these cases it is necessary to have <typeMapping> elements for the array qnames. -I'm confused, isn't most any 'service' usually a non-axis client/server? -What does that mean? -I've been seeing traffic about arrays but have not boned up on that yet. 4) Your code will need to recoginize JAX-RPC compliant enum classes. - 5) Your code will need to dive deeper if a bean contains a bean. And needs to handle any looping problems, etc. -I can do this currently, so not a problem but worth noting. 6) Remember that some types (java.math.BigDecimal) are defined as 'basic types'. -I was unaware of this. Is there a resource for this type of thing in the code base? It sounds like what you are trying to do is already available in WSDL2Java. -I will bone up on this for sure. Hope this helps ? If you believe that what you are doing is truly necessary, maybe it should be built into the Axis runtime. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) "Peake, Chris" <[EMAIL PROTECTED] To: "\"[EMAIL PROTECTED]\"" <[EMAIL PROTECTED]> om> cc: Subject: <typeMapping> determination programmatically 02/14/2002 03:03 PM Please respond to axis-user I am programmatically, trying to determine if I need <beanMapping>/<typeMapping> elements in my WSDDService deployment. If I use java reflection on the candidate methods for Web Service deployment and look at the return type and parameter list to see if any of these are NON java basic types then they become <typeMapping>s which I will include in the WSDDService as WSDDTypeMappings. Current constraint is that no special serializer/deserializers are required for any non-basic type. Only the default BeanSerializer and BeanDeserFactor. Assuming the above is correct, the questions I then have are: 1-I assume I must then 'reflect' on these non basic types then. 2-a:if that is true, then do I limit my introspection of this 'bean' to just get/set methods? b:all methods? c:fields? d:Any 'modifer' considerations? 3-So, continually walk the tree down until 'only' basic java types are in the signatures. Any other comments are welcome too. thanks, chris Chris Peake Computer Associates Software Engineer tel: +1 214 473 1375 fax: +1 214 473 1168 [EMAIL PROTECTED]
