-----Original Message-----
From: John Hawkins
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 24, 2005
1:39 PM
To: Apache AXIS C User List
Subject: RE: Two build questions
If you do not specify the lib names in conf then Axis
relies on defaults which should get picked up from lib path.
|
"Samisa Abeysinghe"
<[EMAIL PROTECTED]>
24/08/2005 05:34
|
Please
respond to
"Apache AXIS C User List"
|
|
|
To
|
"Apache AXIS C User List"
<axis-c-user@ws.apache.org>
|
|
cc
|
|
|
Subject
|
RE: Two build questions
|
|
Hi
Kevin,
> -----Original Message-----
> From: Kevin Rogers [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 24, 2005 3:20 AM
> To: Apache AXIS C User List
> Subject: Re: Two build questions
>
>
> Hey Samisa, thanks for the response. See my
notes below:
>
> Samisa Abeysinghe wrote:
>
> >We seem to have few problems with Xerces
2.6 with some test cases.
> >However, I was able to run the samples
both on Linux and Windows
using
> >Xerces 2.6
> >
> >
> I am, unfortunately, unable to upgrade to 2.6
at this time because of
> dependencies of other tools in my work
envirnoment on Xerces. I'll
keep
> trying, or maybe try to set up my environment
to fall back to the 2.2
> version that Axis 1.5.0 was built against.
Xerces 2.0 doe not seem to have any problems at
the moment. Hence you
will have fewer issues with it.
>
> >axisapp.conf file is not pointing to the
Xerces parser. Rather it is
> >ponting to the Axis C++ implementation of
the Xerces based paser
> >abstraction layer lib.
> >
> >
> >The libs such as Xerces are infact are
picked from the lib path. We
> >need the axiscpp.conf file to specify the
location of the paser,
> >transport and cannel abstraction
implementations.
> >
> >
>
> Yes, this is true. However, isn't this why
you copy libaxis_xercesc.so
> (the default parser library) to
libaxis_xmlparser.so (or create a
> simlink to accomplish the same thing)? Am I
misunderstanding in
thinking
> that these two libs are supposed to be
exactly the same, only with
> different names?
Well you do not have to have different names. You
can use
libaxis_xercesc.so directly in axiscpp.conf file
>
> If I am understanding correctly, this
requires a step (post-build) on
> the user's part to make sure that they have
either copied or linked
the
> appropriate XML parser lib so that it is
represented by the name
> 'axis_xmlparser', which is just an
abstraction you have placed on top
of
> it. If this is the case, why not just do the
same thing for the
> transport and channel libs? Meaning, why
don't you provide generic lib
> names as an abstraction on top of the
libraries, and then rely on the
> user to either copy or link them post-build?
This would do away with
the
> need for the conf file, correct?
The only reason that I can think of to have a conf
file is to have the
possibility of switching the transport and parser
libs.
However, as we build shared libs, as you are
suggesting, we would be
able to pick the libs from the lib path and use
it.
I have never tried it but you have a valid point
here. As of now the
code is written to locate it from conf file and
load it - may be this
can be changed, but someone needs to look into the
viability.
Thanks,
Samisa...
>
> >>Second, for right now, I need to have
the axiscpp.conf file located
> >>somewhere other that /etc, and was
wondering what needs to be done
to
> >>make that happen?
> >>
> >>
> >
> >You do not need to have the conf file in
/etc. All that you have to
do
> >is to define the AXISCPP_DEPLOY
environment variable. Then both the
> >server and clients will try to locate the
conf file from
> >$AXISCPP_DEPLOY/etc.
> >
> >Obviously, if AXISCPP_DEPLOY is not set,
it will look in /etc.
> >
> >
>
> Thanks! That hint just helped me track that
down to the
> common/AxisConfig.cpp file. I'll try that out
now.
>
> Best,
> Kevin
>
> --
> Kevin Rogers
> PDI / Dreamworks
> ext.29163 | 650.562.9163
> [EMAIL PROTECTED]
