Re: Tomcat 4.x auth issue
Bill Barker wrote: I'm hardly a 4.x expert, but this looks like it will solve the major problem. This fix will still send an Auth to /myapp if you first request /myapp/protected, but that shouldn't be too much of a problem. In 5.0, I think that the spec is going to eventually require that we move the logic to the Mapper however. Which BTW is not implementable in the general case; if you allow only physical resources, it should be possible, though. (at least, if you find a way which works, let me know) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
mturk 2002/07/04 00:23:55
Modified:jk/native2/server/isapi jk_isapi_plugin.c
Log:
Set the starter thread extisting through entire extension life cycle.
The starter thread at init sleeps for 1 s, causing not blocking of
the main IIS thread that calls LoadLibrary for our extension.
Revision ChangesPath
1.32 +26 -6
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- jk_isapi_plugin.c 1 Jul 2002 16:53:55 - 1.31
+++ jk_isapi_plugin.c 4 Jul 2002 07:23:55 - 1.32
@@ -520,8 +520,13 @@
return TerminateFilter(dwFlags);
}
+HANDLE jk2_starter_event;
+
BOOL WINAPI TerminateFilter(DWORD dwFlags)
{
+/* detatch the starter thread */
+SetEvent(jk2_starter_event);
+
if (is_inited) {
is_inited = JK_FALSE;
if (workerEnv) {
@@ -540,11 +545,14 @@
DWORD WINAPI jk2_isapi_starter( LPVOID lpParam )
{
+Sleep(1000);
+
initialize_extension();
if (is_inited) {
if (init_jk(NULL))
is_mapread = JK_TRUE;
}
+WaitForSingleObject(jk2_starter_event, INFINITE);
return 0;
}
@@ -558,21 +566,33 @@
char dir[_MAX_DIR];
char fname[_MAX_FNAME];
DWORD dwThreadId;
+DWORD dwRes;
+int tcount = 0;
switch (ulReason) {
case DLL_PROCESS_DETACH:
-__try {
-if (jk2_starter_thread)
-CloseHandle(jk2_starter_thread);
-TerminateFilter(HSE_TERM_MUST_UNLOAD);
-} __except(1) {
+while (!GetExitCodeThread(jk2_starter_thread, dwRes)) {
+if (dwRes == STILL_ACTIVE) {
+++tcount;
+if (tcount 30) {
+TerminateThread(jk2_starter_thread, -1);
+break;
+}
+Sleep(100);
+}
}
+CloseHandle(jk2_starter_thread);
break;
case DLL_PROCESS_ATTACH:
if (GetModuleFileName( hInst, file_name, sizeof(file_name))) {
_splitpath( file_name, drive, dir, fname, NULL );
_makepath( ini_file_name, drive, dir, fname, .properties );
+
+jk2_starter_event = CreateEvent(NULL,
+FALSE,
+FALSE,
+NULL);
jk2_starter_thread = CreateThread( NULL,
0,
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
problem with xalan
Hello, I have a problem with xalan. I want to generate a .html file. I have a xml and xsl files, foo.xml and foo.xsl (these are from the examples of xalan). When I execute the jsp file, one error is produced, the error is that the namespace is not valid (more or less) Anything can help me! Thanks _ MSN. Más Útil cada Día. http://www.msn.es/intmap/ ?xml version=1.0? docHello/doc ?xml version=1.0? xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:param name=param1 select='default value'/ xsl:template match=doc html headtitleStylesheet parameter/title/head body h2XML source/h2 pxsl:value-of select=.//p h2Stylesheet parameter/h2 pThe param1 stylesheet parameter has been set to xsl:value-of select=$param1/./p /body /html /xsl:template /xsl:stylesheet jspSample.jsp Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10469] New: - URLs of resources from application archives contain spaces
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10469. 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=10469 URLs of resources from application archives contain spaces Summary: URLs of resources from application archives contain spaces Product: Tomcat 4 Version: 4.0.4 Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If Tomcat is installed in a directory with spaces, then the following code breaks because application class loader will put spaces in the resource URL: URL url=Test.class.getResource(res/resource.gif); String useURI=url.toString(); URI uri=new URI(useURI); For example, if installed under c:\temp\s p a c e s\catalina, Tomcat will generate following URL: jar:file:C:/Temp/s p a c e r/catalina/webapps/kaonportal/WEB- INF/lib/apionrdf.jar!/test/res/resource.gif The same code when executed from Java alone in the same directory will give following URL: jar:file:/C:/Temp/s%20p%20a%20c%20e%20r/test.jar!/test/res/resource.gif In the latter case the spaces are correctly escaped with %20, whereas in the case of running under Tomcat, the spaces are present in the URL, which is incorrect according to the URL standard. The URL class doesn't check this, but the URI class does, and the code breaks. Boris Motik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: mod_jk2
Fyi... Not acked... -- Forwarded Message From: Mark Howell [EMAIL PROTECTED] Date: Thu, 4 Jul 2002 02:51:24 -0500 (CDT) To: [EMAIL PROTECTED] Subject: mod_jk2 Hello, The past two days, I have attempted to download mod_jk2 from http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/ and every time that I checked, the server suggested an empty directory structure. There is, under the nightly builds directory, mod_jk2 dll's for M$, but I'm looking for the Apache mod_jk2. Giving up on mod_jk2, I proceeded to try to get mod_jk instead, but found: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1 /bin/linux/i386/ to be empty as well. So...then I figured I would just build it from source, but: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1 /src/ was empty as well. TIA, Mark [EMAIL PROTECTED] -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jetty and mod_jk2
The Jetty folks have been working hard on improving the connectivity between apache and jetty and so from 4.1.D2 Jetty has shipped with its own AJP13 Listener. According to Greg Wilkins, the currently shipped version has problems with authenticated and SSL connections, but these are solved in the latest CVS version. Attached is a HOWTO on getting Jetty and Apache 2 talking via mod_jk2. Can I please get some feedback on this? And what do people think about this (or something similar) being included in the next release of the jtc? Regards, Simon -- I like to fill my tub up with water, then turn the shower on and act like I'm in a submarine that's been hit ... Steven Wright Using mod_jk2 and Jetty === Jetty is a popular Open Source HTTP Server and Servlet container, written in 100% pure Java. It supports serving static content, servlets and JSPs, and is fast and lightweight. It is commonly used as an embedded HTTP and servlet container, notably by JBoss (a full featured J2EE environment) Jetty's current developement branch is 4.1. This is working to enhance the performance of the server, as well as to improve its support for apache integration. To further this support, since 4.1.D2 Jetty has shipped with an AJP13 connector, meaning that it can communicate using the mod_jk and mod_jk2 apache modules in addition to working as a standalone server. This document aims to provide a guide for using this facility. Normal, authenticated and SSL connections are all supported, so in theory, Jetty could be used as a drop in replacement for Tomcat. In order to keep things as simple as possible, this document only considers apache2 and mod_jk2. This is the successor to mod_jk, and uses the same protocol, so using the older module should not cause any problems. The process will be very similar to installing jk2 on any server, so if you are using IIS or iPlanet, simply follow the normal installation notes for jk2 on those platforms, ignoring any references to compiling the java code. Once the native side of the AJP13 connector is installed, skip to the section on Configuring Jetty Building * Install apache, ensuring that DSO support is available. * Install any version of Jetty from 4.1.D2 onwards. * Copy build.properties.sample to build.properties * Edit build.properties to taste. In particular it's important to set the path to apache2. * Run ant native to build the native connectors for the detected servers (both jk and jk2) It is possible to use configure/make/dsp/apxs, but this way is simpler. * Copy the created build/apache2/mod_jk2.so to your apache installation's module directory. Configuring Apache 2 On the native side, jk2 is configured using the workers2.properties file that is kept in apache's conf directory. Currently Jetty's AJP connector supports TCP/IP socket connections. Perhaps the simplest way to explain things is with an example workers2.properties file: workers2.properties # Example socket channel, override port and host. [channel.socket:localhost:8009] port=8009 host=127.0.0.1 # define the worker [ajp13:localhost:8009] channel=channel.socket:localhost:8009 # Uri mapping. This says that any incoming connection to any file # under /jetty/ should be handled the worker defined above [uri:/jetty/*] worker=ajp13:localhost:8009 # The same, but for /demo [uri:/demo/*] worker=ajp13:localhost:8009 end worker2.properties An apachectl configtest should report no errors. You should configure the URI mappings to cover any installed webapps that you may have. The examples given here are for the demo apps that come with a fresh download of Jetty. Configuring Jetty = Jetty is easy to configure. At a bare minimum, all that needs to be done is to simply include the following fragment in Jetty's configuration file (typically found at etc/jetty.xml): Call name=addListener Arg New class=org.mortbay.http.ajp.AJP13Listener Set name=port8009/Set /New /Arg /Call Once this is place, it should be possible to start Jetty and then (re)start apache. Check that everything works as expected by visiting port 8080 of your server with a web browser. If doesn't work then you have a problem with your Jetty config. Assuming that you can connect properly to Jetty directly, it's time to connect using jk2. Check that your webserver is running as expected by pointing a browser at the homepage (for example, http://localhost/ ) If this works, attempt to visit one of the mapped URIs. Congratulations! Jetty Config Options The Jetty AJP13 connector has a compact set of configuration options. These are: Jetty config options bufferSize Size of the AJP13 data buffers (default 8192) confidentialPortThe port to redirect to if a servlet security constraint of CONFIDENTIAL is not met. (default 0 : forbidden response). confidentialScheme The scheme to
Re: Jetty and mod_jk2
Simon Stewart wrote: The Jetty folks have been working hard on improving the connectivity between apache and jetty and so from 4.1.D2 Jetty has shipped with its own AJP13 Listener. According to Greg Wilkins, the currently shipped version has problems with authenticated and SSL connections, but these are solved in the latest CVS version. Attached is a HOWTO on getting Jetty and Apache 2 talking via mod_jk2. Can I please get some feedback on this? And what do people think about this (or something similar) being included in the next release of the jtc? -1. - Jetty users who are interested in AJP should be able to find the readme in the Jetty docs. - It would also give the impression that we're somehow officially supporting Jetty in JK 2 or Coyote (we obviously don't), and people would bug us with Jetty questions/problems. - We also have no buisness advocating Tomcat alternatives. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
CVS problem
Trying to tag the CVS with 4.1.7 ... cvs server: [03:59:27] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets cvs server: [04:00:00] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets Dan, can you fix it ASAP ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10060] - Make the common and shared class loaders look in catalina.base
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10060. 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=10060 Make the common and shared class loaders look in catalina.base --- Additional Comments From [EMAIL PROTECTED] 2002-07-04 11:19 --- Apparently this patch makes some trouble for uPortal. I've made another patch, but I'll leave it running and see if it does too before I send it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jetty and mod_jk2
On Thu, Jul 04, 2002 at 03:57:37AM -0700, Remy Maucherat wrote: Simon Stewart wrote: The Jetty folks have been working hard on improving the connectivity between apache and jetty and so from 4.1.D2 Jetty has shipped with its own AJP13 Listener. According to Greg Wilkins, the currently shipped version has problems with authenticated and SSL connections, but these are solved in the latest CVS version. Attached is a HOWTO on getting Jetty and Apache 2 talking via mod_jk2. Can I please get some feedback on this? And what do people think about this (or something similar) being included in the next release of the jtc? -1. - Jetty users who are interested in AJP should be able to find the readme in the Jetty docs. It's been posted to the Jetty developers too. - It would also give the impression that we're somehow officially supporting Jetty in JK 2 or Coyote (we obviously don't), and people would bug us with Jetty questions/problems. A simple these aren't the answers you're looking for would suffice. If that's too much bother, then putting a warning at the top of the README stating that the correct place to go for help may be the jetty mailing lists could be added. There's also an outside chance that the issue the Jetty user has found _could_ be a problem with the native side of the adapter - We also have no buisness advocating Tomcat alternatives. It really does depend on how you're looking at it. While I can see your point of view, I believe that your last point is specious. Consider the facts: 1) Tomcat is an Open Source product. It has no imperative to grab market share. 2) Open Source products thrive on collaboration and competition. 3) The AJP13 protocol, which mod_jk speaks, is openly documented. Tomcat has a java-side implementation of it. So does Jetty. The native side is common between both platforms. Can't you see how useful it is that there's a standard way for a servlet container and a web server to communicate at high speed? Without loosing the data that proxying does? AJP has a chance of doing this. Tomcat gets some collaboration on the development of the protocol, and there's some competition because there are two ways of doing the same thing --- one version will undoubtedly be faster or more stable than the other, but there's an obvious incentive to improve both implementations, as well as the documentation of the protocol. Improved documentation of the protocol can only be a Good Thing, since it makes it easier for a newbie to start being useful when providing bug fixes, for a start. Also, the Not Invented Here attitude seems a little odd. I believe that you're coming from this as I'm a tomcat developer, not a jetty developer, but I'm coming at this as I'm a sysadmin who gets asked to make things happen. Occasionally, I have to use Jetty, occasionally tomcat. They both do the same job, and they both have to sit behind apache. Why should I need to use different tools to connect them together? There's a chance here to make life a little more pleasent for people on the sharp end. Why not take it? Regards, Simon -- Misspellers of the world untie! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: mod_jk2
Quoting Pier Fumagalli [EMAIL PROTECTED]: Fyi... Not acked... Just replied to this gentleman :) Asked to stay tuned and watch announcement on tomcat-dev for mod_jk 1.2.0 and 2.0.0 alpha. Henri -- Forwarded Message From: Mark Howell [EMAIL PROTECTED] Date: Thu, 4 Jul 2002 02:51:24 -0500 (CDT) To: [EMAIL PROTECTED] Subject: mod_jk2 Hello, The past two days, I have attempted to download mod_jk2 from http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/ and every time that I checked, the server suggested an empty directory structure. There is, under the nightly builds directory, mod_jk2 dll's for M$, but I'm looking for the Apache mod_jk2. Giving up on mod_jk2, I proceeded to try to get mod_jk instead, but found: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1 /bin/linux/i386/ to be empty as well. So...then I figured I would just build it from source, but: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1 /src/ was empty as well. TIA, Mark [EMAIL PROTECTED] -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat servlet and JBoss client problem!
Hi, I'm using Tomcat 4.0 as a servlet container for my servlet 'deltaclient'. This servlet is in fact a client of EJB application deployed on JBoss 2.4.4 This application runs on separate machine and requires authentication for every client app. The problem is that I can not instantiate javax.security.auth.login.LoginContext object from inside of the servlet. This object is required to make login operation and I have to create this in my client servlet. When I try to execute the same code as a simple java program (with main function) not as a servlet it works! I suppose that the problem is with java's SecurityManager config of Tomcat. But what can I do to solve this? Please help! Artur PS See the log output: StandardWrapperValve[deltaclient]: Allocate exception for servlet deltaclient javax.servlet.ServletException: unable to instantiate LoginConfiguration javax.servlet.ServletException: unable to instantiate LoginConfiguration at pl.empolis.delta.servlet.DeltaClient.init(DeltaClient.java:59) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:91 6) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:653) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:214) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:190) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve. java:170) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 64) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :174) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5 66) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 1012) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107 ) at java.lang.Thread.run(Thread.java:484) Pozdrawiam, AJ mailto:[EMAIL PROTECTED] http://strony.wp.pl/wp/ajonak -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
mturk 2002/07/04 05:44:56
Modified:jk/native2/server/isapi jk_isapi_plugin.c
Log:
Use the WaitForSingleObject instead of GetThreatExitCode.
There was a bug that caused terminating the starter thread
before the entire clenup finished.
The entire extinsion start/stop management is now done in a
separate thread.
Revision ChangesPath
1.33 +17 -29
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- jk_isapi_plugin.c 4 Jul 2002 07:23:55 - 1.32
+++ jk_isapi_plugin.c 4 Jul 2002 12:44:56 - 1.33
@@ -521,28 +521,17 @@
}
HANDLE jk2_starter_event;
+HANDLE jk2_starter_thread = NULL;
BOOL WINAPI TerminateFilter(DWORD dwFlags)
{
/* detatch the starter thread */
SetEvent(jk2_starter_event);
-
-if (is_inited) {
-is_inited = JK_FALSE;
-if (workerEnv) {
-jk_env_t *env = workerEnv-globalEnv;
-workerEnv-close(env, workerEnv);
-}
-apr_pool_destroy(jk_globalPool);
-workerEnv=NULL;
-is_mapread = JK_FALSE;
-}
+WaitForSingleObject(jk2_starter_thread, 3000);
return TRUE;
}
-HANDLE jk2_starter_thread = NULL;
-
DWORD WINAPI jk2_isapi_starter( LPVOID lpParam )
{
Sleep(1000);
@@ -552,7 +541,17 @@
if (init_jk(NULL))
is_mapread = JK_TRUE;
}
+
WaitForSingleObject(jk2_starter_event, INFINITE);
+
+if (is_inited) {
+is_inited = JK_FALSE;
+if (workerEnv) {
+jk_env_t *env = workerEnv-globalEnv;
+workerEnv-close(env, workerEnv);
+}
+is_mapread = JK_FALSE;
+}
return 0;
}
@@ -566,25 +565,17 @@
char dir[_MAX_DIR];
char fname[_MAX_FNAME];
DWORD dwThreadId;
-DWORD dwRes;
-int tcount = 0;
switch (ulReason) {
case DLL_PROCESS_DETACH:
-while (!GetExitCodeThread(jk2_starter_thread, dwRes)) {
-if (dwRes == STILL_ACTIVE) {
-++tcount;
-if (tcount 30) {
-TerminateThread(jk2_starter_thread, -1);
-break;
-}
-Sleep(100);
-}
-}
+WaitForSingleObject(jk2_starter_thread, INFINITE);
CloseHandle(jk2_starter_thread);
+apr_terminate();
break;
case DLL_PROCESS_ATTACH:
+apr_initialize();
+apr_pool_create( jk_globalPool, NULL );
if (GetModuleFileName( hInst, file_name, sizeof(file_name))) {
_splitpath( file_name, drive, dir, fname, NULL );
_makepath( ini_file_name, drive, dir, fname, .properties );
@@ -754,9 +745,6 @@
jk_pool_t *globalPool;
jk_bean_t *jkb;
jk_env_t *env;
-
-apr_initialize();
-apr_pool_create( jk_globalPool, NULL );
jk2_pool_apr_create( NULL, globalPool, NULL, jk_globalPool );
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk2 jvm thread issues
Hi, We have still some problems with the threads and jvm attach/detach. The detaching is now done in the afterRequest (It was already there but commented), but that doesn't prevent the case of the premature request dying when we are processing a long request (ore hanged one) and trying to shutdown the server. There fix for the Apache would be quite easy to implement (registering a pool cleanup for a request_rec), but the IIS imposes some problems. IMO we are needing something like a TLS to fix that, or make the behavior similar to the apache's request rec, creating a pool for each request. Does anyone has some other ideas about that. MT. ICQ# 163961212 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10487] New: - load-balancing for apache1.3/tomcat4.0.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10487. 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=10487 load-balancing for apache1.3/tomcat4.0.4 Summary: load-balancing for apache1.3/tomcat4.0.4 Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hello, I'd want to load-balance apache1.3 with tomcat4.0.4. My first test (with mod_jk/ajp13) fail : bug # 10378 So I test the communication apache/tomcat with Coyote (1.0-rc2) jk2 protocol handler (without load-balancing for the moment). and I have this errors (mod_jk.log) : [Thu Jul 04 17:54:07 2002] [jk_ajp13_worker.c (228)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [Thu Jul 04 17:54:07 2002] [jk_ajp13_worker.c (712)]: Error reading reply [Thu Jul 04 17:54:07 2002] [jk_ajp13_worker.c (845)]: In jk_endpoint_t::service, get_reply failed in send loop 0 For tomcat 4.0.4 : what is the solution for load-balancing and is there a complete documentation to do this ? In fact, I do my tests with : - mod_jk.so built from tomcat3.3 - coyote jars from : jakarta-tomcat-connectors/coyote/release/v1.0-rc2 (but only tomcat-jk2.jar and tomcat-jni.jar because the others are already in the tomcat4.0.4 package!!) - jk2.properties from jakarta-tomcat-connectors/coyote/release/v1.0-b8 (because there is not this file after this release) So, help... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
