Hi,
The generated C stubs can be compiled with a C compiler and will not need a
C++ compiler. The C support is being separated out from the Axis C++ engine
into a separate DLL/shared library. So C applications will link with
AxisClientC.dll.
Currently the PlatformAutoSense.hpp and other platform header files are not
externalised (they are in src not include) so C/C++ generated stubs cannot
use them. Any platform support is in GDefine.hpp or AxisUserAPI.hpp. I'm
not proposing to change this so the Platform specific class will only ever
be called from C++ interally and never by external C applications.
Mark
Mark Whitlock
IBM
----- Forwarded by Mark Whitlock/UK/IBM on 12/01/2005 09:43 -----
Nadir Amra
<[EMAIL PROTECTED]>
To
12/01/2005 06:58 "Apache AXIS C Developers List"
<[email protected]>
cc
Please respond to
"Apache AXIS C Subject
Developers List" RE: Platform specific class
I guess I would like to tackle the question of whether the "generated C
stubs can be compiled by just using a C compiler?".
I guess the person working on C stub generation needs to answer that.
However, even if customer requires a C++ compiler, generating C stubs is
still useful. Yes, the customer would have to compile C++ code, but does
not have to understand what the C++ code is doing, as long as customer has
the ability to call a C stub to access a Web Service. That is the most
important thing.
Obviously, I would prefer a purely C implementation for C stub generation,
which means Axis would have to provide a C interface to the Axis engine
that is compiled with C++ compiler (the C interface would be wrapper'ed
with extern "C"). The C interface then can access the C++ engine. I
thought that was the direction we were going on this, but I may be
mistaken.
Even in a purely C stub interface, I think we can go with C++ abstraction
as long as we provide C interfaces to the platform abstractions. That is
a possible solution. Discussion on how the abstraction should be
implemented should be left for later....unless you want to discuss now. We
can start a new thread on that.
"Lilantha Darshana" <[EMAIL PROTECTED]> wrote on 01/10/2005 06:03:55 PM:
>
> Let me make myself clear on what I said.
> We can have the suggested bridge pattern to make axis transparent
> from platform
> specific functions. i.e decouple an abstraction from its real
implementation.
> This would make things more manageable esp. when OS/HW or
> environment (runtime lib etc)
> changes. Better option is to have layered architecture (PAL) and
> grow up from it.
> This is not a short term answer, but is a long term solution.
>
> One question will crops up when we convert platform support to
> classes as pointed by
> Nadir is: when we create C stubs if C stubs need these functions
> what shall we do?
> My question is, can the generated C stubs be compiled by just using
> a C compiler (none C++)
> and link it with axis libs? If not, my general assumption is:
> creating C stubs does not
> make much sense to me, if you do not have strong arguments of
> supporting C stubs.
> May be I have not heard of your perspectives on that(we can discuss)
> We can create C++ stubs and call any external APIs from it - this
> external API could
> have been written by any language not just C. Often, with
> webservices we would rather
> require to call/access to external code written in different legacy
> languages, eg. COBOL.
> So, how you would suggest to call a service written in any other
> language than C?
> Therefore, my understanding is, if we additionally support C services
that
> does not solve all requirements what ppl try to resolve by using
> webservices these days.
>
> APR is just one of the good option if we need some OS/HW dependent
> functions and make
> it transparent to axis when we impl. above design. So APR can be
> used to impl. some
> of the common functions in the base class. However, this is not
> mandatory to go in to
> any particular axis release, rather, is a thought whether we have
> any complications
> on using it. I'm afraid whether I could make much comment about APR
> running on OS/400.
> You IBM forks must know about it more than I do. Although, I have
> seen that IBM provides
> APR with HTTP server for IBM iSeries server. So my assumption is at
least 90%
> is compatible.
>
> Functions like:
> #define PLATFORM_STRTOASC( x ) ( x )
> #define PLATFORM_ASCTOSTR( x ) ( x )
>
> is required because we deal with ASCII/EBCDIC rather than with real
> Unicode char sets
> So my strong suggestion is we need moving to use Unicode (with
> w_char) in place of bytes (char),
> esp. in the Axis lib - In stubs we might want to support by giving some
> functions to convert back and forth - or make call to a platform
> abstraction layer that
> we try to introduce here to make this conversion.
>
> Thoughts please??
>
> regards
> -Lilantha
>
>
> -----Original Message-----
> From: Nadir Amra [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 06, 2005 4:11 PM
> To: Apache AXIS C Developers List
> Subject: RE: Platform specific class
>
>
> Two things.
>
> First, the use of APR should be delayed until 1.6 or beyond because we
> have too many things we need to get done for 1.5, at least from my
> perspective. Major hurdle is I want to overcome is making code locale
> sensitive. Adding APR to the mix would be too much to handle.
>
> Second, I do not think we can get rid of the platform header files that
> includes defines and typedefs, etc. As far as making a platform class
> with methods to say load library, get locale, etc...my only concern is
if
> C code needed to access any platform-specific APIs. I know the AXIS
> engine is purely C++, and if we can guarantee that C stubs do not need
> access, then I would say yes going to the class implementation, although
I
> am not sure it would not be overkill.
>
> I do not mind in 1.5 changing macros to functions if you feel it is
> necessary. For example:
>
> In PlatformAutoSense.hpp, the APIs the platforms would need to implement
> would be listed:
>
> extern "C" platform_loadlibray( ...)
> .
> .
> extern "C" platform_unloadlibrary(...)
>
>
> And the implementation of the code would be in the separate files for
each
> platform, for example,
>
> \axis\axis-c\src\platforms\os400\PlatformSpecificOS400.cpp
> \axis\axis-c\src\platforms\aix\PlatformSpecificAIX.cpp
> .
> .
> .
>
> and in the ANT build, we can choose what platform cpp file to include
> based on platform.
>
> In addition, this could be a separate DLL so that we do not have to
> include in all DLLs used.
>
> Or, we can revisit this in a future release :-) and leave as-is. There
> is not that much in the files at this point in time.
>
>
>
>
>
> John Hawkins <[EMAIL PROTECTED]>
> 01/06/2005 04:58 AM
> Please respond to
> "Apache AXIS C Developers List"
>
>
> To
> "Apache AXIS C Developers List" <[email protected]>
> cc
>
> Subject
> RE: Platform specific class
>
>
>
>
>
>
>
>
>
>
> Hi Lilantha,
>
> Good point - I'd forgotten about that project !
>
> Yes, the library routines there are exactly what we are talking about
here
> e.g. they have a getErrorMessage equivelant and most of the other
> functions
> that we have defined in our platform objects now.
> I can't see the equivelant of our ->
> #define PLATFORM_STRTOASC( x ) ( x )
> #define PLATFORM_ASCTOSTR( x ) ( x )
>
> in it but I might have missed it.
>
> If we were to use this library. We might still need some level of
> "Platform" object because our platform stuff has filenames in it (but
this
> is minor and is more architecture dependent than OS dependent between
Win
> and non-windows) and it might even be solved I perhaaps just didn't see
> the
> routine in the APR ?
>
> I'm worried about using APR because it's quite big and they say they
have
> compiled it on windows and Unix. This may have ramifications for us as
we
> support OS400 - Nadir - thoughts please?
>
> It would be a big move to use APR and it might be better to do it slowly
-
> if at all depending on the OS400 issue. If OS400 has issues with APR (or
> indeed other architectures/platforms) then we could have a compromise
(not
> a great one but a way forward) of moving to the platform model as
> previously described but making the base class use APR. That way any
> functions we had issues with or architectures/platforms that could not
be
> supported using APR could overwrite the methods.
>
> It's not great because it means that for every APR function that does
not
> work on all platforms we have to wrapper.
>
>
> Thoughts please folks?
>
>
>
>
>
>
>
>
>
> John Hawkins
>
>
>
>
>
> "Lilantha
> Darshana"
> <[EMAIL PROTECTED] To
>
> com> "Apache AXIS C Developers List"
> <[email protected]>
> 05/01/2005 15:08 cc
>
>
> Subject
>
> Please respond to RE: Platform specific class
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
> +1 for a Bridge pattern to support. PAL - Platform Abstraction Layer.
> Can we think of using APR (http://apr.apache.org/) for some of impl. ?
>
> regards
> -Lilantha
>
>
> -----Original Message-----
> From: John Hawkins [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 05, 2005 6:38 AM
> To: Apache AXIS C Developers List
> Subject: Re: Platform specific class
>
>
>
>
>
>
> I was thinking of something like the following:
>
> (See attached file: Platform hierarchy.jpeg)
>
> As you can see the IPlatform interface has base implementations for
macros
> and pure virtual methods only. This makes it really clear what the
> platforms have to implement (with appropriate documentation at this
> level).
> The architecture layer (Windows, Unix etc.) then has platform specific
> implementations of the methods and any overriding of the macros that may
> be
> necessary.
> The platform specific layer (WINNT, AIX, HP_UX etc.) then has any more
> specific overrides that may be necessary over and above the architecture
> layer.
>
> The Platform factory is the key class it is set out something like this
> (Pseudo) ->
>
> class Platform
> {
> static IPlatform platform;
> #ifdef WIN32
> platform = Win32Platform
> #endif
> /**
> *
> * returns the specific instance of Platform
> */
> static IPlatform getplatform();
> }
>
>
> Thoughts folks?
>
>
> John Hawkins
>
>
>
>
>
> Nadir Amra
> <[EMAIL PROTECTED]>
> To
> 04/01/2005 18:44 "Apache AXIS C Developers List"
> <[email protected]>
> cc
> Please respond to
> "Apache AXIS C Subject
> Developers List" Re: Transport specific class
>
>
>
>
>
>
>
>
>
>
> I agree, and was thinking of doing that....although do we want a
> PlatformServices class or just individual APIs?
>
> Nadir K. Amra
> e-Business Technologies - IBM eServer i5/OS
> IBM Rochester, MN, (Tel. 507-253-0645, t/l 553-0645)
> Internet: [EMAIL PROTECTED]
>
>
>
> John Hawkins <[EMAIL PROTECTED]>
> 01/04/2005 12:40 PM
> Please respond to
> "Apache AXIS C Developers List"
>
>
> To
> [email protected]
> cc
>
> Subject
> Transport specific class
>
>
>
>
>
>
>
>
>
>
> Hi Folks,
>
> I've just been putting some error information into transport and
realised
> a
> few things. (I'm going to start another thread re other issue.)
>
> I just implemented a "getErrorMessage" piece of code which should have
> gone
> into the platform specifics but it was quite chunky and did not sit
easily
> with being a macro.
>
> The Platform specific files are not classes - this surprised me - would
it
> be better to have a platform interface that the specific classes
overrode
> with their implementation? I understand that the macros are probably
fine
> for most things but if we had a platform class it would be more explicit
> what each method had to achieve. These methods could also return values
> more explicitly?
>
>
>
> John Hawkins
>
>
>
>
>
>
>
>
