RE: Why do I receive CVS-commit stuff?

2002-01-03 Thread Morrison, John

If you are subscribed to a -dev list it is expected that you are a developer
and are therefore interested in changes to the code.  It cannot be turned
off.  If you don't want to recieve them, subscribe to -user instead :)

J

> -Original Message-
> From: Roland [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 03 January 2002 1:55 pm
> To: Tomcat Developers List
> Subject: Why do I receive CVS-commit stuff?
> 
> 
> Hello, I'm subscribed to the tomcat-dev mailing list but keep 
> receiving 
> cvs-commit emails. Why is that? Here are some of the headers 
> of the emails 
> I receive:
> 
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: cvs commit: 
> jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session 
> StandardManager.java
> 
> Can someone turn this off please?
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

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




RE: CVS question: Almost off topic

2001-09-25 Thread Morrison, John

The cvs list is moderated.  It takes a little time the first time ;)  Don't
worry, it'll get there.

> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 25 September 2001 10:33 am
> To: Tomcat Dev List
> Subject: CVS question: Almost off topic
> 
> 
> I've committed a patch to the repository today, expecting an automatic
> e-mail to the tomcat-dev list when the commit happens. But it 
> never did,
> although the commit went through OK.
> 
> After searching the CVS manual for clues, I bumped into -i option for
> modules, but that seems like an admin/setup kind of thing.
> 
> I must be doing something funny...
> 
> Bojan
> 
> PS. The commit was done with a simple:
> 
> cvs -d [EMAIL PROTECTED]:/home/cvs commit -m Message File
> 


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



RE: cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt

2001-09-13 Thread Morrison, John

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> 
> On Wed, 12 Sep 2001, jean-frederic clere wrote:
> >
> > Hi,
> >
> > How was the issue with sun.tools.javac.Main solved?
> >
> 
> It is going to be deferred to a future release.  Here's the reasoning:
> 
> * The Merlin (i.e. JDK 1.4) folks originally planned to simply
>   remove the old compiler entry point.  But they have changed
>   plans, and now it is merely deprecated.  The old compiler *will*
>   work in the 1.4 final release, so the time pressure is off.
> 
> * The new entry point can indeed be programmed to (like Ant does,
>   for example), but it has a crippling disadvantage for a servlet
>   container - it only writes error messages to System.out, so you
>   have to synchronize and do at most one compile at a time.  This
>   is not a good thing, and I'd rather see us take some time to
>   look at alternative approaches.

Nice of them - esp considering that they added a log capability into the
base distribution...

> > Cheers
> >
> > Jean-frederic
> >
> 
> Craig

J.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



RE: [anoncvs@jakarta.apache.org-error]Connection refused

2001-07-16 Thread Morrison, John



Try
 
cvs -d 
:pserver:[EMAIL PROTECTED]:/home/cvspublic 
login
 
J.

  -Original Message-From: Dongsheng, Song 
  [mailto:[EMAIL PROTECTED]]Sent: Monday, 16 July 2001 12:44 
  pmTo: [EMAIL PROTECTED]Cc: 
  [EMAIL PROTECTED]Subject: 
  [[EMAIL PROTECTED]]Connection refused
  Hi,
   
  When I execute:
   
  cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic 
  login
   
  with password "anoncvs", the error occured:
   
  cvs [login aborted]: connect to jakarta.apache.org:2401 
  failed: Connection refused
   
  Has anyone encountered this problem, and/or is 
  there a solution?
  Dongsheng Song

===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



RE: Tomcat Admin Web Interface

2001-06-15 Thread Morrison, John

Would/could this be implemented as a web context with (possibly) some
'administration' flag set in it's context that way, if you didn't want to
have a GUI (security?) you could just remove the context?

Just my 2p worth ;)

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 14 June 2001 23:13
To: '[EMAIL PROTECTED]'
Subject: RE: Tomcat Admin Web Interface



It would be very good at this stage to go back 1 1/2 years in tomcat
archives and re-read the "admin" thread. It was a huge discussion, with
many ideas - but nothing happened. 

As usual, my opinion is that you should start with a prototype and/or
existing code - and figure out what is the best way to do it by trying
different aproaches. 

Costin




On Thu, 14 Jun 2001, Eric Anderson wrote:

> Count me in on working on an admin interface for Tomcat.  This along with
a
> better install/connector config program would go a long way to improve the
> overall usability of Tomcat for me.
> 
> Having had experience working on server product GUIs, the plan to decide
> what goes into the GUI before starting the project is definitely the best
> way to go.  Even though there is a considerable amount of planning and
> discussion that goes into the GUI requirements sheet, in the end it is
> easier to deny unreasonable requests like, "we have this new functionality
> two weeks before the release can you incorporate it into the admin
> interface?", or "I'd like the GUI to wash and wax my car."  A hard and
fast
> list of GUI features for each release is essential to keeping the GUI
> project manageable
> 
> My 2 cents.
> 
> Eric
> 
> 
> On Thu, 14 Jun 2001, M B wrote:
> 
> > Hello All,
> > 
> > In response to the recent postings regarding Tomcat
> > documentation and administration (Re: ~rant~ Docs,
> > user list, etc.), I am willing to contribute much
> > effort in this area.  In addition to documentation, I
> > am particularly interested in helping to build an
> > administrative web interface for Tomcat 4.0, something
> > similar to JRun Management Console, for example.
> > 
> 
> That would be awesome!
> 
> > Naturally, I want to coordinate my efforts with the
> > Tomcat community.  Can anyone please point out where I
> > should begin, or who I should contact?  Is there a
> > project for this?  The Catalina TODO identifies John
> > Shin as volunteer for producing an admin interface,
> > but I thought I should email this list before
> > contacting him directly.  
> > 
> 
> He volunteered long, long, ago but I haven't heard anything from him
> lately.
> 
> As it happens, I've been accumulating a list of functional requirements
> for admin capabilities that I'd like to post for discussion.  I'll be
> finished with what I'm thinking in the next couple of days.
> 
> What I'd like to see us do on issues like this is to discuss and agree on
> a functional specs document that is checked in to the CVS repository, and
> then start working together on the pieces.  It's a little more formal than
> the usual :-) open source approach, but I think it will help in the long
> run.  Does that sound like a useful plan?
> 
> > Thanks,
> > Matt
> > 
> 
> Craig
> 


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



TC4.0 Debug

2001-05-31 Thread Morrison, John

I was wondering whether anybody who's got tomcat to start up on a debug JVM
would be kind enough to add another option to catalina.[bat|sh] and possibly
a debugstartup.[bat|sh]?

Failing that, if somebody would tell me how, I'd be willing to do so.


Thanks,
John.

PS, I'm looking to use Netbeans as the debugger if specifics are required...


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



RE: [PROPOSAL] Revised Tomcat 4.0-beta-2 Release Plan

2001-01-23 Thread Morrison, John

Rather than removing the TC4.1 cvs would it not be better to alias it back
to the TC4.0 repository and not broadcast that it exists?  This will keep
those who checked out the source from having to move back to 4.0.

Excellent project...

J.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]




RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building i s hard)

2000-12-15 Thread Morrison, John

Yeh, I see your point.  But CVS ignores any files it doesn't know about and
it _is_ a common idiom amongst open source projects...

If you don't like cluttering the CVS co (and you're using Linux), create a
linked dir to build into.

> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> Sent: 15 December 2000 11:59 am
> To: [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] building is easy (was: Re: 
> [tomcat-4.0] building
> i s hard)
> 
> 
> John Morrison wrote:
> >
> > While jakarta-servletapi-4.0 and TC4.0 builds are being
> > re-developed, could we please *stop* them creating
> > directories higher in the hierarchy thantheir own root?
> > ie
> >
> > /jakarta-tomcat/ shouldn't then create ../build/ - it's
> > not nice!
> 
> An alternate perspective - I like the fact that building a 
> cvs checkout
> does not modify the checkout itself.
> 
> - Sam Ruby
> 


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



RE: [PROPOSAL] building is easy (was: Re: [tomcat-4.0] building is hard)

2000-12-15 Thread Morrison, John

While jakarta-servletapi-4.0 and TC4.0 builds are being re-developed, could
we please *stop* them creating directories higher in the hierarchy than
their own root?  ie

/jakarta-tomcat/ shouldn't then create ../build/ - it's not nice!

Just my 2p worth ;-)

> -Original Message-
> From: Jon S. Stevens [mailto:[EMAIL PROTECTED]]
> Sent: 14 December 2000 9:13 pm
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] building is easy (was: Re: 
> [tomcat-4.0] building
> is hard)
> 
> 
> > 
> > Jon Stevens wrote:
> > >
> > > If the above files do not exist, then attempt to look
> > > for relative paths (ie: ../../jakarta-servletapi) to
> > > the .jar files here:
> > >
> > > /jakarta-servletapi
> > > /jsse*
> > > /jmx*
> > 
> > It is not clear to me why property files with reasonable 
> defaults are
> > "easy" whereas environment variables with the same defaults 
> are "hard".  It
> > seems to me that the key discussion is what are reasonable defaults.
> > Whatever.
> 
> Try fitting the current model of building Tomcat into 
> relative paths and
> you will see. It wasn't clear to me until I started hacking at it.
> 
> > More substantially, I'm troubled by thoses asterisks, and I 
> have a similar
> > problem with jakarta-servletapi.  I routinely have multiple 
> copies of
> > various products on my system.  One case in point is 
> jakarta-servletapi as
> > I routinely build both tomcat3 and tomcat4.  To enable 
> this, I have two
> > copies of servletapi, one named jakarta-servletapi-4.0.  
> Clearly this can
> > be addressed via a properties file, I just want to be sure 
> that the build
> > system doesn't do me a "favor" by tossing in additional, 
> randomly selected
> > things into my path without warning.
> 
> Knowing where the problem is is key. In this case, I would 
> propose that
> the build for jakarta-servletapi is badly broken in that you can't
> currently (by default) have multiple versions of it in your /build and
> /dist directory at the same time.
> 
> I would say that the servlet api build process should be "fixed" to
> build/install into directories with the version number attached.
> 
> /build/jakarta-tomcat-4.0
> /build/jakarta-tomcat-3.2
> /build/jakarta-ant-1.2
> /build/jakarta-ant-1.3
> /build/servletapi-2.2
> /build/servletapi-2.3
> /dist/servletapi-2.2
> /dist/servletapi-2.3
> /jakarta-tomcat-4.0
> /jakarta-tomcat-3.2
> /jakarta-ant-1.2
> /jsse-1.0.1
> 
> This builds in the promise that things won't get confused.
> 
> Clarity: The first / is relative to whatever directory things are put
> into, not your / on your disk.
> 
> -jon
> 
> -- 
> Scarab -
>   Java Servlet Based - Open Source 
>  Bug/Issue Tracking System
> 
> 


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF



[Tomcat 4] working directory

2000-11-23 Thread Morrison, John

Hi all,

Is there somewhere in the configurations where I can set where I want the
work directory?  If there isn't if somebody would be kind enough to point me
into the sources I'd be glad to add the functionality.

John Morrison.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF