DO NOT REPLY [Bug 41538] Unable to run Tomcat as a Windows service under JDK 1.6

2008-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=41538





--- Comment #24 from Ingolf Magnus <[EMAIL PROTECTED]>  2008-04-21 02:21:55 PST 
---

It may be that the run-time error occurs in the commons-daemon codebase.

But the bug is in the Tomcat installer, not in the installed code.

According to OS (Windows) policy, each application requiring msvcrt71.dll
should bring its own copy (see comment above), independently of other
applications (e.g. the JDK).

If the Tomcat installer is written by the Tomcat team, this bug should not be
RESOLVED:INVALID. I do not see how the commons-daemon team could fix Tomcat's
problem here.

--Ingolf Magnus


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

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



DO NOT REPLY [Bug 41538] Unable to run Tomcat as a Windows service under JDK 1.6

2008-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=41538





--- Comment #25 from Mark Thomas <[EMAIL PROTECTED]>  2008-04-21 03:13:36 PST 
---
Based on the analysis so far, the issue appears to be related to how daemon
loads jvm.dll. This makes is a daemon issue not a Tomcat one.


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

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



DO NOT REPLY [Bug 43634] PKCS12 keystoreType is not taken into account on Http11NioProtocol

2008-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=43634


Mark Thomas <[EMAIL PROTECTED]> changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #2 from Mark Thomas <[EMAIL PROTECTED]>  2008-04-21 10:10:11 PST ---
The patch for this was applied back in October 2007. It is included in 6.0.16
onwards.


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

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



DO NOT REPLY [Bug 41538] Unable to run Tomcat as a Windows service under JDK 1.6

2008-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=41538





--- Comment #26 from Mark Thomas <[EMAIL PROTECTED]>  2008-04-21 14:05:01 PST 
---
To be clear it is jvm.dll that requires mscvr71.dll. This is a JVM component.
It is neither a Tomcat nor a daemon component.

Looking a bit further it appears to be a JVM issue, but one that Sun don't view
as an issue. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6509291

There is a nice summary here:
http://www.duckware.com/tech/java6msvcr71.html

The fix at the end looks like an approach that would work in daemon.


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

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



Re: JNDIRealm

2008-04-21 Thread Henri Gomez
Did someone as a example LDAP configuration against AD available
against standard JNDIRealm  ?

Regards.

2008/4/14, Seth Leger <[EMAIL PROTECTED]>:
> When working on this, I would appreciate if bug 44645 could also be
> resolved. It's a fairly trivial patch.
>
>  https://issues.apache.org/bugzilla/show_bug.cgi?id=44645
>
>  I also have additional fixes for JNDIRealm that address problems in
> connecting to Active Directory. The biggest issue is that during the
> authenticate() call, an LDAP search is performed. The current implementation
> uses the bind DN/bind password to perform the search or null credentials (if
> the bind DN/bind password is not provided). However, it should also use the
> credentials being supplied to the authenticate() call; adding code to do
> this resolves a giant hurdle in getting AD authentication to work properly
> with most Active Directory setups.
>
>  There is also a lifecycle bug in the JNDIRealm that causes authentication
> problems if stop() -> start() calls are issued against it.
>
>  I was waiting to open bugs and supply patches for these additional issues
> until bug 44645 was resolved (since that would give me a new base for
> patching). Bug 44645 is a much more severe issue since it affects all LDAP
> servers that use invalid or expired SSL certificates. I'll paste the
> description I gave in the bug in case anyone sees this message via search
> engines:
>
>  "This [bug 44645 patch] is necessary so that you can perform customized SSL
> negotiation on the connection. For instance, it allows you to connect to an
> SSL server with an invalid, expired, self-signed, or otherwise untrusted
> certificate. To do this, you just need to write a
> javax.net.ssl.SSLSocketFactory that does not perform the normal certificate
> validation during the SSL handshake and then specify the classname on the
> new setSocketFactory() call added by this patch."
>
>  Seth Leger
>  Sr. Software Engineer
>  Raritan, Inc.
>
>
>  [EMAIL PROTECTED] wrote:
>
> > Brandon DuRette schrieb:
> >
> >
> > > While trying to track down an issue with logins taking a very long time,
> I
> > > just discovered in the 5.5.26 source code/Javadoc for JNDIRealm
> (likewise in
> > > the 6.0 documentation) that there's a big bold TODO to support
> connection
> > > pooling in the JNDIRealm.  I think this may be part of the login problem
> I'm
> > > seeing.
> > >
> > > Looking over the current source code, I can see that it's going to
> require a
> > > fairly extensive refactoring of the JNDIRealm code.  I'm willing to take
> a
> > > shot at fixing it, but wanted to first check with the list on a couple
> of
> > > 
> > > Thanks in advance for any pointers.
> > >
> > > Regards,
> > > Brandon
> > >
> > >
> >
> > Dear Brandon,
> >
> > re-doing JNDIRealm seems to me very necesary, but for an other
> > reason as yours, mentioned above.
> >
> > As I said in my mail (27 Feb 2008 to bug 42579) JNDIRealm is hardly
> > useable with (Windows Server 2003) Active Directory Domains  --
> > except for very small / trivial cases.
> >
> > After a long history of frustrations, I solved all the
> > Tomcat+AD-issues by an own ADweRealms. Experiences are, so far,
> > 100% good (with Apache Tomcat/6.0.16 on JDK1.6.0_05 and before
> > also with 5.5.x od 1.5.0_y). I offered the solution, already, in
> > mentioned mail. (got nil reactions)
> >
> > Perhaps, you could make your newly designed JNDIRealm realy fit for
> > Active Directory. It would be warmly welcomed by all who tried to
> > use / would have liked to use (but, as I know from some, gave up)
> > Tomcat with AD.
> >
> > Good luck
> >Albrecht
> >
> > --
> >
> > PS.: For your convinience follows part of mentioned mail, in the
> > hope of giving some pointers, you asked for in your mail.
> >
> > --- Comment #2 from
> > Dr. Albrecht Weinert <[EMAIL PROTECTED]>
> > 2008-02-27 22:48:41 ---
> > By the way of JNDI/Tomcat + Active Directory:
> >
> > JNDIRealm is/was never quite happy with Active
> > Directory for a variety of reasons. After a bunch
> > of frustrations (of which the lying isUserInGruop()
> > was one of the worst), some time ago, I decided to
> > write a new Realm class, which I may contribute.
> >
> >
> http://www.a-weinert.de/java/docs/aWeinertBib/de/a_weinert/realm/ADweRealm.html
> >
> > ADweRealm searches only one way (performance!) from the
> > (authenticated) user to his groups. It follows
> > the quite important group-in-group relations (to
> > any depth), and so on.
> >
> > Experiences in a Windows Server 2003 domain (3000+ user
> > accounts, hundreds of groups etc.) are quite encouraging.
> > None of the Tomcat + Active Directory problems, which
> > Google is full of, arised any more.
> >
> >
> >
>
> -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To uns

DO NOT REPLY [Bug 44850] New: response.flushbuffer() doesn' t flush the data to the output

2008-04-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=44850

   Summary: response.flushbuffer() doesn't flush the data to the
output
   Product: Tomcat 6
   Version: 6.0.14
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In servlet, response.flushbuffer() would just flush all the data which we have
writen to the response.getOutputstream before to the client side. However,
tomcat6.0.14 would just keep it under either close of connection from the
server side or 8k buffer limit reached. That bug would limit the capability for
us to do the streaming.


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

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