[Axis2] [ANN] Apache Axis2/C 1.2.0 Released

[Damitha Kumarage]

Apache Axis2/C Team is pleased to announce the release of Apache Axis2/C
version 1.2.0
You can download this release from
http://ws.apache.org/axis2/c/download.cgi

Key Features

   1. Support for one-way messaging (In-Only) and request response
  messaging (In-Out)
   2. Client APIs: Easy to use service client API and more advanced
operation
  client API
   3. Transports supported: HTTP
  * Inbuilt HTTP server called simple axis server
  * Apache2 httpd module called mod_axis2 for server side
  * IIS module for server side
  * Client transport with ability to enable SSL support
  * Basic HTTP Authentication
  * libcurl based client transport
   4. Module architecture, mechanism to extend the SOAP processing model
   5. WS-Addressing support, both the submission (2004/08) and final
(2005/08)
  versions, implemented as a module
   6. MTOM/XOP support
   7. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages; This
has
  complete XML infoset support
   8. XML parser abstraction
  * Libxml2 wrapper
  * Guththila pull parser support
   9. Both directory based and archive based deployment models for deploying
  services and modules
  10. Description hierarchy providing access to static data of Axis2/C
runtime
  (configuration, service groups, services, operations and messages)
  11. Context hierarchy providing access to dynamic Axis2/C runtime
information
  (corresponding contexts to map to each level of description hierarchy)
  12. Message receiver abstraction
  * Inbuilt raw XML message receiver
  13. Code generation tool for stub and skeleton generation for a given WSDL
  (based on Java tool)
  * Axis Data Binding (ADB) support
  14. Transport proxy support
  15. REST support (more POX like) using both HTTP POST and GET
  16. Comprehensive documentation
  * Axis2/C Manual
  17. WS-Policy implementation called Neethi/C, with WS-SecurityPolicy
extension
  18. TCP Transport, for both client and server side

Major Changes Since Last Release

   1 Improvements to Java tool, WSDL2C, that generates C code
   2 Improvment to Apache2 module so that it
(1) Create a shared memory global pool
(11) create context hierarchy in the global pool
 enabling it to have true application level scope.
   3 Improved Policy
   4 Improvements to thread environment
   5 Improvements to error handling
   6 Memory leak fixes
   7 Many bug fixes

We welcome your early feedback on this implementation.
Thanks for your interest in Axis2/C

-- Apache Axis2/C Team --

RE: Help needed on building custom soap fault in axis2c

[Dave Meier]

I tried the proposed solution for 1.1.0, but it didn't work.  I am using
1.2.0 so the code may have changed.

Anyway, the following code worked well for me to get my custom error
message sent in the faultstring:

  // status.GetMessage() returns a const char*
  axis2_char_t* msg = (axis2_char_t*) axutil_strdup( env,
const_cast( status.GetMessage() ) );
  axutil_error_set_error_message( env->error, msg );
  AXIS2_ERROR_SET( env->error,  (enum axutil_error_codes)
AXUTIL_ERROR_MAX, AXIS2_FAILURE );

The code in axutil_error_get_message() (error.c) will only use
error->message if the code is > AXUTIL_ERROR_MAX.

Note that I had to cast to (enum axutil_error_codes) because I have this
code in a .cpp file.

-Dave.

-Original Message-
From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 04, 2007 11:18 PM
To: Apache AXIS C User List
Subject: Re: Help needed on building custom soap fault in axis2c


Samisa Abeysinghe wrote:
> Subra A Narayanan wrote:
>> Hi Dimuthu,
>>
>> I am using the solution you suggested in your last mail. That 
>> solution is perfect for my application. But I have some concerns. I 
>> saw this line in your code
>>
>> #define MYSERVICE_ERROR_CODES_START (AXIS2_ERROR_LAST + 2000)
>>
>>
>> Will this cause any problems in the future? What if the value of 
>> AXIS2_ERROR_LAST changes? Or what if some other axis2 component (like

>> sandesha or neethi or something else) uses error codes in the same 
>> range? Will I be forced to change my code because of the above 
>> scenarios?
> Yes there is a problem that one would take over this value.
> The solution for this is to define the "register" the error block 
> sizes with Axis2/C axutil_error.h so that there is no room to take 
> over the range.
>
> e.g.
> #define AXUTIL_ERROR_MESSAGE_BLOCK_SIZE 2000 #define 
> NEETHI_ERROR_CODES_START (AXIS2_ERROR_LAST +
> AXUTIL_ERROR_MESSAGE_BLOCK_SIZE)
> #define RAMPART_ERROR_CODES_START (NEETHI_ERROR_CODES_START +
> AXUTIL_ERROR_MESSAGE_BLOCK_SIZE)
> #define SANDESHA2_ERROR_CODES_START (RAMPART_ERROR_CODES_START +
> AXUTIL_ERROR_MESSAGE_BLOCK_SIZE)
> #define SAVAN_ERROR_CODES_START (SANDESHA2_ERROR_CODES_START +
> AXUTIL_ERROR_MESSAGE_BLOCK_SIZE)
> #define USER_ERROR_CODES_START (SAVAN_ERROR_CODES_START +
> AXUTIL_ERROR_MESSAGE_BLOCK_SIZE)
>
> In the future, if we need to add another XYZ error block, we can 
> #define XYZ_ERROR_CODES_START (USER_ERROR_CODES_START +
> AXUTIL_ERROR_MESSAGE_BLOCK_SIZE)
>
BTW, what I am proposing is a future design to solve the situation.
With the current release, 1.1.0, you can use the following for a custom
error:

axutil_error_set_error_message(env->error, error_message);
AXIS2_ERROR_SET(env->error, AXIS2_ERROR_LAST + 1, AXIS2_FAILURE);

We need to improve our error model based on my earlier discussion.

Thanks,
Samisa...
> Samisa...
>>
>> Any help is greatly appreciated.
>>
>> Subra
>>
>>
>>
>> On 10/1/07, *Dimuthu Gamage* <[EMAIL PROTECTED] 
>>  > wrote:
>>
>> Hi Sathya,
>>
>> Please check the attachment. This tries to use custom error
codes.
>> (mostly follow the way Sandhesha/C is using their custom error
>> messages)
>> Anyway still functions like  "axutil_error_get_message" are too
>> inflexible to work with custom error codes. So we need to define
>> our version of the same function.
>>
>> Thanks
>> Dimuthu
>>
>>
>> On 10/1/07, *Sathya Raghunathan* < [EMAIL PROTECTED]
>> > wrote:
>>
>> If i have build a soap fault based on an error code, should i
>> create a global variable in axutil_error_init() function? Can
>> i make use of the axutil_error_messages array?
>>  Thanks
>> Sathya
>>
>>  On 9/29/07, *Dimuthu Gamage* < [EMAIL PROTECTED]
>> > wrote:
>>
>> HI  Sathya,
>>
>> you can follow the attachments. I didnt test it, but it
>> may give some hints to do your work.
>> If you want to build a soap fault base on an error code,
>> you need to keep a global variable to keep the error code
>> and build the soap exception based on that.
>>
>> So It is clear we should have a better mechanism than
this
>> to do that, I think there was a discussion earlier in the
>> same topic in the list sometime ago. We should quickly
>> figure out a good way to do this and fix the code
>> generation templates.
>>
>> Thanks
>> Dimuthu
>>
>>
>>
>> /*axiom_element_set_text(error_ele, env,
>> adb_MyFirstException_get_text(_MyFirstException,env),
>> error_node); */
>>
>> /** instead use following */
>>
>> another_node =
>> adb_MyFirstException_serialize(_MyFirstException, env,
>> NULL, AXIS2_FALSE);
>>   

Re: [Axis2C] Client with xml declaration

[Samisa Abeysinghe]

Atanacio Reyes wrote:

I think xml declaration shouldn't be optional, but mandatory, because soap 
envelope is a xml document. and as xml document can be processed with xslt, 
ajax, W3C-DOM or another technologies directly in the browser. but this is a 
discussion for a WS specification group not for axis2c devs.
  


You are correct, and it is the WS-I gropup, who is trying to ensure 
interoperability, that is saying that it should be optional. So we are 
following the guidelines and we, Axis2/C devs, did not define it.
However, we can choose to implement it the way we want, as long as it 
interops, and that is what we have done. If any other implementation 
does not interop, it is because they mandate XML declaration and that is 
incorrect, as per the specs, and that is not Axis2/C devs fault.


Samisa...


- Original Message 
From: Senaka Fernando <[EMAIL PROTECTED]>
To: axis-c-user@ws.apache.org
Sent: Wednesday, January 16, 2008 9:10:22 PM
Subject: Re: [Axis2C] Client with xml declaration


Hi Samisa, Atanacio,

I see a valid point here in including the xml declaration in the
soap_envelope_serialize() method. However, after querying various
developers it was decided that the addition of the xml declaration was
the responsibility of the authority who does the
soap_envelope_serialize() and therefore has been added at transport
sender level. Another reason to why we took this approach is the
 ability
for the user to specify in the axis2.xml whether or whether not the xml
declaration has to be sent with the SOAP message. I think it is much
cleaner. One more reason was the flexibility we gain in interop
scenarios which meets the WS-I specification that the xml declaration
 is
optional, when it comes to sending.

Regards,
Senaka

On Thu, 2008-01-17 at 06:09 +0530, Samisa Abeysinghe wrote:
  

Senaka Fernando wrote:


Hi Antonio,
This might work. But, I don't believe that writing the XML
  

 declaration is
  

necessarily a part of axiom_soap_envelope_serialize(). This is
  

 because,
  

logically speaking, the XML declaration is not a part of the SOAP
envelope.
  

Logically speaking, a SOAP envelope is an XML document.



By doing this tweak, you are violating the concept of a SOAP
envelope. And, therefore this is not correct according to my
  

 personal
  

belief. Devs, please correct me if I've made any mistake.

  

It is nt possible to include this in OM layer, as we cannot afford to
keep state of the start point of serialization. That would restrict


 our
  

ability to serioalize a given node as we wish when we wish.

Hence for me, the solution by Atanacio looks fine.

Samisa...


Regards,
Senaka

  






  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2C] Client with xml declaration

[Atanacio Reyes]

I think xml declaration shouldn't be optional, but mandatory, because soap 
envelope is a xml document. and as xml document can be processed with xslt, 
ajax, W3C-DOM or another technologies directly in the browser. but this is a 
discussion for a WS specification group not for axis2c devs.

- Original Message 
From: Senaka Fernando <[EMAIL PROTECTED]>
To: axis-c-user@ws.apache.org
Sent: Wednesday, January 16, 2008 9:10:22 PM
Subject: Re: [Axis2C] Client with xml declaration


Hi Samisa, Atanacio,

I see a valid point here in including the xml declaration in the
soap_envelope_serialize() method. However, after querying various
developers it was decided that the addition of the xml declaration was
the responsibility of the authority who does the
soap_envelope_serialize() and therefore has been added at transport
sender level. Another reason to why we took this approach is the
 ability
for the user to specify in the axis2.xml whether or whether not the xml
declaration has to be sent with the SOAP message. I think it is much
cleaner. One more reason was the flexibility we gain in interop
scenarios which meets the WS-I specification that the xml declaration
 is
optional, when it comes to sending.

Regards,
Senaka

On Thu, 2008-01-17 at 06:09 +0530, Samisa Abeysinghe wrote:
> Senaka Fernando wrote:
> > Hi Antonio,
> > This might work. But, I don't believe that writing the XML
 declaration is
> > necessarily a part of axiom_soap_envelope_serialize(). This is
 because,
> > logically speaking, the XML declaration is not a part of the SOAP
> > envelope.
>
> Logically speaking, a SOAP envelope is an XML document.
>
> > By doing this tweak, you are violating the concept of a SOAP
> > envelope. And, therefore this is not correct according to my
 personal
> > belief. Devs, please correct me if I've made any mistake.
> >
>
> It is nt possible to include this in OM layer, as we cannot afford to
> keep state of the start point of serialization. That would restrict
 our
> ability to serioalize a given node as we wish when we wish.
>
> Hence for me, the solution by Atanacio looks fine.
>
> Samisa...
> > Regards,
> > Senaka
> >
>





  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to generate C++ (not C) code using WSDL2C

[Samisa Abeysinghe]

Arseny wrote:

Hello!
Wsdl2ws from axis 1.2 generated stub header using classes.
Is it possible class for stub header using wsdl2c tool in axis2 
instead of C-style functions?


Nop. C++ support has not been implemeted.

Thanks,
Samisa...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to generate C++ (not C) code using WSDL2C

[Arseny]

Hello!
Wsdl2ws from axis 1.2 generated stub header using classes.
Is it possible class for stub header using wsdl2c tool in axis2 instead 
of C-style functions?


Thanks in advance!


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]