You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/06/17 11:38:10 UTC
RFE: axis c++ engine tracing
hi,
filed it under http://issues.apache.org/jira/browse/AXISCPP-100
i think it would be good to have some kind of tracing/logging compiled
into binary that could be triggered by setting environment variable (for
example AXISCPP_TRACE=engine:ALL).
it would be very useful tool when debugging such problems like wrong
SOAPAction to see if engine received request and see where did it go and
why it was rejected.
any comments? is it alredy possible?
in particular i had to add this (now ocmmented out) to WSDDService.cpp
to track the problem - if i could use tracer/logger intead of printf it
would be great:
diff -u -r1.21 WSDDService.cpp
--- WSDDService.cpp 26 Apr 2004 04:04:39 -0000 1.21
+++ WSDDService.cpp 17 Jun 2004 09:37:28 -0000
@@ -100,8 +100,10 @@
bool WSDDService::isAllowedMethod(const AxisChar* sServiceName) const
{
list<AxisString>::const_iterator iter;
+ //printf("ALEK:::: service name=%s\n", sServiceName);
for(iter = m_AllowedMethods.begin();iter !=
m_AllowedMethods.end();iter++)
{
+ //printf("ALEK::: *iter %s\n", *iter);
if((*iter) == sServiceName)
{
return true;
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Stub class changes
Posted by Susantha Kumara <su...@opensource.lk>.
On Mon, 2004-06-21 at 09:09, Samisa Abeysinghe wrote:
> Hi Susantha,
> You have changed the signature of the signature of Stub constructor from:
> Stub(const char *pcEndPointUri) to
> Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
>
> This has made the stubBase test case in tesst forlder fail to compile.
>
> I tried to get the test working, however you have not documented the eProtocol parameter, and
> I find it difficult to find what parameter values I should be passing.
>
> Could you please document the parameter.
>
Done.
> Also, is it a must to specify a protocol? cant we assume a default?
>
Done. Now the generated C++ stubs use HTTP by default.
Thanks samisa for early reporting the bug.
Susantha
---
> Samisa...
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
Re: Stub class changes
Posted by Susantha Kumara <su...@opensource.lk>.
Fixed.
Thanks for quick testing and reporting the problem.
Susantha
---
On Mon, 2004-06-21 at 09:43, Samisa Abeysinghe wrote:
> Hi Susantha,
> I set the default parameter value of eProtocol to be HTTP.
>
> Now I get yet another problem. You have shifted the logic of creating the header block to Call
> class. Now the Stub test case that I have written fails. See the stack trace below.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075313920 (LWP 4902)]
> 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50, pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
> 580 return (m_pIWSSZ->createHeaderBlock (pachLocalName, pachUri));
> Current language: auto; currently c++
> (gdb) bt
> #0 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50, pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
> #1 0x4005cfd2 in Stub::createSOAPHeaderBlock(char*, char*) (this=0xbfffe7f0,
> pachLocalName=0x804a9aa "TestHeader",
> pachUri=0x804cd50 "�\t@") at Stub.cpp:178
> #2 0x08048ee0 in strcpy ()
> #3 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
> (gdb)
>
> Earlier logic was working. But the new logic of yours is giving problems.
> Could you please fix this.
> Thanks,
> Samisa...
>
>
>
>
> --- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> > Hi Susantha,
> > You have changed the signature of the signature of Stub constructor from:
> > Stub(const char *pcEndPointUri) to
> > Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
> >
> > This has made the stubBase test case in tesst forlder fail to compile.
> >
> > I tried to get the test working, however you have not documented the eProtocol parameter,
> > and
> > I find it difficult to find what parameter values I should be passing.
> >
> > Could you please document the parameter.
> >
> > Also, is it a must to specify a protocol? cant we assume a default?
> >
> > Samisa...
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Take Yahoo! Mail with you! Get it on your mobile phone.
> > http://mobile.yahoo.com/maildemo
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
Re: Stub class changes
Posted by John Hawkins <HA...@uk.ibm.com>.
OK, so more API changes have happened !
This brings up the question of exactly when are we going to stop changing
the API. We must make this API concrete NOW so that people don't have to
rewrite their code. There seems to be a fundamental problem with the object
model if we have to keep doing things like this to add in more function.
Are we happy with the overall object model now or do we see more change
ahead?
John Hawkins
"Sanjiva
Weerawarana"
<sanjiva@opensour To
ce.lk> "Apache AXIS C Developers List"
<ax...@ws.apache.org>
21/06/2004 04:55 cc
Subject
Please respond to Re: Stub class changes
"Apache AXIS C
Developers List"
Guys, design changes like this should be proposed/explained
*before* they're implemented .. that would've prevented this
kind of problems.
Sanjiva.
----- Original Message -----
From: "Samisa Abeysinghe" <sa...@yahoo.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Monday, June 21, 2004 9:43 AM
Subject: Re: Stub class changes
> Hi Susantha,
> I set the default parameter value of eProtocol to be HTTP.
>
> Now I get yet another problem. You have shifted the logic of creating
the header block to Call
> class. Now the Stub test case that I have written fails. See the stack
trace below.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075313920 (LWP 4902)]
> 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50,
pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at
Call.cpp:580
> 580 return (m_pIWSSZ->createHeaderBlock (pachLocalName,
pachUri));
> Current language: auto; currently c++
> (gdb) bt
> #0 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50,
pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at
Call.cpp:580
> #1 0x4005cfd2 in Stub::createSOAPHeaderBlock(char*, char*)
(this=0xbfffe7f0,
> pachLocalName=0x804a9aa "TestHeader",
> pachUri=0x804cd50 "�\t@") at Stub.cpp:178
> #2 0x08048ee0 in strcpy ()
> #3 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
> (gdb)
>
> Earlier logic was working. But the new logic of yours is giving
problems.
> Could you please fix this.
> Thanks,
> Samisa...
>
>
>
>
> --- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> > Hi Susantha,
> > You have changed the signature of the signature of Stub constructor
from:
> > Stub(const char *pcEndPointUri) to
> > Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
> >
> > This has made the stubBase test case in tesst forlder fail to
compile.
> >
> > I tried to get the test working, however you have not documented
the
eProtocol parameter,
> > and
> > I find it difficult to find what parameter values I should be passing.
> >
> > Could you please document the parameter.
> >
> > Also, is it a must to specify a protocol? cant we assume a default?
> >
> > Samisa...
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Take Yahoo! Mail with you! Get it on your mobile phone.
> > http://mobile.yahoo.com/maildemo
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
Re: Stub class changes
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Guys, design changes like this should be proposed/explained
*before* they're implemented .. that would've prevented this
kind of problems.
Sanjiva.
----- Original Message -----
From: "Samisa Abeysinghe" <sa...@yahoo.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Monday, June 21, 2004 9:43 AM
Subject: Re: Stub class changes
> Hi Susantha,
> I set the default parameter value of eProtocol to be HTTP.
>
> Now I get yet another problem. You have shifted the logic of creating
the header block to Call
> class. Now the Stub test case that I have written fails. See the stack
trace below.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075313920 (LWP 4902)]
> 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50,
pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
> 580 return (m_pIWSSZ->createHeaderBlock (pachLocalName, pachUri));
> Current language: auto; currently c++
> (gdb) bt
> #0 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50,
pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
> #1 0x4005cfd2 in Stub::createSOAPHeaderBlock(char*, char*)
(this=0xbfffe7f0,
> pachLocalName=0x804a9aa "TestHeader",
> pachUri=0x804cd50 "�\t@") at Stub.cpp:178
> #2 0x08048ee0 in strcpy ()
> #3 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
> (gdb)
>
> Earlier logic was working. But the new logic of yours is giving
problems.
> Could you please fix this.
> Thanks,
> Samisa...
>
>
>
>
> --- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> > Hi Susantha,
> > You have changed the signature of the signature of Stub constructor
from:
> > Stub(const char *pcEndPointUri) to
> > Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
> >
> > This has made the stubBase test case in tesst forlder fail to
compile.
> >
> > I tried to get the test working, however you have not documented the
eProtocol parameter,
> > and
> > I find it difficult to find what parameter values I should be passing.
> >
> > Could you please document the parameter.
> >
> > Also, is it a must to specify a protocol? cant we assume a default?
> >
> > Samisa...
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Take Yahoo! Mail with you! Get it on your mobile phone.
> > http://mobile.yahoo.com/maildemo
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
Re: Stub class changes
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
I am unable to create header blocks. The stub fails. This functioanlity was tested by me two weeks
ago and it was working without problems. I think Roshan tested as well.
Unfortunately moving the logic to Call class has made the functionality not to work. I am
disaapointed for the third time that working pice of code that I wrote has been made non
functional due to changes done over them.
I thought there is some unit testing in place to make sure the changes are working, before
commiting them. I am using Linux platform. Is it working on windows at least? (I do not think so.)
Samisa...
--- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> Hi Susantha,
> I set the default parameter value of eProtocol to be HTTP.
>
> Now I get yet another problem. You have shifted the logic of creating the header block to
> Call
> class. Now the Stub test case that I have written fails. See the stack trace below.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075313920 (LWP 4902)]
> 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50, pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
> 580 return (m_pIWSSZ->createHeaderBlock (pachLocalName, pachUri));
> Current language: auto; currently c++
> (gdb) bt
> #0 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50, pachLocalName=0x804a9aa
> "TestHeader",
> pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
> #1 0x4005cfd2 in Stub::createSOAPHeaderBlock(char*, char*) (this=0xbfffe7f0,
> pachLocalName=0x804a9aa "TestHeader",
> pachUri=0x804cd50 "�\t@") at Stub.cpp:178
> #2 0x08048ee0 in strcpy ()
> #3 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
> (gdb)
>
> Earlier logic was working. But the new logic of yours is giving problems.
> Could you please fix this.
> Thanks,
> Samisa...
>
>
>
>
> --- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> > Hi Susantha,
> > You have changed the signature of the signature of Stub constructor from:
> > Stub(const char *pcEndPointUri) to
> > Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
> >
> > This has made the stubBase test case in tesst forlder fail to compile.
> >
> > I tried to get the test working, however you have not documented the eProtocol parameter,
> > and
> > I find it difficult to find what parameter values I should be passing.
> >
> > Could you please document the parameter.
> >
> > Also, is it a must to specify a protocol? cant we assume a default?
> >
> > Samisa...
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Take Yahoo! Mail with you! Get it on your mobile phone.
> > http://mobile.yahoo.com/maildemo
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Re: Stub class changes
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Susantha,
I set the default parameter value of eProtocol to be HTTP.
Now I get yet another problem. You have shifted the logic of creating the header block to Call
class. Now the Stub test case that I have written fails. See the stack trace below.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075313920 (LWP 4902)]
0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50, pachLocalName=0x804a9aa
"TestHeader",
pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
580 return (m_pIWSSZ->createHeaderBlock (pachLocalName, pachUri));
Current language: auto; currently c++
(gdb) bt
#0 0x4005b998 in Call::createHeaderBlock(char*, char*) (this=0x804cd50, pachLocalName=0x804a9aa
"TestHeader",
pachUri=0x804a760 "http://ws.apache.org/axisCppTest/") at Call.cpp:580
#1 0x4005cfd2 in Stub::createSOAPHeaderBlock(char*, char*) (this=0xbfffe7f0,
pachLocalName=0x804a9aa "TestHeader",
pachUri=0x804cd50 "�\t@") at Stub.cpp:178
#2 0x08048ee0 in strcpy ()
#3 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb)
Earlier logic was working. But the new logic of yours is giving problems.
Could you please fix this.
Thanks,
Samisa...
--- Samisa Abeysinghe <sa...@yahoo.com> wrote:
> Hi Susantha,
> You have changed the signature of the signature of Stub constructor from:
> Stub(const char *pcEndPointUri) to
> Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
>
> This has made the stubBase test case in tesst forlder fail to compile.
>
> I tried to get the test working, however you have not documented the eProtocol parameter,
> and
> I find it difficult to find what parameter values I should be passing.
>
> Could you please document the parameter.
>
> Also, is it a must to specify a protocol? cant we assume a default?
>
> Samisa...
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Stub class changes
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Susantha,
You have changed the signature of the signature of Stub constructor from:
Stub(const char *pcEndPointUri) to
Stub(const char *pcEndPointUri, AXIS_PROTOCOL_TYPE eProtocol)
This has made the stubBase test case in tesst forlder fail to compile.
I tried to get the test working, however you have not documented the eProtocol parameter, and
I find it difficult to find what parameter values I should be passing.
Could you please document the parameter.
Also, is it a must to specify a protocol? cant we assume a default?
Samisa...
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Re: RFE: axis c++ engine tracing
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
John Hawkins wrote:
>
>
>Sounds a good idea. However, this must be internationalised.
>
>There are two considerations here:
>
>Debug Tracing - this is purely for developers to understand what went
>wrong. This is not something that should done lightly - if we do this then
>we should do it properly i.e. put in entry/exit trace everywhere or nowhere
>- there is nothing worse than dong a half job of trace ! Because this is
>for developers only there is no need to internationalise this.
>
>
that is what i wanted: trace dispatching and execution of SOAP message.
>Informational "messages". I have to say that I think we would have very
>little, if any, of these?
>
agreed
>Most/all of our messages are, hopefully, now
>exceptions. In which case, at the client-side, it would be up to the
>application writer to catch the exceptions and translate them to their
>language as suitable. The chances are they would want to alter/wrap the
>exceptions into their own format anyway. I think we should avoid putting in
>any informational messages at the client, if at all possible. Perhaps on
>the server side there is need for a "starting Axis server", "Stopping Axis
>server" message
>
yes.
>There are plenty of opensource pkgs out there that do internationalisation
>and logging. I would point you towards this one -
>http://oss.software.ibm.com/icu/ - which we've looked at before (oh, it
>happens to come from IBM too ;-)
>
>
:) isnt it very complicated?
>Now, going onto another favuorite topic of mine Aspect orientation. It
>would be possible to make entry and exit trace an aspect and apply it at
>build time ! This would mean, if we needed to change the trace (for
>whatever reason) in the future we would just change the aspect. It also
>means that we can keep the codebase easier to work with and avoid people
>having to swim through the trace to find the functional code. I don't know
>how good aspect C is now adays but I'm sure it would be up to this simple
>job (aspect people always cite entry and exit trace as their samples!)
>
>
>
i am not that big on tracing entry/exit but more interested to add some
tracing/logging of key data/control points such as decision to what
service message is dispatched (or dropped). i spent hours debugging this
in AXIS-C++ and if we could save time for future developers working with
AXIS-C++ ...
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: RFE: axis c++ engine tracing
Posted by John Hawkins <HA...@uk.ibm.com>.
Sounds a good idea. However, this must be internationalised.
There are two considerations here:
Debug Tracing - this is purely for developers to understand what went
wrong. This is not something that should done lightly - if we do this then
we should do it properly i.e. put in entry/exit trace everywhere or nowhere
- there is nothing worse than dong a half job of trace ! Because this is
for developers only there is no need to internationalise this.
Informational "messages". I have to say that I think we would have very
little, if any, of these? Most/all of our messages are, hopefully, now
exceptions. In which case, at the client-side, it would be up to the
application writer to catch the exceptions and translate them to their
language as suitable. The chances are they would want to alter/wrap the
exceptions into their own format anyway. I think we should avoid putting in
any informational messages at the client, if at all possible. Perhaps on
the server side there is need for a "starting Axis server", "Stopping Axis
server" message but that'll be it won't it? (Perhaps a "Axis server has
died horribly" message as well? :-( But other than that I can't see the
need for spewing out a load of messages on the server either?
There are plenty of opensource pkgs out there that do internationalisation
and logging. I would point you towards this one -
http://oss.software.ibm.com/icu/ - which we've looked at before (oh, it
happens to come from IBM too ;-)
Now, going onto another favuorite topic of mine Aspect orientation. It
would be possible to make entry and exit trace an aspect and apply it at
build time ! This would mean, if we needed to change the trace (for
whatever reason) in the future we would just change the aspect. It also
means that we can keep the codebase easier to work with and avoid people
having to swim through the trace to find the functional code. I don't know
how good aspect C is now adays but I'm sure it would be up to this simple
job (aspect people always cite entry and exit trace as their samples!)
John Hawkins
Aleksander
Slominski
<aslom@cs.indiana To
.edu> Apache AXIS C Developers List
<ax...@ws.apache.org>
17/06/2004 10:38 cc
Subject
Please respond to RFE: axis c++ engine tracing
"Apache AXIS C
Developers List"
hi,
filed it under http://issues.apache.org/jira/browse/AXISCPP-100
i think it would be good to have some kind of tracing/logging compiled
into binary that could be triggered by setting environment variable (for
example AXISCPP_TRACE=engine:ALL).
it would be very useful tool when debugging such problems like wrong
SOAPAction to see if engine received request and see where did it go and
why it was rejected.
any comments? is it alredy possible?
in particular i had to add this (now ocmmented out) to WSDDService.cpp
to track the problem - if i could use tracer/logger intead of printf it
would be great:
diff -u -r1.21 WSDDService.cpp
--- WSDDService.cpp 26 Apr 2004 04:04:39 -0000 1.21
+++ WSDDService.cpp 17 Jun 2004 09:37:28 -0000
@@ -100,8 +100,10 @@
bool WSDDService::isAllowedMethod(const AxisChar* sServiceName) const
{
list<AxisString>::const_iterator iter;
+ //printf("ALEK:::: service name=%s\n", sServiceName);
for(iter = m_AllowedMethods.begin();iter !=
m_AllowedMethods.end();iter++)
{
+ //printf("ALEK::: *iter %s\n", *iter);
if((*iter) == sServiceName)
{
return true;
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay