Hi Michael,
Thanks for the response. I've sorted the problem with the headers now. I
think these which mainly occurred due to the app having evolved from CGI
-> MP1 -> MP2, and has been hacked on each transition until it worked,
but with some unnecessary detritus being left behind (including a
combination of CGI/CA and MP method calls on the query object). These
worked ok under MP1 but not MP2, so this was not directly a CA issue.
Have you tried using the normal CGI::App methods for doing headers? I think
C::A::P::Apache tries to send those out through mod_perl at the very end.
$self->header_add('Content-disposition' => "attachment;filename=$sid.jnlp");
return $template->output;
Using the header_add method generates a similar error as the header_type
method:
Can't locate auto/CGI/Application/Plugin/Apache/Request/header_add.al
For the sake of the list archives, it looks like the header_type (and
header_add) methods come from CGI::Application, but are not available
when using CAP::Apache::Request as the query object, hence the errors
resulting from a failed attempt to autoload the methods (although this
was happy enough under MP1). I've therefore removed the
$query->header_type('none');
line, and using the MP2 style
$query->headers_out->{"Content-disposition"} = "attachment;filename=$sid.jnlp";
produces the required Content-disposition header. Additionally, I was
using 'send_http_header' to set the Content-type (which seemed fine in
conjunction with header-type=>none), but this is fixed by simply using
the content_type method instead:
$query->content_type('application/x-java-jnlp-file');
Again, the install may not work exactly like it should on MP2. If you have some
time I'd greatly appreciate any efforts to make it work better on MP2.
Having looked further into the code, CAP::Apache itself seems fine, with
all the necessary Apache -> Apache2 differences all handled within
version specific conditional blocks. but the problems I hit were in
CAP::Apache::Request, which still has all the modules are in the
'Apache' namespace. The cases where these are 'use'd can be handled by a
'require xxx; import xxx';' in a conditional block as in CAP::Apache,
but I think the big problem is with the subclassing, since 'use base'
does not appear amenable to such treatment.
I saw in the list archives that you do not want to have separate modules
for MP1/MP2, but I suspect to some extent that is inevitable here. The
cleanest way I can think of is to create separate (but minimalist...)
CAPA::Request and CAPA2::Request classes which inherit from
Apache::Request and Apache2::Request respectively, then create a
separate subclass containing the rest of the code which can require and
import the appropriate CAPA(2?)::Request module according to the flavour
of mod_perl being used. The MP1/MP2 specific code could then either be
split into the appropriate classes (probably cleaner...), or just left
in the generic subclass with conditional statements as it is at present
if you prefer keeping it together. This would also need a hack to the
CAPA use the correct class for the query object if CAPA_CGI_Compat is
enabled.
I can have a go at coding this up if you don't think it's too wacky or
there is something horribly wrong with my logic....
Cheers,
James
--
Dr. James Abbott
Bioinformatics Software Developer
Imperial College, London
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
