Thanks for taking to the time to help.
I have interspersed my answers. Remember that the primary aim here was for
me to be able to run the Cayenne tutorial command line sample *** in
JBuilder ***. The secondary aim was to be able to build the sample *** from
source in JBuilder. ***
I can now do both.
David
----- Original Message -----
From: "Holger Hoffstätte" <holge..izards.de>
To: <cayenne-use..bjectstyle.org>
Sent: Sunday, May 11, 2003 4:40 AM
Subject: Re: Newbie: suggestions for help with JBuilder....
>
> 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?
>
No, thanks for pointing this out.
> > 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.
With some tweaking this was fairly easy. It was not obvious to a newbie
that the classpath would be searched for non-class files.
>
> - 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.
>
This is a JBuilder oddity. Until very recently it was not convenient
to add non .class files to the classes directory at compile time. It is a
common trick for files like this to be hidden in .jar files but it is hard
to arrange for XML files such as this to be forced to nestle with .class
files in this fashion. The reason that JBuilder creates a classes directory
afresh every time is to use its own compiler, which adds debugging
information to the file.
When the classes are finally debugged and ready for deployment adding XML
files in this fashion is trivial as the .jar files are built. The problem
is only evident while in edit, compile and debug mode, when the classes
execute from the classes directory and not from the .jar file.
.
.
.
>
> Holger
This archive was generated by hypermail 2.0.0 : Sun May 11 2003 - 16:16:21 EDT