[jira] Assigned: (AXIS2C-1338) make install overly eager

2009-01-29 Thread Sanjaya Ratnaweera (JIRA)

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

Sanjaya Ratnaweera reassigned AXIS2C-1338:
--

Assignee: Sanjaya Ratnaweera

 make install overly eager
 ---

 Key: AXIS2C-1338
 URL: https://issues.apache.org/jira/browse/AXIS2C-1338
 Project: Axis2-C
  Issue Type: Bug
  Components: build system (Unix/Linux)
Affects Versions: 1.5.0
 Environment: Ubuntu 9.04 (pre-release)
Reporter: Soren Hansen
Assignee: Sanjaya Ratnaweera

 I'm building an axis2c package for Ubuntu.
 After make install DESTDIR=/foo/bar/baz is done, I get all of these:
 /foo/bar/baz/usr/share/INSTALL
 /foo/bar/baz/usr/share/README
 /foo/bar/baz/usr/share/AUTHORS
 /foo/bar/baz/usr/share/NEWS
 /foo/bar/baz/usr/share/LICENSE
 /foo/bar/baz/usr/share/COPYING
 /foo/bar/baz/usr/LICENSE
 /foo/bar/baz/usr/bin/tools/wsdl2c/README
 /foo/bar/baz/usr/INSTALL
 /foo/bar/baz/usr/CREDITS
 /foo/bar/baz/usr/COPYING
 /foo/bar/baz/usr/NEWS
 /foo/bar/baz/usr/NOTICE
 /foo/bar/baz/usr/AUTHORS
 They obvisouly have no place in neither /usr nor /usr/share.
 Looking at the Makefile.am's, however, it looks deliberate?
 One of them has this:
 datadir=
 datadir=$(prefix)
 data_DATA= samples/server/axis2.xml README \
 INSTALL CREDITS COPYING NEWS NOTICE AUTHORS
 Also, adding subdirectories in /usr/bin is bad manners :)

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



Operation and message level policies in client side

2009-01-29 Thread Manjula Peiris
Hi devs,

In order to fix https://issues.apache.org/jira/browse/AXIS2C-619 we need
to change the following function signature in the svc_client API.

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_svc_client_set_policy(
axis2_svc_client_t * svc_client,
const axutil_env_t * env,
neethi_policy_t * policy)

I am proposing to add the policy_type defined in axis2_policy_include.h
as a parameter.

So the function signature will become,

AXIS2_EXTERN axis2_status_t AXIS2_CALL
axis2_svc_client_set_policy(
axis2_svc_client_t * svc_client,
const axutil_env_t * env,
neethi_policy_t * policy,
axis2_policy_types type)

WDYT ?

Thanks,
-Manjula.


-- 
Manjula Peiris
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
Blog: http://manjula-peiris.blogspot.com/



Re: Axis2- Hi can i use axis2/c for developing webservices which are deployed to embedded systems.

2009-01-29 Thread Manjula Peiris
Yes we encourage you to use it in embedded systems. If you have problems
send them to the list, so we can share your experience.

Thanks,
-Manjula.


On Thu, 2009-01-29 at 10:29 +0500, Supun Kamburugamuva wrote:
 As Axis2/C development community, we haven't herd of Axis2/C used in
 embedded systems yet. But it should be possible to do this because
 Axis2/C is light weight and has a low memory consumption.
 
 Thanks,
 Supun.
 
 On Wed, Jan 28, 2009 at 10:42 PM, koteswara Bellamkonda
 bbellamko...@gmail.com wrote:
 Hi,
 I am looking to deploy WebServices developed using apache
 axis2/c to embedded systems.
 is it works or not?
 Your help is appreciated.
 Let me know.
 Thanks,
 Koti
 
 
 
 



Re: Operation and message level policies in client side

2009-01-29 Thread Supun Kamburugamuva
How about adding another method with a name like
axis2_svc_client_set_policy_with_type. We can have a default value for
axis2_policy_types in the first method.

Supun.


On Thu, Jan 29, 2009 at 2:49 PM, Manjula Peiris manj...@wso2.com wrote:

 Hi devs,

 In order to fix https://issues.apache.org/jira/browse/AXIS2C-619 we need
 to change the following function signature in the svc_client API.

 AXIS2_EXTERN axis2_status_t AXIS2_CALL
 axis2_svc_client_set_policy(
axis2_svc_client_t * svc_client,
const axutil_env_t * env,
neethi_policy_t * policy)

 I am proposing to add the policy_type defined in axis2_policy_include.h
 as a parameter.

 So the function signature will become,

 AXIS2_EXTERN axis2_status_t AXIS2_CALL
 axis2_svc_client_set_policy(
axis2_svc_client_t * svc_client,
const axutil_env_t * env,
neethi_policy_t * policy,
axis2_policy_types type)

 WDYT ?

 Thanks,
 -Manjula.


 --
 Manjula Peiris
 Senior Software Engineer
 WSO2 Inc.
 Oxygenating the Web Service Platform.
 http://wso2.org/
 Blog: http://manjula-peiris.blogspot.com/




[jira] Commented: (AXIS2C-1337) Fails to compile if chdir and/or fread declared with warn_unused_result

2009-01-29 Thread Soren Hansen (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2C-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668471#action_12668471
 ] 

Soren Hansen commented on AXIS2C-1337:
--

You should use perror instead of fprintf(stderr,  It resolves the errno 
to a (localised, even) error message.

Regarding the patch against tcpmon, fread returning less than the requested 
number of bytes is not necessarily a fatal error. The system call might simply 
have been interrupted, in which case you should simply try again. In other 
words, you should check for errno == EINTR
.


 Fails to compile if chdir and/or fread declared with warn_unused_result
 ---

 Key: AXIS2C-1337
 URL: https://issues.apache.org/jira/browse/AXIS2C-1337
 Project: Axis2-C
  Issue Type: Bug
  Components: tcpmon, util
Affects Versions: 1.5.0
 Environment: Ubuntu 9.04 (pre-release)
Reporter: Soren Hansen
 Attachments: axis2c-warn_unused.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 axis2c fails to compile on Ubuntu 9.04, due to two things:
 In util/src/dir_handler.c, AXIS2_CHDIR's return value is ignored. chdir is 
 declared with warn_unused_result in our toolchain, and you pass -Werror to 
 gcc, so this causes a build failure. Obvisouly, chdir could fail for a number 
 of reasons, and failing to check is a problem.
 The same problem exists in tools/tcpmon/src/tcpmon.c, where the return value 
 of fread is ignored.

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



Re: Axis2- Hi can i use axis2/c for developing webservices which are deployed to embedded systems.

2009-01-29 Thread Rajika Kumarasiri
hi

You'll need some optimization in axiom level to get it working on an embeded
environment.

-Rajika
On Wed, Jan 28, 2009 at 11:12 PM, koteswara Bellamkonda 
bbellamko...@gmail.com wrote:

 Hi,
 I am looking to deploy WebServices developed using apache axis2/c to
 embedded systems.
 is it works or not?
 Your help is appreciated.
 Let me know.
 Thanks,
 Koti




-- 
http://wso2.org/
http://llvm.org/
http://www.osdev.org/


guththila_next_char clarification needed

2009-01-29 Thread Catalina Caloian
Hi

In the 'guththila_next_char' method, whenever a character is being retrieved 
from Guththila's internal char buffers, a check is being made to see if it has 
a positive value:
e.g.  'return c = 0 ? c : -1;' (guththila_xml_parser.c, lines 1522, 
1537, 1616, 1632)
-1 is interpreted as an error code by the caller and the parser basically 
stops, deeming the input as invalid.

I encountered this situation when dealing with a response that contained some 
non-ASCII characters. Those non-ASCII characters got stored in Guththila's 
buffers of char after a wrap-around of their values, so to fit in a char. When 
'guththila_next_char' got to those characters, it would encounter negative 
values and return -1. As a consequence, Axis2C would treat the response as 
invalid.

Replacing the aforementioned 'return' statements with a simple 'return c;' made 
Guththila parse the entire response, although the VS XML Visualizer doesn't 
display the non-ASCII characters as expected.

I'm wondering what's the rationale behind Guththila's current way of doing 
things. I feel as if I'm missing something, so any help would be highly 
appreciated.

Thank you.


Catalina-Georgiana Caloian
Software Engineer
 
Quintiq
 
T +31 (0) 73 691 07 39
F +31 (0) 73 691 07 54
M +31 (0) 65 247 63 99
E catalina.calo...@quintiq.com
I www.quintiq.com


Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate 
Duin  Kruidberg, near Amsterdam Schiphol, The Netherlands - for more 
information visit www.quintiq.com

This message contains information that may be privileged or confidential and is 
the property of Quintiq. It is only intended for the person to whom it is 
addressed. If you are not the intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute or use this message or any 
part thereof. If you have received this message in error, please notify the 
sender immediately and delete all copies of this message. Please note that 
e-mails are susceptible to change, therefore they are not binding.


Re: Operation and message level policies in client side

2009-01-29 Thread Uthaiyashankar
On Thu, Jan 29, 2009 at 11:23 PM, Manjula Peiris manj...@wso2.com wrote:

 On Thu, 2009-01-29 at 15:45 +0500, Supun Kamburugamuva wrote:
  How about adding another method with a name like
  axis2_svc_client_set_policy_with_type. We can have a default value for
  axis2_policy_types in the first method.

 +1. So this will be an API addition rather than an API change. And most
 users are using axis2_svc_client_set_policy.


+1

Regards,
Shankar




 
  Supun.
 
 
  On Thu, Jan 29, 2009 at 2:49 PM, Manjula Peiris manj...@wso2.com
  wrote:
  Hi devs,
 
  In order to fix
  https://issues.apache.org/jira/browse/AXIS2C-619 we need
  to change the following function signature in the svc_client
  API.
 
  AXIS2_EXTERN axis2_status_t AXIS2_CALL
  axis2_svc_client_set_policy(
 axis2_svc_client_t * svc_client,
 const axutil_env_t * env,
 neethi_policy_t * policy)
 
  I am proposing to add the policy_type defined in
  axis2_policy_include.h
  as a parameter.
 
  So the function signature will become,
 
  AXIS2_EXTERN axis2_status_t AXIS2_CALL
  axis2_svc_client_set_policy(
 axis2_svc_client_t * svc_client,
 const axutil_env_t * env,
 neethi_policy_t * policy,
 axis2_policy_types type)
 
  WDYT ?
 
  Thanks,
  -Manjula.
 
 
  --
  Manjula Peiris
  Senior Software Engineer
  WSO2 Inc.
  Oxygenating the Web Service Platform.
  http://wso2.org/
  Blog: http://manjula-peiris.blogspot.com/
 




-- 
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - The Open Source SOA Company


Re: guththila_next_char clarification needed

2009-01-29 Thread Supun Kamburugamuva
Guthtila is written assuming ASCHII characters. So it is not possible to get
negative characters. If Guththila gets negative charactes, it means the XML
stream has ended or contains invalid characters.

Anyway what do you mean by non-ASCII characters? Do you mean binary?

Supun.

On Thu, Jan 29, 2009 at 8:02 PM, Catalina Caloian 
catalina.calo...@quintiq.com wrote:

 Hi

 In the 'guththila_next_char' method, whenever a character is being
 retrieved from Guththila's internal char buffers, a check is being made to
 see if it has a positive value:
e.g.  'return c = 0 ? c : -1;' (guththila_xml_parser.c, lines 1522,
 1537, 1616, 1632)
 -1 is interpreted as an error code by the caller and the parser basically
 stops, deeming the input as invalid.

 I encountered this situation when dealing with a response that contained
 some non-ASCII characters. Those non-ASCII characters got stored in
 Guththila's buffers of char after a wrap-around of their values, so to fit
 in a char. When 'guththila_next_char' got to those characters, it would
 encounter negative values and return -1. As a consequence, Axis2C would
 treat the response as invalid.

 Replacing the aforementioned 'return' statements with a simple 'return c;'
 made Guththila parse the entire response, although the VS XML Visualizer
 doesn't display the non-ASCII characters as expected.

 I'm wondering what's the rationale behind Guththila's current way of doing
 things. I feel as if I'm missing something, so any help would be highly
 appreciated.

 Thank you.


 Catalina-Georgiana Caloian
 Software Engineer

 Quintiq

 T +31 (0) 73 691 07 39
 F +31 (0) 73 691 07 54
 M +31 (0) 65 247 63 99
 E catalina.calo...@quintiq.com
 I www.quintiq.com


 Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate
 Duin  Kruidberg, near Amsterdam Schiphol, The Netherlands - for more
 information visit www.quintiq.com

 This message contains information that may be privileged or confidential
 and is the property of Quintiq. It is only intended for the person to whom
 it is addressed. If you are not the intended recipient, you are not
 authorized to read, print, retain, copy, disseminate, distribute or use this
 message or any part thereof. If you have received this message in error,
 please notify the sender immediately and delete all copies of this message.
 Please note that e-mails are susceptible to change, therefore they are not
 binding.



Re: guththila_next_char clarification needed

2009-01-29 Thread Catalina Caloian
Hi

By non-ASCII I meant characters with a value greater than 127. The response 
that Guththila couldn't parse completely had the french small letter e with 
acute accent; when retrieved from Guththila's internal buffers (and stored in 
an 'int'), it would yield a negative value.

While googling Guththila, I found that it was supposed to support UTF-8 and 
UTF-16; according to that, a response containing special french characters 
should have been properly parsed.

Should I conclude that in order to handle UTF-8 encoded requests and responses 
I should use a different parser?

Thank you.
Catalina Caloian

 
From:   Supun Kamburugamuva supu...@gmail.com
To: Apache AXIS C Developers List axis-c-dev@ws.apache.org
Date:   1/30/2009 6:33 AM
Subject:Re: guththila_next_char clarification needed

Guthtila is written assuming ASCHII characters. So it is not possible to get
negative characters. If Guththila gets negative charactes, it means the XML
stream has ended or contains invalid characters.

Anyway what do you mean by non-ASCII characters? Do you mean binary?

Supun.

On Thu, Jan 29, 2009 at 8:02 PM, Catalina Caloian 
catalina.calo...@quintiq.com wrote:

 Hi

 In the 'guththila_next_char' method, whenever a character is being
 retrieved from Guththila's internal char buffers, a check is being made to
 see if it has a positive value:
e.g.  'return c = 0 ? c : -1;' (guththila_xml_parser.c, lines 1522,
 1537, 1616, 1632)
 -1 is interpreted as an error code by the caller and the parser basically
 stops, deeming the input as invalid.

 I encountered this situation when dealing with a response that contained
 some non-ASCII characters. Those non-ASCII characters got stored in
 Guththila's buffers of char after a wrap-around of their values, so to fit
 in a char. When 'guththila_next_char' got to those characters, it would
 encounter negative values and return -1. As a consequence, Axis2C would
 treat the response as invalid.

 Replacing the aforementioned 'return' statements with a simple 'return c;'
 made Guththila parse the entire response, although the VS XML Visualizer
 doesn't display the non-ASCII characters as expected.

 I'm wondering what's the rationale behind Guththila's current way of doing
 things. I feel as if I'm missing something, so any help would be highly
 appreciated.

 Thank you.


 Catalina-Georgiana Caloian
 Software Engineer

 Quintiq

 T +31 (0) 73 691 07 39
 F +31 (0) 73 691 07 54
 M +31 (0) 65 247 63 99
 E catalina.calo...@quintiq.com 
 I www.quintiq.com 


 Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate
 Duin  Kruidberg, near Amsterdam Schiphol, The Netherlands - for more
 information visit www.quintiq.com 

 This message contains information that may be privileged or confidential
 and is the property of Quintiq. It is only intended for the person to whom
 it is addressed. If you are not the intended recipient, you are not
 authorized to read, print, retain, copy, disseminate, distribute or use this
 message or any part thereof. If you have received this message in error,
 please notify the sender immediately and delete all copies of this message.
 Please note that e-mails are susceptible to change, therefore they are not
 binding.


Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate 
Duin  Kruidberg, near Amsterdam Schiphol, The Netherlands - for more 
information visit www.quintiq.com

This message contains information that may be privileged or confidential and is 
the property of Quintiq. It is only intended for the person to whom it is 
addressed. If you are not the intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute or use this message or any 
part thereof. If you have received this message in error, please notify the 
sender immediately and delete all copies of this message. Please note that 
e-mails are susceptible to change, therefore they are not binding.