+1
On 6/29/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > 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 > > > >
