On 29/11/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote: > On 28/11/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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
