axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <susan...@opensource.lk>
Subject RE: Axis C++ 1.2 trasport support
Date Mon, 26 Apr 2004 10:43:07 GMT
Ok then lets go with axiscpp.conf having 3 new configuration options

1. AXIS_SOAP_PARSER_LIB
2. AXIS_WSDD_PARSER_LIB
3. AXIS_CLIENT_TRANSPORT_LIB

Ex:

AXIS_SOAP_PARSER_LIB=libAxisSoapParserExpat.so
AXIS_WSDD_PARSER_LIB=libAxisWSDDParserXerces.so
AXIS_CLIENT_TRANSPORT_LIB=libAxisXIO.so

---
Susantha.

-----Original Message-----
From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com] 
Sent: Monday, April 26, 2004 9:55 AM
To: Apache AXIS C Developers List
Subject: Re: Axis C++ 1.2 trasport support

Susantha,
    What I meant by a 'configuration mechanism' is to use a conf file.

    Currently the compiler directives are used from within the parser
abstraction layer code.
    This is more like hardcoding the parser.
    This means the parser abstraction layer has to be improved.

    Infat I made a mistake. I used the compiler directives to make a
configuration selection.
Actually what has to be done is to specify a configaration parameter.
    Once there is flexibility to select the parser from a conf file, to
select the parser, there
need to be multiple parser support compiled.
    At the moment this kind of selection is done by modifying the
Makefile.am file. But if you use
configuration parameters in the way that I have suggested then the users
would not have to edit
the Makefile.am in the parser folder. Rather they could use the
directive during config time and
select  what parsers they are going to use at run time.
    

> >Or we can hard code the name of the parser in Axis and user have to
> >rename his library to that name say libAxisSoapParser.so
    I do not think this is a good idea because then the user has to
rebuild the source to et
another parser support.
    Rather dynamic switching would be ideal.

Thanks,
Samisa...

--- Paul Fremantle <pzf@hursley.ibm.com> wrote:
> Susantha
> 
> That sounds cool.
> 
> Paul
> 
> Susantha Kumara wrote:
> 
> >Hi Samisa,
> >
> >Why should we decide what parser(s) is(are) used at compile time.
Rather
> >we can let it happen at runtime. The name of the shared object (or
DLL)
> >can be taken from a configuration file.
> >For exmaple: In your machine you can have 
> >	libAxisSoapParserExpat.so and
> >	libAxisSoapParserXerces.so
> >But Axis uses the parser specified in the axiscpp.conf by say line
> >	AXISSOAPPARSER=libAxisSoapParserXerces
> >

> >
> >---
> >Susantha
> >
> >On Fri, 2004-04-23 at 04:26, Samisa Abeysinghe wrote:
> >  
> >
> >>We can keep thecompiler directive as it is and need to make sure
that
> >>multiple compiler directives are possibe.
> >>This is because one can choose to use only Xerces, while another may
> >>choose to use both Xerces and Expat. Also there can be situations
that
> >>users would wish to include their own parsers.
> >>(simply speaking one should be able to use -DUSE_EXPAT_PARSER
> >>-DUSE_XERCES_PARSER together)
> >>This needs bit of work
> >> 
> >>Also there is another work package related to this.
> >>That is for those who have selected to compile with multiple
parsers,
> >>there needs to be a mechanism to configure what parser to use. Hence
> >>configuration support need to be built. (it would be nice if we
could
> >>do that for transport as well)
> >> 
> >>If the Parser abstraction layer API could be well defined, third
party
> >>parsers could be plugged in by users easily. At the moment the API
is
> >>not very clear.
> >>(Can we document this?)
> >> 
> >>Thanks,
> >>Samisa...
> >>
> >>Susantha Kumara <susantha@opensource.lk> wrote:
> >>        Yes we can include this in 1.2 release plan. Both features
> >>        
> >>        1. Transport layer abstraction
> >>        2. SOAP parser abstraction
> >>        
> >>        But there is another place that needs parser abstraction.
That
> >>        is wsdd
> >>        parsing. At the moment a compiler directive decides that
too.
> >>        We have to
> >>        get rid of that compiler directive too. Am I correct ?
> >>        
> >>        ---
> >>        Susantha
> >>        
> >>        On Fri, 2004-04-23 at 01:06, Samisa Abeysinghe wrote:
> >>        > >even better if we could get to the point where these
plugs
> >>        (like 
> >>        > >expat/xerces, libwww, etc) would be possible by
> >>        configuration file 
> >>        > >rather than recompile.
> >>        > 
> >>        > +1
> >>        > 
> >>        > This will need a bit of architectural restructuring; but
it
> >>        is worth
> >>        > the effort.
> >>        > Can we include this in 1.2 plan please?
> >>        > 
> >>        > Thanks, 
> >>        > Samisa...
> >>        > 
> >>        > 
> >>        > 
> >>        >
> >>
______________________________________________________________________
> >>        > Do you Yahoo!?
> >>        > Yahoo! Photos: High-quality 4x6 digital prints for 25
> >>
>
>>______________________________________________________________________
> >>Do you Yahoo!?
> >>Yahoo! Photos: High-quality 4x6 digital prints for 25
> >>    
> >>
> >
> >
> >  
> >
> 



	
		
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25ยข
http://photos.yahoo.com/ph/print_splash




Mime
View raw message