Maybe we should build those files into one of the Roller jars instead
of leaving them there in the classes dir.
- Dave
On Feb 17, 2006, at 1:52 PM, Allen Gilliland wrote:
On Fri, 2006-02-17 at 10:45, Dave Lindsey wrote:
Thanks Allen,
rollerRuntimeConfigDefs.xml
you should never modify this file yourself.
Ok, then you should probably change the comment at the top of the
file:
<!--
The global-properties represents the base set of roller runtime
properties.
In *most* cases you should be putting your properties here and
they can
then be changed from the admin configuration page at ...
/admin/rollerConfig.do
-->
well ... at least it says that you change them via the admin config
page.
i agree though, i will add a warning suggesting that the file is
not meant to be editied by users.
The site settings page says:
Absolute URL to site (if required), *required for what??*
It appears to be required for planet..
yes, this is a somewhat confusing issue which i don't believe we
have a
solution for yet. the problem is that to build some urls we need
to know
the absolute url desired. unfortunately this can't always be
determined at
runtime, especially in the case of the planet stuff.
Using the Refresh entries button, results in this:
Could not find fetcher.properties on classpath
The Synchronize Roller Weblogs button
results in two : expecting IDENT, found 'group' log messages.
I thought those buttons didn't even work at all, but I'm not
positive. Dave will have to answer that one.
Above the buttons, It says "for testing" .... Testing for dev or
deployment?
yeah, i have no idea what that means either. AFAIK they don't
actually work :/
Can the planet-cache directory be relative like the search-index
and
uploads?
No. It's a full path.
That's too bad, For consistency, it would be nice if it could be
configured
like the other two directories defined in roller.properties.
I didn't even think you could do relative paths for the other
settings to be honest. I suppose it works simply because we don't
actually check that you started the property with a "/" and
therefore when it's used it will be used relative to whatever
directory the jvm thinks it's located at. Hopefully this doesn't
mean you have put these directories inside the WAR directory,
because that is really not a good idea.
It's really not supposed to be used that way though. I'm not sure
why it wouldn't work for the planet-cache directory if it works for
the other props.
-- Allen
-- Allen
Thanks, Dave
