You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by "Lefrancois, Carl" <Ca...@axa-canada.com> on 2008/04/21 15:23:04 UTC
RE : RE : abstract base type support
Hi Dimuthu,
So the question is how best to support run-time type information in a C environment. I really like your mention of using a char * as first member of the structure.
With void * comes crashes, but you are right, it is not a bad way to proceed. Proceed with caution :)
>From your position of experience with the existing process, you see what the currently generated XML file supports best for rendering type serializing / deserializing code. I hope I get a chance to look at this interesting problem, because I would like to understand how xsl transform could put sub-type information into the base type node. This approach may be backward and not in the spirit of good oo design so I will rather rethink on how to mimic RTTI in C instead.
For now I am working on a quick hack to already generated stub files and maybe later I will be able to put some time into an addition to the code generation process.
Regards,
Carl
-----Message d'origine-----
De : Dimuthu Gamage [mailto:dimuthuc@gmail.com]
Envoyé : vendredi, avril 18, 2008 23:07
À : Apache AXIS C User List
Objet : Re: RE : abstract base type support
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 called.
But in parsing (deserializing) , they compare all the type information and return the correct adb class object using logic inside ExtensionMapper.java.
if (
"https://adwords.google.com/api/adwords/v11".equals(namespaceURI) &&
"CommerceAd".equals(typeName)){
return com.google.adwords.api.adwords.v11.CommerceAd.Factory.parse(reader);
}
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 == "https://adwords.google.com/api/adwords/v11|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 suggested.
Thanks
Dimuthu
On Sat, Apr 19, 2008 at 12:08 AM, Lefrancois, Carl <Ca...@axa-canada.com> 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: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org