You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Mark Whitlock <ma...@uk.ibm.com> on 2004/10/28 12:00:51 UTC
Fw: Header files
Hi,
Please change any private applications/testcases you may have to include
the Axis C++ external header files with the .hpp extension (*not* the .h
extension) since I am about to disable the .h external headers. I am also
making Attribute.hpp an internal header file. Applications should include
IAttribute.hpp instead.
Also wsdl2ws will not generate C stubs until 1.5.
Mark
Mark Whitlock
IBM
----- Forwarded by Mark Whitlock/UK/IBM on 28/10/2004 10:45 -----
Mark
Whitlock/UK/IBM@I
BMGB To
axis-c-dev@ws.apache.org
25/10/2004 14:02 cc
Subject
Please respond to Header files
"Apache AXIS C
Developers List"
I am about to start copying the external .h files to .hpp files. I won't
delete the .h files yet. If you explicitly include any header files in any
private testcases, please change them to .hpp, if they exist yet. If you
change any affected headers, please also change the .hpp file as well, but
if you forget, I'll copy your change across when I delete the .h file.
Mark
Mark Whitlock
IBM
----- Forwarded by Mark Whitlock/UK/IBM on 25/10/2004 13:37 -----
John
Hawkins/UK/IBM@IB
MGB To
"Apache AXIS C Developers List"
20/10/2004 13:21 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Process for renaming .h to .hpp
Developers List" [WAS Re: Fw: RE: Re: 1.3 release]
+1 !
Good approach :-)
John Hawkins
Mark
Whitlock/UK/IBM@I
BMGB To
axis-c-dev@ws.apache.org
20/10/2004 11:11 cc
Subject
Please respond to Process for renaming .h to .hpp
"Apache AXIS C [WAS Re: Fw: RE: Re: 1.3 release]
Developers List"
Hi Samisa,
I would prefer not to make one *massive* commit, renaming all the external
.h files, changing all the places where they are included and changing
wsdl2ws at the same time, since this is error prone and would require a
superhuman effort. Instead I would prefer to make the change incrementally
with small commits, making sure that the tests run all the time, never
breaking the product. So this is how I plan to do it...
1) Wait until 1.3 is shipped
2) Disable wsdl2ws from generating C artifacts (one line change)
3) Notify the mailing list of what I'm doing
4) Copy all the external .h files to .hpp files without removing C support
(so there are 2 identical copies committed in CVS)
5) Change all the includes throughout the product to include the .hpp
headers, committing incrementally
6) Change wsdl2ws to make the generated C++ artifacts include the .hpp
headers
7) Make the sure the .hpp headers are up to date by merging in any changes
that other committers have been making to the .h files
8) Replace the contents of the .h files with a suitable #error
9) Remove C support from the new .hpp files
10) Fix problems with the directory structure (client includes axis/server
headers, empty classes, etc)
11) A couple of weeks later remove the .h files completely
Mark
Mark Whitlock
IBM
----- Forwarded by Mark Whitlock/UK/IBM on 10/20/2004 10:11 AM -----
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
10/20/2004 02:44 <ax...@ws.apache.org>
AM cc
Subject
Please respond to Re: Fw: RE: Re: 1.3 release
"Apache AXIS C
Developers List"
Hi Mark,
Would you be changing C to C++ (including header changes) module by
module (e.g. one folder in
src at a time - engine, soap, xml etc.) and commit to CVS or would you do
all the changes and then
commit to the CVS at once?
Thanks,
Samisa...
--- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
>
>
>
> Once 1.3 has shipped I intend to remove all the C support. Then make the
> engine pure C++ which means changing all the mallocs/frees/strdups to
> news/deletes and changing structs to classes, where possible. I won't add
> in any STL strings to the external API, but I may use STL strings
> internally where it makes sense (e.g. AxisConfig.cpp). I will make it
clear
> in the API documentation who (Axis or the application) owns the storage
> that is returned from the Axis APIs, so it is easier for applications to
> avoid memory leaks. I will attempt to fix memory leaks in the engine, as
I
> review the lifecycle of these objects. There are a bunch of JIRAs that I
> hope to fix along the way such as 190, 191, 202 and 207.
>
> In 1.5, I will add back in C support. As was agreed in a previous thread,
> the new C support would be contained in separate header files, source
files
> and built into a separate library which C applications could link
against.
> The current C bindings for the dynamic client API are awkward for C
> programmers to use and need rework. I will discuss major changes on the
> mailing list to get general agreement.
>
> Samisa suggested, I agreed and no one disagreed that the C support should
> be in .h header files and the C++ support should be in .hpp files. So
after
> 1.3 is shipped I intend to rename the existing external C++ header files
to
> .hpp. So Call.h will become Call.hpp (without the C support in it). In
1.5
> Call.h will reappear as a C-only header file.
>
> I may create a "sandpit" branch so that I can try out the reworked C
> bindings before externalising them in 1.5. I am primarily focussing on
the
> client, but I need to make sure that I don't break the server as I go.
> Mark
> Mark Whitlock
> IBM
>
> ----- Forwarded by Mark Whitlock/UK/IBM on 10/19/2004 11:58 AM -----
>
> damitha@opensourc
> e.lk
>
To
> 10/19/2004 09:09 "Apache AXIS C Developers List"
> AM <ax...@ws.apache.org>
>
cc
>
> Please respond to
Subject
> "Apache AXIS C RE: Re: 1.3 release
> Developers List"
>
>
>
>
>
>
>
>
>
> Yes a rewriting would be easier. Practically it is very difficult to
merge
> back when there is lot of changes
>
> thanks
> damitha
>
> > I do not think that we would be able to branch 1.3 and then later
merger
> > with 1.5 on C stuff.
> >
> > This is because, with the proposed wrapper approach in 1.5 for C
support,
> > the API though which the
> > C client/services talk to the main engine would change considerably.
> Hence
> > I doubt the
> > possibilities of merging. Rather than try and merge, a rewrite would be
> > easier, I guess.
> >
> > Samisa...
> >
> > --- Farhaan Mohideen <fa...@opensource.lk> wrote:
> >
> >> Hi Mark;
> >>
> >> I was following your thread on cleaning up the engine code so as to
make
> >> it
> >> pure C++. In 1.4 if you were to remove C support and then include it
> >> back in
> >> 1.5 by when are we expecting to ship 1.5? This would also mean that we
> >> should branch at 1.3 and then converge if all goes well in 1.5.
> >>
> >> Regards
> >> Farhaan
> >>
> >> -----Original Message-----
> >> From: Mark Whitlock [mailto:mark_whitlock@uk.ibm.com]
> >> Sent: 18 October 2004 19:31
> >> To: axis-c-dev@ws.apache.org
> >> Subject: Fw: Re: 1.3 release
> >>
> >>
> >>
> >>
> >>
> >> I'm keen that 1.3 gets shipped soon, as I would like to start making
> >> changes for 1.4 (C/C++ bindings, etc) but I don't want to make these
> >> changes until 1.3 is shipped as it would destabilise the code.
> >> Mark
> >>
> >> > >
> >> > > Hi Folks,
> >> > >
> >> > > the 1.3 release has not been declared.
> >> > > What are the latest schedules ?
> >> > > Are we waiting on any bugs to be fixed?
> >> >
> >> > linux user guide is obsolete. Need to update it. I'm going to fix it
> >> > tomorrow earliest
> >> >
> >> > thanks
> >> > damitha
> >> > >
> >> > >
> >> > >
> >> > > John Hawkins
> >> > >
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > _______________________________
> > Do you Yahoo!?
> > Declare Yourself - Register online to vote today!
> > http://vote.yahoo.com
> >
> >
>
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com