Nabble - WSO2 WSF/C Development

[Notice] WSO2 Oxygentank Mailing List Re-organization

2009-08-26T05:16:54Z

Notice: WSO2 Oxygentank Mailing List Re-organization

Hi all,

We are reorganizing the set of wso2.org mailing lists, in order to leverage the power of open source community aspect even further around the Oxygen Tank. Hence we will merge this list, along with several others, into wsf-dev@.... The key benefit is that, you will get a wider exposure to the WSO2 SOA Platform with wsf-dev@... list as opposed to a single product view that this list was covering. You will be automatically subscribed to this new list. If you wish to unsubscribe, please follow the instructions at wso2.org/mail.

Thank you,
The WSO2 Oxygen Tank Team

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://mail.wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Resolved: (WSFCPP-75) Generate VC projects with different names for clients and services

2009-08-25T00:54:01Z

[ https://wso2.org/jira/browse/WSFCPP-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana resolved WSFCPP-75.
---------------------------------------

Resolution: Fixed

Fixed the issue in the svn trunk

> Generate VC projects with different names for clients and services
> ------------------------------------------------------------------
>
> Key: WSFCPP-75
> URL: https://wso2.org/jira/browse/WSFCPP-75
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: Any
> Reporter: Nandika Jayawardana
> Assignee: Nandika Jayawardana
> Fix For: 2.1.0
>
>
> Currently the vc project generated from the codegen tool generate the project with the same name for client and service. If both client and service is generated, one project file get replaced.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Assigned: (WSFCPP-75) Generate VC projects with different names for clients and services

2009-08-25T00:52:01Z

[ https://wso2.org/jira/browse/WSFCPP-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana reassigned WSFCPP-75:
-----------------------------------------

Assignee: Nandika Jayawardana (was: Uthaiyashankar)

[jira] Created: (WSFPHP-407) WSFault::getMessage() should return WSFault::Reason

2009-08-25T00:09:00Z

WSFault::getMessage() should return WSFault::Reason
---------------------------------------------------

Key: WSFPHP-407
URL: https://wso2.org/jira/browse/WSFPHP-407
Project: WSO2 WSF/PHP
Issue Type: Improvement
Components: WSFault
Affects Versions: 2.0.0
Reporter: alexey baranov

regular use of try-catch construction is

try (
)
catch (Exception $ e) (
/ / use of $ e-> getMessage()
)

with WSFault method getMessage() always returns an empty string, and accounted for in all places, which used the WSO to use the expanded structure to achieve the same result

try (
)
catch (WSFault $ e) (
/ / use of $ e-> __toString()
)
catch (Exception $ e) (
/ / repeat the previous code block, using $ e-> getMessage()
)

this is very inconvenient. could you sell in the following releases WSFault::getMessage() as
function getMessage(){
return $this->Reason;
}
thanks

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Resolved: (WSFPHP-406) The error exception message 'request payload should not be null ; should be changed to a more meaningful error message

2009-08-24T11:34:00Z

[ https://wso2.org/jira/browse/WSFPHP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana resolved WSFPHP-406.
----------------------------------------

Resolution: Fixed

Fixed in the current svn

> The error exception message 'request payload should not be null ; should be changed to a more meaningful error message
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: WSFPHP-406
> URL: https://wso2.org/jira/browse/WSFPHP-406
> Project: WSO2 WSF/PHP
> Issue Type: Improvement
> Environment: any
> Reporter: Nandika Jayawardana
> Assignee: Nandika Jayawardana
>
> When an incorrect xml message with a single element is set as the payload element, the output from wsf/php is request payload should not be null . This should be changed to a more meaningful error message.

[jira] Assigned: (WSFPHP-406) The error exception message 'request payload should not be null ; should be changed to a more meaningful error message

2009-08-24T11:32:02Z

[ https://wso2.org/jira/browse/WSFPHP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana reassigned WSFPHP-406:
------------------------------------------

Assignee: Nandika Jayawardana

[jira] Created: (WSFPHP-406) The error exception message 'request payload should not be null ; should be changed to a more meaningful error message

2009-08-24T05:28:00Z

The error exception message 'request payload should not be null ; should be changed to a more meaningful error message
----------------------------------------------------------------------------------------------------------------------

Key: WSFPHP-406
URL: https://wso2.org/jira/browse/WSFPHP-406
Project: WSO2 WSF/PHP
Issue Type: Improvement
Environment: any
Reporter: Nandika Jayawardana

When an incorrect xml message with a single element is set as the payload element, the output from wsf/php is request payload should not be null . This should be changed to a more meaningful error message.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFPHP-405) Improvement Exceptions handling

2009-08-24T05:23:00Z

Improvement Exceptions handling
-------------------------------

Key: WSFPHP-405
URL: https://wso2.org/jira/browse/WSFPHP-405
Project: WSO2 WSF/PHP
Issue Type: Improvement
Components: WSClient, WSDL Generation , WSDL Mode, WSService
Affects Versions: 2.0.0
Reporter: alexey baranov

When you call a non-existent address service does not thrown any exceptions. It is bad style.

For example the following cod does not produse any warning or exception.

$wsclient = new WSClient( array(
"wsdl" => "ExamResult.wsdl",
"to" => "http://localhost/INVALIDE_SERVICE_URL.php")); //INVALIDE URL

$proxy = $wsclient->getProxy();

$ret_val = $proxy->INVALIDE_OPERATION_NAME(array("studentName" => "Hiro", //INVALIDE OPERATION NAME
"subject" => "Maths",
"year" => 2007,
"semester" => "2"));

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFPHP-404) WSClient - XSLTProcessor::transformToDoc() - A potential infinite template recursion was detected

2009-08-24T05:09:00Z

WSClient - XSLTProcessor::transformToDoc() - A potential infinite template recursion was detected
--------------------------------------------------------------------------------------------------

Key: WSFPHP-404
URL: https://wso2.org/jira/browse/WSFPHP-404
Project: WSO2 WSF/PHP
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Fedora Core 9, PHP 5.2.9, Apache 2.2.9,
Reporter: Plamen Mishev
Priority: High

here is the code I use to connect to a WS:

$url = 'http://ws.spexlive.net/service/soap/catalog?wsdl&appId=223284';
$options = array (
'useSOAP' => '1.2',
'HTTPMethod' => 'POST',
'useMTOM' => 1,
'responseXOP' => 1,
'wsdl' => $url,
);

$client = new WSClient($options);
$proxy = $client->getProxy();
$proxy->GetVersion(); // in the SpexLive documentation GetVersion() function does not take any parameters

and I have this warnings :

Warning: XSLTProcessor::transformToDoc() [xsltprocessor.transformtodoc]: xsltApplyXSLTTemplate: A potential infinite template recursion was detected.
You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000). in /usr/share/pear/wso2_wsf_php/scripts/dynamic_invocation/wsf_wsdl_util.php on line 188

Warning: XSLTProcessor::transformToDoc() [xsltprocessor.transformtodoc]: #1 name complex-param in /usr/share/pear/wso2_wsf_php/scripts/dynamic_invocation/wsf_wsdl_util.php on line 188

And this warnings repeat for hundreds of time before I terminate the script.
As far as I figured what happens WSClient Proxy can not parse (if this is the right term) the wsdl supplied by SpexLive.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFCPP-75) Generate VC projects with different names for clients and services

2009-08-23T09:45:00Z

Generate VC projects with different names for clients and services
------------------------------------------------------------------

Key: WSFCPP-75
URL: https://wso2.org/jira/browse/WSFCPP-75
Project: WSO2 WSF/C++
Issue Type: Improvement
Affects Versions: 2.0.0
Environment: Any
Reporter: Nandika Jayawardana
Assignee: Uthaiyashankar
Fix For: 2.1.0

Currently the vc project generated from the codegen tool generate the project with the same name for client and service. If both client and service is generated, one project file get replaced.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFPHP-403) Use of lambda (create_function return) functions causes WSService to allocate 1.6 gigs of ram

2009-08-21T13:16:00Z

Use of lambda (create_function return) functions causes WSService to allocate 1.6 gigs of ram
---------------------------------------------------------------------------------------------

Key: WSFPHP-403
URL: https://wso2.org/jira/browse/WSFPHP-403
Project: WSO2 WSF/PHP
Issue Type: Bug
Components: WSService
Affects Versions: 2.0.0
Environment: * Apache/2.2.8 (Ubuntu) PHP/5.2.9-0.dotdeb.2 with Suhosin-Patch
* with XCache v1.2.1, Copyright (c) 2005-2007, by mOo
* suhosin patch 0.9.7
* wso2-wsf-php-src-2.0.0 (compiled from source on ubuntu fresh from the tarball)

WSF Info:
Directive Local Value Master Value
wsf.attachment_cache_dir /tmp /tmp
wsf.enable_attachment_caching 1 1
wsf.home no value no value
wsf.log_level 4 4
wsf.log_path /tmp /tmp
wsf.rm_db_dir /tmp /tmp
Reporter: Aaron Stewart
Priority: High

Hey all,

I'm trying to wrap WSService in a drupal module for use in creating a soap endpoint available to applications. Ultimately I'm hoping this will extend the services module, but right now I'm running into an interesting scenario.

When I invoke the service as follows, it works fine:

function testme($foo) {
error_log('o hai');
}

$server = new WSService('operations' => array('testme' => 'testme'));

However, when I return the function name as defined by create_function, eg (code abridged fro readability):

function _wsf_soap_call_wrapper($method, $args) {
error_log("Got $method");
}

$arglist = array('foo');
$method = 'myfoo';
$function_name = create_function(implode(',', $arglist), 'return _wsf_soap_call_wrapper(\'' . $method . '\', func_get_args());');
$server = new WSService('operations' => array('testme' => $function_name));

I get this error:

Fatal error: Allowed memory size of 188743680 bytes exhausted (tried to allocate 1680204321 bytes) in /home/acs/develop/wsf_server/wsf_server.module on line 58

I'm wondering if there's an issue with the way that WSService is fetching the internal php function table.

The code above should do fine to reproduce the bug.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFCPP-74) Using xml2 instead of guththila doesn't build due to dependency on guththila

2009-08-19T10:39:00Z

Using xml2 instead of guththila doesn't build due to dependency on guththila
----------------------------------------------------------------------------

Key: WSFCPP-74
URL: https://wso2.org/jira/browse/WSFCPP-74
Project: WSO2 WSF/C++
Issue Type: Bug
Components: Build System - Unix/Linux
Affects Versions: Current (Nightly)
Environment: Suse Linux Enterprise Server (SLES) 9 (x86_64) - Kernel: 2.6.5-7.311-smp

Reporter: Harald Eiermann
Assignee: Uthaiyashankar

WSO2 C++ is configured to use libxml2 instead of guththila.
But there seems to be a direct dependency on ../../../../../axiom/src/parser/guththila/libaxis2_parser.la:

gcc -DHAVE_CONFIG_H -I. -I. -I../../../../.. -I../../../../../include -I../../../../../src/core/engine -I../../../../../util/include -I../../../../../axiom/include -I/users/q4de3tsy926/user3/heierma1/usr/include -I/users/q4de3tsy926/user3/heierma1/usr/include/openssl -g -O2 -D_LARGEFILE64_SOURCE -ansi -Wall -Wno-implicit-function-declaration -g -D_GNU_SOURCE -I/users/q4de3tsy926/user3/heierma1/usr/include/libxml2 -DAXIS2_SVR_MULTI_THREADED -DAXIS2_SSL_ENABLED -MT http_transport_utils.lo -MD -MP -MF .deps/http_transport_utils.Tpo -c http_transport_utils.c -o http_transport_utils.o >/dev/null 2>&1
gmake[8]: *** No rule to make target `../../../../../axiom/src/parser/guththila/libaxis2_parser.la', needed by `libaxis2_http_util.la'. Stop.
gmake[8]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c/src/core/transport/http/util'
gmake[7]: *** [all-recursive] Error 1
gmake[7]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c/src/core'
gmake[6]: *** [all-recursive] Error 1
gmake[6]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c/src'
gmake[5]: *** [all-recursive] Error 1
gmake[5]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c'
gmake[4]: *** [all] Error 2
gmake[4]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod/wsf_c'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/users/q4de3tsy926/user3/heierma1/wso2-wsf-cpp-src-snapshot.mod'

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFCPP-73) configure fails when pkg-config executable doesn't exist and --enable-xml2 is used

2009-08-19T10:26:00Z

configure fails when pkg-config executable doesn't exist and --enable-xml2 is used
----------------------------------------------------------------------------------

Key: WSFCPP-73
URL: https://wso2.org/jira/browse/WSFCPP-73
Project: WSO2 WSF/C++
Issue Type: Bug
Components: Build System - Unix/Linux
Affects Versions: Current (Nightly)
Environment: Suse Linux Enterprise Server (SLES) 9 (x86_64) - Kernel: 2.6.5-7.311-smp

Reporter: Harald Eiermann
Assignee: Uthaiyashankar

On our system pkg-config is not installed.
Additionally the libxml2 shall be used. Therefore the command
( PKG_CONFIG="no" CPPFLAGS="-I$HOME/usr/include -I$HOME/usr/include/openssl" LDFLAGS="-L/users/q4de3tsy926/user3/heierma1/usr/lib" PARSER_CFLAGS="-I/users/q4de3tsy926/user3/heierma1/usr/include/libxml2" LIBXML2_CFLAGS="-I/users/q4de3tsy926/user3/heierma1/usr/include/libxml2" LIBXML2_LIBS="-L/users/q4de3tsy926/user3/heierma1/usr/lib -lxml2" PARSER_LIBS="-L/users/q4de3tsy926/user3/heierma1/usr/lib -lxml2" LIBXML2_CFLAGS="-I/users/q4de3tsy926/user3/heierma1/usr/include/libxml2" LIBXML2_LIBS="-L/users/q4de3tsy926/user3/heierma1/usr/lib -lxml2" ./configure --enable-libxml2 --prefix=$HOME/usr && make clean && make && make install ) 2>&1 |tee install.log

was issued to configure (having installed libxml2 and openssl locally in $HOME/usr).

Then the configure fails in the main directory as well as in wsf_c, wsf_c/axis2 and wsf_c/axis2/axiom

In all cases I was able to proceed configuring by modifying configure as follows:

--- wsf_c/configure 2009-08-19 11:26:32.000000000 +0200
+++ ../wso2-wsf-cpp-src-snapshot.mod/wsf_c/configure 2009-08-19 17:33:04.163640632 +0200
@@ -20030,7 +20030,7 @@
{ echo "$as_me:$LINENO: checking for PARSER" >&5
echo $ECHO_N "checking for PARSER... $ECHO_C" >&6; }

-if test -n "$PKG_CONFIG"; then
+if test -z "$PKG_CONFIG"; then
if test -n "$PARSER_CFLAGS"; then
pkg_cv_PARSER_CFLAGS="$PARSER_CFLAGS"
else
@@ -20048,7 +20048,7 @@
else
pkg_failed=untried
fi
-if test -n "$PKG_CONFIG"; then
+if test -z "$PKG_CONFIG"; then
if test -n "$PARSER_LIBS"; then
pkg_cv_PARSER_LIBS="$PARSER_LIBS"
else

--- wsf_c/axis2c/configure 2009-08-19 11:26:54.000000000 +0200
+++ ../wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c/configure 2009-08-19 17:34:37.810064553 +0200
@@ -20888,7 +20888,7 @@
{ echo "$as_me:$LINENO: checking for PARSER" >&5
echo $ECHO_N "checking for PARSER... $ECHO_C" >&6; }

-if test -n "$PKG_CONFIG"; then
+if test -z "$PKG_CONFIG"; then
if test -n "$PARSER_CFLAGS"; then
pkg_cv_PARSER_CFLAGS="$PARSER_CFLAGS"
else
@@ -20906,7 +20906,7 @@
else
pkg_failed=untried
fi
-if test -n "$PKG_CONFIG"; then
+if test -z "$PKG_CONFIG"; then
if test -n "$PARSER_LIBS"; then
pkg_cv_PARSER_LIBS="$PARSER_LIBS"
else

and

--- wsf_c/axis2c/axiom/configure 2009-08-19 11:27:48.000000000 +0200
+++ ../wso2-wsf-cpp-src-snapshot.mod/wsf_c/axis2c/axiom/configure 2009-08-19 17:39:46.539352772 +0200
@@ -20368,7 +20368,7 @@
{ echo "$as_me:$LINENO: checking for LIBXML2" >&5
echo $ECHO_N "checking for LIBXML2... $ECHO_C" >&6; }

-if test -n "$PKG_CONFIG"; then
+if test -z "$PKG_CONFIG"; then
if test -n "$LIBXML2_CFLAGS"; then
pkg_cv_LIBXML2_CFLAGS="$LIBXML2_CFLAGS"
else
@@ -20386,7 +20386,7 @@
else
pkg_failed=untried
fi
-if test -n "$PKG_CONFIG"; then
+if test -z "$PKG_CONFIG"; then
if test -n "$LIBXML2_LIBS"; then
pkg_cv_LIBXML2_LIBS="$LIBXML2_LIBS"
else

I don't know much about the auto... tools. So maybe there is some simple method to solve the issue...

Unfortunatley, compiling does not succeed afterwards as there is still a dependency to the guththila parser. Issue follows ...

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFPHP-402) Error when using Java client and https request

2009-08-19T08:17:00Z

Error when using Java client and https request
----------------------------------------------

Key: WSFPHP-402
URL: https://wso2.org/jira/browse/WSFPHP-402
Project: WSO2 WSF/PHP
Issue Type: Bug
Components: WSDL Mode
Affects Versions: 2.0.0
Environment: Client:
Java 1.5.0_20
Metro webservice library (v 1.5)
Server:
Linux 2.6.18-53.1.21.el5PAE
wso2 v2.0
Reporter: John Thorhauer
Attachments: wsf-wsdl-https.patch

I have manually applied the patch from bug WSFPHP-367. I am connecting the the webservice using Java/Metro and I get an error on the server side as follows when trying to call an operation:
ERROR:file_get_contents(http://jthor.yakabod.net:443/ws/BaseObjectService-1_0?wsdl) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed! <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> FILE:wsf_wsdl.php LINE:176 STACK:#0 WSErrorHandler::handle(2, file_get_contents(http://jthor.yakabod.net:443/ws/BaseObjectService-1_0?wsdl) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed! <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> , wsf_wsdl.php, 176, Array ([wsdl_url] => http://jthor.yakabod.net:443/ws/BaseObjectService-1_0?wsdl,[user_parameters] => Array ([wsdl] => http://jthor.yakabod.net:443/ws/BaseObjectService-1_0?wsdl,[serviceName] => BaseObjectService-1_0),[username] => ,[password] => ,[password_type] => ,[options] => ,[http_response_header] => Array

The problem appears to be that somewhere, not sure where, the wsdl url is getting set to http://jthor.yakabod.net:443/ (note there is no https). It seems that this call is happening in part of the C code somewhere. I have attached the patch that fixed this for me. Although this may be a problem at a deeper level than where I fixed it at.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Resolved: (WSFPHP-401) WSClient::getProxy() crashes with a fatal error if the service is not available

2009-08-19T03:08:00Z

[ https://wso2.org/jira/browse/WSFPHP-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana resolved WSFPHP-401.
----------------------------------------

Fix Version/s: Current (nightly)
Resolution: Fixed

Applied the patch. Also corrected the other call to file_get_contents function in the same file. Thanks for the patch.

> WSClient::getProxy() crashes with a fatal error if the service is not available
> -------------------------------------------------------------------------------
>
> Key: WSFPHP-401
> URL: https://wso2.org/jira/browse/WSFPHP-401
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Components: WSClient
> Affects Versions: 2.0.0
> Reporter: Lucas S. Bickel
> Assignee: Nandika Jayawardana
> Fix For: Current (nightly)
>
> Attachments: wso2-wsf-php-src-2.0.0-wsf_wsdl.php-receiver_fault_on_upstream_unavailable.patch
>
>
> If a WSDL file returns a 403 HTTP return value the following errors gets raised:
> <pre>
> PHP Warning: file_get_contents(http://localhost:8080/SearchService?wsdl) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
> in wsf_wsdl.php on line 176
> PHP Warning: DOMDocument::loadXML() [<a href='function.DOMDocument-loadXML'>function.DOMDocument-loadXML</a>]: Empty string supplied as input in wsf_wsdl.php on line 236
> PHP Fatal error: WSClient::getProxy() [<a href='function.WSClient-getProxy'>function.WSClient-getProxy</a>]: Error occurred in script: WSDL http://localhost:8080/ams.basis06.com/addresses/services/SearchService?wsdl could not be loaded. in /nexbyte/webstamp/program/include/address_service.inc on line 325
> </pre>
> The last fatal error then kills the php interpreter. I believe that this should return a WSFault("Receiver") Exception that i may then handle in my code. This also seems to be the problem described in http://wso2.org/forum/thread/5279
> As a fix i propose checking the results from the file_get_contents call in wsf_get_wsdl_str_from_url. This way the last warning can be replaced with a WSFault (we could even do schema validation on the wsdl at that stage!).
> Im adding a patch to this issue that fixes the problem by checking that the returned wsdl is not empty().

[jira] Assigned: (WSFPHP-401) WSClient::getProxy() crashes with a fatal error if the service is not available

2009-08-19T03:05:00Z

[ https://wso2.org/jira/browse/WSFPHP-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana reassigned WSFPHP-401:
------------------------------------------

Assignee: Nandika Jayawardana

> WSClient::getProxy() crashes with a fatal error if the service is not available
> -------------------------------------------------------------------------------
>
> Key: WSFPHP-401
> URL: https://wso2.org/jira/browse/WSFPHP-401
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Components: WSClient
> Affects Versions: 2.0.0
> Reporter: Lucas S. Bickel
> Assignee: Nandika Jayawardana
> Attachments: wso2-wsf-php-src-2.0.0-wsf_wsdl.php-receiver_fault_on_upstream_unavailable.patch
>
>
> If a WSDL file returns a 403 HTTP return value the following errors gets raised:
> <pre>
> PHP Warning: file_get_contents(http://localhost:8080/SearchService?wsdl) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
> in wsf_wsdl.php on line 176
> PHP Warning: DOMDocument::loadXML() [<a href='function.DOMDocument-loadXML'>function.DOMDocument-loadXML</a>]: Empty string supplied as input in wsf_wsdl.php on line 236
> PHP Fatal error: WSClient::getProxy() [<a href='function.WSClient-getProxy'>function.WSClient-getProxy</a>]: Error occurred in script: WSDL http://localhost:8080/ams.basis06.com/addresses/services/SearchService?wsdl could not be loaded. in /nexbyte/webstamp/program/include/address_service.inc on line 325
> </pre>
> The last fatal error then kills the php interpreter. I believe that this should return a WSFault("Receiver") Exception that i may then handle in my code. This also seems to be the problem described in http://wso2.org/forum/thread/5279
> As a fix i propose checking the results from the file_get_contents call in wsf_get_wsdl_str_from_url. This way the last warning can be replaced with a WSFault (we could even do schema validation on the wsdl at that stage!).
> Im adding a patch to this issue that fixes the problem by checking that the returned wsdl is not empty().

[jira] Created: (WSFPHP-401) WSClient::getProxy() crashes with a fatal error if the service is not available

2009-08-19T01:55:00Z

WSClient::getProxy() crashes with a fatal error if the service is not available
-------------------------------------------------------------------------------

Key: WSFPHP-401
URL: https://wso2.org/jira/browse/WSFPHP-401
Project: WSO2 WSF/PHP
Issue Type: Bug
Components: WSClient
Affects Versions: 2.0.0
Reporter: Lucas S. Bickel
Attachments: wso2-wsf-php-src-2.0.0-wsf_wsdl.php-receiver_fault_on_upstream_unavailable.patch

If a WSDL file returns a 403 HTTP return value the following errors gets raised:

<pre>
PHP Warning: file_get_contents(http://localhost:8080/SearchService?wsdl) [<a href='function.file-get-contents'>function.file-get-contents</a>]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
in wsf_wsdl.php on line 176
PHP Warning: DOMDocument::loadXML() [<a href='function.DOMDocument-loadXML'>function.DOMDocument-loadXML</a>]: Empty string supplied as input in wsf_wsdl.php on line 236
PHP Fatal error: WSClient::getProxy() [<a href='function.WSClient-getProxy'>function.WSClient-getProxy</a>]: Error occurred in script: WSDL http://localhost:8080/ams.basis06.com/addresses/services/SearchService?wsdl could not be loaded. in /nexbyte/webstamp/program/include/address_service.inc on line 325
</pre>

The last fatal error then kills the php interpreter. I believe that this should return a WSFault("Receiver") Exception that i may then handle in my code. This also seems to be the problem described in http://wso2.org/forum/thread/5279

As a fix i propose checking the results from the file_get_contents call in wsf_get_wsdl_str_from_url. This way the last warning can be replaced with a WSFault (we could even do schema validation on the wsdl at that stage!).

Im adding a patch to this issue that fixes the problem by checking that the returned wsdl is not empty().

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Created: (WSFCPP-72) Fix memory leaks from service skeleton invoke method.

2009-08-18T23:30:01Z

Fix memory leaks from service skeleton invoke method.
-----------------------------------------------------

Key: WSFCPP-72
URL: https://wso2.org/jira/browse/WSFCPP-72
Project: WSO2 WSF/C++
Issue Type: Bug
Affects Versions: 2.0.0
Environment: Linux/Windows
Reporter: Nandika Jayawardana
Assignee: Nandika Jayawardana
Fix For: 2.1.0

C++ Object OMElement is used for invoking the service operation and receive back the result. These elements are should be destroyed once the request handling is complete.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Commented: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-18T15:41:00Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28695#action_28695 ]

Russell Tempero commented on WSFCPP-71:
---------------------------------------

I just remembered that I am not defining the "xsi" name space on SOAP responses or checking for it on requests. This is probably something that will need to be cleaned up for a proper fix.

Russell

> Support polymorphism and circular reference in C++ parser generation
> --------------------------------------------------------------------
>
> Key: WSFCPP-71
> URL: https://wso2.org/jira/browse/WSFCPP-71
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: $ uname -a
> Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.2.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ javac -version
> javac 1.6.0_05
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
> Reporter: Russell Tempero
> Assignee: Nandika Jayawardana
> Priority: High
> Attachments: full_polly_support.2009.08.12.diff, full_poly_support.2009.08.12.svn.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.
> **************************************************************************************************************
> Issue 1:
> The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:
> #ifndef OBJECTTYPE1_H
> #define OBJECTTYPE1_H
> /**
> * various comments
> .
> .
> .
> */
> namespace <name_of_namespace> {
> class ObjectType1;
> }
> #include ObjectType2.h
> .
> .
> .
> A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.
> The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".
> FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432
> **************************************************************************************************************
> Issue 2:
> The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
> modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java
> You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.
> Off the top of my head, there are a couple areas of my changes that may need further attention.
> Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.
> Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.
> **************************************************************************************************************
> I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.
> Russell
> P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

[jira] Updated: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-18T09:57:00Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Russell Tempero updated WSFCPP-71:
----------------------------------

Attachment: full_poly_support.2009.08.12.svn.diff

Hi Nandika,

I have attached the requested SVN diff as full_poly_support.2009.08.12.svn.diff.

Please note that there are two important differences between this diff and the one that I attached previously. The first difference is that I fixed a problem with my previous changes where inherited fields were not returned in SOAP responses. The second difference is that I fixed a problem where my last set of changes did not support multi-level inheritance. For example: ObjectType3 extends ObjectType2 which extends ObjectType1.

Let me know if you notice any problems or if there are any ways that I can further assist you.

Thanks,
Russell

[jira] Commented: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-18T08:50:00Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28693#action_28693 ]

Nandika Jayawardana commented on WSFCPP-71:
-------------------------------------------

You can get the svn checkout of WSF/CPP using url http://wso2.org/repos/wso2/trunk/wsf/cpp or https://wso2.org/repos/wso2/trunk/wsf/cpp

Regards
Nandika

> Support polymorphism and circular reference in C++ parser generation
> --------------------------------------------------------------------
>
> Key: WSFCPP-71
> URL: https://wso2.org/jira/browse/WSFCPP-71
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: $ uname -a
> Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.2.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ javac -version
> javac 1.6.0_05
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
> Reporter: Russell Tempero
> Assignee: Nandika Jayawardana
> Priority: High
> Attachments: full_polly_support.2009.08.12.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.
> **************************************************************************************************************
> Issue 1:
> The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:
> #ifndef OBJECTTYPE1_H
> #define OBJECTTYPE1_H
> /**
> * various comments
> .
> .
> .
> */
> namespace <name_of_namespace> {
> class ObjectType1;
> }
> #include ObjectType2.h
> .
> .
> .
> A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.
> The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".
> FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432
> **************************************************************************************************************
> Issue 2:
> The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
> modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java
> You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.
> Off the top of my head, there are a couple areas of my changes that may need further attention.
> Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.
> Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.
> **************************************************************************************************************
> I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.
> Russell
> P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

[jira] Commented: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-18T07:13:01Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28691#action_28691 ]

Russell Tempero commented on WSFCPP-71:
---------------------------------------

Sure. What is the URL for the SVN repository for wsdl2cpp? I poked around a bit on the site but couldn't seem to come up with a repository URL.

Russell

> Support polymorphism and circular reference in C++ parser generation
> --------------------------------------------------------------------
>
> Key: WSFCPP-71
> URL: https://wso2.org/jira/browse/WSFCPP-71
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: $ uname -a
> Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.2.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ javac -version
> javac 1.6.0_05
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
> Reporter: Russell Tempero
> Assignee: Nandika Jayawardana
> Priority: High
> Attachments: full_polly_support.2009.08.12.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.
> **************************************************************************************************************
> Issue 1:
> The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:
> #ifndef OBJECTTYPE1_H
> #define OBJECTTYPE1_H
> /**
> * various comments
> .
> .
> .
> */
> namespace <name_of_namespace> {
> class ObjectType1;
> }
> #include ObjectType2.h
> .
> .
> .
> A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.
> The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".
> FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432
> **************************************************************************************************************
> Issue 2:
> The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
> modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java
> You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.
> Off the top of my head, there are a couple areas of my changes that may need further attention.
> Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.
> Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.
> **************************************************************************************************************
> I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.
> Russell
> P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

[jira] Commented: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-17T03:50:01Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28675#action_28675 ]

Nandika Jayawardana commented on WSFCPP-71:
-------------------------------------------

If possible, can you attach an svn patch.

> Support polymorphism and circular reference in C++ parser generation
> --------------------------------------------------------------------
>
> Key: WSFCPP-71
> URL: https://wso2.org/jira/browse/WSFCPP-71
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: $ uname -a
> Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.2.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ javac -version
> javac 1.6.0_05
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
> Reporter: Russell Tempero
> Assignee: Nandika Jayawardana
> Priority: High
> Attachments: full_polly_support.2009.08.12.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.
> **************************************************************************************************************
> Issue 1:
> The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:
> #ifndef OBJECTTYPE1_H
> #define OBJECTTYPE1_H
> /**
> * various comments
> .
> .
> .
> */
> namespace <name_of_namespace> {
> class ObjectType1;
> }
> #include ObjectType2.h
> .
> .
> .
> A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.
> The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".
> FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432
> **************************************************************************************************************
> Issue 2:
> The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
> modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java
> You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.
> Off the top of my head, there are a couple areas of my changes that may need further attention.
> Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.
> Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.
> **************************************************************************************************************
> I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.
> Russell
> P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

[jira] Assigned: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-17T03:08:01Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana reassigned WSFCPP-71:
-----------------------------------------

Assignee: Nandika Jayawardana (was: Uthaiyashankar)

> Support polymorphism and circular reference in C++ parser generation
> --------------------------------------------------------------------
>
> Key: WSFCPP-71
> URL: https://wso2.org/jira/browse/WSFCPP-71
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: $ uname -a
> Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.2.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ javac -version
> javac 1.6.0_05
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
> Reporter: Russell Tempero
> Assignee: Nandika Jayawardana
> Priority: High
> Attachments: full_polly_support.2009.08.12.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.
> **************************************************************************************************************
> Issue 1:
> The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:
> #ifndef OBJECTTYPE1_H
> #define OBJECTTYPE1_H
> /**
> * various comments
> .
> .
> .
> */
> namespace <name_of_namespace> {
> class ObjectType1;
> }
> #include ObjectType2.h
> .
> .
> .
> A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.
> The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".
> FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432
> **************************************************************************************************************
> Issue 2:
> The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
> modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java
> You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.
> Off the top of my head, there are a couple areas of my changes that may need further attention.
> Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.
> Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.
> **************************************************************************************************************
> I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.
> Russell
> P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

[jira] Resolved: (WSFPHP-367) request to a WSDL via https returns wrong scheme prefix

2009-08-16T21:13:00Z

[ https://wso2.org/jira/browse/WSFPHP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana resolved WSFPHP-367.
----------------------------------------

Fix Version/s: Current (nightly)
Resolution: Fixed

patch applied

> request to a WSDL via https returns wrong scheme prefix
> -------------------------------------------------------
>
> Key: WSFPHP-367
> URL: https://wso2.org/jira/browse/WSFPHP-367
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Components: WSDL Generation
> Affects Versions: 2.0.0
> Environment: Fedora 8 i386 Linux
> Reporter: Philip Eschenbacher
> Assignee: Nandika Jayawardana
> Fix For: Current (nightly)
>
> Attachments: https_wsdl.patch
>
>
> when requesting a wsdl via https URL the service destination URL still has a http scheme prefix. correct were the https prefix. Lets have a look to a little example:
> https://myservice/?wsdl
> returns the following WSDL target:
> ...
> <service name="myservice">
> <port name="myserviceSOAPPort_Http" binding="tns:myserviceSOAPBinding">
> <soap:address location="http://myservice:443/index.php"/>
> </port>
> </service>
> ...
> I provide a workaround patch with this ticket. This patch should not be applyed because it does not solve the problem very well. ws_generate_wsdl in wsf.php receives a request url without scheme prefix. so i had to decide by selecting the port number which scheme prefix to set. I think it would be bether to call the ws_generate_wsdl function and provide a valid request URL with scheme prefix like https://hostname/path... and then set this prefix instead of the WS_WSDL_HTTP_ATTR_NAME const.

[jira] Assigned: (WSFPHP-367) request to a WSDL via https returns wrong scheme prefix

2009-08-16T20:37:00Z

[ https://wso2.org/jira/browse/WSFPHP-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana reassigned WSFPHP-367:
------------------------------------------

Assignee: Nandika Jayawardana

> request to a WSDL via https returns wrong scheme prefix
> -------------------------------------------------------
>
> Key: WSFPHP-367
> URL: https://wso2.org/jira/browse/WSFPHP-367
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Components: WSDL Generation
> Affects Versions: 2.0.0
> Environment: Fedora 8 i386 Linux
> Reporter: Philip Eschenbacher
> Assignee: Nandika Jayawardana
> Attachments: https_wsdl.patch
>
>
> when requesting a wsdl via https URL the service destination URL still has a http scheme prefix. correct were the https prefix. Lets have a look to a little example:
> https://myservice/?wsdl
> returns the following WSDL target:
> ...
> <service name="myservice">
> <port name="myserviceSOAPPort_Http" binding="tns:myserviceSOAPBinding">
> <soap:address location="http://myservice:443/index.php"/>
> </port>
> </service>
> ...
> I provide a workaround patch with this ticket. This patch should not be applyed because it does not solve the problem very well. ws_generate_wsdl in wsf.php receives a request url without scheme prefix. so i had to decide by selecting the port number which scheme prefix to set. I think it would be bether to call the ws_generate_wsdl function and provide a valid request URL with scheme prefix like https://hostname/path... and then set this prefix instead of the WS_WSDL_HTTP_ATTR_NAME const.

[jira] Commented: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-12T22:34:02Z

[ https://wso2.org/jira/browse/WSFCPP-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28635#action_28635 ]

Nandika Jayawardana commented on WSFCPP-71:
-------------------------------------------

Thanks for attaching the patch. I will look into this and apply the patch.

> Support polymorphism and circular reference in C++ parser generation
> --------------------------------------------------------------------
>
> Key: WSFCPP-71
> URL: https://wso2.org/jira/browse/WSFCPP-71
> Project: WSO2 WSF/C++
> Issue Type: Improvement
> Affects Versions: 2.0.0
> Environment: $ uname -a
> Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 4.2.2
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ javac -version
> javac 1.6.0_05
> $ java -version
> java version "1.6.0_05"
> Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
> Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
> Reporter: Russell Tempero
> Assignee: Uthaiyashankar
> Priority: High
> Attachments: full_polly_support.2009.08.12.diff
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.
> **************************************************************************************************************
> Issue 1:
> The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:
> #ifndef OBJECTTYPE1_H
> #define OBJECTTYPE1_H
> /**
> * various comments
> .
> .
> .
> */
> namespace <name_of_namespace> {
> class ObjectType1;
> }
> #include ObjectType2.h
> .
> .
> .
> A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.
> The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".
> FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432
> **************************************************************************************************************
> Issue 2:
> The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
> modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
> modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
> modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java
> You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.
> Off the top of my head, there are a couple areas of my changes that may need further attention.
> Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.
> Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.
> **************************************************************************************************************
> I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.
> Russell
> P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

[jira] Created: (WSFCPP-71) Support polymorphism and circular reference in C++ parser generation

2009-08-12T11:52:00Z

Support polymorphism and circular reference in C++ parser generation
--------------------------------------------------------------------

Key: WSFCPP-71
URL: https://wso2.org/jira/browse/WSFCPP-71
Project: WSO2 WSF/C++
Issue Type: Improvement
Affects Versions: 2.0.0
Environment: $ uname -a
Linux clearwater 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version
gcc (GCC) 4.2.2
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ javac -version
javac 1.6.0_05

$ java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
Reporter: Russell Tempero
Assignee: Uthaiyashankar
Priority: High
Attachments: full_polly_support.2009.08.12.diff

There are actually fixes to two different problems contained in this patch. I apologize for submitting them together but it would have been difficult to split the changes apart.

**************************************************************************************************************
Issue 1:

The first issue is with circular references defined in a WSDL. If you define your WSDL in such a way that ObjectType1 contains a field of type ObjectType2 which in turn contains a field of type ObjectType1, you will get a build error with the code generated by the current C++ code generator. The simple fix that I used was to put a forward declaration of each class in the header file for that class before the include statements for *all* other header files. For example, the top of ObjectType1.h would appear as the following:

#ifndef OBJECTTYPE1_H
#define OBJECTTYPE1_H

/**
* various comments
.
.
.
*/

namespace <name_of_namespace> {
class ObjectType1;
}

#include ObjectType2.h
.
.
.

A more advanced solution might be to add code in the code generator to only add the forward declaration if it is needed. However, this would probably end up being rather complex and I'm not sure it would buy much except a negligibly faster compile time.

The changes in the included patch file that deal with this issue are for modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl and are labeled with "// rnt-mod: start: forward declaration for circular references".

FYI: one of my colleges submitted a similar fix for the circular reference problem to the Axis2 project for the C code generator: https://issues.apache.org/jira/browse/AXIS2-4432

**************************************************************************************************************
Issue 2:

The second issue has to do with polymorphism support in the generated code from a WSDL that uses <extension base="">. My changes to support polymorphism were rather extensive and included alterations of the following files:

modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateSource.xsl
modules/adb-codegen/src/org/apache/axis2/schema/template/CPPADBBeanTemplateHeader.xsl
modules/adb-codegen/src/org/apache/axis2/schema/BeanWriterMetaInfoHolder.java
modules/adb-codegen/src/org/apache/axis2/schema/SchemaCompiler.java
modules/adb-codegen/src/org/apache/axis2/schema/writer/CStructWriter.java
modules/adb-codegen/src/org/apache/axis2/schema/writer/CPPBeanWriter.java
modules/adb-codegen/src/org/apache/axis2/schema/writer/JavaBeanWriter.java
modules/adb-codegen/src/org/apache/axis2/schema/writer/BeanWriter.java

You will probably want to review my changes to make sure they are suitable for inclusion in the WSF/C++ project. I only checked to make sure these changes worked with our WSDL, so there may be a few things that I am not taking into account. There may also be a better way to accomplish some of the things I am trying to do with some of my changes.

Off the top of my head, there are a couple areas of my changes that may need further attention.

Area 1: In order for the parser to create an object that corresponds to the passed in xsi:type, I created a member function for each class called createByType(). This function does not take namespaces into account and assumes you only have one class defined with a certain name accross all namespaces. This may need to be fixed if dealing with larger, more complex WSDLs.

Area 2: In order for each class to be aware of the different subtypes of itself, I had to wait until all data types were processed in the WSDL before writing out the classes for those types. I did this by means of a java function called deferredWrite(). However, in order to make everything work, I had to make changes to the SchemaCompiler class as well as the CStructWriter, JavaBeanWriter and BeanWriter classes. Ideally, we should only be making changes to the CPPBeanWriter class because that is the code generator to which we are adding polymorphism support. I was going to attempt to resolve this issues and make changes in such a way that only the C++ code generator java code was affected. However, I looks like I won't have time to work on this myself. Let me know if there is anyway I can help out though.

**************************************************************************************************************

I hope that these changes will be useful for enhancing the WSF/C++ project. Let me know if there is anything more I can do to help.

Russell

P.S. There is also a change included in the diff to modules/codegen/src/org/apache/axis2/wsdl/template/cpp/SkelHeaderTemplate.xsl. This was to change angle brackets to quotes on include statements to resolve an issue with compiling the generated code. If this issue has not already been dealt with, please feel free to commit this change as well.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://wso2.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

[jira] Commented: (WSFPHP-400) PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+

2009-08-11T23:15:01Z

[ https://wso2.org/jira/browse/WSFPHP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28620#action_28620 ]

Nandika Jayawardana commented on WSFPHP-400:
--------------------------------------------

The niglity build seem to have an isssue and will be fixed. Will look in to it.

> PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+
> -----------------------------------------------------------------------------------------------------
>
> Key: WSFPHP-400
> URL: https://wso2.org/jira/browse/WSFPHP-400
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Affects Versions: 2.0.0
> Environment: CentOS 5.2 / Linux x86_64
> Reporter: Mike Reid
> Assignee: Nandika Jayawardana
> Priority: Highest
>
> All,
> WSF/PHP 2.0.0 is no longer compatible with PHP 5.3.0 :( Here is the list of the functions that were deprecated with this new release: http://php.net/manual/en/migration53.deprecated.php
> I have built from source and can confirm that WSF/PHP will need to be updated to support PHP 5.3
> In addition, here are the files containing references to the now deprecated functions:
> ereg() - ./scripts/wsdl2php/wsf_utils.php
> split() - ./scripts/dynamic_invocation/wsf_wsdl_util.php
> Updating these files alone does not solve this issue. Are there currently any efforts underway to restore functionality for this new PHP release?
> Kind Regards,
> Mike

[jira] Assigned: (WSFPHP-400) PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+

2009-08-11T23:13:00Z

[ https://wso2.org/jira/browse/WSFPHP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nandika Jayawardana reassigned WSFPHP-400:
------------------------------------------

Assignee: Nandika Jayawardana

[jira] Issue Comment Edited: (WSFPHP-400) PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+

2009-08-11T14:42:04Z

[ https://wso2.org/jira/browse/WSFPHP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28619#action_28619 ]

Mike Reid edited comment on WSFPHP-400 at 8/11/09 9:40 PM:
-----------------------------------------------------------

Thank you, Nandika. I have just downloaded from the SVN, the nightly build apparently hasn't been rebuilt in many months. I will let you know how it goes!

Also, is there anyway to determine in the SVN if the following patch has been applied to the source? https://www.wso2.org/jira/browse/WSFPHP-367

UPDATE:

When I try downloading from the SVN it seems my local "wsf_c" directory is incomplete? The wso2-wsf-php-src-2.0.0/ from wso2.org is 141MB (uncompressed), and my export from this SVN copy is only 5.9MB (uncompressed).

Not sure how to fix this to test from SVN?

was (Author: pixelchutes):
Thank you, Nandika. I have just downloaded from the SVN, the nightly build apparently hasn't been rebuilt in many months. I will let you know how it goes! Also, is there anyway to determine in the SVN if the following patch has been applied to the source? https://www.wso2.org/jira/browse/WSFPHP-367

> PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+
> -----------------------------------------------------------------------------------------------------
>
> Key: WSFPHP-400
> URL: https://wso2.org/jira/browse/WSFPHP-400
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Affects Versions: 2.0.0
> Environment: CentOS 5.2 / Linux x86_64
> Reporter: Mike Reid
> Priority: Highest
>
> All,
> WSF/PHP 2.0.0 is no longer compatible with PHP 5.3.0 :( Here is the list of the functions that were deprecated with this new release: http://php.net/manual/en/migration53.deprecated.php
> I have built from source and can confirm that WSF/PHP will need to be updated to support PHP 5.3
> In addition, here are the files containing references to the now deprecated functions:
> ereg() - ./scripts/wsdl2php/wsf_utils.php
> split() - ./scripts/dynamic_invocation/wsf_wsdl_util.php
> Updating these files alone does not solve this issue. Are there currently any efforts underway to restore functionality for this new PHP release?
> Kind Regards,
> Mike

[jira] Commented: (WSFPHP-400) PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+

2009-08-11T14:24:00Z

[ https://wso2.org/jira/browse/WSFPHP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28619#action_28619 ]

Mike Reid commented on WSFPHP-400:
----------------------------------

Thank you, Nandika. I have just downloaded from the SVN, the nightly build apparently hasn't been rebuilt in many months. I will let you know how it goes! Also, is there anyway to determine in the SVN if the following patch has been applied to the source? https://www.wso2.org/jira/browse/WSFPHP-367

> PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+
> -----------------------------------------------------------------------------------------------------
>
> Key: WSFPHP-400
> URL: https://wso2.org/jira/browse/WSFPHP-400
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Affects Versions: 2.0.0
> Environment: CentOS 5.2 / Linux x86_64
> Reporter: Mike Reid
> Priority: Highest
>
> All,
> WSF/PHP 2.0.0 is no longer compatible with PHP 5.3.0 :( Here is the list of the functions that were deprecated with this new release: http://php.net/manual/en/migration53.deprecated.php
> I have built from source and can confirm that WSF/PHP will need to be updated to support PHP 5.3
> In addition, here are the files containing references to the now deprecated functions:
> ereg() - ./scripts/wsdl2php/wsf_utils.php
> split() - ./scripts/dynamic_invocation/wsf_wsdl_util.php
> Updating these files alone does not solve this issue. Are there currently any efforts underway to restore functionality for this new PHP release?
> Kind Regards,
> Mike

[jira] Commented: (WSFPHP-400) PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+

2009-08-11T11:36:02Z

[ https://wso2.org/jira/browse/WSFPHP-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=28618#action_28618 ]

Nandika Jayawardana commented on WSFPHP-400:
--------------------------------------------

I only encounter one compilation issue while compiling on windows and it is fixed on the current svn trunk now. Also the above mentioned functions were replaced with compatible functions.

> PHP 5.3.0 Compatability Issues - WSF/PHP 2.0.0 errors and does not not function correctly on PHP 5.3+
> -----------------------------------------------------------------------------------------------------
>
> Key: WSFPHP-400
> URL: https://wso2.org/jira/browse/WSFPHP-400
> Project: WSO2 WSF/PHP
> Issue Type: Bug
> Affects Versions: 2.0.0
> Environment: CentOS 5.2 / Linux x86_64
> Reporter: Mike Reid
> Priority: Highest
>
> All,
> WSF/PHP 2.0.0 is no longer compatible with PHP 5.3.0 :( Here is the list of the functions that were deprecated with this new release: http://php.net/manual/en/migration53.deprecated.php
> I have built from source and can confirm that WSF/PHP will need to be updated to support PHP 5.3
> In addition, here are the files containing references to the now deprecated functions:
> ereg() - ./scripts/wsdl2php/wsf_utils.php
> split() - ./scripts/dynamic_invocation/wsf_wsdl_util.php
> Updating these files alone does not solve this issue. Are there currently any efforts underway to restore functionality for this new PHP release?
> Kind Regards,
> Mike

Re: savan_db_journal file

2009-08-11T05:24:36Z

This file gets created from the savan module. If you are not useing any features associated with savan [ WS-Eventing ] you can simply remove that module from modules folder and the savan related services from the services folder.

Regards

Nandika

On Tue, Aug 11, 2009 at 5:12 PM, John Thorhauer <jthorhauer@...> wrote:

Hi,

On one of our servers there is a file, /tmp/savan_db_journal that is
getting written to about 24 times every 10 seconds. Does anyone know
why that is and how I can turn it off?

Thanks,
John Thorhauer

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

--
Nandika Jayawardana
Technical Lead and Project Manager, WSO2 Inc
www.wso2.com "Open Source SOA Company"

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev

savan_db_journal file

2009-08-11T04:42:17Z

Hi,

On one of our servers there is a file, /tmp/savan_db_journal that is
getting written to about 24 times every 10 seconds. Does anyone know
why that is and how I can turn it off?

Thanks,
John Thorhauer

_______________________________________________
Wsf-c-dev mailing list
Wsf-c-dev@...
https://wso2.org/cgi-bin/mailman/listinfo/wsf-c-dev