Re: Two build questions
Thanks John! I actually tried this out (removing the conf file entirely), and it does seem to pick up the axis_xmlparser lib from the path. =) However, it seems to only pick up the axis_xmlparser lib - and still bombs when trying to find the http_transport and http_channel libs, though they are in the same location... ??? Is there someone on this list who has gotten Axis to successfully pick up all of the libs without use of the conf file? thanks! kevin Samisa Abeysinghe wrote: Oh I did not know that. In fact I never tried without conf file entry. -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.
RE: Two build questions
Oh I did not know that. In fact I never
tried without conf file entry.
-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"
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]
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" 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]
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]
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. 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? 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? 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]
Re: Two build questions
Hi Kevin, Please see below for my response. On 8/22/05, Kevin Rogers <[EMAIL PROTECTED]> wrote: > > Hi! Before I drop a bunch of question on you, I just wanted to say great > job on the library! =) > I have two build-related questions for the group: > > The first question has to do with the version of Xerces that the lib > builds against / uses at runtime. I'm attempting to get Axis 1.5.0 to > use Xerces 2.5. I can successfully build the code against Xerces 2.5, > however, at runtime I get errors of the form: > > HTTPTransportException: HTTP transport error > Exception Code: 50 > > ...which I did not receive before when using Xerces 2.2 (no code > changes). I've updated the references in the build.Linux.properties file > and the axiscpp.conf file to point to the 2.5 version of Xerces. Are > there any other variables which reference the version of Xerces in the > building of the Axis lib? I know that it may not be possible to run Axis > 1.5 against a newer version of the library, but I thought it would be > worth asking the group. 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 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 build variables that you have mentioned are the only ones for 1.5 release. With the current CVS version we have a simplified build properties file named "build.common.properties" > > ...Speaking of the axiscpp.conf file - that leads me to me second set of > questions... > > First, I'm curious as to why the axiscpp.conf file is necessary, and was > wondering (read: hoping) if it might be done away with in the next > release of Axis. I guess what I'm having trouble understanding is why > the version of libraries that are being used need to be specified both > at build time *and* at run-time, especially with absolute paths. It > seems strange to have to specify a library location in a file when it > should be picked up at runtime on the library include path. 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. As an example, one can either use the Xerces based or the Guththila based implementation of the parser abstraction layer. The way to specify which one to use is to use the conf file. The same applied to the transport (we used to have several transport implementations in the past. We had a LibWWW based one. Even though LibWWW is not used any more, we want to keep the options open. ) > > 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, Samisa... > > Again, keep up the great work, and thanks in advance for any help! > kevin > > -- > Kevin Rogers > PDI / Dreamworks > ext.29163 | 650.562.9163 > [EMAIL PROTECTED] > >
