+1
Can we differ this to 1.0.
I would like to have Attachment (MTOM & SwA) stuff integrated ASAP before looking at this.
Is it OK with all???
On 6/29/05, Srinath Perera <[EMAIL PROTECTED]> wrote:
+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
> >
>
>
--
"May the SourcE be with u"
