DO NOT REPLY [Bug 45852] New: conf/tomcat-users.xml has invalid encoding "cp932".
https://issues.apache.org/bugzilla/show_bug.cgi?id=45852 Summary: conf/tomcat-users.xml has invalid encoding "cp932". Product: Tomcat 6 Version: 6.0.18 Platform: PC OS/Version: Windows Vista Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tomcat failed to startup because of it. -- 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: Default Role in Realms
Rainer Jung schrieb: I added an optional configurable default role to the JNDIRealm. That's useful, if you only want to authenticate the users (password check). http://svn.apache.org/viewvc?rev=697213&view=rev I could as well add it to most of the other Realms, but I'm wondering, if it would make more sense to introduce an additional getRoles to RealmBase, which returns the default role if configured and can be included in the getRoles already present in most of the Realm implementations. Thoughts? Regards, Rainer Im my opinion a most useful feature, as itreally is in ADweRealm (see http://a-weinert.de/java/docs/aWeinertBib/de/a_weinert/realm/ADweRealm.html ) for Active Directory. Active Directory (AD) lists certain default group memberships not explicitely. So an user account, who is just "Domänen-Benutzer", would get authentication but no roles and hence no Tomcat rights w/o such a default role feature. But I'm not sure if a change to the base class (RealmBase) is much help. To use ADweRealm again as an example, it implements a primitive way of Realm Chaining (badly needed with AD and missed in Tomcat). Here the default role signals which Realm the user got her authentication from. Under this aspect a base class implementation of the default role feature would only make sense if the Realm Chaining feature would be implemented there as well. Best regards Albrecht - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Role in Realms
A. Weinert schrieb: > Rainer Jung schrieb: >> I added an optional configurable default role to the JNDIRealm. >> That's useful, if you only want to authenticate the users (password >> check). >> >>http://svn.apache.org/viewvc?rev=697213&view=rev >> >> I could as well add it to most of the other Realms, but I'm wondering, >> if it would make more sense to introduce an additional getRoles to >> RealmBase, which returns the default role if configured and can be >> included in the getRoles already present in most of the Realm >> implementations. >> >> Thoughts? >> >> Regards, >> >> Rainer > > Im my opinion a most useful feature, > as itreally is in ADweRealm (see > http://a-weinert.de/java/docs/aWeinertBib/de/a_weinert/realm/ADweRealm.html > ) for Active Directory. > > Active Directory (AD) lists certain default group memberships not > explicitely. So an user account, who is just "Domänen-Benutzer", > would get authentication but no roles and hence no Tomcat > rights w/o such a default role feature. > > But I'm not sure if a change to the base class (RealmBase) is much help. > To use ADweRealm again as an example, it implements a primitive way > of Realm Chaining (badly needed with AD and missed in Tomcat). Here the > default role signals which Realm the user got her authentication from. > Under this aspect a base class implementation of the default role > feature would only make sense if the Realm Chaining feature would be > implemented there as well. I'll have a look, as it's already ASL 2 licensed. I also have recursive role searches in the queue (not committed yet) and Mark recently added a CombinedRealm to trunk. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Role in Realms
Rainer Jung schrieb: >> Im my opinion a most useful feature, >> as itreally is in ADweRealm (see >> http://a-weinert.de/java/docs/aWeinertBib/de/a_weinert/realm/ADweRealm.html >> ) for Active Directory. > I'll have a look, as it's already ASL 2 licensed. Speaking to fast. That was only the original License note carried over form the JNDIRealm. Do you have plans to contribute ADweRealm? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Role in Realms
Rainer Jung wrote: > I added an optional configurable default role to the JNDIRealm. > That's useful, if you only want to authenticate the users (password check). > >http://svn.apache.org/viewvc?rev=697213&view=rev > > I could as well add it to most of the other Realms, but I'm wondering, > if it would make more sense to introduce an additional getRoles to > RealmBase, which returns the default role if configured and can be > included in the getRoles already present in most of the Realm > implementations. > > Thoughts? I think it is just as useful for other realms so I would go ahead with adding getRoles() to RealmBase in some form. Maybe add getDefaultRole() to RealmBase and then call that from the other Realms? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r697366 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
Author: mturk
Date: Sat Sep 20 07:19:35 2008
New Revision: 697366
URL: http://svn.apache.org/viewvc?rev=697366&view=rev
Log:
Do not allow --enable-prefork modules to run on threaded servers
Modified:
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=697366&r1=697365&r2=697366&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Sat Sep 20 07:19:35
2008
@@ -2887,6 +2887,30 @@
if (ap_mpm_query(AP_MPMQ_MAX_THREADS, &mpm_threads) != APR_SUCCESS)
mpm_threads = 1;
}
+if (mpm_threads > 1) {
+#if _MT_CODE
+/* _MT_CODE */
+if (JK_IS_DEBUG_LEVEL(conf->log)) {
+#if !defined(WIN32) && !defined(NETWARE)
+#if USE_FLOCK_LK
+jk_log(conf->log, JK_LOG_DEBUG,
+ "Using flock() for locking.");
+#else
+jk_log(conf->log, JK_LOG_DEBUG,
+ "Using fcntl() for locking.");
+#endif /* USE_FLOCK_LK */
+#else /* WIN32 */
+jk_log(conf->log, JK_LOG_DEBUG,
+ "Not using locking.");
+#endif
+}
+#else
+/* !_MT_CODE */
+ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s,
+ "Cannot run prefork mod_jk on threaded server.");
+return JK_FALSE;
+#endif
+}
if (JK_IS_DEBUG_LEVEL(conf->log))
jk_log(conf->log, JK_LOG_DEBUG,
"Setting default connection pool max size to %d",
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question about org.apache.coyote.Request
Hi again, I continued doing further research on Tomcat and I feel as if Tomcat is not able to support custom developed Protocol Handlers without changing also some code in the Catalina package as well! I opened the CoyoteAdapter in the Catalina package and here it seems that the service() method takes it for granted that any in coming request is of type Http (since the Request object used in this class extends HttpRequest). This means that if I want to develop a connector for Tomcat completly http independent then I will also have to develop my own CoyoteAdapter and somehow tell Tomcat to use this one! Right? (I accept the fact that i could possible be talking rubish. If so please do tell me - at least I would learn something). I also cannot understand another thing. If in theory the Http11Protocol class is responsable to handle any http request, then why doesn't this create a Request object of type HttpRequest at that level; rather then let the CoyoteAdapter in the Catalina package do that? (At the moment it seems that the Http11Protocol will create a Request object (which is very similar to the actual HttpRequest) which is then send to the Adapter, which in turn creates an HttpRequest). Thanks & Regards, Simon J. > From: [EMAIL PROTECTED] > To: dev@tomcat.apache.org > Subject: Question about org.apache.coyote.Request > Date: Fri, 19 Sep 2008 14:13:31 +0200 > > Hi, > > I am new in the Tomcat world. However these last few months I tried to > understand a little better how tomcat works concentrating mostly on the > Connectors (Protocol Handlers) aspect. I now found something which is > confusing me a little and I hope someone here can explain to me how this > works out. > > When I downloaded the source code and opened org.apache.coyote.Request I > found out that this does not inherit from javax.servlet.ServletRequest, nor > to any other class. This is confusing me! > > When a request and response objects are constructed, the processor will call > the Adapter.process() method which takes the request > (org.apache.coyote.Request) and response (org.apache.coyote.Response) objects > as parameters. At the end of the line a servlet service() method is called. > However how is this possible if the service() method of the servlet object > can only recieve a request and response objects of type ServletRequest and > ServletResponse respectivly!? > > Does tomcat internally have some mapping functionality to change a > Request/Response object of type org.apache.coyote.Request/Response to type > javax.servlet.ServletRequest/ServletResponse? > > Sorry if the question may sound stupid. I am not what you call an expert > programmer but have spent lots of time to understand how Tomcat works. My > final aim is to actually develop my own connector (as I said on the users > list). > > btw - I posted this on this mailing list since I am actually extending Tomcat > funtionality then just using it. So I tought this was a better place to ask > this. > > Thanks & Regards, > Simon J. > > _ > Discover the new Windows Vista > http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
RE: Question about org.apache.coyote.Request
Hi, I think I am posting in the wrong mailing list. I posted my question here because I felt it was "Apache Tomcat source code" related. However I feel that this mailing list is only for the developers who actually change the Apache Tomcat source code for the next release. I am sorry for any the inconvenience. Regards, Simon J. From: [EMAIL PROTECTED] To: dev@tomcat.apache.org Subject: RE: Question about org.apache.coyote.Request Date: Sat, 20 Sep 2008 19:41:04 +0200 Hi again, I continued doing further research on Tomcat and I feel as if Tomcat is not able to support custom developed Protocol Handlers without changing also some code in the Catalina package as well! I opened the CoyoteAdapter in the Catalina package and here it seems that the service() method takes it for granted that any in coming request is of type Http (since the Request object used in this class extends HttpRequest). This means that if I want to develop a connector for Tomcat completly http independent then I will also have to develop my own CoyoteAdapter and somehow tell Tomcat to use this one! Right? (I accept the fact that i could possible be talking rubish. If so please do tell me - at least I would learn something). I also cannot understand another thing. If in theory the Http11Protocol class is responsable to handle any http request, then why doesn't this create a Request object of type HttpRequest at that level; rather then let the CoyoteAdapter in the Catalina package do that? (At the moment it seems that the Http11Protocol will create a Request object (which is very similar to the actual HttpRequest) which is then send to the Adapter, which in turn creates an HttpRequest). Thanks & Regards, Simon J. > From: [EMAIL PROTECTED] > To: dev@tomcat.apache.org > Subject: Question about org.apache.coyote.Request > Date: Fri, 19 Sep 2008 14:13:31 +0200 > > Hi, > > I am new in the Tomcat world. However these last few months I tried to > understand a little better how tomcat works concentrating mostly on the > Connectors (Protocol Handlers) aspect. I now found something which is > confusing me a little and I hope someone here can explain to me how this > works out. > > When I downloaded the source code and opened org.apache.coyote.Request I > found out that this does not inherit from javax.servlet.ServletRequest, nor > to any other class. This is confusing me! > > When a request and response objects are constructed, the processor will call > the Adapter.process() method which takes the request > (org.apache.coyote.Request) and response (org.apache.coyote.Response) objects > as parameters. At the end of the line a servlet service() method is called. > However how is this possible if the service() method of the servlet object > can only recieve a request and response objects of type ServletRequest and > ServletResponse respectivly!? > > Does tomcat internally have some mapping functionality to change a > Request/Response object of type org.apache.coyote.Request/Response to type > javax.servlet.ServletRequest/ServletResponse? > > Sorry if the question may sound stupid. I am not what you call an expert > programmer but have spent lots of time to understand how Tomcat works. My > final aim is to actually develop my own connector (as I said on the users > list). > > btw - I posted this on this mailing list since I am actually extending Tomcat > funtionality then just using it. So I tought this was a better place to ask > this. > > Thanks & Regards, > Simon J. > > _ > Discover the new Windows Vista > http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE Discover the new Windows Vista Learn more! _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx
Re: Default Role in Realms
Mark Thomas wrote: Rainer Jung wrote: I added an optional configurable default role to the JNDIRealm. That's useful, if you only want to authenticate the users (password check). http://svn.apache.org/viewvc?rev=697213&view=rev I could as well add it to most of the other Realms, but I'm wondering, if it would make more sense to introduce an additional getRoles to RealmBase, which returns the default role if configured and can be included in the getRoles already present in most of the Realm implementations. Thoughts? I think it is just as useful for other realms so I would go ahead with adding getRoles() to RealmBase in some form. Maybe add getDefaultRole() to RealmBase and then call that from the other Realms? +1 Mark - 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 45851] FarmWarDeployer fails to properly unpack copied war on target node
https://issues.apache.org/bugzilla/show_bug.cgi?id=45851 Paul McGurn <[EMAIL PROTECTED]> changed: What|Removed |Added CC|[EMAIL PROTECTED] | -- 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]
svn commit: r697447 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
Author: mturk Date: Sat Sep 20 23:50:57 2008 New Revision: 697447 URL: http://svn.apache.org/viewvc?rev=697447&view=rev Log: Log socket number before we set it to -1 Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?rev=697447&r1=697446&r2=697447&view=diff == --- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original) +++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Sat Sep 20 23:50:57 2008 @@ -1039,7 +1039,8 @@ } ae->last_errno = errno; jk_log(l, JK_LOG_INFO, - "sendfull returned %d (errno=%d)", rc, ae->last_errno); + "sendfull for socket %d returned %d (errno=%d)", + ae->sd, rc, ae->last_errno); ae->sd = JK_INVALID_SOCKET; JK_TRACE_EXIT(l); @@ -1398,11 +1399,11 @@ if (rc == JK_FATAL_ERROR) op->recoverable = JK_FALSE; jk_log(l, JK_LOG_INFO, - "(%s) failed sending request (%srecoverable), " - "socket %d (errno=%d)", + "(%s) failed sending request (%srecoverable) " + "(errno=%d)", ae->worker->name, op->recoverable ? "" : "un", -ae->sd, ae->last_errno); +ae->last_errno); JK_TRACE_EXIT(l); return JK_FATAL_ERROR; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
