Re: Looking for a debugger for axis2c

[Supun Kamburugamuva]

Hi,

There is a VS 2005 solution in the ides/vc/axis2c folder of Axis2/C source
distribution. You can use that project.

Supun.

On Tue, Jun 10, 2008 at 11:09 PM, Gupta, Shivam <[EMAIL PROTECTED]> wrote:

>  Hello,
>
> I have tried but was unsuccessful in managing to debug axis on Visula
> Studio 2005. Could you provide me a link to some tutorial or document that
> would guide me about creating a project in VS2005. I want to import Axis2/c
> as a project in VS2005.
>
> Thanks,
> Shivam
>
>  --
> *From:* Rajika Kumarasiri [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, June 10, 2008 6:45 PM
> *To:* Apache AXIS C Developers List
> *Subject:* Re: Looking for a debugger for axis2c
>
> You can try gdb on Linux based platforms and Micrsoft Visual Studio 2005
> for Windows platform.
>
> -Rajika
>
> On Tue, Jun 10, 2008 at 6:25 PM, Gupta, Shivam <[EMAIL PROTECTED]>
> wrote:
>
>>  Hello,
>>
>>Could someone suggest me the best debugger that could be used to debug
>> Axis2/C.
>>
>> Thanks,
>> Shivam
>>
>
>
>
> --
> comp.lang.c - http://groups.google.com/group/comp.lang.c/topics
>

[jira] Commented: (AXIS2C-1191) Add Documentation for AMQP Transport

[Dushshantha Chandradasa (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604135#action_12604135
 ] 

Dushshantha Chandradasa commented on AXIS2C-1191:
-

applied the patch

> Add Documentation for AMQP Transport
> 
>
> Key: AXIS2C-1191
> URL: https://issues.apache.org/jira/browse/AXIS2C-1191
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: Current (Nightly)
>Reporter: Danushka Menikkumbura
> Fix For: Current (Nightly)
>
> Attachments: AXIS2C-1191-V2.patch, AXIS2C-1191.patch
>
>
> Modify existing docs to have AMQP installation guide.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Question about AXIS2_PARAM_CHECK

[Supun Kamburugamuva]

Hi Damitha,

Do we have lots of code written in the way that you have mentioned? If yes,
we may have to keep the existing code. But as you have mentioned previously
if we are neglecting a error and calling another function that implies two
things. Actually error is not an error that we should be concerned of or we
are doing bad coding. In both cases we should remove the unnecessary else
part.

I have done a profiling recently and it shows that the function with the
greatest hit count is axutil_error_set_status_code. This function takes so
much time that it is around half the time of what guththila_next has taken
(guththila_next is a function with a very high workload).

Regards,
Supun..

On Tue, Jun 10, 2008 at 1:34 AM, Damitha Kumarage <[EMAIL PROTECTED]>
wrote:

> Hi,
> I had the same concern and tried a similar kind of fix few weeks back. But
> because of the following explanation it seems we have to bear with the
> current code.
>
> Suppose we have implemented your fix. say we call to functions x, y and z
> in that order. Say inside function x it set an error code status.
>
> Now we call y. Inside y() we neglect the error code and say we do even a
> database commit.
> Now we call to z(). At the beginning of z say we do an param check. If all
> parameters are good to go it should pass param checks. But it return an
> error (because of previously set error status in function x)  even when all
> parameters are good. This is unfair for function z() and it is also
> misleading.
>
> So the best thing to do is to handle error status before calling any
> important function which has param checkings etc. For example in function
> y() we have even done a database commit  neglecting the error status which
> is not good.
>
> thanks
> Damitha.
>
>
> Dimuthu Gamage wrote:
>
>  Hi devs,
>>
>> Currently in AXIS2_PARAM_CHECK, if the param is null we set the status
>> code to AXIS2_FAILURE and if not null set the status code AXIS2_SUCCESSS
>>
>> #define AXIS2_PARAM_CHECK(error, object, error_return)  \
>>if (!object)\
>>{   \
>>AXIS2_ERROR_SET_ERROR_NUMBER(error,
>> AXIS2_ERROR_INVALID_NULL_PARAM); \
>>AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE);  \
>>return error_return;\
>>}   \
>>else\
>>{   \
>>AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);  \
>>}
>>
>>
>> My question is, is it ok to set the status code to AXIS2_SUCCESS,
>> Because
>> 1. If  we are in happy path, the status code is already AXIS2_SUCCESS, we
>> don't need to explicitly set that.
>> 2. The macro can overwrite the status, That is if the status is already
>> set to failure by an early case, this macro will overwrite the status to
>> SUCCESS which is wrong.
>>
>> So my suggestion is to remove the else part from that macro?. Please let
>> me know your ideas, I may be wrong on this.
>>
>> Thanks
>> Dimuthu
>>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Closed: (AXIS2C-1162) Axis2/C does not invoke the phases correctly when there are module defined phases.

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage closed AXIS2C-1162.


Resolution: Fixed

This is not an issue as this is the designed behaviour. Use can add handlers if 
he want to the axis2 defined phases instead.

> Axis2/C does not invoke the phases correctly when there are module defined 
> phases.
> --
>
> Key: AXIS2C-1162
> URL: https://issues.apache.org/jira/browse/AXIS2C-1162
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: Current (Nightly)
>Reporter: Manjula Peiris
>
> Axis2/C always invoke the default phases first even when the user module 
> defined phase are defined before them in the axis2.xml. So if a user want to 
> invoke any module defined phase before the default phases it will fail.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: Looking for a debugger for axis2c

[Gupta, Shivam]

Hello,

I have tried but was unsuccessful in managing to debug axis on Visula 
Studio 2005. Could you provide me a link to some tutorial or document that 
would guide me about creating a project in VS2005. I want to import Axis2/c as 
a project in VS2005.

Thanks,
Shivam


From: Rajika Kumarasiri [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 6:45 PM
To: Apache AXIS C Developers List
Subject: Re: Looking for a debugger for axis2c

You can try gdb on Linux based platforms and Micrsoft Visual Studio 2005 for 
Windows platform.

-Rajika

On Tue, Jun 10, 2008 at 6:25 PM, Gupta, Shivam <[EMAIL PROTECTED]> wrote:
Hello,

   Could someone suggest me the best debugger that could be used to debug 
Axis2/C.

Thanks,
Shivam



--
comp.lang.c - http://groups.google.com/group/comp.lang.c/topics

[jira] Assigned: (AXIS2C-1190) Non blocking samples could be improved by the use of axis2_callback_get_complete function.

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1190:


Assignee: Damitha Kumarage

> Non blocking samples could be improved by the use of 
> axis2_callback_get_complete function.
> --
>
> Key: AXIS2C-1190
> URL: https://issues.apache.org/jira/browse/AXIS2C-1190
> Project: Axis2-C
>  Issue Type: Bug
> Environment: all
>Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
>
> I can see that in non blocking samples it keep variable isComplete which is 
> updated from within the on_complte callback function to notify the 
> application client that response has arrived. Meanwhile client is in a while 
> loop which look for the change in onComplete variable for loop break.
> I think it is more advisable simpler  to use following in the client code 
> which use axis2_callback_get_complete function.
> while(!axis2_callback_get_comlete(callback, env))
> {
> AXIS2_SLLEP(1);
> if(count < 30)
> {
> count++; 
> }
> else
> {
> printf("\necho client invoke failed. Counter timed out. \n"); 
> }
> }
> echo_process_result_node(callback, env);
> Note that echo_process_result_node(callback, env) function
> has the same content as the echo_callback_on_complete() function. Only the 
> name
> is changed for appropriateness.
> Also significant change is not passing a callback function with the callback. 
> This is not needed.
> Once response come back the callback has the response envelope set. Calling 
> echo_process_result_node
> we can process this result appropriatley.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (AXIS2C-1191) Add Documentation for AMQP Transport

[Danushka Menikkumbura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Danushka Menikkumbura updated AXIS2C-1191:
--

Attachment: AXIS2C-1191-V2.patch

Sanjaya,
  Try AXIS2C-1191-V2.patch and see.


> Add Documentation for AMQP Transport
> 
>
> Key: AXIS2C-1191
> URL: https://issues.apache.org/jira/browse/AXIS2C-1191
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: Current (Nightly)
>Reporter: Danushka Menikkumbura
> Fix For: Current (Nightly)
>
> Attachments: AXIS2C-1191-V2.patch, AXIS2C-1191.patch
>
>
> Modify existing docs to have AMQP installation guide.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (AXIS2C-1192) axis2c dual sample clients give a memory corruption in consecutive execution

[S.Uthaiyashankar (JIRA)]

axis2c dual sample clients give a memory corruption in consecutive execution


 Key: AXIS2C-1192
 URL: https://issues.apache.org/jira/browse/AXIS2C-1192
 Project: Axis2-C
  Issue Type: Bug
  Components: samples
Affects Versions: Current (Nightly)
 Environment: Windows XP, guththila
Reporter: S.Uthaiyashankar


axis2c dual sample clients give a memory corruption in consecutive execution.

To recreate the issue, try running echo_blocking_dual.exe several times 
consecutively. The corruption occurs randomly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Assigned: (AXIS2C-1189) svc_client_send_receive could be improved significantly in blocking dual channel case.

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1189:


Assignee: Damitha Kumarage

> svc_client_send_receive could be improved significantly in blocking dual 
> channel case.
> --
>
> Key: AXIS2C-1189
> URL: https://issues.apache.org/jira/browse/AXIS2C-1189
> Project: Axis2-C
>  Issue Type: Bug
> Environment: all
>Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
>
> I observered that in svc_client_send_receive function's blocking dual related 
> code section could be improved.
> Currently after establishing the callback and starting listener manager it 
> repeatedly call op_client_receive function in a loop. It in tern call engine 
> receive.It then extract the response soap envelope from the response message 
> context passed to  engine receive. But this is redundant and expensive calls 
> to engine_receive. By this time, the callback we passed already contain the 
> response soap envelope. What we need is just the following code to get the 
> response envelope instead of having some unneccessary complexity.
> index = axis2_options_get_timeout_in_milli_seconds(svc_client->options, env) 
> / 10;
> while(!axis2_callback_get_complete(callback, env))
> {
> if(index-- >= 0)
> {
>AXIS2_USLEEP(1);
> }
> else
> {
> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_RESPONSE_TIMED_OUT, 
> AXIS2_FAILURE);
> AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Response time out");
> }
> 
> soap_envelope = axis2_callback_get_envelope(callback, env);
> }
> Note that I use the function axis2_callback_get_complete() function as the 
> loop condition.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (AXIS2C-701) Provide a link to API documents in the axis2c home page

[Dushshantha Chandradasa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dushshantha Chandradasa closed AXIS2C-701.
--


>  Provide a link to API documents in the axis2c home page
> 
>
> Key: AXIS2C-701
> URL: https://issues.apache.org/jira/browse/AXIS2C-701
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: documentation
> Environment: All
>Reporter: Dushshantha Chandradasa
>Assignee: Dushshantha Chandradasa
> Fix For: Current (Nightly)
>
>
> I cannot find any link to API documents in axis2c documentation. It would be 
> better if we can provide a link under Developer guidelines section. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (AXIS2C-701) Provide a link to API documents in the axis2c home page

[Dushshantha Chandradasa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dushshantha Chandradasa resolved AXIS2C-701.


   Resolution: Fixed
Fix Version/s: Current (Nightly)

Added a link on Axis2/c Documentation page under Additional References.

>  Provide a link to API documents in the axis2c home page
> 
>
> Key: AXIS2C-701
> URL: https://issues.apache.org/jira/browse/AXIS2C-701
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: documentation
> Environment: All
>Reporter: Dushshantha Chandradasa
>Assignee: Dushshantha Chandradasa
> Fix For: Current (Nightly)
>
>
> I cannot find any link to API documents in axis2c documentation. It would be 
> better if we can provide a link under Developer guidelines section. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (AXIS2C-1111) INSTALL file should be updated to have information of Guththila parser as default

[Dushshantha Chandradasa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dushshantha Chandradasa resolved AXIS2C-.
-

Resolution: Fixed

> INSTALL file should be updated to have information of Guththila parser as 
> default
> -
>
> Key: AXIS2C-
> URL: https://issues.apache.org/jira/browse/AXIS2C-
> Project: Axis2-C
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: Current (Nightly)
> Environment: All
>Reporter: Dushshantha Chandradasa
>Assignee: Dushshantha Chandradasa
> Fix For: 1.4.1
>
>
> INSTALL file should be updated to have information of Guththila parser as 
> default. This should go to html docs as well. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (AXIS2C-1111) INSTALL file should be updated to have information of Guththila parser as default

[Dushshantha Chandradasa (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dushshantha Chandradasa closed AXIS2C-.
---


> INSTALL file should be updated to have information of Guththila parser as 
> default
> -
>
> Key: AXIS2C-
> URL: https://issues.apache.org/jira/browse/AXIS2C-
> Project: Axis2-C
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: Current (Nightly)
> Environment: All
>Reporter: Dushshantha Chandradasa
>Assignee: Dushshantha Chandradasa
> Fix For: 1.4.1
>
>
> INSTALL file should be updated to have information of Guththila parser as 
> default. This should go to html docs as well. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: MTOM Caching With a user provided callback

[Manjula Peiris]

On Tue, 2008-06-10 at 11:03 -0700, Thilina Gunarathne wrote:
> Hi,
> 
> On Tue, 2008-06-10 at 16:46 +0530, Samisa Abeysinghe wrote:
> > And what I am wondering is that, if we are truly using the
> pull model,
> > should we be pulling the attachments form the stream before
> we hit the
> > service?
> 
> 
> In order to do this we may need to stop parsing the incoming
> stream
> after we found the SOAP part. Then need to find a place to
> continue
> parsing after we found the service.
> Does this mean that Axis2/c parses the whole MIME message beforehand?.

Yes while we are parsing the stream depending on the size write it to a
file or keep it on memory. This parsing happens at very early stages of
request processing at the transport level even before invoking the
engine. The data_handler has a reference to the attachment if it is in
memory or it knows if it is cached.


> yes...You are correct..  We just give the temporary file option for
> the user. 
>  
> Talking about your case, IMHO we don't want to cache the SOAP part at
> all and it's the SOAP part that's needed in order to dispatch to the
> service. Attachments in other MIME parts will be requested by the
> service only by the business logic or the data binding layer depending
> whether or not that layer supports the differed building of
> attachments.

This means calling the mime_parser happens at the service business
logic. Till that the mime attachments are in the incoming data stream.
So inside the business logic of the service we need to have access to
the incoming data stream in order to separate the attachment. Please
correct me if I am wrong.


>  At that point we are aware of the service and even the operation. We
> might be able to pass in that information to the MIME parser when we
> are requesting the actual attachment.
> There is the very rare case of SOAP part not being the first MIME part
> scenerio which will break the above model as you need to parse the
> earlier MIME parts before getting to the SOAP part.  But frankly
> I have not seeing any web service engine or client does that, even
> though the spec does not restricts it.
>  
>  thanks,
> Thilina
> 
> 
> -Manjula.
> 
> 
> 
> > Samisa...
> >
> > Supun Kamburugamuva wrote:
> > > Hi Manula,
> > >
> > > I understand your point. But as Samisa said this is a
> service specific
> > > configuration and I'm sure users will definitely have
> different
> > > callbacks for different services. So I think we need to
> figure out a
> > > way to do this configuration at the service level.
> > >
> > > Supun..
> > >
> > > On Mon, Jun 9, 2008 at 9:19 PM, Manjula Peiris
> <[EMAIL PROTECTED]
> > > > wrote:
> > >
> > >
> > > On Mon, 2008-06-09 at 23:52 +0530, Samisa Abeysinghe
> wrote:
> > > > Manjula Peiris wrote:
> > > > > On Mon, 2008-06-09 at 20:24 +0530, Samisa
> Abeysinghe wrote:
> > > > >
> > > > >> Manjula Peiris wrote:
> > > > >>
> > > > >>> Seems that every one is ok with this approach.
> But as I
> > > mentioned this
> > > > >>> approach has problems when there are multiple
> MTOM services.
> > > > >>>
> > > > >> You mean threading issues?
> > > > >>
> > > > >
> > > > > No in the implementation I have specified the
> callback in the
> > > axis2.xml.
> > > > > But when there are many services which have
> different
> > > callbacks then
> > > > > there should be a way to specify them. We can't
> put this in the
> > > > > services.xml becasue mime_parser does not have any
> information
> > > about the
> > > > > services.
> > > > >
> > > >
> > > > I think the correct way to do this is to use the one
> given in
> > > axis2.xml
> > > > as the default and override that with one in
> services.xml, if
> > > there is
> > > > one provided. If the callback is set as a parameter,
> then this
> > > will work
> > > > seamlessly, as service level parameters override
> conf level params.
> > >
> > > When we are invoking the mime_parser the service is
> not dispatched. So
> > > the mime_parser don't know which callback to load if
> it is
> > > specified in
> > > the services.xml.
> > >
> > > >
> > > > Samisa...
> 

[jira] Closed: (AXIS2C-1161) In echo sample client wrong addressing headers passed in the second message.

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage closed AXIS2C-1161.


Resolution: Fixed

The reason for this issue is in op_client_two_way_send function we take the 
options from the outgoing messagecontext and set it to response message context 
before passing to engine_receive() function. I removed this line and it works 
fine now.

> In echo sample client wrong addressing headers passed in the second message.
> 
>
> Key: AXIS2C-1161
> URL: https://issues.apache.org/jira/browse/AXIS2C-1161
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/engine
> Environment: debian
>Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
>
> When I run echo client samples, in the second message I can see addressing 
> headers 'relates_to' and 'from' as can be seen in the following message.
> In effect what this tell is that from address is 
> "http://localhost:9090/axis2/services/echo"; and that this message releates to 
> the first client message.
> When I debugged I can see that these headers are added to the 
> msg_info_headers struct from addressing_in_handler.
> I am testing with the current svn header.
> http://www.w3.org/2003/05/soap-envelope";>
>http://www.w3.org/2005/08/addressing";>
>   http://localhost:9090/axis2/services/echo
>   http://ws.apache.org/axis2/c/samples/echoString
>   
>  http://localhost:9090/axis2/services/echo
>   
>   07dd679a-2a4c-1dd1-2b3c-001125b4c0fc
>wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply";>07d15306-2a4c-1dd1-2b3b-001125b4c0fc
>
>
>   http://ws.apache.org/axis2/services/echo";>
>  Hello World!
>   
>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: MTOM Caching With a user provided callback

[Thilina Gunarathne]

Hi,

>
> On Tue, 2008-06-10 at 16:46 +0530, Samisa Abeysinghe wrote:
> > And what I am wondering is that, if we are truly using the pull model,
> > should we be pulling the attachments form the stream before we hit the
> > service?
>
> In order to do this we may need to stop parsing the incoming stream
> after we found the SOAP part. Then need to find a place to continue
> parsing after we found the service.

Does this mean that Axis2/c parses the whole MIME message beforehand?.

>
>
> > Looks like something is wrong.
>
> Yes this is a design issue. For example in Axis2/Java they just write to
> a temporary file during caching. I think it is not a user provided
> option. Please correct me if I am wrong. But in our case we are trying
> to access service level parameters even before the dispatching
> happened.

yes...You are correct..  We just give the temporary file option for the
user.

Talking about your case, IMHO we don't want to cache the SOAP part at all
and it's the SOAP part that's needed in order to dispatch to the service.
Attachments in other MIME parts will be requested by the service only by the
business logic or the data binding layer depending whether or not that layer
supports the differed building of attachments. At that point we are aware of
the service and even the operation. We might be able to pass in that
information to the MIME parser when we are requesting the actual attachment.

There is the very rare case of SOAP part not being the first MIME part
scenerio which will break the above model as you need to parse the earlier
MIME parts before getting to the SOAP part.  But frankly I have not seeing
any web service engine or client does that, even though the spec does not
restricts it.

 thanks,
Thilina

>
>
> -Manjula.
>
>
> > Samisa...
> >
> > Supun Kamburugamuva wrote:
> > > Hi Manula,
> > >
> > > I understand your point. But as Samisa said this is a service specific
> > > configuration and I'm sure users will definitely have different
> > > callbacks for different services. So I think we need to figure out a
> > > way to do this configuration at the service level.
> > >
> > > Supun..
> > >
> > > On Mon, Jun 9, 2008 at 9:19 PM, Manjula Peiris <[EMAIL PROTECTED]
> > > > wrote:
> > >
> > >
> > > On Mon, 2008-06-09 at 23:52 +0530, Samisa Abeysinghe wrote:
> > > > Manjula Peiris wrote:
> > > > > On Mon, 2008-06-09 at 20:24 +0530, Samisa Abeysinghe wrote:
> > > > >
> > > > >> Manjula Peiris wrote:
> > > > >>
> > > > >>> Seems that every one is ok with this approach. But as I
> > > mentioned this
> > > > >>> approach has problems when there are multiple MTOM services.
> > > > >>>
> > > > >> You mean threading issues?
> > > > >>
> > > > >
> > > > > No in the implementation I have specified the callback in the
> > > axis2.xml.
> > > > > But when there are many services which have different
> > > callbacks then
> > > > > there should be a way to specify them. We can't put this in the
> > > > > services.xml becasue mime_parser does not have any information
> > > about the
> > > > > services.
> > > > >
> > > >
> > > > I think the correct way to do this is to use the one given in
> > > axis2.xml
> > > > as the default and override that with one in services.xml, if
> > > there is
> > > > one provided. If the callback is set as a parameter, then this
> > > will work
> > > > seamlessly, as service level parameters override conf level
> params.
> > >
> > > When we are invoking the mime_parser the service is not dispatched.
> So
> > > the mime_parser don't know which callback to load if it is
> > > specified in
> > > the services.xml.
> > >
> > > >
> > > > Samisa...
> > > >
> > > > >
> > > > >> Thanks,
> > > > >> Samisa...
> > > > >>
> > > > >>
> > > > >>> Any way I
> > > > >>> will integrate the stuff when the sending side is finished.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> -Manjula.
> > > > >>>
> > > > >>>
> > > > >>> On Mon, 2008-06-02 at 12:12 +0530, Manjula Peiris wrote:
> > > > >>>
> > > > >>>
> > > >  Hi all,
> > > > 
> > > >  I have developed the MTOM Caching stuff and it is almost
> > > finished in the
> > > >  receiving side. The implementation is here [1] as a branch.
> > > I have
> > > >  tested with a 160MB attachment and the results are
> > > promising. The main
> > > >  advantage of this implementation is it keeps a fixed user
> > > defined size
> > > >  of the attachment at any moment during the attachment
> > > processing. The
> > > >  user can implement his own callback to cache the
> > > attachment. I have
> > > >  included a sample callback [2] which stores the attachment
> > > in to a
> > > >  file.
> > > > 
> > > >  Follow

Re: MTOM Caching With a user provided callback

[Manjula Peiris]

On Tue, 2008-06-10 at 16:46 +0530, Samisa Abeysinghe wrote:
> And what I am wondering is that, if we are truly using the pull model, 
> should we be pulling the attachments form the stream before we hit the 
> service?

In order to do this we may need to stop parsing the incoming stream
after we found the SOAP part. Then need to find a place to continue
parsing after we found the service.

> Looks like something is wrong.

Yes this is a design issue. For example in Axis2/Java they just write to
a temporary file during caching. I think it is not a user provided
option. Please correct me if I am wrong. But in our case we are trying
to access service level parameters even before the dispatching
happened. 

-Manjula.


> Samisa...
> 
> Supun Kamburugamuva wrote:
> > Hi Manula,
> >
> > I understand your point. But as Samisa said this is a service specific 
> > configuration and I'm sure users will definitely have different 
> > callbacks for different services. So I think we need to figure out a 
> > way to do this configuration at the service level.
> >
> > Supun..
> >
> > On Mon, Jun 9, 2008 at 9:19 PM, Manjula Peiris <[EMAIL PROTECTED] 
> > > wrote:
> >
> >
> > On Mon, 2008-06-09 at 23:52 +0530, Samisa Abeysinghe wrote:
> > > Manjula Peiris wrote:
> > > > On Mon, 2008-06-09 at 20:24 +0530, Samisa Abeysinghe wrote:
> > > >
> > > >> Manjula Peiris wrote:
> > > >>
> > > >>> Seems that every one is ok with this approach. But as I
> > mentioned this
> > > >>> approach has problems when there are multiple MTOM services.
> > > >>>
> > > >> You mean threading issues?
> > > >>
> > > >
> > > > No in the implementation I have specified the callback in the
> > axis2.xml.
> > > > But when there are many services which have different
> > callbacks then
> > > > there should be a way to specify them. We can't put this in the
> > > > services.xml becasue mime_parser does not have any information
> > about the
> > > > services.
> > > >
> > >
> > > I think the correct way to do this is to use the one given in
> > axis2.xml
> > > as the default and override that with one in services.xml, if
> > there is
> > > one provided. If the callback is set as a parameter, then this
> > will work
> > > seamlessly, as service level parameters override conf level params.
> >
> > When we are invoking the mime_parser the service is not dispatched. So
> > the mime_parser don't know which callback to load if it is
> > specified in
> > the services.xml.
> >
> > >
> > > Samisa...
> > >
> > > >
> > > >> Thanks,
> > > >> Samisa...
> > > >>
> > > >>
> > > >>> Any way I
> > > >>> will integrate the stuff when the sending side is finished.
> > > >>>
> > > >>> Thanks,
> > > >>> -Manjula.
> > > >>>
> > > >>>
> > > >>> On Mon, 2008-06-02 at 12:12 +0530, Manjula Peiris wrote:
> > > >>>
> > > >>>
> > >  Hi all,
> > > 
> > >  I have developed the MTOM Caching stuff and it is almost
> > finished in the
> > >  receiving side. The implementation is here [1] as a branch.
> > I have
> > >  tested with a 160MB attachment and the results are
> > promising. The main
> > >  advantage of this implementation is it keeps a fixed user
> > defined size
> > >  of the attachment at any moment during the attachment
> > processing. The
> > >  user can implement his own callback to cache the
> > attachment. I have
> > >  included a sample callback [2] which stores the attachment
> > in to a
> > >  file.
> > > 
> > >  Following are the user configurable parameters in axis2.xml.
> > > 
> > >  10
> > > 
> > >  Using this parameter the user can govern the caching
> > threshold. This is
> > >  in KB and I will fix this to be in MB.For example this is
> > 10 means any
> > >  attachment greater than 10KB will be cached.
> > > 
> > >   > locked="false">1000
> > > 
> > >  This will tell maximum numbers of buffers Axis2/C can
> > handle when the
> > >  attachment comes with a pretty large SOAP envelope. Because
> > we are not
> > >  caching the SOAP envelope.
> > > 
> > > 
> > >   > >  locked="false">/path/to/your/caching_callabck
> > > 
> > >  User will specify the callback name using this parameter so
> > that Axis2/C
> > >  can load when it wants to cache the attachment. If the user
> > does not
> > >  specify this the attachment will be in memory.
> > > 
> > >  I also added a flag called 'cached' to the
> > axiom_data_handler. This flag
> > >  will tell whether the attachment is cached or not using the
> > user
> >

[jira] Commented: (AXIS2C-1191) Add Documentation for AMQP Transport

[Sanjaya Ratnaweera (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603924#action_12603924
 ] 

Sanjaya Ratnaweera commented on AXIS2C-1191:


Danushka,

I get the following error when I try to apply the patch

patching file NEWS
Hunk #1 FAILED at 22.
1 out of 1 hunk FAILED -- saving rejects to file NEWS.rej


did you create the patch against svn head?

> Add Documentation for AMQP Transport
> 
>
> Key: AXIS2C-1191
> URL: https://issues.apache.org/jira/browse/AXIS2C-1191
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: Current (Nightly)
>Reporter: Danushka Menikkumbura
> Fix For: Current (Nightly)
>
> Attachments: AXIS2C-1191.patch
>
>
> Modify existing docs to have AMQP installation guide.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: Possible improvements to Axis2/C

[Bill Mitchell]

Supun, when I read your proposal, I started to wonder how long the
memory/buffer containing the strings will persist, since as soon as the
underlying buffer is freed or reused the axiom tree using pointers to these
strings will become invalid.  I am guessing that the buffer is freed or
reused when the next request is issued, and you are assuming that at that
time the tree structure from the last request has also been freed.

 

My particular concern is with the logic in axiom_node_detach.  This is used
to transfer ownership of a subtree from the axiom tree to the caller.  Among
other users of this routine, the generated adb classes use axiom_node_detach
to return to the application the subtree corresponding to WSDL data of type
Any.  The application may retain ownership of these returned subtrees for
long periods, well beyond the next request.  

 

To maintain the current API, I infer that axiom_node_detach will need to
traverse the entire subtree that is being detached, look for any strings
that are not owned, and replace them with new copies of the strings that are
owned.  So, as well as the new routines you suggested like
axiom_element_create_nos, won't you need another set of routines like
axiom_element_force_ownership for each axiom structure?  Axiom_node_detach
could invoke these force_ownership routines on each element of the subtree
to make sure that every unowned string is replaced.  

 

Regards,

Bill Mitchell

 

From: Supun Kamburugamuva [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 10, 2008 12:49 AM
To: Apache AXIS C Developers List
Subject: Re: Possible improvements to Axis2/C

 

Hi List,

I have managed to get this thing working. The purpose of this implementation
is to avoid duplicating strings from the parser to the axiom level.
Guththila keeps a buffer of the incoming XML. Instead of duplicating XML
Strings from this buffer Guththila can give a pointer to the starting
position of the string in the buffer. We need to build Axiom by using these
pointers and Axiom shoudn't assume the ownership of these strings. This is
the brief summary of what I have done.

Axiom Model Level

Basically I have introduced a Boolean flag to virtually every structure on
Axiom as well axutil_qname_t structure. This flag indicates weather we are
allowed to free the string buffers or not. Here is an example.

 struct axiom_comment
{

/** comment text */
axutil_string_t *value;
/* True if we are allowed to free string buffers */
axis2_bool_t owns_strings;
};

Then I have introduced a new create method for all the structures in om.
This method creates the structure without assuming the ownership of the
strings. Following is the new method for axiom_element_t structure.

axiom_element_create_nos(params same as normal create method)

I don't feel right about the name of the method (nos means "not owns
strings"). So I would like to here a more readable name from you guys.
This create method sets the owns_strings to FALSE and all the getter methods
and setter methods were changed to act according to the owns_strings field.
These are the only changes to the Axiom level and as you can see no API
changes. Just few additional API methods. 

Stax Level

I have introduced the "owns_strings" Boolean flag to the
axiom_stax_builder_t structure. If this is FALSE, builder will build the
tree without assuming the ownership of the strings. So I have introduced a
new create method for stax builder as well.

AXIS2_EXTERN axiom_stax_builder_t *AXIS2_CALL
axiom_stax_builder_create_nos(
const axutil_env_t * env,
axiom_xml_reader_t * parser);

In all the stax builder methods the owns_strings flag is checked and
appropriate methods are called to build the om tree. For example if this
flag is FALSE the newly added axiom_element_create_nos will be called
instead of axiom_element_create_str. 

Parser Level

I have introduced a new method to the axiom_xml_reader API. The method is 

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_set_duplicate_strings(
axiom_xml_reader_t * parser,
const axutil_env_t * env,
axis2_bool_t is_duplicate);

This method will try to set the parser to not to duplicate strings. If the
method is unsuccessful (in the case of Libxml2) this method will return
false. The advantage of this method is that depending on the return value of
this method we can create the appropriate stax builder (one that uses
duplicated strings or one that uses strings as pointers to a buffer).

The implementation is at an experimental level. All the samples are working
but there are memory leaks in the system. Also I haven't check the
implementation with Libxml2.  We need to do a performance test and see
weather this gives a good performance gain as well. 

Regards,
Supun.



On Mon, Jun 2, 2008 at 6:16 AM, Supun Kamburugamuva <[EMAIL PROTECTED]>
wrote:



AFAIK yes we can do this. The only thing is we need to introduce the
axutil_string_t to every structure in axiom/C for handl

Re: Looking for a debugger for axis2c

[Rajika Kumarasiri]

You can try gdb on Linux based platforms and Micrsoft Visual Studio 2005 for
Windows platform.

-Rajika

On Tue, Jun 10, 2008 at 6:25 PM, Gupta, Shivam <[EMAIL PROTECTED]> wrote:

>  Hello,
>
>Could someone suggest me the best debugger that could be used to debug
> Axis2/C.
>
> Thanks,
> Shivam
>



-- 
comp.lang.c - http://groups.google.com/group/comp.lang.c/topics

Looking for a debugger for axis2c

[Gupta, Shivam]

Hello,

   Could someone suggest me the best debugger that could be used to debug 
Axis2/C.

Thanks,
Shivam

[jira] Updated: (AXIS2C-1191) Add Documentation for AMQP Transport

[Danushka Menikkumbura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Danushka Menikkumbura updated AXIS2C-1191:
--

Attachment: AXIS2C-1191.patch

Please apply the attached patch to update docs for AMQP transport. This will 
update the following files.

INSTALL
NEWS
CREDITS

> Add Documentation for AMQP Transport
> 
>
> Key: AXIS2C-1191
> URL: https://issues.apache.org/jira/browse/AXIS2C-1191
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: Current (Nightly)
>Reporter: Danushka Menikkumbura
> Fix For: Current (Nightly)
>
> Attachments: AXIS2C-1191.patch
>
>
> Modify existing docs to have AMQP installation guide.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: MTOM Caching With a user provided callback

[Samisa Abeysinghe]

And what I am wondering is that, if we are truly using the pull model, 
should we be pulling the attachments form the stream before we hit the 
service?


Looks like something is wrong.

Samisa...

Supun Kamburugamuva wrote:

Hi Manula,

I understand your point. But as Samisa said this is a service specific 
configuration and I'm sure users will definitely have different 
callbacks for different services. So I think we need to figure out a 
way to do this configuration at the service level.


Supun..

On Mon, Jun 9, 2008 at 9:19 PM, Manjula Peiris <[EMAIL PROTECTED] 
> wrote:



On Mon, 2008-06-09 at 23:52 +0530, Samisa Abeysinghe wrote:
> Manjula Peiris wrote:
> > On Mon, 2008-06-09 at 20:24 +0530, Samisa Abeysinghe wrote:
> >
> >> Manjula Peiris wrote:
> >>
> >>> Seems that every one is ok with this approach. But as I
mentioned this
> >>> approach has problems when there are multiple MTOM services.
> >>>
> >> You mean threading issues?
> >>
> >
> > No in the implementation I have specified the callback in the
axis2.xml.
> > But when there are many services which have different
callbacks then
> > there should be a way to specify them. We can't put this in the
> > services.xml becasue mime_parser does not have any information
about the
> > services.
> >
>
> I think the correct way to do this is to use the one given in
axis2.xml
> as the default and override that with one in services.xml, if
there is
> one provided. If the callback is set as a parameter, then this
will work
> seamlessly, as service level parameters override conf level params.

When we are invoking the mime_parser the service is not dispatched. So
the mime_parser don't know which callback to load if it is
specified in
the services.xml.

>
> Samisa...
>
> >
> >> Thanks,
> >> Samisa...
> >>
> >>
> >>> Any way I
> >>> will integrate the stuff when the sending side is finished.
> >>>
> >>> Thanks,
> >>> -Manjula.
> >>>
> >>>
> >>> On Mon, 2008-06-02 at 12:12 +0530, Manjula Peiris wrote:
> >>>
> >>>
>  Hi all,
> 
>  I have developed the MTOM Caching stuff and it is almost
finished in the
>  receiving side. The implementation is here [1] as a branch.
I have
>  tested with a 160MB attachment and the results are
promising. The main
>  advantage of this implementation is it keeps a fixed user
defined size
>  of the attachment at any moment during the attachment
processing. The
>  user can implement his own callback to cache the
attachment. I have
>  included a sample callback [2] which stores the attachment
in to a
>  file.
> 
>  Following are the user configurable parameters in axis2.xml.
> 
>  10
> 
>  Using this parameter the user can govern the caching
threshold. This is
>  in KB and I will fix this to be in MB.For example this is
10 means any
>  attachment greater than 10KB will be cached.
> 
>  1000
> 
>  This will tell maximum numbers of buffers Axis2/C can
handle when the
>  attachment comes with a pretty large SOAP envelope. Because
we are not
>  caching the SOAP envelope.
> 
> 
>    locked="false">/path/to/your/caching_callabck
> 
>  User will specify the callback name using this parameter so
that Axis2/C
>  can load when it wants to cache the attachment. If the user
does not
>  specify this the attachment will be in memory.
> 
>  I also added a flag called 'cached' to the
axiom_data_handler. This flag
>  will tell whether the attachment is cached or not using the
user
>  provided callback. If it is cached then it is user's
responsibility in
>  his client/service code to find the attachment, because
Axis2/C cached
>  it using his callback.
> 
>  I have a one major problem in this model. That is if there
are more than
>  one mtom services and if those are going to use different
callbacks then
>  we can't specify this in axis2.xml. We can't specify this in
>  services.xml either because attachment separation happens
before
>  accessing the service.
> 
>  So really appreciate your ideas regarding the above
parameters, callback
>  and the problem I have mentioned above.
> 
> 

[1]https://svn.apache.org/repos/asf/webservices/axis2/branches/c/post_1_4_mtom/c
> 
> 

[2]https://svn.apache.org/repos/asf/webservices/axis2/branches/c/post_1_4_mtom/c/samples/mtom_caching_callback/mtom_caching_callback.c
> 
> 
>  

Re: Possible improvements to Axis2/C

[Samisa Abeysinghe]

May be you should commit this to a scratch area so that others could 
have a look.


Samisa...

Supun Kamburugamuva wrote:

Hi List,

I have managed to get this thing working. The purpose of this 
implementation is to avoid duplicating strings from the parser to the 
axiom level. Guththila keeps a buffer of the incoming XML. Instead of 
duplicating XML Strings from this buffer Guththila can give a pointer 
to the starting position of the string in the buffer. We need to build 
Axiom by using these pointers and Axiom shoudn't assume the ownership 
of these strings. This is the brief summary of what I have done.


*Axiom Model Level*

Basically I have introduced a Boolean flag to virtually every 
structure on Axiom as well axutil_qname_t structure. This flag 
indicates weather we are allowed to free the string buffers or not. 
Here is an example.


 struct axiom_comment
{

/** comment text */
axutil_string_t *value;
/* True if we are allowed to free string buffers */
axis2_bool_t owns_strings;
};

Then I have introduced a new create method for all the structures in 
om. This method creates the structure without assuming the ownership 
of the strings. Following is the new method for axiom_element_t structure.


axiom_element_create_nos(params same as normal create method)

I don't feel right about the name of the method (nos means "not owns 
strings"). So I would like to here a more readable name from you guys.
This create method sets the owns_strings to FALSE and all the getter 
methods and setter methods were changed to act according to the 
owns_strings field.
These are the only changes to the Axiom level and as you can see no 
API changes. Just few additional API methods.


*Stax Level
*
I have introduced the "owns_strings" Boolean flag to the 
axiom_stax_builder_t structure. If this is FALSE, builder will build 
the tree without assuming the ownership of the strings. So I have 
introduced a new create method for stax builder as well.


AXIS2_EXTERN axiom_stax_builder_t *AXIS2_CALL
axiom_stax_builder_create_nos(
const axutil_env_t * env,
axiom_xml_reader_t * parser);

In all the stax builder methods the owns_strings flag is checked and 
appropriate methods are called to build the om tree. For example if 
this flag is FALSE the newly added axiom_element_create_nos will be 
called instead of axiom_element_create_str.


*Parser Level*

I have introduced a new method to the axiom_xml_reader API. The method is

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axiom_xml_reader_set_duplicate_strings(
axiom_xml_reader_t * parser,
const axutil_env_t * env,
axis2_bool_t is_duplicate);

This method will try to set the parser to not to duplicate strings. If 
the method is unsuccessful (in the case of Libxml2) this method will 
return false. The advantage of this method is that depending on the 
return value of this method we can create the appropriate stax builder 
(one that uses duplicated strings or one that uses strings as pointers 
to a buffer).


The implementation is at an experimental level. All the samples are 
working but there are memory leaks in the system. Also I haven't check 
the implementation with Libxml2.  We need to do a performance test and 
see weather this gives a good performance gain as well.


Regards,
Supun.


On Mon, Jun 2, 2008 at 6:16 AM, Supun Kamburugamuva <[EMAIL PROTECTED] 
> wrote:




AFAIK yes we can do this. The only thing is we need to introduce
the axutil_string_t to every structure in axiom/C for handling the
strings (most of these are already done). When we create these
strings we set the owns_buffer to false. When Axiom/C free the
axutil_string_t structure it won't free the actual buffer. We can
free the actual buffer at the end of the processing of the request
and every string buffer will be free at once.

Also with the current design all the methods in Axiom/C returns
the strings to the users but the ownership of those strings
remains with Axiom/C. So hopefully we won't have to worry about
that also.

Supun.


On Mon, Jun 2, 2008 at 4:51 AM, Samisa Abeysinghe <[EMAIL PROTECTED]
> wrote:

Supun Kamburugamuva wrote:

Hi All,

At the moment Axis2/C is considerably faster than its Java
implementation. We have run performance tests for Axis2/C
and the results are promising. But we believe that we can
improve the Axis2/C performance to a much higher level
than what it has achieved.

I have done profiling for Axis2/C on a Windows machine
using the Benchmark service and Apache "ab". These tests
were done using both Apache web server (httpd) and Simple
Http Server. These results didn't show any routines which
cause bottlenecks in the Axis2/C. Also Guththila is at its
best and I canno

Re: Question about AXIS2_PARAM_CHECK

[Damitha Kumarage]

Hi,
I had the same concern and tried a similar kind of fix few weeks back. 
But because of the following explanation it seems we have to bear with 
the current code.


Suppose we have implemented your fix. say we call to functions x, y and 
z in that order. Say inside function x it set an error code status.


Now we call y. Inside y() we neglect the error code and say we do even a 
database commit.
Now we call to z(). At the beginning of z say we do an param check. If 
all parameters are good to go it should pass param checks. But it return 
an error (because of previously set error status in function x)  even 
when all parameters are good. This is unfair for function z() and it is 
also misleading.


So the best thing to do is to handle error status before calling any 
important function which has param checkings etc. For example in 
function y() we have even done a database commit  neglecting the error 
status which is not good.


thanks
Damitha.

Dimuthu Gamage wrote:


Hi devs,

Currently in AXIS2_PARAM_CHECK, if the param is null we set the status 
code to AXIS2_FAILURE and if not null set the status code AXIS2_SUCCESSS


#define AXIS2_PARAM_CHECK(error, object, error_return)  \
if (!object)\
{   \
AXIS2_ERROR_SET_ERROR_NUMBER(error, 
AXIS2_ERROR_INVALID_NULL_PARAM); \

AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_FAILURE);  \
return error_return;\
}   \
else\
{   \
AXIS2_ERROR_SET_STATUS_CODE(error, AXIS2_SUCCESS);  \
}


My question is, is it ok to set the status code to AXIS2_SUCCESS,
Because
1. If  we are in happy path, the status code is already AXIS2_SUCCESS, 
we don't need to explicitly set that.
2. The macro can overwrite the status, That is if the status is 
already set to failure by an early case, this macro will overwrite the 
status to SUCCESS which is wrong.


So my suggestion is to remove the else part from that macro?. Please 
let me know your ideas, I may be wrong on this.


Thanks
Dimuthu




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

Re: axiom_mime_output_t struct

[Nandika Jayawardana]

+1 for removing this struct.

Nandika

On Tue, Jun 10, 2008 at 1:40 PM, Manjula Peiris <[EMAIL PROTECTED]> wrote:
> Hi devs,
>
> In axiom/src/attachments/axiom_mime_output.h the $subject id defined but
> it does not have any members. For all the functions in the mime_output.c
> a pointer to this function is passed but not used. Is there any reasons
> for defining this struct. If not I propose we should remove it.
>
> Thanks,
> -Manjula.
>
>
> --
> Manjula Peiris: http://manjula-peiris.blogspot.com/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com

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

axiom_mime_output_t struct

[Manjula Peiris]

Hi devs,

In axiom/src/attachments/axiom_mime_output.h the $subject id defined but
it does not have any members. For all the functions in the mime_output.c
a pointer to this function is passed but not used. Is there any reasons
for defining this struct. If not I propose we should remove it.

Thanks,
-Manjula.


-- 
Manjula Peiris: http://manjula-peiris.blogspot.com/


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