Craig Miskell wrote:
> Just updated from cvs again (beginning to dread these periodic
> adventures :-)), and found that FileConfiguration doesn't quite work
> they way I expected. I started having a poke around, and got confused
> and unsure what is expected behaviour...
Maybe that's because the documentation could be better :-)
Default and File are separate now so that the different lookup strategies
are not mixed. File previously worked only by accident and not at all for
absolute file references, since the project directory was never correctly
used for node loading.
> I'm expecting to be able to do something like this:
> Configuration.initSharedConfig(new FileConfiguration(new
> File("classes/test-cayenne.xml")));
>
> (exactly the way I used to be able to do with DefaultConfiguration).
..which was more accidental than anything else. I do not think this ever
worked with paths that were not also on the classpath. It does now.
If the config files are on the classpath, just use DefaultConfiguration.
If it's on the classpath in a subpackage, add an otherwise empty subclass
of DefaultConfiguration to that package and initialize that. For paths
outside the classpath use FileConfiguration with an absolute path (best);
I don't think paths relative to the current working directory are a good
idea or work. Will check right away & fix if necessary.
> However, it doesn't work, as DefaultConfiguration.getDomainConfiguration
> tries to read DEFAULT_DOMAIN_FILE (cayenne.xml). DefaultConfiguraiton
That's OK, because all Configuration subclasses now consistently use the
ResourceLocator and therefore all the default implementation of
getDomainConfiguration() has to do is use it. :)
DEFAULT_DOMAIN_FILE is now really just the name of the resource to be
found and makes no more assumptions about any package/directory/URL
prefixes or paths.
> has a projectFile ivar which is set by FileConfiguration, but doesn't
dead leftover; gone unnoticed since eclipse cannot properly identify dead
code unless it's private. the real projectFile is in FileConfiguration.
> seem to be used. I'm kind of confused as to what to fix... override
> getDomainConfiguration in FileConfiguration, change it to use
Don't start overriding stuff, the internals are significantly different
than before. I made most of these changes so that all this overriding is
not necessary anymore.
> projectFile instead (and set that to be DEFAULT_DOMAIN_FILE as a default
> value).... ummmmm help?
First of all turn on logging to DEBUG for all of .conf and .util, this is
now very helpful. I'll check the relative file use case right away.
Holger
This archive was generated by hypermail 2.0.0 : Tue Mar 25 2003 - 04:18:36 EST