commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [5.0] fileupload 1.0 RC 1 API breakage
Date Wed, 04 Jun 2003 17:18:29 GMT

On Wed, 4 Jun 2003, Glenn Nielsen wrote:

> Martin Cooper wrote:
> > I posted a patch to the Tomcat-Dev list yesterday which should fix this
> > problem. Apparently, nobody on the Tomcat-Dev list paid any attention to
> > my post. The methods in question have been deprecated for some time.
> >
> I have not seen the patch email on tomcat-dev.  Perhaps its in the moderator
> queue.  BTW, use of FileUpload was implemented in Tomcat once there was a
> Beta release of FileUpload. So the API must have changed since the Beta release.

I don't think it's in the moderator queue, since it showed up in the GMane
newsgroup already. Perhaps I should have made it more obvious - I replied
to the Gump failure message, thinking that people would pay attention to
those, and supplied a patch to fix the Gump failure.

Yes, the API has changed since Beta 1.

> > I have gone out of my way to help FileUpload clients avoid exactly this
> > kind of issue. It really ticks me off to see this kind of message, when I
> > have gone to great lengths to make sure that the clients I know about are
> > made aware of the changes before they happen.
> >
> Thats great that you performed notifications to known clients.  :-) Somehow
> Tomcat slipped through the cracks.  :-( I don't recall seeing anything about
> this on the Tomcat list.  I wlll admit that I subscribe to commons-dev but
> often don't keep up with messages related to the code bases there I am interested in.
> > Get your own act together, Tomcat developers, before you start pointing
> > the finger at those of us who really try hard to maintain compatibility
> > across Jakarta projects.
> >
> Was this really necessary?  The email below went to both the commons-dev and
> tomcat -dev lists.  If Remy was pointing the finger at anyone, it was at his
> fellow Tomcat Developers.  Thats how I interpreted it.

>From the Tomcat developers' perspective, and if it had been posted only to
tomcat-dev, no, I don't think it was necessary.

>From my perspective, and because it was copied to commons-dev, yes, I do
think it was necessary. Everyone should know that nightly builds are wide
open as far as changes go. But it seems that any time I even touch the
FileUpload API, I get complaints when a nightly build fails. This time, it
was from the Tomcat folks. The last time, it was from the Tapestry folks.

When I change the API, I look to see who declares a dependency on it in
Gump, and then look to see if the associated Gump build fails. In this
case, the Tomcat Gump build failed, and I supplied a patch. In the case of
Tapestry, they keep their Gump descriptor to themselves, so I wasn't aware
of the dependency. In any case, I suspect that I go further to keep Gump
builds happy than most other people do.

> We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal.

Thank you.

Martin Cooper

> Regards,
> Glenn
> > --
> > Martin Cooper
> >
> >
> > On Wed, 4 Jun 2003, Remy Maucherat wrote:
> >
> >
> >>FileUpload.setRepositoryPath(String) and FileItem(String) were removed
> >>from the fileupload RC 1 release, which breaks the Tomcat 4.1.x and
> >>5.0.x build. The first method has no apparent replacement (but I didn't
> >>try to dig around).
> >>
> >>This is clearly an unacceptable situation from the Tomcat perspective
> >>:-( I'm hoping there can be positive solutions to the problem ...
> >>
> >>Remy
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> >>For additional commands, e-mail:
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message