Hi David,
thanks for your feedback.
"David W. Taylor" wrote:
> 1. Please describe the Logging .properties file in more detail. In the end I
> discovered that I don't need it but it confused me as I debugged the
> cayenne.xml discovery problem at 2 below.
Did you see chapter 13.6 "Configuring Logging" or was it not descriptive
enough?
> 2. Please describe the four states for the "cayenne.xml" discovery code.
It's more complicated than only ResourceLocator; in fact resource lookup
necessary for bootstrapping something is way more complicated than many
people imagine. Anyway, the missing docs on Configuration are squarely my
fault; I've already written some more but need to finish and commit it.
AFAICT I'll have time for this starting tomorrow, so that it will be part
of the upcoming beta-3 release.
> The code that uses them in DefaultConfiguration is:
>
> l.setSkipAbsolutePath(true);
> l.setSkipClasspath(false);
> l.setSkipCurrentDirectory(true);
> l.setSkipHomeDirectory(false);
>
> Where are these documented? In the end to get things working, I changed
> the last to false.
That was, unfortunately, very wrong. :-) As you correctly found out,
concrete Configuration subclasses use a ResourceLocator to actually find &
load things. I need to document this, but you're not supposed to change
this behaviour unless you expect 'surprising' (i.e. random) results. For
historical reasons the Configuration's ResourceLocator is public (IMHO it
shouldn't be, to prevent the error you made) and DefaultConfiguration
should really better be called ClasspathConfiguration, but isn't. Maybe in
the next version.
So how do we solve your setup woes? There are several ways:
- put your cayenne.xml etc. files on the top-level classpath of your
project. This will work immediately, no messing required.
- if you want to put them in a subdirectory of your classpath (aka a Java
package), create an empty subclass (except for Constructors) of
DefaultConfiguration, put it into the package in question and use
Configuration.initializeSharedConfiguration(new YourConfiguration()) to
set up everything. The subclass is necessary because (AFAIK) loading
classes is the only reliable way in Java to find stuff in unresolved
packages, as it is often the case on startup. java.lang.Package does _not_
contain all available packages after startup, only the ones that have so
far been referenced by the class loader; this makes it unsuitable for
resource lookup. There's nothing I can do about that.
- if you want to have stuff in the filesystem outside your classpath, use
FileConfiguration - it was made exactly for that purpose and is quite
flexible:
// default configuration file name (cayenne.xml)
conf = new FileConfiguration();
// custom named configuration file
conf = new FileConfiguration("myapp-cayenne.xml");
// add a search path that is checked for existence
conf.getResourceLocator().addFilesystemPath(new File("/temp"));
// add a possibly existing search path
conf.getResourceLocator().addFilesystemPath("foo");
Paths can be relative to the "current working directory" or absolute. The
File version checks the argument, the String version doesn't (nice for
ordered lookups in several places).
More about all this can be found in the javadocs for Configuration,
DefaultConfiguration and FileConfiguration. Running applications in a
Servlet container adds another level of complexity, because of security
and other constraints; see BasicServletConfiguration and
WebApplicationListener.
> 3. Please document the use of the types.xml file, which is used for each
> database type. It is stored only in the .jar file beside each
> xxxxAdapter.class file in org.objectstyle.cayenne.dba.mysql, for example.
I'm curious - why would you need it? This is only used internally.
> 4. Please update the web site. The link for Jakarta Log4J package, version
> 1.2.7 in the User Guide incorrectly points at Jakarta ORO Regular
> Expressions package.
done!
> 5. Building with source using JBuilder instead of Ant needs the source for
> org.objectstyle.ashwood.xxxx to be available. The download for Ashwood uses
> the obsolete package layout net.ash.dbutil instead of
> org.objectstyle.ashwood.xxxx. (I cobbled together a .jar file to get around
> this by deleting all other classes from the main .jar file and renaming it.)
I think this must be done by Andrus or Andriy (Ashwood's dad).
> 6. Now that I am working I have configuration files in three distinct
> locations: the "Home" directory
See above - the .xml files should simply be in the project.
> the "Home"\.cayenne directory and the
This is used mainly for Modeler's preferences and log file (if enabled);
you _can_ put the cayenne-log.properties log4j file there for development,
but it's not really necessary. It's mostly historical since Modeler used
to work with JDK 1.3 which had no built-in Preferences system. OTOH on
UNIX the JDK 1.4 preferences system simply writes to your $HOME as well,
so it's not much of a difference anyway.
> org.objectstyle.cayenne.dba.mysql directory. This seems confusing. How
The last one is definitely wrong. You never need to put stuff into
framework packages, and the JDBC types mapping should not be your concern.
> about everything useful being in the "Home"\.cayenne directory?
Technically possible, but not useful for a multitude of non-obvious
reasons (security, obscurity, deployability..) :(
Anyway, I hope these tips get you back on track! Please let us know how
they worked for you and about any other oddities that you find.
Holger
This archive was generated by hypermail 2.0.0 : Sun May 11 2003 - 07:40:50 EDT