Re:Re: SQL Realm for tomcat

[Neelesh]

Hi Ian,
  Thanks for pointing me to the links. Coming back to the realm, as far as
I know, JDBCRealm does not allow you to run arbitrary SQL queries against
the database to retrieve the role/password information. I believe, this can
be solved to some extent by creating appropriate views in the database. What
SQLRealm offers is the flexibility to pass in additional parameters to the
query (say, an organizationid or a departmentid) as part of j_username
value, delimited by some character. I understand that appending these extra
parameters to j_username is definitely a workaround, but it has proved to be
quite useful in a few projects.

Please do take a look at http://mirroronthenet.org/blog , if you can spare a
couple of minutes.

Thanks
Neelesh

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Henri Gomez]

What the status of mod_jk 1.2.17 ?

It would be usefull to get some binaries to help users check against
their platform, for instance win32.

Regards

2006/7/13, Henri Gomez <[EMAIL PROTECTED]>:

2006/7/13, Jean-frederic Clere <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
>
> > I don't know if we could called it a regression but the API spec is to
> > used a socklen_t not an int or unsigned int.
> >
> > iSeries compiler is very strict on such 'cast' and probably some
> > others. gcc is a little more conciliant :)
> >
> > BTW, I think next major version of mod_jk (1.3 / 3.x ?) should use APR
> > to be simpler and better integrated in Apache 2.x
>
> Use mod_proxy for that ;-)

There was discussion about next version / evolution of mod_jk, and I
feel we should make use of APR to stop battling about OS dependencies
on all IO/SYS system calls.



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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Mladen Turk]

Henri Gomez wrote:

What the status of mod_jk 1.2.17 ?

It would be usefull to get some binaries to help users check against
their platform, for instance win32.



http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
Wait for a while until synced.

Regards,
Mladen.

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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Rainer Jung]

Hi Mladen,

would you mind putting it on

http://tomcat.apache.org/dev/dist/

first?

Many thanks for the Win-Builds!

Regards,

Rainer

Mladen Turk wrote:

Henri Gomez wrote:


What the status of mod_jk 1.2.17 ?

It would be usefull to get some binaries to help users check against
their platform, for instance win32.



http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
Wait for a while until synced.

Regards,
Mladen.

-
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]

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Mladen Turk]

Rainer Jung wrote:

Hi Mladen,

would you mind putting it on

http://tomcat.apache.org/dev/dist/

first?



Nope. There is no version/platform directory
structure inside.


Regards,
Mladen.


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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Henri Gomez]

Thanks !

2006/7/17, Mladen Turk <[EMAIL PROTECTED]>:

Henri Gomez wrote:
> What the status of mod_jk 1.2.17 ?
>
> It would be usefull to get some binaries to help users check against
> their platform, for instance win32.
>

http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
Wait for a while until synced.

Regards,
Mladen.

-
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 40056] New: - added httpHeader after invoking chain.doFilter(..) gets lost by chunked transfer

[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=40056

   Summary: added httpHeader after invoking chain.doFilter(..) gets
lost by chunked transfer
   Product: Tomcat 5
   Version: 5.5.7
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P4
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Normally, an added http-header AFTER the call "chain.doFilter(request, response)
" is not transmitted to the client if a servlet or subsequent filter closes the 
output stream. 
It IS transmitted, if the filter closes the stream itself using a wrapper 
perventing subsequent filters or the servlet from closing the  stream.

If the entity size increases above the max. HTTP-Package size the container 
automatically adds the header "transfer-encoding:chunked" and removes the 
"content-size" header.
In this case any header added AFTER the call "chain.doFilter(request, 
response)" 
is NOT transmitted any more.

{
chain.doFilter(request, wrappedResponse);

wrappedResponse.addHeader("Test-Header","not transmitted if 
chunked");

// close Stream (call override-method of wrapper for ".close()")
wrappedResponse.closeOutputStream();
}

soo many words 4 discribing a tiny 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]

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[William A. Rowe, Jr.]

Mladen Turk wrote:

Rainer Jung wrote:

Hi Mladen,

would you mind putting it on

http://tomcat.apache.org/dev/dist/

first?



Nope. There is no version/platform directory
structure inside.


Uhm - then create one?  /dev/dist/ has the distinction of containing
anything any RM wants to create.  www.apache.org has the distinction
of containing only apache.org released code.

I'm happy to see tomcat picked the /dev/dist/ tree to distinguish
the candidates!  Binaries have got to obey the same process as source.

Bill

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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[William A. Rowe, Jr.]

William A. Rowe, Jr. wrote:

Mladen Turk wrote:

Rainer Jung wrote:

Hi Mladen,

would you mind putting it on

http://tomcat.apache.org/dev/dist/

first?



Nope. There is no version/platform directory
structure inside.


Uhm - then create one?  /dev/dist/ has the distinction of containing
anything any RM wants to create.  www.apache.org has the distinction
of containing only apache.org released code.

I'm happy to see tomcat picked the /dev/dist/ tree to distinguish
the candidates!  Binaries have got to obey the same process as source.


Actually, deserves further clarification... IF 1.2.17 is moved to www.
then all is well, the person who rolls the binaries chooses if they want
folks to test it first in /dev/dist/, or they are putting it straight
into the www. tree.  E.g., after major changes to the windows installer,
even with a released package, I'll drop these to /dev/dist/ and ask folks
to check out the installer changes before they get swept up by the mirrors
and widely used.

IF 1.2.17 sources aren't at www. then, well, the binaries don't belong
there either.

Bill

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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Mladen Turk]

William A. Rowe, Jr. wrote:


IF 1.2.17 sources aren't at www. then, well, the binaries don't belong
there either.



Simply used the current method.
Was not aware of the new repo inside tomcat.
Should I delete them or what?

Regards,
Mladen.

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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Mladen Turk]

Henri Gomez wrote:

jk 1.2.17 build failed on iSeries v5R3.

/home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
 argument assignment between types "int*" and "unsigned int*" is not
 allowed.



Henri, can you commit the working version?
Seems that the 'unsigned int' is present for ages,
and unless there is actual reason that would break
the functionality if you force your compiler to
treat this as warning instead as error,
we should go with 1.2.17.

OTOH, the same might apply to SOCKET<->int types
for windows, where we simply disregard the warnings
although I don't know how that behaves on win64, cause
SOCKET is defined as 'unsigned int *' (UINT_PTR)

Perhaps we could fix that socklen_t and add jk_sock_t
type all at once if you guys think this bug breaks
the 1.2.17.

Regards,
Mladen.

-
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

[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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-07-17 16:07 ---
Same expierence here... please get this fixed, suggested patches are here...

BTW: What's the difference between JAVA_OPTS and CATALINA_OPTS, anyway?  I
solved this by setting the com.sun.management.jmxremote.* stuff on CATALINA_OPTS
only, and then (as discussed above) commented out passing CATALINA_OPTS during
stop.  I found it "logical" to think that JAVA_OPTS are options passed to all
Java VM from catalina.sh/bat, but CATALINA_OPTS only to the actually started 
Tomcat.


PS: This "BindException: Address already in use" problem isn't limited to JMX;
doesn't the same - doesn't the same occur e.g. if a port for the debugger to
attach is used?  Or is that OK in the script and that's not passed on shutdown?

-- 
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: Next try: mod_jk 1.2.17 release candidate ready to test

[Rainer Jung]

Be careful:

I understand Henri problem report as getsockopt complaining about the 
*last* argument. So it has been introduced between 1.2.15 and 1.2.16:



r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri, 17 Mar 2006) | 1 line

Fix gcc 4.0.1 compiler warning at mac os x!


svn diff -r 386628:386629 jk_connect.c
Index: jk_connect.c
===
--- jk_connect.c(revision 386628)
+++ jk_connect.c(revision 386629)
@@ -177,7 +177,7 @@
&& (timeout > 0)) {
 fd_set wfdset;
 struct timeval tv;
-int rclen = sizeof(rc);
+unsigned int rclen = sizeof(rc);

 FD_ZERO(&wfdset);
 FD_SET(sock, &wfdset);

Since it actually build OK for Linux 32 and 64Bit I would also like to 
go forward with 1.2.17. Is it possible to make this error a warning on 
iSeries and fix for 1.2.18?


We set rclen only in the line

unsigned int rclen = sizeof(rc);

and rc itself is an int, there is no way, how rclen could behave 
differently as an argument (sign extensions). Furthermore we never read 
from rclen after passing &rclen to getsockopt(), so it really should be 
save using either of both ways (unsigned int and int).


Rainer

Mladen Turk wrote:

Henri Gomez wrote:


jk 1.2.17 build failed on iSeries v5R3.

/home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
 argument assignment between types "int*" and "unsigned int*" is not
 allowed.



Henri, can you commit the working version?
Seems that the 'unsigned int' is present for ages,
and unless there is actual reason that would break
the functionality if you force your compiler to
treat this as warning instead as error,
we should go with 1.2.17.

OTOH, the same might apply to SOCKET<->int types
for windows, where we simply disregard the warnings
although I don't know how that behaves on win64, cause
SOCKET is defined as 'unsigned int *' (UINT_PTR)

Perhaps we could fix that socklen_t and add jk_sock_t
type all at once if you guys think this bug breaks
the 1.2.17.

Regards,
Mladen.

-
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]

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Mladen Turk]

Rainer Jung wrote:

Be careful:

I understand Henri problem report as getsockopt complaining about the 
*last* argument. So it has been introduced between 1.2.15 and 1.2.16:



r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri, 17 Mar 2006) | 1 line

Fix gcc 4.0.1 compiler warning at mac os x!


Right, one fix breaks other :)
Anyhow, I suppose it should be neither int nor unsigned int,
but rather size_t, at least that's the retval from sizeof, right?
Of course its used by getsockopt that OTOH requires socklen_t.
I just wonder who is the genius that invented something that
stupid as socklen_t :)
I suppose it should be some sort of a size, correct?

--
Mladen.

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

Re: Next try: mod_jk 1.2.17 release candidate ready to test

[Rainer Jung]

Mladen Turk wrote:

Anyhow, I suppose it should be neither int nor unsigned int,
but rather size_t, at least that's the retval from sizeof, right?
Of course its used by getsockopt that OTOH requires socklen_t.


Since it's only use is putting it into getsockopt(), I would suggest the 
use of socklen_t and explicitely cast the return from sizeof().



I just wonder who is the genius that invented something that
stupid as socklen_t :)
I suppose it should be some sort of a size, correct?


Found some interesting pieces:

1) http://www.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html

Says:

 makes available a type, socklen_t, which is an unsigned 
opaque integral type of length of at least 32 bits. To forestall 
portability problems, it is recommended that applications should not use 
values larger than 2^32 - 1.


2) http://www.opengroup.org/austin/docs/austin_76r1.txt

has interesting comments (...The type socklen_t is an unfortunate 
historical accident...):


 The type socklen_t was invented to cover the range of implementations
 seen in the field.  The intent of socklen_t is to be the type for all
 lengths that are naturally bounded in size, that is, that they are the
 length of a buffer which cannot sensibly become of massive size: network
 addresses, hostnames, string representations of these, ancillary data,
 control messages, and socket options are examples.  Truly boundless
 sizes are represented by size_t as in read(), write(), etc.

 All socklen_t types were originally (in BSD UNIX) of type int.
 During the development of the document it was decided to change
 all buffer lengths to size_t, which appears at face value to make sense.
 When dual mode 32/64 bit systems came along, this choice unnecessarily
 complicated system interfaces because size_t (with long) was a different
 size under ILP32 and LP64 models.  Reverting to int would have happened
 except that some systems had already shipped 64-bit only interfaces. The
 compromise was a type which could be defined to be any size by the
 implementation: socklen_t.

and


 People are continually confused about socklen_t.

 The type socklen_t is an unfortunate historical accident, and needed to
 be invented to cover the range of implementations seen in the field.
 The intent of socklen_t is to be the type for all lengths that are
 naturally bounded in size, that is, that they are the length of a
 buffer which cannot sensibly become of massive size: network addresses,
 hostnames, string representations of these, ancillary data, control
 messages, and socket options are examples.  Truly boundless sizes are
 represented by size_t as in read(), write(), etc.

 All socklen_t types were originally (in BSD UNIX) of type int.
 An overzealous unknown decided without significant review to "correct"
 all buffer lengths to size_t, which appears on its face to make sense.
 When dual mode 32/64 bit systems came along, this choice unnecessarily
 complicated system interfaces because size_t (with long) was a different
 size under ILP32 and LP64 models.  Reverting to int would have happened
 except that some systems had already shipped 64-bit only interfaces. The
 compromise was a type which could be defined to be any size by the
 implementation: socklen_t.

Rainer



--
Mladen.

-
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]