What SOAP stub/proxy generation tools use Xerces C++ as XML parser?
Does anyone on the list use SOAP stubs/proxies in a C++ environment?
- URS C. MUFF
SOFTWARE ARCHITECT - RESEARCH LAB
QUARK INC.
[EMAIL PROTECTED] - X6360
+1 (303) 894 3360
CONFIDENTIALITY NOTICE
This e-mail transmissi
n of DOM, or is it to be used
> with the current underlying implementation?
>
> Khaled
>
> Urs Muff wrote:
>
> > Hi Khaled,
> >
> > That's exactly the point: no impact change. DOMNodePtr is defined in
> > DOMNode.h, and if you have ref counting on, it wi
Hi Khaled,
That's exactly the point: no impact change. DOMNodePtr is defined in
DOMNode.h, and if you have ref counting on, it will be a ref counted
pointer, and if ref counting is off, it's just a normal pointer. Once
changed the DOMWriterImpl will never have to change again, since the ref
coun
it might be good to have
> a
> > >> stable release for people to use sooner rather than later.
> >
> > Is this happening in 2.3. This will be a big boost to DOM which
> is
> a
> > memory hog. This would enable
> > users to spool DOM content to disk and not
Title: Bug 17945: Allow custom implementation of DOMNode interface to enable reference counting over nodes
Hi all,
Can somebody with CVS check in privileges please have a look at the change proposed, and tell me if it will be checked in for the next release?
If not, let's start a discussion
Hi,
The current implementation of Xerces is assuming that the complete document
is in memory at any given time. This is a gross oversimplification and does
not allow for other implementations to do otherwise. The main problem is
that pointers to nodes are returned and there is no way of knowing
There is a fundamental problem with this memory model. Imaging a DOM
emulation implementation, that is capable of reading terra byte XML files.
In the current model, if somebody is just walking the tree using
getFirstChild(), getNextSibling(), ... you can never dispose those DOMNodes
since you can
Hi Tinny,
Any status on the bugs mentioned?
- URS C. MUFF
SYSTEMS ARCHITECT - RESEARCH LAB
> -Original Message-
> From: James Berry [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 16, 2002 9:29 AM
> To: Urs Muff; Tinny Ng
> Cc: Xerces C Dev
> Subject:
James, please consider checking in #15106, and #15398, both have patches
available.
- URS C. MUFF
SYSTEMS ARCHITECT - RESEARCH LAB
> -Original Message-
> From: James Berry [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 15, 2002 8:08 AM
> To: Xerces C Dev
> Subject: Any more fil
Title: DOMNode destructor
Destructor should be hidden too, since it is not allowed to delete a DOMNode, since it is owned by the implementation. You have to call release() to dispose of the memory.
class CDOM_EXPORT DOMNode {
...
public:
//
>
>
> > Hi,
> > could you open a Bugzilla entry so we can keep track of this?
> >
> > thanks
> >
> > Gareth
> >
> >
> > On Mon, 2 Dec 2002, Urs Muff wrote:
> >
> > > /*
> > > * $Id: Wrapper4InputSource.hpp,v 1.5 2002/11/04
Title: Wrapper4InputSource does not work since get/set Encoding are not virtual on InputSource!
/*
* $Id: Wrapper4InputSource.hpp,v 1.5 2002/11/04 15:00:21 tng Exp $
*/
Implementing those functions in Wrapper4InputSource does not really help, since InputSource does not declare them virtua
> Would you mind expanding on why this is for a namespace newbie?
>
> Thanks, Scot Nielsen
>
>
> -Original Message-
> From: Urs Muff [mailto:umuff@;quark.com]
> Sent: 04 November 2002 22:22
> To: '[EMAIL PROTECTED]'
> Subject: RE: Proposal Review: Us
I couldn't agree more! It's a very bad idea to have ANY using namespace
clause in ANY header, since this goes completely against the point of
namespaces in the first place.
- URS C. MUFF
SYSTEMS ARCHITECT - RESEARCH LAB
[EMAIL PROTECTED] - X6360
+1 (303) 894 3360
> -Original M
The problem is the following:
If one DLL is allocating memory no other DLL including the main application
can free that memory. This is a general issue with all memory managers on
many platforms. The solution is to use a DLL version for the memory manager
[MSVCRTD.dll/MSVCRT.dll]. This only wor
Are there any known issues using the 1.7.0 version of Xerces on MacOS X
[Carbon] in combination with MSL_All_Carbon.Shlib that could cause a crash
in DOMStringData::removeRef when trying to delete [] this? I double
checked, if there are double disposals [no luck] and the string data looks
valid r
16 matches
Mail list logo
