Deserialization of arrays of complex elements with nil members
--
Key: AXISCPP-418
URL: http://issues.apache.org/jira/browse/AXISCPP-418
Project: Axis-C++
Type: Bug
Components: Deserialization
Versio
Programmatic configuration
--
Key: AXISCPP-426
URL: http://issues.apache.org/jira/browse/AXISCPP-426
Project: Axis-C++
Type: New Feature
Components: Configuration
Versions: future (enh)
Environment: all
Reporter: Tim Bartley
Multiple instances within a process
---
Key: AXISCPP-427
URL: http://issues.apache.org/jira/browse/AXISCPP-427
Project: Axis-C++
Type: New Feature
Components: Basic Architecture
Versions: future (enh)
Environment: all
[ http://issues.apache.org/jira/browse/AXISCPP-418?page=history ]
Tim Bartley updated AXISCPP-418:
Attachment: ComplexStore.wsdl
> Deserialization of arrays of complex elements with nil members
> --
[
http://issues.apache.org/jira/browse/AXISCPP-418?page=comments#action_59123 ]
Tim Bartley commented on AXISCPP-418:
-
Hmmm. The problem might be more severe than I thought. When paring my app down
to a simpler example I can't even get any elements
[ http://issues.apache.org/jira/browse/AXISCPP-418?page=history ]
Tim Bartley updated AXISCPP-418:
Attachment: axis.trace
> Deserialization of arrays of complex elements with nil members
> --
>
[ http://issues.apache.org/jira/browse/AXISCPP-418?page=history ]
Tim Bartley updated AXISCPP-418:
Attachment: axis2.trace
Ethereal trace corresponding to transaction generated by Complex2.wsdl.
> Deserialization of arrays of complex elements with nil m
[ http://issues.apache.org/jira/browse/AXISCPP-418?page=history ]
Tim Bartley updated AXISCPP-418:
Attachment: Complex2.wsdl
I think there may be two problems. The behaviour shown by the first wsdl I
attached seesm to be a different problem. The problem
Complex array member of object generated client stubs with compilation errors
-
Key: AXISCPP-431
URL: http://issues.apache.org/jira/browse/AXISCPP-431
Project: Axis-C++
Type: Bug
Components
[ http://issues.apache.org/jira/browse/AXISCPP-431?page=history ]
Tim Bartley updated AXISCPP-431:
Attachment: Complex2.wsdl
> Complex array member of object generated client stubs with compilation errors
> ---
[ http://issues.apache.org/jira/browse/AXISCPP-470?page=history ]
Tim Bartley updated AXISCPP-470:
Attachment: ArrayBean.cpp.patch
> Compiler warnings compiling src/common/ArrayBean.cpp
>
>
>
Compiler warnings compiling src/common/ArrayBean.cpp
Key: AXISCPP-470
URL: http://issues.apache.org/jira/browse/AXISCPP-470
Project: Axis-C++
Type: Bug
Versions: current (nightly)
Reporter: Tim Bartley
[
http://issues.apache.org/jira/browse/AXISCPP-431?page=comments#action_59645 ]
Tim Bartley commented on AXISCPP-431:
-
I have verified this in the current CVS. Do I close the issue or do you? I
don't know how.
> Complex array member of object gene
[
http://issues.apache.org/jira/browse/AXISCPP-418?page=comments#action_59650 ]
Tim Bartley commented on AXISCPP-418:
-
Thanks Samisa,
Unfortunately I see no change in behaviour.
The difference is maybe that the nil element is encoded as:
in you
Stub generation broken for nested array of simple type
--
Key: AXISCPP-510
URL: http://issues.apache.org/jira/browse/AXISCPP-510
Project: Axis-C++
Type: Bug
Components: Client - Stub
Versions: current (night
[ http://issues.apache.org/jira/browse/AXISCPP-510?page=history ]
Tim Bartley updated AXISCPP-510:
Attachment: Service.wsdl
ArrayOf_xsd_string.cpp
Actually better description would of data structure would be:
Complex {int, Complex { Arra
[ http://issues.apache.org/jira/browse/AXISCPP-511?page=history ]
Tim Bartley updated AXISCPP-511:
Attachment: Service2.wsdl
axis.trace
> Deserialization of complex nested arrays broken
> ---
>
Deserialization of complex nested arrays broken
---
Key: AXISCPP-511
URL: http://issues.apache.org/jira/browse/AXISCPP-511
Project: Axis-C++
Type: Bug
Components: Deserialization
Versions: current (nightly)
Env
[
http://issues.apache.org/jira/browse/AXISCPP-511?page=comments#action_60398 ]
Tim Bartley commented on AXISCPP-511:
-
This appears to be a bug in the stub code generated for deserializing arrays.
Stepping
through the deserialization the generic de
Response timeouts in addition to connection timeouts
Key: AXISCPP-526
URL: http://issues.apache.org/jira/browse/AXISCPP-526
Project: Axis-C++
Type: Improvement
Components: Transport (Client)
Versions: curre
Inter shared library exception handling broken on Linux
---
Key: AXISCPP-533
URL: http://issues.apache.org/jira/browse/AXISCPP-533
Project: Axis-C++
Type: Bug
Components: Basic Architecture
Versions: current
HTTPTransport::flushOutput should be declared throw(AxisException)
--
Key: AXISCPP-534
URL: http://issues.apache.org/jira/browse/AXISCPP-534
Project: Axis-C++
Type: Bug
Components: Transport (axis3)
Reference count initialize/terminate calls
--
Key: AXISCPP-557
URL: http://issues.apache.org/jira/browse/AXISCPP-557
Project: Axis-C++
Type: Bug
Components: Basic Architecture
Versions: current (nightly)
Reporte
[ http://issues.apache.org/jira/browse/AXISCPP-557?page=history ]
Tim Bartley updated AXISCPP-557:
Attachment: Axis.cpp.patch
> Reference count initialize/terminate calls
> --
>
> Key: AXISCPP-557
>
Gracefully handle server side close of persistant connection
Key: AXISCPP-558
URL: http://issues.apache.org/jira/browse/AXISCPP-558
Project: Axis-C++
Type: Bug
Components: Transport (axis3)
Reporter
[ http://issues.apache.org/jira/browse/AXISCPP-558?page=history ]
Tim Bartley updated AXISCPP-558:
Attachment: http.patch
> Gracefully handle server side close of persistant connection
>
>
>
Use proper synchronization mechanisms on Windows
Key: AXISCPP-559
URL: http://issues.apache.org/jira/browse/AXISCPP-559
Project: Axis-C++
Type: Improvement
Components: Basic Architecture
Environment: Windows
R
[ http://issues.apache.org/jira/browse/AXISCPP-559?page=history ]
Tim Bartley updated AXISCPP-559:
Attachment: SharedObject.patch
Again untested (but low risk once it compiles) - sorry - rushing to go on
vacation and wanted to get this raised.
> Use pr
SetSecure must be changed to use
---
Key: AXISCPP-560
URL: http://issues.apache.org/jira/browse/AXISCPP-560
Project: Axis-C++
Type: Bug
Components: Client - Stub
Versions: current (nightly)
Reporter: Tim Bartle
[
http://issues.apache.org/jira/browse/AXISCPP-559?page=comments#action_61188 ]
Tim Bartley commented on AXISCPP-559:
-
Note that without this fix multi-threaded Windows apps (client or server) will
not work reliably.
> Use proper synchronization m
[
http://issues.apache.org/jira/browse/AXISCPP-558?page=comments#action_62531 ]
Tim Bartley commented on AXISCPP-558:
-
Hi Fred,
I have to disagree strongly.
The application should never need to know about this condition - it is purely
an artifact
[
http://issues.apache.org/jira/browse/AXISCPP-533?page=comments#action_62625 ]
Tim Bartley commented on AXISCPP-533:
-
Hmmm. Unfortunate. I know that I *need* this flag. I'll investigate the test
programs and see if I can understand why use of this
32 matches
Mail list logo