You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by damitha kumarage <da...@opensource.lk> on 2004/07/16 06:00:28 UTC
Re: Implementation of SOAPTransport interface using LibWWW for
client
Well done Samisa,
What is this 100-continue?
damitha
On Thu, 2004-07-15 at 17:27, Samisa Abeysinghe wrote:
> Hi All,
>
> I developed a transport module for clients using the trasport
> abstraction. I tested it on Linux and all seems to be fine except
> thread safety. The module need to be tested on WIndows.
>
> The Axis C++ server side fails to work with 100-continue. Axis Java is
> capable of managing 100-continue. This is the default mode used in
> LibWWW. I used a macro in Makefile.am to enable/disable 100-continue.
> (use -DHT_EXT_CONTINUE to enable or -UHT_EXT_CONTINUE to disable in
> AM_CPPFLAGS setting) I observed that the transport is much faster when
> it is used without 100-continue. However, to disable 100-continue,
> LibWWW need to be built with -?with-extension option (./configure
> --with-extension)
>
> You do not need to bother about location of LibWWW headers and
> libraries, provided that you have done the LibWWW installation
> properly. I have used libwww-config in the Makefile.am to pick LibWWW
> specific settings.
>
> Once you build the library, you could use it by specifying the
> location of the lib in $AXIS_HOME/axiscpp.conf file.
>
> e.g.Transport_http:/usr/local/Axis/libs/libaxis_LibWWWTransport.so
>
> For more information on LibWWW please see
> http://www.w3.org/Library/User/
>
> Issues:
>
> The thread test in tests/client/threadSafe fails with this
> implementation. Bit of surfing lead me to
> http://www.w3.org/Library/User/Architecture/Events.html, which says
> "LibWWW is not posix thread safe but it uses a 'pseudo-thread' model
> based on non-blocking sockets and interleaved IO." Bit of research is
> needed to figure out how to make this implementation thread safe. It
> remains a TODO as of now.
>
> Thanks,
>
> Samisa...
>
>
> ______________________________________________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
Re: Axis Java WSDL jars and WSDL2WS tool
Posted by ni...@opensource.lk.
Hi,
I tried to sync WSDL2WS tool with Latest Axis Java Jar due to the impact
of it, I replaced the SchemaUtils.java from Axis java and added some of
the axis c++ functionalty already exisited in SchemaUtils.java,
further some changes to ElementDecl.java and WSDL2Ws.java was also required.
After these changes, WSDL2Ws tool is generating skeletons & wrappers for
server side and stubs for client side as well.
I have attached the files.
rgds,
Nithya
> The current WSDL2WS implementation is based on Axis Java 1.1 Jars.
> Is there any effort to sync the WSDL2WS tool with Latest Axis Java Jars?
>
> Samisa...
>
>
>
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>
>
>
Axis Java WSDL jars and WSDL2WS tool
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
The current WSDL2WS implementation is based on Axis Java 1.1 Jars.
Is there any effort to sync the WSDL2WS tool with Latest Axis Java Jars?
Samisa...
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
Re: Implementation of SOAPTransport interface using LibWWW for client
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
I too agree that we could forget about continue.
However, thread safety is a headache with LibWWW on client side. I would like the client transport
to be thread safe.
Samisa...
--- Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> I understand the principle, but is that a real feature in today's
> Internet? For Web browsing it *may* make sense to have the *HTTP*
> headers checked before the payload is sent (esp. if you have a
> low bandwidth connection like I do), but even that is questionable
> when payload for POSTs in HTTP is almost always very small.
>
> For SOAP stuff, IMO it makes no sense. Why? Because most of the
> time SOAP stuff will be unprocessable by the server because there's
> something wrong in the *SOAP envelope* and not because there's anything
> screwy with the HTTP headers. While whacky clients may use this HTTP
> feature, in practice I don't see it being of any value in the SOAP
> world.
>
> I guess we should still support it because it could be an interop
> problem, but if its too much of a pain I'd say let's not worry too
> hard about it.
>
> Keep-alive and chunking, OTOH, is very real and very useful to have.
>
> Sanjiva.
>
> ----- Original Message -----
> From: "Samisa Abeysinghe" <sa...@yahoo.com>
> To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
> Sent: Monday, July 19, 2004 11:51 AM
> Subject: Re: Implementation of SOAPTransport interface using LibWWW for
> client
>
>
> > Using "Expect: 100-continue" header, your application safes time and
> network (see RFC2616, section
> > 8.2.3).
> >
> > Samisa...
> >
> > --- damitha kumarage <da...@opensource.lk> wrote:
> > > Well done Samisa,
> > > What is this 100-continue?
> > >
> > > damitha
> > > On Thu, 2004-07-15 at 17:27, Samisa Abeysinghe wrote:
> > > > Hi All,
> > > >
> > > > I developed a transport module for clients using the trasport
> > > > abstraction. I tested it on Linux and all seems to be fine except
> > > > thread safety. The module need to be tested on WIndows.
> > > >
> > > > The Axis C++ server side fails to work with 100-continue. Axis Java is
> > > > capable of managing 100-continue. This is the default mode used in
> > > > LibWWW. I used a macro in Makefile.am to enable/disable 100-continue.
> > > > (use -DHT_EXT_CONTINUE to enable or -UHT_EXT_CONTINUE to disable in
> > > > AM_CPPFLAGS setting) I observed that the transport is much faster when
> > > > it is used without 100-continue. However, to disable 100-continue,
> > > > LibWWW need to be built with -?with-extension option (./configure
> > > > --with-extension)
> > > >
> > > > You do not need to bother about location of LibWWW headers and
> > > > libraries, provided that you have done the LibWWW installation
> > > > properly. I have used libwww-config in the Makefile.am to pick LibWWW
> > > > specific settings.
> > > >
> > > > Once you build the library, you could use it by specifying the
> > > > location of the lib in $AXIS_HOME/axiscpp.conf file.
> > > >
> > > > e.g.Transport_http:/usr/local/Axis/libs/libaxis_LibWWWTransport.so
> > > >
> > > > For more information on LibWWW please see
> > > > http://www.w3.org/Library/User/
> > > >
> > > > Issues:
> > > >
> > > > The thread test in tests/client/threadSafe fails with this
> > > > implementation. Bit of surfing lead me to
> > > > http://www.w3.org/Library/User/Architecture/Events.html, which says
> > > > "LibWWW is not posix thread safe but it uses a 'pseudo-thread' model
> > > > based on non-blocking sockets and interleaved IO." Bit of research is
> > > > needed to figure out how to make this implementation thread safe. It
> > > > remains a TODO as of now.
> > > >
> > > > Thanks,
> > > >
> > > > Samisa...
> > > >
> > > >
> > > > ______________________________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Mail is new and improved - Check it out!
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Vote for the stars of Yahoo!'s next ad campaign!
> > http://advision.webevents.yahoo.com/yahoo/votelifeengine/
> >
> >
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/
Re: Implementation of SOAPTransport interface using LibWWW for client
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I understand the principle, but is that a real feature in today's
Internet? For Web browsing it *may* make sense to have the *HTTP*
headers checked before the payload is sent (esp. if you have a
low bandwidth connection like I do), but even that is questionable
when payload for POSTs in HTTP is almost always very small.
For SOAP stuff, IMO it makes no sense. Why? Because most of the
time SOAP stuff will be unprocessable by the server because there's
something wrong in the *SOAP envelope* and not because there's anything
screwy with the HTTP headers. While whacky clients may use this HTTP
feature, in practice I don't see it being of any value in the SOAP
world.
I guess we should still support it because it could be an interop
problem, but if its too much of a pain I'd say let's not worry too
hard about it.
Keep-alive and chunking, OTOH, is very real and very useful to have.
Sanjiva.
----- Original Message -----
From: "Samisa Abeysinghe" <sa...@yahoo.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Monday, July 19, 2004 11:51 AM
Subject: Re: Implementation of SOAPTransport interface using LibWWW for
client
> Using "Expect: 100-continue" header, your application safes time and
network (see RFC2616, section
> 8.2.3).
>
> Samisa...
>
> --- damitha kumarage <da...@opensource.lk> wrote:
> > Well done Samisa,
> > What is this 100-continue?
> >
> > damitha
> > On Thu, 2004-07-15 at 17:27, Samisa Abeysinghe wrote:
> > > Hi All,
> > >
> > > I developed a transport module for clients using the trasport
> > > abstraction. I tested it on Linux and all seems to be fine except
> > > thread safety. The module need to be tested on WIndows.
> > >
> > > The Axis C++ server side fails to work with 100-continue. Axis Java is
> > > capable of managing 100-continue. This is the default mode used in
> > > LibWWW. I used a macro in Makefile.am to enable/disable 100-continue.
> > > (use -DHT_EXT_CONTINUE to enable or -UHT_EXT_CONTINUE to disable in
> > > AM_CPPFLAGS setting) I observed that the transport is much faster when
> > > it is used without 100-continue. However, to disable 100-continue,
> > > LibWWW need to be built with -?with-extension option (./configure
> > > --with-extension)
> > >
> > > You do not need to bother about location of LibWWW headers and
> > > libraries, provided that you have done the LibWWW installation
> > > properly. I have used libwww-config in the Makefile.am to pick LibWWW
> > > specific settings.
> > >
> > > Once you build the library, you could use it by specifying the
> > > location of the lib in $AXIS_HOME/axiscpp.conf file.
> > >
> > > e.g.Transport_http:/usr/local/Axis/libs/libaxis_LibWWWTransport.so
> > >
> > > For more information on LibWWW please see
> > > http://www.w3.org/Library/User/
> > >
> > > Issues:
> > >
> > > The thread test in tests/client/threadSafe fails with this
> > > implementation. Bit of surfing lead me to
> > > http://www.w3.org/Library/User/Architecture/Events.html, which says
> > > "LibWWW is not posix thread safe but it uses a 'pseudo-thread' model
> > > based on non-blocking sockets and interleaved IO." Bit of research is
> > > needed to figure out how to make this implementation thread safe. It
> > > remains a TODO as of now.
> > >
> > > Thanks,
> > >
> > > Samisa...
> > >
> > >
> > > ______________________________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail is new and improved - Check it out!
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Vote for the stars of Yahoo!'s next ad campaign!
> http://advision.webevents.yahoo.com/yahoo/votelifeengine/
>
>
Re: Implementation of SOAPTransport interface using LibWWW for client
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Using "Expect: 100-continue" header, your application safes time and network (see RFC2616, section
8.2.3).
Samisa...
--- damitha kumarage <da...@opensource.lk> wrote:
> Well done Samisa,
> What is this 100-continue?
>
> damitha
> On Thu, 2004-07-15 at 17:27, Samisa Abeysinghe wrote:
> > Hi All,
> >
> > I developed a transport module for clients using the trasport
> > abstraction. I tested it on Linux and all seems to be fine except
> > thread safety. The module need to be tested on WIndows.
> >
> > The Axis C++ server side fails to work with 100-continue. Axis Java is
> > capable of managing 100-continue. This is the default mode used in
> > LibWWW. I used a macro in Makefile.am to enable/disable 100-continue.
> > (use -DHT_EXT_CONTINUE to enable or -UHT_EXT_CONTINUE to disable in
> > AM_CPPFLAGS setting) I observed that the transport is much faster when
> > it is used without 100-continue. However, to disable 100-continue,
> > LibWWW need to be built with -?with-extension option (./configure
> > --with-extension)
> >
> > You do not need to bother about location of LibWWW headers and
> > libraries, provided that you have done the LibWWW installation
> > properly. I have used libwww-config in the Makefile.am to pick LibWWW
> > specific settings.
> >
> > Once you build the library, you could use it by specifying the
> > location of the lib in $AXIS_HOME/axiscpp.conf file.
> >
> > e.g.Transport_http:/usr/local/Axis/libs/libaxis_LibWWWTransport.so
> >
> > For more information on LibWWW please see
> > http://www.w3.org/Library/User/
> >
> > Issues:
> >
> > The thread test in tests/client/threadSafe fails with this
> > implementation. Bit of surfing lead me to
> > http://www.w3.org/Library/User/Architecture/Events.html, which says
> > "LibWWW is not posix thread safe but it uses a 'pseudo-thread' model
> > based on non-blocking sockets and interleaved IO." Bit of research is
> > needed to figure out how to make this implementation thread safe. It
> > remains a TODO as of now.
> >
> > Thanks,
> >
> > Samisa...
> >
> >
> > ______________________________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail is new and improved - Check it out!
>
>
__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/