DO NOT REPLY [Bug 38318] New: - jsvc error: Cannot find any VM in Java Home /usr/lib/j2sdk1.5-sun

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=38318

   Summary: jsvc error: Cannot find any VM in Java Home
/usr/lib/j2sdk1.5-sun
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have an emt64 cpu and have installed debian-amd64 system.I have installed
jdk-1.5.02 for 64bit cpu.When tried to install tomcat as service of linux by
using jsvc,I had met configure error "unsupported cpu archtitecture".I fixed it
by following the solution mentioned in Bug#: 33494.But when tried to start
tomcat service,I had got error message "jsvc error: Cannot find any VM in Java
Home /usr/lib/j2sdk1.5-sun".How can I solve this problem?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 38315] - OutOfMemoryError : PermGen space

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=38315





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 12:15 ---
*** Bug 38317 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 38317] - OutOfMemoryError : PermGen space

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=38317


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 12:15 ---


*** This bug has been marked as a duplicate of 38315 ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 38315] - OutOfMemoryError : PermGen space

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=38315





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 17:29 ---
(In reply to comment #1)
> This isn't the correct way to do it.  Use the tomcat5w.exe executable to set 
> this in the "Java Options" box under the "Java" tab.

Hi,
I tried that too but it didn't work. Any other suggestions?

Thank you


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 37356] - Tomcat does not invalidate sessions after session-timeout period has passed.

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=37356


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|NEW




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Realm.authenticate() doesn't register Principal in Session.. use Authenticator instead?

2006-01-19 Thread Mark Thomas 
Please do not cross-post. This belongs on the users list BTW.

Mark
[EMAIL PROTECTED]


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

DO NOT REPLY [Bug 37788] - Use IPv6 with APR Connectors

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=37788





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 22:34 ---
The patch looks reasonable to me, but I would like to do further testing before 
committing

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36976] - Tomcat VM does not shutdown with remote jmx enabled

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=36976





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 23:35 ---
Have the same problem and found this bug thread.  Tried patch in comment #6. 
Now the error message is gone when I am trying to shutdown the tomcat.  But the
tomcat process is still there and I have to manually kill it to restart tomcat.
 Seems the problem is not fixed yet.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=7831





--- Additional Comments From [EMAIL PROTECTED]  2006-01-19 23:54 ---
I do want to add support for certificate authentication to the JNDIRealm and
your patch has given me food for thought. I am minded, however, to use your
patch as a basis for an implementation of getPrincipal() rather than over-riding
authenticate(X509Certificate).

In terms of suporting muliple LDAP servers my intention is to provide something
that works for OpenLDAP and can be over-ridden as required for other 
directories.

I have started to look at your patch and have the following comments. Where I
have questions, any further information you can provide will help me understand
the rationale for the approach you took.

1. I moved the classes into the o.a.c.Realm package.
2. Please keep to the coding standards of the original when copying source. It
makes it much easier to find where you have made any subtle changes.
3. CertUser looks to be unnecessary - why not use User from JNDIRealm?
4. Your changes to authenticate(String, String) appear to be unrelated to adding
support for certificates. Please keep patches for different issues separate so
they can be considered separately. Feel free to file a new bug for this one.
5. You appear to have reverted the patches for bugs 23190, 16541 and 26487. What
is the reason for this?
6. The patch for bug 22236 has also been reverted. Is this intentional?
7. If there a reason that getCertUserByPattern() isn't supported?
8. A change commiited at the same time as bug 22236 to
addAttributeValues(String, Attributes, ArrayList) that modified the return value
from null to values in a couple of places has also been reverted. Why?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r370664 - /tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/realm/MemoryRealm.java

2006-01-19 Thread markt 
Author: markt
Date: Thu Jan 19 15:01:07 2006
New Revision: 370664

URL: http://svn.apache.org/viewcvs?rev=370664&view=rev
Log:
Code clean up. Remove unused code.

Modified:

tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/realm/MemoryRealm.java

Modified: 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/realm/MemoryRealm.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/realm/MemoryRealm.java?rev=370664&r1=370663&r2=370664&view=diff
==
--- 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/realm/MemoryRealm.java
 (original)
+++ 
tomcat/container/branches/tc4.1.x/catalina/src/share/org/apache/catalina/realm/MemoryRealm.java
 Thu Jan 19 15:01:07 2006
@@ -22,7 +22,6 @@
 import java.io.File;
 import java.util.ArrayList;
 import java.util.HashMap;
-import org.apache.catalina.Container;
 import org.apache.catalina.LifecycleException;
 import org.apache.catalina.util.StringManager;
 import org.apache.commons.digester.Digester;
@@ -50,12 +49,6 @@
 
 
 /**
- * The Container with which this Realm is associated.
- */
-private Container container = null;
-
-
-/**
  * The Digester we will use to process in-memory database files.
  */
 private static Digester digester = null;
@@ -93,12 +86,6 @@
  */
 private static StringManager sm =
 StringManager.getManager(Constants.Package);
-
-
-/**
- * Has this component been started?
- */
-private boolean started = false;
 
 
 // - Properties



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

DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=35853





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 02:57 ---
I wonder if this is similar to a problem I have. Using Tomcat directly I can
access a webapp that is titled JSPWiki by going to http://url:8080/JSPWiki,
however if I try via JkMount it will fail to connect even though it found a 
match.

However if I renamed the webapp to jspwiki I can access it through Tomcat
directly and via mod_jk.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Response not flushed before RD.forward() returns

2006-01-19 Thread Jan Luehe 
Consider the following code snippet of a servlet's service() method:

  public class DispatcherServlet extends HttpServlet {

public void service(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException {

  request.getRequestDispatcher("/target").forward(request, response);

  try {
  Thread.currentThread().sleep(6);
  } catch (Exception ex) { }
}

where "target" prints some output to the response.

The code currently returns the output printed by "target" only after
DispatcherServlet's service() method has finished, instead of right
before RD.forward() returns.

This seems to be in violation of the Servlet Spec, which has this:

SRV.8.4 ("The Forward Method"):

  Before the forward() method of the RequestDispatcher interface
  returns, the response content must be sent and committed, and closed
  by the servlet container.

The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
looks like this:

// This is not a real close in order to support error processing
if ( log.isDebugEnabled() )
log.debug(" Disabling the response for futher output");

if  (response instanceof ResponseFacade) {
((ResponseFacade) response).finish();
} else {
// Servlet SRV.6.2.2. The Resquest/Response may have been
wrapped
// and may no longer be instance of RequestFacade
if (log.isDebugEnabled()){
log.debug( " The Response is vehiculed using a wrapper: "
   + response.getClass().getName() );
}

// Close anyway
try {
PrintWriter writer = response.getWriter();
writer.close();
} catch (IllegalStateException e) {
try {
ServletOutputStream stream = response.getOutputStream();
stream.close();
} catch (IllegalStateException f) {
;
} catch (IOException f) {
;
}
} catch (IOException e) {
;
}
}

In the above code sample, response will be an instance of
ResponseFacade, meaning it will be suspended instead of being flushed
and closed right away.

Does anyone remember why the "response instanceof ResponseFacade"
check is there? I would have expected the "else" case to always be
executed.

Any hints appreciated.

Thanks,


Jan


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

DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=35853


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

RE: Response not flushed before RD.forward() returns

2006-01-19 Thread Bill Barker 
 

> -Original Message-
> From: Jan Luehe [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, January 19, 2006 5:57 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Response not flushed before RD.forward() returns
> 
> Consider the following code snippet of a servlet's service() method:
> 
>   public class DispatcherServlet extends HttpServlet {
> 
> public void service(HttpServletRequest req, 
> HttpServletResponse res)
> throws IOException, ServletException {
> 
>   
> request.getRequestDispatcher("/target").forward(request, response);
> 
>   try {
>   Thread.currentThread().sleep(6);
>   } catch (Exception ex) { }
> }
> 
> where "target" prints some output to the response.
> 
> The code currently returns the output printed by "target" only after
> DispatcherServlet's service() method has finished, instead of right
> before RD.forward() returns.
> 
> This seems to be in violation of the Servlet Spec, which has this:
> 
> SRV.8.4 ("The Forward Method"):
> 
>   Before the forward() method of the RequestDispatcher interface
>   returns, the response content must be sent and committed, and closed
>   by the servlet container.
> 
> The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
> looks like this:
> 
> // This is not a real close in order to support error 
> processing
> if ( log.isDebugEnabled() )
> log.debug(" Disabling the response for futher output");
> 
> if  (response instanceof ResponseFacade) {
> ((ResponseFacade) response).finish();
> } else {
> // Servlet SRV.6.2.2. The Resquest/Response may have been
> wrapped
> // and may no longer be instance of RequestFacade
> if (log.isDebugEnabled()){
> log.debug( " The Response is vehiculed using 
> a wrapper: "
>+ response.getClass().getName() );
> }
> 
> // Close anyway
> try {
> PrintWriter writer = response.getWriter();
> writer.close();
> } catch (IllegalStateException e) {
> try {
> ServletOutputStream stream = 
> response.getOutputStream();
> stream.close();
> } catch (IllegalStateException f) {
> ;
> } catch (IOException f) {
> ;
> }
> } catch (IOException e) {
> ;
> }
> }
> 
> In the above code sample, response will be an instance of
> ResponseFacade, meaning it will be suspended instead of being flushed
> and closed right away.
> 
> Does anyone remember why the "response instanceof ResponseFacade"
> check is there? I would have expected the "else" case to always be
> executed.
> 

Without ever actually having looked at ResponseFacade, I'd always assumed
that ResponseFacade.finish called Response.finishResponse.  And I would have
been wrong ;-).  This would have done the commit/send/close properly.

I don't have time right now to dig through the SVN logs to see why it's this
way, but suspended doesn't really look good enough to satisfy the spec.

> Any hints appreciated.
> 
> Thanks,
> 
> 
> Jan
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 



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]

Re: Response not flushed before RD.forward() returns

2006-01-19 Thread Jan Luehe 


Bill Barker wrote On 01/19/06 18:11,:
>  
> 
> 
>>-Original Message-
>>From: Jan Luehe [mailto:[EMAIL PROTECTED] 
>>Sent: Thursday, January 19, 2006 5:57 PM
>>To: tomcat-dev@jakarta.apache.org
>>Subject: Response not flushed before RD.forward() returns
>>
>>Consider the following code snippet of a servlet's service() method:
>>
>>  public class DispatcherServlet extends HttpServlet {
>>
>>public void service(HttpServletRequest req, 
>>HttpServletResponse res)
>>throws IOException, ServletException {
>>
>>  
>>request.getRequestDispatcher("/target").forward(request, response);
>>
>>  try {
>>  Thread.currentThread().sleep(6);
>>  } catch (Exception ex) { }
>>}
>>
>>where "target" prints some output to the response.
>>
>>The code currently returns the output printed by "target" only after
>>DispatcherServlet's service() method has finished, instead of right
>>before RD.forward() returns.
>>
>>This seems to be in violation of the Servlet Spec, which has this:
>>
>>SRV.8.4 ("The Forward Method"):
>>
>>  Before the forward() method of the RequestDispatcher interface
>>  returns, the response content must be sent and committed, and closed
>>  by the servlet container.
>>
>>The code at the end of o.a.c.core.ApplicationDispatcher.doForward()
>>looks like this:
>>
>>// This is not a real close in order to support error 
>>processing
>>if ( log.isDebugEnabled() )
>>log.debug(" Disabling the response for futher output");
>>
>>if  (response instanceof ResponseFacade) {
>>((ResponseFacade) response).finish();
>>} else {
>>// Servlet SRV.6.2.2. The Resquest/Response may have been
>>wrapped
>>// and may no longer be instance of RequestFacade
>>if (log.isDebugEnabled()){
>>log.debug( " The Response is vehiculed using 
>>a wrapper: "
>>   + response.getClass().getName() );
>>}
>>
>>// Close anyway
>>try {
>>PrintWriter writer = response.getWriter();
>>writer.close();
>>} catch (IllegalStateException e) {
>>try {
>>ServletOutputStream stream = 
>>response.getOutputStream();
>>stream.close();
>>} catch (IllegalStateException f) {
>>;
>>} catch (IOException f) {
>>;
>>}
>>} catch (IOException e) {
>>;
>>}
>>}
>>
>>In the above code sample, response will be an instance of
>>ResponseFacade, meaning it will be suspended instead of being flushed
>>and closed right away.
>>
>>Does anyone remember why the "response instanceof ResponseFacade"
>>check is there? I would have expected the "else" case to always be
>>executed.
>>
> 
> 
> Without ever actually having looked at ResponseFacade, I'd always assumed
> that ResponseFacade.finish called Response.finishResponse.  And I would have
> been wrong ;-).  This would have done the commit/send/close properly.
> 
> I don't have time right now to dig through the SVN logs to see why it's this
> way, but suspended doesn't really look good enough to satisfy the spec.

Yes. I'm afraid it's been like this forever.

Does anybody see any problems with removing the
"response instanceof ResponseFacade" check at the end of RD.doForward(),
and unconditionally executing the code in the "else" block, which
commits and closes the response, as requested by the servlet spec?


Jan



> 
>>Any hints appreciated.
>>
>>Thanks,
>>
>>
>>Jan
>>
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
> 
> 
> 
> 
> 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 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=7831





--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 07:36 ---
> I am minded, however, to use your
> patch as a basis for an implementation of getPrincipal() rather than 
> over-riding
> authenticate(X509Certificate).
Sorry, I dont know what you mean.
I use "authenticate(X509Certificate)", whats bad with it? Thats the place where
authentication should occur, no?
But I dont know the latest codebase, so it will be that some stuff has been 
changed.


> In terms of suporting muliple LDAP servers my intention is to provide 
> something
> that works for OpenLDAP and can be over-ridden as required for other 
> directories.
Something which my patch tries to address to.
There are implementations for ActiveDirectory and OpenExchange (I guess this is
OpenLDAP)

> 1. I moved the classes into the o.a.c.Realm package.
> 2. Please keep to the coding standards of the original when copying source. It
> makes it much easier to find where you have made any subtle changes.
Yes. Sorry for this.

> 3. CertUser looks to be unnecessary - why not use User from JNDIRealm?
I need CertUser to be able to hold both, the username and the dn of the ldap 
entry.
Internally it works with the "dn" but as username it will use what ever the user
configured to use.
I dont wanted to pass the rather large dn (and meaningless from the point of the
application) back to the application.

> 4. Your changes to authenticate(String, String) appear to be unrelated to 
> adding
> support for certificates. Please keep patches for different issues separate so
> they can be considered separately. Feel free to file a new bug for this one.
As you might have seen I started coding mid 2003, so I cant remember what I
changed here, though, the best would be to make it possible to extend JNDIRealm
and change only what needed to handle the certificate stuff.
For some reason I cant rembemer this was not possible.

> 5. You appear to have reverted the patches for bugs 23190, 16541 and 26487. 
> What
> is the reason for this?
> 6. The patch for bug 22236 has also been reverted. Is this intentional?
As I said, I started mid 2003, the last addition in 2005 is based on this rather
old version - none of those bugs were there when I started.

> 7. If there a reason that getCertUserByPattern() isn't supported?
I cant remember.

> 8. A change commiited at the same time as bug 22236 to
> addAttributeValues(String, Attributes, ArrayList) that modified the return 
> value
> from null to values in a couple of places has also been reverted. Why?
See 5 & 6.


All in all I waited all the time to find a tomcat committer which will start
looking at it and point me to the right direction.
My "patch" was meant to be a discussion base and hopefully not that bad so we
can have a cleaned wersion sometimes in the codebase.

Now, it looks like there is one :-)

I can update the patch to the tomcat 5.5.x codebase if wanted.
E.g. starting to refactor JNDIRealm so that in JNDIRealmCertBase only the
certificate relevant stuff is included.
That way I wont mask the other patches.
It just I am so out of time, so I'll do this only when I know that you pick it 
up.

Ciao,
Mario

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 35853] - Make JkMount compatible with servlet-mapping/url-pattern in web.xml

2006-01-19 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=35853


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME




--- Additional Comments From [EMAIL PROTECTED]  2006-01-20 08:56 ---
Use:

JkMount /app1/MyServlet1|/* MyWorker
as a convinience method for matching both
/app1/MyServlet1
and
/app1/MyServlet1/*


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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