[ANNOUNCEMENT] Domino / Tomcat connecter available
I've written a Tomcat for Lotus Domino in the spirit of the IIS and Netscape connectors making it possible to use Tomcat as Domino's servlet container. It can be found at http://free.tagish.net/domino-tomcat/index.jsp It's quite small and wouldn't look at all out of place in the Tomcat release ;-) -- Andy Armstrong, Tagish
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
Hi Pier, It's using AJP at the mo, though it could, I think, also use JNI. Not using Domino's bundled VM tho. "Pier P. Fumagalli" wrote: > > Andy Armstrong at [EMAIL PROTECTED] wrote: > > > I've written a Tomcat for Lotus Domino in the spirit of the IIS and > > Netscape connectors making it possible to use Tomcat as Domino's servlet > > container. > > > > It can be found at > > > > http://free.tagish.net/domino-tomcat/index.jsp > > > > It's quite small and wouldn't look at all out of place in the Tomcat > > release ;-) > > I didn't take a look at the sources (bear with me for a second, please :) I > believe it's for Tomcat 3.x, but are you actually using the VM inside Domino > itself or using something like JNI/AJP?? > > Thanks a lot... (Will check the sources this weekend) > > Pier -- Andy Armstrong, Tagish
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
That would be super cool with me ;-) GOMEZ Henri wrote: > > We could add it to jakarta-tomcat-connector ? > > - > Henri Gomez ___[_] > EMAIL : [EMAIL PROTECTED](. .) > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 > > >-----Original Message- > >From: Andy Armstrong [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, May 30, 2001 1:05 PM > >To: Tomcat Dev > >Subject: [ANNOUNCEMENT] Domino / Tomcat connecter available > > > > > >I've written a Tomcat for Lotus Domino in the spirit of the IIS and > >Netscape connectors making it possible to use Tomcat as > >Domino's servlet > >container. > > > >It can be found at > > > > http://free.tagish.net/domino-tomcat/index.jsp > > > >It's quite small and wouldn't look at all out of place in the Tomcat > >release ;-) > > > >-- > >Andy Armstrong, Tagish > > -- Andy Armstrong, Tagish
Re: [BUG T322] Bug in getServletContext().getResource() for relative URLs
[EMAIL PROTECTED] wrote: > > Wasn't one of the 3.2.2 changes that you could not request URLs from the > WEB-INF directory? Possibly its just that and not really all relative URLs. The IIS and Domino connectors certainly explicitly veto access to the web-inf directory. -- Andy Armstrong, Tagish
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
kevin seguin wrote: > > > > > We could add it to jakarta-tomcat-connector ? > > > > +1 -- so long as andy will help fix bugs in it when/if they come :) Of course ;-) We'll be actively using it here for a long time to come, so we'll have a vested interest in keeping it sweet. -- Andy Armstrong, Tagish
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
GOMEZ Henri wrote:
>
> >> We could add it to jakarta-tomcat-connector ?
> >>
> >
> >+1 -- so long as andy will help fix bugs in it when/if they come :)
>
> I'll commit this works on current JTC.
>
> I'd like to see this connector supporting others protocol like
> ajp13 and may be ajp14/warp.
I'm going to investigate ajp{13,14} support this weekend ;-)
--
Andy Armstrong, Tagish
A starting point for ajp13, ajp14/warp anyone?
Hi, This weekend I'm going to look at making the Domino connector we released this week use ajp13 or ajp14 or both. Can anyone give me a quick pointer to which source I should grab from where (or a meta pointer to something I can read to find out) to get started. I had a quick look at the Tomcat 4 sources -- am I right in thinking that the only ajp14 connector that exists at the moment is the Apache one? Sorry if this is an rtfm -- I've had a quick look round the site but couldn't find much. -- Andy Armstrong, Tagish
Re: A starting point for ajp13, ajp14/warp anyone?
Thanks for that Kevin. Pardon my ignorance ;-) kevin seguin wrote: > > tomcat 4 is not the right place to look for ajp13 examples. ajp14 is > still in the early stages, so you're probably better off starting with > ajp13. jakarta-tomcat-connectors/jk is probably the best place to look > for examples. there are ajp13 connectors for apache, iis and netscape. > you're domino connector is also there now, i think :) > > Andy Armstrong wrote: > > > > Hi, > > > > This weekend I'm going to look at making the Domino connector we > > released this week use ajp13 or ajp14 or both. Can anyone give me a > > quick pointer to which source I should grab from where (or a meta > > pointer to something I can read to find out) to get started. I had a > > quick look at the Tomcat 4 sources -- am I right in thinking that the > > only ajp14 connector that exists at the moment is the Apache one? > > > > Sorry if this is an rtfm -- I've had a quick look round the site but > > couldn't find much. > > > > -- > > Andy Armstrong, Tagish -- Andy Armstrong, Tagish
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
GOMEZ Henri wrote: > > >> We could add it to jakarta-tomcat-connector ? > >> > > > >+1 -- so long as andy will help fix bugs in it when/if they come :) > > I'll commit this works on current JTC. > > I'd like to see this connector supporting others protocol like > ajp13 and may be ajp14/warp. I've just been testing it against ajp13 and it seems fine -- did you think there might be a problem with it? Or was it just because it wasn't tested? -- Andy Armstrong, Tagish
Re: [ANNOUNCEMENT] Domino / Tomcat connecter available
GOMEZ Henri wrote: > > >GOMEZ Henri wrote: > >> > >> >> We could add it to jakarta-tomcat-connector ? > >> >> > >> > > >> >+1 -- so long as andy will help fix bugs in it when/if they come :) > >> > >> I'll commit this works on current JTC. > >> > >> I'd like to see this connector supporting others protocol like > >> ajp13 and may be ajp14/warp. > > > >I've just been testing it against ajp13 and it seems fine -- did you > >think there might be a problem with it? Or was it just because > >it wasn't > >tested? > > i just wasn't tested and you're now our resident expert in Domino > and Tomcat connection. Welcome on-board... Thanks ;-) Next up I'm going to try and get it all going on Linux which should also open up the possibility of migrating to other Unices -- though I'm not in a position to test anything other than Linux. -- Andy Armstrong, Tagish
Re: A starting point for ajp13, ajp14/warp anyone?
Thanks Henri, I needed the original code in such a hurry that I confess I didn't take much time finding out what was what. GOMEZ Henri wrote: > > jakarta-tomcat-connector is the safe place to put experimental > code, like Domino redirector. > > Also we could hope this sub-project could be one day the > reference of connectors between majors Web-Servers and > jakarta Servlet Engines :) > > It's an arena where there we may speak more on native > problems (OS, web-server, autoconf, libtool, apr) than > Java :) > > - > Henri Gomez ___[_] > EMAIL : [EMAIL PROTECTED](. .) > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 > > >-Original Message- > >From: Andy Armstrong [mailto:[EMAIL PROTECTED]] > >Sent: Friday, June 01, 2001 9:58 PM > >To: [EMAIL PROTECTED] > >Subject: Re: A starting point for ajp13, ajp14/warp anyone? > > > > > >Thanks for that Kevin. Pardon my ignorance ;-) > > > >kevin seguin wrote: > >> > >> tomcat 4 is not the right place to look for ajp13 examples. ajp14 is > >> still in the early stages, so you're probably better off > >starting with > >> ajp13. jakarta-tomcat-connectors/jk is probably the best > >place to look > >> for examples. there are ajp13 connectors for apache, iis > >and netscape. > >> you're domino connector is also there now, i think :) > >> > >> Andy Armstrong wrote: > >> > > >> > Hi, > >> > > >> > This weekend I'm going to look at making the Domino connector we > >> > released this week use ajp13 or ajp14 or both. Can anyone give me a > >> > quick pointer to which source I should grab from where (or a meta > >> > pointer to something I can read to find out) to get > >started. I had a > >> > quick look at the Tomcat 4 sources -- am I right in > >thinking that the > >> > only ajp14 connector that exists at the moment is the Apache one? > >> > > >> > Sorry if this is an rtfm -- I've had a quick look round > >the site but > >> > couldn't find much. > >> > > >> > -- > >> > Andy Armstrong, Tagish > > > >-- > >Andy Armstrong, Tagish > > -- Andy Armstrong, Tagish
[ANNOUNCE] Domino redirector 1.0.1
Version 1.0.1 of the Lotus Domino redirector is available now at http://free.tagish.net/domino-tomcat/ The main change is that Linux is a supported platform in addition to Win32. It should be quite simple to build it for other Unices now, and I'd be most grateful to hear of the experiences of anyone who is in a position to do this. -- Andy Armstrong, Tagish
Re: [VOTE] New Committer: Andy Armstrong
Thanks folks ;-) kevin seguin wrote: > > i'd like to propose Andy Armstrong as a new committer. > > he has provided a connector for the lotus domino webserver > (http://free.tagish.net/domino-tomcat/index.jsp) which has recently been > incorporated into jakarta-tomcat-connectors. > > please vote :) > > -kevin. -- Andy Armstrong, Tagish
Re: realms and authentication
Is this not more or less what JAAS does? There are a number of JAAS
modules at http://free.tagish.net/ that implement among other things a
JDBC Authentication provider.
Michael Jennings wrote:
>
> Hi everyone,
>
> Just for my own education, I decided to write my own authentication-stuff
> for tomcat 3.2.2
>
> To that end I wrote a Request Interceptor that takes 2 parameters
> called "realmProviderClass" and "setupString".
>
> The "realmProviderClass" is the fully-qualified class name of a class which
> implements
> the "RealmProvider" interface which looks like the following:
>
> public interface RealmProvider
> {
> public boolean authenticate(String username, String credentials) throws
> Exception;
> public String[] getUserRoles(String username) throws Exception;
> public boolean initialize(String setupstring) throws Exception;
> public void shutdown() throws Exception;
> }
>
> The "setupString" parameter is passed to the initialize method of the
> RealmProvider class
> during context initialization.
>
> I thought that this might be an easy way to implement various different
> authentication schemes
> by delegating to a "RealmProvider". One could write a "SimpleRealmProvider"
> or a "JDBCRealmProvider"
> etc.
>
> Does anyone think this might be a good idea for inclusion in tomcat?
> -Mike
>
> __
> Mike Jennings
> Southgate Software Ltd.
> 250-382-6851 (ph)
> 250-382-6800 (fax)
> [EMAIL PROTECTED]
--
Andy Armstrong, Tagish
Re: realms and authentication
Michael Jennings wrote: > > Thanks for the feedback! > > Does tomcat 3.2.2 currently support JAAS? Not in any explicit sense I think (anyone?), but JAAS is usable with Tomcat -- if that isn't too much of a politicians answer! -- Andy Armstrong, Tagish
Re: realms and authentication
Antony Bowesman wrote: > > "Ignacio J. Ortega" wrote: > > > > I do like your idea , this was something i was talking some time ago, > > But better than for 3.2.2 ( that is on bug fix mode only , no new > > features ), But I would prefer to apply your idea to share Realms > > Implementatios between 3.3 and 4.0, a much more useful objetive.. > > I would like to see Tomcat taking the initiative and providing core > support for JAAS given then pending inclusion of JAAS in the final > release of JDK1.4. I know this would limit tomcat to JDK1.3 and above > but this should not be a problem for v4. All the existing realm > implementations can then be re-implemented as JAAS LoginModules. This would seem to me to be the way to go. +1 here. -- Andy Armstrong, Tagish
Re: realms and authentication
Antony Bowesman wrote: > > Andy Armstrong wrote: > > > > Michael Jennings wrote: > > > > > > Thanks for the feedback! > > > > > > Does tomcat 3.2.2 currently support JAAS? > > > > Not in any explicit sense I think (anyone?), > > JAAS is not explicitly supported by tomcat. JAAS was only available > from JDK 1.3, supplied as an extension. JAAS is now merged into JDK1.4 > but there is no explicit support for JAAS in the servlet API spec 2.3 > although JAAS is graudually gaining momentum. There has to be some > reworking to the servlet spec (as well as EJB) to support the concept of > multiple Principals and the JAAS Subject. I've just been having a look at this. As you say it would be easy enough to implement a JAAS realm -- the main problem being how to provide access to the JAAS Subject. The cleanest route would seem to be just to expose the Subject directly by adding Subject getUserSubject() to HttpServletRequest() leaving the question of how to change the handling of Principals to reflect the fact that there can be more than one under JAAS. A quick google reveals that the question of JAAS/Tomcat integration, but I couldn't bottom out what the consensus was last time -- the threads I found just seemed to fizzle out... -- Andy Armstrong, Tagish
Re: realms and authentication
Antony Bowesman wrote: > > Andy Armstrong wrote: [snip] > > I've just been having a look at this. As you say it would be easy enough > > to implement a JAAS realm -- the main problem being how to provide > > access to the JAAS Subject. The cleanest route would seem to be just to > > expose the Subject directly by adding > > > > Subject getUserSubject() > > > > to HttpServletRequest() leaving the question of how to change the > > handling of Principals to reflect the fact that there can be more than > > one under JAAS. > > Exactly, I would hope that this is how it will be exposed in Servlet and > EJB specs with getUser/CallerPrincipal being deprecated in favour of > getUser/CallerSubject. Do we know if there's any likelyhood of this happening? > Another issue is how roles work. The current isUser/CallerInRole > methods are rather simple. Mapping realm roles to application roles > needs to be addresses, I see that Alex Roytman's mail to user group > allows for a role mapping class to map from user realm roles to the J2EE > roles in the servlet spec. I also have the same concept with my JAAS > realm so that user realm roles can be mapped to J2EE String roles based > on the web app context. It seems to make sense that roles would be > incorporated as Principals inside the Subject so they could then be used > inside JAAS authorization. In general JAAS providers do seem to map roles (or groups) to Principals whenever the concept makes sense. -- Andy Armstrong, Tagish
Re: realms and authentication
[EMAIL PROTECTED] wrote: > > Just FYI, I don't think this is a good idea for general > tomcat authentication. > > One reason is that "credentials" are not allways a simple string - you can > have complex authentication schemes where you require certain schemes > based on the IP address, etc. JAAS has been designed to address this problem -- it isn't limited to plain text username/password credentials. > GetUserRoles might not work for paranoid realms - if I remember corectly > some allow you to check if a user has a certain role, but not to find all > the roles that a user has. For example Apache ( if you treat the native > apache auth modules as a realm - quite usefull for integration with > apache). Not quite sure how this could map to JAAS. getPrincipals() returns all the Principals for a Subject. Actually I suppose it could legitimately return a subset of Principals based on inspection rights that have been granted to the caller. -- Andy Armstrong, Tagish
Re: SSL - NES / DOMINO
Andy Armstrong wrote:
[snip]
> There's a bug in the current release of the Domino connector that means
> that it doesn't properly recognise SSL requests, which means it doesn't
> is_ssl in the jk_ws_service structure. I've fixed this now, but I don't
> seem to be able to recover values for ssl_cert, ssl_cipher or
> ssl_session from Domino. I also find that if I these fields are set as
> follows
>
> s->is_ssl = 1;/* i.e. it is an SSL request... */
> s->ssl_cert_len = 128;
> s->ssl_cert = NULL; /* ...but we don't have these values */
> s->ssl_cipher = NULL;
> s->ssl_session = NULL;
>
> I'm getting a null pointer exception in Ajp13ConnectorRequest.java at
> this code:
> case SC_A_SSL_CERT :
> isSSL = true;
> ---> attributes.put("javax.servlet.request.X509Certificate",
>msg.getString());
> break;
>
> It seems that msg.getString() is probably returning a null. This may be
> because I'm working with Tomcat 3.2.1 tonight, so I'm just grabbing a
> copy of 3.3 to see if that problem has been fixed.
I've now had a look at the 3.3 source for ajp13 and I think I understand
the problem. Look at this:
if(s->ssl_cert_len) {
if(0 != jk_b_append_byte(msg, SC_A_SSL_CERT) ||
0 != jk_b_append_string(msg, s->ssl_cert)) {
jk_log(l, JK_LOG_ERROR,
"Error ajp13_marshal_into_msgb - Error appending the
SSL certificates\n");
return JK_FALSE;
}
}
I've been assuming that ssl_cert_len and ssl_cert are independent
variables, and specifically that it's possible, and desirable, to know
the length of the cert without actually having the cert. However, the
ajp13 code assumes that if you know the length of the cert you also have
the cert. If ssl_cert_len != 0 then it assumes that ssl_cert != NULL and
attempts to send it.
Is this correct? Is it never useful to know the cert's length without
having the cert itself?
--
Andy Armstrong, Tagish
Re: SSL - NES / DOMINO
Hi Henri,
GOMEZ Henri wrote:
>
> Hi,
>
> I take a look at NES and the SSL vars are not handled
> by this connector.
>
> Idem for DOMINO where some vars are grabbed but not used.
>
> Who know how to get the SSL vars (the following come from apache+mod_ssl) :
>
> SSL_CLIENT_CERT => The client certificat (if user auth used)
> SSL_CIPHER => cipher used (ie RC4-MD5)
> SSL_SESSION_ID => SSL session ID, a big number unique big SSL
> SESSION
> SSL_CIPHER_USEKEYSIZE => #bits used in clt<->srv exchange ie: 128
There's a bug in the current release of the Domino connector that means
that it doesn't properly recognise SSL requests, which means it doesn't
is_ssl in the jk_ws_service structure. I've fixed this now, but I don't
seem to be able to recover values for ssl_cert, ssl_cipher or
ssl_session from Domino. I also find that if I these fields are set as
follows
s->is_ssl = 1;/* i.e. it is an SSL request... */
s->ssl_cert_len = 128;
s->ssl_cert = NULL; /* ...but we don't have these values */
s->ssl_cipher = NULL;
s->ssl_session = NULL;
I'm getting a null pointer exception in Ajp13ConnectorRequest.java at
this code:
case SC_A_SSL_CERT :
isSSL = true;
---> attributes.put("javax.servlet.request.X509Certificate",
msg.getString());
break;
It seems that msg.getString() is probably returning a null. This may be
because I'm working with Tomcat 3.2.1 tonight, so I'm just grabbing a
copy of 3.3 to see if that problem has been fixed.
Once I've solved this little problem I'll make a new release which
understands SSL.
> Here is was I got in TC 3.3-M3 (using initial AJP14), with attached
> snoop.jsp against Apache 1.3.20/mod_ssl 2.8.4
>
> Request Information
>
> JSP Request Method: GET
> Request URI: /examples/jsp/snp/snoop.jsp
> Request Protocol: HTTP/1.0
> Servlet path: /jsp/snp/snoop.jsp
> Path info: null
> Path translated: null
> Query string: null
> Content length: -1
> Content type: null
> Server name: localhost
> Server port: 443
> Remote user: null
> Remote address: 127.0.0.1
> Remote host: localhost
> Authorization scheme: null
>
> SSL Client Certificate: null
> SSL Cypher Suite: RC4-MD5
> SSL Session Id:
> 9A9F153F57A505AA3FAB648223929413BC035ACE89FF2735138456F7B38B2CAB
> SSL Key Size: 128
>
> The browser you are using is Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)
>
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
> Name: snoop.jsp
>snoop.jspType: unspecified type (application/octet-stream)
> Encoding: quoted-printable
--
Andy Armstrong, Tagish
Re: SSL - NES / DOMINO
Andy Armstrong wrote:
[snip]
> I've now had a look at the 3.3 source for ajp13 and I think I understand
> the problem. Look at this:
>
> if(s->ssl_cert_len) {
> if(0 != jk_b_append_byte(msg, SC_A_SSL_CERT) ||
>0 != jk_b_append_string(msg, s->ssl_cert)) {
> jk_log(l, JK_LOG_ERROR,
>"Error ajp13_marshal_into_msgb - Error appending the
> SSL certificates\n");
>
> return JK_FALSE;
> }
> }
>
> I've been assuming that ssl_cert_len and ssl_cert are independent
> variables, and specifically that it's possible, and desirable, to know
> the length of the cert without actually having the cert. However, the
> ajp13 code assumes that if you know the length of the cert you also have
> the cert. If ssl_cert_len != 0 then it assumes that ssl_cert != NULL and
> attempts to send it.
>
> Is this correct? Is it never useful to know the cert's length without
> having the cert itself?
I've now found where Domino stashes the cert/cert length and am now
passing them through to Tomcat. I'll make a new release tomorrow when
I've had a chance to test against an NT Domino server.
Incidentally, is it the case that the SSL Cert contains, in effect,
arbitrary binary data? If so the code I quoted above from ajp13 seems to
be flawed in that it uses jk_b_append_string() (which expects a null
terminated string) to append the cert to the message. If there happens
to be a zero byte in the cert it will be truncated at that point.
--
Andy Armstrong, Tagish
[ANNOUNCE] Domino redirector 1.0.2
Version 1.0.2 of the Lotus Domino redirector for Win32 and Linux is available now at http://free.tagish.net/domino-tomcat/ The main change is a fix to the SSL handling that means that SSL connections are now correctly reported to Tomcat. -- Andy Armstrong, Tagish
Re: [ANNOUNCE] Domino redirector 1.0.2
GOMEZ Henri wrote: > > >Version 1.0.2 of the Lotus Domino redirector for Win32 and Linux is > >available now at > > > > http://free.tagish.net/domino-tomcat/ > > > >The main change is a fix to the SSL handling that means that SSL > >connections are now correctly reported to Tomcat. > > Excellent !:) > > Will you commit it ? I don't seem to have commit rights yet -- I didn't really hear much after the vote. Otherwise I would have ;-) -- Andy Armstrong, Tagish
Re: [ANNOUNCE] Domino redirector 1.0.2
GOMEZ Henri wrote: > > 7 vote +1, no vote -1 > > You're now commiter: > > Craig is a little busy with JavaOne but I'm sure > he will do the necessary next week. > > I'll do the commit :) Merci Henri. -- Andy Armstrong, Tagish
Re: [ANNOUNCE] Domino redirector 1.0.2
"Craig R. McClanahan" wrote: > > On Fri, 8 Jun 2001, Andy Armstrong wrote: > > > GOMEZ Henri wrote: > > > > > > >Version 1.0.2 of the Lotus Domino redirector for Win32 and Linux is > > > >available now at > > > > > > > > http://free.tagish.net/domino-tomcat/ > > > > > > > >The main change is a fix to the SSL handling that means that SSL > > > >connections are now correctly reported to Tomcat. > > > > > > Excellent !:) > > > > > > Will you commit it ? > > > > I don't seem to have commit rights yet -- I didn't really hear much > > after the vote. Otherwise I would have ;-) > > > > That's my fault -- your vote caught me at JavaOne where I barely had time > to breath, let alone process much TOMCAT-DEV mail. I will initiate the > appropriate process shortly. I thought it might be something like that ;-) -- Andy Armstrong, Tagish
Re: [j-t-c] OS poll
NT4/5, GNU/Linux (Various kernels) GOMEZ Henri wrote: > > Hi, > > A quick poll to get informations about OS used by > j-t-c developpers & users ... > > I: Redhat 6.2 / 7.1 > > - > Henri Gomez ___[_] > EMAIL : [EMAIL PROTECTED](. .) > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- Andy Armstrong, Tagish
Re: [ANNOUNCE] Domino redirector 1.0.2
"Craig R. McClanahan" wrote: [snip] > Your new username/password should have been delivered, and I've set up > your commit privileges. Welcome! How was that sent? I don't have it yet, but I'm on the road ATM. -- Andy Armstrong, Tagish
Re: [j-t-c] OS poll => [j-t-c] webserver poll
Apache 1.3/Win32 Apache 1.3/GNU/Linux (actually RedHat 6, 7) IIS 4.0/NT IIS 5.0/2000 Domino 5/Linux Domino 5/NT -- Andy Armstrong, Tagish
Re: ~rant~ Docs, user list, etc.
How about a decent book? Robert Slifka wrote: > > I've only recently re-subscibed to the user list, but so far, since last > summer, the average quality of question seems way down. I guess it's a > testament to Tomcat's increasing popularity. People think, "oh, Tomcat!" > then they come here and email to the user list, "How do i install and > configure Tomcat?" I'm sure the committers get this all the time, but in > 2-3 days of answering questions, I've started to get personal emails as > well! > > Rather than continue to bludgeon people with documentation they refuse to > read (as one poster writes, "...hence i would like to get your ideas rather > than just reading through the docs") is there something else that can be > done? > > Maybe more mailing lists than just user? tomcat-apache, tomcat-install, > etc.? > > Or maybe a configuration validation program that does more than just check > syntax (a la httpd's)? > > I'm trying to take some intiative here, but I've been out of the loop since > Oct 2000 or so =) > > Thoughts anyone? > > - r -- Andy Armstrong, Tagish
#define JK_VERSION in j-t-c (doesn't exist)
Hi Folks, I'm doing some work on the domino tomcat connector which makes the current version unbuildable for anything < T4.0. It occurred to me that there might be a #define somewhere in the shared jk_* stuff that would give me a version number I could test, but I can't see one. Is there anything there? Should there be? -- Andy Armstrong, Tagish
Re: Tomcat book WAS : RE: ~rant~ Docs, user list, etc.
Martin van den Bemt wrote: > > I tried that in the past, writing a book ;-(( wasn't happy with that, before > I finished, the new version was already there or someone else already > created a book. I'm not a fast writer anyway ;-)) (the first sentence block, > is what I'm suffering of). Start in the middle ;-) > maby we could all write that book. Everyone has > different experience in different area's and can write on there favorite > subject (also needed for documentation anyway). Why not make it a more > structured effort for this. Maby a n writer with some experience in writing > (?) can do an initial set up of where such a book should end up, to be > actually usefull. This is just an idea and no I'm not volunteering to do > this ;-)). I actually need to do some painting and do something about my > garden now, so I can enjoy the summer and a home which actually looks like a > place where also other people would like to come ;-)). -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote:
[snip explanation of versions]
> the jk in j-t-c, is an evolution of mod_jk found in Tomcat 3.3.
> We add more features and entry points but keep compatibility
> with actual Tomcat 3.2/3.3/4.0 (with its ajp13 connector).
Ah. So it's really the jk version I need then so people can build the
connector whether they have the latest j-t-c source or something like
the Tomcat 3.2 source distro. It would be useful to have an API version
number somewhere.
How about
#define JK_EXPOSED_VERSION ("mod_jk/1.1a1") <== exists now
#define JK_VERSION 1 <== proposed
in jk_global.h? There should be some defined mapping between the version
string and the number too I suppose.
--
Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote:
>
> >Ah. So it's really the jk version I need then so people can build the
> >connector whether they have the latest j-t-c source or something like
> >the Tomcat 3.2 source distro. It would be useful to have an API version
> >number somewhere.
>
> * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) :
>
> we could version it : 1.0.x
>
> * mod_jk in TC 3.3 is not frozen but there will be no major feature added :
>
> we could version it : 1.1.x
>
> * mod_jk in J-T-C will continue its evolution :
>
> we could version it : 1.2.x
>
> >How about
> >
> >#define JK_EXPOSED_VERSION ("mod_jk/1.1a1") <== exists now
> >#define JK_VERSION 1 <== proposed
> >
> >in jk_global.h? There should be some defined mapping between
> >the version
> >string and the number too I suppose.
>
> May we use something like Apache 2.0 :
>
> #define JK_MODULE_BASEPRODUCT "mod_jk"
> #define JK_MODULE_BASEREVISION "1.2.0-dev"
> #define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT "/"
> JK_MODULE_BASEREVISION
>
> #define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION
OK, but I was thinking of something numeric so it could easily be tested
at compile time, for example
#if defined(JK_VERSION) && JK_VERSION >= 1
... newer stuff ...
#endif
Strings are fine for user readable versioning, but hard to test at
compile time.
> But what do you means by users building from j-t-c or 3.2/3.3 ?
I think the two groups of people who will be interested in the source
for this (and other) connectors are:
a) People using one of the stable releases and wanting to use it with
the web server of their choice. They will have downloaded the
appropriate Tomcat source and may have grabbed the connector source from
either free.tagish.net or as part of the latest j-t-c release.
b) People working on the cutting edge j-t-c stuff who will be using the
latest versions of everything.
Ideally I'd like the source for the connector to be the same in either
case with conditional stuff to include functionality required by later
jk versions. I assume this would be useful for other connector
developers too.
As to the mapping between textual versions and numeric one way to do it
would be to reserve a certain number of digits for each part of the
version string so you'd have something like this:
1.0.1 ==> 10001
12.3.6 ==> 120306
which has the advantage that the numerical representation increases
monotonically and linearly with increases in textual version.
--
Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: [snip] > > #if defined(JK_VERSION) && JK_VERSION >= 1 > > ... newer stuff ... > > #endif > > Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-) Yup. > But it makes only sense if someone want to use a new module with a old core > code. > That means a protocol developed in 1.3.x could be used in 1.2.x. > Well could be nice, but difficult to handle. Backport a new protocol to an old > mod_jk! It makes sense for the kind of code I'm writing for the Domino connector though. The source supports/will support the latest protocols, but should still be buildable in cases where those protocols aren't available. At the moment I'm doing that with switches in a header that's local to the Domino connector, but it would be better if it was part of the jk/common source tree. > > b) People working on the cutting edge j-t-c stuff who will be using the > > latest versions of everything. > > ? That is CVS ? Yes. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: > > >OK, but I was thinking of something numeric so it could easily > >be tested > >at compile time, for example > > > >#if defined(JK_VERSION) && JK_VERSION >= 1 > >... newer stuff ... > >#endif > > > >Strings are fine for user readable versioning, but hard to test at > >compile time. > > I understand better there :=) > > Instead of avoid #ifdef/#endif in all the sources, we'll use the > CVS and make release. People who want STABLE release, will grab > a STABLE SNAPSHOT. JTC developpers will continue from CVS. OK, I get that but the Domino connector (in particular) is fairly immature -- it's quite likely that bugs will be found that would affect both people using stable Tomcat releases and those on the development track -- it would nice to fix any such bugs in a single source file. I suppose my requirement is unusual in that the Domino connector is available both as a retrofit for current Tomcat releases and as part of the j-t-c development track -- most other connector code will have been frozen as part of the relevant Tomcat release. If the versioning information isn't useful to other people I'll happily sort my particular requirements some other way, but I'm still inclined to use #if/#endif with some suitable swicth to bracket code that's only usable with the latest jk code. > >b) People working on the cutting edge j-t-c stuff who will be using the > >latest versions of everything. > > > >Ideally I'd like the source for the connector to be the same in either > >case with conditional stuff to include functionality required by later > >jk versions. I assume this would be useful for other connector > >developers too. > > Let be carefull here since having too much #ifdef/#endif will 'pollute' > the code. I'd like better have the EXPERIMENTAL switch as used I take the point about excessive #ifdef/#endif use -- I've seen plenty of C source code rendered practically unreadable in this way. I didn't know about the EXPERIMENTAL switch. What are the semantics of that? > >As to the mapping between textual versions and numeric one way to do it > >would be to reserve a certain number of digits for each part of the > >version string so you'd have something like this: > > > > 1.0.1 ==> 10001 > >12.3.6 ==> 120306 > > Ok -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: [snip] > As I said Domino need to be compiled. It could be marked as experimental > and only Domino users will have this warning. > > Why did we start j-t-c ? > > - a connector is mainly native code, how to build apxs or use autoconf > has nothing to do in tomcat dev/users list. I hope we could have a > separate dev/users lists later. > > - mod_jk is in TC 3.2 and 3.3. Thegeneral rules for TC 3.2 is to freeze > features and only correct bugs. > I add some features (AP2.0 support, TimeStamp in log, more robust handling > > of Tomcat failure or reboot) in the mod_jk for TC 3.3 and now the version > have diverged :! > Frankly having 2 code branchs to support is too just much job. > And then Kevin proposed the ajp13 port to TC 4.0, and so the need for > an independant repository > > - a connector could/should be independant from the core container > and we could have a different release rate. > > - j-t-c make possible reflexion on how to build connections > common to TC 3.2/3.3/4.0. See the excellent Coyote Proposal which live > now in jtc. I understand all that, but I'm not quite clear how that negates the possible advantage of making it possible to know at compile time which version of the jk code is being used, and in general if there is a version number at all defining a way of mapping it to a numeric constant also seems to be a good idea. Is your concern that, if we were to do that, the code would end up polluted with many conditionally compiled sections making testing and maintenance harder? If nothing else such a constant could be used to throw a compile time error if people attempt to build a connector using incompatible shared jk code. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: [snip] > >If nothing else such a constant could be used to throw a compile time > >error if people attempt to build a connector using incompatible shared > >jk code. > > Could you develop ? D'you mean could I write code that throws a compile time error? If so, it's just #if !defined(JK_MODULE_RELEASE) || JK_MODULE_RELEASE < REQUIRED #error "You need to have a later of the jk module. See source for details" #endif Is that what you meant or were you expecting something more glamorous? -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote:
[snip]
> > > But it makes only sense if someone want to use a new module with a old core
> > > code.
> > > That means a protocol developed in 1.3.x could be used in 1.2.x.
> > > Well could be nice, but difficult to handle. Backport a new protocol to an old
> > > mod_jk!
> >
> > It makes sense for the kind of code I'm writing for the Domino connector
> > though. The source supports/will support the latest protocols, but
> > should still be buildable in cases where those protocols aren't
> > available.
>
> The protocols should be in one place, the interface to a WebServer in another
> place.
> Domino is a WebServer so you should not care about the protocols but just
> provide the calls the core part needs, otherwise we will have a huge quantity of
> code copied in several places (Hard for maintenance).
> These version things should be only when making a backport of something new to a
> old version or when adding a code that cannot work in an old version.
I'm obviously missing the point here: in common with other connectors
the Domino connector makes calls /to/ the common jk code -- the external
interface it provides faces the other way -- towards Domino. That means
that as the interface to the jk code changes the Domino connector has to
change too. I want to be able to build a Domino connector for Tomcat 3.2
(for example) and a Domino connector for the current bleeding edge code
from the same source base. At the moment I can do that, but it involves
me having switches that are local to my source tree to select features
suitable for the current jk version. What I'm proposing is that the
version information should be exposed by the common jk code for /all/
connectors to use.
I'm categorically /not/ suggesting moving anything protocol specific
into the Domino connector, but the interface to the protocol code is
changing over time -- extra fields are being added and so on. I want the
Domino code to work with both the current jk stuff and the legacy 3.2
stuff is all.
Maybe a specific example will explain what I'm talking about. Here's a
bit of code that handles parsing the SSL keysize and passing it to the
jk stuff. The field ssl_key_size wasn't available until recently so the
I have to cope with that case too. Surely that isn't too evil is it?
#if FOR_TOMCAT >= TOMCAT400
/* Read the variable into a dummy variable: we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT("HTTPS_KEYSIZE", &dummy, 0);
if (workBuf[0] == '[')
s->ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
--
Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote:
[snip]
> > I'm categorically /not/ suggesting moving anything protocol specific
> > into the Domino connector, but the interface to the protocol code is
> > changing over time -- extra fields are being added and so on. I want the
> > Domino code to work with both the current jk stuff and the legacy 3.2
> > stuff is all.
>
> Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
> > Maybe a specific example will explain what I'm talking about. Here's a
> > bit of code that handles parsing the SSL keysize and passing it to the
> > jk stuff. The field ssl_key_size wasn't available until recently so the
> > I have to cope with that case too. Surely that isn't too evil is it?
> >
> >#if FOR_TOMCAT >= TOMCAT400
> > /* Read the variable into a dummy variable: we do this for the
> > side
> > * effect of reading it into workBuf.
> > */
> > GETVARIABLEINT("HTTPS_KEYSIZE", &dummy, 0);
> > if (workBuf[0] == '[')
> > s->ssl_key_size = atoi(workBuf+1);
> >#else
> > (void) dummy;
> >#endif
>
> Ok, I will put this version information in a commun include file named
> version.h. (On Monday!).
> Of course we will to have to document our internal API so that for each version
> of mod_jk the connectors could know the parameters and the structures used by
> the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new connector to
start with the source of an existing one -- I certainly did -- that
pretty much documents everything you need to know. Perhaps it would be
enough to nominate one connector (mod_jk I guess) as 'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
'localhost' v '127.0.0.1' in workers.properties
Has anyone else found that NT/2000 can't resolve 'localhost' in a line like worker.ajp13.host=localhost in conf/workers.properties? I had the problem when I was developing the domino connector and someone else has just reported the same problem to me. On the machine where I had the problem nslookup localhost was fine, and the problem persisted whether or not there was a localhost entry in hosts. I haven't tried other hostnames there. -- Andy Armstrong, Tagish
Re: Some clean up of the jakarta-tomcat tree for Tomcat 3.3
+1 (cleaning is good -- I love deleting stuff) Mike Anderson wrote: > > +1 > > Mike Anderson > > >>> [EMAIL PROTECTED] 06/19/01 03:49PM >>> > Hi, > > Does anyone have any objection to my deleting the following folders > from the jakarta-tomcat head: > > proposals/jasper34 > proposals/tomcat-4.0 > proposals/web-connector > src/jasper34 > > They all have projects elsewhere and, as Henri noted earlier, would make > a noticeable reduction in the size of the source file. > > Cheers, > Larry -- Andy Armstrong, Tagish
[Fwd: RE: 'localhost' v '127.0.0.1' in workers.properties]
This just in from Jay. I think he's probably right that it's 2000 only
-- I had thought I had the problem on NT too, but I can't now remember
the chronology of seeing the problem on a particular machine and
replacing NT with 2000 on the same machine -- it may be that I'd already
upgraded it to 2k when I saw the problem.
Original Message
Subject: RE: 'localhost' v '127.0.0.1' in workers.properties
Date: Tue, 19 Jun 2001 16:48:07 -0500
From: "Burgess, Jay" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
I've got problems sending to the newsgroup, but I thought I'd reply
personally, in case it helps.
Are you definitely having problems with both 2000 and NT, or maybe just
2000? I found a bug with InetAddress.getLocalHost() on WIN2000, and
maybe it's related to the way Tomcat works internally. The code below
shows it best:
try {
localHost = InetAddress.getLocalHost();
//
// Because of a bug on WIN 2000, getLocalHost() may
// return 0.0.0.0, for this machine. Clear localHost
// flag so we can try again below.
//
if (localHost.getHostAddress().equals("0.0.0.0")) {
localHost = null;
}
}
catch (UnknownHostException e) {
}
//
// If we haven't succeeded yet, try the loopback address.
//
if (localHost == null) {
try {
localHost = InetAddress.getByName("127.0.0.1");
}
catch (UnknownHostException e2){
throw (new Exception("Unable to resolve local host name."));
}
}
Jay
-- Jay Burgess
Delano Technology Corporation
mailto:[EMAIL PROTECTED]
(913) 438-9444 x154
-Original Message-
From: Andy Armstrong [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 19, 2001 4:39 PM
To: Tomcat Dev
Subject: 'localhost' v '127.0.0.1' in workers.properties
Has anyone else found that NT/2000 can't resolve 'localhost' in a line
like
worker.ajp13.host=localhost
in conf/workers.properties?
I had the problem when I was developing the domino connector and someone
else has just reported the same problem to me. On the machine where I
had the problem
nslookup localhost
was fine, and the problem persisted whether or not there was a localhost
entry in hosts. I haven't tried other hostnames there.
--
Andy Armstrong, Tagish
Re: JVM files on a standard linux box..
I've got the IBM JDK (2.13) on a machine here -- is that any use? "Pier P. Fumagalli" wrote: > > Can someone send me the output of a "find $JAVA_HOME -type f" from a Linux > environment, please? :) > > Cheers.. > > Pier -- Andy Armstrong, Tagish
Re: JVM files on a standard linux box..
zipped, attached. "Pier P. Fumagalli" wrote: > > Pier P. Fumagalli at [EMAIL PROTECTED] wrote: > > > Pier P. Fumagalli at [EMAIL PROTECTED] wrote: > > > >> Can someone send me the output of a "find $JAVA_HOME -type f" from a Linux > >> environment, please? :) > > > > Whops.. Better a "ls -laR" since it includes links and their targets... > > And also, since you're there already, your $MACHTYPE (in bash) or the output > of executing a random "config.guess" (you have it lying around somewhere :), > and the version of the JVM (do I have to tell you that you need to type > "java -version" to see it? :) :) :) > > Thanks a million :) > > Pier -- Andy Armstrong, Tagish javastuff.zip
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote:
>
> Hi,
>
> I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and
> JK_VERSION.
> The result is a file named common/version.h:
> +++
> #define JK_EXPOSED_VERSION "mod_jk/1.2.0-dev"
> #define JK_VERSION (((1) << 16) + ((2) << 8) +
> (0))
> +++
> Any comments? - Otherwise I will commit it tomorrow -
Decimal fields might be more appropriate to the ranges of numbers
expected, and I think Henri suggested an additional field for alpha,
beta etc.
How about
#define JK_DEV 0
#define JK_ALPHA1
#define JK_BETA 2
#define JK_RELEASE 99
#define JK_MKVER(major, minor, sequence, type) \
((major) * 100 + (minor) * 1 + (sequence) * 100 + (type))
#define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV)
>
> Cheers
>
> Jean-frederic
>
> Andy Armstrong wrote:
> >
> > jean-frederic clere wrote:
> > [snip]
> > > > I'm categorically /not/ suggesting moving anything protocol specific
> > > > into the Domino connector, but the interface to the protocol code is
> > > > changing over time -- extra fields are being added and so on. I want the
> > > > Domino code to work with both the current jk stuff and the legacy 3.2
> > > > stuff is all.
> > >
> > > Yep, that is because it is a developement version ;-)
> >
> > Yes, I got that ;-)
> >
> > > > Maybe a specific example will explain what I'm talking about. Here's a
> > > > bit of code that handles parsing the SSL keysize and passing it to the
> > > > jk stuff. The field ssl_key_size wasn't available until recently so the
> > > > I have to cope with that case too. Surely that isn't too evil is it?
> > > >
> > > >#if FOR_TOMCAT >= TOMCAT400
> > > > /* Read the variable into a dummy variable: we do this for the
> > > > side
> > > > * effect of reading it into workBuf.
> > > > */
> > > > GETVARIABLEINT("HTTPS_KEYSIZE", &dummy, 0);
> > > > if (workBuf[0] == '[')
> > > > s->ssl_key_size = atoi(workBuf+1);
> > > >#else
> > > > (void) dummy;
> > > >#endif
> > >
> > > Ok, I will put this version information in a commun include file named
> > > version.h. (On Monday!).
> > > Of course we will to have to document our internal API so that for each version
> > > of mod_jk the connectors could know the parameters and the structures used by
> > > the version.
> >
> > Thanks Jean. I don't think the documentation burden necessarily
> > increases that much. I expect most people writing a new connector to
> > start with the source of an existing one -- I certainly did -- that
> > pretty much documents everything you need to know. Perhaps it would be
> > enough to nominate one connector (mod_jk I guess) as 'state of the art'
> > and direct connector implementors to it.
> >
> > --
> > Andy Armstrong, Tagish
>
>
> dnl
> dnl Process this file with autoconf to produce a configure script
> dnl
> AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13 jfclere Exp $)dnl
>
> AC_PREREQ(2.13)
> AC_INIT(common/jk_ajp13.h)
> AC_CONFIG_AUX_DIR(scripts/build/unix)
>
> dnl package and version.
> PACKAGE=mod_jk
> VERMAJOR=1
> VERMINOR=2
> VERFIX=0
> dnl set VERISRELEASE to 1 when release (do not forget to commit!)
> VERISRELEASE=0
>
> VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
>
> AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
>
> dnl AM_PROG_LIBTOOL often causes problems.
> dnl I have solved them once using aclocal --acdir=/usr/local/share/aclocal/
> AM_PROG_LIBTOOL
>
> AC_PROG_CC
>
> AC_PROG_LD
>
> AC_PATH_PROG(TEST,test,$PATH)dnl
> AC_SUBST(TEST)
>
> AC_PATH_PROG(RM,rm,$PATH)dnl
> AC_SUBST(RM)
>
> AC_PATH_PROG(GREP,grep,$PATH)dnl
> AC_SUBST(GREP)
>
> AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
> AC_SUBST(ECHO)
>
> AC_PATH_PROG(SED,sed,$PATH)dnl
> AC_SUBST(SED)
>
> AC_PATH_PROG(CP,cp,$PATH)dnl
> AC_SUBST(CP)
>
> AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
> AC_SUBST(MKDIR)
>
> dnl prepare the string and value for mod_jk version logic
> JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
> if ${TEST} ${VERISRELEASE} -eq 0 ; then
> JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
> fi
>
> AC_SUBST(JK_EXPOSED_VERSION)
> AC_SUBST(PACKAGE)
> AC_SUBST(VERSION)
> AC_SUB
Re: FORM-based authentication idea
Michael Jennings wrote: > Hi everyone, > > I just wanted to bounce an idea off of everyone. In tomcat, when one > specifies form-based > authentication you have to tell tomcat which page is the login page. This is > done > via the context's web.xml file by setting the property > under the > section. When a user hits a protected URL in a context, if they are not > already authenticated, the original > request page is saved in their session, then they are redirected to the > login page, if the login > succeeds, they are redirected to their original request page. > A problem happens however, when a user requests JUST the login page. After > logging in, > there is nowhere to redirect the user to since their is no original request > saved in the session. > > What if there was a concept of a "default login target"? so that when a user > requests just the > designated login page, if they are already authenticated, they get > redirected to the "default login target" > page. Similarly, if a user requests the login page but they are not > authenticated, upon logging in they > would get redirected to the "default login target". > > I realize that this is probably not in the JSP spec, but something like this > seems to be necessary. > The alternative is to look for the presence of a session variable called > "tomcat.auth.originalLocation" > and set up a default from within the login page if that session variable > isn't there. > > Any thoughts? Why not supply the default in a hidden field on the login page? -- Andy Armstrong, Tagish
Re: FORM-based authentication idea
Michael Jennings wrote: >>>The alternative is to look for the presence of a session variable called >>>"tomcat.auth.originalLocation" >>>and set up a default from within the login page if that session variable >>>isn't there. >>> >>>Any thoughts? >>> >> >>Why not supply the default in a hidden field on the login page? >> > > wouldn't that just overwrite the session variable > "tomcat.auth.originalLocation" even > if there was stuff in it? Sorry. Stupid head engaged. I've just re-read your post. Please carry on without me ;-) -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: > > > > Decimal fields might be more appropriate to the ranges of numbers > > expected, and I think Henri suggested an additional field for alpha, > > beta etc. > > I have VERISRELEASE to mark that it is a developement version, I am not sure we > need the beta number. I would prefer to do it like httpd. > But will this be ok? > mod_jk/1.2.0-beta-01 (for the first beta) > mod_jk/1.2.0 (for the release version). > > > > > How about > > > > #define JK_DEV 0 > > #define JK_ALPHA1 > > #define JK_BETA 2 > > #define JK_RELEASE 99 > > #define JK_MKVER(major, minor, sequence, type) \ > > ((major) * 100 + (minor) * 1 + (sequence) * 100 + (type)) > > > > #define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV) > What about: > #ifdef RELEASE > #define JK_VERSION JK_MKVER(1, 2, 0, 99) > #else > #define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA) > > Hex is a copy + paste from Linux sources. Dec is more easy? - No problem - But I > like to write 0x010200 and 0x110200 it is easy to see than 10200 and 110200. Fine, +1 ;-) -- Andy Armstrong, Tagish
Any reason why...
...these two lines at around 1110 in jk_ajp_common.c int port = jk_get_worker_port(props, p->name, port); char *host = jk_get_worker_host(props, p->name, host); use unitialised values for port and host. Anyone mind if I change them to int port = jk_get_worker_port(props, p->name, -1); char *host = jk_get_worker_host(props, p->name, NULL); ? -- Andy Armstrong, Tagish
Re: Any reason why...
GOMEZ Henri wrote: > > >...these two lines at around 1110 in jk_ajp_common.c > > > > int port = jk_get_worker_port(props, p->name, port); > > char *host = jk_get_worker_host(props, p->name, host); > > > >use unitialised values for port and host. Anyone mind if I change them > >to > > > > int port = jk_get_worker_port(props, p->name, -1); > > char *host = jk_get_worker_host(props, p->name, NULL); > > > > The value are initialised some lines before depending AJP13/AJP14 :) They can't be initialised before -- they're actually declared in the fragment I quote -- they don't exist before here. -- Andy Armstrong, Tagish
Re: Any reason why...
Andy Armstrong wrote: > > GOMEZ Henri wrote: > > > > >...these two lines at around 1110 in jk_ajp_common.c > > > > > > int port = jk_get_worker_port(props, p->name, port); > > > char *host = jk_get_worker_host(props, p->name, host); > > > > > >use unitialised values for port and host. Anyone mind if I change them > > >to > > > > > > int port = jk_get_worker_port(props, p->name, -1); > > > char *host = jk_get_worker_host(props, p->name, NULL); > > > > > > > The value are initialised some lines before depending AJP13/AJP14 :) > > They can't be initialised before -- they're actually declared in the > fragment I quote -- they don't exist before here. Ah. I see the real problem -- they're declared at the start of the function and again here. Unfortunately the values that are in scope when jk_get_worker_port() and jk_get_worker_host() are called are the new, uninitialised variables rather than the ones declared at the top of the function. Those two lines should change to port = jk_get_worker_port(props, p->name, port); host = jk_get_worker_host(props, p->name, host); -- Andy Armstrong, Tagish
Re: Any reason why...
GOMEZ Henri wrote: > > +1, I'll correct now. > > I'll have a huge commit to send today, > AJP14 login feature is quasi finished :) Quasi? :-) -- Andy Armstrong, Tagish
Re: Any reason why...
GOMEZ Henri wrote: > > >> +1, I'll correct now. > >> > >> I'll have a huge commit to send today, > >> AJP14 login feature is quasi finished :) > > > >Quasi? :-) > > Quasi (oups french word). C'est la meme en Anglais. > native and java parts of AJP14 login are working now. > We need now to add some stuff to set the secret word > and also grab some entropy. > > I'll commit my AJP13/AJP14 today in TC33 sub dir of > J-T-C... -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
One small point comes to light now you've released this: version.h is quite a common thing to have on your include path; certainly under MS operating systems there tends to be a version.h already on the include path which may cause confusion. Any reason not to call it jk_version.h? jean-frederic clere wrote: > > Andy Armstrong wrote: > > > > jean-frederic clere wrote: > > > > > > Hi, > > > > > > I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and > > > JK_VERSION. > > > The result is a file named common/version.h: > > > +++ > > > #define JK_EXPOSED_VERSION "mod_jk/1.2.0-dev" > > > #define JK_VERSION (((1) << 16) + ((2) << 8) + > > > (0)) > > > +++ > > > Any comments? - Otherwise I will commit it tomorrow - -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: > > GOMEZ Henri wrote: > > > > >One small point comes to light now you've released this: version.h is > > >quite a common thing to have on your include path; certainly under MS > > >operating systems there tends to be a version.h already on the include > > >path which may cause confusion. Any reason not to call it jk_version.h? > > > > +1 for jk_version.h > > > > Sure it will take less than 30ms to JF :) > > Done, it was more 3 mn and 3 commits... I saw them ;-) Thanks -- Andy Armstrong, Tagish
Re: [jtc] tabs policy??
Here we go... ;-) I like tabs set to four spaces, tabs in source rather than spaces and opening braces on a new line. How evil does that make me? Actually I was just wondering the other day how easy it would be to do smart de-tabbing on source -- i.e. how easily can you infer the original tab size given some arbitrary source file. Of course it's easy enough for a human, but how much syntax awareness would you need to do it automagically? kevin seguin wrote: > > so, is there a tabs policy in jakarta? like the number of spaces per > tab (4 vs. 8), of no tabs in source code? i ask because i just got the > latest jtc source, and when i open up some of the files in emacs (in > which i have tab width set to 8 spaces), some lines are indented 4 > spaces, and some 8. what it looks like is someone used an editor with > tabs configured to be 4 spaces, but insert tab characters rather than > spaces. anyway, it's quite unreadable, so that why i ask ;) (i hope > this doesn't start a war ;-)) -- Andy Armstrong, Tagish
Re: [jtc] tabs policy??
[EMAIL PROTECTED] wrote: > > On Sat, 23 Jun 2001, Andy Armstrong wrote: > > > Here we go... ;-) > > > > I like tabs set to four spaces, tabs in source rather than spaces and > > opening braces on a new line. How evil does that make me? > > Not necesarily evil, I also like the week with 3 days ( 1 for work, 2 for > weekend ), tabs in source, lines below 80 chars, and consistent > indentation. > > The only problem is that all the code in jakarta-tomcat repository is > using the old eight space tab, with 4 space indentation. Is there then a recommended tool for reformatting Java source to the required standard? I use indent for C and C++ -- is there an equivalent for Java? > ( xml projects seem to prefer a 2 space indentation ) > > > Actually I was just wondering the other day how easy it would be to do > > smart de-tabbing on source -- i.e. how easily can you infer the original > > tab size given some arbitrary source file. Of course it's easy enough > > for a human, but how much syntax awareness would you need to do it > > automagically? > > It's much easier to set the tab consistenly. The "8" has been used in > typewriters and most computers ( until recent editors decided it'll be fun > to allow you to configure that, and also what character coresponds to the > "0x41" byte ). You're being satirical now aren't you ;-) -- Andy Armstrong, Tagish
Re: [jtc] anybody build iis plugin lately
kevin seguin wrote: > > when i try to use jtc/jk/native/iis/isapi.ds[wp], i get errors that look > like this: > > The file > g:\dev\jakarta\jakarta-tomcat-connectors\jk\native\iis\isapi.dsp has > been modified and cannot be loaded as a Developer Studio project. I haven't noticed that with IIS, but I got the same thing when I hand edited the dsapi.dsp file for the Domino connector. It seems that, although Microsoft have implemented a textual file format for the Visual Studio project files if you actually edit them outside Visual Studio something breaks! This is presumably to protect us from ourselves. Please don't get me started... I've just verified here that some types of edit are OK on dsp files so I'm not sure what triggers this message. In the absence of anyone else volunteering I'd be happy to have a look at this -- I've got several IIS boxes (for my sins) on which I can test it. > ideas?? > > by the way, it'd be nice to have an nmake file here... if someone could > generate one :) I can probably do that too unless anyone else is a more appropriate volunteer. -- Andy Armstrong, Tagish
Re: [jtc] anybody build iis plugin lately
kevin seguin wrote: > > I can probably do that too unless anyone else is a more appropriate > > volunteer. > > > > i've also be tossing around the idea of a plain old gnu makefile too... > but i suppose an nmake file would be better for most people. if the dsp > works for you, andy, you should be able to simply export isapi.mak and > check that in. I haven't looked at it, but I'll have a go at it later tonight. -- Andy Armstrong, Tagish
Re: [jtc] anybody build iis plugin lately
I've fixed isapi.dsp and added an nmake Makefile (isapi.mak). I also had to fix a vouple of syntax errors in jk_isapi_plugin.c that I think were changes that Henri made in an attempt to bring the IIS connector in line with the latest jk code. One of the changes Henri had made was similar to a change he made in the Domino connector. For now I've commented out the lines in question, which I don't think will break anything, but to incorporate that change fully in the Domino connector I had to make some non trivial changes to the code to defer initialisation of the worker map until the first request is seen by the connector. I think I'd have to do the same thing with the IIS connector to make it work (basically the problem is that Henri's code is looking for the name of the server which isn't available either from IIS or from Domino until you're inside a real request). I can go ahead and make the necessary changes, but I'm concious that I might be stepping on someone else's toes given that I'm not really the maintainer of the IIS connector. Should I go ahead and do it? Andy Armstrong wrote: > > kevin seguin wrote: > > > > I can probably do that too unless anyone else is a more appropriate > > > volunteer. > > > > > > > i've also be tossing around the idea of a plain old gnu makefile too... > > but i suppose an nmake file would be better for most people. if the dsp > > works for you, andy, you should be able to simply export isapi.mak and > > check that in. > > I haven't looked at it, but I'll have a go at it later tonight. > > -- > Andy Armstrong, Tagish -- Andy Armstrong, Tagish
Anyone know why the ISAPI redirector works how it does?
I've been looking at the source of the ISAPI redirector (initially to get it to build again -- it seems to have broken), and wondering why it works the way it does. It provides both an HttpFilterProc and an HttpExtensionProc. The HttpFilterProc looks for incoming requests that are elligable to be handled by Tomcat and, if it finds one, it rewrites the request so that it will be passed to the HttpExtensionProc for processing. From a cursory glance at the ISAPI documentation it seems that this could all be handled in HttpFilterProc. Does anyone know what I'm missing? If there isn't a clear reason why it's implemented like this I might try and build a new ISAPI filter that works the same way as the Domino DSAPI filter. It should make request handling slightly faster, simplify the code and might make it possible to have some source in common between the Domino and IIS redirectors. -- Andy Armstrong, Tagish
Re: [jtc] anybody build iis plugin lately
kevin seguin wrote: > > > > > I've fixed isapi.dsp and added an nmake Makefile (isapi.mak). I also had > > to fix a vouple of syntax errors in jk_isapi_plugin.c that I think were > > changes that Henri made in an attempt to bring the IIS connector in line > > with the latest jk code. > > > > One of the changes Henri had made was similar to a change he made in the > > Domino connector. For now I've commented out the lines in question, > > which I don't think will break anything, but to incorporate that change > > fully in the Domino connector I had to make some non trivial changes to > > the code to defer initialisation of the worker map until the first > > request is seen by the connector. I think I'd have to do the same thing > > with the IIS connector to make it work (basically the problem is that > > Henri's code is looking for the name of the server which isn't available > > either from IIS or from Domino until you're inside a real request). > > > > I can go ahead and make the necessary changes, but I'm concious that I > > might be stepping on someone else's toes given that I'm not really the > > maintainer of the IIS connector. Should I go ahead and do it? > > > > i haven't seen much movement in the iis connector for a while, and i > have no idea whose baby it is :) i'd say go for it if you have some > ideas to improve/fix it. > people who are interested will see your changes and can view the diffs > and if they have problems, they can speak up ;-) Yup I think I'll give it a bash. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
kevin seguin wrote: > > well, i've never even looked at the iis connector, and i am by no means > an isapi expert, but what you describe does sound odd... i was under > the impression that the isapi filter was doing all of the work. didn't > know there was an extension involved as well. It's not a big deal -- just two entry points into the same DLL, so you wouldn't notice from outside, but it does seem a bit odd. > perhaps you can, instead of mucking with the existing iis connector, > just create a new one that uses only HttpFilterProc. that'd be cool > with me :) I'll give it a go. It might be next week unless I go to the office and grab a box to make into an IIS server for home. Still, what else are weekends for. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Yes, but at the moment every IIS request gets passed to the filter chain /and/ to the extension. What I'm proposing /must/ be faster. Please explain your objection. "Ignacio J. Ortega" wrote: > > I think this was done this way because every request on a IIS server > pass the entire Filter Chain, so a request that takes longer to be > served simply occupies the server thread more than necesssary , > > I'm -1 for this change ... > > Saludos , > Ignacio J. Ortega > > > -Mensaje original- > > De: Andy Armstrong [mailto:[EMAIL PROTECTED]] > > Enviado el: sábado 23 de junio de 2001 20:02 > > Para: Tomcat Dev > > Cc: Gal Shachor > > Asunto: Anyone know why the ISAPI redirector works how it does? > > > > > > I've been looking at the source of the ISAPI redirector (initially to > > get it to build again -- it seems to have broken), and > > wondering why it > > works the way it does. > > > > It provides both an HttpFilterProc and an HttpExtensionProc. The > > HttpFilterProc looks for incoming requests that are elligable to be > > handled by Tomcat and, if it finds one, it rewrites the > > request so that > > it will be passed to the HttpExtensionProc for processing. From a > > cursory glance at the ISAPI documentation it seems that this could all > > be handled in HttpFilterProc. Does anyone know what I'm missing? > > > > If there isn't a clear reason why it's implemented like this > > I might try > > and build a new ISAPI filter that works the same way as the > > Domino DSAPI > > filter. It should make request handling slightly faster, simplify the > > code and might make it possible to have some source in common between > > the Domino and IIS redirectors. > > > > -- > > Andy Armstrong, Tagish > > -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
"Ignacio J. Ortega" wrote: > > AFAIK only the request that need to be served by the Extension , that is > request that match the config present in UWM.P file are routed to the > extension , that runs in other priority thread, if you serve the Tomcat > request directly from the filter therad you are blocking the filter > thread in Tomcat.., and i repeat *ALL* the request served by an IIS > server are passed to ALL the filters..not only the Tomcat one.. so if > the ISAPI extension were working like you are proposing you are blocking > the main server thread waiting for tomcat to serve the request, many > unrelated request will be slowed appreciably and the overall capacity of > the server will be greatly impacted... Thanks Ignacio; I understand what you're saying now. If all the filters run in the same thread that implies that IIS handles all its requests in a single thread, which seems unlikely, but of course I could be wrong. > I think there are good reasons to keep things as they are now...i dont > found a good reason , apart from code complexity , to do what you are > proposing ..but i'm not a ISAPI expert...I could be wrong.. i'm only > repeating to you the reasons Gal said to my many time ago.. you can > consult archives about May past year .. (i'm doing so now i wil try to > document it ) I'd be interested in anything you can find. I don't expect it to involve too much work, so I'm going to build it and do some performance testing to find out if there are any problems. From what you're saying the performance problem to look for would be lots of Tomcat requests having an adverse affect on the performance for non-Tomcat IIS requests. > But i'm open to test and help in what you are proposing .. i'm not > trying to block you from doing so .. i'm only trying to left the old > code as it is, you can do what you are proposing in another directory in > jtc and call it with a funny name ( IISTHAR ? :), and we can test and > use it as an alternative .. if everything works as you expect .. good .. > if not we still have that good old code ... users need a escape way from > developers. :) I'm putting it in a directory called 'isapi' and leaving 'iis' intact. In any case I have some more work to do on the existing IIS redirector to make it work properly with the latest jk code, but that's a separate issue, and I won't do anything too scary to the current IIS code. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
"Ignacio J. Ortega" wrote: > > Hola Andy: > > > > > Thanks Ignacio; I understand what you're saying now. If all > > the filters > > run in the same thread that implies that IIS handles all its > > requests in > > a single thread, which seems unlikely, but of course I could be wrong. > > > > What i'm trying to say is not that, is evident that IIS does not serve > all the request from the same thread .. only that every filter is called > in ALL the IIS request.. ergo if you start to block server threads in > tomcat requests you are pushing innecesarily the IIS server... at least > the thread pool that is used to serve requests.. I would have thought that IIS's threading model was designed to handle that. There must be other cases where an in-process request can stall for a significant period of time; can it really be the case that this causes problems for the server as a whole? In any case I suspect I am about to find out ;-) > > I'd be interested in anything you can find. I don't expect it > > to involve > > too much work, so I'm going to build it and do some > > performance testing > > to find out if there are any problems. From what you're saying the > > performance problem to look for would be lots of Tomcat > > requests having > > an adverse affect on the performance for non-Tomcat IIS requests. > > > > This is the bad behaviour the filter+Extension mix is trying to avoid.. I understand that. What I'm saying is that if I can detect any performance degradation for non-Tomcat requests I will have failed. > > I'm putting it in a directory called 'isapi' and leaving 'iis' intact. > > In any case I have some more work to do on the existing IIS redirector > > to make it work properly with the latest jk code, but that's > > a separate > > issue, and I won't do anything too scary to the current IIS code. > > > > Thanks, this is was my -1 was intended for.. So, +1 for trying a different approach without breaking what's already there? -- Andy Armstrong, Tagish
Re: [jtc] anybody build iis plugin lately
GOMEZ Henri wrote: > > >I've fixed isapi.dsp and added an nmake Makefile (isapi.mak). > >I also had > >to fix a vouple of syntax errors in jk_isapi_plugin.c that I think were > >changes that Henri made in an attempt to bring the IIS > >connector in line > >with the latest jk code. > > Right and in the IIS case I still didn't tried to rebuilt on my W2K > machine. But I've got a VC6 now loaded and if you put a nmake I could > test before commit :) I'm building an NT test machine here so I can test the IIS stuff before I commit it here. > >One of the changes Henri had made was similar to a change he > >made in the > >Domino connector. For now I've commented out the lines in question, > >which I don't think will break anything, but to incorporate that change > >fully in the Domino connector I had to make some non trivial changes to > >the code to defer initialisation of the worker map until the first > >request is seen by the connector. I think I'd have to do the same thing > >with the IIS connector to make it work (basically the problem is that > >Henri's code is looking for the name of the server which isn't > >available > >either from IIS or from Domino until you're inside a real request). > > I've update worker open() proc to have this information at init/validate > time. If we couldn't have this information at init time, we'll have a > problem with autoconf support since we NEED to log to servlet-engine > BEFORE processing any REQUEST since we MUST GRAB all the URI the > remote tomcat could handle For the Domino connector (which sees /every/ request the server gets remember) I do the init in the first request the filter sees, which is early enough to catch even the case where that first request should be routed to Tomcat. I don't think this should make any difference from Tomcat's point of view. The only reason for doing it this way is to be able to fill in worker_env.server_name. The name of the server isn't available either with IIS or Domino until the first request passes through the filter. > Thanks for any information on init stage !!! -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
OK, I've done a bit more digging. From what I've read about ISAPI it seems that thread exhaustion can be a problem both for filters /and/ extensions[1]. The advice on this page /is/ to avoid filters, but I assume that's just because filters will be invoked for every request -- unfortunately that's unavoidable for the Tomcat connector because we need to see every request in case Tomcat can handle it. So, currently we have a filter that delegates to an extension, both in the same DLL. If extensions execute in a different thread pool from filters it's possible that this helps performance, but it's not clear from the MS documentation that this is the case. What MS do specifically say is that, in cases where a filter or extension may block for any length of time the blocking part should run in a seperate thread so that IIS doesn't get thread starved -- this makes sense, and suggests that the correct performance oriented architecture for the IIS connector should be a filter (with an optimized 'straight throw' path) which delegates Tomcat requests not to an ISAPI extension but to a worker thread taken from a pool that is internal to the connector. This is more complex than what I had in mind, but I'm prepared to give it a try. Before I do, does anyone have any empirical evidence about what works best with IIS? [1] http://msdn.microsoft.com/library/default.asp? \ url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp "Ignacio J. Ortega" wrote: > > > So, +1 for trying a different approach without breaking what's already > > there? > > My swahili is at times hard to understand :)) > > Yes i'm +1 on trying what you are proposing in another place on jtc tree > and leaving iis as it is now.. I'm really courious about what you find > .. every bit of performance is welcomed ever .. so if there is a bit > waiting for tomcat lets catch it ..:)) > > i recall that i'd found the same architecture in other ISAPI modules > like resin... > > Saludos , > Ignacio J. Ortega > > > > > -- > > Andy Armstrong, Tagish > > -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Marc Saegesser wrote: > > I don't have any problem with the experiment, and couldn't stop the > *experiment* even if I wanted to. By all means, scratch the itch. > > I am curious though, what it takes to cause the thread starvation in a > normal environment (what ever that is). Adding the complexity of a thread > pool will slow down processing by some amount in the non-starved case. For > the case where thread starvation is occurring, it stands to reason that we > have *lots* of requests and lots more requests and threads than processors > to throwing more threads probably won't improve the throughput for Tomcat > requests. It might improve the throughput for the static pages served by > IIS directly since those requests won't be stuck behind potentially long > running servlet requests, but then only if those long running threads are > blocked on I/O. Basically, throwing threads at a problem usually doesn't do > much for performance. > > Still, I'd be interested to see how this experiment effects performance. Yeah, well I'm not entirely convinced myself. I'm guessing, from what I've read on the MS site, that IIS actually runs with quite a small, fixed size, pool of threads and relies on its ability to serve static content very quickly to ensure that this is adequate. As soon as you start executing (relatively) slow requests in threads from this pool you end up with most of the threads blocked. That's my reading anyway -- I might do some experiments to find out how many distinct threads IIS is using before I do anything else. I am prepared to believe that if IIS is tightly optimized for static content and runs with a thread pool that is only just large enough for its normal needs that this might be the case, though, like you, I'm a little sceptical. > > Marc Saegesser > > > -Original Message- > > From: Andy Armstrong [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, June 24, 2001 7:11 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Anyone know why the ISAPI redirector works how it does? > > > > > > OK, I've done a bit more digging. From what I've read about ISAPI it > > seems that thread exhaustion can be a problem both for filters /and/ > > extensions[1]. The advice on this page /is/ to avoid filters, but I > > assume that's just because filters will be invoked for every request -- > > unfortunately that's unavoidable for the Tomcat connector because we > > need to see every request in case Tomcat can handle it. > > > > So, currently we have a filter that delegates to an extension, both in > > the same DLL. If extensions execute in a different thread pool from > > filters it's possible that this helps performance, but it's not clear > > from the MS documentation that this is the case. What MS do specifically > > say is that, in cases where a filter or extension may block for any > > length of time the blocking part should run in a seperate thread so that > > IIS doesn't get thread starved -- this makes sense, and suggests that > > the correct performance oriented architecture for the IIS connector > > should be a filter (with an optimized 'straight throw' path) which > > delegates Tomcat requests not to an ISAPI extension but to a worker > > thread taken from a pool that is internal to the connector. > > > > This is more complex than what I had in mind, but I'm prepared to give > > it a try. Before I do, does anyone have any empirical evidence about > > what works best with IIS? > > > > [1] http://msdn.microsoft.com/library/default.asp? \ > > url=/library/en-us/iisref/html/psdk/asp/perf4vsj.asp > > > > "Ignacio J. Ortega" wrote: > > > > > > > So, +1 for trying a different approach without breaking what's already > > > > there? > > > > > > My swahili is at times hard to understand :)) > > > > > > Yes i'm +1 on trying what you are proposing in another place on jtc tree > > > and leaving iis as it is now.. I'm really courious about what you find > > > .. every bit of performance is welcomed ever .. so if there is a bit > > > waiting for tomcat lets catch it ..:)) > > > > > > i recall that i'd found the same architecture in other ISAPI modules > > > like resin... > > > > > > Saludos , > > > Ignacio J. Ortega > > > > > > > > > > > -- > > > > Andy Armstrong, Tagish > > > > > > > > -- > > Andy Armstrong, Tagish -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
(sorry to follow myself up, but I've just found some more evidence about this) Andy Armstrong wrote: [snip] > > Yeah, well I'm not entirely convinced myself. I'm guessing, from what > I've read on the MS site, that IIS actually runs with quite a small, > fixed size, pool of threads and relies on its ability to serve static > content very quickly to ensure that this is adequate. As soon as you > start executing (relatively) slow requests in threads from this pool you > end up with most of the threads blocked. That's my reading anyway -- I > might do some experiments to find out how many distinct threads IIS is > using before I do anything else. > > I am prepared to believe that if IIS is tightly optimized for static > content and runs with a thread pool that is only just large enough for > its normal needs that this might be the case, though, like you, I'm a > little sceptical. Hmm. Well, surprisingly, according to this page[1] the default thread pool size for IIS is 10 times the number of processors and the server doesn't do anything adaptive with this number though it can be changed in the registry. This number does seem surprisingly low -- I can see how, in cases where the server was handling a lot of traffic of which some was being delegated to Tomcat there could be starvation. [1] http://www.google.com/search?q=cache:2jnr72XWvVU: \ msdn.microsoft.com/componentresources/html/articles \ /ta/ta_030.asp+iis+thread+pool+size&hl=en -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Marc Saegesser wrote: > > Again, threads don't improve performance, in fact they degrade performance > and on some platforms (namely, Windows) they can degrade performance very > quickly. Context switching between threads on Win32 is *really, really* > expensive (several hundred instructions in kernel space). Without > processors to back up the threads you can just end up wasting cycles > switching between threads and not accomplishing real work. Yes, understood. What surprised me was that it wouldn't dynamically throw new threads in the pool in the specific case where lots of threads where blocked which is what I assume happens quite a lot in a typical webserver <--> Tomcat interaction. Extra threads are only compute intensive when they get scheduled -- if most of them are sleeping then they're relatively cheap. Of course it turns out, as I read more, than IIS /can/ dynamically throw new threads in the pool in that eventuality. I think the only way to bottom this out is for me to write some code to test it, but I do understand that more threads != more speed in the general case. I'm still unconvinced though that the current filter + extension connector architecture is likely to be any better than a filter only implementation on the basis of what I've read about the internals of IIS. Time to stop talking and start experimenting I think ;-) -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
[EMAIL PROTECTED] wrote: > > Hi, I'm a new, late starter on this thread... > > My understanding is that IIS runs about 15 threads and for filters it runs it on one >of the threads, and for extension procs it uses the model defined in the application >setup of the virtual directory (Low [iis thread], Medium [pool thread], High >[isolated, app specific threads]). From what I can see of the Tomcat code, because >it has the Filter and Extension call backs in the same DLL it will always default to >Low (ie. as a filter). > > My understanding is that the best way to do the IIS/Tomcat integration is tricky - >but worth it. > > You would: > > o Have a separate filter to do the absolute minimum to check whether the URI is for >a Servlet - this would run on the IIS thread and then direct it to the Exension Proc. > o Have a separate DLL implementing the extension proc and have it run in the High >protection model. > o In the extension proc you would implement the asynch call back model where in >simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own >pool of threads to process the request by releasing the IIS thread and holding a ref >to a callback sig function so that when Tomcat has finished it sigs back to IIS that >it is complete and IIS then takes over again. This is the way ASP works and makes >sure you never get the dreaded "Server Busy" response back to the client because the >scarce IIS threads are exhausted. > > Apart from that, I haven't thought about it ;-) Not much ;-) I'm surprised that it can choose which thread to use for filters -- is it not the case that filters are just called in the context of whichever thread is handling a particular request? I seem to be committed now to finding out empirically what's going on inside IIS and which approach will yield the best performance, both for requests delegated to Tomcat and for everything else the server's doing. I'll be sure to try the approach you suggest -- it certainly sounds reasonable. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
Thanks Pete -- I'll watch for that. I've already had some experience of this sort of thing. Not nice. [EMAIL PROTECTED] wrote: > > You're right - it can't for filters - hence why it defaults to "Low". > > A word of advice, if you are doing this on Win2K you also get into some hairy >security issues and what is happenning under IUSR, IWAM etc. accounts. Keep it in >mind if you start to see some strange behaviour in you tests. > > Cheers...Pete > > -Original Message- > From: Andy Armstrong [mailto:[EMAIL PROTECTED]] > Sent: Monday,25 June 2001 8:04 > To: [EMAIL PROTECTED] > Subject: Re: Anyone know why the ISAPI redirector works how it does? > > [EMAIL PROTECTED] wrote: > > > > Hi, I'm a new, late starter on this thread... > > > > My understanding is that IIS runs about 15 threads and for filters it runs it on >one of the threads, and for extension procs it uses the model defined in the >application setup of the virtual directory (Low [iis thread], Medium [pool thread], >High [isolated, app specific threads]). From what I can see of the Tomcat code, >because it has the Filter and Extension call backs in the same DLL it will always >default to Low (ie. as a filter). > > > > My understanding is that the best way to do the IIS/Tomcat integration is tricky - >but worth it. > > > > You would: > > > > o Have a separate filter to do the absolute minimum to check whether the URI is >for a Servlet - this would run on the IIS thread and then direct it to the Exension >Proc. > > o Have a separate DLL implementing the extension proc and have it run in the High >protection model. > > o In the extension proc you would implement the asynch call back model where in >simple terms IIS passes the call to the Tomcat DLL, the Tomcat DLL then has its own >pool of threads to process the request by releasing the IIS thread and holding a ref >to a callback sig function so that when Tomcat has finished it sigs back to IIS that >it is complete and IIS then takes over again. This is the way ASP works and makes >sure you never get the dreaded "Server Busy" response back to the client because the >scarce IIS threads are exhausted. > > > > Apart from that, I haven't thought about it ;-) > > Not much ;-) > > I'm surprised that it can choose which thread to use for filters -- is > it not the case that filters are just called in the context of whichever > thread is handling a particular request? > > I seem to be committed now to finding out empirically what's going on > inside IIS and which approach will yield the best performance, both for > requests delegated to Tomcat and for everything else the server's doing. > > I'll be sure to try the approach you suggest -- it certainly sounds > reasonable. > > -- > Andy Armstrong, Tagish > > ------ > This message and any attachment is confidential and may be privileged or otherwise >protected from disclosure. If you have received it by mistake please let us know by >reply and then delete it from your system; you should not copy the message or >disclose its contents to anyone. -- Andy Armstrong, Tagish
Re: Anyone know why the ISAPI redirector works how it does?
[EMAIL PROTECTED] wrote: > > That would work in the first instance. I also have some metabase management code to >set this up properly for an auto installer - let me know if you want it. > Cheers...Pete I'm sure that'll be useful -- the setup could usefully be more automated. -- Andy Armstrong, Tagish
Re: [jtc - jk] jk_version.h
+1 jean-frederic clere wrote: > > GOMEZ Henri wrote: > > > > >so, forgive me if this is a stupid question, but... how is jk_version.h > > >generated on windows? do i need to install cygwin stuff and run > > >buildconf.sh/configure? > > > > Good point Kevin :) > > > > May be just by editing it ;) > > Should move the logic of version out from configure and to jk_version.h (Any > way I was not very happy to have to commit configure.in when the j-t-c version > changes). -- Andy Armstrong, Tagish
Re: [jtc - jk] jk_version.h
Would you like me to commit it now? jean-frederic clere wrote: > > Andy Armstrong wrote: > > > > +1 > > > > jean-frederic clere wrote: > > > > > > GOMEZ Henri wrote: > > > > > > > > >so, forgive me if this is a stupid question, but... how is jk_version.h > > > > >generated on windows? do i need to install cygwin stuff and run > > > > >buildconf.sh/configure? > > > > > > > > Good point Kevin :) > > > > > > > > May be just by editing it ;) > > > > > > Should move the logic of version out from configure and to jk_version.h (Any > > > way I was not very happy to have to commit configure.in when the j-t-c version > > > changes). > > > > -- > > Andy Armstrong, Tagish > > I have prepared a jk_version.h. I will commit it tomorrow (If I have time). > Find it enclosed. > > > /* common/jk_version.h */ > > /** START OF AREA TO MODIFY BEFORE RELEASING */ > #define JK_VERMAJOR 1 > #define JK_VERMINOR 2 > #define JK_VERFIX 0 > #define JK_VERSTRING"1.2.0" > > /* Beta number */ > #define JK_VERBETA 1 > #define JK_BETASTRING "1" > /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ > #define JK_VERISRELEASE 1 > /** END OF AREA TO MODIFY BEFORE RELEASING */ > > #define PACKAGE "mod_jk/" > /* Build JK_EXPOSED_VERSION and JK_VERSION */ > #define JK_EXPOSED_VERSION_INT PACKAGE JK_VERSTRING > > #if ( JK_VERISRELEASE == 1 ) > #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT > #undef JK_VERBETA > #define JK_VERBETA 255 > #else > #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-beta-" JK_BETASTRING > #endif > > #define JK_VERSION (((JK_VERMAJOR) << 24) + ((JK_VERMINOR) << 16) + \ > ((JK_VERFIX) << 8) + (JK_VERBETA)) -- Andy Armstrong, Tagish
Re: [jtc - jk] jk_version.h
Anyone mind if I replace #define JK_VERSION (((JK_VERMAJOR) << 24) + ((JK_VERMINOR) << 16) + \ ((JK_VERFIX) << 8) + (JK_VERBETA)) with #define JK_MAKEVERSION(major, minor, fix, beta) \ (((major) << 24) + ((minor) << 16) + \ ((fix) << 8) + (beta)) #define JK_VERSION \ JK_MAKEVERSION(JK_VERMAJOR, JK_VERMINOR, JK_VERFIX, JK_VERBETA) ? Then you can have #if defined(JK_VERSION) && JK_VERSION >= JK_MAKEVERSION(1, 2, 0, 1) ... #endif [snip] > I have prepared a jk_version.h. I will commit it tomorrow (If I have time). > Find it enclosed. > > > /* common/jk_version.h */ > > /** START OF AREA TO MODIFY BEFORE RELEASING */ > #define JK_VERMAJOR 1 > #define JK_VERMINOR 2 > #define JK_VERFIX 0 > #define JK_VERSTRING"1.2.0" > > /* Beta number */ > #define JK_VERBETA 1 > #define JK_BETASTRING "1" > /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ > #define JK_VERISRELEASE 1 > /** END OF AREA TO MODIFY BEFORE RELEASING */ > > #define PACKAGE "mod_jk/" > /* Build JK_EXPOSED_VERSION and JK_VERSION */ > #define JK_EXPOSED_VERSION_INT PACKAGE JK_VERSTRING > > #if ( JK_VERISRELEASE == 1 ) > #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT > #undef JK_VERBETA > #define JK_VERBETA 255 > #else > #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-beta-" JK_BETASTRING > #endif > > #define JK_VERSION (((JK_VERMAJOR) << 24) + ((JK_VERMINOR) << 16) + \ > ((JK_VERFIX) << 8) + (JK_VERBETA)) -- Andy Armstrong, Tagish
Re: [jtc - jk] jk_version.h
Hi Jean Frederic, Would you like me to commit this? jean-frederic clere wrote: > > Andy Armstrong wrote: > > > > +1 > > > > jean-frederic clere wrote: > > > > > > GOMEZ Henri wrote: > > > > > > > > >so, forgive me if this is a stupid question, but... how is jk_version.h > > > > >generated on windows? do i need to install cygwin stuff and run > > > > >buildconf.sh/configure? > > > > > > > > Good point Kevin :) > > > > > > > > May be just by editing it ;) > > > > > > Should move the logic of version out from configure and to jk_version.h (Any > > > way I was not very happy to have to commit configure.in when the j-t-c version > > > changes). > > > > -- > > Andy Armstrong, Tagish > > I have prepared a jk_version.h. I will commit it tomorrow (If I have time). > Find it enclosed. > > > /* common/jk_version.h */ > > /** START OF AREA TO MODIFY BEFORE RELEASING */ > #define JK_VERMAJOR 1 > #define JK_VERMINOR 2 > #define JK_VERFIX 0 > #define JK_VERSTRING"1.2.0" > > /* Beta number */ > #define JK_VERBETA 1 > #define JK_BETASTRING "1" > /* set JK_VERISRELEASE to 1 when release (do not forget to commit!) */ > #define JK_VERISRELEASE 1 > /** END OF AREA TO MODIFY BEFORE RELEASING */ > > #define PACKAGE "mod_jk/" > /* Build JK_EXPOSED_VERSION and JK_VERSION */ > #define JK_EXPOSED_VERSION_INT PACKAGE JK_VERSTRING > > #if ( JK_VERISRELEASE == 1 ) > #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT > #undef JK_VERBETA > #define JK_VERBETA 255 > #else > #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-beta-" JK_BETASTRING > #endif > > #define JK_VERSION (((JK_VERMAJOR) << 24) + ((JK_VERMINOR) << 16) + \ > ((JK_VERFIX) << 8) + (JK_VERBETA)) -- Andy Armstrong, Tagish
Re: TomcatBook - was TOMCAT SUCKS
GOMEZ Henri wrote: > > >On Friday 29 June 2001 11:41, [EMAIL PROTECTED] wrote: > >> A few months ago a project to write a Tomcat book was started (check: > >> http://www.sourgeforge.org search for tomcatbook) > > > >http://sourceforge.net/projects/tomcatbook/> > > > >> Haven't heard a lot about it since. Wouldn't it be an good idea to > >> synchronise efforts? > > > >Probably. Apparently 22 people are signed up... can't see how far > >they've got yet, though. > > A tomcat book using a GPL licence to cover a tool using Apache Licence ? > > A more realist approach could be to move that project to jakarta-tomcat, > or a sub-project like jakarta-tomcat-docs, and may be provide authors > a commiter status ? > > What about ? +1 if they're interested. -- Andy Armstrong, Tagish
Re: mod_jk configuration
Can we broaden this out to all connectors? At the moment the IIS connector has stuff in the registry, the Domino connector has stuff either in the registry or in an INI file (depending on platform). It's all a bit messy really. [EMAIL PROTECTED] wrote: > > The goals: > > 1. Full support for all the settings in web.xml. Right now the generated > config fragment is incomplete, security configs are not generated, neither > welcome files. > > 2. As easy as possible for the admin. The user should install the > .so/.dll, add few lines in httpd.conf, and get a running system. No > further configuration should be needed ( when you add a context for > example ). > > 3. Support "manual override". We can't expect the "automatic" config > to resolve all the needs, only the common use case. A smart apache admin > with a complex site might want to fine-tune the system. A complex load > balancing site might also want to do advanced settings. > > 4. Fit into a "bigger view" - we want to extend the solution with more > features and integrate it into the /admin or some other tools. > > Possible solution: > > 1. Start by using the same mapping as in webapp, i.e. mount the context > and have all the requests served by tomcat. > > 2. Stop generating the current set of files but only > uri_workers.properties ( which is equivalent with mount directives, only > simpler and consistent for all supported web servers ) > > 3. For some webapps it should be possible to generate a better mapping, > by including all the rules - but if we can't generate something equivalent > with web.xml, we'll fall back to (2). > > 4. Fix the problem that was pointed by Dirk, i.e. allow explicit mappings > in httpd.conf ( that set handler to script/jakarta ). This will be the > "override" mode, with explicit settings in the config files. > > 5. For ajp14, add a set of classes to represent the configuration and the > handler that will send it when the server connects. > > 6. (optional) Extend the current config generator to automatically edit > httpd.conf and include the "Include" statements > > I'm still working on a longer term solution that could address more compex > configurations and user tunning ( like server pools, special settings for > security integration, etc ). > > Note that we already plan some extensions to ajp14 to support chunks of > static content ( discussed mostly in jasper34 threads I think ), and this > will extend very well for static files ( and reduce the problem that > static files are served by tomcat intead of apache ). > > The extension will send the file name ( and offsets ) instead of the > actual chunk, reducing the wire transfer and letting apache handle the > static content ( assuming it is big enough ). This will be great for > jasper, but also for static files. Also note that this is a temporary > solution ( for static files ), until we figure out a way to map web.xml > into apache, iis, nes, aol, domino ( or at least jk ) configurations. > > Please send feedback, I'll start implementing some of it tommorow or > early next week ( I have a vacation - and I plan to go out for few > days at the end of next week ). > > Costin -- Andy Armstrong, Tagish
Re: submit a patch
Send it to this list with an explanation of what it does. If all is well someone will take it and apply it to the source tree. Thomas Colin de Verdiere wrote: > > Hi, > how do i submit a patch? > > Thomas -- Andy Armstrong, Tagish
Re: Multipart/Form-Data Problem
So these two pages refer to each other? What's supposed to handle the multipart/form-data? You know that Tomcat won't automatically handle it don't you? [EMAIL PROTECTED] wrote: > > Hi all, > > I have encountered a strange problem with tomcat 3.2.2 (standalone). I have > prepared pages to upload files using post method but i ended up getting "Can not > find server" and "Connection reset by peer" responses from IE and Netscape. When > i post the data from the first page, the browsers display error messages. The > thing is that error does not occur on every file and it occurs on both binary > and text files. > > During the localization of the problem i removed the jsp statements from the > program and changed the code. What i ended up with is the following two files > whose content are nothing but the HTML tags; but the error is still there. > > Here are the files: > > --file upload.jsp > > > > > action="/java/1.jsp" enctype="multipart/form-data"> > > Select a file: > > > > > -file--1.jsp > > > > > action="/java/upload.jsp" > > value="\"> > value="name"> > > > > > Can someone help me with this problem ? > > -Oner Necip Hamali -- Andy Armstrong, Tagish
Re: Tomcat Documentation Project
+1 [EMAIL PROTECTED] wrote: > > Leaving aside the issue of file format for just one second... > > Are we agreed on the following? > > 1. Tomcat documentation sucks :-) > > 2. There needs to be a new CVS project called jakarta-tomcat-doc. > > My reasoning is that we want to avoid the fragmentation of documentation > into different trees for 3.2, 3.3, and 4.0. Why? Because a lot of > documentation would apply equally to all versions. > > Looking at it in reverse, the fact that someone is using an old version > of Tomcat shouldn't mean they're forced to use an old version of the > documentation. Instead, a chapter on, say, web application deployment > may need to have a sidebar describing changes between 3.x and 4.x, but > assuming 4.x isn't *radically* different, they can both use the same > core text. (In cases where 4.x *is* radically different, it would just > have a separate document/chapter, with the 4.x specificity clearly > labelled in the title.) > > I know the 4.x crew have begun the process of creating a separate > documentation set, including xdocs, and this is great. If it's too much > work to integrate 3.x and 4.x then maybe they should remain separate CVS > projects too, but it may still be desirable to have a separate CVS > project anyway. > > 3. There needs to be a better index/TOC for the documentation we do > have, and a reorganization of the redundant / outdated / wrong parts of > the existing docs (the Apache config stuff comes to mind). > > 4. Someone or some small group of people should take responsibility for > making this happen (before we "run out of steam"), regularly submitting > proposals and keeping the rest of the group apprised of developments and > decisions, but retaining some authority. Let's call this person/people > the Documentation Czar. I'm not proposing he/they have any real > authority over the content, but just over organizing it, deciding where > to place it, and forming "to do" lists for documents/chapters that need > to be written or proofed or tech edited or revised. > > If we agree on the above, then there's a good chance I'd volunteer to be > the Doc Czar, even though I think it's a lot of work. I've been managing > the jGuru Tomcat FAQ for a year, and the Servlets FAQ for longer, so I > at least have some idea of the scope of this kind of organizational > task. (Note that I'm not suggesting I actually *write* all this new > documentation... :-) > > Maybe a better term would be "Doc Editor" or "Editorial Board". And > maybe I'm being too anal in proposing it; maybe the open source process > will ensure the job gets done by interested developers even without the > title. > > - Alex > > -- > Alex Chaffee mailto:[EMAIL PROTECTED] > jGuru - Java News and FAQs http://www.jguru.com/alex/ > Creator of Gamelan http://www.gamelan.com/ > Founder of Purple Technology http://www.purpletech.com/ > Curator of Stinky Art Collective http://www.stinky.com/ -- Andy Armstrong, Tagish
Re: TC4 docs - can we end this?
"Rob S." wrote: > > (apologies in advance for the tone, I'm a happy person =) > > As far as Anakia is concerned, it's proven (within Jakarta), it looks a lot > like XHTML, there's resident expertise, and TC 4 is already using it. Of > course I am *all for* debate, discussion, etc. but in lieu of all of the > above, why continue dicussing it? What's *wrong*? > > I dunno who said it, but a long time ago there's a nice quote I heard in > English class, "The purity of a revolution lasts for about two weeks." It > explains what happens each time we talk about docs, a nice(r) admin UI, etc. > It seems like people are more interested in talking about what projects to > create, what tools to use, etc. when I *still* haven't read any comments > about *THE ACTUAL DOCUMENTATION* aside from "TOMCAT SUCKS!" and everyone's > agreement that the docs are in need of repair... Not a lot of > groundbreaking realizations left to make on those two points. You have, of course, put your finger on the reason why so many free software projects have sucky docs -- we'd all far rather fantasize about high falutin tools than put finger to keyboard. Talking about the tools is just another reason to delay writing the docs. Anyway +1 million on getting some decent docs written. Personally I'd find it useful if someone who is reasonably clueful on the state of TC documentation at the moment could summarise what's out there. The TC book project for example; where's that at? -- Andy Armstrong, Tagish
Re: TC4 docs - can we end this?
"Rob S." wrote: > > > Anyway +1 million on getting some decent docs written. Personally I'd > > find it useful if someone who is reasonably clueful on the state of TC > > documentation at the moment could summarise what's out there. The TC > > book project for example; where's that at? > > I think that falls under my personal category of "too involved to garner > much continual support". That's just my thought tho' =) If we had a solid > bank of docs and had proven to ourselves that we could even do that 'simple' > task, then I'd be all for a book. Lets get some docs out there first ;) Completely agree -- I'm just trying to get a feel for what's been done so far on the assumption that there may be useful documentation lying around out there. -- Andy Armstrong, Tagish
Re: First day - RE: PROPOSAL: Tomcat docs
"Rob S." wrote: > > Shown below are the results of today's content and organizational > suggestions. It's still extreeemely rough, but this is the kind of stuff I > like. We're making progress! =) > > - r > > 0) Introduction > >- Why use tomcat, what does it do and what doesn't it do? >- Feature list as from tomcat 3 and as from tomcat 4 (group together > features and in which versions they appear/dissapear). >- Requirements (JDK versions, extra libs?, etc.) >- How-to submit a bug >- How-to subscribe to tomcat-user/-dev & how-to UNSUBSCRIBE :) >- Interesting links (api-spec, etc) - Comparisons with other containers > > 1) Administrator's Guide > >- Quick install (VERY short and simple) >- Detailed installation? Not a nice name... - In Depth Installation? >- Connectors and beyond. Why choose which connector and > why don't use a certain connector? >- Tomcat standalone >- Apache >- IIS >- Netscape - Domino ;-) >- Tomcat & SSL >- Tips - Style recommendations - Where to put JARs in different scenarios >- (versioned?) Mini-FAQ >- Advanced configuration >- Complete server.xml reference >- Heavy Load Guide (Loadbalancing) - Route map -- what lives where (server.xml/web.xml) > > 2) Web Application Developers' Guide > >- Things to know while developing with Tomcat. The web dev > doesn't have to be an admin pro! - Links to other servlet/jsp resources I'm guessing that we only want Tomcat specific stuff in here, so general servlet topics might not be appropriate, but for the sake of completeness a couple of worked examples of servlets and jsps might not be out of place. > 3) Container Architecture Guide > >- In this case also some references to technical docs which > explain how to start writing eg custom handlers, etc). -- Andy Armstrong, Tagish
Re: [J-T-C] struct defs
The reason would be to keep the implementation details of the structure
private so that people aren't tempted to access the fields directly. All
the caller gets is an opaque handle. Think of it as 'objects lite' for
C.
GOMEZ Henri wrote:
>
> We found many definitions like this
> in mod_jk :
>
> xxx.h
>
> struct jk_map;
> typedef struct jk_map jk_map_t;
>
> xxx.c
>
> struct jk_map {
> jk_pool_t p;
> jk_pool_atom_t buf[SMALL_POOL_SIZE];
>
> char **names;
> void **values;
>
> unsigned capacity;
> unsigned size;
> };
>
> Why not having it directly in xxx.h
>
> typedef struct {
> jk_pool_t p;
> jk_pool_atom_t buf[SMALL_POOL_SIZE];
>
> char **names;
> void **values;
>
> unsigned capacity;
> unsigned size;
> } jk_map_t;
>
> -
> Henri Gomez ___[_]
> EMAIL : [EMAIL PROTECTED] (. .)
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
--
Andy Armstrong, Tagish
Re: [J-T-C] struct defs
GOMEZ Henri wrote: > > >The reason would be to keep the implementation details of the structure > >private so that people aren't tempted to access the fields > >directly. All > >the caller gets is an opaque handle. Think of it as 'objects lite' for > >C. > > I could understand the OO construction if we were using C++ > but in strict K&R when you need to have access elements in > a struct you need to know about them ?) > > The goal is to have functions defs in .c and data defs in .h > preparing scandoc task > > So what about that repartition ? No, I think it's right as it stands. Just because we're working in C doesn't mean we can't do encapsulation. This is a perfectly valid idiom to express the concept of some.c and some.h working together to implement a 'class' which is only accessed through a functional interface. The encapsulation benefits are the same as for Java or C++. For one thing it means that the implementation in some.c can change without impacting client code. I haven't looked at any of the specific cases you're talking about, but in general I would say that this is good programming style. -- Andy Armstrong, Tagish
Re: [J-T-C] struct defs
> OK, you two, Andy/JF convinced me to OOing also in standard C ;;;))) Tres bon ;-) -- Andy Armstrong, Tagish
Re: First day - RE: PROPOSAL: Tomcat docs
Has everyone seen these articles: http://www.onjava.com/pub/ct/33 ? Might be useful to link to from the doc. "Rob S." wrote: > > Shown below are the results of today's content and organizational > suggestions. It's still extreeemely rough, but this is the kind of stuff I > like. We're making progress! =) > > - r > > 0) Introduction > >- Why use tomcat, what does it do and what doesn't it do? >- Feature list as from tomcat 3 and as from tomcat 4 (group together > features and in which versions they appear/dissapear). >- Requirements (JDK versions, extra libs?, etc.) >- How-to submit a bug >- How-to subscribe to tomcat-user/-dev & how-to UNSUBSCRIBE :) >- Interesting links (api-spec, etc) > > 1) Administrator's Guide > >- Quick install (VERY short and simple) >- Detailed installation? Not a nice name... >- Connectors and beyond. Why choose which connector and > why don't use a certain connector? >- Tomcat standalone >- Apache >- IIS >- Netscape >- Tomcat & SSL >- Tips >- (versioned?) Mini-FAQ >- Advanced configuration >- Complete server.xml reference >- Heavy Load Guide (Loadbalancing) > > 2) Web Application Developers' Guide > >- Things to know while developing with Tomcat. The web dev > doesn't have to be an admin pro! > > 3) Container Architecture Guide > >- In this case also some references to technical docs which > explain how to start writing eg custom handlers, etc). -- Andy Armstrong, Tagish
Re: Somebody get me off this List PLEASE!!!!!!!!!!!!!!!!
"Swart, James (Jim) ** CTR **" wrote: > > why is it everyone has such a hard time getting off this list? Someone put > me in charge of getting people off the jarkata maillists, I'll make sure > it's done to ensure these floods of "get me off here" is done... Sound good? Can't it be automated? What are the lists running on? -- Andy Armstrong, Tagish
Re: Somebody get me off this List PLEASE!!!!!!!!!!!!!!!!
Justin Erenkrantz wrote: > > On Thu, Jul 05, 2001 at 06:10:42PM +0100, Andy Armstrong wrote: > > "Swart, James (Jim) ** CTR **" wrote: > > > > > > why is it everyone has such a hard time getting off this list? Someone put > > > me in charge of getting people off the jarkata maillists, I'll make sure > > > it's done to ensure these floods of "get me off here" is done... Sound good? > > > > Can't it be automated? What are the lists running on? > > Apache.org is using ezmlm. The problem is when users don't confirm the > unsubscription or send it from the wrong address. It is automated, but > it isn't idiot-proof. Ah > It'd be nice to have a human moderator who reads tomcat-dev and can > manually take people off the list when they start to complain on-list. > -- justin Yup. -- Andy Armstrong, Tagish
Re: Separating Service code from Tomcat 4.0
"Pier P. Fumagalli" wrote: > > Pier P. Fumagalli at [EMAIL PROTECTED] wrote: > > > > I'd say, let's stick it with Tomcat until we don't have a "proof-of-concept" > > that it works, and then we can decide... I like jakarta-tomcat-service. > > Request-for-vote: Can I go ahead and open the new CVS repo? > > Pier > > Print and detach the following portion, then mail it over to me at: > > Pier > Somewhere in London > United Kingdom > > And don't forget to put a STAMP :) > > --- > > [ ] +1 - Do it, and I can help > [X] +0 - Do it, but I can't help > [ ] -0 - Do it, even if > [ ] -1 - Don't do it, because > > My comments: -- Andy Armstrong, Tagish
Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Hi Joe et al, Joe Flowers wrote: [snip cogent words about running TC as a service] I agree with you 100% WRT the difficulty of getting JavaService to work -- a sysadmin here pulled most of his few remaining hairs one day trying to get it working, so while I haven't personally looked at it I can well sympathize. For the Domino connector I took a slightly different approach: the Domino connector can optionally be configured to start Tomcat when it loads. This has a number of benefits including * simplified installation * assurance that Tomcat starts and stops at the right time relative to the web server's lifecycle * conceptually portable By "conceptually portable" I mean that while the code in the connector to implement Tomcat startup and shutdown isn't the same for all platforms the concept of running Tomcat in that way is -- you can safely assume that whatever the platform the admin has already arranged for the web server to start automatically if that's what they want, and the arrangements for starting Tomcat at the same time are essentially the same across all platforms. It would be easy enough to add the same functionality to the other connectors. This is a simple solution for all platforms in all cases except the one where you want to have Tomcat autostart in stand-alone mode, and I would assume that that's a relatively rare requirement. If there's interest I can investigate adding the same functionality to the other connectors. -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
GOMEZ Henri wrote: [snip] > >This is a simple solution for all platforms in all cases > >except the one where you want to have Tomcat autostart in stand-alone > >mode, and I would assume that that's a relatively rare requirement. > > No so rare since many sites use a farm a Tomcat behind their web-server > (using mod_jk load-balancing features) Ah yes -- I forgot about that. > >If there's interest I can investigate adding the same functionality to > >the other connectors. > > I'd like to see it on Apache at least. Could it be shared (or replace) > the jk_service allready present in jtc/jk/native ? I'd have thought so -- I'll have a look. -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was: SeparatingService code from Tomcat 4.0)
"Pier P. Fumagalli" wrote: > > Andy Armstrong at [EMAIL PROTECTED] wrote: > > > > If there's interest I can investigate adding the same functionality to > > the other connectors. > > I would not want to see it in webapp... Autostart was the major headache > back in JServ days... I wouldn't want to have to deal with the same thing > again. > > Pier I only used JServ briefly before switching to Tomcat and "it worked for me"(tm). Can you recall any of the specific problems? -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was: SeparatingServicecode from Tomcat 4.0)
"Pier P. Fumagalli" wrote: > > Andy Armstrong at [EMAIL PROTECTED] wrote: > > > > I only used JServ briefly before switching to Tomcat and "it worked for > > me"(tm). Can you recall any of the specific problems? > > It was back in 1997, and I remember several patches across 2 months from Ed > Korthof just to "make it work". But you should get back and see the > archives. > > I remember it was a big pain in the ass (and that for Jserv 1.0 I was > always starting Jserv stand alone!) I'll do some reading. Do you recall whether the problems where specific to that implementation of the startup code or more generically related to having the servlet container autostart? -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was: Separating Service code from Tomcat 4.0)
Remy Maucherat wrote: > > Quoting Andy Armstrong <[EMAIL PROTECTED]>: > > > Hi Joe et al, > > > > Joe Flowers wrote: > > [snip cogent words about running TC as a service] > > > > I agree with you 100% WRT the difficulty of getting JavaService to work > > -- a sysadmin here pulled most of his few remaining hairs one day > > trying > > to get it working, so while I haven't personally looked at it I can > > well > > sympathize. > > Yes, I can also confirm it's extremely hard to do too. One time, I forgot to > check the "NT Service" check box in the installer, and it failed to install !!! > > ;-) > > So the bottom line is : give it another try using the installer (and keep your > hair :) ). Maybe bugs were fixed or something like that. It wasn't my hair -- I don't have any any more ;-) -- Andy Armstrong, Tagish
Re: Different approach to TC as a service (was:SeparatingServicecode from Tomcat 4.0)
"Pier P. Fumagalli" wrote: [snip] > > I'll do some reading. Do you recall whether the problems where specific > > to that implementation of the startup code or more generically related > > to having the servlet container autostart? > > Oh, I remember it was about invoking the startup script, and also one big > hassle was to shut down JServ from Apache, connecting to the port to issue a > shutdown command... For the Domino connector I just do bin/tomcat.sh start or bin/tomcat.sh stop appropriately. It seems to work OK and is very simple to implement. -- Andy Armstrong, Tagish
