You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Pete Robbins <ro...@googlemail.com> on 2006/11/28 07:56:29 UTC
[C++] Removing dependency on Axis2C
I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
that Oisin started. Axis2C does not have an OSX port yet (Oisin's supplied
patch has not been applied) and I've been having a few problems building
their code which are probably simple to solve but I want to focus on getting
the Tuscany core ported.
I would like to remove the dependency on Axis2C and make it optional.
For SDO this would be achieved simply by not building the sdo_axiom utility
library.
For SCA it is more complex. FIrst of all we would not build the current WS
binding extensions. Some of the samples would have to be changed so we do
not build the wsclients which are Axis2C specific. I think we may also have
to provide a dummy ws binding in place of the Axis2C versions.
For Linux/Mac we can have a --with-axis2c option on the configure script.
For Windows I changed the build.bat script to optionally build extensions,
e.g. if PYTHON_HOME is not set then the python extension is not built, so we
could optionally build with Axis if AXIS2C_HOME is set. It may be better to
code optional parameters onto the build.bat script to control the build to
be in line with the Linux build but for now using the environment variables
is OK.
Any thoughts?
Cheers,
--
Pete
Re: [C++] Mac OS X port, was: Removing dependency on Axis2C
Posted by Pete Robbins <ro...@googlemail.com>.
On 08/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
>
>
> On 07/12/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> >
> >
> > On 07/12/06, Jean-Sebastien Delfino < jsdelfino@apache.org> wrote:
> > >
> > > [snip]
> > > Pete Robbins wrote:
> > > > I'm in the process of porting Tuscany C++ to Mac OSX continuing the
> > > work
> > > > that Oisin started.
> > > >
> > >
> > > Pete,
> > >
> > > I am trying to clean up our JIRA backlog and wondering if TUSCANY-681
> > > can be closed now ( https://issues.apache.org/jira/browse/TUSCANY-681
> > > ).
> > > What is the status of the patch in TUSCANY-681? Has it been included
> > > as
> > > part of the Mac OS X port you've been working on?
> >
> >
> > Oisin's patch has been applied but there's still more to do so I was
> > leaving this open. The build for samples needs to be checked in. Once I've
> > done that I'll close 681 and open new Jiras for any problems.
> >
> > Cheers,
> >
> >
> >
> >
> >
> > --
> > Pete
>
>
> As part of this work I will be removing the Axis2C client and use of WS
> binding from the CppCalculator sample. CppBigBank can demonstrate ws. We
> will not have WS bindings available on Mac until there is an Axis2C Mac port
> which looks like it's planned for their 1.0 release (March 2007 ish).
>
> I have some more work to do to build/test the scripting bindings/samples.
>
>
So which samples are we left with without a ws binding? CppCalculator is the
first. What about PythonCalculator? The basic sample would work but the
composite contains a binding.ws for use with the wsclient. I was wondering
if we could remove this for the basic sample then have a second composite to
wrap the other and expose as a webservice?? Maybe we could just have a
separate sample that re-uses the sample.calculator.composite??
Do the Rest samples require Axis?
Should all the xxxCalculator samples just not use WS as we have other
samples that do show this?
--
Pete
Re: [C++] Mac OS X port, was: Removing dependency on Axis2C
Posted by Pete Robbins <ro...@googlemail.com>.
On 07/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
>
>
> On 07/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > [snip]
> > Pete Robbins wrote:
> > > I'm in the process of porting Tuscany C++ to Mac OSX continuing the
> > work
> > > that Oisin started.
> > >
> >
> > Pete,
> >
> > I am trying to clean up our JIRA backlog and wondering if TUSCANY-681
> > can be closed now (https://issues.apache.org/jira/browse/TUSCANY-681 ).
> > What is the status of the patch in TUSCANY-681? Has it been included as
> > part of the Mac OS X port you've been working on?
>
>
> Oisin's patch has been applied but there's still more to do so I was
> leaving this open. The build for samples needs to be checked in. Once I've
> done that I'll close 681 and open new Jiras for any problems.
>
> Cheers,
>
>
>
>
>
> --
> Pete
As part of this work I will be removing the Axis2C client and use of WS
binding from the CppCalculator sample. CppBigBank can demonstrate ws. We
will not have WS bindings available on Mac until there is an Axis2C Mac port
which looks like it's planned for their 1.0 release (March 2007 ish).
I have some more work to do to build/test the scripting bindings/samples.
Cheers,
--
Pete
Re: [C++] Mac OS X port, was: Removing dependency on Axis2C
Posted by Pete Robbins <ro...@googlemail.com>.
On 07/12/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Pete Robbins wrote:
> > I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
> > that Oisin started.
> >
>
> Pete,
>
> I am trying to clean up our JIRA backlog and wondering if TUSCANY-681
> can be closed now (https://issues.apache.org/jira/browse/TUSCANY-681).
> What is the status of the patch in TUSCANY-681? Has it been included as
> part of the Mac OS X port you've been working on?
Oisin's patch has been applied but there's still more to do so I was leaving
this open. The build for samples needs to be checked in. Once I've done that
I'll close 681 and open new Jiras for any problems.
Cheers,
--
Pete
[C++] Mac OS X port, was: Removing dependency on Axis2C
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Pete Robbins wrote:
> I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
> that Oisin started.
>
Pete,
I am trying to clean up our JIRA backlog and wondering if TUSCANY-681
can be closed now (https://issues.apache.org/jira/browse/TUSCANY-681).
What is the status of the patch in TUSCANY-681? Has it been included as
part of the Mac OS X port you've been working on?
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Removing dependency on Axis2C
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Jean-Sebastien Delfino wrote:
> We may want to ask the OSOA spec workgroup whether the WS binding is
> actually mandatory to support as part of core SCA programming model or
> not. The SCA assembly spec currently states that it is mandatory, but
> now that the WS binding has its own separate spec document I'm
> wondering what makes it so special and mandatory. I can ask the
> question to the OSOA spec worgroup and I'll create a JIRA issue in the
> Specification category to track this.
>
I have created JIRA https://issues.apache.org/jira/browse/TUSCANY-984
for this.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Removing dependency on Axis2C
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 29/11/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Pete Robbins wrote:
>> > On 28/11/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> >>
>> >> Pete Robbins wrote:
>> >> > I'm in the process of porting Tuscany C++ to Mac OSX continuing the
>> >> work
>> >> > that Oisin started. Axis2C does not have an OSX port yet (Oisin's
>> >> > supplied
>> >> > patch has not been applied) and I've been having a few problems
>> >> building
>> >> > their code which are probably simple to solve but I want to
>> focus on
>> >> > getting
>> >> > the Tuscany core ported.
>> >> >
>> >> > I would like to remove the dependency on Axis2C and make it
>> optional.
>> >> >
>> >> > For SDO this would be achieved simply by not building the sdo_axiom
>> >> > utility
>> >> > library.
>> >> >
>> >> > For SCA it is more complex. FIrst of all we would not build the
>> >> > current WS
>> >> > binding extensions. Some of the samples would have to be changed so
>> we
>> >> do
>> >> > not build the wsclients which are Axis2C specific. I think we may
>> also
>> >> > have
>> >> > to provide a dummy ws binding in place of the Axis2C versions.
>> >> >
>> >> > For Linux/Mac we can have a --with-axis2c option on the configure
>> >> script.
>> >> > For Windows I changed the build.bat script to optionally build
>> >> > extensions,
>> >> > e.g. if PYTHON_HOME is not set then the python extension is not
>> built,
>> >> > so we
>> >> > could optionally build with Axis if AXIS2C_HOME is set. It may be
>> >> > better to
>> >> > code optional parameters onto the build.bat script to control the
>> >> > build to
>> >> > be in line with the Linux build but for now using the environment
>> >> > variables
>> >> > is OK.
>> >> >
>> >> > Any thoughts?
>> >> >
>> >> > Cheers,
>> >> >
>> >>
>> >> Pete,
>> >>
>> >> This sounds good to me. A few more thoughts:
>> >>
>> >> - +1 for just detecting the AXIS2C_HOME environment variable on
>> Windows,
>> >> this is more convenient if you build from the IDE as well.
>> >>
>> >> - On Linux we already have --enable-wsbinding=yes/no config option. I
>> >> think we could just change the default to "no", instead of
>> introducing
>> a
>> >> dummy ws binding and another --with-axis2c config option.
>> >>
>> >> - Most of our samples depend on WS on both the client and server
>> side,
>> >> so turning them into variable geometry samples with an optional WS
>> part
>> >> sounds a bit complicated :) Could we just use a
>> >> --enable-wsbinding=yes/no option to enable/disable the samples that
>> >> require the WS binding? I realize that this will disable most of our
>> >> current samples but this situation is evolving... We already have a
>> >> RestCalculator sample that works without the WS binding, I'm about to
>> >> add another REST sample, Andy is adding a new Python sample, and I'll
>> >> probably add next a sample that reuses an existing C++ library, which
>> >> won't use WS either. Soon we'll have enough non-WS samples to
>> illustrate
>> >> the SCA programming model... and disabling the WS samples won't be a
>> >> problem.
>> >>
>> >> What do you think?
>> >>
>> >> --
>> >> Jean-Sebastien
>> >
>> >
>> > binding.ws is part of the core assembly model so we should have at
>> least
>> > something that registers to handle those scdl elements. This is my
>> > thinking
>> > for a dummy/default ws binding extension. When I took out the existing
>> > Axis2C ws extension our simple C++ Calculator sample with C++ client
>> > fails
>> > because the .composite declares a <binding.ws> although this is only
>> > used in
>> > the ws client case.
>> >
>> > So I think --enable-wsbinding should always be true and in fact the
>> > option
>> > would be redundant. Control over who provides the ws binding extension
>> > can
>> > be with a different switch
>> --with-axis/--with-petes-super-ws-package or
>> > whatever.
>> >
>> > It makes sense to me for the CppCalcualtor sample to conditionally
>> > build the
>> > wsclient rather than have a separate sample with/without ws.
>> >
>> > Cheers,
>> >
>> >
>> >
>> >
>> >
>>
>> This poses interesting questions :)
>>
>> Should we be able to build a runtime with a subset of the "core"
>> bindings and component implementation types? I would say yes. For
>> example, you may want to build scaled down versions of the runtime for
>> use in a distributed environment, in parts of your system where you
>> don't need Web services support, or no C++ support, etc.
>>
>> What did you mean by a dummy/default WS binding? Would it be functional
>> like the Axis2C based one? If yes, how would you want to implement it?
>> If no, what would be the purpose of that binding?
>
>
> At a minimum we need a ws binding extension that includes the
> schema... and
> that is what I have checked in. So now if you build without the axis
> binding
> and run the calculator client you do not get an SDO Runtime exception for
> the unrecognized element. What you do get is an "Unsupported binding
> type"
> exception which is good IMO.
>
OK, I understand now. Sounds good!
We may want to ask the OSOA spec workgroup whether the WS binding is
actually mandatory to support as part of core SCA programming model or
not. The SCA assembly spec currently states that it is mandatory, but
now that the WS binding has its own separate spec document I'm wondering
what makes it so special and mandatory. I can ask the question to the
OSOA spec worgroup and I'll create a JIRA issue in the Specification
category to track this.
> Conditionally build the wsclient part of the samples is not going to be
>> sufficient. As you said the sample .composite files also depend on the
>> WS binding, so I guess we'd have to strip the binding.ws elements out of
>> the sample composite files when the WS binding is not enabled... other
>> wise it's going to be pretty confusing to have them there but no Web
>> Services created for them... Any thoughts on how to do this simply?
>
>
> no :-(
>
> Maybe we just leave CppCalculator as a pure C++ sample and leave the ws
> stuff to the BigBank sample.
>
Yes, good idea.
> Is it true that you can only have a composite file named the same as the
> composite? e.g fred.composite contains <composite name="fred">? If
> not, then
> can you have a joe.composite which also contains <composite
> name="fred"> and
> the runtime would merge the definitions? I suspect not!
>
The name of a composite file does not need to match the name of the
composite.
Independent of file names, you cannot have two SCDL files defining the
same composite name. Merging fragments of composites is achieved using
SCDL <include> statements instead.
>
> Cheers,
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Removing dependency on Axis2C
Posted by Pete Robbins <ro...@googlemail.com>.
On 29/11/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > On 28/11/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>
> >> Pete Robbins wrote:
> >> > I'm in the process of porting Tuscany C++ to Mac OSX continuing the
> >> work
> >> > that Oisin started. Axis2C does not have an OSX port yet (Oisin's
> >> > supplied
> >> > patch has not been applied) and I've been having a few problems
> >> building
> >> > their code which are probably simple to solve but I want to focus on
> >> > getting
> >> > the Tuscany core ported.
> >> >
> >> > I would like to remove the dependency on Axis2C and make it optional.
> >> >
> >> > For SDO this would be achieved simply by not building the sdo_axiom
> >> > utility
> >> > library.
> >> >
> >> > For SCA it is more complex. FIrst of all we would not build the
> >> > current WS
> >> > binding extensions. Some of the samples would have to be changed so
> we
> >> do
> >> > not build the wsclients which are Axis2C specific. I think we may
> also
> >> > have
> >> > to provide a dummy ws binding in place of the Axis2C versions.
> >> >
> >> > For Linux/Mac we can have a --with-axis2c option on the configure
> >> script.
> >> > For Windows I changed the build.bat script to optionally build
> >> > extensions,
> >> > e.g. if PYTHON_HOME is not set then the python extension is not
> built,
> >> > so we
> >> > could optionally build with Axis if AXIS2C_HOME is set. It may be
> >> > better to
> >> > code optional parameters onto the build.bat script to control the
> >> > build to
> >> > be in line with the Linux build but for now using the environment
> >> > variables
> >> > is OK.
> >> >
> >> > Any thoughts?
> >> >
> >> > Cheers,
> >> >
> >>
> >> Pete,
> >>
> >> This sounds good to me. A few more thoughts:
> >>
> >> - +1 for just detecting the AXIS2C_HOME environment variable on
> Windows,
> >> this is more convenient if you build from the IDE as well.
> >>
> >> - On Linux we already have --enable-wsbinding=yes/no config option. I
> >> think we could just change the default to "no", instead of introducing
> a
> >> dummy ws binding and another --with-axis2c config option.
> >>
> >> - Most of our samples depend on WS on both the client and server side,
> >> so turning them into variable geometry samples with an optional WS part
> >> sounds a bit complicated :) Could we just use a
> >> --enable-wsbinding=yes/no option to enable/disable the samples that
> >> require the WS binding? I realize that this will disable most of our
> >> current samples but this situation is evolving... We already have a
> >> RestCalculator sample that works without the WS binding, I'm about to
> >> add another REST sample, Andy is adding a new Python sample, and I'll
> >> probably add next a sample that reuses an existing C++ library, which
> >> won't use WS either. Soon we'll have enough non-WS samples to
> illustrate
> >> the SCA programming model... and disabling the WS samples won't be a
> >> problem.
> >>
> >> What do you think?
> >>
> >> --
> >> Jean-Sebastien
> >
> >
> > binding.ws is part of the core assembly model so we should have at least
> > something that registers to handle those scdl elements. This is my
> > thinking
> > for a dummy/default ws binding extension. When I took out the existing
> > Axis2C ws extension our simple C++ Calculator sample with C++ client
> > fails
> > because the .composite declares a <binding.ws> although this is only
> > used in
> > the ws client case.
> >
> > So I think --enable-wsbinding should always be true and in fact the
> > option
> > would be redundant. Control over who provides the ws binding extension
> > can
> > be with a different switch --with-axis/--with-petes-super-ws-package or
> > whatever.
> >
> > It makes sense to me for the CppCalcualtor sample to conditionally
> > build the
> > wsclient rather than have a separate sample with/without ws.
> >
> > Cheers,
> >
> >
> >
> >
> >
>
> This poses interesting questions :)
>
> Should we be able to build a runtime with a subset of the "core"
> bindings and component implementation types? I would say yes. For
> example, you may want to build scaled down versions of the runtime for
> use in a distributed environment, in parts of your system where you
> don't need Web services support, or no C++ support, etc.
>
> What did you mean by a dummy/default WS binding? Would it be functional
> like the Axis2C based one? If yes, how would you want to implement it?
> If no, what would be the purpose of that binding?
At a minimum we need a ws binding extension that includes the schema... and
that is what I have checked in. So now if you build without the axis binding
and run the calculator client you do not get an SDO Runtime exception for
the unrecognized element. What you do get is an "Unsupported binding type"
exception which is good IMO.
Conditionally build the wsclient part of the samples is not going to be
> sufficient. As you said the sample .composite files also depend on the
> WS binding, so I guess we'd have to strip the binding.ws elements out of
> the sample composite files when the WS binding is not enabled... other
> wise it's going to be pretty confusing to have them there but no Web
> Services created for them... Any thoughts on how to do this simply?
no :-(
Maybe we just leave CppCalculator as a pure C++ sample and leave the ws
stuff to the BigBank sample.
Is it true that you can only have a composite file named the same as the
composite? e.g fred.composite contains <composite name="fred">? If not, then
can you have a joe.composite which also contains <composite name="fred"> and
the runtime would merge the definitions? I suspect not!
Cheers,
--
Pete
Re: [C++] Removing dependency on Axis2C
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> On 28/11/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> Pete Robbins wrote:
>> > I'm in the process of porting Tuscany C++ to Mac OSX continuing the
>> work
>> > that Oisin started. Axis2C does not have an OSX port yet (Oisin's
>> > supplied
>> > patch has not been applied) and I've been having a few problems
>> building
>> > their code which are probably simple to solve but I want to focus on
>> > getting
>> > the Tuscany core ported.
>> >
>> > I would like to remove the dependency on Axis2C and make it optional.
>> >
>> > For SDO this would be achieved simply by not building the sdo_axiom
>> > utility
>> > library.
>> >
>> > For SCA it is more complex. FIrst of all we would not build the
>> > current WS
>> > binding extensions. Some of the samples would have to be changed so we
>> do
>> > not build the wsclients which are Axis2C specific. I think we may also
>> > have
>> > to provide a dummy ws binding in place of the Axis2C versions.
>> >
>> > For Linux/Mac we can have a --with-axis2c option on the configure
>> script.
>> > For Windows I changed the build.bat script to optionally build
>> > extensions,
>> > e.g. if PYTHON_HOME is not set then the python extension is not built,
>> > so we
>> > could optionally build with Axis if AXIS2C_HOME is set. It may be
>> > better to
>> > code optional parameters onto the build.bat script to control the
>> > build to
>> > be in line with the Linux build but for now using the environment
>> > variables
>> > is OK.
>> >
>> > Any thoughts?
>> >
>> > Cheers,
>> >
>>
>> Pete,
>>
>> This sounds good to me. A few more thoughts:
>>
>> - +1 for just detecting the AXIS2C_HOME environment variable on Windows,
>> this is more convenient if you build from the IDE as well.
>>
>> - On Linux we already have --enable-wsbinding=yes/no config option. I
>> think we could just change the default to "no", instead of introducing a
>> dummy ws binding and another --with-axis2c config option.
>>
>> - Most of our samples depend on WS on both the client and server side,
>> so turning them into variable geometry samples with an optional WS part
>> sounds a bit complicated :) Could we just use a
>> --enable-wsbinding=yes/no option to enable/disable the samples that
>> require the WS binding? I realize that this will disable most of our
>> current samples but this situation is evolving... We already have a
>> RestCalculator sample that works without the WS binding, I'm about to
>> add another REST sample, Andy is adding a new Python sample, and I'll
>> probably add next a sample that reuses an existing C++ library, which
>> won't use WS either. Soon we'll have enough non-WS samples to illustrate
>> the SCA programming model... and disabling the WS samples won't be a
>> problem.
>>
>> What do you think?
>>
>> --
>> Jean-Sebastien
>
>
> binding.ws is part of the core assembly model so we should have at least
> something that registers to handle those scdl elements. This is my
> thinking
> for a dummy/default ws binding extension. When I took out the existing
> Axis2C ws extension our simple C++ Calculator sample with C++ client
> fails
> because the .composite declares a <binding.ws> although this is only
> used in
> the ws client case.
>
> So I think --enable-wsbinding should always be true and in fact the
> option
> would be redundant. Control over who provides the ws binding extension
> can
> be with a different switch --with-axis/--with-petes-super-ws-package or
> whatever.
>
> It makes sense to me for the CppCalcualtor sample to conditionally
> build the
> wsclient rather than have a separate sample with/without ws.
>
> Cheers,
>
>
>
>
>
This poses interesting questions :)
Should we be able to build a runtime with a subset of the "core"
bindings and component implementation types? I would say yes. For
example, you may want to build scaled down versions of the runtime for
use in a distributed environment, in parts of your system where you
don't need Web services support, or no C++ support, etc.
What did you mean by a dummy/default WS binding? Would it be functional
like the Axis2C based one? If yes, how would you want to implement it?
If no, what would be the purpose of that binding?
Conditionally build the wsclient part of the samples is not going to be
sufficient. As you said the sample .composite files also depend on the
WS binding, so I guess we'd have to strip the binding.ws elements out of
the sample composite files when the WS binding is not enabled... other
wise it's going to be pretty confusing to have them there but no Web
Services created for them... Any thoughts on how to do this simply?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Removing dependency on Axis2C
Posted by Pete Robbins <ro...@googlemail.com>.
On 28/11/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Pete Robbins wrote:
> > I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
> > that Oisin started. Axis2C does not have an OSX port yet (Oisin's
> > supplied
> > patch has not been applied) and I've been having a few problems building
> > their code which are probably simple to solve but I want to focus on
> > getting
> > the Tuscany core ported.
> >
> > I would like to remove the dependency on Axis2C and make it optional.
> >
> > For SDO this would be achieved simply by not building the sdo_axiom
> > utility
> > library.
> >
> > For SCA it is more complex. FIrst of all we would not build the
> > current WS
> > binding extensions. Some of the samples would have to be changed so we
> do
> > not build the wsclients which are Axis2C specific. I think we may also
> > have
> > to provide a dummy ws binding in place of the Axis2C versions.
> >
> > For Linux/Mac we can have a --with-axis2c option on the configure
> script.
> > For Windows I changed the build.bat script to optionally build
> > extensions,
> > e.g. if PYTHON_HOME is not set then the python extension is not built,
> > so we
> > could optionally build with Axis if AXIS2C_HOME is set. It may be
> > better to
> > code optional parameters onto the build.bat script to control the
> > build to
> > be in line with the Linux build but for now using the environment
> > variables
> > is OK.
> >
> > Any thoughts?
> >
> > Cheers,
> >
>
> Pete,
>
> This sounds good to me. A few more thoughts:
>
> - +1 for just detecting the AXIS2C_HOME environment variable on Windows,
> this is more convenient if you build from the IDE as well.
>
> - On Linux we already have --enable-wsbinding=yes/no config option. I
> think we could just change the default to "no", instead of introducing a
> dummy ws binding and another --with-axis2c config option.
>
> - Most of our samples depend on WS on both the client and server side,
> so turning them into variable geometry samples with an optional WS part
> sounds a bit complicated :) Could we just use a
> --enable-wsbinding=yes/no option to enable/disable the samples that
> require the WS binding? I realize that this will disable most of our
> current samples but this situation is evolving... We already have a
> RestCalculator sample that works without the WS binding, I'm about to
> add another REST sample, Andy is adding a new Python sample, and I'll
> probably add next a sample that reuses an existing C++ library, which
> won't use WS either. Soon we'll have enough non-WS samples to illustrate
> the SCA programming model... and disabling the WS samples won't be a
> problem.
>
> What do you think?
>
> --
> Jean-Sebastien
binding.ws is part of the core assembly model so we should have at least
something that registers to handle those scdl elements. This is my thinking
for a dummy/default ws binding extension. When I took out the existing
Axis2C ws extension our simple C++ Calculator sample with C++ client fails
because the .composite declares a <binding.ws> although this is only used in
the ws client case.
So I think --enable-wsbinding should always be true and in fact the option
would be redundant. Control over who provides the ws binding extension can
be with a different switch --with-axis/--with-petes-super-ws-package or
whatever.
It makes sense to me for the CppCalcualtor sample to conditionally build the
wsclient rather than have a separate sample with/without ws.
Cheers,
--
Pete
Re: [C++] Removing dependency on Axis2C
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Pete Robbins wrote:
> I'm in the process of porting Tuscany C++ to Mac OSX continuing the work
> that Oisin started. Axis2C does not have an OSX port yet (Oisin's
> supplied
> patch has not been applied) and I've been having a few problems building
> their code which are probably simple to solve but I want to focus on
> getting
> the Tuscany core ported.
>
> I would like to remove the dependency on Axis2C and make it optional.
>
> For SDO this would be achieved simply by not building the sdo_axiom
> utility
> library.
>
> For SCA it is more complex. FIrst of all we would not build the
> current WS
> binding extensions. Some of the samples would have to be changed so we do
> not build the wsclients which are Axis2C specific. I think we may also
> have
> to provide a dummy ws binding in place of the Axis2C versions.
>
> For Linux/Mac we can have a --with-axis2c option on the configure script.
> For Windows I changed the build.bat script to optionally build
> extensions,
> e.g. if PYTHON_HOME is not set then the python extension is not built,
> so we
> could optionally build with Axis if AXIS2C_HOME is set. It may be
> better to
> code optional parameters onto the build.bat script to control the
> build to
> be in line with the Linux build but for now using the environment
> variables
> is OK.
>
> Any thoughts?
>
> Cheers,
>
Pete,
This sounds good to me. A few more thoughts:
- +1 for just detecting the AXIS2C_HOME environment variable on Windows,
this is more convenient if you build from the IDE as well.
- On Linux we already have --enable-wsbinding=yes/no config option. I
think we could just change the default to "no", instead of introducing a
dummy ws binding and another --with-axis2c config option.
- Most of our samples depend on WS on both the client and server side,
so turning them into variable geometry samples with an optional WS part
sounds a bit complicated :) Could we just use a
--enable-wsbinding=yes/no option to enable/disable the samples that
require the WS binding? I realize that this will disable most of our
current samples but this situation is evolving... We already have a
RestCalculator sample that works without the WS binding, I'm about to
add another REST sample, Andy is adding a new Python sample, and I'll
probably add next a sample that reuses an existing C++ library, which
won't use WS either. Soon we'll have enough non-WS samples to illustrate
the SCA programming model... and disabling the WS samples won't be a
problem.
What do you think?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org