You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2003/06/03 16:32:02 UTC
[5.0] Commons dependencies
Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot
of stuff from the Commons. Most of those are in a stable state, but a
few are either in between two stable releases, or not yet released.
Here's the list of the components which will need to be released as
stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
for the component, based on past interactions with the components.
- el: Core JSP 2.0 feature; this is a critical component, and needs to
get released simultaneaously with Tomcat 5; I think a RM is needed for
that component [Kin-Man, Jan, Craig ?]
- modeler: Basis for Tomcat 5 JMX features, with a lot of new
impressively efficient functionality since release 1.0; again, a
critical component [Costin (do you have enough time to continue being
the RM of that component ?)]
- daemon: Home of Mladen's procrun, a very promising exe wrapper for
Java programs on Windows; this also contains a Unix wrapper for Java
programs; the Unix wrapper could be advertised as "the" recommended
solution to run Tomcat on 80 on Unix, and included as source with
Tomcat's binary d/l; this component is currently in the sandbox, and
would need to be either moved ASAP to commons proper, or be migrated to
j-t-c (if thought to be too Tomcat specific to exist in the commons); a
RM will be needed [Mladen, Jean-Frederic]
- dbcp: There are some BZ issues related to DBCP, so if there's a new
DBCP release (I've seen some Struts 1.1 related activity), we'll need to
include it [Glenn]
- fileupload: Used by the HTML manager to upload the webapp to be
deployed; 1.0 RC 1 is soon to be released, with an API breakage
(deprecated method removal between beta releases (TM)); 1.0 is supposed
to occur before Struts 1.1 [Glenn]
I think that's it for now.
About the daemon Unix wrapper: there was some proprietary interfaces
defined in there. It was agreed some time ago to use reflection instead
of these interfaces; looking at the native code, the interfaces are
still being used. Could that be fixed ?
Comments ?
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] Commons dependencies
Posted by Glenn Nielsen <gl...@mail.more.net>.
I will take care of the HTML Manager and file upload if no one else gets to it.
Same for a reveiw of DBCP. But I won't have time until next week.
Regards,
Glenn
Remy Maucherat wrote:
> Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot
> of stuff from the Commons. Most of those are in a stable state, but a
> few are either in between two stable releases, or not yet released.
>
> Here's the list of the components which will need to be released as
> stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
> for the component, based on past interactions with the components.
>
> - el: Core JSP 2.0 feature; this is a critical component, and needs to
> get released simultaneaously with Tomcat 5; I think a RM is needed for
> that component [Kin-Man, Jan, Craig ?]
>
> - modeler: Basis for Tomcat 5 JMX features, with a lot of new
> impressively efficient functionality since release 1.0; again, a
> critical component [Costin (do you have enough time to continue being
> the RM of that component ?)]
>
> - daemon: Home of Mladen's procrun, a very promising exe wrapper for
> Java programs on Windows; this also contains a Unix wrapper for Java
> programs; the Unix wrapper could be advertised as "the" recommended
> solution to run Tomcat on 80 on Unix, and included as source with
> Tomcat's binary d/l; this component is currently in the sandbox, and
> would need to be either moved ASAP to commons proper, or be migrated to
> j-t-c (if thought to be too Tomcat specific to exist in the commons); a
> RM will be needed [Mladen, Jean-Frederic]
>
> - dbcp: There are some BZ issues related to DBCP, so if there's a new
> DBCP release (I've seen some Struts 1.1 related activity), we'll need to
> include it [Glenn]
>
> - fileupload: Used by the HTML manager to upload the webapp to be
> deployed; 1.0 RC 1 is soon to be released, with an API breakage
> (deprecated method removal between beta releases (TM)); 1.0 is supposed
> to occur before Struts 1.1 [Glenn]
>
> I think that's it for now.
>
> About the daemon Unix wrapper: there was some proprietary interfaces
> defined in there. It was agreed some time ago to use reflection instead
> of these interfaces; looking at the native code, the interfaces are
> still being used. Could that be fixed ?
>
> Comments ?
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-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] Commons dependencies
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> Tomcat 5.0.x, like many other major Jakarta projects, depends on a lot
> of stuff from the Commons. Most of those are in a stable state, but a
> few are either in between two stable releases, or not yet released.
>
> Here's the list of the components which will need to be released as
> stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
> for the component, based on past interactions with the components.
>
> - el: Core JSP 2.0 feature; this is a critical component, and needs to
> get released simultaneaously with Tomcat 5; I think a RM is needed for
> that component [Kin-Man, Jan, Craig ?]
>
> - modeler: Basis for Tomcat 5 JMX features, with a lot of new
> impressively efficient functionality since release 1.0; again, a
> critical component [Costin (do you have enough time to continue being
> the RM of that component ?)]
>
> - daemon: Home of Mladen's procrun, a very promising exe wrapper for
> Java programs on Windows; this also contains a Unix wrapper for Java
> programs; the Unix wrapper could be advertised as "the" recommended
> solution to run Tomcat on 80 on Unix, and included as source with
> Tomcat's binary d/l; this component is currently in the sandbox, and
> would need to be either moved ASAP to commons proper, or be migrated to
> j-t-c (if thought to be too Tomcat specific to exist in the commons); a
> RM will be needed [Mladen, Jean-Frederic]
The daemon moved from tomcat to common and now back to tomcat. That does not
help to advertise the project.
>
> - dbcp: There are some BZ issues related to DBCP, so if there's a new
> DBCP release (I've seen some Struts 1.1 related activity), we'll need to
> include it [Glenn]
>
> - fileupload: Used by the HTML manager to upload the webapp to be
> deployed; 1.0 RC 1 is soon to be released, with an API breakage
> (deprecated method removal between beta releases (TM)); 1.0 is supposed
> to occur before Struts 1.1 [Glenn]
>
> I think that's it for now.
>
> About the daemon Unix wrapper: there was some proprietary interfaces
> defined in there. It was agreed some time ago to use reflection instead
> of these interfaces; looking at the native code, the interfaces are
> still being used. Could that be fixed ?
Sure.
>
> Comments ?
Does someone has one example of code using reflection?
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-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] Commons dependencies
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Remy & others,
>
>
>>Here's the list of the components which will need to be released as
>>stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
>>for the component, based on past interactions with the components.
>>
>>- el: Core JSP 2.0 feature; this is a critical component, and needs to
>>get released simultaneaously with Tomcat 5; I think a RM is needed for
>>that component [Kin-Man, Jan, Craig ?]
>
>
> I'll take this one. What exactly does being a RM involve?
In order:
- post a release plan (and have people vote)
- tag and release a beta
- fix BZ items
- propose and vote for a final
- tag and release a final
There are plenty of examples on how to package a release in commons,
since there are so many components having already been released.
If everything else fails, do what people usually do: ask Craig :-D
> commons-el currently has version 1.0, and it's been tagged with
> TOMCAT_5_0_2.
Well, as far as I am concerned, commons-el 1.0 does not exist yet ;-)
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] Commons dependencies
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy & others,
> Here's the list of the components which will need to be released as
> stable before Tomcat 5.0 gets stable. I'm associating a proposed "owner"
> for the component, based on past interactions with the components.
>
> - el: Core JSP 2.0 feature; this is a critical component, and needs to
> get released simultaneaously with Tomcat 5; I think a RM is needed for
> that component [Kin-Man, Jan, Craig ?]
I'll take this one. What exactly does being a RM involve?
commons-el currently has version 1.0, and it's been tagged with
TOMCAT_5_0_2.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] More dependencies
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> In this email, I forgot to speak about other commons (and others)
> dependencies. Thanks for all the volunteering, BTW, it really helps
> (damn day job ...) :)
+1 :-)
> JMX: I think we should try to ship with JMX 1.2 + a JSR 160
> implementation if possible. I really hope MX4J will be able to provide
> that.
I think we must ship with JMX1.2 - AFAIK MX4J is close, but it may be better
to use JMX-RI for this one. If I remember the terms on the licence are
different from the previous one - but someone should confirm if we can
redistribute it.
> Tyrex: This project seems dead (unfortunately) :-( We could replace it
> with some other TM, or (I like that one better) not provide an object
> factory implementation for UserTransaction by default, and let third
> parties provide it. That model seems to work great for J2EE providers
> (JOTM, OpenEJB, etc).
+1 on no TM. If someone needs a TM - he can choose whatever fits. This will
also reduce the size of tomcat :-)
> Struts: We need 1.1 ! (I think the rest of the world does also :-D)
>
> Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's called)
> ?
>
> Remy
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] More dependencies
Posted by Remy Maucherat <re...@apache.org>.
Jean-Francois Arcand wrote:
> Remy Maucherat wrote:
>> commons-launcher: Problem; I think I did release 0.9 with Patrick Luby
>> a long time ago, and the component has been dead since. Reviving it
>> and putting a websiter up could help, but it's not certain. This piece
>> of code was developed for the Sun web services pack 1.0 originally.
>> Does anyone use it anymore ? Can it be removed (in favor of native
>> wrappers) ? I have to admit it was quite nice, so I'd rather not have
>> to remove it.
>
> Yes, jwsdp 1.2 is still using it. I also think we should keep it.
Cool. IMO it's good enough to be released, and quite useful :) So we
need to do a release then.
>> Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's
>> called) ?
>
> I'm unaware of such packages (but I will double check).
Well, there must be something to test the new specs, right ? Esp JSP 2.0 ...
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] More dependencies
Posted by Jean-Francois Arcand <Je...@Sun.COM>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>
>> - daemon: Home of Mladen's procrun, a very promising exe wrapper for
>> Java programs on Windows; this also contains a Unix wrapper for Java
>> programs; the Unix wrapper could be advertised as "the" recommended
>> solution to run Tomcat on 80 on Unix, and included as source with
>> Tomcat's binary d/l; this component is currently in the sandbox, and
>> would need to be either moved ASAP to commons proper, or be migrated
>> to j-t-c (if thought to be too Tomcat specific to exist in the
>> commons); a RM will be needed [Mladen, Jean-Frederic]
>
>
> In this email, I forgot to speak about other commons (and others)
> dependencies. Thanks for all the volunteering, BTW, it really helps
> (damn day job ...) :)
>
> commons-collection: No problem.
>
> commons-beanutils: No problem.
>
> commons-launcher: Problem; I think I did release 0.9 with Patrick Luby a
> long time ago, and the component has been dead since. Reviving it and
> putting a websiter up could help, but it's not certain. This piece of
> code was developed for the Sun web services pack 1.0 originally. Does
> anyone use it anymore ? Can it be removed (in favor of native wrappers)
> ? I have to admit it was quite nice, so I'd rather not have to remove it.
Yes, jwsdp 1.2 is still using it. I also think we should keep it.
>
> commons-digester: No problem.
>
> commons-logging: No problem.
>
> commons-pool: No problem.
>
> JMX: I think we should try to ship with JMX 1.2 + a JSR 160
> implementation if possible. I really hope MX4J will be able to provide
> that.
>
> Tyrex: This project seems dead (unfortunately) :-( We could replace it
> with some other TM, or (I like that one better) not provide an object
> factory implementation for UserTransaction by default, and let third
> parties provide it. That model seems to work great for J2EE providers
> (JOTM, OpenEJB, etc).
>
> Struts: We need 1.1 ! (I think the rest of the world does also :-D)
>
> Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's
> called) ?
I'm unaware of such packages (but I will double check).
-- Jeanfrancois
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-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] More dependencies
Posted by Costin Manolache <cm...@yahoo.com>.
Bill Barker wrote:
> I know that at one point there was a problem if you enabled the JMX consol
> (e.g. set mx.port=9000 in jk2.properties). I don't remember if that's
> been fixed.
I think the bug was in our code - i.e. we didn't call stop. I remember
fixing it in jk, if you start the adapter using jk2.properties it should
work.
Costin
>
> But the short answer is, yes the HttpAdapter creates non-daemon threads.
>
> ----- Original Message -----
> From: "Tim Funk" <fu...@joedog.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Thursday, June 05, 2003 2:12 PM
> Subject: Re: [5.0] More dependencies
>
>
>> When I was testing with the HttpAdapter and Sun's JMX 1.2ri, on shutdown
> of
>> tomcat the JVM did not die. If I removed the jar - all was OK. (But of
> course
>> I lost HttpAdapter functionality) Does anyone know if Sun's HttpAdapter
>> creates non-daemon threads? Of course the problem might be in tomcat too,
> I'm
>> sorry for not doing much debugging on this yet.
>>
>> Unfortunately, I was using cygwin and you can't get JVM stacktraces with
> cygwin.
>>
>> Time permitting, I will try testing this on linux box tonight to see what
>> threads are keeping the JVM alive. (Or *gasp* - go back to using the bat
> files)
>>
>> -Tim
>>
>> Remy Maucherat wrote:
>> >
>> > JMX: I think we should try to ship with JMX 1.2 + a JSR 160
>> > implementation if possible. I really hope MX4J will be able to provide
>> > that.
>> >
>> >
>> > Remy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-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] More dependencies
Posted by Bill Barker <wb...@wilshire.com>.
I know that at one point there was a problem if you enabled the JMX consol
(e.g. set mx.port=9000 in jk2.properties). I don't remember if that's been
fixed.
But the short answer is, yes the HttpAdapter creates non-daemon threads.
----- Original Message -----
From: "Tim Funk" <fu...@joedog.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, June 05, 2003 2:12 PM
Subject: Re: [5.0] More dependencies
> When I was testing with the HttpAdapter and Sun's JMX 1.2ri, on shutdown
of
> tomcat the JVM did not die. If I removed the jar - all was OK. (But of
course
> I lost HttpAdapter functionality) Does anyone know if Sun's HttpAdapter
> creates non-daemon threads? Of course the problem might be in tomcat too,
I'm
> sorry for not doing much debugging on this yet.
>
> Unfortunately, I was using cygwin and you can't get JVM stacktraces with
cygwin.
>
> Time permitting, I will try testing this on linux box tonight to see what
> threads are keeping the JVM alive. (Or *gasp* - go back to using the bat
files)
>
> -Tim
>
> Remy Maucherat wrote:
> >
> > JMX: I think we should try to ship with JMX 1.2 + a JSR 160
> > implementation if possible. I really hope MX4J will be able to provide
> > that.
> >
> >
> > Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-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] More dependencies
Posted by Tim Funk <fu...@joedog.org>.
When I was testing with the HttpAdapter and Sun's JMX 1.2ri, on shutdown of
tomcat the JVM did not die. If I removed the jar - all was OK. (But of course
I lost HttpAdapter functionality) Does anyone know if Sun's HttpAdapter
creates non-daemon threads? Of course the problem might be in tomcat too, I'm
sorry for not doing much debugging on this yet.
Unfortunately, I was using cygwin and you can't get JVM stacktraces with cygwin.
Time permitting, I will try testing this on linux box tonight to see what
threads are keeping the JVM alive. (Or *gasp* - go back to using the bat files)
-Tim
Remy Maucherat wrote:
>
> JMX: I think we should try to ship with JMX 1.2 + a JSR 160
> implementation if possible. I really hope MX4J will be able to provide
> that.
>
>
> Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0] More dependencies
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> - daemon: Home of Mladen's procrun, a very promising exe wrapper for
> Java programs on Windows; this also contains a Unix wrapper for Java
> programs; the Unix wrapper could be advertised as "the" recommended
> solution to run Tomcat on 80 on Unix, and included as source with
> Tomcat's binary d/l; this component is currently in the sandbox, and
> would need to be either moved ASAP to commons proper, or be migrated to
> j-t-c (if thought to be too Tomcat specific to exist in the commons); a
> RM will be needed [Mladen, Jean-Frederic]
In this email, I forgot to speak about other commons (and others)
dependencies. Thanks for all the volunteering, BTW, it really helps
(damn day job ...) :)
commons-collection: No problem.
commons-beanutils: No problem.
commons-launcher: Problem; I think I did release 0.9 with Patrick Luby a
long time ago, and the component has been dead since. Reviving it and
putting a websiter up could help, but it's not certain. This piece of
code was developed for the Sun web services pack 1.0 originally. Does
anyone use it anymore ? Can it be removed (in favor of native wrappers)
? I have to admit it was quite nice, so I'd rather not have to remove it.
commons-digester: No problem.
commons-logging: No problem.
commons-pool: No problem.
JMX: I think we should try to ship with JMX 1.2 + a JSR 160
implementation if possible. I really hope MX4J will be able to provide that.
Tyrex: This project seems dead (unfortunately) :-( We could replace it
with some other TM, or (I like that one better) not provide an object
factory implementation for UserTransaction by default, and let third
parties provide it. That model seems to work great for J2EE providers
(JOTM, OpenEJB, etc).
Struts: We need 1.1 ! (I think the rest of the world does also :-D)
Watchdog: (to the Sun folks) Where is Watchdog 5 (or whatever it's called) ?
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 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
[5.0] fileupload 1.0 RC 1 API breakage
Posted by Remy Maucherat <re...@apache.org>.
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
[5.0] fileupload 1.0 RC 1 API breakage
Posted by Remy Maucherat <re...@apache.org>.
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] Commons dependencies
Posted by Jean-Francois Arcand <Je...@Sun.COM>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Remy Maucherat wrote:
>>
>>
>>> - modeler: Basis for Tomcat 5 JMX features, with a lot of new
>>> impressively efficient functionality since release 1.0; again, a
>>> critical component [Costin (do you have enough time to continue being
>>> the RM of that component ?)]
>>
>>
>>
>> I have very little free time - if anyone could do the release it would be
>> great. There are no changes from M1 - I'll check bugzilla to see what
>> remains to be done.
>
>
> Ok, I undertsand; too bad :-(
> Any volunteers ? (again, this is a critical item)
Yes, I can but I have very little experience . If you show me how or
point me to some documentation, I can do it.
-- Jeanfrancois
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-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] Commons dependencies
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>- modeler: Basis for Tomcat 5 JMX features, with a lot of new
>>impressively efficient functionality since release 1.0; again, a
>>critical component [Costin (do you have enough time to continue being
>>the RM of that component ?)]
>
>
> I have very little free time - if anyone could do the release it would be
> great. There are no changes from M1 - I'll check bugzilla to see what
> remains to be done.
Ok, I undertsand; too bad :-(
Any volunteers ? (again, this is a critical item)
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] Commons dependencies
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> - modeler: Basis for Tomcat 5 JMX features, with a lot of new
> impressively efficient functionality since release 1.0; again, a
> critical component [Costin (do you have enough time to continue being
> the RM of that component ?)]
I have very little free time - if anyone could do the release it would be
great. There are no changes from M1 - I'll check bugzilla to see what
remains to be done.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org