[EMAIL PROTECTED] wrote:
Just my 2 pence worth (as an apache/tomcat admin in a large company);



- the configuration should be in Apache's config file, rather than some complex properties file

+1


Yes please!


The general idea is to connect to TC and get the URI/VHOST

topology, but we

still need the 'intervene' directives for connector specific ones.
How to make them simpler to use the JK and JK2?

Perhaps using something like:

<CoyoteWorker workerA>
...directives

</CoyoteWorker>

I agreed for this on worker configuration in httpd.conf.


And then:

<Files *.jsp>
  CoyoteUsesWorker workerA
</Files>

ok.

We should also be able to handle :

<Location /myspecialurl>
    CoyoteUsesWorker workerA
</Files>

Something very familiar to Apache admins.



Excellent point in that it needs to be similar to other apache directives.


- it should work well with other modules (I guess if somehow it is accepted into the Apache codebase, it will be required)

That's why we should focus on Apache 2 only module.


Hum, but


Not sure I'm in favor of that (unless you meant dropping

1.3 module by

that).

Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
No more code complexity to handle all the web-servers around,
we should focus on Apache 2.x.


For example majors Linux distributions are now using Apache 2 instead of Apache 1.3. So Apache 2.x will be more and more used.


true.

But from experience most admins will not use the vendor (Sun/Redhat/IBM etc
...) supplier widget as this widget is subject to a vendors patching
schedule.

Hence most admins install their own version outside the normal file system
hierarchy.

So, be in mind that people like me still use 1.3 for many reasons, although
some have moved to 2.x.

What I am trying to say is that do not dismiss 1.3.x unless it is difficult
to include.

Well if we had to support Apache 1.3, will have to support two very different web-server and could make use of APR since Apache 1.3 came
without APR.


And in such case, we'll have to spend time on -dev and -users list
to explain how to make Apache 1.3 with APR support, a waste of time.

If admins want to stay with Apache 1.3, no problem for me, they'll have
to stay with mod_jk 1.2.x.

- I think the protocol should be an extension of AJP/1.3

I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be a good candidate. In my idea we should start to write an APR based
AJP/1.4 library, which could be first used outside Apache 2 server for test and benchs purposes.




+1, but in contradiction with previous :).
I would also like to see the gzip like extension to AJP/xx

for lowering the

data transfer.

It was proposed some times ago together with some light crypto to secure
apache - tomcat link when you're not in a secure network. All of these could be made optional in protocol negociation side of AJP/14...


Crypto and compression would be a very good addition - although not to
ignore the simple connection as it needs to be quick/efficient!

Compression and crypto are negociated at AJP nego time, see the part about MD5 use in both native and java side.

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



Reply via email to