You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@apache.org> on 2004/07/14 18:31:04 UTC
Some JK2 ideas
Hi all,
Seems that the JK2 development has been stalled for a while, cause either
developers loose the interest, or it's so damn good :)
I would like to propose few things that IMO could make the JK2 a better.
1. Get rid of JNI from core and make a new 'server/jni/(iis|apace2|xxx)'.
This new would require java jre on server side. Also focus only on TC5
embedded mode.
It would require a lot of work like rewriting aprImpl and TomcatStarter, but
it should finally work something like Jrun or ServletExec.
This would be better explained as jk2jni then jk2/jni, but since they will
be using the same code base...
1.1 Make APR_JNI project.
Something like APR_UTIL or APR_ICONV that will give a portable JNI
interface, using APR.
2. workers2.properties -> workers2.xml using apr_utils xml support.
Get rid of 'assumed' properties like figuring out the context from url.
Get rid of copying mappings from 'default' to virtual hosts.
Of course, it would require few extra 'boring' statements in the config for
each mapping.
3. Get rid of Jk2* from Apache module and use only
'Jk2On'
That will register the JK2 in the same way as filter on IIS (for each
virtual server).
All this imply that the workers2.xml is the main config point, meaning that
the same workers2.xml is operable either on IIS or Apache or any other web
server. Also there are no other 'per-server' directives rather then 'on or
off'.
4. Get rid of all platform specific configuration stuff like WIN32 registry,
event log, apache log, and use only JK2 log.
Something like I proposed two years ago, but since people tend to change its
opinions, and since there was no major proposals for JK2 enhancements for
two years (not counting myself), do I have a 'card banshee', or do I need to
make a 'fork'?
Waiting for response from someone that can 'provide' something different, or
just file a veto :)
MT.
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
>>From: Jess Holle
>>
>>
>>I can see eliminating all web-server-specific configuration
>>options in the long-term -- though keeping the existing
>>options around for a while as deprecated alternatives would
>>be nice, i.e. to give everyone a conversion grace period.
>>
>>
>Well, you have a JK or that.
>
>
Point taken.
>>I cannot, however, see pushing everything into a single XML
>>file. This is insufficiently modular for a web server that
>>may have dozens of web apps with their own specific settings.
>> Rather what I'd suggest is something like:
>>
>>
>Did you try to set up the JK2 on some other server then Apache?
>
>
No, though on this basis I can understand and concur with your general
idea. I just firmly believe forcing an entire server's jk2
configuration including all web-apps' configurations into a single XML
file lacks sufficient modularity.
>Did you try to use your server.xml from TC on other platforms?
>
>
Huh? server.xml is Tomcat-specific -- as are the <Context> elements.
That's like saying "did you ever try to use mod_jk2 config files with JRun".
Now if what you mean is have I tried it with Tomcat on various OS and
web server platforms, then the answer is, yes.
Until Tomcat allowed <Context> elements to be placed outside its
server.xml into separate, per-web-app files, configuring (non-WAR) web
apps led to ugly to a merging and general maintenance issue with
server.xml. Once per-web-app XML config files were allowed things
became 1000 times more manageable from a tooling and maintenance
perspective.
[Now if your question is shouldn't everything be done via WAR files,
then you're one of the lucky few for whom unexpanded WAR files actually
fulfill your requirements.]
>Having things Apache specific AFAICT was the major reason why so many
>project has failed.
>
>
Nothing about modular XML files should be Apache specific. I'm just
suggesting we learn from Tomcat's experiences and not require every
web-app's configuration be merged into a single XML file. It was not
workable there and it won't be here.
--
Jess Holle
Re: Some JK2 ideas
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> Andy Armstrong wrote:
>>
>>> Mladen Turk wrote:
>>>
>>>> In contrary, it makes it simpler, cause you have a common
>>>> denominator, and
>>>> that is
>>>> 'well documented' config file, usable on any container.
>>>
>>>
>>>
>>>
>>> Well documented is the crux here for me. Or at least readily
>>> understandable. I've just had someone nearly abandon Tomcat
>>> altogether because they had a problem (with file uploads) that
>>> required the latest version of the IIS connector but they couldn't
>>> find out how to configure it.
>>>
>>> I find it frustrating that we're an Apache project but we're
>>> currently nowhere near Apache in usability terms. Right now running
>>> Tomcat with another webserver is a scary proposition.
>>>
>>> All the JK code has to do is forward eligible requests from the host
>>> web server to Tomcat. I'm afraid that right now it behaves like a
>>> self indulgent vanity project with aspirations above its station.
>>> With appropriate apologies for the toes that I'm treading on why tge
>>> hell is JK so convoluted?
>>
>>
>>
>> There is weeks I'm thinking about another approach for Apache to
>> Tomcats (AJP13) requests relaying.
>>
>> My idea is about a new module, only Apache 2.x for now, which will
>> make use of SetEnv, SetEnvIf, BrowserMath and Location
>> directives to redirect some URLs to tomcats via AJP.
>
>
> Everything in httpd.conf, probably that is a good idea. Reusing existing
> directives also.
>
>>
>> Many users complains about problems between Directive, Location,
>> JkMount and of course the configuration complexity of JK and JK2,
>> and yes jk/jk2 are big when you compare them to modules like
>> mod_rewrite or mod_proxy.
>>
>> What I'd like will be a true Apache module where all settings will
>> be in httpd.conf, a module where there will be only one way to configure
>> or define something (which is not the case for JK2 for instance).
>>
>> After all we're ASF commiter and making a specific Apache 2.x connector
>> seems a reasonable goal.
>>
>> The code in jk/jk2 is now so complex that there is only a small
>> number of people who can be involved in.
>>
>> Ok, now that I exposed my general idea, I'd like to have your opinion
>> about what could be a lighter module.
>
>
> Renew mod_webapp!
mod_webapp was a good idea but :
- It didn't use the de-facto standard AJP13.
- It came too soon, before APR was widely available.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Remy Maucherat <re...@apache.org>.
jean-frederic clere wrote:
>> My idea is about a new module, only Apache 2.x for now, which will
>> make use of SetEnv, SetEnvIf, BrowserMath and Location
>> directives to redirect some URLs to tomcats via AJP.
>
> Everything in httpd.conf, probably that is a good idea. Reusing existing
> directives also.
>
>> Many users complains about problems between Directive, Location,
>> JkMount and of course the configuration complexity of JK and JK2,
>> and yes jk/jk2 are big when you compare them to modules like
>> mod_rewrite or mod_proxy.
>>
>> What I'd like will be a true Apache module where all settings will
>> be in httpd.conf, a module where there will be only one way to configure
>> or define something (which is not the case for JK2 for instance).
>>
>> After all we're ASF commiter and making a specific Apache 2.x connector
>> seems a reasonable goal.
>>
>> The code in jk/jk2 is now so complex that there is only a small
>> number of people who can be involved in.
>>
>> Ok, now that I exposed my general idea, I'd like to have your opinion
>> about what could be a lighter module.
>
> Renew mod_webapp!
Well:
- the Java side of webapp was very questionable (so no matter what
happens, this needs to go)
- performance was bad
- APR and Apache 2 weren't ready yet (the market share of Apache 2 has
only recently started going up significantly)
- Craig and I supported its development for a very long time, which
means we supported its core ideas
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> Andy Armstrong wrote:
>
>> Mladen Turk wrote:
>>
>>> In contrary, it makes it simpler, cause you have a common
>>> denominator, and
>>> that is
>>> 'well documented' config file, usable on any container.
>>
>>
>>
>> Well documented is the crux here for me. Or at least readily
>> understandable. I've just had someone nearly abandon Tomcat altogether
>> because they had a problem (with file uploads) that required the
>> latest version of the IIS connector but they couldn't find out how to
>> configure it.
>>
>> I find it frustrating that we're an Apache project but we're currently
>> nowhere near Apache in usability terms. Right now running Tomcat with
>> another webserver is a scary proposition.
>>
>> All the JK code has to do is forward eligible requests from the host
>> web server to Tomcat. I'm afraid that right now it behaves like a self
>> indulgent vanity project with aspirations above its station. With
>> appropriate apologies for the toes that I'm treading on why tge hell
>> is JK so convoluted?
>
>
> There is weeks I'm thinking about another approach for Apache to
> Tomcats (AJP13) requests relaying.
>
> My idea is about a new module, only Apache 2.x for now, which will
> make use of SetEnv, SetEnvIf, BrowserMath and Location
> directives to redirect some URLs to tomcats via AJP.
Everything in httpd.conf, probably that is a good idea. Reusing existing
directives also.
>
> Many users complains about problems between Directive, Location,
> JkMount and of course the configuration complexity of JK and JK2,
> and yes jk/jk2 are big when you compare them to modules like
> mod_rewrite or mod_proxy.
>
> What I'd like will be a true Apache module where all settings will
> be in httpd.conf, a module where there will be only one way to configure
> or define something (which is not the case for JK2 for instance).
>
> After all we're ASF commiter and making a specific Apache 2.x connector
> seems a reasonable goal.
>
> The code in jk/jk2 is now so complex that there is only a small
> number of people who can be involved in.
>
> Ok, now that I exposed my general idea, I'd like to have your opinion
> about what could be a lighter module.
Renew mod_webapp!
>
> Regards
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Andy Armstrong <an...@hexten.net>.
Henri Gomez wrote:
> The code in jk/jk2 is now so complex that there is only a small
> number of people who can be involved in.
It certainly scares me and I like complex things :)
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by David Rees <dr...@greenhydrant.com>.
Henri Gomez wrote:
>
> My idea is about a new module, only Apache 2.x for now, which will
> make use of SetEnv, SetEnvIf, BrowserMath and Location
> directives to redirect some URLs to tomcats via AJP.
This sounds like a great idea. It would be easy to configure, and I would
love to be able to completely configure the connector in the httpd.conf
instead of having to use a seperate properties file for the connector.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Henri Gomez <hg...@apache.org>.
Andy Armstrong wrote:
> Mladen Turk wrote:
>
>> In contrary, it makes it simpler, cause you have a common denominator,
>> and
>> that is
>> 'well documented' config file, usable on any container.
>
>
> Well documented is the crux here for me. Or at least readily
> understandable. I've just had someone nearly abandon Tomcat altogether
> because they had a problem (with file uploads) that required the latest
> version of the IIS connector but they couldn't find out how to configure
> it.
>
> I find it frustrating that we're an Apache project but we're currently
> nowhere near Apache in usability terms. Right now running Tomcat with
> another webserver is a scary proposition.
>
> All the JK code has to do is forward eligible requests from the host web
> server to Tomcat. I'm afraid that right now it behaves like a self
> indulgent vanity project with aspirations above its station. With
> appropriate apologies for the toes that I'm treading on why tge hell is
> JK so convoluted?
There is weeks I'm thinking about another approach for Apache to
Tomcats (AJP13) requests relaying.
My idea is about a new module, only Apache 2.x for now, which will
make use of SetEnv, SetEnvIf, BrowserMath and Location
directives to redirect some URLs to tomcats via AJP.
Many users complains about problems between Directive, Location,
JkMount and of course the configuration complexity of JK and JK2,
and yes jk/jk2 are big when you compare them to modules like
mod_rewrite or mod_proxy.
What I'd like will be a true Apache module where all settings will
be in httpd.conf, a module where there will be only one way to configure
or define something (which is not the case for JK2 for instance).
After all we're ASF commiter and making a specific Apache 2.x connector
seems a reasonable goal.
The code in jk/jk2 is now so complex that there is only a small
number of people who can be involved in.
Ok, now that I exposed my general idea, I'd like to have your opinion
about what could be a lighter module.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Andy Armstrong <an...@hexten.net>.
Mladen Turk wrote:
> In contrary, it makes it simpler, cause you have a common denominator, and
> that is
> 'well documented' config file, usable on any container.
Well documented is the crux here for me. Or at least readily
understandable. I've just had someone nearly abandon Tomcat altogether
because they had a problem (with file uploads) that required the latest
version of the IIS connector but they couldn't find out how to configure it.
I find it frustrating that we're an Apache project but we're currently
nowhere near Apache in usability terms. Right now running Tomcat with
another webserver is a scary proposition.
All the JK code has to do is forward eligible requests from the host web
server to Tomcat. I'm afraid that right now it behaves like a self
indulgent vanity project with aspirations above its station. With
appropriate apologies for the toes that I'm treading on why tge hell is
JK so convoluted?
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Wed, 14 Jul 2004, Jess Holle wrote:
|
| >>Using a modular multi-XML-file approach does not pollute the
| >>result with any additional server-specific or Tomcat-specific
| >>baggage. It just makes management and automated
| >>configuration/installation much more workable.
| >>
| >>
| >In contrary, it makes it simpler, cause you have a common denominator, and
| >that is 'well documented' config file, usable on any container.
| >
| >
| What I'm saying here is that I want modular per-web-app config-file
| support. I don't care if any/all server-specific and Tomcat-specific
| stuff is removed from them -- actually that is laudable in the long term
| even if a bit painful in the short term. I just don't want to be forced
| into shoving the whole configuration into a single file (or using XML
| entity reference hacks which are beyond ugly -- and require the main
| file to be modified to add extra entity references which is highly
| undesirable).
Couldn't agree more.
|
| >JkUriSet can be used only on the Apache server.
| >So, the question is, are we adapting the apache module to other servers, or
| >we have a
| >container independent module.
| >
| >
| I think you are missing my point:
|
| Go ahead and remove JkUriSet, just add equivalent functionality to
| do per-web-app configuration files. Just do it in a
| server-independent, XML-based way this time around.
Most definately.
But get them files understandable!!
(I, contrary to many others, apparently, like auto-stuff to a degree.
However, I most definately need to know -what- is assumed, possibly using
some "what-are-assumed" command, or log the assumptions to file on
startup)
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
>
>
>
>
>>-----Original Message-----
>>From: Jess Holle
>>
>>
>>>Who ever asked the poor apache admin about the TC's config ater all?
>>>
>>>
>>>
>>>
>>It really does not matter who the admin is. Even a
>>sophisticated admin is going to want to have file
>>modification dates they can trust on various aspects of the
>>configuration so they can answer "did I change this part?" questions.
>>
>>
>Don't think that the current config provides that either.
>
>
It does if you use JkUriSet. I have a separate (auto-generated) .conf
file for every web app containing mod_jk, jk2, etc, etc, configuration
and another auto-generated .conf file for each web app (included by the
first) containing any/all Apache-side authentication configuration for
the web app.
I can have (and auto-generate) more files per web app, but I (and others
I know) won't move to anything that regresses from this level of modularity.
>>Using a modular multi-XML-file approach does not pollute the
>>result with any additional server-specific or Tomcat-specific
>>baggage. It just makes management and automated
>>configuration/installation much more workable.
>>
>>
>In contrary, it makes it simpler, cause you have a common denominator, and
>that is 'well documented' config file, usable on any container.
>
>
What I'm saying here is that I want modular per-web-app config-file
support. I don't care if any/all server-specific and Tomcat-specific
stuff is removed from them -- actually that is laudable in the long term
even if a bit painful in the short term. I just don't want to be forced
into shoving the whole configuration into a single file (or using XML
entity reference hacks which are beyond ugly -- and require the main
file to be modified to add extra entity references which is highly
undesirable).
>JkUriSet can be used only on the Apache server.
>So, the question is, are we adapting the apache module to other servers, or
>we have a
>container independent module.
>
>
I think you are missing my point:
Go ahead and remove JkUriSet, just add equivalent functionality to
do per-web-app configuration files. Just do it in a
server-independent, XML-based way this time around.
>If you wish to have a few virtual hosts, you will need to apply two
>completely different
>configurations for each side anyhow (httpd.conf or click-clik and
>server.xml).
>Having specific directives for each container makes that even more
>complicated thought.
>
>
I'm just looking for things like:
* Web app X:
o jk-mount /x/*, /y/*, and *.jsp
o map these all to worker X
* Web app Y
o jk-mount /m/* and *.jsp
o map these all to worker Y
....and so on....
With the information above (and any other things which are justifiably
per-web-app *and* per-web-app support already exists for) be specifiable
in separate files, one for Web app X, one for Web app Y, and so on.
--
Jess Holle
RE: Some JK2 ideas
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Jess Holle
> >
> >Who ever asked the poor apache admin about the TC's config ater all?
> >
> >
> It really does not matter who the admin is. Even a
> sophisticated admin is going to want to have file
> modification dates they can trust on various aspects of the
> configuration so they can answer "did I change this part?" questions.
>
Don't think that the current config provides that either.
> Using a modular multi-XML-file approach does not pollute the
> result with any additional server-specific or Tomcat-specific
> baggage. It just makes management and automated
> configuration/installation much more workable.
>
In contrary, it makes it simpler, cause you have a common denominator, and
that is
'well documented' config file, usable on any container.
JkUriSet can be used only on the Apache server.
So, the question is, are we adapting the apache module to other servers, or
we have a
container independent module.
If you wish to have a few virtual hosts, you will need to apply two
completely different
configurations for each side anyhow (httpd.conf or click-clik and
server.xml).
Having specific directives for each container makes that even more
complicated thought.
MT.
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
>>-----Original Message-----
>>From: Bill Barker
>>
>>Having the option to do per-host and even per-context configs
>>makes life much easier for admins of servers that support it.
>> Otherwise, you end up with a file that looks like:
>> <jk-config>
>> &host1;
>> &host2;
>> &host3;
>> </jk-config>
>>which is fine for xml-hackers, but not very helpful for server-admins.
>>
>>
>Yes, that's true, but that same layz admin still has to make the Tomcat
>running, or not?
>It still has to learn that server.xml stuff, and even make it working :)
>
>Who ever asked the poor apache admin about the TC's config ater all?
>
>
It really does not matter who the admin is. Even a sophisticated admin
is going to want to have file modification dates they can trust on
various aspects of the configuration so they can answer "did I change
this part?" questions.
Using a modular multi-XML-file approach does not pollute the result with
any additional server-specific or Tomcat-specific baggage. It just
makes management and automated configuration/installation much more
workable.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Bill Barker
>
> Having the option to do per-host and even per-context configs
> makes life much easier for admins of servers that support it.
> Otherwise, you end up with a file that looks like:
> <jk-config>
> &host1;
> &host2;
> &host3;
> </jk-config>
> which is fine for xml-hackers, but not very helpful for server-admins.
>
>
Yes, that's true, but that same layz admin still has to make the Tomcat
running, or not?
It still has to learn that server.xml stuff, and even make it working :)
Who ever asked the poor apache admin about the TC's config ater all?
MT.
Re: Some JK2 ideas
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Mladen Turk" <mt...@apache.org>
To: "'Tomcat Developers List'" <to...@jakarta.apache.org>
Sent: Wednesday, July 14, 2004 10:49 AM
Subject: RE: Some JK2 ideas
>
>
> > -----Original Message-----
> > From: Jess Holle
> > >
> > >
> > I can see eliminating all web-server-specific configuration
> > options in the long-term -- though keeping the existing
> > options around for a while as deprecated alternatives would
> > be nice, i.e. to give everyone a conversion grace period.
> >
>
> Well, you have a JK or that.
>
>
> > I cannot, however, see pushing everything into a single XML
> > file. This is insufficiently modular for a web server that
> > may have dozens of web apps with their own specific settings.
> > Rather what I'd suggest is something like:
> >
>
> Did you try to set up the JK2 on some other server then Apache?
> Did you try to use your server.xml from TC on other platforms?
>
>
> Having things Apache specific AFAICT was the major reason why so many
> project has failed.
>
I'm driving a Peugeot 406 (Apache), why should I care how it works on a Yugo
(IIS)? ;-)
Having the option to do per-host and even per-context configs makes life
much easier for admins of servers that support it. Otherwise, you end up
with a file that looks like:
<jk-config>
&host1;
&host2;
&host3;
</jk-config>
which is fine for xml-hackers, but not very helpful for server-admins.
> MT.
>
RE: Some JK2 ideas
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Jess Holle
> >
> >
> I can see eliminating all web-server-specific configuration
> options in the long-term -- though keeping the existing
> options around for a while as deprecated alternatives would
> be nice, i.e. to give everyone a conversion grace period.
>
Well, you have a JK or that.
> I cannot, however, see pushing everything into a single XML
> file. This is insufficiently modular for a web server that
> may have dozens of web apps with their own specific settings.
> Rather what I'd suggest is something like:
>
Did you try to set up the JK2 on some other server then Apache?
Did you try to use your server.xml from TC on other platforms?
Having things Apache specific AFAICT was the major reason why so many
project has failed.
MT.
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
>>-----Original Message-----
>>From: Jess Holle
>>
>>
>>If you're proposing getting rid of JkUriSet, DON'T!
>>
>>
>That's exactly what I whish to do.
>
>
>>It is *very* helpful to be able to mount URI's for a specific
>>web app in an Apache .conf file that contains all the other
>>settings for that web app.
>>
>>
>I'm driving the Peugeot 406, and it would be very helpull that I can get a
>spare part from 'Yugo' :)
>So, will I adapt my Peugot, or just try to find a cheaper part?
>
>Also as I stated the workers2.xml should be the main config, for _all_
>platorms. No exceptions. Like there is no exceptions in Java itself.
>
>
I can see eliminating all web-server-specific configuration options in
the long-term -- though keeping the existing options around for a while
as deprecated alternatives would be nice, i.e. to give everyone a
conversion grace period.
I cannot, however, see pushing everything into a single XML file. This
is insufficiently modular for a web server that may have dozens of web
apps with their own specific settings. Rather what I'd suggest is
something like:
workers2.xml
* contains all mod_jk2 settings that are not web-app specific
* /can/ contain all mod_jk2 settings for the given server
one or more directories containing web-app specific settings (again
specified as XML)
* each worker defined in workers2.xml could have its own
sub-directory and each web app could thus be mounted by each
placing an XML file containing any settings for it in the
appropriate sub-directory
* other alternatives are possible (e.g. each web-app's XML file
could explicitly call out the worker instead and all the XML
files could be in one location, though I like the
mapping-by-placement arrangement)
This suggestion is essentially how Tomcat 5.0.x handles web-app
<Context> elements -- down to my shameless pilfering of the
mapping-by-placement idea. It was painful to add <Context> elements
directly to server.xml when this was required, i.e. when such modularity
was not supported, the Tomcat group realized this and an easy to use
modular configuration approach was provided.
I'd wholeheartedly support this sort of an approach (and would be
grateful to have XML rather the current workers2.properties format).
Killing off JkUriSet without such an improved modular alternative
(especially without a grace period) would *not* be appreciated -- by me
and a number of others I know who don't follow this list. It would
essentially push me towards sticking my customers with mod_jk indefinitely.
A final suggestion: A utility to produce the new XML file format from
the old formats (not part of the mod_jk2 binary, of course) would be
helpful.
--
Jess Holle
RE: Some JK2 ideas
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Jess Holle
> >
> If you're proposing getting rid of JkUriSet, DON'T!
>
That's exactly what I whish to do.
> It is *very* helpful to be able to mount URI's for a specific
> web app in an Apache .conf file that contains all the other
> settings for that web app.
I'm driving the Peugeot 406, and it would be very helpull that I can get a
spare part from 'Yugo' :)
So, will I adapt my Peugot, or just try to find a cheaper part?
Also as I stated the workers2.xml should be the main config, for _all_
platorms. No exceptions. Like there is no exceptions in Java itself.
MT.
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
>3. Get rid of Jk2* from Apache module and use only
>'Jk2On'
>That will register the JK2 in the same way as filter on IIS (for each
>virtual server).
>
>All this imply that the workers2.xml is the main config point, meaning that
>the same workers2.xml is operable either on IIS or Apache or any other web
>server. Also there are no other 'per-server' directives rather then 'on or
>off'.
>
>
If you're proposing getting rid of JkUriSet, DON'T!
It is *very* helpful to be able to mount URI's for a specific web app in
an Apache .conf file that contains all the other settings for that web
app. This is doubly true when you want that single conf file to cover
mod_jk and mod_jk2 bases so you can quickly and easily toggle between
the two in case of issues.
Having to merge per-web-app configurations into a single XML file would
be a mess by comparison for such use cases....
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Andy Armstrong
> > 2. workers2.properties -> workers2.xml using apr_utils xml support.
> > Get rid of 'assumed' properties like figuring out the
> context from url.
> > Get rid of copying mappings from 'default' to virtual hosts.
> > Of course, it would require few extra 'boring' statements in the
> > config for each mapping.
>
> One of the biggest problems I have /using/ Jk2 is working out
> what assumptions are going on. I tend to end up making
> everything explicit in w2.p anyway just so I know what's
> going on. A well defined XML config syntax would be most welcome.
>
That's my point too.
Having a config on the same place (.xml,evenually merged from TC) gives a
lot.
Ater all we are connecting to the 'portable' system.
MT.
Re: Some JK2 ideas
Posted by Andy Armstrong <an...@hexten.net>.
Mladen Turk wrote:
> 2. workers2.properties -> workers2.xml using apr_utils xml support.
> Get rid of 'assumed' properties like figuring out the context from url.
> Get rid of copying mappings from 'default' to virtual hosts.
> Of course, it would require few extra 'boring' statements in the config for
> each mapping.
One of the biggest problems I have /using/ Jk2 is working out what
assumptions are going on. I tend to end up making everything explicit in
w2.p anyway just so I know what's going on. A well defined XML config
syntax would be most welcome.
> 4. Get rid of all platform specific configuration stuff like WIN32 registry,
> event log, apache log, and use only JK2 log.
One thing to consider is a portable method for actually finding
workers2.xml in the first place. Windows based connectors tend to put it
in the same directory as the dll but that doesn't work as well for unix
like platforms which may not easily / sensibly be able to work out which
directory the .so is in.
> Waiting for response from someone that can 'provide' something different, or
> just file a veto :)
> MT.
It sounds reasonable to me and I'm happy to make necessary changes to
the Domino connector.
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Henri Gomez <hg...@apache.org>.
Cavan Morris wrote:
> Andy Armstrong wrote:
>
>> I have concrete examples of people giving up on Tomcat altogether for
>> no other reason than the fact that they couldn't get JK configured. By
>> comparison the rest of the task of configuring Tomcat is a walk in the
>> park. Please let's not be so up ourselves that we forget that it's
>> nice for people to actually be able to use the software.
>
>
> As a lurker on this list I can give myself and everyone I've ever worked
> with as concrete examples of some people that have given up on 4.1+
> tomcat because of JK configuration.
>
> I can count at least 12 projects I have worked on, or am working on,
> that are still on Tomcat 4.0.6 with mod_webapp because we could never
> get JK to do what we wanted. That is, mount this webapp at that URI in
> one line and be done with it. All the other JK features are great but
> 90% of the configurations are going to be like the one I just described
> and no one can figure out how to do it.
Could you send us your configuration for all these projects and we'll
give you httpd.conf / workers.properties settings.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
I actually built this yesterday upon rediscovering it -- and it seems to
work fine.
Unfortunately:
1. The licensing is unclear.
2. There appears to be no active maintenance or support of this module.
I'm thus more than a little reluctant to put too many eggs in this basket.
--
Jess Holle
Günter Knauf wrote:
>Hi,
>
>
>>A good number desparately want NTLM-based authentication. [They like
>>the single-sign on for Windows clients, but they love the notion of
>>better security than clear-text name/password, etc, without having to
>>buy a server certificate or use HTTPS on their intranet.] If Apache 2
>>had a stable module for this (whether or not it was from the ASF
>>itself), I would think this would be a good step to get these folk to
>>shift to Apache.
>>
>>
>then shift them - this module is available since first Apache2 days:
>http://www.gknw.net/development/apache/httpd-2.0/win32/modules/mod_auth_sspi-1.0.1-2.0.49.zip
>and also for Apache 2.1:
>http://www.gknw.net/development/apache/httpd-2.1-dev/win32/modules/mod_auth_sspi-1.0.1-2.1-dev.zip
>
>Guenter.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
Re: Some JK2 ideas
Posted by Günter Knauf <fu...@apache.org>.
Hi,
> A good number desparately want NTLM-based authentication. [They like
> the single-sign on for Windows clients, but they love the notion of
> better security than clear-text name/password, etc, without having to
> buy a server certificate or use HTTPS on their intranet.] If Apache 2
> had a stable module for this (whether or not it was from the ASF
> itself), I would think this would be a good step to get these folk to
> shift to Apache.
then shift them - this module is available since first Apache2 days:
http://www.gknw.net/development/apache/httpd-2.0/win32/modules/mod_auth_sspi-1.0.1-2.0.49.zip
and also for Apache 2.1:
http://www.gknw.net/development/apache/httpd-2.1-dev/win32/modules/mod_auth_sspi-1.0.1-2.1-dev.zip
Guenter.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Costin Manolache wrote:
> Jess Holle wrote:
>
>>> Maybe the best response to this would be to update the docs and say
>>> "tomcat IIS 6 is not supported, plese contact microsoft and ask them
>>> to do it". They have plenty of developers and money - they could
>>> send a check to Andy and Henri, or do it themself :-)
>>
>> I'm quite certain that they're ecstatic that it is problematic to
>> make these things work together.
>>
>> Personally, I despise IIS.
>>
>> However, when customers insist on using IIS for all HTTP(S) traffic
>> and your product relies on a servlet engine, what are you supposed to
>> do?
>
> Tell them to contact Microsoft.
Unfortunately some customers have IIS support (with no extra help from
Microsoft) as a requirement for the whole solution. They'll not buy or
buy non-Java before bothering to pave this ground themselves with Microsoft.
> Customers are probably paying money to use IIS ( plus the OS, support,
> etc ). Why should Apache tomcat solve their problems with IIS ? I
> don't think any tomcat developer received any free IIS + development
> tools + os licence + support from msft.
>
> We should obviously provide all the APIs and protocols to allow such a
> thing to work, but I don't think we should maintain it ( unless
> someone really has fun doing it ).
I can understand that. It is unfortunate for those caught trying to get
Java into Microsoft shops, but it is certainly an easily understood
position.
>> Do quality commercial offering exist that integrate with IIS *well*?
>> JRun is completely untenable. Most of the big guys have their own
>> web server, app server, etc, etc, to push -- causing still more
>> problems. Moreover, we don't want still more engines to test
>> everything with....
>
> I just think the problem of running IIS with app servers should be
> handled by Microsoft. They get the money from the IIS users, they
> should support IIS and implement what their customers need.
>
> We should just focus on Apache.
>
>>> It's better then having people struggle with mod_jk config and
>>> feeling it's tomcat developer's job to support IIS.
>>
>> In a way I agree, Microsoft is happily creating an unworkable
>> environment.
>>
>> Unfortunately, either Java as a whole backs out of this arena or it
>> fights for it. If Tomcat backs out, then it seems unlikely that many
>> using IIS will even bother trying Java servlets and/or JSP pages (as
>> they'll have no free way to do so).
>
> If they try using servlets with IIS - they'll have a bad experience
> and blame us.
>
> So it may be much better to just tell them to open a feature request
> on microsoft support site, or if they want to try servlets - download
> apache for free.
All that makes sense for ASF. It just leaves me SOL :-)
Perhaps IIS serving as a proxy for Apache would be a more tenable
position....
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Costin Manolache <cm...@yahoo.com>.
Jess Holle wrote:
>> Maybe the best response to this would be to update the docs and say
>> "tomcat IIS 6 is not supported, plese contact microsoft and ask them
>> to do it". They have plenty of developers and money - they could send
>> a check to Andy and Henri, or do it themself :-)
>
>
> I'm quite certain that they're ecstatic that it is problematic to make
> these things work together.
>
> Personally, I despise IIS.
>
> However, when customers insist on using IIS for all HTTP(S) traffic and
> your product relies on a servlet engine, what are you supposed to do?
Tell them to contact Microsoft.
Customers are probably paying money to use IIS ( plus the OS, support,
etc ). Why should Apache tomcat solve their problems with IIS ? I don't
think any tomcat developer received any free IIS + development tools +
os licence + support from msft.
We should obviously provide all the APIs and protocols to allow such a
thing to work, but I don't think we should maintain it ( unless someone
really has fun doing it ).
>
> Do quality commercial offering exist that integrate with IIS *well*?
> JRun is completely untenable. Most of the big guys have their own web
> server, app server, etc, etc, to push -- causing still more problems.
> Moreover, we don't want still more engines to test everything with....
I just think the problem of running IIS with app servers should be
handled by Microsoft. They get the money from the IIS users, they should
support IIS and implement what their customers need.
We should just focus on Apache.
>
>> It's better then having people struggle with mod_jk config and feeling
>> it's tomcat developer's job to support IIS.
>
>
> In a way I agree, Microsoft is happily creating an unworkable environment.
>
> Unfortunately, either Java as a whole backs out of this arena or it
> fights for it. If Tomcat backs out, then it seems unlikely that many
> using IIS will even bother trying Java servlets and/or JSP pages (as
> they'll have no free way to do so).
If they try using servlets with IIS - they'll have a bad experience and
blame us.
So it may be much better to just tell them to open a feature request on
microsoft support site, or if they want to try servlets - download
apache for free.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Costin Manolache wrote:
> Jess Holle wrote:
>
>> Andy Armstrong wrote:
>>
>>> Jess Holle > Getting the IIS connectors to work with IIS 6 appears
>>> to be rocket
>>>
>>>> science though. [Dang thing just shows a red down arrow on the
>>>> filter whatever you do without giving any real error!]
>>>
>>> Heh. Having spent two days getting the filter to work on IIS I'm
>>> thinking about starting to sell a consultancy service based on
>>> getting JK2 working. I actually wrote, debugged, documented and
>>> delivered a non trivial ISAPI filter for a different project in less
>>> time than it took me to get JK2 working.
>>
>> This is the JK, nor JK2, based connector in my case, but:
>>
>> 1. There are documented missing configuration steps out on the web
>> for IIS 6 that should be verified and placed in the Tomcat isapi
>> documentation.
>> 2. Any hint as to what to do other than start over again and hope for
>> better luck would be great appreciated. [I used the
>> 'isapi_install.vbs' script in hopes of having fewer error-prone
>> manual steps. Was that a bad idea?]
>>
>> I'd have kept this off the 'dev' group, but item (1) is quite glaring
>> at this point in that there are many reports that one cannot use the
>> Tomcat connectors with IIS 6 without extra configuration steps beyond
>> what the Tomcat docs provide.
>
> Maybe the best response to this would be to update the docs and say
> "tomcat IIS 6 is not supported, plese contact microsoft and ask them
> to do it". They have plenty of developers and money - they could send
> a check to Andy and Henri, or do it themself :-)
I'm quite certain that they're ecstatic that it is problematic to make
these things work together.
Personally, I despise IIS.
However, when customers insist on using IIS for all HTTP(S) traffic and
your product relies on a servlet engine, what are you supposed to do?
Do quality commercial offering exist that integrate with IIS *well*?
JRun is completely untenable. Most of the big guys have their own web
server, app server, etc, etc, to push -- causing still more problems.
Moreover, we don't want still more engines to test everything with....
> It's better then having people struggle with mod_jk config and feeling
> it's tomcat developer's job to support IIS.
In a way I agree, Microsoft is happily creating an unworkable environment.
Unfortunately, either Java as a whole backs out of this arena or it
fights for it. If Tomcat backs out, then it seems unlikely that many
using IIS will even bother trying Java servlets and/or JSP pages (as
they'll have no free way to do so).
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Tim Funk <fu...@joedog.org>.
I was lucky enough to ditch a bloated buggy j2ee engine in place of
tomcat/apache while we were in the process of switching CIO's. As nice as it
is to have someone to blame, its even harder to justify having to pay the fat
up front prices and yearly (lack of) support contracts for something that has
worked even better than said bloated buggy j2ee engine ;)
-Tim
Jess Holle wrote:
>> Then it may be better to spend the time implementing an NTLM auth for
>> Tomcat and Apache instead of spending the time supporting IIS :-)
>
>
> Quite possibly...
>
> Though there is also a sizable contingent of "we've got to have someone
> to sue" folk, i.e. they're down on open source software due to a lack of
> people to throw lawsuits at rather than due to a lack of support.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Costin Manolache wrote:
> Jess Holle wrote:
>
>> Henri Gomez wrote:
>>
>>>> It's better then having people struggle with mod_jk config and
>>>> feeling it's tomcat developer's job to support IIS.
>>>
>>> You could also suggest IIS users to switch to Apache 2.0.50 for
>>> Windows :)
>>
>> I'd love to -- and have.
>>
>> Unfortunately, some have drank too much Microsoft Kool-Aid.
>>
>> A good number desparately want NTLM-based authentication. [They like
>> the single-sign on for Windows clients, but they love the notion of
>> better security than clear-text name/password, etc, without having to
>> buy a server certificate or use HTTPS on their intranet.] If Apache
>> 2 had a stable module for this (whether or not it was from the ASF
>> itself), I would think this would be a good step to get these folk to
>> shift to Apache.
>
> Then it may be better to spend the time implementing an NTLM auth for
> Tomcat and Apache instead of spending the time supporting IIS :-)
Quite possibly...
Though there is also a sizable contingent of "we've got to have someone
to sue" folk, i.e. they're down on open source software due to a lack of
people to throw lawsuits at rather than due to a lack of support.
Sad but true....
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Costin Manolache <cm...@yahoo.com>.
Jess Holle wrote:
> Henri Gomez wrote:
>
>>> It's better then having people struggle with mod_jk config and
>>> feeling it's tomcat developer's job to support IIS.
>>
>>
>> You could also suggest IIS users to switch to Apache 2.0.50 for
>> Windows :)
>
>
> I'd love to -- and have.
>
> Unfortunately, some have drank too much Microsoft Kool-Aid.
>
> A good number desparately want NTLM-based authentication. [They like
> the single-sign on for Windows clients, but they love the notion of
> better security than clear-text name/password, etc, without having to
> buy a server certificate or use HTTPS on their intranet.] If Apache 2
> had a stable module for this (whether or not it was from the ASF
> itself), I would think this would be a good step to get these folk to
> shift to Apache.
Then it may be better to spend the time implementing an NTLM auth for
Tomcat and Apache instead of spending the time supporting IIS :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Henri Gomez wrote:
>> It's better then having people struggle with mod_jk config and
>> feeling it's tomcat developer's job to support IIS.
>
> You could also suggest IIS users to switch to Apache 2.0.50 for
> Windows :)
I'd love to -- and have.
Unfortunately, some have drank too much Microsoft Kool-Aid.
A good number desparately want NTLM-based authentication. [They like
the single-sign on for Windows clients, but they love the notion of
better security than clear-text name/password, etc, without having to
buy a server certificate or use HTTPS on their intranet.] If Apache 2
had a stable module for this (whether or not it was from the ASF
itself), I would think this would be a good step to get these folk to
shift to Apache.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Jess Holle wrote:
>
>> Andy Armstrong wrote:
>>
>>> Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
>>> be rocket
>>>
>>>> science though. [Dang thing just shows a red down arrow on the
>>>> filter whatever you do without giving any real error!]
>>>
>>>
>>>
>>> Heh. Having spent two days getting the filter to work on IIS I'm
>>> thinking about starting to sell a consultancy service based on
>>> getting JK2 working. I actually wrote, debugged, documented and
>>> delivered a non trivial ISAPI filter for a different project in less
>>> time than it took me to get JK2 working.
>>
>>
>>
>> This is the JK, nor JK2, based connector in my case, but:
>>
>> 1. There are documented missing configuration steps out on the web
>> for IIS 6 that should be verified and placed in the Tomcat isapi
>> documentation.
>> 2. Any hint as to what to do other than start over again and hope for
>> better luck would be great appreciated. [I used the
>> 'isapi_install.vbs' script in hopes of having fewer error-prone
>> manual steps. Was that a bad idea?]
>>
>> I'd have kept this off the 'dev' group, but item (1) is quite glaring
>> at this point in that there are many reports that one cannot use the
>> Tomcat connectors with IIS 6 without extra configuration steps beyond
>> what the Tomcat docs provide.
>
>
>
> Maybe the best response to this would be to update the docs and say
> "tomcat IIS 6 is not supported, plese contact microsoft and ask them to
> do it". They have plenty of developers and money - they could send a
> check to Andy and Henri, or do it themself :-)
No ask M$ to make a donation to ASF...
> It's better then having people struggle with mod_jk config and feeling
> it's tomcat developer's job to support IIS.
You could also suggest IIS users to switch to Apache 2.0.50 for Windows :)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Schalk Neethling <sc...@volume4.co.za>.
With all the talk about the new jk, I hope of the main focuses will be
to make the integration between Tomcat and Apache a lot easier. I find
that there are very few hosting companies out there that are able to do
this correctly and as such do not support Java/JSP/Servlets. It has come
to a point where some web projects had to be changed to PHP instead of
Java because the client just can not find a host or, the prices for
those who do are extremely high.
I really love the Java language and everything it offers and hope that
there can be a way to make integration and management of a Tomcat/Apache
environment easier for both sys admin and developers.
Andy Armstrong wrote:
> Costin Manolache wrote:
>
>> Maybe the best response to this would be to update the docs and say
>> "tomcat IIS 6 is not supported, plese contact microsoft and ask them
>> to do it". They have plenty of developers and money - they could send
>> a check to Andy and Henri, or do it themself :-)
>
>
> Hey why not? :)
>
> I've just mailed a couple of guys who I /think/ are among the lead IIS
> developers with the subject "IIS / Apache entente cordial"; let's see
> what happens...
>
--
Kind Regards
Schalk Neethling
Web Developer.Designer.Programmer.President
Volume4.Development.Multimedia.Branding
emotionalize.conceptualize.visualize.realize
Tel: +27125468436
Fax: +27125468436
email:schalk@volume4.co.za
web: www.volume4.co.za
This message contains information that is considered to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender. If you received this message in error, please notify me immediately so that I can correct and delete the original email. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Andy Armstrong <an...@hexten.net>.
Costin Manolache wrote:
> Maybe the best response to this would be to update the docs and say
> "tomcat IIS 6 is not supported, plese contact microsoft and ask them to
> do it". They have plenty of developers and money - they could send a
> check to Andy and Henri, or do it themself :-)
Hey why not? :)
I've just mailed a couple of guys who I /think/ are among the lead IIS
developers with the subject "IIS / Apache entente cordial"; let's see
what happens...
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Costin Manolache <cm...@yahoo.com>.
Jess Holle wrote:
> Andy Armstrong wrote:
>
>> Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
>> be rocket
>>
>>> science though. [Dang thing just shows a red down arrow on the
>>> filter whatever you do without giving any real error!]
>>
>>
>> Heh. Having spent two days getting the filter to work on IIS I'm
>> thinking about starting to sell a consultancy service based on getting
>> JK2 working. I actually wrote, debugged, documented and delivered a
>> non trivial ISAPI filter for a different project in less time than it
>> took me to get JK2 working.
>
>
> This is the JK, nor JK2, based connector in my case, but:
>
> 1. There are documented missing configuration steps out on the web
> for IIS 6 that should be verified and placed in the Tomcat isapi
> documentation.
> 2. Any hint as to what to do other than start over again and hope for
> better luck would be great appreciated. [I used the
> 'isapi_install.vbs' script in hopes of having fewer error-prone
> manual steps. Was that a bad idea?]
>
> I'd have kept this off the 'dev' group, but item (1) is quite glaring at
> this point in that there are many reports that one cannot use the Tomcat
> connectors with IIS 6 without extra configuration steps beyond what the
> Tomcat docs provide.
Maybe the best response to this would be to update the docs and say
"tomcat IIS 6 is not supported, plese contact microsoft and ask them to
do it". They have plenty of developers and money - they could send a
check to Andy and Henri, or do it themself :-)
It's better then having people struggle with mod_jk config and feeling
it's tomcat developer's job to support IIS.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Costin Manolache <cm...@yahoo.com>.
Jess Holle wrote:
> Andy Armstrong wrote:
>
>> Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
>> be rocket
>>
>>> science though. [Dang thing just shows a red down arrow on the
>>> filter whatever you do without giving any real error!]
>>
>>
>> Heh. Having spent two days getting the filter to work on IIS I'm
>> thinking about starting to sell a consultancy service based on getting
>> JK2 working. I actually wrote, debugged, documented and delivered a
>> non trivial ISAPI filter for a different project in less time than it
>> took me to get JK2 working.
>
>
> This is the JK, nor JK2, based connector in my case, but:
>
> 1. There are documented missing configuration steps out on the web
> for IIS 6 that should be verified and placed in the Tomcat isapi
> documentation.
> 2. Any hint as to what to do other than start over again and hope for
> better luck would be great appreciated. [I used the
> 'isapi_install.vbs' script in hopes of having fewer error-prone
> manual steps. Was that a bad idea?]
>
> I'd have kept this off the 'dev' group, but item (1) is quite glaring at
> this point in that there are many reports that one cannot use the Tomcat
> connectors with IIS 6 without extra configuration steps beyond what the
> Tomcat docs provide.
Maybe the best response to this would be to update the docs and say
"tomcat IIS 6 is not supported, plese contact microsoft and ask them to
do it". They have plenty of developers and money - they could send a
check to Andy and Henri, or do it themself :-)
It's better then having people struggle with mod_jk config and feeling
it's tomcat developer's job to support IIS.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
Andy Armstrong wrote:
> Jess Holle > Getting the IIS connectors to work with IIS 6 appears to
> be rocket
>
>> science though. [Dang thing just shows a red down arrow on the
>> filter whatever you do without giving any real error!]
>
> Heh. Having spent two days getting the filter to work on IIS I'm
> thinking about starting to sell a consultancy service based on getting
> JK2 working. I actually wrote, debugged, documented and delivered a
> non trivial ISAPI filter for a different project in less time than it
> took me to get JK2 working.
This is the JK, nor JK2, based connector in my case, but:
1. There are documented missing configuration steps out on the web
for IIS 6 that should be verified and placed in the Tomcat isapi
documentation.
2. Any hint as to what to do other than start over again and hope for
better luck would be great appreciated. [I used the
'isapi_install.vbs' script in hopes of having fewer error-prone
manual steps. Was that a bad idea?]
I'd have kept this off the 'dev' group, but item (1) is quite glaring at
this point in that there are many reports that one cannot use the Tomcat
connectors with IIS 6 without extra configuration steps beyond what the
Tomcat docs provide.
--
Jess Holle
Re: Some JK2 ideas
Posted by Andy Armstrong <an...@hexten.net>.
Jess Holle > Getting the IIS connectors to work with IIS 6 appears to be
rocket
> science though. [Dang thing just shows a red down arrow on the filter
> whatever you do without giving any real error!]
Heh. Having spent two days getting the filter to work on IIS I'm
thinking about starting to sell a consultancy service based on getting
JK2 working. I actually wrote, debugged, documented and delivered a non
trivial ISAPI filter for a different project in less time than it took
me to get JK2 working.
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Jess Holle <je...@ptc.com>.
mod_jk with Apache is not that hard.
Actually I believe it is fairly easy....
mod_jk2 is much harder for me to understand.
Getting the IIS connectors to work with IIS 6 appears to be rocket
science though. [Dang thing just shows a red down arrow on the filter
whatever you do without giving any real error!]
--
Jess Holle
Cavan Morris wrote:
> Andy Armstrong wrote:
>
>> I have concrete examples of people giving up on Tomcat altogether for
>> no other reason than the fact that they couldn't get JK configured.
>> By comparison the rest of the task of configuring Tomcat is a walk in
>> the park. Please let's not be so up ourselves that we forget that
>> it's nice for people to actually be able to use the software.
>
>
> As a lurker on this list I can give myself and everyone I've ever
> worked with as concrete examples of some people that have given up on
> 4.1+ tomcat because of JK configuration.
>
> I can count at least 12 projects I have worked on, or am working on,
> that are still on Tomcat 4.0.6 with mod_webapp because we could never
> get JK to do what we wanted. That is, mount this webapp at that URI
> in one line and be done with it. All the other JK features are great
> but 90% of the configurations are going to be like the one I just
> described and no one can figure out how to do it.
>
> I love what you guys are doing. I think you should strive to make the
> most common configuration as simple as mod_webapp and allow people to
> add complexity if their needs require it.
>
> -Cavan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Cavan Morris <cm...@paycom.net>.
Andy Armstrong wrote:
> I have concrete examples of people giving up on Tomcat altogether for
> no other reason than the fact that they couldn't get JK configured. By
> comparison the rest of the task of configuring Tomcat is a walk in the
> park. Please let's not be so up ourselves that we forget that it's
> nice for people to actually be able to use the software.
As a lurker on this list I can give myself and everyone I've ever worked
with as concrete examples of some people that have given up on 4.1+
tomcat because of JK configuration.
I can count at least 12 projects I have worked on, or am working on,
that are still on Tomcat 4.0.6 with mod_webapp because we could never
get JK to do what we wanted. That is, mount this webapp at that URI in
one line and be done with it. All the other JK features are great but
90% of the configurations are going to be like the one I just described
and no one can figure out how to do it.
I love what you guys are doing. I think you should strive to make the
most common configuration as simple as mod_webapp and allow people to
add complexity if their needs require it.
-Cavan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Andy Armstrong <an...@hexten.net>.
Endre Stølsvik wrote:
> All the jk's I've been exposed for -sucks- when it comes to these aspects
> - ANYTHING that makes it easier to use are VERY WELCOME feature.
I have concrete examples of people giving up on Tomcat altogether for no
other reason than the fact that they couldn't get JK configured. By
comparison the rest of the task of configuring Tomcat is a walk in the
park. Please let's not be so up ourselves that we forget that it's nice
for people to actually be able to use the software.
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Remy Maucherat <re...@apache.org>.
Endre Stølsvik wrote:
> On Thu, 15 Jul 2004, jean-frederic clere wrote:
>
> | >
> | >
> | > 2. workers2.properties -> workers2.xml using apr_utils xml support.
> | > Get rid of 'assumed' properties like figuring out the context from url.
> | > Get rid of copying mappings from 'default' to virtual hosts.
> | > Of course, it would require few extra 'boring' statements in the config for
> | > each mapping.
> |
> | -0, that does not bring new features.
>
> What? "Understandability" and "Get-the-SHIT-up-and-God-damn-running-for-
> others-than-people-that-have-master-degrees-in-jk-ibility" aren't features
> for you?
>
> All the jk's I've been exposed for -sucks- when it comes to these aspects
> - ANYTHING that makes it easier to use are VERY WELCOME feature.
Cool that you have useful stuff to contribute. I'll kick you out of this
list, and recommend you don't come back.
Thanks,
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Thu, 15 Jul 2004, jean-frederic clere wrote:
| >
| >
| > 2. workers2.properties -> workers2.xml using apr_utils xml support.
| > Get rid of 'assumed' properties like figuring out the context from url.
| > Get rid of copying mappings from 'default' to virtual hosts.
| > Of course, it would require few extra 'boring' statements in the config for
| > each mapping.
|
| -0, that does not bring new features.
?
What? "Understandability" and "Get-the-SHIT-up-and-God-damn-running-for-
others-than-people-that-have-master-degrees-in-jk-ibility" aren't features
for you?
All the jk's I've been exposed for -sucks- when it comes to these aspects
- ANYTHING that makes it easier to use are VERY WELCOME feature.
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Mladen Turk wrote:
> Hi all,
>
> Seems that the JK2 development has been stalled for a while, cause either
> developers loose the interest, or it's so damn good :)
>
> I would like to propose few things that IMO could make the JK2 a better.
>
> 1. Get rid of JNI from core and make a new 'server/jni/(iis|apace2|xxx)'.
> This new would require java jre on server side. Also focus only on TC5
> embedded mode.
> It would require a lot of work like rewriting aprImpl and TomcatStarter, but
> it should finally work something like Jrun or ServletExec.
> This would be better explained as jk2jni then jk2/jni, but since they will
> be using the same code base...
>
> 1.1 Make APR_JNI project.
> Something like APR_UTIL or APR_ICONV that will give a portable JNI
> interface, using APR.
+1, but may be that is a new project.
>
>
> 2. workers2.properties -> workers2.xml using apr_utils xml support.
> Get rid of 'assumed' properties like figuring out the context from url.
> Get rid of copying mappings from 'default' to virtual hosts.
> Of course, it would require few extra 'boring' statements in the config for
> each mapping.
-0, that does not bring new features.
>
>
> 3. Get rid of Jk2* from Apache module and use only
> 'Jk2On'
> That will register the JK2 in the same way as filter on IIS (for each
> virtual server).
>
>
> All this imply that the workers2.xml is the main config point, meaning that
> the same workers2.xml is operable either on IIS or Apache or any other web
> server. Also there are no other 'per-server' directives rather then 'on or
> off'.
I am not in favour to remove JkUriSet because that makes easy things like
servering fixed pages with Apache and get dynamic ones served by Tomcat.
(see http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk2/davhowto.html)
>
> 4. Get rid of all platform specific configuration stuff like WIN32 registry,
> event log, apache log, and use only JK2 log.
+1.
>
>
> Something like I proposed two years ago, but since people tend to change its
> opinions, and since there was no major proposals for JK2 enhancements for
> two years (not counting myself), do I have a 'card banshee', or do I need to
> make a 'fork'?
>
>
>
>
>
> Waiting for response from someone that can 'provide' something different, or
> just file a veto :)
> MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org