On Oct 28, 2007, at 08:32:50, Rainer Jung wrote:

Hi,

BuildSmart wrote:
I'm trying to get around a configuration issue.
My webapp builds dynamic script content but the generated scripts are not accessible. For example, calling http://domain.tld/index.jsp? ip=192.168.0.10&count=10&key=robot" should generate some subdirectories and builds some jsp pages with content and this seems to work as expected but from apache these are not accessible but from the Tomcat port I can access the pages without issue, is there a way to resolve this?

With respect to what is following below, I'm not actually sure, if I understand, what you mean by "not accessible".

"not accessible" means apache cannot access the pages, gives an error --> page does not exist.

if the content pages that are built have the following paths:
<docroot>/index.jsp <-- the main page
<docroot>/example/user.jsp <-- generated by main page
<docroot>/example/data.jsp <-- generated by main page

I cannot access any pages in examples directory from apache.

I cannot code the subdirectory because they are generated on the fly and I do not know in advance that they are.

I cannot use /* because apache also has other content handlers like php and then Tomcat errors on the php file.


I can't pre-define the mount points for the subdirectories because I don't know what they are in advance, there doesn't seem to be a way to define access to Tomcat based on the file extension since it wont let you assign a mount point without a leading "/".

JkMount /*.jsp myworker

would be perfectly valid. You can combine prefixes and suffixes.
If there are no rules at all (no known prefixes and no known suffixes) then your URL space is weird and you can only use

JkMount /* myworker

and live with the consequences :(

In case it would be easier to describe, what *not* to forward, you can combine JkMount with JkUnmount

Now I'd be getting into a complicated and bastardized configuration.


See

http://tomcat.apache.org/connectors-doc/reference/apache.html
and
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html

See further comments inline.

Maybe I should be using a different protocol that allows assignment by file extension (if one exists) but google has done nothing but create more confusion for me.
_______________________________________
My apache config contains:
_______________________________________
<IfModule mod_jk.c>
    JKWorkersFile /etc/httpd/workers.ajp13.properties
    JKLogFile /var/log/httpd/mod_jk.log
    JKLogLevel debug
    JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

That was our old default JkLogStampFormat. If you omit the lines, you will get milliseconds for free starting with mod_jk 1.2.25.

    JkMount /*.jsp ajp13

Uups: there you are, you already use a suffix pattern!

    JkOptions +ForwardKeySize +ForwardURICompat

It's very likely, that you won't need the +ForwardURICompat when using an up-to-date mod_jk.

</IfModule>
_______________________________________
my workers.ajp13.properties contains:
_______________________________________
ps=/

This defines a variable ps, which you are never using. Simply delete this.

# Define 1 real worker using ajp13
worker.list=ajp13
# ------------------------
# First worker server
# ------------------------
# Set properties for ajp13 (ajp13)
worker.ajp13.host=localhost
worker.ajp13.port=8019
worker.ajp13.type=ajp13
worker.ajp13.lbfactor=1
#
# END workers.properties
#
_______________________________________
-- Dale

Regards,

Rainer

Forgive me for complaining but why on earth has no servlet handler/ module been developed that processes by file extension rather than only by context.

It would be nice to do:
jkMount *.jsp ajp13

then all .jsp files would be processed by the handler, of course mod_jk doesn't allow it and to do it by file extension would be too intelligent and renders a lot of current configuration complicated methods obsolete.

adding mode_rewrite or having to configure more than a single webapp host makes no sense if all you want to do is gain access to the java engine to deploy pgaes from within apache and having to define more than one host/port in Tomcat is a retarded concept by any standards.

I believe that one host/port can be used by any apache virtualhost to server pages from the apache virtualhost DOCUMENT_ROOT and not the webapp docroot making it's implementation far more dynamic and useable rather than all the complicated configuring of the current methods discussed on this list.

A good example of this in action is BlueDragon, it has a custom connector and a module to handle the communication between the webapp server and apache.

Adobe CF does something similiar with mod_jrun but it's configuration is a little more complicated and also not a free useable solution.

BlueDragon makes integration and use from apache very easy to achieve, does not require telling the webapp server where the apache DOCUMENT_ROOT's are and servers the pages from the apache DOCUMENT_ROOT's and not the webapp docroots which is a far more intelligent solution.

Currently due to the lack of functionality based on the current ajp connector and mod_jk, my current solution to execute the .jsp files from the apache DOCUMENT_ROOT's is limited to the .jsp files being at the first level of the DOCUMENT_ROOT because mod_jk is too stupid to allow mapping by file extension and this is not acceptable.

If it involves more than a simple configuration of the apache module then the method is tainted.

I want to server the .jsp pages from any apache DOCUMENT_ROOT without requiring a degree to configure several modules to achieve the goal.

I'd pay someone to write the connector and module for me cause my java skills suck but I'm currently so dumb-founded that no one else has achieved or even complained that the current method of implementation is useless in a production environment where apache virtualhosts are the norm.

I have a partial solution based on the modified Ajp13Connector class and a modified mod_jk module but as I stated earlier, it's limited to the first level of DOCUMENT_ROOT because mapping by file extension is not possible.

-- Dale



Attachment: PGP.sig
Description: This is a digitally signed message part

Reply via email to