You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/02/13 16:36:26 UTC

Re: Please revert this - and a proposal

On Mon, 2006-02-13 at 10:16 -0500, Doug Davis wrote:
> 
> Done - apologies for not explaining this a bit more in the svn
> commit... the changes that Dims 
> is referring to are the couple of lines in the AxisEngines that make
> calls out to RM code 
> and Security code.  These do not assume any particulat implementation
> choice - they 
> are totally pluggable.  In principle I agree that doing these things
> as handlers would be 
> the way to go, however, in working with these specs I've found that
> when you start to 
> look at their requirements it shows that the handlers can't really
> meet their needs. 

Doug, these are some of the reasons we started on Axis2. There are many
design points in Axis2 to enable this stuff to be done. So far the Axis1
community has been content with saying "we're moving to axis2" when it
came to this kind of stuff and overall evolution in general.

The last time I asked you about it you said "yes some of the old timers
have agreed privately." 

I am no longer willing to accept that and would like a discussion on the
list on how much of "a few lines of code" changes to make to Axis1 to
take it where it hasn't gone before (;-)). From comments from both Glen
and Dims it not clear they agreed these are changes we want to make and
they are as "old timers" as its gets with Axis1. 

Can you indicate what your plans are any why we're doing this? We need
to have a discussion of the direction and have a vote on it amongst the
community before making any more changes; you're burning into Axis1
stuff that's by design meant to go in handlers .. and that's not a
simple change *even if its a few lines of code*. 

Sanjiva.


Re: Please revert this - and a proposal

Posted by Doug Davis <du...@us.ibm.com>.
Dims,
  Will move the changes from yesterday into the proposal and am still 
working on
getting access to the tck tests.  For wsa since I did send out a note [1] 
prior to making
the changes and there wasn't any -1's (just q's) I'd like to leave that in 
there for now.
-Doug

[1] http://marc.theaimsgroup.com/?l=axis-dev&m=113795638320607&w=2

Davanum Srinivas <da...@gmail.com> wrote on 02/13/2006 12:33:44 PM:

> Doug,
> 
> Can you please move all your changes to the proposals? (including wsa)
> http://svn.apache.org/repos/asf/webservices/axis/trunk/proposals/dug/
> 
> Once you are ready with all tests working, tck passing, etc. then
> write up a detailed proposal with changes, put it for a VOTE and go on
> from there?
> 
> Let's get back HEAD in the shape it was before (modulo the failures :)
> 
> thanks,
> dims
> 
> 
> 
> On 2/13/06, Davanum Srinivas <da...@gmail.com> wrote:
> > Dug,
> >
> > - Have u set your self up with the TCK stuff? Can u run the automatic
> > tck test harness and make sure nothing is broken?
> > - Are there existing issues in JIRA which will be fixed with your 
changes?
> >
> > thanks,
> > dims
> >
> > On 2/13/06, Doug Davis <du...@us.ibm.com> wrote:
> > >
> > > Sanjiva,
> > >   Let me first say that I am in no way against the general idea of 
people
> > > from to axis2 - from what
> > > I've seen and heard of the new architecture it sounds like a very 
positive
> > > thing.  My desire to
> > > integrate these changes into axis1 is based on a couple of things: 
first,
> > > in previous interop events
> > > I've been to I saw some of the difficulty the axis1 guys had in 
getting
> > > things to work and I believe
> > > that part of that was because of the limitations they were trying to 
live
> > > under (ie. just handlers).
> > > During that time, for my own purposes, I did have a version of Axis1 
that
> > > could handle those
> > > cases and IMO did it w/o a major change to Axis1 so after struggling 
thru
> > > the pains of IBM legal
> > > (you know what that's like! :-)   I finally got permission to 
contribute
> > > them - and am working on
> > > more.  So, since I had these changes ready to go I thought that it 
made
> > > sense to help out the
> > > existing axis1 community by contributing them.  The migration 
> from Axis1 to
> > > Axis2 will take
> > > some time and not everyone will be able to switch over right away 
(or any
> > > time soon) so I saw
> > > no harm (but a lot of benefit) to giving people the option of 
> using some of
> > > my changes to support
> > > things like better WSA and RM support.
> > >   As to your comment about me taking Axis1 where it hasn't gone 
> before - I'm
> > > no so sure that's
> > > true.  Axis has changed over time - I remember way back when 
> (old timer talk
> > > :-)   Axis was
> > > supposed to be a generic messaging engine and supporting SOAP was 
just one
> > > of the options.
> > > Since then Axis has changed and its pretty clear its a web service
> > > engine/processor.  Changes that
> > > are made that help it support the new WS specs is still taking it 
down its
> > > current path, IMO.  Adding
> > > the notion of new plug-points, aside from handlers, isn't that 
radical
> > > either - being able to plug-in
> > > different loggers or xml parsers isn't done thru handlers either.
> > >   In terms of future plans, I (and probably the rest of the 
> axis1 community)
> > > will probably move to
> > > axis2 at some point - but in the meantime I'd like to share some of 
the
> > > benefits of these changes
> > > with others.  As I've said before, my primary rule with these 
> changes is to
> > > not break existing code,
> > > so if people don't like these new extensions or plug-ins they are 
not
> > > required to use them.  But I feel
> > > pretty confident in their ability to work properly since I've been 
using
> > > them for several years now.
> > > And I do not intent to just "dump and run" - I fully intent to 
> support them
> > > and fix bugs as they pop-up.
> > > I plan on continuing to use this myself for quite some time. 
Hopefully,
> > > this help.
> > > thanks
> > > -Doug
> > >
> > >
> > > Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/13/2006 
> 10:36:26 AM:
> > >
> > >  > On Mon, 2006-02-13 at 10:16 -0500, Doug Davis wrote:
> > >  > >
> > >  > > Done - apologies for not explaining this a bit more in the svn
> > >  > > commit... the changes that Dims
> > >  > > is referring to are the couple of lines in the AxisEngines that 
make
> > >  > > calls out to RM code
> > >  > > and Security code.  These do not assume any particulat 
implementation
> > >  > > choice - they
> > >  > > are totally pluggable.  In principle I agree that doing these 
things
> > >  > > as handlers would be
> > >  > > the way to go, however, in working with these specs I've found 
that
> > >  > > when you start to
> > >  > > look at their requirements it shows that the handlers can't 
really
> > >  > > meet their needs.
> > >  >
> > >  > Doug, these are some of the reasons we started on Axis2. There 
are many
> > >  > design points in Axis2 to enable this stuff to be done. So 
> far the Axis1
> > >  > community has been content with saying "we're moving to axis2" 
when it
> > >  > came to this kind of stuff and overall evolution in general.
> > >  >
> > >  > The last time I asked you about it you said "yes some of the old 
timers
> > >  > have agreed privately."
> > >  >
> > >  > I am no longer willing to accept that and would like a 
> discussion on the
> > >  > list on how much of "a few lines of code" changes to make to 
Axis1 to
> > >  > take it where it hasn't gone before (;-)). From comments fromboth 
Glen
> > >  > and Dims it not clear they agreed these are changes we want to 
make and
> > >  > they are as "old timers" as its gets with Axis1.
> > >  >
> > >  > Can you indicate what your plans are any why we're doing this? We 
need
> > >  > to have a discussion of the direction and have a vote on it 
amongst the
> > >  > community before making any more changes; you're burning into 
Axis1
> > >  > stuff that's by design meant to go in handlers .. and that's not 
a
> > >  > simple change *even if its a few lines of code*.
> > >  >
> > >  > Sanjiva.
> > >  >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
> 
> 
> --
> Davanum Srinivas : http://wso2.com/blogs/

Re: Please revert this - and a proposal

Posted by Davanum Srinivas <da...@gmail.com>.
Let me clarify. w.r.t wsa, *IF* you see failures in jaxrpc tck or saaj
tck, please move that too.

thanks,
dims

On 2/13/06, Davanum Srinivas <da...@gmail.com> wrote:
> Doug,
>
> Can you please move all your changes to the proposals? (including wsa)
> http://svn.apache.org/repos/asf/webservices/axis/trunk/proposals/dug/
>
> Once you are ready with all tests working, tck passing, etc. then
> write up a detailed proposal with changes, put it for a VOTE and go on
> from there?
>
> Let's get back HEAD in the shape it was before (modulo the failures :)
>
> thanks,
> dims
>
>
>
> On 2/13/06, Davanum Srinivas <da...@gmail.com> wrote:
> > Dug,
> >
> > - Have u set your self up with the TCK stuff? Can u run the automatic
> > tck test harness and make sure nothing is broken?
> > - Are there existing issues in JIRA which will be fixed with your changes?
> >
> > thanks,
> > dims
> >
> > On 2/13/06, Doug Davis <du...@us.ibm.com> wrote:
> > >
> > > Sanjiva,
> > >   Let me first say that I am in no way against the general idea of people
> > > from to axis2 - from what
> > > I've seen and heard of the new architecture it sounds like a very positive
> > > thing.  My desire to
> > > integrate these changes into axis1 is based on a couple of things:  first,
> > > in previous interop events
> > > I've been to I saw some of the difficulty the axis1 guys had in getting
> > > things to work and I believe
> > > that part of that was because of the limitations they were trying to live
> > > under (ie. just handlers).
> > > During that time, for my own purposes, I did have a version of Axis1 that
> > > could handle those
> > > cases and IMO did it w/o a major change to Axis1 so after struggling thru
> > > the pains of IBM legal
> > > (you know what that's like! :-)   I finally got permission to contribute
> > > them - and am working on
> > > more.  So, since I had these changes ready to go I thought that it made
> > > sense to help out the
> > > existing axis1 community by contributing them.  The migration from Axis1 to
> > > Axis2 will take
> > > some time and not everyone will be able to switch over right away (or any
> > > time soon) so I saw
> > > no harm (but a lot of benefit) to giving people the option of using some of
> > > my changes to support
> > > things like better WSA and RM support.
> > >   As to your comment about me taking Axis1 where it hasn't gone before - I'm
> > > no so sure that's
> > > true.  Axis has changed over time - I remember way back when (old timer talk
> > > :-)   Axis was
> > > supposed to be a generic messaging engine and supporting SOAP was just one
> > > of the options.
> > > Since then Axis has changed and its pretty clear its a web service
> > > engine/processor.  Changes that
> > > are made that help it support the new WS specs is still taking it down its
> > > current path, IMO.  Adding
> > > the notion of new plug-points, aside from handlers, isn't that radical
> > > either - being able to plug-in
> > > different loggers or xml parsers isn't done thru handlers either.
> > >   In terms of future plans, I (and probably the rest of the axis1 community)
> > > will probably move to
> > > axis2 at some point - but in the meantime I'd like to share some of the
> > > benefits of these changes
> > > with others.  As I've said before, my primary rule with these changes is to
> > > not break existing code,
> > > so if people don't like these new extensions or plug-ins they are not
> > > required to use them.  But I feel
> > > pretty confident in their ability to work properly since I've been using
> > > them for several years now.
> > > And I do not intent to just "dump and run" - I fully intent to support them
> > > and fix bugs as they pop-up.
> > > I plan on continuing to use this myself for quite some time.  Hopefully,
> > > this help.
> > > thanks
> > > -Doug
> > >
> > >
> > > Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/13/2006 10:36:26 AM:
> > >
> > >  > On Mon, 2006-02-13 at 10:16 -0500, Doug Davis wrote:
> > >  > >
> > >  > > Done - apologies for not explaining this a bit more in the svn
> > >  > > commit... the changes that Dims
> > >  > > is referring to are the couple of lines in the AxisEngines that make
> > >  > > calls out to RM code
> > >  > > and Security code.  These do not assume any particulat implementation
> > >  > > choice - they
> > >  > > are totally pluggable.  In principle I agree that doing these things
> > >  > > as handlers would be
> > >  > > the way to go, however, in working with these specs I've found that
> > >  > > when you start to
> > >  > > look at their requirements it shows that the handlers can't really
> > >  > > meet their needs.
> > >  >
> > >  > Doug, these are some of the reasons we started on Axis2. There are many
> > >  > design points in Axis2 to enable this stuff to be done. So far the Axis1
> > >  > community has been content with saying "we're moving to axis2" when it
> > >  > came to this kind of stuff and overall evolution in general.
> > >  >
> > >  > The last time I asked you about it you said "yes some of the old timers
> > >  > have agreed privately."
> > >  >
> > >  > I am no longer willing to accept that and would like a discussion on the
> > >  > list on how much of "a few lines of code" changes to make to Axis1 to
> > >  > take it where it hasn't gone before (;-)). From comments from both Glen
> > >  > and Dims it not clear they agreed these are changes we want to make and
> > >  > they are as "old timers" as its gets with Axis1.
> > >  >
> > >  > Can you indicate what your plans are any why we're doing this? We need
> > >  > to have a discussion of the direction and have a vote on it amongst the
> > >  > community before making any more changes; you're burning into Axis1
> > >  > stuff that's by design meant to go in handlers .. and that's not a
> > >  > simple change *even if its a few lines of code*.
> > >  >
> > >  > Sanjiva.
> > >  >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>


--
Davanum Srinivas : http://wso2.com/blogs/

Re: Please revert this - and a proposal

Posted by Davanum Srinivas <da...@gmail.com>.
Doug,

Can you please move all your changes to the proposals? (including wsa)
http://svn.apache.org/repos/asf/webservices/axis/trunk/proposals/dug/

Once you are ready with all tests working, tck passing, etc. then
write up a detailed proposal with changes, put it for a VOTE and go on
from there?

Let's get back HEAD in the shape it was before (modulo the failures :)

thanks,
dims



On 2/13/06, Davanum Srinivas <da...@gmail.com> wrote:
> Dug,
>
> - Have u set your self up with the TCK stuff? Can u run the automatic
> tck test harness and make sure nothing is broken?
> - Are there existing issues in JIRA which will be fixed with your changes?
>
> thanks,
> dims
>
> On 2/13/06, Doug Davis <du...@us.ibm.com> wrote:
> >
> > Sanjiva,
> >   Let me first say that I am in no way against the general idea of people
> > from to axis2 - from what
> > I've seen and heard of the new architecture it sounds like a very positive
> > thing.  My desire to
> > integrate these changes into axis1 is based on a couple of things:  first,
> > in previous interop events
> > I've been to I saw some of the difficulty the axis1 guys had in getting
> > things to work and I believe
> > that part of that was because of the limitations they were trying to live
> > under (ie. just handlers).
> > During that time, for my own purposes, I did have a version of Axis1 that
> > could handle those
> > cases and IMO did it w/o a major change to Axis1 so after struggling thru
> > the pains of IBM legal
> > (you know what that's like! :-)   I finally got permission to contribute
> > them - and am working on
> > more.  So, since I had these changes ready to go I thought that it made
> > sense to help out the
> > existing axis1 community by contributing them.  The migration from Axis1 to
> > Axis2 will take
> > some time and not everyone will be able to switch over right away (or any
> > time soon) so I saw
> > no harm (but a lot of benefit) to giving people the option of using some of
> > my changes to support
> > things like better WSA and RM support.
> >   As to your comment about me taking Axis1 where it hasn't gone before - I'm
> > no so sure that's
> > true.  Axis has changed over time - I remember way back when (old timer talk
> > :-)   Axis was
> > supposed to be a generic messaging engine and supporting SOAP was just one
> > of the options.
> > Since then Axis has changed and its pretty clear its a web service
> > engine/processor.  Changes that
> > are made that help it support the new WS specs is still taking it down its
> > current path, IMO.  Adding
> > the notion of new plug-points, aside from handlers, isn't that radical
> > either - being able to plug-in
> > different loggers or xml parsers isn't done thru handlers either.
> >   In terms of future plans, I (and probably the rest of the axis1 community)
> > will probably move to
> > axis2 at some point - but in the meantime I'd like to share some of the
> > benefits of these changes
> > with others.  As I've said before, my primary rule with these changes is to
> > not break existing code,
> > so if people don't like these new extensions or plug-ins they are not
> > required to use them.  But I feel
> > pretty confident in their ability to work properly since I've been using
> > them for several years now.
> > And I do not intent to just "dump and run" - I fully intent to support them
> > and fix bugs as they pop-up.
> > I plan on continuing to use this myself for quite some time.  Hopefully,
> > this help.
> > thanks
> > -Doug
> >
> >
> > Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/13/2006 10:36:26 AM:
> >
> >  > On Mon, 2006-02-13 at 10:16 -0500, Doug Davis wrote:
> >  > >
> >  > > Done - apologies for not explaining this a bit more in the svn
> >  > > commit... the changes that Dims
> >  > > is referring to are the couple of lines in the AxisEngines that make
> >  > > calls out to RM code
> >  > > and Security code.  These do not assume any particulat implementation
> >  > > choice - they
> >  > > are totally pluggable.  In principle I agree that doing these things
> >  > > as handlers would be
> >  > > the way to go, however, in working with these specs I've found that
> >  > > when you start to
> >  > > look at their requirements it shows that the handlers can't really
> >  > > meet their needs.
> >  >
> >  > Doug, these are some of the reasons we started on Axis2. There are many
> >  > design points in Axis2 to enable this stuff to be done. So far the Axis1
> >  > community has been content with saying "we're moving to axis2" when it
> >  > came to this kind of stuff and overall evolution in general.
> >  >
> >  > The last time I asked you about it you said "yes some of the old timers
> >  > have agreed privately."
> >  >
> >  > I am no longer willing to accept that and would like a discussion on the
> >  > list on how much of "a few lines of code" changes to make to Axis1 to
> >  > take it where it hasn't gone before (;-)). From comments from both Glen
> >  > and Dims it not clear they agreed these are changes we want to make and
> >  > they are as "old timers" as its gets with Axis1.
> >  >
> >  > Can you indicate what your plans are any why we're doing this? We need
> >  > to have a discussion of the direction and have a vote on it amongst the
> >  > community before making any more changes; you're burning into Axis1
> >  > stuff that's by design meant to go in handlers .. and that's not a
> >  > simple change *even if its a few lines of code*.
> >  >
> >  > Sanjiva.
> >  >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>


--
Davanum Srinivas : http://wso2.com/blogs/

Re: Please revert this - and a proposal

Posted by Davanum Srinivas <da...@gmail.com>.
Dug,

- Have u set your self up with the TCK stuff? Can u run the automatic
tck test harness and make sure nothing is broken?
- Are there existing issues in JIRA which will be fixed with your changes?

thanks,
dims

On 2/13/06, Doug Davis <du...@us.ibm.com> wrote:
>
> Sanjiva,
>   Let me first say that I am in no way against the general idea of people
> from to axis2 - from what
> I've seen and heard of the new architecture it sounds like a very positive
> thing.  My desire to
> integrate these changes into axis1 is based on a couple of things:  first,
> in previous interop events
> I've been to I saw some of the difficulty the axis1 guys had in getting
> things to work and I believe
> that part of that was because of the limitations they were trying to live
> under (ie. just handlers).
> During that time, for my own purposes, I did have a version of Axis1 that
> could handle those
> cases and IMO did it w/o a major change to Axis1 so after struggling thru
> the pains of IBM legal
> (you know what that's like! :-)   I finally got permission to contribute
> them - and am working on
> more.  So, since I had these changes ready to go I thought that it made
> sense to help out the
> existing axis1 community by contributing them.  The migration from Axis1 to
> Axis2 will take
> some time and not everyone will be able to switch over right away (or any
> time soon) so I saw
> no harm (but a lot of benefit) to giving people the option of using some of
> my changes to support
> things like better WSA and RM support.
>   As to your comment about me taking Axis1 where it hasn't gone before - I'm
> no so sure that's
> true.  Axis has changed over time - I remember way back when (old timer talk
> :-)   Axis was
> supposed to be a generic messaging engine and supporting SOAP was just one
> of the options.
> Since then Axis has changed and its pretty clear its a web service
> engine/processor.  Changes that
> are made that help it support the new WS specs is still taking it down its
> current path, IMO.  Adding
> the notion of new plug-points, aside from handlers, isn't that radical
> either - being able to plug-in
> different loggers or xml parsers isn't done thru handlers either.
>   In terms of future plans, I (and probably the rest of the axis1 community)
> will probably move to
> axis2 at some point - but in the meantime I'd like to share some of the
> benefits of these changes
> with others.  As I've said before, my primary rule with these changes is to
> not break existing code,
> so if people don't like these new extensions or plug-ins they are not
> required to use them.  But I feel
> pretty confident in their ability to work properly since I've been using
> them for several years now.
> And I do not intent to just "dump and run" - I fully intent to support them
> and fix bugs as they pop-up.
> I plan on continuing to use this myself for quite some time.  Hopefully,
> this help.
> thanks
> -Doug
>
>
> Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/13/2006 10:36:26 AM:
>
>  > On Mon, 2006-02-13 at 10:16 -0500, Doug Davis wrote:
>  > >
>  > > Done - apologies for not explaining this a bit more in the svn
>  > > commit... the changes that Dims
>  > > is referring to are the couple of lines in the AxisEngines that make
>  > > calls out to RM code
>  > > and Security code.  These do not assume any particulat implementation
>  > > choice - they
>  > > are totally pluggable.  In principle I agree that doing these things
>  > > as handlers would be
>  > > the way to go, however, in working with these specs I've found that
>  > > when you start to
>  > > look at their requirements it shows that the handlers can't really
>  > > meet their needs.
>  >
>  > Doug, these are some of the reasons we started on Axis2. There are many
>  > design points in Axis2 to enable this stuff to be done. So far the Axis1
>  > community has been content with saying "we're moving to axis2" when it
>  > came to this kind of stuff and overall evolution in general.
>  >
>  > The last time I asked you about it you said "yes some of the old timers
>  > have agreed privately."
>  >
>  > I am no longer willing to accept that and would like a discussion on the
>  > list on how much of "a few lines of code" changes to make to Axis1 to
>  > take it where it hasn't gone before (;-)). From comments from both Glen
>  > and Dims it not clear they agreed these are changes we want to make and
>  > they are as "old timers" as its gets with Axis1.
>  >
>  > Can you indicate what your plans are any why we're doing this? We need
>  > to have a discussion of the direction and have a vote on it amongst the
>  > community before making any more changes; you're burning into Axis1
>  > stuff that's by design meant to go in handlers .. and that's not a
>  > simple change *even if its a few lines of code*.
>  >
>  > Sanjiva.
>  >
>


--
Davanum Srinivas : http://wso2.com/blogs/

Re: Please revert this - and a proposal

Posted by Doug Davis <du...@us.ibm.com>.
Sanjiva,
  Let me first say that I am in no way against the general idea of people 
from to axis2 - from what
I've seen and heard of the new architecture it sounds like a very positive 
thing.  My desire to 
integrate these changes into axis1 is based on a couple of things:  first, 
in previous interop events
I've been to I saw some of the difficulty the axis1 guys had in getting 
things to work and I believe
that part of that was because of the limitations they were trying to live 
under (ie. just handlers). 
During that time, for my own purposes, I did have a version of Axis1 that 
could handle those
cases and IMO did it w/o a major change to Axis1 so after struggling thru 
the pains of IBM legal
(you know what that's like! :-)   I finally got permission to contribute 
them - and am working on 
more.  So, since I had these changes ready to go I thought that it made 
sense to help out the
existing axis1 community by contributing them.  The migration from Axis1 
to Axis2 will take
some time and not everyone will be able to switch over right away (or any 
time soon) so I saw
no harm (but a lot of benefit) to giving people the option of using some 
of my changes to support
things like better WSA and RM support.
  As to your comment about me taking Axis1 where it hasn't gone before - 
I'm no so sure that's
true.  Axis has changed over time - I remember way back when (old timer 
talk :-)   Axis was 
supposed to be a generic messaging engine and supporting SOAP was just one 
of the options.
Since then Axis has changed and its pretty clear its a web service 
engine/processor.  Changes that
are made that help it support the new WS specs is still taking it down its 
current path, IMO.  Adding
the notion of new plug-points, aside from handlers, isn't that radical 
either - being able to plug-in
different loggers or xml parsers isn't done thru handlers either. 
  In terms of future plans, I (and probably the rest of the axis1 
community) will probably move to
axis2 at some point - but in the meantime I'd like to share some of the 
benefits of these changes
with others.  As I've said before, my primary rule with these changes is 
to not break existing code,
so if people don't like these new extensions or plug-ins they are not 
required to use them.  But I feel
pretty confident in their ability to work properly since I've been using 
them for several years now. 
And I do not intent to just "dump and run" - I fully intent to support 
them and fix bugs as they pop-up.
I plan on continuing to use this myself for quite some time.  Hopefully, 
this help.
thanks
-Doug


Sanjiva Weerawarana <sa...@opensource.lk> wrote on 02/13/2006 10:36:26 
AM:

> On Mon, 2006-02-13 at 10:16 -0500, Doug Davis wrote:
> > 
> > Done - apologies for not explaining this a bit more in the svn
> > commit... the changes that Dims 
> > is referring to are the couple of lines in the AxisEngines that make
> > calls out to RM code 
> > and Security code.  These do not assume any particulat implementation
> > choice - they 
> > are totally pluggable.  In principle I agree that doing these things
> > as handlers would be 
> > the way to go, however, in working with these specs I've found that
> > when you start to 
> > look at their requirements it shows that the handlers can't really
> > meet their needs. 
> 
> Doug, these are some of the reasons we started on Axis2. There are many
> design points in Axis2 to enable this stuff to be done. So far the Axis1
> community has been content with saying "we're moving to axis2" when it
> came to this kind of stuff and overall evolution in general.
> 
> The last time I asked you about it you said "yes some of the old timers
> have agreed privately." 
> 
> I am no longer willing to accept that and would like a discussion on the
> list on how much of "a few lines of code" changes to make to Axis1 to
> take it where it hasn't gone before (;-)). From comments from both Glen
> and Dims it not clear they agreed these are changes we want to make and
> they are as "old timers" as its gets with Axis1. 
> 
> Can you indicate what your plans are any why we're doing this? We need
> to have a discussion of the direction and have a vote on it amongst the
> community before making any more changes; you're burning into Axis1
> stuff that's by design meant to go in handlers .. and that's not a
> simple change *even if its a few lines of code*. 
> 
> Sanjiva.
>