[jira] Resolved: (AXIS2C-828) MTOM Sample failed with Libcurl (HTTP) transport
[ https://issues.apache.org/jira/browse/AXIS2C-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjaya Ratnaweera resolved AXIS2C-828. --- Resolution: Fixed Patch applied. Thanks Senaka for the patch > MTOM Sample failed with Libcurl (HTTP) transport > > > Key: AXIS2C-828 > URL: https://issues.apache.org/jira/browse/AXIS2C-828 > Project: Axis2-C > Issue Type: Bug > Components: core/transport, transport/http >Affects Versions: 1.1.0, Current (Nightly) >Reporter: Dinesh Premalal >Assignee: Sanjaya Ratnaweera > Attachments: diff.txt > > > MTOM sample failed with libcurl transport. I can see attachment in both > request and response messages. -- 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: [Axis2] Can we make Guththila the default parser?
On 1/23/08, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: > Supun Kamburugamuva wrote: > > > > Making guththila as the default parser may cause us few problems in > > the short terms. > > What sort of? > There are few issues reported in the Jira and we need to fix them as soon as possible and there may be new bugs that are not yet discovered. These bugs (if there are any) will start to surface as soon as guththila is used by many users with different needs. Regards, Supun.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (AXIS2C-931) ASF policy on cryptographic features
[ https://issues.apache.org/jira/browse/AXIS2C-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Malinda Kaushalye Kapuruge reassigned AXIS2C-931: - Assignee: Glen Daniels > ASF policy on cryptographic features > > > Key: AXIS2C-931 > URL: https://issues.apache.org/jira/browse/AXIS2C-931 > Project: Axis2-C > Issue Type: Task > Components: documentation >Affects Versions: Current (Nightly) > Environment: N/A >Reporter: Malinda Kaushalye Kapuruge >Assignee: Glen Daniels > Fix For: 1.2.1 > > > Since Apache Axis2/C is having cryptographic features (for https support), it > needs to be listed here[1] according to the ASF policy. Please find more > details here[2]. This has to be done by someone having site-dev karma (which > includes all of the PMC chairs). > [1]http://www.apache.org/licenses/exports/ > [2]http://www.apache.org/dev/crypto.html -- 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: Porting axis2/C into an ARM based system
Samisa Abeysinghe wrote: You can have have a look into the header util\include\platforms\axutil_platform_auto_sense.h to get an idea on how to implement auto sense. Since this seems to be a unix like platform, I propose that you create a sub folder within unix platform folder, may be called mobile, and use the unix stuff that works as it is and override whatever stuff that does not work. Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi all, I'm have a sub folder called android, inside util/include/platforms/unix folder, and I have defined a header file for the specific project. And that header file includes the axutil_unix.h header file. But some of the functions are overridden in the new file. * So, my include folder structure would be; util/include/platforms/unix/android - In android folder I'm using the header file axutil_android.h, which inherits from axutil_unix.h, and I have overridden some functions of the original axutil_unix.h file. * The corresponding source files are located in; util/src/platforms/unix/android - In there I plan to re-implement some functionalities. For example, I'm defining new functions for some of the existing ones. Eg. #define rand android_rand and I will put my new functions in the android source folder. And one more thing about the, auto sensing, In platform auto sensing, the compilers(native) for each system, knows about the system, using some specific variables. For example, the compiler for Windows when compiled, knows that WIN32 is defined. Same as in HPUX and so on. But in this case the compiler (cross compiler) doesn't define (or know) any such variable, infact it doesn't know that there exists a OS called android, and also it's not pure linux. So, I suggest using a flag (ANDROID) when compiling the source and use it in the platform auto sensing. Following is a part of the axutil_platform_auto_sense.h file; #if defined( WIN32 ) #include "windows/axutil_windows.h" #include "windows/axutil_dir_windows.h" #include "windows/axutil_uuid_gen_windows.h" #include "windows/axutil_getopt_windows.h" #include "windows/axutil_date_time_util_windows.h" #include "windows/axutil_thread_windows.h" #elif defined ( __OS400__ ) #include #elif defined ( AIX ) #include #elif defined ( HPUX ) #include #elif defined (ANDROID) #include #else #include #endif Any thoughts or suggestions please. Thanks, Diluka. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving REST Support
I had a chat with Keith, who did the REST stuff in Axis2/Java.
They have implemented this with WSDL 2.0, which we do not have.
So, we have to go with the service.xml model. Apparently, Axis2/Java too
seem to have plans to do that model as well.
We can use annotations to map to the HTTP method/operation/parameters in
the service.xml file.
e.g.
GET:add/{a}/{b}
PUT:setQuote/{name}/{price}
In terms of dispatching, the payload could be built only when we look at
and understand the request URI. Hence, we have to implement a "REST
Dispatcher". This would be similar to the URI based dispatcher. However,
would not be on the same path as the SOAP processing path. Once the
request comes, we can get to know it if is SOAP or REST by looking at
the content type, and if it is SOAP we invoke the regular dispatchers
and if now, invoke the REST dispatcher. After dispatching, the remainder
of the invocation would be the same for both REST and SOAP.
Thanks,
Samisa...
Samisa Abeysinghe wrote:
Senaka Fernando wrote:
Hi Dave, and others,
Thanks for the input. I will consider what you've mentioned here. I also
would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
Richardson describe as a RESTful Web Service. The REST API doc can be
found at [1].
According to what is mentioned in the post by Dave as well as in the
book by
Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the
ability of
adding the resource name after the name of the operation. And, most
importantly we are not reconizing this as a resource. Therefore,
these are
the proposals for the logic.
1. In the services.xml, the Service Author must be able to specify the
format of the resource(s) he expects with slashes.
ex:- http://www.sample.com/service/operation/resource =>
http://www.sample.com/service/operation/first/second
resource => {name}/{subname}
Is this the way Axis2/Java folks has done it. We do not need to
re-invent the wheel here. Can have a peek into how Java folks have
done it, because it is the same architecture.
2. We need to read this from the services.xml and store it on the
message
context.
2. In the uri based dispatcher, we need to read the message context,
find
the resource id format and recognize the resource, then we must add the
resource data into the message context.
Rather than adding resource data, we can build the request payload as
an AXIOM model. This way we can keep the SOAP and REST models the same
- useful when exposing the services in both ways.
Also, when this is implemented, the model that we already have should
be kept in place - that is the current implementation with the request
parameters. Since that works, it is worth keeping that too.
3. The http_method will also be added onto the message context.
This is a transport level detail. So it should be handled at transport
level. I am not sure if we have this detail in message context right
now. Anyway, when adding PUT and DELETE, you can use the same
techniques we are already using for GET and POST. Put is analogous to
POST and DELETE to GET. Since our GET and PORT already work well, we
better use the same techniques.
4. Do the processing according to current implementation, and make
use of
http_method as well as resource details.
5. The service writes the state of the operation back onto the message
context.
6. We read the state on the message context and respond with appropriate
http_status_code and payload.
5 and 6 are already in place for GET & POST. You just need to add PUT
and DELETE.
An interesting question would be to see how to map the semantics of
PUT and DELETE to operation invocations. As an example, DELETE is
supposed to remove a resource - does this mean that we are removing an
operation? Does PUT mean we are adding a new operation? I am still not
clear on how to map that. Again Axis2/Java could come to rescue.
Thanks,
Samisa...
-
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: [Axis2] WSDL2C testing
Hi, No, we are not having any tests for the WSDL2c inside axis2/c. Instead I'm doing testing with different WSDLs[1] that users have come across. Currently testing is done using a shell script. I m also +1 for testing the current WSDLs in the tests directory. For that I think we may need to add some code to the current Axis2/c test suite. [1] (A little older codegen test suite) http://people.apache.org/~dimuthu/leisure/1_dec/wsdl2ctests.tar.bz2 Thanks Dimuthu On Jan 23, 2008 8:05 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote: > Are we testing the WSDLs in the tests folder with the codegen tool? > > Thanks, > Samisa... > > - > 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: Improving REST Support
Dave Meier wrote: Yes, I had forgotten to put the operation name into the URL. So the server should figure out the operation from the "service/operation" portion instead of requiring the operation name in an XML payload. Is this something that is happening in the near term (these changes)? I have until late February/early March to complete my work including REST calls. First, I think we should do it now rather than be late on it. Also, looking at the amount of stuff we do, we should be able to have the initial stuff working by early next month. Anyway, when we start on the real implementtion, we would know for sure how long that would take. Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving REST Support
Senaka Fernando wrote:
Hi Dave, and others,
Thanks for the input. I will consider what you've mentioned here. I also
would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
Richardson describe as a RESTful Web Service. The REST API doc can be
found at [1].
According to what is mentioned in the post by Dave as well as in the book by
Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the ability of
adding the resource name after the name of the operation. And, most
importantly we are not reconizing this as a resource. Therefore, these are
the proposals for the logic.
1. In the services.xml, the Service Author must be able to specify the
format of the resource(s) he expects with slashes.
ex:- http://www.sample.com/service/operation/resource =>
http://www.sample.com/service/operation/first/second
resource => {name}/{subname}
Is this the way Axis2/Java folks has done it. We do not need to
re-invent the wheel here. Can have a peek into how Java folks have done
it, because it is the same architecture.
2. We need to read this from the services.xml and store it on the message
context.
2. In the uri based dispatcher, we need to read the message context, find
the resource id format and recognize the resource, then we must add the
resource data into the message context.
Rather than adding resource data, we can build the request payload as an
AXIOM model. This way we can keep the SOAP and REST models the same -
useful when exposing the services in both ways.
Also, when this is implemented, the model that we already have should be
kept in place - that is the current implementation with the request
parameters. Since that works, it is worth keeping that too.
3. The http_method will also be added onto the message context.
This is a transport level detail. So it should be handled at transport
level. I am not sure if we have this detail in message context right
now. Anyway, when adding PUT and DELETE, you can use the same techniques
we are already using for GET and POST. Put is analogous to POST and
DELETE to GET. Since our GET and PORT already work well, we better use
the same techniques.
4. Do the processing according to current implementation, and make use of
http_method as well as resource details.
5. The service writes the state of the operation back onto the message
context.
6. We read the state on the message context and respond with appropriate
http_status_code and payload.
5 and 6 are already in place for GET & POST. You just need to add PUT
and DELETE.
An interesting question would be to see how to map the semantics of PUT
and DELETE to operation invocations. As an example, DELETE is supposed
to remove a resource - does this mean that we are removing an operation?
Does PUT mean we are adding a new operation? I am still not clear on how
to map that. Again Axis2/Java could come to rescue.
Thanks,
Samisa...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2C-857) guththila parser drops xml:id attributes from incoming elements
[ https://issues.apache.org/jira/browse/AXIS2C-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-857: - Attachment: diff2.txt Lahira, it's a nice start on a patch; it's certainly in the right direction. In testing it I uncovered a few minor coding errors. In guththila_init(), (a) the declarations needed to come at the start of the block, (b) the namespace size is getting setting wrong, as it needs strlen(), sizeof is rounding up to the next multiple of the machine word, (c) the code did not handle out-of-memory on the token creates. In guththila_token_create, (d) it was allocating the wrong length of for the string and the token structure, and (e) it was not actually returning the pointer to the allocated token to the caller. In the attached diff2.txt, I corrected the coding errors and the client app now sees the xml:id attributes on the elements and can process them. Thanks for getting this started. > guththila parser drops xml:id attributes from incoming elements > --- > > Key: AXIS2C-857 > URL: https://issues.apache.org/jira/browse/AXIS2C-857 > Project: Axis2-C > Issue Type: Bug > Components: guththila >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: diff.txt, diff2.txt > > > The XML specification allows an element to carry an xml:id attribute without > the xml namespace being declared explicitly. In fact, if the xml namespace > is declared, it must match http://www.w3.org/XML/1998/namespace. When the > namespace is not declared explicitly, it appears that the guththila parser > discards the incoming xml:id attributes without including them in the om. > For example, I receive a response message from a service that begins: > http://www.w3.org/2001/XMLSchema"; > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:fw="http://frameware.xcentrisity.com/services/";> > > name="customer" supportedMethods="browse browseNext browsePrevious create > update delete retrieve"> > > > > > ... > When linked with libxml, the client code sees two attributes, a type > attribute and an xml:id attribute, attached to the element nodes. When > linked with the guththila parser, only the type attribute is present. -- 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: [Axis2] Can we make Guththila the default parser?
Supun Kamburugamuva wrote: Making guththila as the default parser may cause us few problems in the short terms. What sort of? But it will definitely improve Guththila code and I think this is a good choice if we consider the long term issues like dependencies, efficiency, modifiebility etc. Most of the major bugs of Guththila are reported and some are corrected by now. So I don't think making Guththila as the default parser will cause any major issues. So rampart would be OK. How about Sandesha, savan etc? Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-922) axis2_http_server.exe crashes in axis2_getopt
[ https://issues.apache.org/jira/browse/AXIS2C-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561823#action_12561823 ] Dave Meier commented on AXIS2C-922: --- Hi Senaka, I just rebuilt with VS 2005 and verified that yes it does work on 2005, but fails on 2003. I guess the /MDd flag results in different behaviour on 2003. I'll just keep building my debug copy with 2003 and no /MDd flag as the 2005 version does not allow me to debug axis2c code from my 2003 project. -Dave. > axis2_http_server.exe crashes in axis2_getopt > - > > Key: AXIS2C-922 > URL: https://issues.apache.org/jira/browse/AXIS2C-922 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) >Affects Versions: 1.2.0 > Environment: Windows XP >Reporter: Dave Meier > > Crashes on this line: > if (optind >= __argc || *(pos = __argv[optind]) != '-') > I changed the makefile and was able to get it to work. Changed to the > following: > !if "$(DEBUG)" == "1" > CFLAGS = $(CFLAGS) /D "_DEBUG" /Od /Z7 > LDFLAGS = $(LDFLAGS) /DEBUG /INCREMENTAL /NODEFAULTLIB:LIBCMTD.lib > !else > CFLAGS = $(CFLAGS) /D "NDEBUG" /O2 /MT > LDFLAGS = $(LDFLAGS) > !endif > Basically for the DEBUG case, I removed the $(CRUNTIME)d from CFLAGS and > added back the /NODEFAULTLIB:LIBCMTD.lib to LDFLAGS that was there in 1.1. > Also changed $(CRUNTIME) to /MT for the release mode CFLAGS. > In my configure.in, I had CRUNTIME=/MD -- 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: [Axis2] Can we make Guththila the default parser?
> Hi, > I tried with the svn head and had no luck. :(. > The problem is still there. Seems the patch here[1] has already applied > to the head. > Can somebody shed some light on this? Is it necessary to re-open the issue? I have corrected the issue and changes are in the svn head. That patch [1] wasn't completely applied to the head. One part was there and other part was missing. Anyway I have corrected the original problem (duplicating namespaces). I couldn't try it with Rampart samples (I have lot of changes in my rampart source and at the moment it is not compling -). Making guththila as the default parser may cause us few problems in the short terms. But it will definitely improve Guththila code and I think this is a good choice if we consider the long term issues like dependencies, efficiency, modifiebility etc. Most of the major bugs of Guththila are reported and some are corrected by now. So I don't think making Guththila as the default parser will cause any major issues. Regards, Supun... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2C-922) axis2_http_server.exe crashes in axis2_getopt
[ https://issues.apache.org/jira/browse/AXIS2C-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561817#action_12561817 ] Senaka Fernando commented on AXIS2C-922: Hi Dave, I did not get any server crash. I'm building with Visual Studio .NET 2005. I don't see any reason to why this should not build on VS2003? These are some details from my configure.in. ENABLE_SSL = 0 ENABLE_LIBCURL= 0 ENABLE_GUTHTHILA = 0 WITH_TCP= 0 WITH_ARCHIVE = 1 APACHE_VERSION_2_0_X = 0 CRUNTIME=/MD EMBED_MANIFEST = 1 DEBUG=1 By the way, I built axis2/c using build.bat after calling vcvars32.bat found in the VC\bin folder of Visual Studio 2005. My nmake version is 8.00.50727.762. Regards, Senaka > axis2_http_server.exe crashes in axis2_getopt > - > > Key: AXIS2C-922 > URL: https://issues.apache.org/jira/browse/AXIS2C-922 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) >Affects Versions: 1.2.0 > Environment: Windows XP >Reporter: Dave Meier > > Crashes on this line: > if (optind >= __argc || *(pos = __argv[optind]) != '-') > I changed the makefile and was able to get it to work. Changed to the > following: > !if "$(DEBUG)" == "1" > CFLAGS = $(CFLAGS) /D "_DEBUG" /Od /Z7 > LDFLAGS = $(LDFLAGS) /DEBUG /INCREMENTAL /NODEFAULTLIB:LIBCMTD.lib > !else > CFLAGS = $(CFLAGS) /D "NDEBUG" /O2 /MT > LDFLAGS = $(LDFLAGS) > !endif > Basically for the DEBUG case, I removed the $(CRUNTIME)d from CFLAGS and > added back the /NODEFAULTLIB:LIBCMTD.lib to LDFLAGS that was there in 1.1. > Also changed $(CRUNTIME) to /MT for the release mode CFLAGS. > In my configure.in, I had CRUNTIME=/MD -- 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] Commented: (AXIS2C-913) Rampart/C scenario4 onwards are not working with Guththila
[ https://issues.apache.org/jira/browse/AXIS2C-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561815#action_12561815 ] Supun Kamburugamuva commented on AXIS2C-913: The patch attached in this jira tried to correct the issue by reverting a change done in a previous patch. That previous patch was incorrect. The patch attached here doesn't solve the problem instead it introduces a bug that was there preiously. I have commited the changes nessary to correct the duplicating namespaces problem. This is the problem addressed by the previous patch. > Rampart/C scenario4 onwards are not working with Guththila > -- > > Key: AXIS2C-913 > URL: https://issues.apache.org/jira/browse/AXIS2C-913 > Project: Axis2-C > Issue Type: Bug > Components: build system (Unix/Linux) >Affects Versions: Current (Nightly) > Environment: ubuntu7.10 >Reporter: Lahiru Gunathilake >Assignee: Sanjaya Ratnaweera > Fix For: Current (Nightly) > > Attachments: diff.txt > > > when Axis2c build with guththila and run rampart samples it works up to > scenario4.But from scenario4 including itself is not working with Guththila. -- 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: Improving REST Support
Yes, I had forgotten to put the operation name into the URL. So the
server should figure out the operation from the "service/operation"
portion instead of requiring the operation name in an XML payload.
Is this something that is happening in the near term (these changes)? I
have until late February/early March to complete my work including REST
calls.
Thanks!
-Dave.
-Original Message-
From: Senaka Fernando [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 23, 2008 11:36 AM
To: Apache AXIS C Developers List
Subject: RE: Improving REST Support
Hi Dave, and others,
Thanks for the input. I will consider what you've mentioned here. I also
would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
Richardson describe as a RESTful Web Service. The REST API doc can be
found at [1].
According to what is mentioned in the post by Dave as well as in the
book by Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the
ability of adding the resource name after the name of the operation.
And, most importantly we are not reconizing this as a resource.
Therefore, these are the proposals for the logic.
1. In the services.xml, the Service Author must be able to specify the
format of the resource(s) he expects with slashes.
ex:- http://www.sample.com/service/operation/resource =>
http://www.sample.com/service/operation/first/second
resource => {name}/{subname}
2. We need to read this from the services.xml and store it on the
message context.
2. In the uri based dispatcher, we need to read the message context,
find the resource id format and recognize the resource, then we must add
the resource data into the message context.
3. The http_method will also be added onto the message context.
4. Do the processing according to current implementation, and make use
of http_method as well as resource details.
5. The service writes the state of the operation back onto the message
context.
6. We read the state on the message context and respond with appropriate
http_status_code and payload.
Any comments are most warmly welcome. We also need to add PUT and DELETE
support, which will be relatively easy as it is the services'
responsibility to handle these.
[1] http://docs.amazonwebservices.com/AmazonS3/2006-03-01/RESTAPI.html
Thanks,
Senaka.
> Hi,
>
> I agree that it would be nice to have flexibility with REST as far as
> the I/O to the service. Right now, I am using WSDL2C to generate code
> for my project and the way the code is generated, it requires that the
> high level request and response is always there. If the code
> generation was also updated to be more flexible in handling REST style
> requests, that would really help.
>
> As an example with GET, I have a method that returns all the data
> associated with an item id. The SOAP request requires a structure
> that contains the item id along with userid and password for
authentication.
> Using REST, I would put the item id in the URL, then probably put the
> userid and encoded password into the query string of the URL. If
> there are easy ways to retrieve both pieces of information from inside
> my service that would be great. In the generated code I would like
> the call to go through to my service even if there is no XML payload.
> Then for the response I want to send XML describing the item without
> the SOAP envelope.
>
> If I was using REST to update an item in my service, I would require
> that the XML representation of the item is provided in a PUT. For
> this case it would be the same as the SOAP case except for the lack of
> a SOAP envelope. The only difference might be that I could have the
> item id in the URL and possibly the authentication info as in the GET
> case. Also, all of my data elements in the item are optional, so if
> only one part of the item needs to be updated, only that XML element
would be necessary.
> I suppose for these simple update cases, I could allow the update to
> occur as a GET, with the fields being updated by putting field name
> and value in the query string (e.g.
> http://host:9090/axis2/services/myservice/item543?userid=dave&password
> =A FDGA3435FD&title="my%20new%20title"). For the response I could
> either send an HTTP code or the updated item in XML.
>
> -Dave.
>
> -Original Message-
> From: Senaka Fernando [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 22, 2008 8:23 PM
> To: axis-c-dev@ws.apache.org
> Subject: Improving REST Support
>
> Hi all,
>
> I'm interested in improving the REST support on Axis2/C. As a step
> towards improving the REST support, what I can do is relay to the
> service that a particular type of request was made through the message
> context and retrieve the appropriate response from the message context
> and reply to the sender. This wont be that much of a trouble in doing.
> The point is since we are talking about services, the service will
> decide what it would do with the request, not the server. If not, when
>
RE: Improving REST Support
Hi Dave, and others,
Thanks for the input. I will consider what you've mentioned here. I also
would like to draw your attention to AmazonS3, which Sam Ruby & Leonard
Richardson describe as a RESTful Web Service. The REST API doc can be
found at [1].
According to what is mentioned in the post by Dave as well as in the book by
Sam Ruby & Leonard Richardson, I believe that Axis2/C lacks the ability of
adding the resource name after the name of the operation. And, most
importantly we are not reconizing this as a resource. Therefore, these are
the proposals for the logic.
1. In the services.xml, the Service Author must be able to specify the
format of the resource(s) he expects with slashes.
ex:- http://www.sample.com/service/operation/resource =>
http://www.sample.com/service/operation/first/second
resource => {name}/{subname}
2. We need to read this from the services.xml and store it on the message
context.
2. In the uri based dispatcher, we need to read the message context, find
the resource id format and recognize the resource, then we must add the
resource data into the message context.
3. The http_method will also be added onto the message context.
4. Do the processing according to current implementation, and make use of
http_method as well as resource details.
5. The service writes the state of the operation back onto the message
context.
6. We read the state on the message context and respond with appropriate
http_status_code and payload.
Any comments are most warmly welcome. We also need to add PUT and DELETE
support, which will be relatively easy as it is the services'
responsibility to handle these.
[1] http://docs.amazonwebservices.com/AmazonS3/2006-03-01/RESTAPI.html
Thanks,
Senaka.
> Hi,
>
> I agree that it would be nice to have flexibility with REST as far as
> the I/O to the service. Right now, I am using WSDL2C to generate code
> for my project and the way the code is generated, it requires that the
> high level request and response is always there. If the code generation
> was also updated to be more flexible in handling REST style requests,
> that would really help.
>
> As an example with GET, I have a method that returns all the data
> associated with an item id. The SOAP request requires a structure that
> contains the item id along with userid and password for authentication.
> Using REST, I would put the item id in the URL, then probably put the
> userid and encoded password into the query string of the URL. If there
> are easy ways to retrieve both pieces of information from inside my
> service that would be great. In the generated code I would like the
> call to go through to my service even if there is no XML payload. Then
> for the response I want to send XML describing the item without the SOAP
> envelope.
>
> If I was using REST to update an item in my service, I would require
> that the XML representation of the item is provided in a PUT. For this
> case it would be the same as the SOAP case except for the lack of a SOAP
> envelope. The only difference might be that I could have the item id in
> the URL and possibly the authentication info as in the GET case. Also,
> all of my data elements in the item are optional, so if only one part of
> the item needs to be updated, only that XML element would be necessary.
> I suppose for these simple update cases, I could allow the update to
> occur as a GET, with the fields being updated by putting field name and
> value in the query string (e.g.
> http://host:9090/axis2/services/myservice/item543?userid=dave&password=A
> FDGA3435FD&title="my%20new%20title"). For the response I could either
> send an HTTP code or the updated item in XML.
>
> -Dave.
>
> -Original Message-
> From: Senaka Fernando [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 22, 2008 8:23 PM
> To: axis-c-dev@ws.apache.org
> Subject: Improving REST Support
>
> Hi all,
>
> I'm interested in improving the REST support on Axis2/C. As a step
> towards improving the REST support, what I can do is relay to the
> service that a particular type of request was made through the message
> context and retrieve the appropriate response from the message context
> and reply to the sender. This wont be that much of a trouble in doing.
> The point is since we are talking about services, the service will
> decide what it would do with the request, not the server. If not, when
> considering PUT, DELETE, etc. how am I to implement them?
>
> I read through the references below, plus some others which were not
> that very helpful. Hope that they may be of some help.
>
> Thanks,
> Senaka
>
> References:
> [1] http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
> [2] http://java.sun.com/developer/technicalArticles/WebServices/restful/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> **
RE: Improving REST Support
Hi, I agree that it would be nice to have flexibility with REST as far as the I/O to the service. Right now, I am using WSDL2C to generate code for my project and the way the code is generated, it requires that the high level request and response is always there. If the code generation was also updated to be more flexible in handling REST style requests, that would really help. As an example with GET, I have a method that returns all the data associated with an item id. The SOAP request requires a structure that contains the item id along with userid and password for authentication. Using REST, I would put the item id in the URL, then probably put the userid and encoded password into the query string of the URL. If there are easy ways to retrieve both pieces of information from inside my service that would be great. In the generated code I would like the call to go through to my service even if there is no XML payload. Then for the response I want to send XML describing the item without the SOAP envelope. If I was using REST to update an item in my service, I would require that the XML representation of the item is provided in a PUT. For this case it would be the same as the SOAP case except for the lack of a SOAP envelope. The only difference might be that I could have the item id in the URL and possibly the authentication info as in the GET case. Also, all of my data elements in the item are optional, so if only one part of the item needs to be updated, only that XML element would be necessary. I suppose for these simple update cases, I could allow the update to occur as a GET, with the fields being updated by putting field name and value in the query string (e.g. http://host:9090/axis2/services/myservice/item543?userid=dave&password=A FDGA3435FD&title="my%20new%20title"). For the response I could either send an HTTP code or the updated item in XML. -Dave. -Original Message- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 8:23 PM To: axis-c-dev@ws.apache.org Subject: Improving REST Support Hi all, I'm interested in improving the REST support on Axis2/C. As a step towards improving the REST support, what I can do is relay to the service that a particular type of request was made through the message context and retrieve the appropriate response from the message context and reply to the sender. This wont be that much of a trouble in doing. The point is since we are talking about services, the service will decide what it would do with the request, not the server. If not, when considering PUT, DELETE, etc. how am I to implement them? I read through the references below, plus some others which were not that very helpful. Hope that they may be of some help. Thanks, Senaka References: [1] http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1) [2] http://java.sun.com/developer/technicalArticles/WebServices/restful/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (AXIS2C-922) axis2_http_server.exe crashes in axis2_getopt
[ https://issues.apache.org/jira/browse/AXIS2C-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561740#action_12561740 ] hoodoo99 edited comment on AXIS2C-922 at 1/23/08 9:17 AM: I just got the latest source code from svn and built the debug version again. If I put /MDd in the CFLAGS I get the crash, and if I take it out everything works fine. I am building with Visual Studio .NET 2003. The axis2_http_server.exe program crashes immediately when it is started in getopt_windows.c as described in my last comment. -Dave. was (Author: hoodoo99): I just got the latest source code from svn and built the debug version again. If I put i/MDd in the CFLAGS I get the crash, and if I take it out everything works fine. I am building with Visual Studio .NET 2003. The axis2_http_server.exe program crashes immediately when it is started in getopt_windows.c as described in my last comment. -Dave. > axis2_http_server.exe crashes in axis2_getopt > - > > Key: AXIS2C-922 > URL: https://issues.apache.org/jira/browse/AXIS2C-922 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) >Affects Versions: 1.2.0 > Environment: Windows XP >Reporter: Dave Meier > > Crashes on this line: > if (optind >= __argc || *(pos = __argv[optind]) != '-') > I changed the makefile and was able to get it to work. Changed to the > following: > !if "$(DEBUG)" == "1" > CFLAGS = $(CFLAGS) /D "_DEBUG" /Od /Z7 > LDFLAGS = $(LDFLAGS) /DEBUG /INCREMENTAL /NODEFAULTLIB:LIBCMTD.lib > !else > CFLAGS = $(CFLAGS) /D "NDEBUG" /O2 /MT > LDFLAGS = $(LDFLAGS) > !endif > Basically for the DEBUG case, I removed the $(CRUNTIME)d from CFLAGS and > added back the /NODEFAULTLIB:LIBCMTD.lib to LDFLAGS that was there in 1.1. > Also changed $(CRUNTIME) to /MT for the release mode CFLAGS. > In my configure.in, I had CRUNTIME=/MD -- 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] Commented: (AXIS2C-922) axis2_http_server.exe crashes in axis2_getopt
[ https://issues.apache.org/jira/browse/AXIS2C-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561740#action_12561740 ] Dave Meier commented on AXIS2C-922: --- I just got the latest source code from svn and built the debug version again. If I put i/MDd in the CFLAGS I get the crash, and if I take it out everything works fine. I am building with Visual Studio .NET 2003. The axis2_http_server.exe program crashes immediately when it is started in getopt_windows.c as described in my last comment. -Dave. > axis2_http_server.exe crashes in axis2_getopt > - > > Key: AXIS2C-922 > URL: https://issues.apache.org/jira/browse/AXIS2C-922 > Project: Axis2-C > Issue Type: Bug > Components: build system (Windows) >Affects Versions: 1.2.0 > Environment: Windows XP >Reporter: Dave Meier > > Crashes on this line: > if (optind >= __argc || *(pos = __argv[optind]) != '-') > I changed the makefile and was able to get it to work. Changed to the > following: > !if "$(DEBUG)" == "1" > CFLAGS = $(CFLAGS) /D "_DEBUG" /Od /Z7 > LDFLAGS = $(LDFLAGS) /DEBUG /INCREMENTAL /NODEFAULTLIB:LIBCMTD.lib > !else > CFLAGS = $(CFLAGS) /D "NDEBUG" /O2 /MT > LDFLAGS = $(LDFLAGS) > !endif > Basically for the DEBUG case, I removed the $(CRUNTIME)d from CFLAGS and > added back the /NODEFAULTLIB:LIBCMTD.lib to LDFLAGS that was there in 1.1. > Also changed $(CRUNTIME) to /MT for the release mode CFLAGS. > In my configure.in, I had CRUNTIME=/MD -- 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: [Axis2] Can we make Guththila the default parser?
Hi, I tried with the svn head and had no luck. :(. The problem is still there. Seems the patch here[1] has already applied to the head. Can somebody shed some light on this? Is it necessary to re-open the issue? -Kau [1]https://issues.apache.org/jira/browse/AXIS2C-913 Kaushalye Kapuruge wrote: Hi Samisa, We had few issues running security samples with Guththila. Hope those are fixed by now. I will try build Axis2/C with guththila and engage Apache Ramaprt/C. Cheers, Kaushalye Samisa Abeysinghe wrote: Can we make Guththila the default parser in the future releases? Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://blog.kaushalye.org/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] Can we make Guththila the default parser?
Hi Samisa, We had few issues running security samples with Guththila. Hope those are fixed by now. I will try build Axis2/C with guththila and engage Apache Ramaprt/C. Cheers, Kaushalye Samisa Abeysinghe wrote: Can we make Guththila the default parser in the future releases? Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://blog.kaushalye.org/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Can we make Guththila the default parser?
Can we make Guththila the default parser in the future releases? Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] WSDL2C testing
Are we testing the WSDLs in the tests folder with the codegen tool? Thanks, Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF policy on cryptographic features
I raised a JIRA here[1]. -Kau [1]https://issues.apache.org/jira/browse/AXIS2C-931 Kaushalye Kapuruge wrote: Devs, Since Apache Axis2/C is having cryptographic features (for https support), it needs to be listed here[1] according to the ASF policy. Please find more details here[2]. This has to be done by someone having site-dev karma (which includes all of the PMC chairs) Cheers, Kaushalye [1]http://www.apache.org/licenses/exports/ [2]http://www.apache.org/dev/crypto.html -- http://blog.kaushalye.org/ http://wso2.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2C-931) ASF policy on cryptographic features
ASF policy on cryptographic features Key: AXIS2C-931 URL: https://issues.apache.org/jira/browse/AXIS2C-931 Project: Axis2-C Issue Type: Task Components: documentation Affects Versions: Current (Nightly) Environment: N/A Reporter: Malinda Kaushalye Kapuruge Fix For: 1.2.1 Since Apache Axis2/C is having cryptographic features (for https support), it needs to be listed here[1] according to the ASF policy. Please find more details here[2]. This has to be done by someone having site-dev karma (which includes all of the PMC chairs). [1]http://www.apache.org/licenses/exports/ [2]http://www.apache.org/dev/crypto.html -- 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] Commented: (AXIS2C-866) REOPEN - /util/src/base64.c incorrect calculation of length in 'axutil_base64_decode_len'
[
https://issues.apache.org/jira/browse/AXIS2C-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561622#action_12561622
]
Dumindu Pallewela commented on AXIS2C-866:
--
+1 for option 4.
I don't see a reason why a null termination is needed here. It should be left
for the caller to add a null character if he needs it.
> REOPEN - /util/src/base64.c incorrect calculation of length in
> 'axutil_base64_decode_len'
> -
>
> Key: AXIS2C-866
> URL: https://issues.apache.org/jira/browse/AXIS2C-866
> Project: Axis2-C
> Issue Type: Bug
> Components: util
>Affects Versions: 1.2.0
>Reporter: Frank Huebbers
>Priority: Critical
>
> Hi,
> First off, I am opening a new issue here because I don't seem to be able to
> reopen case AXIS2C-731 which does not yet seem to be fixed either for the
> release candidate 1.2.0 (Take 4) nor on head.
> Specifically, it appears as if the proposed bug fix in AXIS2C-731 did not
> make it 1-to-1 into CVS. To reiterate, the proposed bug fix was:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded;
> }
> What actually made it into 1.2.0 and head is the following:
> AXIS2_EXTERN int AXIS2_CALL axutil_base64_decode_len(const char *bufcoded)
> {
> int nbytesdecoded;
> register const unsigned char *bufin;
> register int nprbytes;
> bufin = (const unsigned char *) bufcoded;
> while (pr2six[*(bufin++)] <= 63);
> nprbytes = (bufin - (const unsigned char *) bufcoded) - 1;
> nbytesdecoded = ((nprbytes >> 2) * 3);
> if (nprbytes & 0x03) nbytesdecoded += (nprbytes & 0x03) - 1;
> return nbytesdecoded + 1;
> }
> => Note the "+1" on the return type.
> Frank
--
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]
Sending large attachments with Axis2/C with httpd
Hi devs, While I am working on ,https://issues.apache.org/jira/browse/AXIS2C-862 i found with httpd it takes around 800MB of memory to process a 40MB attachment. The reason is when processing the request with an optimized binary data the entire SOAP message is parsed by mime_parse_parse() method to separates the soap envelope and mime parts. Since the incoming stream is read block by block, after processing a block the parser reallocates the whole (previous + new) for the precessing of second block. With simple axis server this is not a problem , because it uses free () method to release the memory. But with httpd since we are allocating memory from pool and releasing the pool is done by httpd the memory usage grows, hence after 3 or 4 requests the system crashes due to limited memory. Actually the main problem here is httpd does not release the request pool even after processing the request. So I create my own pool using my own allocator and destroy both after processing the request. This cause problems with Sandesha2/c becasue freeng allocator (here allocator means apr_allocator not axutil_allocator)cause problems because Sandesha2/C creates its own threads and those threads use the allocator. Even the above solution does not prevent using larger amount of memory to process large attachments. So I think we need to change the mime_parser to process each block separately and concatenate them. The problem with this approach is the search string(eg : MimeBoundary) may not contain in one buffer. I am trying to come up with an algorithm for this problem. Any thoughts? Thanks, -Manjula. -- Manjula Peiris: http://manjula-peiris.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
