> > > 2. EMBPERL_OBJECT_BASE does not seem to work in my Location pragma
> > > - given the config below, I would just get an error in the
> > > embperl.log about 'kaka.epl' not being found.
> >
> > This looks like the EMBPERL_APPNAME isn't set inside the Location block
> > (Yes, I see it's there, but maybe it wasn't when you does this test?)
>
> Unfortunately it was there. I just double checked again to be sure.
>
That's strange. I use it here without any problems and your config seems to
be alright.
Do you have mod_info running? If yes, please send me it's the output of the
embperl.c section.
If it's loaded/compiled in you can configure it via
<location /server-info>
SetHandler server-info
</location>
and request the page at /server-info
>
> Understandable -- as this is how I found the optDisableChdir -- looking
> to turn this function off to increase performance. For functionality
> however -- could I suggest that you provide some means to 'enable'
> this? I agree it should be off by default, but it could be handy, and
> remove a headache or two if you start mixing external and internal
> calls...
>
I put this "optEnableChdir" on the TODO list
>
> All of my tests had the EMBPERL_URIMATCH set to only process .htm? and
> .epl files. Ahhh, but that gave me an idea. Yup -- looks like if I
> take the EMBPERL_URIMATCH out of the Location block it works.
>
> But it is '403 Forbidden' again if I set
> EMBPERL_ALLOW (\.htm.?|\.epl$)
> in the 'root' level (ie just in the .conf file, not within a block).
> But I can still snag a .txt, which means the ALLOW is working, and the
> URIMATCH is as well (the .txt has emmperl code in it for a test).
That's ok, because the directory ('/') will not match against your ALLOW
mask, so Embperl returns a Forbidden.
As I said before, I plan to change this, so that directories always return a
DECLINED, that gives the normal Apache processing to make it's normal
processing and come back with the index.html. Then it would work the way you
exptected it. For now you have to use the URIMATCH workaround and allow
directories in your ALLOW regex.
>
> This still leaves the problem with EMBPERL_APPNAME which is not working
> like it should, or some of these variables do not work within such blocks.
> Do I need an EMBPERL_APP as well? (the logs show it using Embperl, which
> is my guess for what I would set it as)
>
There is no EMBPERL_APP, only a EMBPERL_OBJECT_APP, which you don't need. It
gives a filename, where you can define your own application class, to
override/extent some of Embperl functions.
> No mean to harp here, as I think this is great stuff and love the work.
> I know that such large changes that are currently being invoked are not
easy.
>
> I *do* however have some concerns about this stuff in production, which
> I previously didn't. (2.0b5 seemed really stable)
>
> Opinions and recommendations anyone?
>
>From my point of view b7 is more stable then b5. I use b7 for all my new
projects. There are more problems with the configuration system, because
that part is really new and the interaction with APache/mod_perl isn't
always easy (because you have to support a bunch of different
configurations), but when I have to choose, I would always use b7 instead of
b5.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
