You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Thomas Gentsch <tg...@e-tge.de> on 2011/02/04 11:53:14 UTC
Re: XML reader/writer buffer size problem?
Hi all,
sorry, I have to re-open this, the corrupted XML was my fault (while
editing the test data).
Basically it still does not work. In my real prog I have added some more
printouts (also in Axis code):
axiom_node_t * SOAPServer::invokeFunc(const axutil_env_t * env,
axiom_node_t * n)
{
DataObjectPtr req = sdoFromAxiom(n);
DataObjectPtr resp = doTheWork(req);
printf("TGE: SDO Resp:\n");
dumpSDO(resp);
axiom_node_t * ax = sdoToAxiom(resp);
printf("TGE: Axiom Resp:\n");
dumpAxiom(ax);
return ax;
}
Now what I see is that the incoming request gets transformed from Axiom
to SDO nicely, will be processed, and I also see the response SDO "resp"
as complete printed out (dumpSDO).
Then, in sdoToAxiom() I convert the response SDO back to an Axiom node
(as stated earlier, using the SDO AxiomHelper) and print it to stdout
(see below). Here I have added a printout into the guththila XML writer
and can see that *all* tags are properly written.
Now something funny happens:
In dumpAxiom() I originally had this:
axiom_xml_writer_t * w = axiom_xml_writer_create_for_memory(env,
NULL, AXIS2_TRUE, 0, AXIS2_XML_PARSER_TYPE_BUFFER);
axiom_output_t * om_output = axiom_output_create(env, w);
axiom_node_serialize(n, env, om_output);
axis2_char_t * buf = (axis2_char_t *) axiom_xml_writer_get_xml(w, env);
fprintf(f, "\nData: '%s'\n", buf);
which yields a truncated output string:
Data: '<listresponse ... <tns3:num300000000>24<//^M'
However, note the closing single quote which is part of the fprintf
above.
Now, (before noticing that) I have added:
fflush(f);
after the fprintf and voila, the printout was complete. Does not make
any sense to me ... :-|
However, now, still my Axis2c client prog receives a truncated response
only, even (now the next interesting piece), again the guththila XML
writer runs again in the server (serializing the Axiom into the socket,
I guess ...) after the fprintf above and I can see all XML tags written
correctly.
Is it possible that this is not a question of the XML reader/writer but
rather that the SOAP client is not fast enough reading the response
while the server already closes the connection or something like this?
I'm still digging further, but any hints are welcome! :-)
Rgds,
tge
On Sun, 2011-01-30 at 13:21 +0100, Thomas Gentsch wrote:
> Hi all,
>
> sorry, not Axis' fault ... the input.xml is wrong. Hard to spot, but
> there was an opening tag <num50000000> missing.
> However
> - still unclear why the two writer types behave that differently ??
> - the error message in the log might be a bit better (my input.xml
> consists of *one* line of a length of 460000 chars, hence line 1 :-)
> maybe a char offset might have helped)
> I'll update Jira ...
>
> Rgds,
> tge
>
> On Thu, 2011-01-27 at 18:43 +0100, Thomas Gentsch wrote:
> > Hi Damitha,
> >
> > if you refer to AXIS2C-448 - I have that in.
> >
> > Besides of that I haven't found anything :-| (searching for
> > axiom_xml_reader or axiom_xml_writer)
> > I'll dig more but into it but of course I could save that effort of
> > somebody else had an idea :-)
> >
> > Also, might be interesting to run that against 1.7 ...
> >
> > Rgds + thx,
> > tge
> >
> > On Thu, 2011-01-27 at 22:26 +0530, Damitha Kumarage wrote:
> > > Hi Thomas,
> > > I remember similar problem appeared in a previous thread. Could you
> > > please search in mail archives?
> > >
> > > Thanks,
> > > Damitha
> > > Thomas Gentsch wrote:
> > > > Just opened AXIS2C-1534 and attached the test progs + data.
> > > > Any help is appreciated!!
> > > > Rgds,
> > > > tge
> > > >
> > > > On Thu, 2011-01-27 at 13:16 +0100, Thomas Gentsch wrote:
> > > >
> > > >> Minor correction in the code below (I merged two functions) ...
> > > >>
> > > >> On Thu, 2011-01-27 at 13:03 +0100, Thomas Gentsch wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> I'm still with Axis2c 1.6 and have a problem (de)serializing an XML
> > > >>> string. Is there anything know about such a problem (haven't found
> > > >>> anything in Jira)?
> > > >>>
> > > >>> The essential piece is a string buffer containing an XML structure,
> > > >>> which is created from a Tuscany SDO. Then that string buffer gets
> > > >>> converted to an Axiom Node (using the Tuscany AxiomHelper) to be
> > > >>> returned to the calling Axis2c client. Normally this works nicely, but
> > > >>> if the XML is very long (in my example 484460 bytes), it gets truncated.
> > > >>>
> > > >>> I can see the string buffer "str" (below) as still intact. Then,
> > > >>> essentially the following happens:
> > > >>> ===========
> > > >>> AxiomHelper::toAxiomNode()
> > > >>> {
> > > >>> ...
> > > >>> axiom_xml_reader_t * reader =
> > > >>> axiom_xml_reader_create_for_memory(
> > > >>> the_env, (void*)str, strlen(str),
> > > >>> (const axis2_char_t *)"UTF-8", AXIS2_XML_PARSER_TYPE_BUFFER);
> > > >>> axiom_stax_builder_t* builder =
> > > >>> axiom_stax_builder_create(the_env, reader);
> > > >>> axiom_document_t* document =
> > > >>> axiom_stax_builder_get_document(builder, the_env);
> > > >>> axiom_node_t* root_node =
> > > >>> axiom_document_get_root_element(document, the_env);
> > > >>> axiom_document_build_all(document, the_env);
> > > >>>
> > > >> The code above is function1 and returns "document".
> > > >> Below is function2 dealing with that document.
> > > >>
> > > >>
> > > >>> axiom_node_t* root_node =
> > > >>> axiom_document_get_root_element(doc, the_env);
> > > >>> return root_node;
> > > >>> }
> > > >>>
> > > >>> Now I have the Axiom node "n" and dump it (just for testing):
> > > >>>
> > > >>> axiom_xml_writer_t * w = axiom_xml_writer_create_for_memory(env,
> > > >>> NULL, AXIS2_TRUE, 0, AXIS2_XML_PARSER_TYPE_BUFFER);
> > > >>> axiom_output_t * om_output = axiom_output_create(env, w);
> > > >>> axiom_node_serialize(n, env, om_output);
> > > >>> axis2_char_t * buf = (axis2_char_t *) axiom_xml_writer_get_xml(w, env);
> > > >>>
> > > >>> fprintf(f, "\nData: '%s'\n", buf);
> > > >>> =============
> > > >>>
> > > >>> and the output is truncated to 17253 bytes ending with some control
> > > >>> characters.
> > > >>> As said, that code has been working for months/years now w/o any
> > > >>> problems, so I believe that it is OK in general and I rather suspect the
> > > >>> Axis2c XML handling in conjunction with large buffers ...
> > > >>>
> > > >>> I'll extract the pieces into a standalone testprog for easier
> > > >>> troubleshooting - but still: Any ideas?
> > > >>>
> > > >>> Many thx!!!
> > > >>> tge
> > > >>>
> > > >>>
> > > >>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: XML reader/writer buffer size problem?
Posted by Thomas Gentsch <tg...@e-tge.de>.
OK, I give up. I tried with the libxml2 parser and with that it works.
Here are my latest findings, just in case somebody wants to look into
this further ...
===================
Digging further, now I'm back at the XML writer again. Have found this:
axis2_http_transport_sender_invoke()
{
...
buffer = (axis2_char_t *) axiom_xml_writer_get_xml(xml_writer, env);
buffer_size = axiom_xml_writer_get_xml_size(xml_writer, env);
/* TGE */
printf("TGE: http sender: %d bytes\n", buffer_size);
printf("TGE: http sender: '%s'\n", buffer);
fflush(stdout);
...
int rc = axutil_stream_write(out_stream, env, buffer, buffer_size);
printf("TGE: http sender stream_write returned %d.\n", rc);
}
and I get again the truncated XML. In other words, here happens the same
as I had before in my dump() function - the axiom node gets printed into
a buffer, but not completely.
The guththila XML writer prints everything correctly - but not, as I
initially thought, into the socket, but again into another buffer (as
above).
The size of the buffer is correct (975000), however the actual buffer is
not:
...
TGE: http sender: 975921 bytes
TGE: http sender: '<soapenv:Envelope ... <tns3:num300000000>24<//^M'
TGE: http sender stream_write returned 975921.^M
TGE: axutil_stream_write_socket 17 bytes^M
TGE: axutil_stream_write_socket wrote 17 bytes^M
TGE: axutil_stream_write_socket 36 bytes^M
TGE: axutil_stream_write_socket wrote 36 bytes^M
TGE: axutil_stream_write_socket 49 bytes^M
TGE: axutil_stream_write_socket wrote 49 bytes^M
TGE: axutil_stream_write_socket 50 bytes^M
TGE: axutil_stream_write_socket wrote 50 bytes^M
TGE: axutil_stream_write_socket 24 bytes^M
TGE: axutil_stream_write_socket wrote 24 bytes^M
TGE: axutil_stream_write_socket 2 bytes^M
TGE: axutil_stream_write_socket wrote 2 bytes^M
TGE: axutil_stream_write_socket 245761 bytes^M
TGE: axutil_stream_write_socket wrote 245761 bytes^M
TGE: axutil_stream_write_socket 2 bytes^M
TGE: axutil_stream_write_socket wrote 2 bytes^M
The 245761 is about the length of data actually sent over the wire and
the same as printed as out truncated.
Now, further ... it turned out that while constructing the buffer, the
guththila XML writer finds an empty/illegal prefix:
TGE Guth chars: '1'^M
TGE Guth elem end pfx: ''^M
TGE Guth elem end: 'num300000000'^M
and writes:
TGE: Copying buffer[4](262137): 'num300000000>1</'^M
or:
... 31 3c 2f 00 0d 00 04 3a ...
equals:
... ></ rubbish :
Now I tried to understand what's going on in the guththila parser but
give up for now.
The crazy thing is that it works ok for 25000 tags within that stupid
structure and fails 2 times (found another occurence of the same) ...
actually I just notice:
Both cases are the first closing tags in buffers 4 and 5:
TGE: Copying buffer[4](262137): 'num300000000>1</'
TGE: Copying buffer[5](468040): 'num8000000>339386</'
and the previous buffer ends like this:
...><tns3:
in both cases
===================
On Fri, 2011-02-04 at 13:21 +0100, Thomas Gentsch wrote:
> Must be something like that.
> Essentially:
>
> 1. In the SOAP server I can see all data correctly, and I can see that
> the guththila XML writer prints all XML tags correctly.
> 2. In the SOAP client (I have added prinouts to the guththila XML
> parser) I see the truncated XML - at some point it just stops.
>
> Now I have added a few more trace statements into the network handler
> and now I can see this (PID 9419 is the server, 9428 the client):
> ========
> [Fri Feb 4 13:07:44 2011] 9419 [...TRACE...] msg_recv.c(459)
> [axis2]Exit:axis2_msg_recv_receive_impl
> [Fri Feb 4 13:07:44 2011] 9419 [...TRACE...] engine.c(323)
> Exit:axis2_engine_receive
> [Fri Feb 4 13:07:44 2011] 9428 [...TRACE...] http_sender.c(1593)
> Entry:axis2_http_sender_process_response
> [Fri Feb 4 13:07:44 2011] 9428 [...TRACE...] http_sender.c(1614)
> Exit:axis2_http_sender_process_response
> [Fri Feb 4 13:07:44 2011] 9428 [debug] http_transport_sender.c(822) OP
> name axutil_qname_get_localpart = http://www.w3.org/2004/08/wsdl/out-in
> [Fri Feb 4 13:07:44 2011] 9428 [debug] soap_builder.c(945) identified
> soap version is soap12
> [Fri Feb 4 13:07:44 2011] 9419 [error] network_handler.c(208) TGE:
> Shutting down socket
> [Fri Feb 4 13:07:44 2011] 9419 [error] network_handler.c(218) TGE:
> Waiting for response ...
> [Fri Feb 4 13:07:44 2011] 9419 [error] network_handler.c(224) TGE:
> Returned. Closing socket.
> [Fri Feb 4 13:07:44 2011] [info] Request served in 22.036 seconds
> [Fri Feb 4 13:07:45 2011] 9428 [...TRACE...]
> http_transport_sender.c(596) Exit:axis2_http_transport_sender_invoke
> [Fri Feb 4 13:07:45 2011] 9428 [...TRACE...] engine.c(192)
> axis2_engine_send end successfully
> [Fri Feb 4 13:07:45 2011] 9428 [...TRACE...] engine.c(211)
> Start:axis2_engine_receive
> [Fri Feb 4 13:07:45 2011] 9428 [...TRACE...] engine.c(680)
> Start:axis2_engine_invoke_phases
> ========
>
> Means that the server closes the connection already while the client has
> not even started to receive the response data ... That in turn would
> mean that we now rely on the OS buffering data written into the socket.
>
> Hmmm, is that intended? Is that more a developers topic?
>
> Rgds,
> tge
>
> On Fri, 2011-02-04 at 11:53 +0100, Thomas Gentsch wrote:
> > Hi all,
> >
> > sorry, I have to re-open this, the corrupted XML was my fault (while
> > editing the test data).
> > Basically it still does not work. In my real prog I have added some more
> > printouts (also in Axis code):
> >
> > axiom_node_t * SOAPServer::invokeFunc(const axutil_env_t * env,
> > axiom_node_t * n)
> > {
> > DataObjectPtr req = sdoFromAxiom(n);
> >
> > DataObjectPtr resp = doTheWork(req);
> >
> > printf("TGE: SDO Resp:\n");
> > dumpSDO(resp);
> >
> > axiom_node_t * ax = sdoToAxiom(resp);
> > printf("TGE: Axiom Resp:\n");
> > dumpAxiom(ax);
> >
> > return ax;
> > }
> >
> > Now what I see is that the incoming request gets transformed from Axiom
> > to SDO nicely, will be processed, and I also see the response SDO "resp"
> > as complete printed out (dumpSDO).
> > Then, in sdoToAxiom() I convert the response SDO back to an Axiom node
> > (as stated earlier, using the SDO AxiomHelper) and print it to stdout
> > (see below). Here I have added a printout into the guththila XML writer
> > and can see that *all* tags are properly written.
> > Now something funny happens:
> > In dumpAxiom() I originally had this:
> >
> > axiom_xml_writer_t * w = axiom_xml_writer_create_for_memory(env,
> > NULL, AXIS2_TRUE, 0, AXIS2_XML_PARSER_TYPE_BUFFER);
> > axiom_output_t * om_output = axiom_output_create(env, w);
> > axiom_node_serialize(n, env, om_output);
> > axis2_char_t * buf = (axis2_char_t *) axiom_xml_writer_get_xml(w, env);
> > fprintf(f, "\nData: '%s'\n", buf);
> >
> > which yields a truncated output string:
> > Data: '<listresponse ... <tns3:num300000000>24<//^M'
> > However, note the closing single quote which is part of the fprintf
> > above.
> > Now, (before noticing that) I have added:
> > fflush(f);
> > after the fprintf and voila, the printout was complete. Does not make
> > any sense to me ... :-|
> >
> > However, now, still my Axis2c client prog receives a truncated response
> > only, even (now the next interesting piece), again the guththila XML
> > writer runs again in the server (serializing the Axiom into the socket,
> > I guess ...) after the fprintf above and I can see all XML tags written
> > correctly.
> >
> > Is it possible that this is not a question of the XML reader/writer but
> > rather that the SOAP client is not fast enough reading the response
> > while the server already closes the connection or something like this?
> > I'm still digging further, but any hints are welcome! :-)
> >
> > Rgds,
> > tge
> >
> > On Sun, 2011-01-30 at 13:21 +0100, Thomas Gentsch wrote:
> > > Hi all,
> > >
> > > sorry, not Axis' fault ... the input.xml is wrong. Hard to spot, but
> > > there was an opening tag <num50000000> missing.
> > > However
> > > - still unclear why the two writer types behave that differently ??
> > > - the error message in the log might be a bit better (my input.xml
> > > consists of *one* line of a length of 460000 chars, hence line 1 :-)
> > > maybe a char offset might have helped)
> > > I'll update Jira ...
> > >
> > > Rgds,
> > > tge
> > >
> > > On Thu, 2011-01-27 at 18:43 +0100, Thomas Gentsch wrote:
> > > > Hi Damitha,
> > > >
> > > > if you refer to AXIS2C-448 - I have that in.
> > > >
> > > > Besides of that I haven't found anything :-| (searching for
> > > > axiom_xml_reader or axiom_xml_writer)
> > > > I'll dig more but into it but of course I could save that effort of
> > > > somebody else had an idea :-)
> > > >
> > > > Also, might be interesting to run that against 1.7 ...
> > > >
> > > > Rgds + thx,
> > > > tge
> > > >
> > > > On Thu, 2011-01-27 at 22:26 +0530, Damitha Kumarage wrote:
> > > > > Hi Thomas,
> > > > > I remember similar problem appeared in a previous thread. Could you
> > > > > please search in mail archives?
> > > > >
> > > > > Thanks,
> > > > > Damitha
> > > > > Thomas Gentsch wrote:
> > > > > > Just opened AXIS2C-1534 and attached the test progs + data.
> > > > > > Any help is appreciated!!
> > > > > > Rgds,
> > > > > > tge
> > > > > >
> > > > > > On Thu, 2011-01-27 at 13:16 +0100, Thomas Gentsch wrote:
> > > > > >
> > > > > >> Minor correction in the code below (I merged two functions) ...
> > > > > >>
> > > > > >> On Thu, 2011-01-27 at 13:03 +0100, Thomas Gentsch wrote:
> > > > > >>
> > > > > >>> Hi all,
> > > > > >>>
> > > > > >>> I'm still with Axis2c 1.6 and have a problem (de)serializing an XML
> > > > > >>> string. Is there anything know about such a problem (haven't found
> > > > > >>> anything in Jira)?
> > > > > >>>
> > > > > >>> The essential piece is a string buffer containing an XML structure,
> > > > > >>> which is created from a Tuscany SDO. Then that string buffer gets
> > > > > >>> converted to an Axiom Node (using the Tuscany AxiomHelper) to be
> > > > > >>> returned to the calling Axis2c client. Normally this works nicely, but
> > > > > >>> if the XML is very long (in my example 484460 bytes), it gets truncated.
> > > > > >>>
> > > > > >>> I can see the string buffer "str" (below) as still intact. Then,
> > > > > >>> essentially the following happens:
> > > > > >>> ===========
> > > > > >>> AxiomHelper::toAxiomNode()
> > > > > >>> {
> > > > > >>> ...
> > > > > >>> axiom_xml_reader_t * reader =
> > > > > >>> axiom_xml_reader_create_for_memory(
> > > > > >>> the_env, (void*)str, strlen(str),
> > > > > >>> (const axis2_char_t *)"UTF-8", AXIS2_XML_PARSER_TYPE_BUFFER);
> > > > > >>> axiom_stax_builder_t* builder =
> > > > > >>> axiom_stax_builder_create(the_env, reader);
> > > > > >>> axiom_document_t* document =
> > > > > >>> axiom_stax_builder_get_document(builder, the_env);
> > > > > >>> axiom_node_t* root_node =
> > > > > >>> axiom_document_get_root_element(document, the_env);
> > > > > >>> axiom_document_build_all(document, the_env);
> > > > > >>>
> > > > > >> The code above is function1 and returns "document".
> > > > > >> Below is function2 dealing with that document.
> > > > > >>
> > > > > >>
> > > > > >>> axiom_node_t* root_node =
> > > > > >>> axiom_document_get_root_element(doc, the_env);
> > > > > >>> return root_node;
> > > > > >>> }
> > > > > >>>
> > > > > >>> Now I have the Axiom node "n" and dump it (just for testing):
> > > > > >>>
> > > > > >>> axiom_xml_writer_t * w = axiom_xml_writer_create_for_memory(env,
> > > > > >>> NULL, AXIS2_TRUE, 0, AXIS2_XML_PARSER_TYPE_BUFFER);
> > > > > >>> axiom_output_t * om_output = axiom_output_create(env, w);
> > > > > >>> axiom_node_serialize(n, env, om_output);
> > > > > >>> axis2_char_t * buf = (axis2_char_t *) axiom_xml_writer_get_xml(w, env);
> > > > > >>>
> > > > > >>> fprintf(f, "\nData: '%s'\n", buf);
> > > > > >>> =============
> > > > > >>>
> > > > > >>> and the output is truncated to 17253 bytes ending with some control
> > > > > >>> characters.
> > > > > >>> As said, that code has been working for months/years now w/o any
> > > > > >>> problems, so I believe that it is OK in general and I rather suspect the
> > > > > >>> Axis2c XML handling in conjunction with large buffers ...
> > > > > >>>
> > > > > >>> I'll extract the pieces into a standalone testprog for easier
> > > > > >>> troubleshooting - but still: Any ideas?
> > > > > >>>
> > > > > >>> Many thx!!!
> > > > > >>> tge
> > > > > >>>
> > > > > >>>
> > > > > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: XML reader/writer buffer size problem?
Posted by Thomas Gentsch <tg...@e-tge.de>.
Must be something like that.
Essentially:
1. In the SOAP server I can see all data correctly, and I can see that
the guththila XML writer prints all XML tags correctly.
2. In the SOAP client (I have added prinouts to the guththila XML
parser) I see the truncated XML - at some point it just stops.
Now I have added a few more trace statements into the network handler
and now I can see this (PID 9419 is the server, 9428 the client):
========
[Fri Feb 4 13:07:44 2011] 9419 [...TRACE...] msg_recv.c(459)
[axis2]Exit:axis2_msg_recv_receive_impl
[Fri Feb 4 13:07:44 2011] 9419 [...TRACE...] engine.c(323)
Exit:axis2_engine_receive
[Fri Feb 4 13:07:44 2011] 9428 [...TRACE...] http_sender.c(1593)
Entry:axis2_http_sender_process_response
[Fri Feb 4 13:07:44 2011] 9428 [...TRACE...] http_sender.c(1614)
Exit:axis2_http_sender_process_response
[Fri Feb 4 13:07:44 2011] 9428 [debug] http_transport_sender.c(822) OP
name axutil_qname_get_localpart = http://www.w3.org/2004/08/wsdl/out-in
[Fri Feb 4 13:07:44 2011] 9428 [debug] soap_builder.c(945) identified
soap version is soap12
[Fri Feb 4 13:07:44 2011] 9419 [error] network_handler.c(208) TGE:
Shutting down socket
[Fri Feb 4 13:07:44 2011] 9419 [error] network_handler.c(218) TGE:
Waiting for response ...
[Fri Feb 4 13:07:44 2011] 9419 [error] network_handler.c(224) TGE:
Returned. Closing socket.
[Fri Feb 4 13:07:44 2011] [info] Request served in 22.036 seconds
[Fri Feb 4 13:07:45 2011] 9428 [...TRACE...]
http_transport_sender.c(596) Exit:axis2_http_transport_sender_invoke
[Fri Feb 4 13:07:45 2011] 9428 [...TRACE...] engine.c(192)
axis2_engine_send end successfully
[Fri Feb 4 13:07:45 2011] 9428 [...TRACE...] engine.c(211)
Start:axis2_engine_receive
[Fri Feb 4 13:07:45 2011] 9428 [...TRACE...] engine.c(680)
Start:axis2_engine_invoke_phases
========
Means that the server closes the connection already while the client has
not even started to receive the response data ... That in turn would
mean that we now rely on the OS buffering data written into the socket.
Hmmm, is that intended? Is that more a developers topic?
Rgds,
tge
On Fri, 2011-02-04 at 11:53 +0100, Thomas Gentsch wrote:
> Hi all,
>
> sorry, I have to re-open this, the corrupted XML was my fault (while
> editing the test data).
> Basically it still does not work. In my real prog I have added some more
> printouts (also in Axis code):
>
> axiom_node_t * SOAPServer::invokeFunc(const axutil_env_t * env,
> axiom_node_t * n)
> {
> DataObjectPtr req = sdoFromAxiom(n);
>
> DataObjectPtr resp = doTheWork(req);
>
> printf("TGE: SDO Resp:\n");
> dumpSDO(resp);
>
> axiom_node_t * ax = sdoToAxiom(resp);
> printf("TGE: Axiom Resp:\n");
> dumpAxiom(ax);
>
> return ax;
> }
>
> Now what I see is that the incoming request gets transformed from Axiom
> to SDO nicely, will be processed, and I also see the response SDO "resp"
> as complete printed out (dumpSDO).
> Then, in sdoToAxiom() I convert the response SDO back to an Axiom node
> (as stated earlier, using the SDO AxiomHelper) and print it to stdout
> (see below). Here I have added a printout into the guththila XML writer
> and can see that *all* tags are properly written.
> Now something funny happens:
> In dumpAxiom() I originally had this:
>
> axiom_xml_writer_t * w = axiom_xml_writer_create_for_memory(env,
> NULL, AXIS2_TRUE, 0, AXIS2_XML_PARSER_TYPE_BUFFER);
> axiom_output_t * om_output = axiom_output_create(env, w);
> axiom_node_serialize(n, env, om_output);
> axis2_char_t * buf = (axis2_char_t *) axiom_xml_writer_get_xml(w, env);
> fprintf(f, "\nData: '%s'\n", buf);
>
> which yields a truncated output string:
> Data: '<listresponse ... <tns3:num300000000>24<//^M'
> However, note the closing single quote which is part of the fprintf
> above.
> Now, (before noticing that) I have added:
> fflush(f);
> after the fprintf and voila, the printout was complete. Does not make
> any sense to me ... :-|
>
> However, now, still my Axis2c client prog receives a truncated response
> only, even (now the next interesting piece), again the guththila XML
> writer runs again in the server (serializing the Axiom into the socket,
> I guess ...) after the fprintf above and I can see all XML tags written
> correctly.
>
> Is it possible that this is not a question of the XML reader/writer but
> rather that the SOAP client is not fast enough reading the response
> while the server already closes the connection or something like this?
> I'm still digging further, but any hints are welcome! :-)
>
> Rgds,
> tge
>
> On Sun, 2011-01-30 at 13:21 +0100, Thomas Gentsch wrote:
> > Hi all,
> >
> > sorry, not Axis' fault ... the input.xml is wrong. Hard to spot, but
> > there was an opening tag <num50000000> missing.
> > However
> > - still unclear why the two writer types behave that differently ??
> > - the error message in the log might be a bit better (my input.xml
> > consists of *one* line of a length of 460000 chars, hence line 1 :-)
> > maybe a char offset might have helped)
> > I'll update Jira ...
> >
> > Rgds,
> > tge
> >
> > On Thu, 2011-01-27 at 18:43 +0100, Thomas Gentsch wrote:
> > > Hi Damitha,
> > >
> > > if you refer to AXIS2C-448 - I have that in.
> > >
> > > Besides of that I haven't found anything :-| (searching for
> > > axiom_xml_reader or axiom_xml_writer)
> > > I'll dig more but into it but of course I could save that effort of
> > > somebody else had an idea :-)
> > >
> > > Also, might be interesting to run that against 1.7 ...
> > >
> > > Rgds + thx,
> > > tge
> > >
> > > On Thu, 2011-01-27 at 22:26 +0530, Damitha Kumarage wrote:
> > > > Hi Thomas,
> > > > I remember similar problem appeared in a previous thread. Could you
> > > > please search in mail archives?
> > > >
> > > > Thanks,
> > > > Damitha
> > > > Thomas Gentsch wrote:
> > > > > Just opened AXIS2C-1534 and attached the test progs + data.
> > > > > Any help is appreciated!!
> > > > > Rgds,
> > > > > tge
> > > > >
> > > > > On Thu, 2011-01-27 at 13:16 +0100, Thomas Gentsch wrote:
> > > > >
> > > > >> Minor correction in the code below (I merged two functions) ...
> > > > >>
> > > > >> On Thu, 2011-01-27 at 13:03 +0100, Thomas Gentsch wrote:
> > > > >>
> > > > >>> Hi all,
> > > > >>>
> > > > >>> I'm still with Axis2c 1.6 and have a problem (de)serializing an XML
> > > > >>> string. Is there anything know about such a problem (haven't found
> > > > >>> anything in Jira)?
> > > > >>>
> > > > >>> The essential piece is a string buffer containing an XML structure,
> > > > >>> which is created from a Tuscany SDO. Then that string buffer gets
> > > > >>> converted to an Axiom Node (using the Tuscany AxiomHelper) to be
> > > > >>> returned to the calling Axis2c client. Normally this works nicely, but
> > > > >>> if the XML is very long (in my example 484460 bytes), it gets truncated.
> > > > >>>
> > > > >>> I can see the string buffer "str" (below) as still intact. Then,
> > > > >>> essentially the following happens:
> > > > >>> ===========
> > > > >>> AxiomHelper::toAxiomNode()
> > > > >>> {
> > > > >>> ...
> > > > >>> axiom_xml_reader_t * reader =
> > > > >>> axiom_xml_reader_create_for_memory(
> > > > >>> the_env, (void*)str, strlen(str),
> > > > >>> (const axis2_char_t *)"UTF-8", AXIS2_XML_PARSER_TYPE_BUFFER);
> > > > >>> axiom_stax_builder_t* builder =
> > > > >>> axiom_stax_builder_create(the_env, reader);
> > > > >>> axiom_document_t* document =
> > > > >>> axiom_stax_builder_get_document(builder, the_env);
> > > > >>> axiom_node_t* root_node =
> > > > >>> axiom_document_get_root_element(document, the_env);
> > > > >>> axiom_document_build_all(document, the_env);
> > > > >>>
> > > > >> The code above is function1 and returns "document".
> > > > >> Below is function2 dealing with that document.
> > > > >>
> > > > >>
> > > > >>> axiom_node_t* root_node =
> > > > >>> axiom_document_get_root_element(doc, the_env);
> > > > >>> return root_node;
> > > > >>> }
> > > > >>>
> > > > >>> Now I have the Axiom node "n" and dump it (just for testing):
> > > > >>>
> > > > >>> axiom_xml_writer_t * w = axiom_xml_writer_create_for_memory(env,
> > > > >>> NULL, AXIS2_TRUE, 0, AXIS2_XML_PARSER_TYPE_BUFFER);
> > > > >>> axiom_output_t * om_output = axiom_output_create(env, w);
> > > > >>> axiom_node_serialize(n, env, om_output);
> > > > >>> axis2_char_t * buf = (axis2_char_t *) axiom_xml_writer_get_xml(w, env);
> > > > >>>
> > > > >>> fprintf(f, "\nData: '%s'\n", buf);
> > > > >>> =============
> > > > >>>
> > > > >>> and the output is truncated to 17253 bytes ending with some control
> > > > >>> characters.
> > > > >>> As said, that code has been working for months/years now w/o any
> > > > >>> problems, so I believe that it is OK in general and I rather suspect the
> > > > >>> Axis2c XML handling in conjunction with large buffers ...
> > > > >>>
> > > > >>> I'll extract the pieces into a standalone testprog for easier
> > > > >>> troubleshooting - but still: Any ideas?
> > > > >>>
> > > > >>> Many thx!!!
> > > > >>> tge
> > > > >>>
> > > > >>>
> > > > >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: re[2]: Axis2C build on HP 11.11 (32 bit)
Posted by ramesh Gopal <fa...@yahoo.com>.
Thanks everybody for the advice.
I finally got the Axis2C build to work.
Its a lot tedious on HP 32.
I had to write my own script to get it working.
Ramesh.
--- On Thu, 3/3/11, Dominic Smith <d....@querix.co.uk> wrote:
> From: Dominic Smith <d....@querix.co.uk>
> Subject: re[2]: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Thursday, 3 March, 2011, 4:19 PM
> Hi Ramesh,
>
> This behaviour is caused by the way in which the linker is
> being invoked, and
> is something that GNU libtool has never really dealt with
> correctly on this
> platform. I've never attempted to build axis2/c for this
> configuration, however
> I can give you pointers as to the conditions that need to
> be satisfied.
>
> When linking with shared objects on this platform, the +s
> flag must be used,
> and the -l/-l: flags must used for any libraries.
>
> So, for example:
>
> ld -o myprogram /foo/libbar.sl
>
> will cause /foo/libbar.sl to be the search location of the
> shared library, and
> the dynamic linker will ignore the SHLIB_PATH variable.
>
> ld -o myprogram +s -L/foo -lbar
>
> will create the entries you require.
>
> Also, take care if the +b flag is being used as the +b flag
> will override the
> +s flag for any link items that follow (in general, avoid
> the +b flag if at all
> possible).
>
>
> > Hello,
>
> > Pls help me with this issue.
>
> > There should be a way to suppress the hardcoding of
> the paths while creating
> > the shared object. Is there something parameter in the
> configure script
> > which might be causing this behaviour.
>
> > Ramesh.
>
> > --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> wrote:
>
> > > From: ramesh Gopal <fa...@yahoo.com>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Tuesday, 22 February, 2011, 3:46 PM
> > >
> > > Hello Thomas,
> > >
> > > The chatr command displays :
> > >
> > > chatr libaxis2_engine.so
> > > libaxis2_engine.so:
> > > Â Â Â Â Â Â shared
> library
> > > Â Â Â Â Â Â shared
> library
> > > dynamic path search:
> > > Â Â Â Â Â
> > > Â Â Â SHLIB_PATHÂ
> > >    enabled second
> > > Â Â Â Â Â
> > > Â Â Â embedded pathÂ
> > > enabled   firstÂ
> > > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > > Â Â Â Â Â Â internal
> name:
> > > Â Â Â Â Â
> > > Â Â Â libaxis2_engine.so.5
> > > Â Â Â Â Â Â shared
> library
> > > list:
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> > > Â Â Â Â Â
> > >    dynamic   /usr/lib/libpthread.1
> > > Â Â Â Â Â
> > >    dynamic   /usr/lib/libc.2
> > >
> > > Ramesh.
> > >
> > >
> > > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > > wrote:
> > >
> > > > From: Thomas Gentsch <tg...@e-tge.de>
> > > > Subject: Re: Axis2C build on HP 11.11 (32
> bit)
> > > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > > Date: Friday, 18 February, 2011, 1:45 AM
> > > >
> > > > Hi Ramesh!
> > > >
> > > > On Thu, 2011-02-17 at 16:14 +0530, ramesh
> Gopal
> > > wrote:
> > > > > Hello,
> > > > >
> > > > > I am trying to do an AXIS2C build on HP
> 11.11
> > > (32
> > > > bit).
> > > > >
> > > > > I have modified some CFLAGS and
> LDFLAGS, and
> > > > accordingly changed a few source files to
> include
> > > platform
> > > > specific header files. The compilation goes
> fine and
> > > also
> > > > the axis distribution is done.
> > > > >
> > > > > But when I see ldd libaxis2_engine.so,
> I see
> > > something
> > > > like :
> > > > >
> > > > >
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.
> > so
> > > > =>Â
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.
> > so
> > > >
> > > > What is the problem exactly?
> > > > The fact, that ldd prints the output above
> is not
> > > > necessarily bad - ldd
> > > > just resolves the libs as the loader does
> and if it
> > > finds
> > > > that lib with
> > > > the path /work/... - fine.
> > > >
> > > > > So, if you see here the portion before
> "=>"
> > > has a
> > > > hard-coded path.
> > > > >
> > > > > So, when I take the axis tar file and
> try to
> > > extract
> > > > on a different machine, because this path
> > > "/work/AXIS_HP"
> > > > won't exist on other machines, the
> extraction fails.
> > > >
> > > > If you do the ldd on another machine, ldd
> should say
> > > > something like:
> > > >Â libaxis2_engine.so => not found
> > > > right?
> > > >
> > > > Please provide the command output when
> linking the
> > > > libaxis2_engine.so.
> > > > Also, on HP-UX there is a command "chatr"
> which tells
> > > you
> > > > the libs of
> > > > dependent libs, locating strategies and
> built-in
> > > library
> > > > paths.
> > > > What does that command say?
> > > >
> > > > BTW: This is PA-RISC? What does "uname -a"
> say?
> > > >
> > > > Rgds,
> > > > Â tge
> > > >
> > > > > On other platforms, HPIA/ AIX/ Linux
> etc, the
> > > file is
> > > > displayed as :
> > > > >
> > > > > libaxis2_engine.so =>Â
> > > >
> > >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > >
> > > > >
> > > > > Can somebody tell me which is the flag
> which that
> > > do
> > > > the trick for me ?
> > > > >
> > > > > Rgds,
> > > > > Ramesh.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
>
>
>
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
>
>
> ----------------------- Original Message
> -----------------------
>
> From: ramesh Gopal <fa...@yahoo.com>
> To: Apache AXIS C User List <c-...@axis.apache.org>
> Cc:
> Date: Tue, 1 Mar 2011 14:14:25 +0530 (IST)
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
>
>
> Hello,
>
> Pls help me with this issue.
>
> There should be a way to suppress the hardcoding of the
> paths while creating
> the shared object. Is there something parameter in the
> configure script which
> might be causing this behaviour.
>
> Ramesh.
>
> --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> wrote:
>
> > From: ramesh Gopal <fa...@yahoo.com>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Tuesday, 22 February, 2011, 3:46 PM
> >
> > Hello Thomas,
> >
> > The chatr command displays :
> >
> > chatr libaxis2_engine.so
> > libaxis2_engine.so:
> > shared library
> > shared library
> > dynamic path search:
> >
> > SHLIB_PATH
> > enabled second
> >
> > embedded path
> > enabled first
> > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > internal name:
> >
> > libaxis2_engine.so.5
> > shared library
> > list:
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> >
> >
> dynamic /usr/lib/libpthread.1
> >
> > dynamic /usr/lib/libc.2
> >
> > Ramesh.
> >
> >
> > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > wrote:
> >
> > > From: Thomas Gentsch <tg...@e-tge.de>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Friday, 18 February, 2011, 1:45 AM
> > >
> > > Hi Ramesh!
> > >
> > > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> > wrote:
> > > > Hello,
> > > >
> > > > I am trying to do an AXIS2C build on HP
> 11.11
> > (32
> > > bit).
> > > >
> > > > I have modified some CFLAGS and LDFLAGS,
> and
> > > accordingly changed a few source files to
> include
> > platform
> > > specific header files. The compilation goes fine
> and
> > also
> > > the axis distribution is done.
> > > >
> > > > But when I see ldd libaxis2_engine.so, I
> see
> > something
> > > like :
> > > >
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > =>
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > >
> > > What is the problem exactly?
> > > The fact, that ldd prints the output above is
> not
> > > necessarily bad - ldd
> > > just resolves the libs as the loader does and if
> it
> > finds
> > > that lib with
> > > the path /work/... - fine.
> > >
> > > > So, if you see here the portion before
> "=>"
> > has a
> > > hard-coded path.
> > > >
> > > > So, when I take the axis tar file and try
> to
> > extract
> > > on a different machine, because this path
> > "/work/AXIS_HP"
> > > won't exist on other machines, the extraction
> fails.
> > >
> > > If you do the ldd on another machine, ldd should
> say
> > > something like:
> > > libaxis2_engine.so => not found
> > > right?
> > >
> > > Please provide the command output when linking
> the
> > > libaxis2_engine.so.
> > > Also, on HP-UX there is a command "chatr" which
> tells
> > you
> > > the libs of
> > > dependent libs, locating strategies and built-in
> > library
> > > paths.
> > > What does that command say?
> > >
> > > BTW: This is PA-RISC? What does "uname -a" say?
> > >
> > > Rgds,
> > > tge
> > >
> > > > On other platforms, HPIA/ AIX/ Linux etc,
> the
> > file is
> > > displayed as :
> > > >
> > > > libaxis2_engine.so =>
> > >
> >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > >
> > > >
> > > > Can somebody tell me which is the flag which
> that
> > do
> > > the trick for me ?
> > > >
> > > > Rgds,
> > > > Ramesh.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: re[2]: Axis2C build on HP 11.11 (32 bit)
Posted by ramesh Gopal <fa...@yahoo.com>.
Hello Smith,
Yes ... I manually tried doing this, and with that it shows the embedded path as dynamic as against static.
But if we were to achieve this from the command (configure, libtool),
somehow we will need to modify them to use a format like
-Wl,-L/foo -Wl,-l:libbar.so
And there could be many deplibs too.
How can we achieve this change from within the script.
Thnx,
Ramesh.
--- On Thu, 3/3/11, Dominic Smith <d....@querix.co.uk> wrote:
> From: Dominic Smith <d....@querix.co.uk>
> Subject: re[2]: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Thursday, 3 March, 2011, 4:19 PM
> Hi Ramesh,
>
> This behaviour is caused by the way in which the linker is
> being invoked, and
> is something that GNU libtool has never really dealt with
> correctly on this
> platform. I've never attempted to build axis2/c for this
> configuration, however
> I can give you pointers as to the conditions that need to
> be satisfied.
>
> When linking with shared objects on this platform, the +s
> flag must be used,
> and the -l/-l: flags must used for any libraries.
>
> So, for example:
>
> ld -o myprogram /foo/libbar.sl
>
> will cause /foo/libbar.sl to be the search location of the
> shared library, and
> the dynamic linker will ignore the SHLIB_PATH variable.
>
> ld -o myprogram +s -L/foo -lbar
>
> will create the entries you require.
>
> Also, take care if the +b flag is being used as the +b flag
> will override the
> +s flag for any link items that follow (in general, avoid
> the +b flag if at all
> possible).
>
>
> > Hello,
>
> > Pls help me with this issue.
>
> > There should be a way to suppress the hardcoding of
> the paths while creating
> > the shared object. Is there something parameter in the
> configure script
> > which might be causing this behaviour.
>
> > Ramesh.
>
> > --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> wrote:
>
> > > From: ramesh Gopal <fa...@yahoo.com>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Tuesday, 22 February, 2011, 3:46 PM
> > >
> > > Hello Thomas,
> > >
> > > The chatr command displays :
> > >
> > > chatr libaxis2_engine.so
> > > libaxis2_engine.so:
> > > Â Â Â Â Â Â shared
> library
> > > Â Â Â Â Â Â shared
> library
> > > dynamic path search:
> > > Â Â Â Â Â
> > > Â Â Â SHLIB_PATHÂ
> > >    enabled second
> > > Â Â Â Â Â
> > > Â Â Â embedded pathÂ
> > > enabled   firstÂ
> > > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > > Â Â Â Â Â Â internal
> name:
> > > Â Â Â Â Â
> > > Â Â Â libaxis2_engine.so.5
> > > Â Â Â Â Â Â shared
> library
> > > list:
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> > > Â Â Â Â Â
> > >    static Â
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> > > Â Â Â Â Â
> > >    dynamic   /usr/lib/libpthread.1
> > > Â Â Â Â Â
> > >    dynamic   /usr/lib/libc.2
> > >
> > > Ramesh.
> > >
> > >
> > > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > > wrote:
> > >
> > > > From: Thomas Gentsch <tg...@e-tge.de>
> > > > Subject: Re: Axis2C build on HP 11.11 (32
> bit)
> > > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > > Date: Friday, 18 February, 2011, 1:45 AM
> > > >
> > > > Hi Ramesh!
> > > >
> > > > On Thu, 2011-02-17 at 16:14 +0530, ramesh
> Gopal
> > > wrote:
> > > > > Hello,
> > > > >
> > > > > I am trying to do an AXIS2C build on HP
> 11.11
> > > (32
> > > > bit).
> > > > >
> > > > > I have modified some CFLAGS and
> LDFLAGS, and
> > > > accordingly changed a few source files to
> include
> > > platform
> > > > specific header files. The compilation goes
> fine and
> > > also
> > > > the axis distribution is done.
> > > > >
> > > > > But when I see ldd libaxis2_engine.so,
> I see
> > > something
> > > > like :
> > > > >
> > > > >
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.
> > so
> > > > =>Â
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.
> > so
> > > >
> > > > What is the problem exactly?
> > > > The fact, that ldd prints the output above
> is not
> > > > necessarily bad - ldd
> > > > just resolves the libs as the loader does
> and if it
> > > finds
> > > > that lib with
> > > > the path /work/... - fine.
> > > >
> > > > > So, if you see here the portion before
> "=>"
> > > has a
> > > > hard-coded path.
> > > > >
> > > > > So, when I take the axis tar file and
> try to
> > > extract
> > > > on a different machine, because this path
> > > "/work/AXIS_HP"
> > > > won't exist on other machines, the
> extraction fails.
> > > >
> > > > If you do the ldd on another machine, ldd
> should say
> > > > something like:
> > > >Â libaxis2_engine.so => not found
> > > > right?
> > > >
> > > > Please provide the command output when
> linking the
> > > > libaxis2_engine.so.
> > > > Also, on HP-UX there is a command "chatr"
> which tells
> > > you
> > > > the libs of
> > > > dependent libs, locating strategies and
> built-in
> > > library
> > > > paths.
> > > > What does that command say?
> > > >
> > > > BTW: This is PA-RISC? What does "uname -a"
> say?
> > > >
> > > > Rgds,
> > > > Â tge
> > > >
> > > > > On other platforms, HPIA/ AIX/ Linux
> etc, the
> > > file is
> > > > displayed as :
> > > > >
> > > > > libaxis2_engine.so =>Â
> > > >
> > >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > >
> > > > >
> > > > > Can somebody tell me which is the flag
> which that
> > > do
> > > > the trick for me ?
> > > > >
> > > > > Rgds,
> > > > > Ramesh.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
>
>
>
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
>
>
> ----------------------- Original Message
> -----------------------
>
> From: ramesh Gopal <fa...@yahoo.com>
> To: Apache AXIS C User List <c-...@axis.apache.org>
> Cc:
> Date: Tue, 1 Mar 2011 14:14:25 +0530 (IST)
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
>
>
> Hello,
>
> Pls help me with this issue.
>
> There should be a way to suppress the hardcoding of the
> paths while creating
> the shared object. Is there something parameter in the
> configure script which
> might be causing this behaviour.
>
> Ramesh.
>
> --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> wrote:
>
> > From: ramesh Gopal <fa...@yahoo.com>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Tuesday, 22 February, 2011, 3:46 PM
> >
> > Hello Thomas,
> >
> > The chatr command displays :
> >
> > chatr libaxis2_engine.so
> > libaxis2_engine.so:
> > shared library
> > shared library
> > dynamic path search:
> >
> > SHLIB_PATH
> > enabled second
> >
> > embedded path
> > enabled first
> > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > internal name:
> >
> > libaxis2_engine.so.5
> > shared library
> > list:
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> >
> >
> dynamic /usr/lib/libpthread.1
> >
> > dynamic /usr/lib/libc.2
> >
> > Ramesh.
> >
> >
> > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > wrote:
> >
> > > From: Thomas Gentsch <tg...@e-tge.de>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Friday, 18 February, 2011, 1:45 AM
> > >
> > > Hi Ramesh!
> > >
> > > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> > wrote:
> > > > Hello,
> > > >
> > > > I am trying to do an AXIS2C build on HP
> 11.11
> > (32
> > > bit).
> > > >
> > > > I have modified some CFLAGS and LDFLAGS,
> and
> > > accordingly changed a few source files to
> include
> > platform
> > > specific header files. The compilation goes fine
> and
> > also
> > > the axis distribution is done.
> > > >
> > > > But when I see ldd libaxis2_engine.so, I
> see
> > something
> > > like :
> > > >
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > =>
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > >
> > > What is the problem exactly?
> > > The fact, that ldd prints the output above is
> not
> > > necessarily bad - ldd
> > > just resolves the libs as the loader does and if
> it
> > finds
> > > that lib with
> > > the path /work/... - fine.
> > >
> > > > So, if you see here the portion before
> "=>"
> > has a
> > > hard-coded path.
> > > >
> > > > So, when I take the axis tar file and try
> to
> > extract
> > > on a different machine, because this path
> > "/work/AXIS_HP"
> > > won't exist on other machines, the extraction
> fails.
> > >
> > > If you do the ldd on another machine, ldd should
> say
> > > something like:
> > > libaxis2_engine.so => not found
> > > right?
> > >
> > > Please provide the command output when linking
> the
> > > libaxis2_engine.so.
> > > Also, on HP-UX there is a command "chatr" which
> tells
> > you
> > > the libs of
> > > dependent libs, locating strategies and built-in
> > library
> > > paths.
> > > What does that command say?
> > >
> > > BTW: This is PA-RISC? What does "uname -a" say?
> > >
> > > Rgds,
> > > tge
> > >
> > > > On other platforms, HPIA/ AIX/ Linux etc,
> the
> > file is
> > > displayed as :
> > > >
> > > > libaxis2_engine.so =>
> > >
> >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > >
> > > >
> > > > Can somebody tell me which is the flag which
> that
> > do
> > > the trick for me ?
> > > >
> > > > Rgds,
> > > > Ramesh.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
re[2]: Axis2C build on HP 11.11 (32 bit)
Posted by Dominic Smith <d....@querix.co.uk>.
Hi Ramesh,
This behaviour is caused by the way in which the linker is being invoked, and
is something that GNU libtool has never really dealt with correctly on this
platform. I've never attempted to build axis2/c for this configuration, however
I can give you pointers as to the conditions that need to be satisfied.
When linking with shared objects on this platform, the +s flag must be used,
and the -l/-l: flags must used for any libraries.
So, for example:
ld -o myprogram /foo/libbar.sl
will cause /foo/libbar.sl to be the search location of the shared library, and
the dynamic linker will ignore the SHLIB_PATH variable.
ld -o myprogram +s -L/foo -lbar
will create the entries you require.
Also, take care if the +b flag is being used as the +b flag will override the
+s flag for any link items that follow (in general, avoid the +b flag if at all
possible).
> Hello,
> Pls help me with this issue.
> There should be a way to suppress the hardcoding of the paths while creating
> the shared object. Is there something parameter in the configure script
> which might be causing this behaviour.
> Ramesh.
> --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com> wrote:
> > From: ramesh Gopal <fa...@yahoo.com>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Tuesday, 22 February, 2011, 3:46 PM
> >
> > Hello Thomas,
> >
> > The chatr command displays :
> >
> > chatr libaxis2_engine.so
> > libaxis2_engine.so:
> > � � � � � � shared library
> > � � � � � � shared library
> > dynamic path search:
> > � � � � �
> > � � � SHLIB_PATH�
> > � � � enabled� second
> > � � � � �
> > � � � embedded path�
> > enabled� � � first�
> > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > � � � � � � internal name:
> > � � � � �
> > � � � libaxis2_engine.so.5
> > � � � � � � shared library
> > list:
> > � � � � �
> > � � � static� �
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> > � � � � �
> > � � � static� �
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> > � � � � �
> > � � � static� �
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> > � � � � �
> > � � � static� �
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> > � � � � �
> > � � � static� �
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> > � � � � �
> > � � � static� �
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> > � � � � �
> > � � � dynamic� � � /usr/lib/libpthread.1
> > � � � � �
> > � � � dynamic� � � /usr/lib/libc.2
> >
> > Ramesh.
> >
> >
> > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > wrote:
> >
> > > From: Thomas Gentsch <tg...@e-tge.de>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Friday, 18 February, 2011, 1:45 AM
> > >
> > > Hi Ramesh!
> > >
> > > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> > wrote:
> > > > Hello,
> > > >
> > > > I am trying to do an AXIS2C build on HP 11.11
> > (32
> > > bit).
> > > >
> > > > I have modified some CFLAGS and LDFLAGS, and
> > > accordingly changed a few source files to include
> > platform
> > > specific header files. The compilation goes fine and
> > also
> > > the axis distribution is done.
> > > >
> > > > But when I see ldd libaxis2_engine.so, I see
> > something
> > > like :
> > > >
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.
> so
> > > =>�
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.
> so
> > >
> > > What is the problem exactly?
> > > The fact, that ldd prints the output above is not
> > > necessarily bad - ldd
> > > just resolves the libs as the loader does and if it
> > finds
> > > that lib with
> > > the path /work/... - fine.
> > >
> > > > So, if you see here the portion before "=>"
> > has a
> > > hard-coded path.
> > > >
> > > > So, when I take the axis tar file and try to
> > extract
> > > on a different machine, because this path
> > "/work/AXIS_HP"
> > > won't exist on other machines, the extraction fails.
> > >
> > > If you do the ldd on another machine, ldd should say
> > > something like:
> > >� libaxis2_engine.so => not found
> > > right?
> > >
> > > Please provide the command output when linking the
> > > libaxis2_engine.so.
> > > Also, on HP-UX there is a command "chatr" which tells
> > you
> > > the libs of
> > > dependent libs, locating strategies and built-in
> > library
> > > paths.
> > > What does that command say?
> > >
> > > BTW: This is PA-RISC? What does "uname -a" say?
> > >
> > > Rgds,
> > > � tge
> > >
> > > > On other platforms, HPIA/ AIX/ Linux etc, the
> > file is
> > > displayed as :
> > > >
> > > > libaxis2_engine.so =>�
> > >
> > /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > >
> > > >
> > > > Can somebody tell me which is the flag which that
> > do
> > > the trick for me ?
> > > >
> > > > Rgds,
> > > > Ramesh.
> > > >
> > > >
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
----------------------- Original Message -----------------------
From: ramesh Gopal <fa...@yahoo.com>
To: Apache AXIS C User List <c-...@axis.apache.org>
Cc:
Date: Tue, 1 Mar 2011 14:14:25 +0530 (IST)
Subject: Re: Axis2C build on HP 11.11 (32 bit)
Hello,
Pls help me with this issue.
There should be a way to suppress the hardcoding of the paths while creating
the shared object. Is there something parameter in the configure script which
might be causing this behaviour.
Ramesh.
--- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com> wrote:
> From: ramesh Gopal <fa...@yahoo.com>
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Tuesday, 22 February, 2011, 3:46 PM
>
> Hello Thomas,
>
> The chatr command displays :
>
> chatr libaxis2_engine.so
> libaxis2_engine.so:
> shared library
> shared library
> dynamic path search:
>
> SHLIB_PATH
> enabled second
>
> embedded path
> enabled first
> /work/AXIS_HP/axis2c-src-1.5.0/lib
> internal name:
>
> libaxis2_engine.so.5
> shared library
> list:
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
>
> dynamic /usr/lib/libpthread.1
>
> dynamic /usr/lib/libc.2
>
> Ramesh.
>
>
> --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> wrote:
>
> > From: Thomas Gentsch <tg...@e-tge.de>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Friday, 18 February, 2011, 1:45 AM
> >
> > Hi Ramesh!
> >
> > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> wrote:
> > > Hello,
> > >
> > > I am trying to do an AXIS2C build on HP 11.11
> (32
> > bit).
> > >
> > > I have modified some CFLAGS and LDFLAGS, and
> > accordingly changed a few source files to include
> platform
> > specific header files. The compilation goes fine and
> also
> > the axis distribution is done.
> > >
> > > But when I see ldd libaxis2_engine.so, I see
> something
> > like :
> > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > =>
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> >
> > What is the problem exactly?
> > The fact, that ldd prints the output above is not
> > necessarily bad - ldd
> > just resolves the libs as the loader does and if it
> finds
> > that lib with
> > the path /work/... - fine.
> >
> > > So, if you see here the portion before "=>"
> has a
> > hard-coded path.
> > >
> > > So, when I take the axis tar file and try to
> extract
> > on a different machine, because this path
> "/work/AXIS_HP"
> > won't exist on other machines, the extraction fails.
> >
> > If you do the ldd on another machine, ldd should say
> > something like:
> > libaxis2_engine.so => not found
> > right?
> >
> > Please provide the command output when linking the
> > libaxis2_engine.so.
> > Also, on HP-UX there is a command "chatr" which tells
> you
> > the libs of
> > dependent libs, locating strategies and built-in
> library
> > paths.
> > What does that command say?
> >
> > BTW: This is PA-RISC? What does "uname -a" say?
> >
> > Rgds,
> > tge
> >
> > > On other platforms, HPIA/ AIX/ Linux etc, the
> file is
> > displayed as :
> > >
> > > libaxis2_engine.so =>
> >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > >
> > >
> > > Can somebody tell me which is the flag which that
> do
> > the trick for me ?
> > >
> > > Rgds,
> > > Ramesh.
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit) ---- Pls help me with this problem
Posted by ramesh Gopal <fa...@yahoo.com>.
Hello Thomas,
The script that gets executed is :
archive_cmds='$CC -b -Wl,+s -Wl,+h -Wl,$soname -Wl,+b -Wl,$install_libdir -o $lib $libobjs $deplibs $compiler_flags
Is it possible to give a direct conversion of this script to use the ld option as you had suggested.
Is this the right way of probably building Axis and its corresponding so files?
Ramesh.
--- On Wed, 2/3/11, Thomas Gentsch <tg...@e-tge.de> wrote:
> From: Thomas Gentsch <tg...@e-tge.de>
> Subject: Re: Axis2C build on HP 11.11 (32 bit) ---- Pls help me with this problem
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Wednesday, 2 March, 2011, 6:42 PM
>
> Hi Ramesh,
>
> sorry for the delay ...
> Here is how I build shared libs on HP-UX PA-Risc (of course
> using some
> Makefile):
>
> $ ld file1.o file2.o ...
> -b
> -B immediate
> +b:
> -L. -L/lib/path1 -L/lib/path2 ...
> +s
> -lib1 -lib2 ...
> -omylib.sl
>
> which means:
> - a list of object files as usual
> - -b create a shared lib
> - -B immediate means "binding immediate, i.e. resolve
> all foreign symbols at lib loading"
> - +b allows to set a runtime library path, +b: is special
> in a way
> that it uses all the -L paths for this
> purpose
> - -L as usual
> - +s means that SHLIB_PATH is to be activated (the HP-UX
> equivalent of
> LD_LIBRARY_PATH)
> - -l and -o as usual
>
> This results in:
> $ chatr mylib.sl
> mylib.sl:
> shared library
> shared library
> dynamic path search:
>
> SHLIB_PATH
> enabled second
>
> embedded path
> enabled first
> :.:/lib/path1:/lib/path2
> shared library
> list:
>
> dynamic /lib/path1/libib1.sl
>
> dynamic /lib/path2/libib2.sl
> ...
> shared vtable
> support disabled
> explicit unloading
> enabled
> ...
>
> Now you have a SL that
> 1. tries to use the shared libs as stated above
> 2. tries the embedded library search path
> 3. tries SHLIB_PATH and LD_LIBRARY_PATH
> (I'm not sure about 1. without trying out)
>
> I never use libtool and don't know what to do in that
> case.
> But the way above works nicely.
>
> HTH :-)
> tge
>
> On Tue, 2011-03-01 at 16:26 +0530, ramesh Gopal wrote:
> > I see that there is a libtool script, I suppose this
> is the one which does the linking phase and there could be
> some parameters which we might need to change to accomplish
> this.
> >
> > I am trying to see.
> >
> > In the meanwhile, can anybody tell me if they could
> get an Axis build on HP UX 11.11 working ...
> >
> > Rgds,
> > Ramesh.
> >
> > --- On Tue, 1/3/11, ramesh Gopal <fa...@yahoo.com>
> wrote:
> >
> > > From: ramesh Gopal <fa...@yahoo.com>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Tuesday, 1 March, 2011, 2:14 PM
> > >
> > > Hello,
> > >
> > > Pls help me with this issue.
> > >
> > > There should be a way to suppress the hardcoding
> of the
> > > paths while creating the shared object. Is there
> something
> > > parameter in the configure script which might be
> causing
> > > this behaviour.
> > >
> > > Ramesh.
> > >
> > > --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> > > wrote:
> > >
> > > > From: ramesh Gopal <fa...@yahoo.com>
> > > > Subject: Re: Axis2C build on HP 11.11 (32
> bit)
> > > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > > Date: Tuesday, 22 February, 2011, 3:46 PM
> > > >
> > > > Hello Thomas,
> > > >
> > > > The chatr command displays :
> > > >
> > > > chatr libaxis2_engine.so
> > > > libaxis2_engine.so:
> > > > shared
> library
> > > > shared
> library
> > > > dynamic path search:
> > > >
> > > > SHLIB_PATH
> > > > enabled second
> > > >
> > > > embedded path
> > > > enabled first
> > > > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > > > internal
> name:
> > > >
> > > > libaxis2_engine.so.5
> > > > shared
> library
> > > > list:
> > > >
> > > > static
> > > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> > > >
> > > > static
> > > >
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> > > >
> > > > static
> > > >
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> > > >
> > > > static
> > > >
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> > > >
> > > > static
> > > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> > > >
> > > > static
> > > >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> > > >
> > > >
> dynamic /usr/lib/libpthread.1
> > > >
> > > >
> dynamic /usr/lib/libc.2
> > > >
> > > > Ramesh.
> > > >
> > > >
> > > > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > > > wrote:
> > > >
> > > > > From: Thomas Gentsch <tg...@e-tge.de>
> > > > > Subject: Re: Axis2C build on HP 11.11
> (32 bit)
> > > > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > > > Date: Friday, 18 February, 2011, 1:45
> AM
> > > > >
> > > > > Hi Ramesh!
> > > > >
> > > > > On Thu, 2011-02-17 at 16:14 +0530,
> ramesh Gopal
> > > > wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I am trying to do an AXIS2C build
> on HP
> > > 11.11
> > > > (32
> > > > > bit).
> > > > > >
> > > > > > I have modified some CFLAGS and
> LDFLAGS,
> > > and
> > > > > accordingly changed a few source files
> to
> > > include
> > > > platform
> > > > > specific header files. The compilation
> goes fine
> > > and
> > > > also
> > > > > the axis distribution is done.
> > > > > >
> > > > > > But when I see ldd
> libaxis2_engine.so, I
> > > see
> > > > something
> > > > > like :
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > > =>
> > > > >
> > > >
> > >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > >
> > > > > What is the problem exactly?
> > > > > The fact, that ldd prints the output
> above is
> > > not
> > > > > necessarily bad - ldd
> > > > > just resolves the libs as the loader
> does and if
> > > it
> > > > finds
> > > > > that lib with
> > > > > the path /work/... - fine.
> > > > >
> > > > > > So, if you see here the portion
> before
> > > "=>"
> > > > has a
> > > > > hard-coded path.
> > > > > >
> > > > > > So, when I take the axis tar file
> and try
> > > to
> > > > extract
> > > > > on a different machine, because this
> path
> > > > "/work/AXIS_HP"
> > > > > won't exist on other machines, the
> extraction
> > > fails.
> > > > >
> > > > > If you do the ldd on another machine,
> ldd should
> > > say
> > > > > something like:
> > > > > libaxis2_engine.so => not
> found
> > > > > right?
> > > > >
> > > > > Please provide the command output when
> linking
> > > the
> > > > > libaxis2_engine.so.
> > > > > Also, on HP-UX there is a command
> "chatr" which
> > > tells
> > > > you
> > > > > the libs of
> > > > > dependent libs, locating strategies and
> built-in
> > > > library
> > > > > paths.
> > > > > What does that command say?
> > > > >
> > > > > BTW: This is PA-RISC? What does "uname
> -a" say?
> > > > >
> > > > > Rgds,
> > > > > tge
> > > > >
> > > > > > On other platforms, HPIA/ AIX/
> Linux etc,
> > > the
> > > > file is
> >
> > > > > displayed as :
> > > > > >
> > > > > > libaxis2_engine.so =>
> > > > >
> > > >
> > >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > > >
> > > > > >
> > > > > > Can somebody tell me which is the
> flag which
> > > that
> > > > do
> > > > > the trick for me ?
> > > > > >
> > > > > > Rgds,
> > > > > > Ramesh.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > > > For additional commands, e-mail:
> c-user-help@axis.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit) ---- Pls help me with this
problem
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi Ramesh,
sorry for the delay ...
Here is how I build shared libs on HP-UX PA-Risc (of course using some
Makefile):
$ ld file1.o file2.o ...
-b
-B immediate
+b:
-L. -L/lib/path1 -L/lib/path2 ...
+s
-lib1 -lib2 ...
-omylib.sl
which means:
- a list of object files as usual
- -b create a shared lib
- -B immediate means "binding immediate, i.e. resolve
all foreign symbols at lib loading"
- +b allows to set a runtime library path, +b: is special in a way
that it uses all the -L paths for this purpose
- -L as usual
- +s means that SHLIB_PATH is to be activated (the HP-UX equivalent of
LD_LIBRARY_PATH)
- -l and -o as usual
This results in:
$ chatr mylib.sl
mylib.sl:
shared library
shared library dynamic path search:
SHLIB_PATH enabled second
embedded path enabled first :.:/lib/path1:/lib/path2
shared library list:
dynamic /lib/path1/libib1.sl
dynamic /lib/path2/libib2.sl
...
shared vtable support disabled
explicit unloading enabled
...
Now you have a SL that
1. tries to use the shared libs as stated above
2. tries the embedded library search path
3. tries SHLIB_PATH and LD_LIBRARY_PATH
(I'm not sure about 1. without trying out)
I never use libtool and don't know what to do in that case.
But the way above works nicely.
HTH :-)
tge
On Tue, 2011-03-01 at 16:26 +0530, ramesh Gopal wrote:
> I see that there is a libtool script, I suppose this is the one which does the linking phase and there could be some parameters which we might need to change to accomplish this.
>
> I am trying to see.
>
> In the meanwhile, can anybody tell me if they could get an Axis build on HP UX 11.11 working ...
>
> Rgds,
> Ramesh.
>
> --- On Tue, 1/3/11, ramesh Gopal <fa...@yahoo.com> wrote:
>
> > From: ramesh Gopal <fa...@yahoo.com>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Tuesday, 1 March, 2011, 2:14 PM
> >
> > Hello,
> >
> > Pls help me with this issue.
> >
> > There should be a way to suppress the hardcoding of the
> > paths while creating the shared object. Is there something
> > parameter in the configure script which might be causing
> > this behaviour.
> >
> > Ramesh.
> >
> > --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> > wrote:
> >
> > > From: ramesh Gopal <fa...@yahoo.com>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Tuesday, 22 February, 2011, 3:46 PM
> > >
> > > Hello Thomas,
> > >
> > > The chatr command displays :
> > >
> > > chatr libaxis2_engine.so
> > > libaxis2_engine.so:
> > > shared library
> > > shared library
> > > dynamic path search:
> > >
> > > SHLIB_PATH
> > > enabled second
> > >
> > > embedded path
> > > enabled first
> > > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > > internal name:
> > >
> > > libaxis2_engine.so.5
> > > shared library
> > > list:
> > >
> > > static
> > > /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> > >
> > > static
> > >
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> > >
> > > static
> > >
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> > >
> > > static
> > >
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> > >
> > > static
> > > /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> > >
> > > static
> > > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> > >
> > > dynamic /usr/lib/libpthread.1
> > >
> > > dynamic /usr/lib/libc.2
> > >
> > > Ramesh.
> > >
> > >
> > > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > > wrote:
> > >
> > > > From: Thomas Gentsch <tg...@e-tge.de>
> > > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > > Date: Friday, 18 February, 2011, 1:45 AM
> > > >
> > > > Hi Ramesh!
> > > >
> > > > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> > > wrote:
> > > > > Hello,
> > > > >
> > > > > I am trying to do an AXIS2C build on HP
> > 11.11
> > > (32
> > > > bit).
> > > > >
> > > > > I have modified some CFLAGS and LDFLAGS,
> > and
> > > > accordingly changed a few source files to
> > include
> > > platform
> > > > specific header files. The compilation goes fine
> > and
> > > also
> > > > the axis distribution is done.
> > > > >
> > > > > But when I see ldd libaxis2_engine.so, I
> > see
> > > something
> > > > like :
> > > > >
> > > > >
> > > >
> > >
> > /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > =>
> > > >
> > >
> > /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > >
> > > > What is the problem exactly?
> > > > The fact, that ldd prints the output above is
> > not
> > > > necessarily bad - ldd
> > > > just resolves the libs as the loader does and if
> > it
> > > finds
> > > > that lib with
> > > > the path /work/... - fine.
> > > >
> > > > > So, if you see here the portion before
> > "=>"
> > > has a
> > > > hard-coded path.
> > > > >
> > > > > So, when I take the axis tar file and try
> > to
> > > extract
> > > > on a different machine, because this path
> > > "/work/AXIS_HP"
> > > > won't exist on other machines, the extraction
> > fails.
> > > >
> > > > If you do the ldd on another machine, ldd should
> > say
> > > > something like:
> > > > libaxis2_engine.so => not found
> > > > right?
> > > >
> > > > Please provide the command output when linking
> > the
> > > > libaxis2_engine.so.
> > > > Also, on HP-UX there is a command "chatr" which
> > tells
> > > you
> > > > the libs of
> > > > dependent libs, locating strategies and built-in
> > > library
> > > > paths.
> > > > What does that command say?
> > > >
> > > > BTW: This is PA-RISC? What does "uname -a" say?
> > > >
> > > > Rgds,
> > > > tge
> > > >
> > > > > On other platforms, HPIA/ AIX/ Linux etc,
> > the
> > > file is
>
> > > > displayed as :
> > > > >
> > > > > libaxis2_engine.so =>
> > > >
> > >
> > /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > > >
> > > > >
> > > > > Can somebody tell me which is the flag which
> > that
> > > do
> > > > the trick for me ?
> > > > >
> > > > > Rgds,
> > > > > Ramesh.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit) ---- Pls help me with this problem
Posted by ramesh Gopal <fa...@yahoo.com>.
I see that there is a libtool script, I suppose this is the one which does the linking phase and there could be some parameters which we might need to change to accomplish this.
I am trying to see.
In the meanwhile, can anybody tell me if they could get an Axis build on HP UX 11.11 working ...
Rgds,
Ramesh.
--- On Tue, 1/3/11, ramesh Gopal <fa...@yahoo.com> wrote:
> From: ramesh Gopal <fa...@yahoo.com>
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Tuesday, 1 March, 2011, 2:14 PM
>
> Hello,
>
> Pls help me with this issue.
>
> There should be a way to suppress the hardcoding of the
> paths while creating the shared object. Is there something
> parameter in the configure script which might be causing
> this behaviour.
>
> Ramesh.
>
> --- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com>
> wrote:
>
> > From: ramesh Gopal <fa...@yahoo.com>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Tuesday, 22 February, 2011, 3:46 PM
> >
> > Hello Thomas,
> >
> > The chatr command displays :
> >
> > chatr libaxis2_engine.so
> > libaxis2_engine.so:
> > shared library
> > shared library
> > dynamic path search:
> >
> > SHLIB_PATH
> > enabled second
> >
> > embedded path
> > enabled first
> > /work/AXIS_HP/axis2c-src-1.5.0/lib
> > internal name:
> >
> > libaxis2_engine.so.5
> > shared library
> > list:
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
> >
> > static
> >
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
> >
> > static
> > /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
> >
> > dynamic /usr/lib/libpthread.1
> >
> > dynamic /usr/lib/libc.2
> >
> > Ramesh.
> >
> >
> > --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> > wrote:
> >
> > > From: Thomas Gentsch <tg...@e-tge.de>
> > > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > > Date: Friday, 18 February, 2011, 1:45 AM
> > >
> > > Hi Ramesh!
> > >
> > > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> > wrote:
> > > > Hello,
> > > >
> > > > I am trying to do an AXIS2C build on HP
> 11.11
> > (32
> > > bit).
> > > >
> > > > I have modified some CFLAGS and LDFLAGS,
> and
> > > accordingly changed a few source files to
> include
> > platform
> > > specific header files. The compilation goes fine
> and
> > also
> > > the axis distribution is done.
> > > >
> > > > But when I see ldd libaxis2_engine.so, I
> see
> > something
> > > like :
> > > >
> > > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > =>
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > >
> > > What is the problem exactly?
> > > The fact, that ldd prints the output above is
> not
> > > necessarily bad - ldd
> > > just resolves the libs as the loader does and if
> it
> > finds
> > > that lib with
> > > the path /work/... - fine.
> > >
> > > > So, if you see here the portion before
> "=>"
> > has a
> > > hard-coded path.
> > > >
> > > > So, when I take the axis tar file and try
> to
> > extract
> > > on a different machine, because this path
> > "/work/AXIS_HP"
> > > won't exist on other machines, the extraction
> fails.
> > >
> > > If you do the ldd on another machine, ldd should
> say
> > > something like:
> > > libaxis2_engine.so => not found
> > > right?
> > >
> > > Please provide the command output when linking
> the
> > > libaxis2_engine.so.
> > > Also, on HP-UX there is a command "chatr" which
> tells
> > you
> > > the libs of
> > > dependent libs, locating strategies and built-in
> > library
> > > paths.
> > > What does that command say?
> > >
> > > BTW: This is PA-RISC? What does "uname -a" say?
> > >
> > > Rgds,
> > > tge
> > >
> > > > On other platforms, HPIA/ AIX/ Linux etc,
> the
> > file is
> > > displayed as :
> > > >
> > > > libaxis2_engine.so =>
> > >
> >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > > >
> > > >
> > > > Can somebody tell me which is the flag which
> that
> > do
> > > the trick for me ?
> > > >
> > > > Rgds,
> > > > Ramesh.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > > For additional commands, e-mail: c-user-help@axis.apache.org
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> > >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit)
Posted by ramesh Gopal <fa...@yahoo.com>.
Hello,
Pls help me with this issue.
There should be a way to suppress the hardcoding of the paths while creating the shared object. Is there something parameter in the configure script which might be causing this behaviour.
Ramesh.
--- On Tue, 22/2/11, ramesh Gopal <fa...@yahoo.com> wrote:
> From: ramesh Gopal <fa...@yahoo.com>
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Tuesday, 22 February, 2011, 3:46 PM
>
> Hello Thomas,
>
> The chatr command displays :
>
> chatr libaxis2_engine.so
> libaxis2_engine.so:
> shared library
> shared library
> dynamic path search:
>
> SHLIB_PATH
> enabled second
>
> embedded path
> enabled first
> /work/AXIS_HP/axis2c-src-1.5.0/lib
> internal name:
>
> libaxis2_engine.so.5
> shared library
> list:
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
>
> static
> /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
>
> dynamic /usr/lib/libpthread.1
>
> dynamic /usr/lib/libc.2
>
> Ramesh.
>
>
> --- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de>
> wrote:
>
> > From: Thomas Gentsch <tg...@e-tge.de>
> > Subject: Re: Axis2C build on HP 11.11 (32 bit)
> > To: "Apache AXIS C User List" <c-...@axis.apache.org>
> > Date: Friday, 18 February, 2011, 1:45 AM
> >
> > Hi Ramesh!
> >
> > On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal
> wrote:
> > > Hello,
> > >
> > > I am trying to do an AXIS2C build on HP 11.11
> (32
> > bit).
> > >
> > > I have modified some CFLAGS and LDFLAGS, and
> > accordingly changed a few source files to include
> platform
> > specific header files. The compilation goes fine and
> also
> > the axis distribution is done.
> > >
> > > But when I see ldd libaxis2_engine.so, I see
> something
> > like :
> > >
> > >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > =>
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> >
> > What is the problem exactly?
> > The fact, that ldd prints the output above is not
> > necessarily bad - ldd
> > just resolves the libs as the loader does and if it
> finds
> > that lib with
> > the path /work/... - fine.
> >
> > > So, if you see here the portion before "=>"
> has a
> > hard-coded path.
> > >
> > > So, when I take the axis tar file and try to
> extract
> > on a different machine, because this path
> "/work/AXIS_HP"
> > won't exist on other machines, the extraction fails.
> >
> > If you do the ldd on another machine, ldd should say
> > something like:
> > libaxis2_engine.so => not found
> > right?
> >
> > Please provide the command output when linking the
> > libaxis2_engine.so.
> > Also, on HP-UX there is a command "chatr" which tells
> you
> > the libs of
> > dependent libs, locating strategies and built-in
> library
> > paths.
> > What does that command say?
> >
> > BTW: This is PA-RISC? What does "uname -a" say?
> >
> > Rgds,
> > tge
> >
> > > On other platforms, HPIA/ AIX/ Linux etc, the
> file is
> > displayed as :
> > >
> > > libaxis2_engine.so =>
> >
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> > >
> > >
> > > Can somebody tell me which is the flag which that
> do
> > the trick for me ?
> > >
> > > Rgds,
> > > Ramesh.
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > > For additional commands, e-mail: c-user-help@axis.apache.org
> > >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit)
Posted by ramesh Gopal <fa...@yahoo.com>.
Hello Thomas,
The chatr command displays :
chatr libaxis2_engine.so
libaxis2_engine.so:
shared library
shared library dynamic path search:
SHLIB_PATH enabled second
embedded path enabled first /work/AXIS_HP/axis2c-src-1.5.0/lib
internal name:
libaxis2_engine.so.5
shared library list:
static /work/AXIS_HP/axis2c-src-1.5.0/lib/libneethi.so.5
static /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_http_common.so.5
static /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_axiom.so.5
static /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxis2_parser.so.5
static /work/AXIS_HP/axis2c-src-1.5.0/lib/libguththila.so.5
static /work/AXIS_HP/axis2c-src-1.5.0/lib/libaxutil.so.5
dynamic /usr/lib/libpthread.1
dynamic /usr/lib/libc.2
Ramesh.
--- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de> wrote:
> From: Thomas Gentsch <tg...@e-tge.de>
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Friday, 18 February, 2011, 1:45 AM
>
> Hi Ramesh!
>
> On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal wrote:
> > Hello,
> >
> > I am trying to do an AXIS2C build on HP 11.11 (32
> bit).
> >
> > I have modified some CFLAGS and LDFLAGS, and
> accordingly changed a few source files to include platform
> specific header files. The compilation goes fine and also
> the axis distribution is done.
> >
> > But when I see ldd libaxis2_engine.so, I see something
> like :
> >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> =>
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
>
> What is the problem exactly?
> The fact, that ldd prints the output above is not
> necessarily bad - ldd
> just resolves the libs as the loader does and if it finds
> that lib with
> the path /work/... - fine.
>
> > So, if you see here the portion before "=>" has a
> hard-coded path.
> >
> > So, when I take the axis tar file and try to extract
> on a different machine, because this path "/work/AXIS_HP"
> won't exist on other machines, the extraction fails.
>
> If you do the ldd on another machine, ldd should say
> something like:
> libaxis2_engine.so => not found
> right?
>
> Please provide the command output when linking the
> libaxis2_engine.so.
> Also, on HP-UX there is a command "chatr" which tells you
> the libs of
> dependent libs, locating strategies and built-in library
> paths.
> What does that command say?
>
> BTW: This is PA-RISC? What does "uname -a" say?
>
> Rgds,
> tge
>
> > On other platforms, HPIA/ AIX/ Linux etc, the file is
> displayed as :
> >
> > libaxis2_engine.so =>
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> >
> >
> > Can somebody tell me which is the flag which that do
> the trick for me ?
> >
> > Rgds,
> > Ramesh.
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit)
Posted by ramesh Gopal <fa...@yahoo.com>.
Hello Thomas,
The problem that I am facing is ... when I try to install the axis distribution on a different machine, it fails to extract it properly, because the complete path (as against the relative path ---- /work/AXIS_HP/ in this case) may not exist on a different machine.
The machine on which axis build is being done is a pa-risc. I am using 32 bit flags.
Ramesh.
--- On Fri, 18/2/11, Thomas Gentsch <tg...@e-tge.de> wrote:
> From: Thomas Gentsch <tg...@e-tge.de>
> Subject: Re: Axis2C build on HP 11.11 (32 bit)
> To: "Apache AXIS C User List" <c-...@axis.apache.org>
> Date: Friday, 18 February, 2011, 1:45 AM
>
> Hi Ramesh!
>
> On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal wrote:
> > Hello,
> >
> > I am trying to do an AXIS2C build on HP 11.11 (32
> bit).
> >
> > I have modified some CFLAGS and LDFLAGS, and
> accordingly changed a few source files to include platform
> specific header files. The compilation goes fine and also
> the axis distribution is done.
> >
> > But when I see ldd libaxis2_engine.so, I see something
> like :
> >
> >
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> =>
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
>
> What is the problem exactly?
> The fact, that ldd prints the output above is not
> necessarily bad - ldd
> just resolves the libs as the loader does and if it finds
> that lib with
> the path /work/... - fine.
>
> > So, if you see here the portion before "=>" has a
> hard-coded path.
> >
> > So, when I take the axis tar file and try to extract
> on a different machine, because this path "/work/AXIS_HP"
> won't exist on other machines, the extraction fails.
>
> If you do the ldd on another machine, ldd should say
> something like:
> libaxis2_engine.so => not found
> right?
>
> Please provide the command output when linking the
> libaxis2_engine.so.
> Also, on HP-UX there is a command "chatr" which tells you
> the libs of
> dependent libs, locating strategies and built-in library
> paths.
> What does that command say?
>
> BTW: This is PA-RISC? What does "uname -a" say?
>
> Rgds,
> tge
>
> > On other platforms, HPIA/ AIX/ Linux etc, the file is
> displayed as :
> >
> > libaxis2_engine.so =>
> /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
> >
> >
> > Can somebody tell me which is the flag which that do
> the trick for me ?
> >
> > Rgds,
> > Ramesh.
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> > For additional commands, e-mail: c-user-help@axis.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Axis2C build on HP 11.11 (32 bit)
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi Ramesh!
On Thu, 2011-02-17 at 16:14 +0530, ramesh Gopal wrote:
> Hello,
>
> I am trying to do an AXIS2C build on HP 11.11 (32 bit).
>
> I have modified some CFLAGS and LDFLAGS, and accordingly changed a few source files to include platform specific header files. The compilation goes fine and also the axis distribution is done.
>
> But when I see ldd libaxis2_engine.so, I see something like :
>
> /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so => /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
What is the problem exactly?
The fact, that ldd prints the output above is not necessarily bad - ldd
just resolves the libs as the loader does and if it finds that lib with
the path /work/... - fine.
> So, if you see here the portion before "=>" has a hard-coded path.
>
> So, when I take the axis tar file and try to extract on a different machine, because this path "/work/AXIS_HP" won't exist on other machines, the extraction fails.
If you do the ldd on another machine, ldd should say something like:
libaxis2_engine.so => not found
right?
Please provide the command output when linking the libaxis2_engine.so.
Also, on HP-UX there is a command "chatr" which tells you the libs of
dependent libs, locating strategies and built-in library paths.
What does that command say?
BTW: This is PA-RISC? What does "uname -a" say?
Rgds,
tge
> On other platforms, HPIA/ AIX/ Linux etc, the file is displayed as :
>
> libaxis2_engine.so => /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
>
>
> Can somebody tell me which is the flag which that do the trick for me ?
>
> Rgds,
> Ramesh.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Axis2C build on HP 11.11 (32 bit)
Posted by ramesh Gopal <fa...@yahoo.com>.
Hello,
I am trying to do an AXIS2C build on HP 11.11 (32 bit).
I have modified some CFLAGS and LDFLAGS, and accordingly changed a few source files to include platform specific header files. The compilation goes fine and also the axis distribution is done.
But when I see ldd libaxis2_engine.so, I see something like :
/work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so => /work/AXIS_HP/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
So, if you see here the portion before "=>" has a hard-coded path.
So, when I take the axis tar file and try to extract on a different machine, because this path "/work/AXIS_HP" won't exist on other machines, the extraction fails.
On other platforms, HPIA/ AIX/ Linux etc, the file is displayed as :
libaxis2_engine.so => /work/AXIS/axis2c-src-1.5.0/axiom/src/core/engine/.libs/libaxis2_engine.so
Can somebody tell me which is the flag which that do the trick for me ?
Rgds,
Ramesh.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: AW: Guththila vs libxml2
Posted by Emanuele Benedetti <be...@mclink.it>.
In data 10 febbraio 2011 alle ore 11:47:42, Thomas Gentsch <tg...@e-tge.de>
ha scritto:
> @Emanuele: Did libxml2 help in your case? Possibly it was a similar
> thing ... I still use 1.6.
Yes, after moving to libxml2 I had no problems with messages of any type
both using Axis2c for services and clients.
I also use the 1.6
--
Saluti
Emanuele
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: AW: Guththila vs libxml2
Posted by Thomas Gentsch <tg...@e-tge.de>.
On Thu, 2011-02-10 at 10:11 +0100, Stadelmann Josef wrote:
> And test and test and be aware that not every client can accept
:-) So far I was quite happy with it
> per default message-response as large as 65536 bytes
> (16 bit pointers eventually).
I'll have to re-read your earlier post again (and search through the
list), but generally now with libxml2 I don't have any general troubles
with large data (if consider 900k as "large").
Right now I use this on Linux and Windows (both 32bit normally, few
tests with 64bit).
@Emanuele: Did libxml2 help in your case? Possibly it was a similar
thing ... I still use 1.6.
Rgds,
tge
> Also chunking and streaming
> architectures/implemntation should ring alarm bells.
> Josef
>
> -----Ursprüngliche Nachricht-----
> Von: Emanuele Benedetti [mailto:benem@mclink.it]
> Gesendet: Donnerstag, 10. Februar 2011 09:43
> An: Apache AXIS C User List
> Betreff: Re: Guththila vs libxml2
>
> In data 09 febbraio 2011 alle ore 20:00:19, Nandika Jayawardana
> <ja...@gmail.com> ha scritto:
>
> > Guththila parser is based on pull model and should be slightly faster
> > than
> > libxml as explained by the article. In the last few years, Guththila
> > became
> > the default parser and hence undergone good amount of testing. Hence, you
> > can use either parser for your usage.
>
>
> Some times ago I had to recompile axis2 with libxml2 support rather than
> Guththila as the latter silently discard messages bigger than 128K. I
> don't know if the sistuation is changed with the last versions (I'm
> speaking of a couple of years ago when was just out the axis2c version
> 1.6).
>
> SO if you plan to receive messages bigger than that, make some tests.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
AW: Guththila vs libxml2
Posted by Stadelmann Josef <jo...@axa-winterthur.ch>.
And test and test and be aware that not every client can accept
per default message-response as large as 65536 bytes
(16 bit pointers eventually). Also chunking and streaming
architectures/implemntation should ring alarm bells.
Josef
-----Ursprüngliche Nachricht-----
Von: Emanuele Benedetti [mailto:benem@mclink.it]
Gesendet: Donnerstag, 10. Februar 2011 09:43
An: Apache AXIS C User List
Betreff: Re: Guththila vs libxml2
In data 09 febbraio 2011 alle ore 20:00:19, Nandika Jayawardana
<ja...@gmail.com> ha scritto:
> Guththila parser is based on pull model and should be slightly faster
> than
> libxml as explained by the article. In the last few years, Guththila
> became
> the default parser and hence undergone good amount of testing. Hence, you
> can use either parser for your usage.
Some times ago I had to recompile axis2 with libxml2 support rather than
Guththila as the latter silently discard messages bigger than 128K. I
don't know if the sistuation is changed with the last versions (I'm
speaking of a couple of years ago when was just out the axis2c version
1.6).
SO if you plan to receive messages bigger than that, make some tests.
--
Saluti
Emanuele
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Guththila vs libxml2
Posted by Emanuele Benedetti <be...@mclink.it>.
In data 09 febbraio 2011 alle ore 20:00:19, Nandika Jayawardana
<ja...@gmail.com> ha scritto:
> Guththila parser is based on pull model and should be slightly faster
> than
> libxml as explained by the article. In the last few years, Guththila
> became
> the default parser and hence undergone good amount of testing. Hence, you
> can use either parser for your usage.
Some times ago I had to recompile axis2 with libxml2 support rather than
Guththila as the latter silently discard messages bigger than 128K. I
don't know if the sistuation is changed with the last versions (I'm
speaking of a couple of years ago when was just out the axis2c version
1.6).
SO if you plan to receive messages bigger than that, make some tests.
--
Saluti
Emanuele
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Guththila vs libxml2
Posted by Thomas Gentsch <tg...@e-tge.de>.
On Thu, 2011-02-10 at 00:30 +0530, Nandika Jayawardana wrote:
> Guththila parser is based on pull model and should be slightly faster
> than libxml as explained by the article. In the last few years,
> Guththila became the default parser and hence undergone good amount of
> testing. Hence, you can use either parser for your usage.
Hmm, ok ... due to a problem I replaced guththila by libxml a few days
ago (before I indeed had no troubles with guththila), still testing with
libxml2 now.
I tried really hard but failed to figure out where the actual problem in
my case is/was with guththila - just in case somebody else want to give
this another go: please see AXIS2C-1534
I'm happy to assist though ...
My latest idea was that it might be connected to the buffering mechanism
since the problem appears only
- with large data (using multiple buffers)
- if at the very end of a full buffer the NS of an opening XML appears
like [...<tns1:] [tagname>value</tns1:tagname>...]
Results in complete Axiom reading with the small flaw that "tagname" has
no NS anymore which makes subsequent writing the XML fail.
Rgds,
tge
> Regards
> Nandika
>
>
> On Fri, Feb 4, 2011 at 4:33 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
> Hi all,
>
> another question - what are the pros + cons of either XML
> parser?
>
> I'm using libxml2 anyway and would like to avoid having two
> XML parsers
> within the same prog. So, I'd like to replace the (obviously
> standard)
> guththila by libxml2, which requires a rebuild etc as far as I
> understand.
> But before actually doing this I'd like to find out what I
> have to
> expect then ...
>
> >From the following I read that guththila is slightly faster:
> http://wso2.org/library/3532
> Anything else?
>
> Many thx in advance!!
> Rgds,
> tge
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Will Axis2C load the same web service twice even if a single
request is made
Posted by Nandika Jayawardana <ja...@gmail.com>.
This should result in loading the service twice. Handler is used for
processing the headers. It does not load the service.
Regards
Nandika
On Fri, Mar 25, 2011 at 10:52 AM, ramesh Gopal <fa...@yahoo.com>wrote:
>
>
> Hi,
>
> Environment - Axis2C 1.5.0
>
> My axis logs contains :
>
> [Wed Mar 23 16:04:12 2011] [debug] phase_resolver.c(222) svc name
> is:issues_serial
> [Wed Mar 23 16:04:12 2011] [debug] phase_resolver.c(139) Service name is :
> issues_serial
> [Wed Mar 23 16:04:12 2011] [debug] phase_resolver.c(1123) Operation name is
> : issues_serial
> [Wed Mar 23 16:04:12 2011] [debug] phase_holder.c(139) Add handler
> AddressingOutHandler to phase MessageOut
> [Wed Mar 23 16:04:12 2011] [debug] phase_holder.c(139) Add handler
> AddressingOutHandler to phase MessageOut
>
> Here we see the handler being called twice.
>
> Will this result in Axis2C loading the same web service twice even if a
> single call is made to the web service?
>
> Rgds,
> Ramesh
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
Will Axis2C load the same web service twice even if a single request is made
Posted by ramesh Gopal <fa...@yahoo.com>.
Hi,
Environment - Axis2C 1.5.0
My axis logs contains :
[Wed Mar 23 16:04:12 2011] [debug] phase_resolver.c(222) svc name is:issues_serial
[Wed Mar 23 16:04:12 2011] [debug] phase_resolver.c(139) Service name is : issues_serial
[Wed Mar 23 16:04:12 2011] [debug] phase_resolver.c(1123) Operation name is : issues_serial
[Wed Mar 23 16:04:12 2011] [debug] phase_holder.c(139) Add handler AddressingOutHandler to phase MessageOut
[Wed Mar 23 16:04:12 2011] [debug] phase_holder.c(139) Add handler AddressingOutHandler to phase MessageOut
Here we see the handler being called twice.
Will this result in Axis2C loading the same web service twice even if a single call is made to the web service?
Rgds,
Ramesh
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Race condition in server stop?
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi all,
I opened AXIS2C-1537 and attached two small patches which basically
contain the changes described below.
In my case it has helped - though I have to admit that I do not use the
"simple_axis2_server", therefore I have not tested the change in
http_server_main.c - it is rather intended to reflect what I have
changed in my own server code (see below [1]).
Some review is appreciated.
Rgds,
tge
On Thu, 2011-02-10 at 04:10 +0100, Thomas Gentsch wrote:
> Hi all,
>
> I experience some infrequent crashes at stopping an Axis server using
> axis2_http_server_stop(...);
> axis2_transport_receiver_free(...);
>
> Now it looks to me as if
> - axis2_http_server_stop() just closes the listening socket of the
> listener thread and sets "stopped" to true
> - then, the listener thread (in axis2_http_svr_thread_run) returns
> from axutil_network_handler_svr_socket_accept()
> and checks the worker:
> if (!svr_thread->worker) ...
> But:
> - axis2_transport_receiver_free() indirectly calls
> axis2_http_server_free() which in turn destroys and frees
> server_impl->svr_thread
>
> I'm not sure yet whether I understand this completely, but it looks as
> if then (depending on which thread is faster) the listener accessed
> memory now already freed.
>
> In a first approach I moved in my own server prog the
This is [1] as mentioned above
> axis2_transport_receiver_free() after starting the HTTP server, i.e.:
> if(axis2_transport_receiver_start(srv, env) == AXIS2_FAILURE)
> {
> // err handling
> }
> printf("Listener returned\n");
> axis2_transport_receiver_free(...);
>
> This changes things a bit, now the crash comes later in
> axis2_http_svr_thread_run
> axutil_thread_pool_get_thread(..., axis2_svr_thread_worker_func
> ...
> axutil_stream_free
>
> But the question is: Is it right that the listener continues at all
> after the accept() returns a failure?
> I have inserted another test for "stopped" and, if so, break the
> listener loop and, so far, it seems to be ok.
>
> axis2_http_svr_thread_run(...)
> {
> ...
> socket = (int)axutil_network_handler_svr_socket_accept(env,
> svr_thread-> listen_socket);
> if(svr_thread->stopped)
> {
> break;
> }
This is the other patch.
> Does that ring any bells? Could somebody more experienced please think
> about that scenario (while having a look into the code)?
>
> I'll do more testing and, hoping that all keeps working, create a defect
> +patch.
>
> Rgds,
> tge
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Race condition in server stop?
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi all,
I experience some infrequent crashes at stopping an Axis server using
axis2_http_server_stop(...);
axis2_transport_receiver_free(...);
Now it looks to me as if
- axis2_http_server_stop() just closes the listening socket of the
listener thread and sets "stopped" to true
- then, the listener thread (in axis2_http_svr_thread_run) returns
from axutil_network_handler_svr_socket_accept()
and checks the worker:
if (!svr_thread->worker) ...
But:
- axis2_transport_receiver_free() indirectly calls
axis2_http_server_free() which in turn destroys and frees
server_impl->svr_thread
I'm not sure yet whether I understand this completely, but it looks as
if then (depending on which thread is faster) the listener accessed
memory now already freed.
In a first approach I moved in my own server prog the
axis2_transport_receiver_free() after starting the HTTP server, i.e.:
if(axis2_transport_receiver_start(srv, env) == AXIS2_FAILURE)
{
// err handling
}
printf("Listener returned\n");
axis2_transport_receiver_free(...);
This changes things a bit, now the crash comes later in
axis2_http_svr_thread_run
axutil_thread_pool_get_thread(..., axis2_svr_thread_worker_func
...
axutil_stream_free
But the question is: Is it right that the listener continues at all
after the accept() returns a failure?
I have inserted another test for "stopped" and, if so, break the
listener loop and, so far, it seems to be ok.
axis2_http_svr_thread_run(...)
{
...
socket = (int)axutil_network_handler_svr_socket_accept(env,
svr_thread-> listen_socket);
if(svr_thread->stopped)
{
break;
}
Does that ring any bells? Could somebody more experienced please think
about that scenario (while having a look into the code)?
I'll do more testing and, hoping that all keeps working, create a defect
+patch.
Rgds,
tge
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org
Re: Guththila vs libxml2
Posted by Nandika Jayawardana <ja...@gmail.com>.
Guththila parser is based on pull model and should be slightly faster than
libxml as explained by the article. In the last few years, Guththila became
the default parser and hence undergone good amount of testing. Hence, you
can use either parser for your usage.
Regards
Nandika
On Fri, Feb 4, 2011 at 4:33 PM, Thomas Gentsch <tg...@e-tge.de> wrote:
> Hi all,
>
> another question - what are the pros + cons of either XML parser?
>
> I'm using libxml2 anyway and would like to avoid having two XML parsers
> within the same prog. So, I'd like to replace the (obviously standard)
> guththila by libxml2, which requires a rebuild etc as far as I
> understand.
> But before actually doing this I'd like to find out what I have to
> expect then ...
>
> >From the following I read that guththila is slightly faster:
> http://wso2.org/library/3532
> Anything else?
>
> Many thx in advance!!
> Rgds,
> tge
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
> For additional commands, e-mail: c-user-help@axis.apache.org
>
>
Guththila vs libxml2
Posted by Thomas Gentsch <tg...@e-tge.de>.
Hi all,
another question - what are the pros + cons of either XML parser?
I'm using libxml2 anyway and would like to avoid having two XML parsers
within the same prog. So, I'd like to replace the (obviously standard)
guththila by libxml2, which requires a rebuild etc as far as I
understand.
But before actually doing this I'd like to find out what I have to
expect then ...
>>From the following I read that guththila is slightly faster:
http://wso2.org/library/3532
Anything else?
Many thx in advance!!
Rgds,
tge
---------------------------------------------------------------------
To unsubscribe, e-mail: c-user-unsubscribe@axis.apache.org
For additional commands, e-mail: c-user-help@axis.apache.org