Craig Miskell writes:
>> 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 :-).
I suggest we do not mess with ClassLoaders - this can be ugly. Rather we
assume that module JARs are in the CLASSPATH of the application (still may
have some ClassLoader issues, but those are easier to solve). Then we may
introduce a module file extension (so a module named "xyz" will be expected
to have a module file called "xyz.someext"). This would allow cayenne.xml to
reference modules by name, and look them up via ClassLoader instead of
loading jars explicitly.
> 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 :-)
+1 for this (with modifications suggested above that would solve resource
location issues).
>> 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?
We are talking about exactly the same thing, you got it all right.
My concern was that JNDI is only available when you deploy in a container,
and is not universally used. But I guess for non_JNDI users some Ant magic
would allow to work around current limitations by substituting
"xyz.driver.xml" file with the right version for the target environment for
the driver-based DataNodes. I just always thought that having connection
info tied to the project and shared via CVS is a major hassle and a security
issue.
I any event, in the future we may make it simpler by mapping named resources
to the connection sets *locally* in $HOME/.cayenne directory, so that users
could work with DataNodes from CayenneModeler, even if they are JNDI-based.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Oct 28 2002 - 18:08:22 EST