Re: svn commit: r450121 - in /webservices/axis2/trunk/java/modules: integration/test/org/apache/axis2/engine/ kernel/src/org/apache/axis2/context/ kernel/src/org/apache/axis2/engine/ kernel/src/org/apache/axis2/handlers/ kernel/src/org/apache/axis2/t

[Thilina Gunarathne <cs...@gmail.com>]

Hi All,

> While the JIRA issue may have had "cleanup" in the title, points 2 and 3
> of the issue (and also Deepal's later comments) deal with what I fixed.
Actually I let it remain it as a blocker due to the "cleanup" issue
(even though lately I was considering to reduce the priority)..

This API change at this moment is going to affect many other modules
which are not inside Axis2..Also we are planning for a RC & code
freeze in another one or two days. I doubt whether we have enough time
to test everything with this change. We have seen that lot of people
were  trying out and testing Axis2 using the snapshots for some time..

I'm not at all positive for doing major change like this at the last
moment. My main concern at this point is to make the current features
solid.. I would like if you can consider doing this after the
branching...

Thanks,
Thilina


>
> I'm not sure that I understand why you say "the impl that has been
> committed is going to slow Axis2 down big time."  It makes one extra
> method invocation to each phase, which in turn makes one extra method
> call to each handler that was previously invoked for each message flow.
> If the handlers don't need to do anything, then that time is negligible
> -- if they do need to do something, then they need to do the work, and
> spend the time for a reason.
>
> -Bill
>
>
> On Wed, 2006-09-27 at 09:58 +0530, Sanjiva Weerawarana wrote:
> > Hi Bill,
> >
> > > This change actually addresses part of a JIRA issue that was marked as a
> > > "blocker" (AXIS2-653), and according to Thilina's post these are to be
> > > fixed before the release.  (I will address the other part as well, but
> > > there were two separate issues so I separated this one out and tackled
> > > if first.)
> >
> > I think the original issue which was marked a blocker was that cleanup()
> > wasn't called. That's not what's implemented by this patch.
> >
> > I am not opposed to solving the problem you want to solve with this
> > patch but the impl that has been committed is going to slow Axis2 down
> > big time. We have discussed the problem but IIRC didn't come to a
> > consensus on the solution. I'd really rather work thru this more before
> > we do it. If a performance degrading solution is the only one then I'd
> > like to think long and hard about it before doing it.
> >
> > We've gotten hammered on the user mailing list for having stuff that is
> > not fully baked in a major release. Doing this now (literally 2 days
> > before the planned code freeze) is going to put in something that hasn't
> > been tried, tested and proven into a major release.
> >
> > So, I'd like to request that we remove the blocker status on this issue
> > and revert this patch. My apologies but I'm not lifting my -1 on this
> > patch.
> >
> > I guess I should be arguing with the release manager for leaving this as
> > a blocker!
> >
> > Let's pick it up after 1.1 and sort it out. ApacheCon US would be a
> > great time to do it if you'll be around there.
> >
> > Sanjiva.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-cvs-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-cvs-help@ws.apache.org
>
>


-- 
http://webservices.apache.org/~thilina/
http://thilinag.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-cvs-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-cvs-help@ws.apache.org