You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Pier P. Fumagalli" <pi...@betaversion.org> on 2001/08/08 22:10:26 UTC
[PROPOSAL] Deprecation of committers...
I recently checked the list of committers for Tomcat 4.0 and MANY of them
are inactive... Our PMC charter mentions:
At times, Committers may go inactive for a variety of reasons. A Committer
that has been inactive for 6 months or more may lose their status as a
Committer. Getting access back is as simple as re-requesting it on the
projects developer mailing list.
Can we start the process for "deprecating" them?
Pier
RE: [PROPOSAL] Deprecation of committers...
Posted by Paulo Gaspar <pa...@krankikom.de>.
LOL
Finally someone with a decent sense of humor on this list!
(And I don't mind even when I am the target.)
Have fun,
Paulo
> -----Original Message-----
> From: Christopher Cain [mailto:ccain@mhsoftware.com]
> Sent: Thursday, August 09, 2001 7:37 AM
>
> Kanan:
>
> You'll have to forgive Pier, he's a little grumpy this week (not
> that we don't
> love him anyway) =)
>
> What is being discussed is whether or not to remove inactive
> developers from
> the server where the source code resides. It doesn't affect the
> mailing lists
> in any way; they just need to remove some old logins from the
> internal servers
> where the developers store the project code.
>
> We would never dream of depriving anyone of the circus that is
> the dev mailing
> list. ;-)
>
> - Christopher
>
> Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
>
> > Kanan Khokhani at kanankhokhani@yahoo.com wrote:
> >
> > > Hi,
> > >
> > > I am a meber of the list but not a commiter.
> > > I have never posted any messages so far, but i
> > > regularly(almost everyday)check messages from this
> > > list. Do you plan to deprecate members like me too??
> >
> > Go and read this one <http://jakarta.apache.org/site/roles.html> it
> > explains
> > how things are working...
> >
> > Pier
>
Re: [PROPOSAL] Deprecation of committers...
Posted by Christopher Cain <cc...@mhsoftware.com>.
Kanan:
You'll have to forgive Pier, he's a little grumpy this week (not that we don't
love him anyway) =)
What is being discussed is whether or not to remove inactive developers from
the server where the source code resides. It doesn't affect the mailing lists
in any way; they just need to remove some old logins from the internal servers
where the developers store the project code.
We would never dream of depriving anyone of the circus that is the dev mailing
list. ;-)
- Christopher
Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
> Kanan Khokhani at kanankhokhani@yahoo.com wrote:
>
> > Hi,
> >
> > I am a meber of the list but not a commiter.
> > I have never posted any messages so far, but i
> > regularly(almost everyday)check messages from this
> > list. Do you plan to deprecate members like me too??
>
> Go and read this one <http://jakarta.apache.org/site/roles.html> it
> explains
> how things are working...
>
> Pier
Re: [PROPOSAL] Deprecation of committers...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Kanan Khokhani at kanankhokhani@yahoo.com wrote:
> Hi,
>
> I am a meber of the list but not a commiter.
> I have never posted any messages so far, but i
> regularly(almost everyday)check messages from this
> list. Do you plan to deprecate members like me too??
Go and read this one <http://jakarta.apache.org/site/roles.html> it explains
how things are working...
Pier
Re: [PROPOSAL] Deprecation of committers...
Posted by Kanan Khokhani <ka...@yahoo.com>.
Hi,
I am a meber of the list but not a commiter.
I have never posted any messages so far, but i
regularly(almost everyday)check messages from this
list. Do you plan to deprecate members like me too??
:(
kanan
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: [PROPOSAL] Deprecation of committers...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Kief Morris at kief@bitbull.com wrote:
> Pier P. Fumagalli typed the following on 10:59 PM 8/8/2001 +0100
>> There are others that, from time to time, pop around on this mailing list,
>> but I never saw one commit coming from them (although I have only a 6-months
>> old archive, I would repropose this further on in the future, when some of
>> them will definitely over the 6 months limit).
>
> I guess I fall into this category. Unfortunately I haven't had the time to
> spend much time on the distributed sessions stuff. At some point I would
> like to dig into it again, but it sounds like even if I am deprecated it won't
> be hard to get commit privs back. Since I'm not using my access at the
> moment it wouldn't both me if I'm deprecated out.
You're not in the list I submitted... You posted quite a lot to this mailing
list lately, and, although I didn't check the commit logs, you seem to be
pretty active still :) I basically checked my 6-months archive for emails
coming from the different people involved with the projects. I didn't check
the CVS... :) :) :)
Pier
Re: [PROPOSAL] Deprecation of committers...
Posted by Kief Morris <ki...@bitbull.com>.
Pier P. Fumagalli typed the following on 10:59 PM 8/8/2001 +0100
>There are others that, from time to time, pop around on this mailing list,
>but I never saw one commit coming from them (although I have only a 6-months
>old archive, I would repropose this further on in the future, when some of
>them will definitely over the 6 months limit).
I guess I fall into this category. Unfortunately I haven't had the time to
spend much time on the distributed sessions stuff. At some point I would
like to dig into it again, but it sounds like even if I am deprecated it won't
be hard to get commit privs back. Since I'm not using my access at the
moment it wouldn't both me if I'm deprecated out.
Kief
RE: how to reload a getResourceAsStream() object
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting Thom Park <tp...@borland.com>:
> Hmm...
>
> so what about this line of code in StandardClassLoader:
>
> public InputStream getResourceAsStream(String name) {
>
> if (debug >= 2)
> log("getResourceAsStream(" + name + ")");
> InputStream stream = null;
>
> // (0) Check for a cached copy of this resource
> stream = findLoadedResource(name);
> if (stream != null) {
> if (debug >= 2)
> log(" --> Returning stream from cache");
> return (stream);
> }...
That code won't be used if you do ServletContext.getResourceAsStream.
Also, the code in StandardClassLoader.findLoadedResource actually is :
protected InputStream findLoadedResource(String name) {
return (null); // FIXME - findLoadedResource()
}
In the new WebappClassLoader, it actually does some caching :
protected InputStream findLoadedResource(String name) {
ResourceEntry entry = (ResourceEntry) resourceEntries.get(name);
if (entry != null) {
if (entry.binaryContent != null)
return new ByteArrayInputStream(entry.binaryContent);
}
return (null);
}
but it does create a stream each time.
For the ServletContext, the thing creating the stream is the directory context
(FileDirContext), and it also does create a new stream each time.
Remy
RE: how to reload a getResourceAsStream() object
Posted by Thom Park <tp...@borland.com>.
Hmm...
so what about this line of code in StandardClassLoader:
public InputStream getResourceAsStream(String name) {
if (debug >= 2)
log("getResourceAsStream(" + name + ")");
InputStream stream = null;
// (0) Check for a cached copy of this resource
stream = findLoadedResource(name);
if (stream != null) {
if (debug >= 2)
log(" --> Returning stream from cache");
return (stream);
}...
Looks to me that if the resource has been loaded, then it stays loaded,
even if it's been closed, at least for the StandardClassLoader...
I've got a scenario where the Context.getResourceAsStream returns me a
duff stream following a close on the stream.
I accept that your testcase proves that there must be something else hosing
me
here but it's a wee bit frustrating.
I guess I need to find out what the heck is going on with this stream
nonsense.
-Thom
-----Original Message-----
From: Remy Maucherat [mailto:remy@betaversion.org]
Sent: Wednesday, August 08, 2001 3:49 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: how to reload a getResourceAsStream() object
Quoting Thom Park <tp...@borland.com>:
> hello,
>
> I have a requirement where i need to make multiple passes over a
> resource
> stream
> obtained via ServletContext.getResourceAsStream().
>
> My problem is that as follows:
>
> InputStream is = sc.getResourceAsStream("/my_resource_name");
>
> .... do 1st processing pass
>
> is.close();
>
> is = sc.getResourceAsStream("/my_resource_name");
>
> ... do second processing pass...
>
> The problem is that, as far as the StandardClassLoader is concerned,
> the
> cached copy of the input stream is still good (and it isn't I just
> closed
> it)
> and I get the original (now bad) input stream returned.
>
>
> Is there anyway to force tomcat to reload the resource object (without
> unloading the context).
> as, right now I'm reading the whole resource into a byte array and
> using
> [my] cached copy
> for processing.
Ok, but :
- SevletContext.getResourceAsStream != ClassLoader.getResourceAsStream. If
you
use the servlet context, it has nothing to do at all with any class loader.
- I modified the HelloWorldServlet from the examples webapp just to be sure,
and inserted :
byte[] b = new byte[4096];
InputStream is = getServletContext().getResourceAsStream
("/servlets/index.html");
while (true) {
int n = is.read(b);
if (n == -1)
break;
System.out.println("Read1: " + n);
}
is.close();
is =
getServletContext().getResourceAsStream("/servlets/index.html");
while (true) {
int n = is.read(b);
if (n == -1)
break;
System.out.println("Read2: " + n);
}
is.close();
The display on the standard out is :
Read1: 4096
Read1: 892
Read2: 4096
Read2: 892
So it's working fine for me.
Using getResourceAsStream on the classloader should work the same (it will
end
up using URL.openStream which will in turn call Resource.streamContent, just
like ServletContext.getResourceAsStream).
Remy
Re: how to reload a getResourceAsStream() object
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting Thom Park <tp...@borland.com>:
> hello,
>
> I have a requirement where i need to make multiple passes over a
> resource
> stream
> obtained via ServletContext.getResourceAsStream().
>
> My problem is that as follows:
>
> InputStream is = sc.getResourceAsStream("/my_resource_name");
>
> .... do 1st processing pass
>
> is.close();
>
> is = sc.getResourceAsStream("/my_resource_name");
>
> ... do second processing pass...
>
> The problem is that, as far as the StandardClassLoader is concerned,
> the
> cached copy of the input stream is still good (and it isn't I just
> closed
> it)
> and I get the original (now bad) input stream returned.
>
>
> Is there anyway to force tomcat to reload the resource object (without
> unloading the context).
> as, right now I'm reading the whole resource into a byte array and
> using
> [my] cached copy
> for processing.
Ok, but :
- SevletContext.getResourceAsStream != ClassLoader.getResourceAsStream. If you
use the servlet context, it has nothing to do at all with any class loader.
- I modified the HelloWorldServlet from the examples webapp just to be sure,
and inserted :
byte[] b = new byte[4096];
InputStream is = getServletContext().getResourceAsStream
("/servlets/index.html");
while (true) {
int n = is.read(b);
if (n == -1)
break;
System.out.println("Read1: " + n);
}
is.close();
is = getServletContext().getResourceAsStream("/servlets/index.html");
while (true) {
int n = is.read(b);
if (n == -1)
break;
System.out.println("Read2: " + n);
}
is.close();
The display on the standard out is :
Read1: 4096
Read1: 892
Read2: 4096
Read2: 892
So it's working fine for me.
Using getResourceAsStream on the classloader should work the same (it will end
up using URL.openStream which will in turn call Resource.streamContent, just
like ServletContext.getResourceAsStream).
Remy
Re: how to reload a getResourceAsStream() object
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Thom Park at tpark@borland.com wrote:
> hello,
>
> I have a requirement where i need to make multiple passes over a resource
> stream
> obtained via ServletContext.getResourceAsStream().
>
> My problem is that as follows:
>
> InputStream is = sc.getResourceAsStream("/my_resource_name");
>
> .... do 1st processing pass
>
> is.close();
>
> is = sc.getResourceAsStream("/my_resource_name");
>
> ... do second processing pass...
>
> The problem is that, as far as the StandardClassLoader is concerned, the
> cached copy of the input stream is still good (and it isn't I just closed
> it)
> and I get the original (now bad) input stream returned.
>
>
> Is there anyway to force tomcat to reload the resource object (without
> unloading the context).
> as, right now I'm reading the whole resource into a byte array and using
> [my] cached copy
> for processing.
Seems to be a bug in the classloader implementation. When the resource
inputstream is closed, and you get another one, you should get a fresh new
working stream...
Pier
how to reload a getResourceAsStream() object
Posted by Thom Park <tp...@borland.com>.
hello,
I have a requirement where i need to make multiple passes over a resource
stream
obtained via ServletContext.getResourceAsStream().
My problem is that as follows:
InputStream is = sc.getResourceAsStream("/my_resource_name");
.... do 1st processing pass
is.close();
is = sc.getResourceAsStream("/my_resource_name");
... do second processing pass...
The problem is that, as far as the StandardClassLoader is concerned, the
cached copy of the input stream is still good (and it isn't I just closed
it)
and I get the original (now bad) input stream returned.
Is there anyway to force tomcat to reload the resource object (without
unloading the context).
as, right now I'm reading the whole resource into a byte array and using
[my] cached copy
for processing.
-Thom
-----Original Message-----
From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
Sent: Wednesday, August 08, 2001 2:13 PM
To: tomcat dev jakarta.apache.org
Cc: pmc@jakarta.apache.org
Subject: Re: [PROPOSAL] Deprecation of committers...
Can you send a list with the commiters that will become deprecated ?
Does this include 3.x commiters as well ? ( from the proposal it seems you
are talking about 4.0 commiters ).
Costin
On Wed, 8 Aug 2001, Pier P. Fumagalli wrote:
> I recently checked the list of committers for Tomcat 4.0 and MANY of them
> are inactive... Our PMC charter mentions:
>
> At times, Committers may go inactive for a variety of reasons. A
Committer
> that has been inactive for 6 months or more may lose their status as a
> Committer. Getting access back is as simple as re-requesting it on the
> projects developer mailing list.
>
> Can we start the process for "deprecating" them?
>
> Pier
>
Re: [PROPOSAL] Deprecation of committers...
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
cmanolache@yahoo.com at cmanolache@yahoo.com wrote:
>
> Can you send a list with the commiters that will become deprecated ?
>
> Does this include 3.x commiters as well ? ( from the proposal it seems you
> are talking about 4.0 commiters ).
I'm talking about ANY committer who hasn't been active for the past 6
months. Those are 17 out of the 45 we have but I would like to propose to
the PMC to review the list of committers every 6 months and mail EVERY
committer (even the active ones) about their committer status... If they are
unreachable, untraceable, or don't reply with a "YES" (in a reasonable
amount of time, to avoid vacations, absences, and so on). They can be
"deprecated"... This is mainly for security reasons... More users with
logins, more problems more attacks possible... Icarus is pretty secure, but
can we guarantee the same level of security of all machines where private
keys of individuals are stored and so on? Blabalbalbal.
People I know and can contact easily:
- stefano (stefano@betaversion.org) Stefano Mazzocchi
- mode (rajiv.mordani@sun.com) Rajiv Mordani
- akv (anil.vijendran@sun.com) Anil Vijendran
- ed (ed@collab.net) Ed Korthof
People I know, but I'm not in contact with:
- shemnon (???) Danno Ferrin
- gonzo (???) James Todd
- jluc (???) Jean-Luc Rochat
People I don't know and haven't seen around:
- preston (???) Preston Bannister
- shachor (???) Gal Shachor
- harishp (harishp@onebox.com) Harish Prabandham
- arun (???) Arun Jamwal
- ariedel (???) Andy Riedel
- gaburici (gaburici@cs.umd.edu) Vasile Gaburici
- shai (???) Shai Fultheim
There are others that, from time to time, pop around on this mailing list,
but I never saw one commit coming from them (although I have only a 6-months
old archive, I would repropose this further on in the future, when some of
them will definitely over the 6 months limit).
Pier
Re: [PROPOSAL] Deprecation of committers...
Posted by cm...@yahoo.com.
Can you send a list with the commiters that will become deprecated ?
Does this include 3.x commiters as well ? ( from the proposal it seems you
are talking about 4.0 commiters ).
Costin
On Wed, 8 Aug 2001, Pier P. Fumagalli wrote:
> I recently checked the list of committers for Tomcat 4.0 and MANY of them
> are inactive... Our PMC charter mentions:
>
> At times, Committers may go inactive for a variety of reasons. A Committer
> that has been inactive for 6 months or more may lose their status as a
> Committer. Getting access back is as simple as re-requesting it on the
> projects developer mailing list.
>
> Can we start the process for "deprecating" them?
>
> Pier
>