You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Remy Maucherat <re...@apache.org> on 2003/06/04 09:09:39 UTC
[5.0] fileupload 1.0 RC 1 API breakage
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Bill Barker <wb...@wilshire.com>.
The attached works for me (against commons-fileupload HEAD). I didn't do
anything about it since I wasn't sure which version of fileupload we were
targeting.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>; "Jakarta
Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, June 04, 2003 12:09 AM
Subject: [5.0] fileupload 1.0 RC 1 API breakage
> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Martin Cooper <ma...@apache.org>.
On Wed, 4 Jun 2003, Henning Schmiedehausen wrote:
> In hometree.jakarta.commons.dev you write:
>
> [Turbine-Dev as Cc for a Heads Up]
>
> Hi,
>
> as we (Turbine) might have that problem too (I'm currently shaping up
> our jar dependencies for an upcoming 2.3rc1 release of Turbine and
> we're still at 1.0-beta-1 with fileupload but will definitely go to
> the RC / release of commons-fileupload), could you please point me at
> the patch / send it to me? Thanks.
The patch (against HEAD of jakarta-tomcat-4.0 is attached.
>
> >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 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.
>
> Just tell me what we need to do. However, you seem to have missed that
> Turbine is using commons-fileupload.
No, I didn't miss that. I know Turbine is dependent on FileUpload, since
that is where the original code base came from. However, I was waiting for
a FileUpload-related Gump failure to tell me what broke, and then I would
have posted a patch. The problem is that it seems the Turbine Gump build
is failing because of a prereq failure, so it didn't get far enough to
break because of FileUpload changes. ;-)
--
Martin Cooper
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Henning Schmiedehausen <he...@intermeta.de>.
In hometree.jakarta.commons.dev you write:
[Turbine-Dev as Cc for a Heads Up]
Hi,
as we (Turbine) might have that problem too (I'm currently shaping up
our jar dependencies for an upcoming 2.3rc1 release of Turbine and
we're still at 1.0-beta-1 with fileupload but will definitely go to
the RC / release of commons-fileupload), could you please point me at
the patch / send it to me? Thanks.
>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 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.
Just tell me what we need to do. However, you seem to have missed that
Turbine is using commons-fileupload.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:38 -0500 6/4/03, Glenn Nielsen wrote:
>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.
Martin has been busting his tail trying to get FileUpload released so
that Struts can make a full 1.1 release, and I'm sure he's just a
little frustrated that other projects which have a dependency on the
library aren't participating very much in the bug cleanup, or,
apparently, the commons-dev mailing list where this was discussed
thoroughly before the change happened. In fact, Martin was reluctant
to remove the deprecated methods completely, and other developers
here on commons-dev pointed out that there is no guarantee of API in
unreleased software.
When I read the message from Remy, I read it as a jab at FileUpload.
And since Martin has basically been a one-man FileUpload team for
several weeks (while being busy in his real life), he took it
personally. Rereading Remy's message, I can see why Glenn read it as
being "spoken to" the tomcat-dev list, with commons-dev as more of a
'cc'. But that's not how I read it originally.
I'd think at least one committer on any major open-source project
should be committed to monitoring the status of each library that
project depends on -- if someone had been doing that, this would not
have been a surprise.
Just a bystander...
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Remy Maucherat <re...@apache.org>.
Glenn Nielsen wrote:
> Martin Cooper wrote:
>
>> 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.
>
> We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no
> big deal.
Sorry for the tone of the original email; I wasn't upset anyway, it was
just a quickly drafted email this morning before leaving to work (having
no access to my Apache email during the day).
BTW, I am not subscribed to commons-dev. I saw about the new Disk*
classes browsing archives, but didn't do a parallel.
One last note: IMO, as a rule (and esp in the commons), you should make
every effort to avoid breaking the API between a beta and a final.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Remy Maucherat <re...@apache.org>.
Glenn Nielsen wrote:
> Martin Cooper wrote:
>
>> 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.
>
> We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no
> big deal.
Sorry for the tone of the original email; I wasn't upset anyway, it was
just a quickly drafted email this morning before leaving to work (having
no access to my Apache email during the day).
BTW, I am not subscribed to commons-dev. I saw about the new Disk*
classes browsing archives, but didn't do a parallel.
One last note: IMO, as a rule (and esp in the commons), you should make
every effort to avoid breaking the API between a beta and a final.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Martin Cooper <ma...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:38 -0500 6/4/03, Glenn Nielsen wrote:
>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.
Martin has been busting his tail trying to get FileUpload released so
that Struts can make a full 1.1 release, and I'm sure he's just a
little frustrated that other projects which have a dependency on the
library aren't participating very much in the bug cleanup, or,
apparently, the commons-dev mailing list where this was discussed
thoroughly before the change happened. In fact, Martin was reluctant
to remove the deprecated methods completely, and other developers
here on commons-dev pointed out that there is no guarantee of API in
unreleased software.
When I read the message from Remy, I read it as a jab at FileUpload.
And since Martin has basically been a one-man FileUpload team for
several weeks (while being busy in his real life), he took it
personally. Rereading Remy's message, I can see why Glenn read it as
being "spoken to" the tomcat-dev list, with commons-dev as more of a
'cc'. But that's not how I read it originally.
I'd think at least one committer on any major open-source project
should be committed to monitoring the status of each library that
project depends on -- if someone had been doing that, this would not
have been a surprise.
Just a bystander...
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Glenn Nielsen <gl...@mail.more.net>.
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 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.
We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal.
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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Glenn Nielsen <gl...@mail.more.net>.
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 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.
We (tomcat devs) will fix use of FileUpload in Tomcat and move on, no big deal.
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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [5.0] fileupload 1.0 RC 1 API breakage
Posted by Martin Cooper <ma...@apache.org>.
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 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.
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.
--
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org