Andrus Adamchik wrote:
> Historically the requirement to have a single "start" file in the known
> location to load Cayenne configuration has always been a real problem.
> So I like your idea of moving Java package concept closer to the
> "bundle" or "framework". I think this is fresh ;-). This makes
Thanks, glad you like it. In the absence of something like NSBundle,
simply using a class package seems odd at first (if you think to much in
terms of filesystems) but really is a nice, clean solution. Unfortunately
requiring everything in one package kind of defeats a lot of the
flexibility that is mentioned about data node loading in the deploy docs.
One good way around this would be to look in the referenced package first,
and then in the root (like it is now) as fallback.
> cool new way of doing things. A few random ideas to make it easier for
> end users:
>
> - Generate MyConfiguration from the modeler (originally I was thinking
> Bcel, but I don't like the idea of runtime class generation)
I thought about this as well, but it's IMHO not worth the hassle. Creating
an empty subclass takes 3 seconds and you only have to do it once.
> - Make Configuration look for system property corresponding to
> configuration subclass (say "cayenne.config.class"), so no extra Java
> code is required to start an alt configuration
This is nice for the default, when no package is explicitly given, but
probably will not work when you have multiple 'applications' running in
the same VM and the same classloader, e.g. two cooperating subsystems that
need independent DataMaps. Tricky..
> - (most important) Create documentation explaning all available
> configurations, and when and how to use them. COnfusing the users is the
> last thing we want. For example:
>
> Config Type Steps
> ----------------------
> Default Put cayenne.xml in CLASSPATH
> Package Put cayenne.xml in the package in CLASSPATH
> ServletConfiguration Put cayenne.xml in app/WEB-INF
Current default still has the problem that the File constructor doesn't
work - what about that, fix or remove? Also the current Default config is
just a 'fallback case' of PackageConfiguration; I'll try to merge both,
add the config.class property and see how it goes, OK?
have a nice weekend & don't get killed by too much work :)
Holger
This archive was generated by hypermail 2.0.0 : Sat Mar 01 2003 - 17:00:22 EST