DO NOT REPLY [Bug 4386] - webapp1.0 will not install on Redhat 7.1

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4386

webapp1.0 will not install on Redhat 7.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   Severity|Blocker |Normal
 OS/Version|Linux   |MacOS X
   Platform|Other   |Macintosh



--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 21:28 ---
After Erich's comments (thanks BTW) I revisited the problem and 
discovered something interesting.  On Mac OS X 10.1 Apache modules 
are installed in /usr/libexex/httpd/ not /usr/libexec/.  I had placed my 
mod_webapp.so file in the /usr/libexec/httpd/ directory and specified the 
same directory in my httpd.conf, as you would expect.  Upon revisiting the 
situation I noticed an older version of the mod_webapp.so file had found 
its way into the /usr/libexec/ directory (I don't know how... there were a lot 
of iterations, so I'm not surprized that I may have left one there).  After 
discovering it there, I deleted it and now Apache starts up correctly.  
Anyway, at this point it all feels a little like chicken blood, but these are my 
observations, and I hope they help someone else.

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

Re: Off for quite a while...

[Tonia A. Flores]

Well, I hope enjoy the holidays and the travel.  :-)

That Mac price -I get the homer award for that one. I didn't realize 
that site holds the previous selection so that when I went back in I 
was setup to purchase 2-machines with extra stuff.  

Probably better to take an extended vaction -one just never knows when 
the next one will be available.

Take it easy . . .

~Tonia

- Original Message -
From: Pier Fumagalli <[EMAIL PROTECTED]>
Date: Thursday, November 15, 2001 7:34 pm
Subject: Off for quite a while...

> Folks, it's time for me to reorganize my life (I'm sure you 
> understand), so
> I'm going to take it slow and easy and be off for quite some time. I'm
> planning to do some traveling over the next month, with random 
> internetaccess (depends a lot on what I get when I'm there - 
> Fellow Titanium is
> coming with me anyway). The plans are (so far):
> 
> - Milan (Nov 18th to Nov 24th)
> - San Diego (Nov 25th to Dec 1st)
> - San Francisco (Dec 2nd to Dec 8th)
> - Dublin (Dec 9th to Dec 15th)
> - London (Dec 16th to Dec 22nd)
> - Milan (Dec 23rd to Dec 29th)
> 
> So that basically mean that unless you don't write to me 
> personally (or you
> know how to get a hold on me), I won't be around until January 
> (although I
> will see most of you during my wonderings).
> 
> Justyna (co-root on Nagoya) knows how to handle most of the stuff, 
> and knows
> how to get in touch with me at any time, so, bye for now, will see 
> ya next
> year... Have fun :)
> 
>Pier
> 
> 
> --
> To unsubscribe, e-mail:    [EMAIL PROTECTED]>For additional commands, e-mail: 
> 
> 
> 


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

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletResponseFacade.java

[billbarker]

billbarker01/11/15 20:10:35

  Modified:src/facade22/org/apache/tomcat/facade
HttpServletResponseFacade.java
  Log:
  Fix URL rewriting when the url has an anchor.
  
  In order to be functional, the "jsessionid=" must be part of the "file" component of 
the URL.  This just makes certain that it is not part of the anchor.
  
  Revision  ChangesPath
  1.23  +11 -3 
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java
  
  Index: HttpServletResponseFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- HttpServletResponseFacade.java2001/11/14 02:57:08 1.22
  +++ HttpServletResponseFacade.java2001/11/16 04:10:35 1.23
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
 1.22 2001/11/14 02:57:08 larryi Exp $
  - * $Revision: 1.22 $
  - * $Date: 2001/11/14 02:57:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletResponseFacade.java,v
 1.23 2001/11/16 04:10:35 billbarker Exp $
  + * $Revision: 1.23 $
  + * $Date: 2001/11/16 04:10:35 $
*
* 
*
  @@ -440,9 +440,17 @@
path = url.substring(0, question);
query = url.substring(question);
}
  + String anchor = null;
  + int hashP = path.indexOf("#");
  + if(hashP >= 0) {
  + anchor = path.substring(hashP);
  + path = path.substring(0,hashP);
  + }
StringBuffer sb = new StringBuffer(path);
sb.append(";jsessionid=");
sb.append(sessionId);
  + if(anchor != null) 
  + sb.append(anchor);
if (query != null)
sb.append(query);
return (sb.toString());
  
  
  

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

Off for quite a while...

[Pier Fumagalli]

Folks, it's time for me to reorganize my life (I'm sure you understand), so
I'm going to take it slow and easy and be off for quite some time. I'm
planning to do some traveling over the next month, with random internet
access (depends a lot on what I get when I'm there - Fellow Titanium is
coming with me anyway). The plans are (so far):

 - Milan (Nov 18th to Nov 24th)
 - San Diego (Nov 25th to Dec 1st)
 - San Francisco (Dec 2nd to Dec 8th)
 - Dublin (Dec 9th to Dec 15th)
 - London (Dec 16th to Dec 22nd)
 - Milan (Dec 23rd to Dec 29th)

So that basically mean that unless you don't write to me personally (or you
know how to get a hold on me), I won't be around until January (although I
will see most of you during my wonderings).

Justyna (co-root on Nagoya) knows how to handle most of the stuff, and knows
how to get in touch with me at any time, so, bye for now, will see ya next
year... Have fun :)

Pier


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

Re: Tomcat: Distributed Session Management revisited

[Tom Drake]

Understood.

I'm looking at a locking mechanism (with a configurable timeout). I'll be
sending some diagrams and interface specs out in the next day or two.

Tom

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
<[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 11:41 AM
Subject: Re: Tomcat: Distributed Session Management revisited


|
|
| On Tue, 13 Nov 2001, Tom Drake wrote:
|
| > I want a distributed session store, where all sessions are known (or
| > are knowable) by all members of the cluster, with a built-in
| > fail-over mechanism?
|
| As you guys discuss this, don't forget a very important requirement in the
| servlet specification with regards to distributable applications:
|
| [Servlet Spec 2.3, Section 7.7.2]  "Within an application
| marked as distributable, all requests that are part of a
| session must be handled by one virtual machine at a time."
|
| In effect, this means that a session can be migrated to a different server
| only "between" requests.  On a failure of the server currently handling
| the session, you could migrate it to a different server, but this
| operation must be atomic.
|
| Craig
|
|
|
| --
| To unsubscribe, e-mail:

| For additional commands, e-mail:

|
|
|


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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardClassLoader.java

[remm]

remm01/11/15 17:21:51

  Modified:catalina/src/share/org/apache/catalina/loader Tag:
tomcat_40_branch StandardClassLoader.java
  Log:
  - Port fix for a race condition in the SCL, where defineClass could be called
multiple times on the same class.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.24.2.1  +7 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
  
  Index: StandardClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
  retrieving revision 1.24
  retrieving revision 1.24.2.1
  diff -u -r1.24 -r1.24.2.1
  --- StandardClassLoader.java  2001/09/10 17:42:50 1.24
  +++ StandardClassLoader.java  2001/11/16 01:21:51 1.24.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.24 2001/09/10 17:42:50 remm Exp $
  - * $Revision: 1.24 $
  - * $Date: 2001/09/10 17:42:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.24.2.1 2001/11/16 01:21:51 remm Exp $
  + * $Revision: 1.24.2.1 $
  + * $Date: 2001/11/16 01:21:51 $
*
* 
*
  @@ -112,7 +112,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.24 $ $Date: 2001/09/10 17:42:50 $
  + * @version $Revision: 1.24.2.1 $ $Date: 2001/11/16 01:21:51 $
*/
   
   public class StandardClassLoader
  @@ -668,6 +668,9 @@
   log("  super.findClass(" + name + ")");
   try {
   synchronized (this) {
  +clazz = findLoadedClass(name);
  +if (clazz != null)
  +return clazz;
   clazz = super.findClass(name);
   }
   } catch(AccessControlException ace) {
  
  
  

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

Re: Ajp14 and Ajp13

[costinm]

On Thu, 15 Nov 2001, Bill Barker wrote:

> I'm in favor of this, since the protocol is only being extended, not really
> changed.
>
> However, I think that one of the extensions that should be implemented early
> on is a version negotiation so that the newer side can gracefully degrade in
> the future without having to rely on the user changing configuration
> settings.

Yes, Henri already implemented this in the login phase - however Ajp13
doesn't support this.

The distinction between post Ajp14 will be the number of callbacks
supported - and login/negotiation is the essential one to diferentiate
between Ajp13 and Ajp14+.

If the user doesn't set the login callback - we will use 'plain' ajp13.

If the user does have a login - it's clear he wants ajp14 ( or later ) and
we can detect the number of callbacks supported.

The distinction between ajp13, 14, ... will be in the number of callbacks
- each version will have a set of callbacks ( sort of API version
instead of protocol version ).

Regardless of the Ajp version, we should support all previous ones up to
13. This will also minimize the amount of pain for 3.2.x users, who are
unlikely to get Ajp14 ported, and also for users of 4.0 - again, support
for ajp14 is likely to be available in 4.0.2 or later. They'll still be
able to get most fixes, and we'll have less code to maintain.


Costin



> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, November 15, 2001 3:19 PM
> Subject: Ajp14 and Ajp13
>
>
> > Hi,
> >
> > Right now we treat Ajp13 and 14 as 2 separate workers ( even if most of
> > the code is shared). The problem is that this adds complexity that we
> > could avoid.
> >
> > Given that Ajp14 is not 'official' yet, I would propose to change it to
> > "Ajp14 == Ajp13 + extra functions".
> >
> > We should use exactly the same header and encapsulation as in Ajp13 -
> > since this is very well tested. The main difference is in the startup
> > phase, where Ajp14 will login and auto-configure.
> >
> > That can be easily configured and we can have the new Ajp14 clients
> > talking with older Ajp13 servers ( so most fixes will go in the same
> > codebase, without needing to fix both the new 1.4 worker and the old one).
> >
> > If the ajp14 worker will be configured with a login password - then it'll
> > do the extra login and configuration steps. If not - it'll be just our old
> > ajp13 client, capable to speak with tomcat3.2 ... tomcat4.0.
> >
> > On tomcat side, if the connector will be configured to require a login
> > it'll behave as a ajp14 server, and do the autoconfiguration ( and refuse
> > connections from unauthenticated ajp13 clients ).
> >
> > This can be extended in future as more callbacks are added. Instead of
> > having ajp15, 16... we'll keep Ajp13 as the base and configure the
> > calls and callbacks to use.
> >
> > The main reason for this is simplifying the code - which is very
> > important to do before any extension. This would also allow a smooth
> > transition - all new features will be included in mod_jk and the new java
> > connector, but the user will be able to use only what he needs and
> > support multiple server versions.
> >
> > What do you think ?
> >
> > Costin
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> >
>
>
> **
>
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
>
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>


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

Re: Ajp14 and Ajp13

[Bill Barker]

I'm in favor of this, since the protocol is only being extended, not really
changed.

However, I think that one of the extensions that should be implemented early
on is a version negotiation so that the newer side can gracefully degrade in
the future without having to rely on the user changing configuration
settings.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 3:19 PM
Subject: Ajp14 and Ajp13


> Hi,
>
> Right now we treat Ajp13 and 14 as 2 separate workers ( even if most of
> the code is shared). The problem is that this adds complexity that we
> could avoid.
>
> Given that Ajp14 is not 'official' yet, I would propose to change it to
> "Ajp14 == Ajp13 + extra functions".
>
> We should use exactly the same header and encapsulation as in Ajp13 -
> since this is very well tested. The main difference is in the startup
> phase, where Ajp14 will login and auto-configure.
>
> That can be easily configured and we can have the new Ajp14 clients
> talking with older Ajp13 servers ( so most fixes will go in the same
> codebase, without needing to fix both the new 1.4 worker and the old one).
>
> If the ajp14 worker will be configured with a login password - then it'll
> do the extra login and configuration steps. If not - it'll be just our old
> ajp13 client, capable to speak with tomcat3.2 ... tomcat4.0.
>
> On tomcat side, if the connector will be configured to require a login
> it'll behave as a ajp14 server, and do the autoconfiguration ( and refuse
> connections from unauthenticated ajp13 clients ).
>
> This can be extended in future as more callbacks are added. Instead of
> having ajp15, 16... we'll keep Ajp13 as the base and configure the
> calls and callbacks to use.
>
> The main reason for this is simplifying the code - which is very
> important to do before any extension. This would also allow a smooth
> transition - all new features will be included in mod_jk and the new java
> connector, but the user will be able to use only what he needs and
> support multiple server versions.
>
> What do you think ?
>
> Costin
>
>
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

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

Ajp14 and Ajp13

[cmanolache]

Hi,

Right now we treat Ajp13 and 14 as 2 separate workers ( even if most of
the code is shared). The problem is that this adds complexity that we
could avoid.

Given that Ajp14 is not 'official' yet, I would propose to change it to
"Ajp14 == Ajp13 + extra functions".

We should use exactly the same header and encapsulation as in Ajp13 -
since this is very well tested. The main difference is in the startup
phase, where Ajp14 will login and auto-configure.

That can be easily configured and we can have the new Ajp14 clients
talking with older Ajp13 servers ( so most fixes will go in the same
codebase, without needing to fix both the new 1.4 worker and the old one).

If the ajp14 worker will be configured with a login password - then it'll
do the extra login and configuration steps. If not - it'll be just our old
ajp13 client, capable to speak with tomcat3.2 ... tomcat4.0.

On tomcat side, if the connector will be configured to require a login
it'll behave as a ajp14 server, and do the autoconfiguration ( and refuse
connections from unauthenticated ajp13 clients ).

This can be extended in future as more callbacks are added. Instead of
having ajp15, 16... we'll keep Ajp13 as the base and configure the
calls and callbacks to use.

The main reason for this is simplifying the code - which is very
important to do before any extension. This would also allow a smooth
transition - all new features will be included in mod_jk and the new java
connector, but the user will be able to use only what he needs and
support multiple server versions.

What do you think ?

Costin









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

DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 14:14 ---
What I suggest doing works for me. That's how the examples webapp is declared 
(and it uses a lot of custom parameters).

The unpackWARs attribute is used only when auto-deploying webapps, not when 
explicitely declaring contexts.

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

DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 13:34 ---
We had already tried your proposal, but it does not work.

We have not changed the parameter unpackWARs (which -I think-
is responsible for the unpacking), but Tomcat does not unpack the
webapp:



Is there any other way to let Tomcat extract the WAR file?

We _must_ define a context for lexis, to do the folowing:
1) avoid the sessions to be persisted and reloaded (saveOnRestart="false") when 
Tomcat is shut down and restarted (Just because we do not only use struts: we 
also use log4j, which is not Serializable, and at higher levels the 
PersistentManager declarations seem not to work)
2) to log4j the lexis application to a specific file/directory
3) to use application parameters

((Without defining a context for the webapp lexis Tomcat
DOES extract the WAR file. Only when I __define__ a context
it DOES NOT!!))

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

RE: Tomcat: Distributed Session Management revisited

[GOMEZ Henri]

>> Costin,
>>
>> that point of view is really interesting. What about separating the
>> distribution part from the integration part of a integrated solution.
>> That would user's give the option to use the "transparent session
>> replication" or to use "explicit object replication services".
>> The former would ease their live with the drawback of 
>missing transaction
>> support, the latter would give the app-developer all control over it.
>
>More important is separating the implementation of the 'distribution'
>part as a stand-alone module.
>
>I'm absolutely -1 on putting this in the same space with the 
>main tomcat4
>- it's already a huge mess and adding this much complexity is 
>going to make
>things worse.

May be a good candidate for jakarta-commons, since it could be
used for example in Avalon. 

I'm not even sure that a Distributed Stuff Management is even
Servlet Engine Specific, it fit more on EJB repository land.




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

Re: Distributed Session Management

[Paul Speed]

"Craig R. McClanahan" wrote:
> 
> On Thu, 15 Nov 2001, Paul Speed wrote:
> 
> > Date: Thu, 15 Nov 2001 14:40:35 -0500
> > From: Paul Speed <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > To: Tomcat Developers List <[EMAIL PROTECTED]>
> > Subject: Re: Distributed Session Management
> >
> > The only problem with including the tests right in the same package
> > is that they can be hard to remove for a test-free distribution.  Also,
> > since they are in the same package, they have access to some non-public
> > methods and properties... this can make them a security risk in some
> > cases (especially since they can't be easily removed).
> >
> > When opting not to build a separate hierarchy for test classes, we
> > always created a "test" sub-package.
> >
> > I can present numerous reasons why it is better to use a separate
> > hierarchy, but I'm not sure I'd change anyone's mind. :)
> 
> There's actually a solution that works for both camps:  parallel source
> directory hierarchies.
> 
>   src/java/org/apache/foo   <-- Contains the implementation
>   src/test/org/apache/foo   <-- Contains the tests

Right, that's my preferred approach as well.  The other nice thing
about a separate source hierarchy is that if you decide to one day
change testing methodologies, your real source tree is still pure.
Just create a src/junit/org/apache/foo or src/supertest/org/apache/foo
as needed.

-Paul

> 
> Then, just set up your build scripts to only compile the tests if you need
> them -- a build to create a distribution will omit them.  Yet, the test
> classes will still be in the same Java package, so you can test package
> protected methods without having to modify the implementation classes.
> 
> The existing JUnit tests in jakarta-tomcat-4.0 (plus bunches of other
> Jakarta projects like those in Commons) follow this style.
> 
> > -Paul
> >
> 
> Craig
>

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

DO NOT REPLY [Bug 4891] - Tyrex's EnabledDataSource cannot find JDBC driver's class placed in $CATALINA_HOME/lib

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4891

Tyrex's EnabledDataSource cannot find JDBC driver's class placed in $CATALINA_HOME/lib





--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 12:01 ---
Well, that's normal if you look at the CL hierarchy. Most of the time,
dependencies must have to be in the same CL or one of its parent. Since the
shared CL is a child of the common CL, it won't work.

OTOH, there's no reason why Tyrex (along with JTA, JavaMail, JAF and the JDBC 2
SE) couldn't be moved to the shared CL.

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

Re: Distributed Session Management Unit tests

[Tom Drake]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 11:39 AM
Subject: Re: Distributed Session Management


|
|
| On Thu, 15 Nov 2001, Paul Speed wrote:
|
| > Date: Thu, 15 Nov 2001 14:40:35 -0500
| > From: Paul Speed <[EMAIL PROTECTED]>
| > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
| > To: Tomcat Developers List <[EMAIL PROTECTED]>
| > Subject: Re: Distributed Session Management
| >
| > The only problem with including the tests right in the same package
| > is that they can be hard to remove for a test-free distribution.  Also,
| > since they are in the same package, they have access to some non-public
| > methods and properties... this can make them a security risk in some
| > cases (especially since they can't be easily removed).
| >
| > When opting not to build a separate hierarchy for test classes, we
| > always created a "test" sub-package.
| >
| > I can present numerous reasons why it is better to use a separate
| > hierarchy, but I'm not sure I'd change anyone's mind. :)
|
|
| There's actually a solution that works for both camps:  parallel source
| directory hierarchies.
|
|   src/java/org/apache/foo   <-- Contains the implementation
|   src/test/org/apache/foo   <-- Contains the tests
|
| Then, just set up your build scripts to only compile the tests if you need
| them -- a build to create a distribution will omit them.  Yet, the test
| classes will still be in the same Java package, so you can test package
| protected methods without having to modify the implementation classes.
|
| The existing JUnit tests in jakarta-tomcat-4.0 (plus bunches of other
| Jakarta projects like those in Commons) follow this style.
|
| > -Paul
| >
|
| Craig
|

Thanks Craig. That's what I was looking for. I didn't
want to invent anything new in this regard.

Tom



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

Re: Distributed Session Management

[Craig R. McClanahan]

On Thu, 15 Nov 2001, Paul Speed wrote:

> Date: Thu, 15 Nov 2001 14:40:35 -0500
> From: Paul Speed <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Distributed Session Management
>
> The only problem with including the tests right in the same package
> is that they can be hard to remove for a test-free distribution.  Also,
> since they are in the same package, they have access to some non-public
> methods and properties... this can make them a security risk in some
> cases (especially since they can't be easily removed).
>
> When opting not to build a separate hierarchy for test classes, we
> always created a "test" sub-package.
>
> I can present numerous reasons why it is better to use a separate
> hierarchy, but I'm not sure I'd change anyone's mind. :)


There's actually a solution that works for both camps:  parallel source
directory hierarchies.

  src/java/org/apache/foo   <-- Contains the implementation
  src/test/org/apache/foo   <-- Contains the tests

Then, just set up your build scripts to only compile the tests if you need
them -- a build to create a distribution will omit them.  Yet, the test
classes will still be in the same Java package, so you can test package
protected methods without having to modify the implementation classes.

The existing JUnit tests in jakarta-tomcat-4.0 (plus bunches of other
Jakarta projects like those in Commons) follow this style.

> -Paul
>

Craig


> Tom Drake wrote:
> >
> > Mika:
> >
> > - Original Message -
> > From: "Mika Goeckel" <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
> > <[EMAIL PROTECTED]>
> > Sent: Thursday, November 15, 2001 3:31 AM
> > Subject: Re: Distributed Session Management
> >
> > | Tom,
> > |
> > | from my (personal?!) philosophy, tests should be with the tested targets.
> > My
> > | experience tells me that tests get out of focus if they are in a separate
> > | tree.
> >
> > I agree, I like to place them in the same package as the code being tested.
> > In other projects, I've used a naming convention to distiguish between
> > Test classes and other classes (e.g. test classes are named Test?.java)
> >
> > | Now when you are going to start hacking, is your approach creating use
> > | cases, sequence diagrams etc. before, or something like class
> > responsibility
> > | cards?
> >
> > Usually, I use a combination of things. In my mind the electronic equivalent
> > of class responsibility cards are java interface definitions or sparse
> > classes
> > with some javadoc. The initial message that I sent out that started this
> > thread
> > had a couple of java interfaces. I'll be sending some more around. I'll may
> > also
> > send some class diagrams, and sequence or collaboration diagrams.
> >
> > Tom
> >
> > P.S.
> >
> > |
> > | M.
> > |
> > | - Original Message -
> > | From: "Tom Drake" <[EMAIL PROTECTED]>
> > | To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> > | Sent: Wednesday, November 14, 2001 8:39 PM
> > | Subject: Distributed Session Management
> > |
> > |
> > | > Tomcat Developers:
> > | >
> > | > I'm going to try to synthesize the results of yesterdays
> > | > discussion on Distributed Session Management into some
> > | > working code. From what I can tell, there will be some
> > | > changes and new objects in the org.apache.session
> > | > package, and possibly some new objects in the
> > | > org.apache.cluster package.
> > | >
> > | > I should have something to share in the next couple of
> > | > days. I'll be creating JUnit tests as I write this code. Is there
> > | > a standard place to put JUnit tests, or can I simply place
> > | > them in the same package as the classes being tested?
> > | >
> > | > Regards,
> > | >
> > | > Tom Drake
> > | > Email: [EMAIL PROTECTED]
> > | >
> > | >
> > | > --
> > | > To unsubscribe, e-mail:
> > | 
> > | > For additional commands, e-mail:
> > | 
> > | >
> > |
> > |
> > | --
> > | To unsubscribe, e-mail:
> > 
> > | For additional commands, e-mail:
> > 
> > |
> > |
> > |
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

cvs commit: jakarta-tomcat-connectors/jk/native build.xml

[mmanders]

mmanders01/11/15 11:38:02

  Modified:jk/native build.xml
  Log:
  Added target for building netscape binaries.
  
  Revision  ChangesPath
  1.14  +134 -19   jakarta-tomcat-connectors/jk/native/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/build.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- build.xml 2001/11/12 23:36:13 1.13
  +++ build.xml 2001/11/15 19:38:02 1.14
  @@ -49,15 +49,51 @@



  +
 
 


  - 
  + 
  +
  +
  + 
  + 
  +
  +
  +
 
 

 
  +  
  +  
  +  
  +  
  +  
  +   
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
   
 
   
  @@ -103,7 +139,6 @@
 


  -
   
 
  @@ -112,12 +147,14 @@



  + 
   
   




  +


   
  @@ -172,23 +209,6 @@
   
 
   
  -  
  -
  -  
  - 
  - 
  - 
  - 
  - 
  - 
  - 
  - 
  - 
  - 
  -  
  -
  -  
  -
 
 
   

  +  
  +
  +  
  +
  +  
  +
  +  
  + 
  + 
  +
  +  
  +  
  + 
  + 
  + 
  + 
  +
  +
  + 
  + 
  +
  + 
  + 
  +
  +
  +  
  +  
  + 
  +  
  +
  +  
  +  
  +  
  +  
  +  
  +   
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +
  +  
  +
  +  
  +
  +  
  + 
  + 
  + 
  + 
  + 
  + 
  + 
  + 
  + 
  + 
  +  
  +
 
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native build.properties.sample

[mmanders]

mmanders01/11/15 11:37:42

  Modified:jk/native build.properties.sample
  Log:
  Added defaults for netscape and windows.
  
  Revision  ChangesPath
  1.3   +10 -0 jakarta-tomcat-connectors/jk/native/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/build.properties.sample,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- build.properties.sample   2001/11/07 15:26:52 1.2
  +++ build.properties.sample   2001/11/15 19:37:42 1.3
  @@ -6,6 +6,9 @@
   # Same for Apache1.3
   apache13.home=/usr
 
  +# Same for Netscape
  +netscape.home=d:/tools/sdk/netscape
  +  
   # Compile-time options
   so.debug=true
   so.optimize=false
  @@ -18,4 +21,11 @@
   # build.compiler.base=d:/tools/mw/6.0
   # build.compiler.cc=${build.compiler.base}/bin/mwccnlm
   # build.compiler.ld=${build.compiler.base}/bin/mwldnlm
  +
  +# Settings for building Windows binaries.  Uncomment these and modify for your
  +# environment to build Windows binaries.
  +#
  +# build.compiler.base=c:/Program Files/Microsoft Visual Studio/VC98
  +# build.compiler.cc=${build.compiler.base}/bin/cl
  +# build.compiler.ld=${build.compiler.base}/bin/link
   
  
  
  

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

Re: Distributed Session Management

[Paul Speed]

The only problem with including the tests right in the same package
is that they can be hard to remove for a test-free distribution.  Also,
since they are in the same package, they have access to some non-public
methods and properties... this can make them a security risk in some
cases (especially since they can't be easily removed).

When opting not to build a separate hierarchy for test classes, we
always created a "test" sub-package.

I can present numerous reasons why it is better to use a separate
hierarchy, but I'm not sure I'd change anyone's mind. :)
-Paul

Tom Drake wrote:
> 
> Mika:
> 
> - Original Message -
> From: "Mika Goeckel" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
> <[EMAIL PROTECTED]>
> Sent: Thursday, November 15, 2001 3:31 AM
> Subject: Re: Distributed Session Management
> 
> | Tom,
> |
> | from my (personal?!) philosophy, tests should be with the tested targets.
> My
> | experience tells me that tests get out of focus if they are in a separate
> | tree.
> 
> I agree, I like to place them in the same package as the code being tested.
> In other projects, I've used a naming convention to distiguish between
> Test classes and other classes (e.g. test classes are named Test?.java)
> 
> | Now when you are going to start hacking, is your approach creating use
> | cases, sequence diagrams etc. before, or something like class
> responsibility
> | cards?
> 
> Usually, I use a combination of things. In my mind the electronic equivalent
> of class responsibility cards are java interface definitions or sparse
> classes
> with some javadoc. The initial message that I sent out that started this
> thread
> had a couple of java interfaces. I'll be sending some more around. I'll may
> also
> send some class diagrams, and sequence or collaboration diagrams.
> 
> Tom
> 
> P.S.
> 
> |
> | M.
> |
> | - Original Message -
> | From: "Tom Drake" <[EMAIL PROTECTED]>
> | To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> | Sent: Wednesday, November 14, 2001 8:39 PM
> | Subject: Distributed Session Management
> |
> |
> | > Tomcat Developers:
> | >
> | > I'm going to try to synthesize the results of yesterdays
> | > discussion on Distributed Session Management into some
> | > working code. From what I can tell, there will be some
> | > changes and new objects in the org.apache.session
> | > package, and possibly some new objects in the
> | > org.apache.cluster package.
> | >
> | > I should have something to share in the next couple of
> | > days. I'll be creating JUnit tests as I write this code. Is there
> | > a standard place to put JUnit tests, or can I simply place
> | > them in the same package as the classes being tested?
> | >
> | > Regards,
> | >
> | > Tom Drake
> | > Email: [EMAIL PROTECTED]
> | >
> | >
> | > --
> | > To unsubscribe, e-mail:
> | 
> | > For additional commands, e-mail:
> | 
> | >
> |
> |
> | --
> | To unsubscribe, e-mail:
> 
> | For additional commands, e-mail:
> 
> |
> |
> |
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: Distributed Session Management

[Tom Drake]

Mika:


- Original Message -
From: "Mika Goeckel" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>; "Tom Drake"
<[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 3:31 AM
Subject: Re: Distributed Session Management


| Tom,
|
| from my (personal?!) philosophy, tests should be with the tested targets.
My
| experience tells me that tests get out of focus if they are in a separate
| tree.

I agree, I like to place them in the same package as the code being tested.
In other projects, I've used a naming convention to distiguish between
Test classes and other classes (e.g. test classes are named Test?.java)

| Now when you are going to start hacking, is your approach creating use
| cases, sequence diagrams etc. before, or something like class
responsibility
| cards?

Usually, I use a combination of things. In my mind the electronic equivalent
of class responsibility cards are java interface definitions or sparse
classes
with some javadoc. The initial message that I sent out that started this
thread
had a couple of java interfaces. I'll be sending some more around. I'll may
also
send some class diagrams, and sequence or collaboration diagrams.

Tom

P.S.

|
| M.
|
| - Original Message -
| From: "Tom Drake" <[EMAIL PROTECTED]>
| To: "Tomcat Dev List" <[EMAIL PROTECTED]>
| Sent: Wednesday, November 14, 2001 8:39 PM
| Subject: Distributed Session Management
|
|
| > Tomcat Developers:
| >
| > I'm going to try to synthesize the results of yesterdays
| > discussion on Distributed Session Management into some
| > working code. From what I can tell, there will be some
| > changes and new objects in the org.apache.session
| > package, and possibly some new objects in the
| > org.apache.cluster package.
| >
| > I should have something to share in the next couple of
| > days. I'll be creating JUnit tests as I write this code. Is there
| > a standard place to put JUnit tests, or can I simply place
| > them in the same package as the classes being tested?
| >
| > Regards,
| >
| > Tom Drake
| > Email: [EMAIL PROTECTED]
| >
| >
| > --
| > To unsubscribe, e-mail:
| 
| > For additional commands, e-mail:
| 
| >
|
|
| --
| To unsubscribe, e-mail:

| For additional commands, e-mail:

|
|
|


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

Re: Tomcat: Distributed Session Management revisited

[Tom Drake]

Mika, Costin:

While pondering things yesterday, the thought occured to me as well,
perhaps this whole notion of distributed management had a wider
application (beyond simply HttpSessions).

Having said that. I disagree, that Tomcat should expose an 'object
replication service' api to web-application writers. Such a thing
is clearly NOT a standard. Tomcat developers, on the other
hand, may, over-time find other uses for such a mechanism.
If we were to create such a generic object replication service,
it should be packaged separately from Tomcat

This, however, is secondary to my primary goal. So, I will
be providing abstractions where it seems to make the most
sense. But I definately want to keep things as simple as possible,
and not 'over-design' this thing. I'd like to create a working
solution that solves the real business problems (discussed ad
nauseum on this list).


Tom


- Original Message -
From: "Mika Goeckel" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 3:24 AM
Subject: Re: Tomcat: Distributed Session Management revisited


| Costin,
|
| that point of view is really interesting. What about separating the
| distribution part from the integration part of a integrated solution.
| That would user's give the option to use the "transparent session
| replication" or to use "explicit object replication services".
| The former would ease their live with the drawback of missing transaction
| support, the latter would give the app-developer all control over it.
|
| M.
|
| - Original Message -
| From: <[EMAIL PROTECTED]>
| To: "Tomcat Developers List" <[EMAIL PROTECTED]>
| Sent: Wednesday, November 14, 2001 6:27 PM
| Subject: Re: Tomcat: Distributed Session Management revisited
|
|
| > To clarify: creating a Distributed Session Manager is a good idea, and
| > something that would be great for users.
| >
| > My problem is with designing it at container-level, as an implementation
| > of the servlet session API.
| >
| > Having all objects in a session distributed and no control or feedback
is
| > not good.
| >
| > You could have a DSMServlet that would have some init parameters in
| > web.xml. There you can specify what classes/interfaces you want
| > 'distributed', or even what attributes ( by name ).
| >
| > Then you can use the existing listeners and notifications to detect when
| > those objects are saved in the session and do the distribution.
| >
| > You could also define a simple API allowing the user to control this -
for
| > example and update() method to be called after the user changes an
object.
| >
| > What's different here is that the behavior of servlet sessions doesn't
| > change - most objects can still be stored without an overhead. The user
| > gets to choose what objects to persist/distribute and he has control
over
| > the process. And this will work in _any_ container, so the user can
assume
| > the objects he marks as persistent/distributable will be this way on any
| > container ( you can't force people to switch to a different container to
| > use your webapp )
| >
| > You can also define specialized interfaces to be implemented by the
| > objects that will be persisted/distributed.
| >
| > All of this can be done with only standard 2.3 support. A container may
| > provide aditional hooks ( valves, interceptors, etc) of course.
| >
| > Costin
| >
| >
| > --
| > To unsubscribe, e-mail:
| 
| > For additional commands, e-mail:
| 
| >
|
|
| --
| To unsubscribe, e-mail:

| For additional commands, e-mail:

|
|
|


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

DO NOT REPLY [Bug 4893] New: - Tomcat dies with following error..

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4893

Tomcat dies with following error..

   Summary: Tomcat dies with following error..
   Product: Tomcat 3
   Version: 3.2.1 Final
  Platform: Sun
OS/Version: Solaris
Status: UNCONFIRMED
  Severity: Blocker
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi !

I am running a servlet based application on Apache-tomcat 3.2.1 on Sun Solaris
platform. Everything is fine in development environment. In live environment
when there is huge load on the server, tomcat dies with following error
message :


FATAL ERROR in native method: JDWP "util.c" (Aug  8 2001), line 1019:
Unexpected error, error code = 51 (JVMDI_ERROR_NOT_MONITOR_OWNER)

Can you tell me what is causing this error and how to find the solution..

With Regards

Ravi

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

Re: Portable SSL Support

[costinm]

On 14 Nov 2001, Eric Rescorla wrote:

> Well, I suppose that since JDK 1.1.x didn't stop you from putting
> classes in java. I could do my own version of
> java.security.cert.X509Certificate. A little gross but perhaps
> the best plan. The alternative is to blatantly violate the spec
> in 1.1 and just deliver something else.

I would say - don't worry about JDK1.1. Support for JDK1.1 is important
for embeded devices ( but even there, GCJ does have X509Certificate - it
already supports a large subset of JDK1.2, and that's included ).


> > > > You have to use request.getAttribute() in the JSPs/servlets.
> > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > interface. Instead we could break out each individual property
> > > we cared about into it's own attribute.
> >
> > To be consistant with 2.3 containers, I'd go with individually named
> > attributes.

> Fine with me. Anyone object to this?

Individual attributes are good, but if possible with lazy evaluation.

The getInfo() callback in BaseInterceptor is supposed to do exactly that -
allow you to lazy-evaluate expensive request fields, so only servlets that
ask for the information will pay for it.

Costin


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

Re: Portable SSL Support

[costinm]

On Wed, 14 Nov 2001, Paul Speed wrote:

>
>
> Eric Rescorla wrote:
> >
> [snip]
> > >
> > > To be consistant with 2.3 containers, I'd go with individually named
> > > attributes.
> > Fine with me. Anyone object to this?
> >
> > -Ekr
>
> I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
> was the former, but all of the servlet 2.3 comments recently make
> me now think it's the latter.

My understanding is that it'll eventually be both. Even for 3.x, anything
we implement must take into consideration the clarifications in 2.3.

Costin


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

Re: Tomcat: Distributed Session Management revisited

[cmanolache]

On Thu, 15 Nov 2001, Mika Goeckel wrote:

> Costin,
>
> that point of view is really interesting. What about separating the
> distribution part from the integration part of a integrated solution.
> That would user's give the option to use the "transparent session
> replication" or to use "explicit object replication services".
> The former would ease their live with the drawback of missing transaction
> support, the latter would give the app-developer all control over it.

More important is separating the implementation of the 'distribution'
part as a stand-alone module.

I'm absolutely -1 on putting this in the same space with the main tomcat4
- it's already a huge mess and adding this much complexity is going to make
things worse.

Costin


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

Re: Portable SSL Support

[costinm]

On Thu, 15 Nov 2001, jean-frederic clere wrote:

> > > Yes, but the question is what does it costs to setAttribute each time we process
> > > a request even if the servlet does not do a getAttribute.
>
> > Yes, this is a good point. This suggests that we ought to just
> > expose SSLSupport as a single attribute because it will be faster.
> > Is that what you're saying?
>
> Yes, but now I am thinking that it only makes sense in mod_webapp (WARP) /mod_jk
> (Ajp14)  where the SSL informations are requested in a separate dialog step
> between httpd and TC.

I think it makes sense for the other cases as well, since the evaluation (
construction of Cert, etc ) can be done only if needed ( i.e. lazy ).

For Ajp14 you'll get an extra benefit if you don't even send it unless
needed.

On the other side, I'm not sure exposing SSLSupport as a req. attribute
is very easy - we must thing about security. If SSLSupport will be recycled,
which it should, then untrusted servlets should not be able to get a
reference to it, otherwise they can hang on the reference and access
informations on other webapps. And I see no need to have it visible to
servlets.

It can be stored as a private attribute ( note in 3.3 ), and that will
also make the access faster.

BTW, regarding JDK1.1 compatibility - I assume most of it will be done as
a module ( you should have all the hooks you need ), and modules don't
have to be 1.1 compatible. The only requirement is that people should be
able to build and run a basic functional container using JDK1.1 - and we
already have this.


Costin






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

Default policy file for TC4 - excessive permissions

[Antony Bowesman]

The catalina.policy file gives AllPermissions to the webapp shared
lib/classes directories by default.  Isn't this too liberal.  Shouldn't
the policy file explicitly name the 3 jars with the default 4.0.1
distribution in lib.

Rgds
Antony

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

DO NOT REPLY [Bug 4891] New: - Tyrex's EnabledDataSource cannot find JDBC driver's class placed in $CATALINA_HOME/lib

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4891

Tyrex's EnabledDataSource cannot find JDBC driver's class placed in $CATALINA_HOME/lib

   Summary: Tyrex's EnabledDataSource cannot find JDBC driver's
class placed in $CATALINA_HOME/lib
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tyrex's EnabledDataSource cannot find JDBC driver's class placed in 
$CATALINA_HOME/lib. But when the driver is placed in the same dir where tyrex 
library resides ($CATALINA_HOME/common/lib/) it works ok. Suspect ther're 
different classloaders for these directories. But according to documentation, 
user libraries should be placed to $CATALINA_HOME/lib and 
$CATALINA_HOME/classes.

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

DO NOT REPLY [Bug 4887] - catalina / LocalStrings_es.properties needs update

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4887

catalina / LocalStrings_es.properties needs update





--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 05:27 ---
Created an attachment (id=796)
LocalStrings_es.properties updated file

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

DO NOT REPLY [Bug 4887] New: - catalina / LocalStrings_es.properties needs update

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4887

catalina / LocalStrings_es.properties needs update

   Summary: catalina / LocalStrings_es.properties needs update
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I include the file 

 catalina / src / share / org / apache / catalina / LocalStrings_es.properties

updated to show the last changes

This is a simple patch so I would like to see this file inside the new Tomcat 
release.

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

AW: Distributed Session Management

[Lauer, Oliver]

Hi, 

if I can help please tell.

Oliver
> AXA eSolutions GmbH
> AXA Konzern AG Germany
> Oliver Lauer 
> Web Architect
> Wörthstraße 34
> D-50668 Köln
> Germany
> Tel.: +49 221 148 31277
> Fax: +49 221 148 43963
> Mobil: +49 179 59 064 59
> e-Mail: [EMAIL PROTECTED]
> _
> 


-Ursprüngliche Nachricht-
Von: Mika Goeckel [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 15. November 2001 12:32
An: Tomcat Developers List; Tom Drake
Betreff: Re: Distributed Session Management


Tom,

from my (personal?!) philosophy, tests should be with the tested targets. My
experience tells me that tests get out of focus if they are in a separate
tree.
Now when you are going to start hacking, is your approach creating use
cases, sequence diagrams etc. before, or something like class responsibility
cards?

M.

- Original Message -
From: "Tom Drake" <[EMAIL PROTECTED]>
To: "Tomcat Dev List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 8:39 PM
Subject: Distributed Session Management


> Tomcat Developers:
>
> I'm going to try to synthesize the results of yesterdays
> discussion on Distributed Session Management into some
> working code. From what I can tell, there will be some
> changes and new objects in the org.apache.session
> package, and possibly some new objects in the
> org.apache.cluster package.
>
> I should have something to share in the next couple of
> days. I'll be creating JUnit tests as I write this code. Is there
> a standard place to put JUnit tests, or can I simply place
> them in the same package as the classes being tested?
>
> Regards,
>
> Tom Drake
> Email: [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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



Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene Information 
nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung reichen wir Ihnen gerne 
auf Anforderung in schriftlicher Form nach. Beachten Sie bitte, dass jede Form der 
unautorisierten Nutzung, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des 
Inhalts dieser E-Mail nicht gestattet ist.Diese Nachricht  ist ausschliesslich fuer 
den bezeichneten Adressaten oder dessen Vertreter bestimmt. Sollten Sie nicht der 
vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich 
mit dem Absender der E-Mail in Verbindung zu setzen.

For legal and security reasons the information provided in this e-mail is not legally 
binding. Upon request we would be pleased to provide you with a legally binding 
confirmation in written form. Any form of unauthorised use, publication, reproduction, 
copying or disclosure of the content of this e-mail is not permitted. This message is 
exclusively for the person addressed or their representative. If you are not the 
intended recipient of this message and its contents, please notify the sender 
immediately.
---



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

DO NOT REPLY [Bug 3509] - Apache 1.3.20 & mod_webapp & Tomcat 4b7 HANGS under Win

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3509

Apache 1.3.20 & mod_webapp & Tomcat 4b7 HANGS under Win

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary||Apache 1.3.20 & mod_webapp &
   ||Tomcat 4b7 HANGS under Win



--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 03:37 ---
Someone removed the summary.

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

Re: Distributed Session Management

[Mika Goeckel]

Tom,

from my (personal?!) philosophy, tests should be with the tested targets. My
experience tells me that tests get out of focus if they are in a separate
tree.
Now when you are going to start hacking, is your approach creating use
cases, sequence diagrams etc. before, or something like class responsibility
cards?

M.

- Original Message -
From: "Tom Drake" <[EMAIL PROTECTED]>
To: "Tomcat Dev List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 8:39 PM
Subject: Distributed Session Management


> Tomcat Developers:
>
> I'm going to try to synthesize the results of yesterdays
> discussion on Distributed Session Management into some
> working code. From what I can tell, there will be some
> changes and new objects in the org.apache.session
> package, and possibly some new objects in the
> org.apache.cluster package.
>
> I should have something to share in the next couple of
> days. I'll be creating JUnit tests as I write this code. Is there
> a standard place to put JUnit tests, or can I simply place
> them in the same package as the classes being tested?
>
> Regards,
>
> Tom Drake
> Email: [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: Portable SSL Support

[jean-frederic clere]

Eric Rescorla wrote:
> 
> > Eric Rescorla wrote:
> > > jean-frederic clere <[EMAIL PROTECTED]> writes:
> > > > Eric Rescorla wrote:
> > > > With JDK 1.1.x and AJP a null is returned.
> > > > With JDK 1.1.x should the CC be returned as a String? (I thought it was).
> > > It's certainly not in the JSSE code I was porting. That code
> > > didn't even compile without JDK 1.2.x.
> >
> > You are right but Ajp does not need JSSE (See Ajp13.java).
> Correct. Currently it tries to convert it to a certificate but
> uses a string if it can't find JSSE. We could easily arrange
> that it did something cleverer than this.
> 
> > > from build.xml:
> > >> >unless="jdk12.present"/>
> > >
> > > In any case, we can do something far more sophisticated than a String
> > > if we want to, even with JDK 1.1.x.
> >
> > It was a String in the past.
> Right, but that's not exactly the most convenient interface.
> 
> > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > interface. Instead we could break out each individual property
> > > we cared about into it's own attribute.
> >
> > Yes, but the question is what does it costs to setAttribute each time we process
> > a request even if the servlet does not do a getAttribute.
> Yes, this is a good point. This suggests that we ought to just
> expose SSLSupport as a single attribute because it will be faster.
> Is that what you're saying?

Yes, but now I am thinking that it only makes sense in mod_webapp (WARP) /mod_jk
(Ajp14)  where the SSL informations are requested in a separate dialog step
between httpd and TC. 

> 
> It's actually easier for me to just expose SSLSupport but I want
> to do whatever's most appropriate and that's why I sought people's
> comments. The reason I wonder if we should set attributes is that
> that's what Ajp currently does.
> 
> > Another question is what about "javax.servlet.request.ssl_session" in PureSSL?
> > Could we get it? (That is the  SSL_SESSION_ID of mod_ssl).
> I'll have to modify PureTLS to expose it but it's not inherently
> difficult. Again, we'd want to add this to SSLSupport, I imagine.

Yes 

> 
> -Ekr

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

Re: Tomcat: Distributed Session Management revisited

[Mika Goeckel]

Costin,

that point of view is really interesting. What about separating the
distribution part from the integration part of a integrated solution.
That would user's give the option to use the "transparent session
replication" or to use "explicit object replication services".
The former would ease their live with the drawback of missing transaction
support, the latter would give the app-developer all control over it.

M.

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 6:27 PM
Subject: Re: Tomcat: Distributed Session Management revisited


> To clarify: creating a Distributed Session Manager is a good idea, and
> something that would be great for users.
>
> My problem is with designing it at container-level, as an implementation
> of the servlet session API.
>
> Having all objects in a session distributed and no control or feedback is
> not good.
>
> You could have a DSMServlet that would have some init parameters in
> web.xml. There you can specify what classes/interfaces you want
> 'distributed', or even what attributes ( by name ).
>
> Then you can use the existing listeners and notifications to detect when
> those objects are saved in the session and do the distribution.
>
> You could also define a simple API allowing the user to control this - for
> example and update() method to be called after the user changes an object.
>
> What's different here is that the behavior of servlet sessions doesn't
> change - most objects can still be stored without an overhead. The user
> gets to choose what objects to persist/distribute and he has control over
> the process. And this will work in _any_ container, so the user can assume
> the objects he marks as persistent/distributable will be this way on any
> container ( you can't force people to switch to a different container to
> use your webapp )
>
> You can also define specialized interfaces to be implemented by the
> objects that will be persisted/distributed.
>
> All of this can be done with only standard 2.3 support. A container may
> provide aditional hooks ( valves, interceptors, etc) of course.
>
> Costin
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Re: Portable SSL Support

[jean-frederic clere]

Bill Barker wrote:
> 
> This is for TC 3.3.  As a result, we are only required to expose the
> certificates. However, there is nothing that prevents exposing other request
> attributes as a non-portable feature (and Ajp13 & JNI already do this).

For TC 3.3:
I would advice to follow 2.3 when JVM1.2.x/1.3.x/1.4.x and a String when
JVM1.1.x because there are a lot of old examples where the CC is delivered as a
String...

For TC 4.x:
We have to follow the 2.3 spec's.

> 
> However, it's also likely to be adopted in j-t-c which supports both 3.3 and
> 4.x.
> - Original Message -
> From: "Paul Speed" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, November 14, 2001 11:39 AM
> Subject: Re: Portable SSL Support
> 
> >
> >
> > Eric Rescorla wrote:
> > >
> > [snip]
> > > >
> > > > To be consistant with 2.3 containers, I'd go with individually named
> > > > attributes.
> > > Fine with me. Anyone object to this?
> > >
> > > -Ekr
> >
> > I'm confused.  Is this for Tomcat 3.x or Tomcat 4.x?  I thought it
> > was the former, but all of the servlet 2.3 comments recently make
> > me now think it's the latter.
> > -Paul
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> >
> 
> **
> 
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
> 
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

tomcat 4.01 SSL stop work

[123times . com webmaster]

I run tomcat 4.01 in Solaris under JDK1.4.

after i start tomcat ,http and https is work well,
but after a minutes,https is unable to connect use by ie,but http is still visitable.

Then i telnet to 443,It's have echo.

Who can help me to resolve it.

Thanks all.

RE: IIS and TC4

[Kevin Jones]

Thank you,

Kevin Jones
Developmentor
www.develop.com

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: 14 November 2001 22:30
> To: Tomcat Developers List
> Subject: RE: IIS and TC4
>
>
> >sorry to ask on this list as this is really a user question,
> >but I'm not on
> >Tomcat-User (too much noise :-) ) so I hope you'll bear with me.
>
> Sure
>
> >Is there a connector available for IIS and TC4? I've searched
> >the archives
> >of both lists and not come up with a definitive answer.
>
> AJP13 is supported in Tomcat 4.0.1 and so you could use mod_jk.
>
> >Can I use the Tomcat 3.3 IIS connector with Tomcat 4? ditto with list
> >searches.
>
> Yes, you could use it to make Tomcat 4 and IIS work together
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail: 


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