> Craig Miskell writes:
> > Do these comments help?
> >
> Absolutely. I was trying to wrap my head around this problem for about 4-5
> months now. A fresh view is really needed.
Glad to be of service :-)
> > It also means that for a
> > given set of projects (all accessing overlapping portions of an
> > underlying database) that the persistence layer cannot be split into
> > multiple chunks (like having multiple eomodels in WO... a very useful
> > conceptual thing).
> WebObjects deployment structure has an advantage of being able to identify
> frameworks and their resources explicitly. So cayenne.xml in a predefined
> location (be it a CLASSPATH, or WEB-INF for web applications) was designed
> to fill in this gap, and avoid hardcoding configuration in the code.
An excellent choice... the less hardcoding the better.
> > I think option 3 is definitely the way to go... it allows "split" models
> > (conceptually split) and multiple distinct models (separate vendors
> > maybe), while still permitting the application final say on mapping Maps
> > to Nodes. Despite the extra work I really really really think it's
> > worth it.
<snip>
>
> I guess when deploying a module, we can modify "cayenne.xml" of the source
> project to be called "module-name.cml" or something (or allow starting
> module projects via GUI from the beginning). Module will NOT have any
> connection info (DataNodes). Application will have its own project that has
> a "cayenne.xml" as a main integration point (so it is still one per VM), but
> would allow linking with named modules - just like you suggested.
I'd suggest module projects be distinct from the start. I guess a module
might require some sort of unifying xml file to list DataMaps, perhaps a
module.xml. A given module would only have one module.xml (fairly clear,
obvious, and non-restrictive), which would (I'm guessing here) be at some
well-known location within the module jar file. Then the application
cayenne.xml could refer to the jar file and let cayenne find the
module.xml. Of course, this presumes something on the class
loader/resource locating... I'm getting out of my depth here and need to
do some reading :-).
If we ignore some of the mechanics, I think making "module.xml" a
different beast from cayenne.xml helps separating their roles and uses.
Also avoids renaming stuff :-)
>
> This seems like a sensible way to solve deployment of multiple libraries,
> though it will require serious GUI modifications. I wonder what holes still
> need to be plugged here?
Resource location... see above. I'll do some more reading sometime today
hopefully... try and figure it out. (Or if somebody knows more about
clean ways of locating resources within, say, specific jar files, I'd love
to hear it)
> There is one more problem left to solve : how to allow an easy change of
> connection information across the environments. But this is a separate
> issue...
And, might I suggest, one that Cayenne needn't do much to solve? All that
cayenne need do is require a named resource (jndi is good for this), and
allow the deployment environment to specify the actual connection info.
Or am I missing the point?
Craig Miskell
Programmer, Black Albatross, Otago University, New Zealand
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s+:- a-->? C++++(++)$ ULXH+++$>++++ P+>++++ L++$>++++$ E--- W+++$
N+ K? w--- !O M-- V? PS--- PE Y t++ 5 X+++ R-- tv+ b+>+++ DI++++ D+ G+ e++
h--- r+++ y+++
------END GEEK CODE BLOCK------
This archive was generated by hypermail 2.0.0 : Mon Oct 28 2002 - 16:57:10 EST