Hi Folks,
attachment specifications (mTom, attachment
profiles ?) are a mystery to me. Could someone tell me (briefly) what type
we are supporting in the current implementation?
The serialisation code looks remarkably
simple !
thanks,
John.
Hi Folks,
how is the attachment support coming
along?
Hi,
I was looking at the attachment support. Does anyone know...
- whether attachments are currently being worked on and whether this
support will be completed in 1.6?
- whether Axis C++ will support attachments defined in the wsdl and
referenced from the soap body? Or will these
Hi All,
I tested attachments (on server side)in Windows using VC (Not using ANT
build) & it's working.
I couldn't test with the ANT build because ANT is not building
properly.
Once ANT is working I can check in Windows & Linux.Till then I'm not
committing the code sin
Hi Damitha, Rangika,
I am very interested in attachment support in the client. If possible, I
would like to work with you on completing this. In particular I would like
doc-literal support - so if your current support is rpc-encoded, I could
add in doc-literal support.
I was expecting to see a
Hi,
I'm starting to implement client side attachments, including attachments
referenced from the soap body. I'm intending to...
- Add the attachments methods that are currently on IWrapperSoapSerializer
to Call as well
- Add in AttachmentReference (internal implement
Hi John,
Attachment specification
we used is SOAP Messages with Attachments, W3C Note 11 December
2000the link is given below,http://www.w3.org/TR/SOAP-attachmentsThe above specification describes a
standard way to associate a SOAP message with one or more attachments in
Hi John,
Server side ws-attachments is
complete.
Regards,
Rangika
- Original Message -
From:
John
Hawkins
To: axis-c-dev@ws.apache.org
Sent: Monday, April 11, 2005 7:30
PM
Subject: attachments
Hi Folks, how is the attachment support coming
along?
Hi Rangika,
How
can we test those? Do we have a sample?
Thanks,
Samisa…
-Original Message-
From: Rangika Mendis
[mailto:[EMAIL PROTECTED]
Sent: Monday, April 18, 2005 10:44
AM
To: Apache AXIS C Developers List
Subject: Re: attachments
Hi John
elopers List"
To
"Apache AXIS C Developers
List"
cc
Subject
Re: attachments
Hi John,
Server side ws-attachments is complete.
Regards,
Rangika
- Original Message -
From: John
Hawkins
To: axis-c-dev@ws.apache.org
Sent: Monday, April 11, 2005 7:30 PM
Subject:
Hi Samisa,
I will test attachments with a sample client &
if it's working will send it to you.
Rangika
- Original Message -
From:
Samisa
Abeysinghe
To: Apache AXIS C Developers List
Sent: Monday, April 18, 2005 10:42
AM
Subject: RE: at
Hi Rangika,
so, is this a CPP client?
"Rangika Mendis"
<[EMAIL PROTECTED]>
18/04/2005 13:36
Please respond to
"Apache AXIS C Developers List"
To
"Apache AXIS C Developers
List"
cc
Subject
Re: attachments
Hi Samisa,
I will test a
Hi John,
Yes it's a cpp client.
Rangika
- Original Message -
From:
John
Hawkins
To: Apache AXIS C Developers List
Sent: Monday, April 18, 2005 10:26
PM
Subject: Re: attachments
Hi Rangika, so, is this a CPP client?
"Rang
Hi John,
I'm sorry for the earlier reply.
The client that I'm using is a socket program
that's just used for testing.It will just send couple of attachments to the
server port &
& then the engine will handle the
attachments.
Rangika
- Origina
So as I understand, you write the raw SOAP
message directly to the server.
Still I think this client would help us
when implementing Client side attachments.
Please attach this client to a Jira issue.
Thanks,
Samisa…
-Original Message-
From: Rangika Mendis
[mailto
derstand.
Request header field is missing ':' separator.
start="<1505912FEDEB53D396BC22103DA3A51A>";
Apache/2.0.48 (Win32) Server at abc Port
80
Can anyone help me on this???
Regards,
Rangika
- Original Message -
From:
Samisa
Abeysinghe
To:
PROTECTED]
Sent: Tuesday, April 19, 2005 12:36 PM
To: Apache AXIS C Developers List
Subject: Re: attachments
Hi Samisa,
I tested attachment support with the
socket client in February and it worked. But now when I tried to see whether
it's working I get the following
that's fine :-)
I'm still not clear though - maybe it's
me :-(
Do attachments work in Axis CPP or not
(I think not).
If not do you have any idea if you are
going to be able to finish them or not. If not - can you leave some docs
or something to give others the way forward?
Hi,
Attachments was working in Axis CPP for Server Side, but currently there seems to be a problem with the stimulated client request message. Need to check on it.
Design document was posted on the mailing list.
Regards,
Nithya
On Tue, 19 Apr 2005 09:46:29 +0100, John Hawkins wrote
Hi Nithya,
Do
we have some partial implementation of client side (not server side)
attachments?
I
see some mime related code included in HTTPTransport
class of axis3. I think this is an attempt to implement attachments. Any
thoughts on how much work is remaining
Hi Samisa,
Client side support for ws-attachments was undertaken by Damitha, I am not very sure about the depth
of work completed.
Regards,
Nithya
On Wed, 20 Apr 2005 10:30:04 +0600, Samisa Abeysinghe wrote
> Hi Nithya,
> Do we have some partial implementat
=
--=MIME BOUNDARY
We're working on this currently.
Regds
Rangika
- Original Message -
From: "Mark Whitlock" <[EMAIL PROTECTED]>
To:
Sent: Monday, April 25, 2005 7:26 PM
Subject: Attachments
>
>
>
>
> Hi,
>
> I was looking at the attachment supp
25/04/2005 15:12
cc
Please respond to Subject
"Apache AXIS C Re: Attachments
t; <[EMAIL PROTECTED]>
To:
Sent: Monday, April 25, 2005 9:03 PM
Subject: Fw: Attachments
>
>
>
>
> Hi Rangika,
> Thanks for your quick response. Users will benefit from the attachment
> support that you're putting in :-)
>
> I noticed that the soap message i
May
be this is not a question to ask:
Is
the return value:
?
Base64
encoded?
thanks
-Lilantha
-Original
Message-
From: Rangika Mendis [mailto:[EMAIL PROTECTED]
Sent: Monday, April 25, 2005 10:13 AM
To: Apache AXIS C Developers List
Subject: Re: Attachments
Hi
pache AXIS C Developers List
Sent: Tuesday, April 26, 2005 7:40
PM
Subject: RE: Attachments
May be this is not a question to
ask:
Is the return value:
?
Base64 encoded?
thanks
-Lilantha
-Original Message-From: Rangika Mendis
[mailto:[
IS C Developers
cc
Subject
Attachments
Hi All,
I tested attachments (on server side)in Windows using VC (Not using ANT
build) & it's working.
I couldn't test with the ANT build because ANT is not building
properly.
Once ANT is working I can check in Windows & Linux.Till
5/2005 08:10
> Please respond to
> "Apache AXIS C Developers List"
>
>
>
>
>To
> Apache AXIS C
> Developers c-
> [EMAIL PROTECTED]>
>cc
>
> Subject
> Attachments
>
>
>
&g
gt; The requested URL /axis/Ref was not found on this server.
>
> Apache/2.0.53 (Unix) Server at 127.0.0.1 Port
>
>
>
>
> Regds
> Rangika
>
>
>
>
>
>
> On Thu, 2005-05-05 at 08:30 +0100, John Hawkins wrote:
> >
> > Hi Rangika,
> >
lease respond to Subject
"Apache AXIS C Re: Attachments
o] SimpleRef - Client Execution - FAILED
> >
> > testSuite:
> >
> > BUILD SUCCESSFUL
> > Total time: 7 seconds
> >
> > Then I gave the testPort = in build/build.Linux.Properties & put
> > target port as 80 & listen port in the
localhost:13260/axis/Ref
> > > [stopwatch] [SimpleRef.timer: 0.592 sec]
> > > [echo] SimpleRef - Execution Time - 0.592 sec
> > >
> > > stopMonitor:
> > >
> > > validateTestClient:
> > > [echo] SimpleRef - Client Execution -
Please commit the program used to test as well.
Thanks,
Samisa...
-Original Message-
From: Rangika Mendis [mailto:[EMAIL PROTECTED]
Sent: Friday, May 06, 2005 10:23 AM
To: Apache AXIS C Developers
Subject: Re: Attachments
Hi Samisa,
yes, the sample is in
\c\samples\server\mime
---
From: Rangika Mendis [mailto:[EMAIL PROTECTED]
Sent: Friday, May 06, 2005 10:23 AM
To: Apache AXIS C Developers
Subject: Re: Attachments
Hi Samisa,
yes, the sample is in
\c\samples\server\mime
Attachment support is only added to Apache 2 currently.
I'm trying to put it for Apache
Hi Rangika,
Unfortunately the attachments code now does not compile on AIX (only AIX)
with this strange error...
[cc] /build/nw00_PA/obj/src/server/apache/AttachmentHelper.cpp:
[cc] /usr/vacpp/exe/xlCentry -D_AIX -D_AIX32 -D_AIX41 -D_AIX43
-D_AIX50 -D_AIX51 -D_IBMR2 -D_POWER
Hi Mark,
I'm not involved in attachment support client side.I was only involved
in server side.Damitha is working on client side I'm not sure how far
he has done.I think he wouldn't mind you working on it.
Regds
Rangika
On Mon, 2005-05-16 at 13:31 +0100, Mark Whitlock wrote:
>
>
>
> Hi Damit
Re: Attachments
Deve
Hi Rangika,
We build but we don't test the Axis C++ server. We run all our tests
against WebSphere Application Server. So unfortunately I don't know whether
server-side attachments work on AIX.
Mark
Mark Whitlock
IBM
- Forwarded by Mark Whitlock/UK/IBM on 18/05/
Hi Rangika,
>From looking through the code, deserialization of a mime message seems to
be missing. The SoapDeSerializer passes the SOAPTransport through to the
XMLParser, but a MIME message is not XML.
I will go ahead and implement this function, unless this is something that
you have implemen
I have added in support into WSDL2Ws for attachments. Attachments are
described in the WSDL as types (DataHandler, Image, etc) in the
http://xml.apache.org/xml-soap namespace. Unfortunately WSDL2Ws uses
axis.jar which uses function that requires a JAF and JavaMail
implementation, when the WSDL
Apache AXIS C Developers
> 05/05/2005 13:06
> cc
>
> Please respond to
so this means attachements will not
work for apache 13?
Mark Whitlock/UK/[EMAIL PROTECTED]
05/05/2005 16:58
Please respond to
"Apache AXIS C Developers List"
To
axis-c-dev@ws.apache.org
cc
Subject
Fw: Attachments
Hi Rangika,
I've fixed the ant buil
Hi Mark,
I'm so sorry that attachments didn't work on AIX.Since we don't have AIX
installed in any machine I couldn't test attachments on it.
So after the change you did does attachments work properly on AIX?
Regds
Rangika
On Fri, 2005-05-06 at 17:15 +0100, Mark Whitlock
Hi Mark,
Yeah sure, post the changes that you intend to make in the mailing list
so that we may be able to help you whether your changes will fit in with
our design or not.
BTW are attachments (server side) running on AIX?
Rangika
On Tue, 2005-05-17 at 17:34 +0100, Mark Whitlock wrote
I propose to add in support to wsdl2ws to allow mime bindings in the wsdl
binding so that attachments are described by the wsdl. Attachments are
passed to the client as a parameter on the web service itself.
This is required by WS-I
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08
Hi,
Is there planned support for SwA for the client in Axis2/C within the
very near future? A project I am working on requires that I support SwA,
as it doesn't support MTOM (and redeploying the service is not an
option).
If this is not planned, then would it be possible for you to give me
+1 for taking mime bindings into account.
Samisa...
On 5/20/05, Mark Whitlock <[EMAIL PROTECTED]> wrote:
>
>
>
>
> I propose to add in support to wsdl2ws to allow mime bindings in the wsdl
> binding so that attachments are described by the wsdl. Attachments are
>
Jamie Lyon wrote:
Hi,
Is there planned support for SwA for the client in Axis2/C within the
very near future? A project I am working on requires that I support
SwA, as it doesn’t support MTOM (and redeploying the service is not an
option).
We do not have anyone working on it right now, hen
Hi devs,
In the current MTOM implementation we are keeping the whole attachment
in memory until passing it to the reciever. The [1] is on supporting
some sort of caching in order to handle large attachments. Axis2/Java
does this by writing the attachment to a file when it exceeds a certain
Hi All,
We added functionalities to the serializer to
serialize soap attachments. The following files were added for that
purpose.
1. SoapAttachmentHeaders
2. SoapAttachment
New API allows to add Soap Attachment objects to the
Manjula Peiris <[EMAIL PROTECTED]> writes:
> Before implementing this I would like to know your suggestions regarding
> this.
+1
thanks,
Dinesh
--
http://nethu.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional com
Hi Manjula,
Sounds great..
Just a small clarification..
> What we can do in our implementation is after extracting the binary
> content write that to a file
In Axis2/Java case we do write the attachment content directly from
the InputStream to the File when the attachment size is larger than
the
nd the attachment size with out searching for
the mime boundaries ? In Axis2/C the problem we have is we will be aware
of the size of the attachment only after extracting the attachments. We
can't determine it from the content length. Because a message with a
large soap envelope or a message with
Hi,
> > In Axis2/Java case we do write the attachment content directly from
> > the InputStream to the File when the attachment size is larger than
> > the threshold. This avoids loading the whole attachment to the memory
> > at all.
>
> In this case to find out the attachment size don't you
Hi Thilina,
What is the upper limit?
And, we also can use a buffer of say 1MB and keep reading the content into
it until we find the end, and in the mean time write to a file, if we
exceed this buffer. This way, we can do the necessary tracking in real
time. Meaning that the MIME parts will be pa
is an IO to the disk. This is where the optimal
buffer size comes into play, if we keep on flushing too small buffer, it
gets too slow.
BTW, this whole discussion is about in path, that is reading an
incomming message. How about the out path? We have the same problems
when sending attachments.
> BTW, this whole discussion is about in path, that is reading an
> incomming message. How about the out path? We have the same problems
> when sending attachments. Right now, we read the whole file into memory
> and then only we send over the wire.
hmm... Why not write it in chu
On Fri, 2008-03-14 at 16:35 -0400, Thilina Gunarathne wrote:
> Hi,
> > What we did in Axis2/Java to overcome this is to read the data to a
> byte[] buffer of up to a certain size (the size threshold). If there
> are more data available in the mime part (if we have not encountered
> the boundary y
>> BTW, this whole discussion is about in path, that is reading an
>> incomming message. How about the out path? We have the same problems
>> when sending attachments. Right now, we read the whole file into memory
>> and then only we send over the wire.
> hmm...
>>> BTW, this whole discussion is about in path, that is reading an
>>> incomming message. How about the out path? We have the same problems
>>> when sending attachments. Right now, we read the whole file into
>>> memory
>>> and then only we send
content-length or
specified it as chunked.
-Manjula.
On Sat, 2008-03-15 at 13:39 +0530, Senaka Fernando wrote:
> >>> BTW, this whole discussion is about in path, that is reading an
> >>> incomming message. How about the out path? We have the same problems
> >>&
discussion is about in path, that is reading an
>> >>> incomming message. How about the out path? We have the same
>> problems
>> >>> when sending attachments. Right now, we read the whole file into
>> >>> memory
>> >>> and then
Hi Senaka,
Looks like you are confused by my mail...
> >> BTW, this whole discussion is about in path, that is reading an
> >> incomming message. How about the out path? We have the same problems
> >> when sending attachments. Right now, we read the whole file into
3:39 +0530, Senaka Fernando wrote:
> >> >>> BTW, this whole discussion is about in path, that is reading an
> >> >>> incomming message. How about the out path? We have the same
> >> problems
> >> >>> when sending attachment
.
Here also I think it is same as what Thilina is saying.
Thanks,
-Manjula.
>
> >
> > -Manjula.
>
> Regards,
> Senaka
>
> >
> > On Sat, 2008-03-15 at 13:39 +0530, Senaka Fernando wrote:
> >> >>> BTW, this whole discussion is about i
ontent Length. This is a not at all expensive operation as the file
>> seek will be scanning the file as a block without reading it to memory.
>> The OS will manage it's efficiency.
>
> Here also I think it is same as what Thilina is saying.
>
> Thanks,
> -Manjula.
>
>&
t to the memory. Well, you can seek through the file
>>> and
>>> find out the size of the content to be written. Add to it the standard
>>> header block and MIME boundary demarcation string lengths and you will
>>> get
>>> the Content Length. This is a
Senaka Fernando wrote:
Hi Manjula, Thilina and others,
Yep, I think I'm exactly in the same view point as Thilina when it comes
to handling attachment data. Well for the chunking part. I think I didn't
get Thilina right in his first e-mail.
And, However, the file per MIME part may not always be
Hi Samisa,
IIRC, this discussion is on handling attachments and thus, does not relate
to caching. Though $subject says "Caching" what actually was discussed was
a mechanism to buffer the attachment in a file, rather than in memory, and
that buffer has nothing to do with a Caching,
y are
> two separate concerns, so ahy are we wasting time discussing parsing
> while the problem at had is not parsing but caching?
No, the current implementation starts parsing after reading the whole
stream. Because of that the parsing is simple and efficient. And for
considerable size of la
On Sun, 2008-03-16 at 17:53 +0530, Senaka Fernando wrote:
> Hi Samisa,
>
> IIRC, this discussion is on handling attachments and thus, does not relate
> to caching. Though $subject says "Caching" what actually was discussed was
> a mechanism to buffer the attachment in
Senaka Fernando wrote:
Hi Samisa,
IIRC, this discussion is on handling attachments and thus, does not relate
to caching. Though $subject says "Caching" what actually was discussed was
a mechanism to buffer the attachment in a file, rather than in memory, and
that buffer has nothing to
> Senaka Fernando wrote:
>> Hi Samisa,
>>
>> IIRC, this discussion is on handling attachments and thus, does not
>> relate
>> to caching. Though $subject says "Caching" what actually was discussed
>> was
>> a mechanism to buffer the atta
large attachments(eg : 100MB) also it is working
well. The only problem it has is the attachment size will depend on the
available system memory.
Still, my argument on the separation of concerns on caching vs. parsing
holds.
It is a question about what takes precedence over the other. If the
ion starts parsing after reading the whole
>> stream. Because of that the parsing is simple and efficient. And for
>> considerable size of large attachments(eg : 100MB) also it is working
>> well. The only problem it has is the attachment size will depend on the
>> availabl
e.
Also you might want to consider deferred parsing of attachments. That
means read the attachment for the stream only when needed. Similar in
concept to StAX parsing of XML.
>This is because
> many small attachments == one big attachment.
Good point..
thanks,
Thilina
>Thus, I'
r the Chunked case.
>
> Also you might want to consider deferred parsing of attachments. That
> means read the attachment for the stream only when needed. Similar in
> concept to StAX parsing of XML.
That will cause the stream to exhaust for the lifetime of the request
isn't i
> Ideally it should be either the Content-Length or if Chunked then we'll
> have to read until the end of chunks. So, if you see Content-Length, then
> no need to calculate size while parsing. You already know it. But, your
> proposal is valid for the Chunked case.
I'm talking about calculating
e Chunked case.
> I'm talking about calculating the size for a individual MIME part.. I
> think I made it clear (+how we do it in Axis2/java) at the beginning
> of this thread... Probably you need to reread this thread.
Yep, true. The point is, as I said earlier, several small attach
. And for
considerable size of large attachments(eg : 100MB) also it is working
well. The only problem it has is the attachment size will depend on the
available system memory.
Still, my argument on the separation of concerns on caching vs. parsing
holds.
It is a question about what takes
g to file.
Also you might want to consider deferred parsing of attachments. That
means read the attachment for the stream only when needed. Similar in
concept to StAX parsing of XML.
This is because
many small attachments == one big attachment.
Good point..
I do not think so.
I'm talking about calculating the size for a individual MIME part.. I
think I made it clear (+how we do it in Axis2/java) at the beginning
of this thread... Probably you need to reread this thread.
Yep, true. The point is, as I said earlier, several small attachments ==
one big attach
Also you might want to consider deferred parsing of attachments. That
means read the attachment for the stream only when needed.
This is what the Java does. How can you do this in C?
Samisa...
-
To unsubscribe, e-mail
>> Also you might want to consider deferred parsing of attachments. That
> >> means read the attachment for the stream only when needed.
>
> This is what the Java does.
That's why I proposed you people to consider doing it in C :)..
In Axis2/Java we first parse onl
Thilina Gunarathne wrote:
>> Also you might want to consider deferred parsing of attachments. That
>> means read the attachment for the stream only when needed.
This is what the Java does.
That's why I proposed you people to consider doing it in C :)..
In Axis2/Ja
> Well, the Java folks have the luxury of streams. C has to manage this at
> socket level. So my question was, how are we supposed to do that with C
> network handler?
I'm not familiar with the workings of the C network handler. But for us the
only useful part of the input stream was the read() me
part containing the soap-envelope
2. Then Read up to some threshold and search for the mime_boundary
3. If it is not found then move one half of the buffer to the file and
append some content equal to that part from stream and parse
The step 3 is needed because in case of multiple attachments the
t-length.. It's based on the
> > size of a particular attachment. We calculate the size while parsing.
> > If the size exceeds a certain limit then put everything to file.
> >
> > Also you might want to consider deferred parsing of attachments. That
> > means read th
Hi devs,
As I understood after going through Axis2/C transport and Axiom stuff
following things need to be done in order to do $subject.
1. Fix problems in the http transport when sending data as chunked.
Currently it is sending the data as one chunk and in the attachment case
data is missing.
2
ent
> > * method of the IWrapperSoapSerializer interface
> > *
> > */
> > virtual ISoapAttachment* createSoapAttachement()=0;
Here another interface called "ISoapAttachment" is used to avoid static
linkage of Axis engine/library code to the web service.
Hi Damitha,
What are the sections of code (trasport, soap etc.) that would be
affected by the changes you have to do to support client side
attachments?
Thanks,
Samisa...
On Tue, 25 Jan 2005 13:38:54 +0600, Damitha Kumarage
<[EMAIL PROTECTED]> wrote:
> Hi all,
> In li
side.
How much support has been implemented is uncertain.
The server side attachments are said to be complete, but we do not have a test
case for this.
Client side implementation is not documented nor we have a working sample.
Attachment support would likely be completed in 1.6
> Supporting
[ http://issues.apache.org/jira/browse/AXISCPP-239?page=all ]
John Hawkins resolved AXISCPP-239:
--
Resolution: Fixed
We have some limited support for attachments in 1.6 alpha. I suggest we close
this issue until such time as anyone wants more
[ http://issues.apache.org/jira/browse/AXISCPP-239?page=all ]
Fred Preston closed AXISCPP-239:
> Supporting ws-attachments
> -
>
> Key: AXISCPP-239
> URL: http://issues.apache.org/jira/bro
Manjula Peiris wrote:
Hi devs,
As I understood after going through Axis2/C transport and Axiom stuff
following things need to be done in order to do $subject.
1. Fix problems in the http transport when sending data as chunked.
Currently it is sending the data as one chunk and in the attachment
On Mon, 2008-06-09 at 20:26 +0530, Samisa Abeysinghe wrote:
> Manjula Peiris wrote:
> > Hi devs,
> >
> > As I understood after going through Axis2/C transport and Axiom stuff
> > following things need to be done in order to do $subject.
> >
> > 1. Fix problems in the http transport when sending da
Manjula Peiris wrote:
On Mon, 2008-06-09 at 20:26 +0530, Samisa Abeysinghe wrote:
Manjula Peiris wrote:
Hi devs,
As I understood after going through Axis2/C transport and Axiom stuff
following things need to be done in order to do $subject.
1. Fix problems in the http transport when s
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
ems 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 lar
Attachments handling mechanism is too restrictive
-
Key: AXIS2C-320
URL: http://issues.apache.org/jira/browse/AXIS2C-320
Project: Axis2-C
Issue Type: Improvement
Environment: linux
1 - 100 of 116 matches
Mail list logo
