axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimuthu Gamage" <>
Subject Re: RE : abstract base type support
Date Sat, 19 Apr 2008 03:07:24 GMT
Hi Carl,

Your idea of putting all the logic inside the basetype is logical, but
unfortunately java generated intermediate XML file (which is feed to
xsl to generate code) doesn't have much information supportting that.
That is in the base type we don't have information of the sub types.
Only the sub type have information on the base type parameters and
base type name.

I went through how WSDL2Java solve this issue. In serializing they
doesn't have any issue. since there they already have the adb object,
they just call adb_object.serialize() and the correct method is

But in parsing (deserializing) , they compare all the type information
and return the correct adb class object using logic inside

                  if (

"".equals(namespaceURI) &&



We currently doesn't generate an ExtensionMapper, infact it should be
able to generate from CADBBeanSourceTemplate.
Our ExtensionMapper would be look like this,

void *adb_get_serialize_parameters_func(typename) {
   if(typename == "|CommerceAd") {
             return adb_CommerAd_serialize_parameters; //the function pointers..
   else {
              return NULL;

// same way with deserialize functions

So unless we change the WSDL2Java code-generation engine we should
satisfy with this. And we can put a char* for the first parameter of
the structure in a way when we cast adb object to (char*) it returns
the type information.

And I believe it is ok to live with void* if we are doing validations
at right times and may be some good doc comments in the function
declaration?. Besides we have to use this approach only for adb
classes related to complex types.

Anyway if you are ready to change the code generation engine, we may
be able to come with more c-friendly design like the one you


On Sat, Apr 19, 2008 at 12:08 AM, Lefrancois, Carl
<> wrote:
> Hi Dimuthu,
>  Such a detailed email is promising.  If I understand correctly, the
>  functionality my project needs is already working (at least partly) in
>  the WSDL2Java tool?
>  My comments / ideas inline below:
>  > I think we don't have much problem with the current designs, WSDL2Java
>  tool with the same design as WSDL2C has been successfully implemented
>  most of the
>  > schema constructs. But WSDL2C has some unimplemented features which I
>  believed to be very uncommon in practice. But whenever user is
>  interested in
>  > something, the developers tend to implement it most of the time with
>  the users support.
>  Good.  I understand the tool is based on Java and I downloaded the java
>  source already when I started the project.  If I can make an acceptable
>  estimate for the work required, I may be asked to develop this piece.
>  Having dev support is a big plus, and even better is the idea that only
>  the translation to C needs to be done (XSLT transform on already
>  completed generic output from WSDL2Java)
>  > Here is a little tip on how to implement xsi:type based serialization
>  and deserialization (just my idea).
>  >
>  > currently each wsdl type/ element is mapped to an adb object. This adb
>  object contains
>  For my application I have worked with the generated adb_*.c files so the
>  structure is already a bit familiar.
>  >
>  > Say type animal is extended by cat and dog types.
>  > so there will be adb objects with the names: adb_animal, adb_cat and
>  adb_dog.
>  >
>  > ... To deserialize, create an object of the sub-type:
> > 1. if (xml.get_attribute("xsi:type") == "cat") {
>  > 2.      var = adb_cat_create();
>  >
>  >
> > Anyway implementing this in C is not much simple. The first thing it
>  doesn't support RTTI and it doesn't support type extension. you can't
>  put adb_cat
>  > object to where adb_animal is expected unless the signature is changed
>  to void*.
> > And all the places of serialization and deserialization functions
>  signature where adb objects expects, should be changed to void*
>  pointers.
>  This seems like the big problem: how to mimic the polymorphism used in
>  generating ADB objects in Java using standard C.  In Java, the
>  deserialisation routine can return an adb_cat object using an adb_animal
>  * but in C as you point out there is only void * which can easily cause
>  crashes.
>  My first thought was rather to use the existing adb_animal.c class to
>  contain the derived-type attributes, and use the
>  adb_animal_cat_attribute_is_nil() approach when consuming deserialised
>  objects, rather than creating an adb_cat object and returning it as void
>  *.  The disadvantage with this may be greater file size (in my project
>  some .c files are >500kB!) but other than that it seems logical.
>  E.g. to deserialize, create an object of the base-type and set sub-type
>  parameters:
>  Adb_cat derives from adb_animal and extends with element IsDeclawed
>  defined with minOccurs = 1:
>  1. if (xml.get_attribute("xsi:type") == "cat") {
>  2. var = adb_animal_create();
>  3. var_set_isDeclawed( // value from IsDeclawed element )
>  And now client can consume like:
>  1. bool isDeclawed;
>  2. var = adb_animal_deserialize();
>  3. if (var.ConcreteType() == "cat") {
>  4.      isDeclawed = adb_animal_get_IsDeclawed();
>  Likewise when serialising, the generated code can check
>  1. if (concreteType == "cat") {
>  2.      if (adb_animal_IsDeclawed_is_nil()) {
>  3.              Return error;
>  The question then becomes: from the output document created by
>  WSDL2Java, can the XSLT transform support creation of this code in the
>  adb_animal.c class?
>  I am not convinced which way is the best.  It seems we have different
>  ideas but I think you are better placed to know which is easiest to do
>  with an XSLT transformation of the current generated document.  I have
>  only heard of XSLT but never used it.
>  Thoughts?
>  Have a good weekend
>  Carl
>   _____
>  "Ce message est confidentiel, a l'usage exclusif du destinataire
>  ci-dessus et son contenu ne represente en aucun cas un engagement de la
>  part de AXA, sauf en cas de stipulation expresse et par ecrit de la part
>  de AXA. Toute publication, utilisation ou diffusion, meme partielle,
>  doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce
>  message, merci d'en avertir immediatement l'expediteur."
>  "This e-mail message is confidential, for the exclusive use of the
>  addressee and its contents shall not constitute a commitment by AXA,
>  except as otherwise specifically provided in writing by AXA. Any
>  unauthorized disclosure, use or dissemination, either whole or partial,
>  is prohibited. If you are not the intended recipient of the message,
>  please notify the sender immediately."
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
>  For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message