Mixing your web applications at the classpath level sounds a bit
dangerous. I have many cayenne apps running on the same tomcat
instance with no problems. Some of them even shared mappings ( well
copies of the same mappings ), some even hit the same database.
The big thing is that I keep the web application classloaders seperate.
-- Joshua T. Pyle Go has always existed.On 7/13/05, Gentry, Michael (Contractor) <michael_gentr..anniemae.com> wrote: > Well, since they are completely separate (different CVS repositories), I > don't think klunking together an uber-cayenne.xml is quite the ticket, > either. > > I've been stepping through the Cayenne configuration process and it uses > the first cayenne.xml it finds and then stops looking. This might be > more Java CLASSPATH related than anything -- you find the first one and > that has priority over all others. I'd even be happy if you could > specify the name of cayenne.xml (like with EOF/EOModeler -- you can name > the models differently), but I just tried that in Cayenne Modeler and it > puked an exception to my screen. > > I don't think addClassPath would work since it would append to the > CLASSPATH and my cayenne.xml #2 is already in the CLASSPATH, it is just > overshadowed by #1. > > The more I'm thinking about this the more I think the best solution > would be to modify the modeler to allow you to specify the filename > (such as foo.cayenne and bar.cayenne) and then modify the Cayenne > configuration process to load all *.cayenne XML files it finds in the > CLASSPATH. This would give you the most flexibility, eliminate this > development and potential production choke point (1), and even allow you > to associate *.cayenne files with an application instead of just a > generic XML file. > > Any thoughts? > > Thanks, > > /dev/mrg > > (1) Imagine you put together a Cayenne based project (free/shareware or > commercial) that is designed to be a standalone framework (integrated > into other projects). The current approach would make it difficult for > a customer to integrate your framework into their Cayenne-based > application, since there are two cayenne.xml files (the framework and > the client code). If they had different filenames, that problem would > be solved ... > > > -----Original Message----- > From: Mike Kienenberger [mailto:mkienen..laska.net] > Sent: Wednesday, July 13, 2005 4:57 PM > To: cayenne-use..bjectstyle.org > Cc: cayenne-use..bjectstyle.org > Subject: Re: Interesting Tomcat (et al) Issue ... > > > "Gentry, Michael (Contractor)" <michael_gentr..anniemae.com> wrote: > > Well ... > > > > cayenne.xml #1: 6 Domains, Sybase > > cayenne.xml #2: 1 Domain, PostgreSQL > > > > They are completely unrelated. There are three (at the moment) > Tapestry > > apps I have under development. Two of them use #1, one of them uses > #2. > > Both are in the CLASSPATH, but #1 shows up first, and that is the only > > one visible to all three apps, so the third app cannot use the DB > unless > > I shut down the other two and remove the projects (which would be > rather > > inconvenient). > > Yes, I was proposing > > cayenne.xml #3: 7 Domains, Sybase and PostgreSQL > > Or if it's just a matter of classpaths, put the files in separate > locations > for each app. > > public void contextInitialized(ServletContextEvent event) > { > DefaultConfiguration conf = new DefaultConfiguration(); > conf.addClassPath("path/to/your/cayenne/config"); > Configuration.initializeSharedConfiguration(conf); > } >
This archive was generated by hypermail 2.0.0 : Wed Jul 13 2005 - 17:26:49 EDT