I think with MTOM married to OM and the resulting nice programming model we've created the default needs to be to have XOP and SwA support turned on by default. The technique I suggested would allow someone who wants to remove it (say someone strictly supporting WS-I BP without SwA) to rebuild Axis2 and to not have the extra Jars around.
Sanjiva. On Wed, 2005-06-29 at 07:56 +0600, Srinath Perera wrote: > I tried to have both your and dims puposal merged. what I tried to > achive is put a static block so the code is removed by compiler if it > is false. But We keep it default to true, (Axis2 code based build with > it set to true) then the classloading thingy to make normal axis2 jar > we distribute with bin dist to work even mail jar is not around. It is > just the expectations out of code ..I am fine with just static, just > reflection or both.. > > On 6/29/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-06-28 at 19:27 +0600, Srinath Perera wrote: > > > To Sum from all I like to purpose following > > > > > > 1) Lets have that final boolean enable removing the code that has > > > dependancy in the compile time > > > 2) Inside the block we will do reflection and and check for the > > > classes if they are missing use code that do not do MTOM. > > > > No no .. that's not what I was suggesting .. put the flag and because > > its a static flag the compiler will not even put the other code in; it > > simply cannot run. So no need to do reflection - just put it wrapped > > around a static const and then the class will load just fine without the > > JavaMail and Activation jars being around at runtime. > > > > > I like to purpose to make OMOutput a interface and put a factory that > > > pick the MTOM dependent or independent OMOutput impl accordingly. And > > > do the same for OMCharacter if needed. > > > > ??? OMOutput has nothing depending on the OM implementation .. what are > > the different OMOutput implementations doing thru this factory? > > > > -1 until proven wrong :). > One OMOutput impl depend on the java mail and other that do not depend > on the java mail . > But may be we can relay on the class loading with one impl. > > Thanks > Srinath >
