DO NOT REPLY [Bug 22677] New: - JNDI not working in Default Context

[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=22677

JNDI not working in Default Context

   Summary: JNDI not working in Default Context
   Product: Tomcat 4
   Version: 4.1.27
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I and a few other users seem to have an issue with JNDI datasources defined in
the default context, or in the global resources. When defined in a specific
Context there is no issue (except it defeats the ability to automatically
deploy), however if a JNDI resource is defined in DefaultContext or
GlobalNamingResources we get a error.

There are two errors depending on where the resource-ref is. If there is a
resource-ref in the web.xml you get a:
java.sql.SQLException: Cannot load JDBC driver class 'null'
If you define the Resource in the server.xml you get 
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context

*  Version - Tomcat 4.1.27 also reported in v5.0

* Tomcat component - Catalina

* Platform - Intel/PC

* OS - Mandrake 9.

* JVM - 1.4

* Web Server - none 

* Configuration - 

server.xml-->




usernamefoo
passwordfoo
driverClassName
org.postgresql.Driver
url
jdbc:postgresql://localhost/foo



web.xml-->

  
  Foo Database
  jdbc/foo
  javax.sql.DataSource
  Container
  


* Log file excerpts and Stack Traces 


DEBUG (LoginAction.java:36) - peter
ERROR (OfficeUserImpl.java:45) - SQL Exception : Cannot load JDBC driver class
'null'
java.sql.SQLException: Cannot load JDBC driver class 'null'
at
nz.co.asterisk.arpt.dao.OfficeUserBase.getConnection(OfficeUserBase.java:301)
at
nz.co.asterisk.arpt.dao.implementation.OfficeUserImpl.verifyUser(OfficeUserImpl.java:27)
at nz.co.asterisk.arpt.actions.LoginAction.perform(LoginAction.java:44)
at
org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:

Re: IP address Assignment problem

[Reshat Sabiq]

Ayoub Raffoul wrote:

Hello,

I'm running Apache Tomcat ver. 4.1 on a Windows 2000 server. The 
machine has multipe IP addresses. I have configured Apache Tomcat in 
server.xml to run on a specific IP address port 80 as follows (fake IP 
address):

   
port="80"   minProcessors="5" maxProcessors="75"
  enableLookups="true" redirectPort="8443"
  acceptCount="100" debug="0" connectionTimeout="2"
  useURIValidationHack="false" disableUploadTimeout="true" 
address="205.200.21.30"/>

I also need to run IIS on the same machine though on a different IP 
IE: 205.200.21.31 and port 80. Each time I try to launch IIS I get an 
error message saying port is in use. If I shut down Tomcat then the 
port get released and I'm able to launch Tomcat. It seems that Tomcat 
is reserving all ports # 80 for all IP addresses on this machine. This 
configuration was working correctly in an older version of Tomcat.
Even though Tomcat seems to be reserving all port 80 for all IP 
addresses it is only responding to 205.200.21.30.

Vice Versa is also a problem. If I shut down Tomcat and start IIS on 
205.200.21.31:80, Tomcat will no longer launch on 205.200.21.30:80. It 
will report that the port is in use.

Has anybody encountered a similar issue? Your help is highly appreciated.

Thank you

___
A port denotes an application, so i'm suprised you were previously able 
to have 2 applications on the same machine on the same port. In other 
words, the OS needs be aware and support different-IP-same-port 
distinction. I don't know if Win or others do that.

--
Sincerely,
Reshat.
---
If you see my certificate with this message, you should be able to send me encrypted e-mail. 
Please consult your e-mail client for details if you would like to do that.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: DO NOT REPLY [Bug 22626] - Removing a webapp(context) doesn'tclose its datasources(resource)

[Dirk Verbeeck]

Then maybe we should define an extended interface or something.
- the factory implements a destroy method that can be used
- the resource implements Closeable then it can be closed
- an eventlistener is registered by the factory to do the cleanup
- a Runnable object is bound with JNDI name "shutdown-xxx" (and contains 
the shutdown code for xxx)
- configurable reflection solution
- ...

Lots of possebilities, you just have to find something that fits the 
general design.

Dirk

Remy Maucherat wrote:

Dirk Verbeeck wrote:

A more general solution then?


?
By definition, all resources have their own custom way of being 
released (hence the WONTFIX). If the JNDI interface included a 
"release" or something, it could possibly be made to work, but here, I 
don't see any way to come up with a generic solution.

Remy



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







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

Auto-Confirmation

[Quest Software]

Thank you for submitting your request to Quest Software Technical Support.  We are 
unable to process your request because our records indicate that you are not 
registered for Technical Support.

To register, logon to our Supportlink web site http://www.quest.com/support , and  
self-register from the web.  Or, you can phone Quest at one of the numbers below to 
register.

Once you have registered, you can submit your request within Supportlink, by email at 
[EMAIL PROTECTED], by phone at one of the numbers below.

Please do not reply to this email.

If this is an URGENT matter please contact Quest Technical Support via telephone at 
one of the numbers listed below.

Thank you,

Quest Software Technical Support
www.quest.com/support

Quest Software Technical Support - Canada   902.442.5700
Quest Software Technical Support - United Kingdom  44.1628.601007
Quest Software Technical Support - United States  949.754.8000
>  Original Message
>  From: "[EMAIL PROTECTED]" [mailto:[EMAIL PROTECTED]
>  Sent: 23 Aug 2003 15:46:45 -
>  To: [EMAIL PROTECTED]
>  Subject: DO NOT REPLY [Bug 22673] New:  -cannot run "catalina.sh debug"
>  
>  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=22673
>  
>  cannot run "catalina.sh debug"
>  
> Summary: cannot run "catalina.sh debug"
> Product: Tomcat 4
> Version: 4.1.27
>Platform: Other
>  OS/Version: Linux
>  Status: NEW
>Severity: Normal
>Priority: Other
>   Component: Unknown
>  AssignedTo: [EMAIL PROTECTED]
>  ReportedBy: [EMAIL PROTECTED]
>  
>  
>  script fails with the error
>  
>  catalina.sh: line 166: exec: : not found
>  
>  I tracked it down to line 56 in setclasspath.sh. the test condition on that line
>  is not what it should be.
>  
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>  

Auto-Confirmation

[Quest Software]

Thank you for submitting your request to Quest Software Technical Support.  We are 
unable to process your request because our records indicate that you are not 
registered for Technical Support.

To register, logon to our Supportlink web site http://www.quest.com/support , and  
self-register from the web.  Or, you can phone Quest at one of the numbers below to 
register.

Once you have registered, you can submit your request within Supportlink, by email at 
[EMAIL PROTECTED], by phone at one of the numbers below.

Please do not reply to this email.

If this is an URGENT matter please contact Quest Technical Support via telephone at 
one of the numbers listed below.

Thank you,

Quest Software Technical Support
www.quest.com/support

Quest Software Technical Support - Canada   902.442.5700
Quest Software Technical Support - United Kingdom  44.1628.601007
Quest Software Technical Support - United States  949.754.8000
>  Original Message
>  From: "Tim Funk" [mailto:[EMAIL PROTECTED]
>  Sent: Sat, 23 Aug 2003 10:50:54 -0400
>  To: Tomcat Developers List [EMAIL PROTECTED]
>  Subject: Re: [VOTE] 5.0.9 stability rating
>  
>  Installed 5.0.9 from exe (win2k)
>  1) startup.bat worked fine, but the icon which calls tomcatw.exe" 
>  //GT//Tomcat5 fails will some "Current Thread not owner error"
>  2) Race conditions and connection handling in JDBCRealm - plus a whole host 
>  of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next 
>  week to have a patch which will close many of the JDBCRealm bugs.
>  3) Need to reinvestigate the JNDIRealm bug reopened.
>  
>  For the first error - I am sure I just need to look through bugzilla, or the 
>  archives and just need to add something to the README.  (User error)
>  
>  For the last 2 errors - tomcat can be considered beta or stable with the 
>  buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code 
>  was part of a stable release.
>  
>  -Tim
>  
>  Remy Maucherat wrote:
>  > 
>  > [X] Alpha
>  > [ ] Beta
>  > 
>  > 
>  
>  
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>  

DO NOT REPLY [Bug 22673] New: - cannot run "catalina.sh debug"

[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=22673

cannot run "catalina.sh debug"

   Summary: cannot run "catalina.sh debug"
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


script fails with the error

catalina.sh: line 166: exec: : not found

I tracked it down to line 56 in setclasspath.sh. the test condition on that line
is not what it should be.

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

Re: [VOTE] 5.0.9 stability rating

[Tim Funk]

Installed 5.0.9 from exe (win2k)
1) startup.bat worked fine, but the icon which calls tomcatw.exe" 
//GT//Tomcat5 fails will some "Current Thread not owner error"
2) Race conditions and connection handling in JDBCRealm - plus a whole host 
of other JDBCRealm bugs in Bugzilla applicable to 4 and 5. I hope early next 
week to have a patch which will close many of the JDBCRealm bugs.
3) Need to reinvestigate the JNDIRealm bug reopened.

For the first error - I am sure I just need to look through bugzilla, or the 
archives and just need to add something to the README.  (User error)

For the last 2 errors - tomcat can be considered beta or stable with the 
buggy JNDIRealm and JDBCRealms since the tomcat4.1 version of the same code 
was part of a stable release.

-Tim

Remy Maucherat wrote:

[X] Alpha
[ ] Beta



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

Need help for workers2.properties file

[EPC]

Hi,

I'm using mod_jk2 with Tomcat 5 (Alpha) & Apache 2, running 
successfully.
But regarding the "workers2.properties" file I have few queries. 
It would be great, if you can comment on them.

[shm]
file=${serverRoot}/logs/shm.file
size=1048576
Q : What exactly above line indicates ? What this *size* indicates 
? What is a *shm* file ?

[channel.socket:localhost:8009]
Q : Are there any other types of communication options available ? 
Are the square brackets part of syntax ?

[ajp13:localhost:8009]
channel=channel.socket:localhost:8009
Q : Is it a right way to declare a *tomcat worker* ? Are any 
additional options available ?

[uri:/jsp-examples/*]
worker=ajp13:localhost:8009
Q : Typically is it a correct way to put URI mappings ?
It would be a *great* help, if someone can put a sample 
"workers2.properties" file contents with comments.

TIA & Regards,
-EPC
___
Art meets Army ; Swapna Weds Capt. Rajsekhar.
Rediff Matchmaker strikes another interesting match !!
Visit http://matchmaker.rediff.com?2


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

>> tomcat4 / jk2 / apache2 / mod_rewrite <

[admin]

hello list,

I have a working apache2/tomcat/jk2 setup that is running 1 webapp.
(this setup is running on RedHat9 if that matters...)
My search engine optimization company is asking us to use mod_rewrite
to make the URLs more SE friendly.  So, we are trying to get mod_rewrite
setup to do just that.
mod_rewrite is installed by default, so that was easy.
We actually got mod_rewrite to work by mapping a URL to a file here:
http://usachurch.com/arizona/phoenix/

which is a non-existent location being mapped to the webapp via:

RewriteEngine on
RewriteRule   ^/arizona/phoenix/(.*)   /usachurch/$1
but, (if you check out that link) the index.jsp page is being served by
apache and not Tomcat4.  I have tried adding things like this to the
workers2.properties file:
[uri:*/arizona/phoenix*]
worker=ajp13:localhost:8009
but, tomcat just doesn't know to serve this page.
even this:
http://usachurch.com/arizona/phoenix/index.jsp

isn't served by tomcat.  and all .jsp pages are served by tomcat.
It seems that because mod_rewrite is touching the request, tomcat
isn't doing anything.
now, I already checked out this page:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/vhosthowto.html

and many others like it on the jakarta site.  but, I just can't seem 
to figure out
what to do.  as you can probably tell, I'm quite the novice java system admin.

Any ideas?

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

DO NOT REPLY [Bug 22645] New: - <%@ include file ="included.jsp" %> encoding problem

[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=22645

<%@ include file ="included.jsp" %> encoding problem

   Summary: <%@ include file ="included.jsp" %> encoding problem
   Product: Tomcat 4
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When the static including (<%@ include %>) JSP file has no specified character 
set for Response (<% page contentType %> but included file has, the including 
file has treated as "iso-8859-1" encoding and the included file treated as 
specified (as contentType) encoding" 

By the term “treated as XXX encoding”, I meant the Reader for XML(JSP) 
document has XXX encoding.

I think the XML(JSP) should be treated as specified by . 
And the XML, generated from JSP file which has no specific xml encoding 
equivalent information, should be treated as default encoding. 
(System.getProperty(“file.encoding”)) like .

Cf.) example source sinps
--- including.jsp ---
<%@ include file ="included.jsp" %>
including : 한글
--- 
--- included.jsp ---
<%@ page contentType="text/html; charset=euc-kr"%>
included : 한글
---

Cf.) possible patch to solve this problem
---
Index: ParserController.java
===
RCS file: /home/cvspublic/jakarta-tomcat-
4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.18
diff -u -r1.18 ParserController.java
--- ParserController.java   21 May 2002 01:40:13 -  1.18
+++ ParserController.java   22 Aug 2003 02:40:56 -
@@ -122,9 +122,8 @@
 /*
  * The encoding of the "top" file. This encoding is used
  * for included files by default.
- * Defaults to "ISO-8859-1" per JSP spec.
  */
-private String topFileEncoding = "ISO-8859-1"; 
+private String topFileEncoding = System.getProperty("file.encoding"); 
 
 /*
  * The 'new' encoding required to read a page.

--- 

I’ve removed the comment which has “per Spec”. I’ve reviewed the JSP 1.2 final 
spec. But it has nothing to do with the encoding of JSP file. But it only read 
that the Response should have “iso-8859-1” as default.

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

Re: [VOTE] 5.0.9 stability rating

[Remy Maucherat]

Remy Maucherat wrote:

[ ] Alpha
[X] Beta

Unlike 5.0.8, I haven't found any problems with this build, other than 
the two issues I mentioned.

Remy



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

Re: [VOTE] 5.0.9 stability rating

[Remy Maucherat]

Bill Barker wrote:
1) The admin webapp lies about Connector properties.
Yes, I mentioned that. To be accurate, I don't think the admin webapp 
has ever been glitch free in any release.

2) Authorization isn't spec-compliant (I mis-read the spec when I did it).
However, I heard a rumor that the spec may move closer to what Tomcat is
currently doing (what's in pfd3 is pretty nonsensical :), so I haven't been
in a rush to "fix" this.
Given that the final behavior is unclear, I do not quite see how this is 
a major problem. If this build becomes a beta, I'll add a note about 
that also.

We're not going to get anywhere IMO by trying to release a bug free 
*first* beta. For example, I don't know right now any bugs or issues I 
should work on, so I'm wasting my time.

Remy

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

DO NOT REPLY [Bug 22626] New: - Removing a webapp(context) doesn't close its datasources(resource)

[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=22626

Removing a webapp(context) doesn't close its datasources(resource)

   Summary: Removing a webapp(context) doesn't close its
datasources(resource)
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
   URL: http://issues.apache.org/bugzilla/show_bug.cgi?id=21182
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Reminder to fix issue 22625 in tomcat 5 tree
http://issues.apache.org/bugzilla/show_bug.cgi?id=22625


[dbcp] removing a webapp does not force connections closed
http://issues.apache.org/bugzilla/show_bug.cgi?id=21182 

Description:
as reported by Michael Holly and Tony Locke on [EMAIL PROTECTED]
"removing" a Tomcat webapp does not force connections present in DBCP pool be
closed.

In fact even if the webapp is unloaded and dbcp is unloaded 
there is nobody to call BasicDataSource.close()

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

DO NOT REPLY [Bug 22625] - Removing a webapp(context) doesn't close its datasources(resource)

[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=22625

Removing a webapp(context) doesn't close its datasources(resource)





--- Additional Comments From [EMAIL PROTECTED]  2003-08-21 14:27 ---
Mail to tomcat-dev (20/08/2003)

Hi

Here at commons-dbcp we have an open issue about the datasource not being closed
when the webapp context is removed.
http://issues.apache.org/bugzilla/show_bug.cgi?id=21182

There is a workaround but I think it should be fixed inside the container.
The BasicDataSource tomcat is using has a close method but I don't think it is
called.
I've looked in the tomcat 4 source but cannot find anything related to
closing/shutting down resources.

I would do something like this in the NamingContextListener
   public void removeResource(String name) {
   try {
   Object resource = envCtx.lookup(name);
   Method closeMethod = resource.getClass().getMethod("close", null);
   closeMethod.invoke(resource, null);
   }
   catch (Exception e) {
   log("Cannot close resource " + e);
   }

   try {
   envCtx.unbind(name);
   } catch (NamingException e) {
   log(sm.getString("naming.unbindFailed", e));
   }
   }

Mind you, I have never even compiled tomcat so maybe I'm totally looking in the
wrong place here.
Other solutions would be implementing a special interface or factory method or ...

We could of cource document the issue for tomcat 4 and fix it in 5.
Comments?

Regards
Dirk

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

Re: [VOTE] 5.0.9 stability rating

[Bill Barker]

Just realized that I marked the wrong box (d*** hanging chads :).  Changing
my vote to 'Alpha' for reasons given below.

"Bill Barker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> - Original Message -
> From: "Remy Maucherat" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Friday, August 22, 2003 10:20 AM
> Subject: [VOTE] 5.0.9 stability rating
>
>
> > 
> > [ ] Alpha
> > [X] Beta
> > 
> >
>
> 1) The admin webapp lies about Connector properties.
> 2) Authorization isn't spec-compliant (I mis-read the spec when I did it).
> However, I heard a rumor that the spec may move closer to what Tomcat is
> currently doing (what's in pfd3 is pretty nonsensical :), so I haven't
been
> in a rush to "fix" this.
>
>
>






> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




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

DO NOT REPLY [Bug 22645] - <%@ include file ="included.jsp" %> encoding problem

[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=22645

<%@ include file ="included.jsp" %> encoding problem





--- Additional Comments From [EMAIL PROTECTED]  2003-08-22 14:18 ---
it seems like this but has something to do with bug #19617

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