On Wed, 2007-05-16 at 10:17 +0200, Henri Gomez wrote:
> 2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
> > 2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> > > The flag is about the response body. We send the response back via a
> > > webserver specific method. It's ws_write() ind mod_jk.c.
> > >
> > > w
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> The flag is about the response body. We send the response back via a
> webserver specific method. It's ws_write() ind mod_jk.c.
>
> ws_write() calls e.g. ap_rwrite() which should in my opinion set
> sent_bod
Hi Henri,
we still need to take care of the change in jk_map_read_properties():
-if (jk_file_exists(f) != JK_TRUE)
+if ((rc = jk_stat(f, &statbuf)) == -1)
otherwise we cant return time_t *modified since the statbuf isnt initialized.
Guen.
Hi Henry,
in jk_util.h we have:
#define jk_stat(a, b) stat(a, b)
in jk_map.c we have now:
if (jk_stat(f, &statbuf) != -1)
return JK_FALSE;
previously in 1.2.22 code we had:
if ((rc = stat(f, &statbuf)) == -1)
return JK_FALSE;
am I missing something, or
Exact. I'll commit a fix asap
2007/4/25, Jean-Frederic <[EMAIL PROTECTED]>:
On Wed, 2007-04-25 at 09:54 +0200, Henri Gomez wrote:
> In jklog_cleanup I could see :
>
> static apr_status_t jklog_cleanup(void *d)
> {
> #ifdef AS400
> main_log = NULL;
> #endif
>
> d = NULL;
> return APR_
On Wed, 2007-04-25 at 09:54 +0200, Henri Gomez wrote:
> In jklog_cleanup I could see :
>
> static apr_status_t jklog_cleanup(void *d)
> {
> #ifdef AS400
> main_log = NULL;
> #endif
>
> d = NULL;
> return APR_SUCCESS;
> }
>
> Shouldn't it be *d = NULL ?
I think that you should have:
In jklog_cleanup I could see :
static apr_status_t jklog_cleanup(void *d)
{
#ifdef AS400
main_log = NULL;
#endif
d = NULL;
return APR_SUCCESS;
}
Shouldn't it be *d = NULL ?
Also shouldn't we reset main_log and conf->log ?
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
It works ! great
It works ! great.
Could I commit ?
Also find a way to fix for i5/OS the HTTP 500 problem
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
jklog_cleanup) ?
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
> Great. I think I
You remove completly the apr_pool_cleanup_register(p, conf->log, jklog_cleanup,
jklog_cleanup) ?
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
Great. I think I now understand the problem.
Could you try this one relativ to your last change:
Index: mod_jk.c
Great. I think I now understand the problem.
Could you try this one relativ to your last change:
Index: mod_jk.c
===
--- mod_jk.c(revision 531926)
+++ mod_jk.c(working copy)
@@ -2539,11 +2539,7 @@
static apr_status_t jklog_
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
The flag is about the response body. We send the response back via a
webserver specific method. It's ws_write() ind mod_jk.c.
ws_write() calls e.g. ap_rwrite() which should in my opinion set
sent_bodyct. I'm careful about that, because I don't fully un
I made it works by adding main_log = NULL in jklog_cleanup
static apr_status_t jklog_cleanup(void *d)
{
/* set the main_log to NULL */
d = NULL;
main_log = NULL;
return APR_SUCCESS;
}
Don't forget that jk is initialized twice and on i5/OS in the same
thread, so may be the static var
main_log is a static in mod_jk.c, which is initialized as NULL.
It gets set inside open_jklog() which gets called once for every virtual
server by jk_post_config() during server initialization.
The first virtual server inherits its logger conf->log from its
configuration to main_log. It also regi
The flag is about the response body. We send the response back via a
webserver specific method. It's ws_write() ind mod_jk.c.
ws_write() calls e.g. ap_rwrite() which should in my opinion set
sent_bodyct. I'm careful about that, because I don't fully understand
the filter architecture involved.
Bu
I'm looking for the exception in jk_log. It happen in ws_write right
now and I wonder what's the life cycle of main_log.
On i5/OS, the init / post are done on the same thread (not the same on Unixes).
How is reset the main_log ?
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
checked that assbackw
checked that assbackwards is 0 on i5/OS
2007/4/24, Rainer Jung <[EMAIL PROTECTED]>:
Hi Henri,
> - Another annoying problem is the HTTP 500 error in SOAP mode. It
> seems the sent_bodyct flag is not set in Apache 2 side, which is
> strange since I got reply from Tomcat (HTTP 500 in HEADER and
>
On my Linux test box, sent_body is allways set.
Did there is some default configuration in Apache 2.0 to flush header
automatically ?
2007/4/24, Henri Gomez <[EMAIL PROTECTED]>:
Ok, just add some log in mod_jk.c and see :
if (rc > 0) {^M
/* If tomcat returned no b
Ok, just add some log in mod_jk.c and see :
if (rc > 0) {^M
/* If tomcat returned no body and the status is not OK,^M
let apache handle the error code */^M
jk_log(xconf->log, JK_LOG_INFO, "sent_bodyct=%d status=%d
header_only=%d" , r->sent_bodyct, r->st
Hi Henri,
> - Another annoying problem is the HTTP 500 error in SOAP mode. It
> seems the sent_bodyct flag is not set in Apache 2 side, which is
> strange since I got reply from Tomcat (HTTP 500 in HEADER and
> SOAPFault in BODY).
>
> Since the sent_bodyct should be set inside Apache 2.x, it may b
Hi to all,
I commited on the changes to make jk works on i5/OS V5R4 (didn't test
anymore on previous release since we upgraded to V5R4).
I still see 2 problems :
- Call to jk_logger still generate thread exceptions, so I temporary
fix that by using printf instead of l->log in jk_log() (jk_util.
Works on progress, I'll made a jk_stat for AS400_UTF8 only
2007/4/23, Guenter Knauf <[EMAIL PROTECTED]>:
Hi Henri,
suggestion (otherwise we would also have 2 unused vars rc and ptr on all
non-AS400 platforms):
int jk_file_exists(const char *f)
{
if (f) {
struct stat st;
int
Hi Henri,
suggestion (otherwise we would also have 2 unused vars rc and ptr on all
non-AS400 platforms):
int jk_file_exists(const char *f)
{
if (f) {
struct stat st;
int rc;
#ifdef AS400
#define S_IFREG _S_IFREG
char *ptr;
/**
* i5/OS V5R4 expect filename in ASCII for
Hi Henri,
> I can adapt some by defines (allready commited) but others require
> more code (to be commited) and of course code less readable...
you may be able to reduce some ifdefs in jk_utils.c with f.e.:
#ifdef AS400
#define S_IFREG _S_IFREG
#endif
> BTW, I will replace call to stat() by calls
Hi,
> My question will be, could we make APR mandatory, even for Apache 1.3 or
> IIS ?
-1 from my side; APR cant be used on NetWare with Apache 1.3 / Netscape due to
other lib version APR depends on. This would again break my just fixed things
with AP13 mod_jk and the Netscape connectors...
isnt
2007/4/23, Guenter Knauf <[EMAIL PROTECTED]>:
Hi,
> My question will be, could we make APR mandatory, even for Apache 1.3 or
> IIS ?
-1 from my side; APR cant be used on NetWare with Apache 1.3 / Netscape due to
other lib version APR depends on. This would again break my just fixed things
with
i5/OS V5R4 show me more and more subtilities :
When designing Apache module, APR/HTTP make use of UTF8.
Some of the i5/OS apis like inet_addr() or stat() need EBCDIC strings,
but others need
ASCII like ... fopen().
So may realize why I'll be happy to see an fully APR based jk
implementation (an
Le 23/04/07, Remy Maucherat<[EMAIL PROTECTED]> a écrit :
Henri Gomez wrote:
> Bonne idée.
>
> Maintenant le loup c'est dans l'ouverture de fichier
> workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
>
> Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
> I/O dans
Henri Gomez wrote:
Bonne idée.
Maintenant le loup c'est dans l'ouverture de fichier
workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
I/O dans mod_jk ?
On se calme, on se calme :)
Rémy
--
Bonne idée.
Maintenant le loup c'est dans l'ouverture de fichier
workers.properties car là aussi fopen bosse sur de ... l'EBCDIC.
Putain pourquoi on n'utilise pas carrement APR pour tout ce qui est
I/O dans mod_jk ?
2007/4/23, Jean-Frederic <[EMAIL PROTECTED]>:
On Mon, 2007-04-23 at 12:26 +020
On Mon, 2007-04-23 at 12:26 +0200, Henri Gomez wrote:
> Hi to all,
>
> I'm still working on i5/OS V5R4 port and I'm facing the following problem.
>
> i5/OS is an EBCDIC system, but in V5R4, IBM decided, for modules
> writer ease, to make all HTTP and APR routines works in UTF.
>
> That's fine bu
Hi to all,
I'm still working on i5/OS V5R4 port and I'm facing the following problem.
i5/OS is an EBCDIC system, but in V5R4, IBM decided, for modules
writer ease, to make all HTTP and APR routines works in UTF.
That's fine but all the native runtime functions still works in EBDIC.
So function
31 matches
Mail list logo