Cool, never heard of resource:// url. Not that it couldn't be changed, but the resource lookup will be done in the context of the terracotta class loader for a dso client application (compared to your example of the boot jar tool). All this means is that having the resource on the regular system classpath isn't going to work as one might expect. I haven't tried it though.
-tim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tc-dev- > [EMAIL PROTECTED] On Behalf Of Gary Keim > Sent: Wednesday, June 27, 2007 12:38 PM > To: Taylor Gautier; Nathaniel Harward > Cc: [email protected] > Subject: Re: [tc-dev] Request for feature feedback from developers > > This works: > > % make-boot-jar.sh -f resource:///com/tc/object/tools/default-config.xml > > The resource should be specified absolutely because the lookup is done by, > and relative to, type > com.tc.config.schema.setup.StandardXMLFileConfigurationCreator. > > ----- Original Message ----- > From: "Taylor Gautier" <[EMAIL PROTECTED]> > To: "Nathaniel Harward" <[EMAIL PROTECTED]> > Cc: <[email protected]> > Sent: Tuesday, June 26, 2007 9:28 PM > Subject: Re: [tc-dev] Request for feature feedback from developers > > > > I've been thinking about the deployment process of applications using > > Terracotta, which is slightly tangential to this discussion, however one > > thing I noticed is that the tc-config.xml lives outside the normal > > process - i.e. we require that it live on the filesystem, while a lot of > > work has been done in Java to abstract away from the filesystem itself, > > and put resources on the classpath. > > > > So is there a possibility of allowing the tc-config file to be loaded > > from the classpath instead of a hard file resource? This seems like a > > simple first step for smoothing a lot of deployments including the > > plugin deployments. > > > > If there is already this option, then I am just dumb. > > > > Nathaniel Harward wrote: > >> A large part of the next Terracotta release (2.5) will be integration > >> work and tools to make using Terracotta with other software easier. > >> This includes building a) a plugin for Geronimo and b) a plugin for > >> Maven 2 -- the question before us now is exactly how and what to do on > >> each of these. I would like to outline the high level goals and lines > >> of thought for each subproject and get feedback so that we build them > in > >> a way that will be useful to people. > >> > >> > >> Geronimo > >> > >> > >> The goal here is to create a Terracotta plugin for Geronimo such > >> that Geronimo users can install it in the normal plugin fashion (a > >> few clicks from the console as I understand it) and at a minimum > >> immediately start using Terracotta session clustering. This should > >> be a completely automated process: the user should *not* have to > >> separately download the Terracotta distribution, and ideally not do > >> anything else outside of the Geronimo console/environment to get > >> things going -- this needs to be a very streamlined process. > >> > >> Things we need to investigate: > >> > >> 1. How do users configure Terracotta once the plugin is > installed? > >> 2. Do we have two plugins - one each for the Terracotta client > >> and server with a shared core as a dependency? If not where > >> does the Terracotta server go? > >> 3. How/what do we plug in to the Geronimo console for > management? > >> > >> > >> Maven 2 > >> > >> > >> The goal here is to create a Maven 2 plugin for people to use > >> Terracotta while building and testing their applications; it should > >> support the following use cases: > >> > >> 1. Application level user: user wants to run their tests with > >> Terracotta enabled by running 'mvn test' and specifying the > >> Terracotta plugin as a test dependency > >> 2. Integrator: framework developer wants to create a Terracotta > >> configuration module for their framework; need to run tests > >> with it (as above) as well as package/publish the module when > >> ready. This will require making ManagerUtil and potentially > >> other classes available to integrators at compile time as > well > >> 3. Both types of users should be equipped with Terracotta > >> archetypes if they are starting from scratch > >> > >> Our own configuration modules should be the first victi- er... > users > >> of our Maven 2 plugin, and they will most likely be pulled out of > >> the existing source tree and put on their own. If done we will > also > >> likely pull binary versions of these published configuration > modules > >> when making an official distribution. > >> > >> One goal of this effort is to [when possible] have the maintainers > >> of a framework/appserver/etc. maintain the Terracotta configuration > >> module for their framework/app as they develop and change it, since > >> they know it best and are in the best position to do so. For this > >> to happen the maintainence/build/test/publish process must be easy > >> for them to do and fit into their normal dev/release processes. > >> > >> Things we need to investigate, and in particular what I think could > >> use some feedback: > >> > >> 1. How is the Terracotta configuration going to be done? Do we > >> go with a detached tc-config.xml file, or should we make it > so > >> locks/roots/etc. are defined in the plugin configuration in > >> pom.xml? Does the pom.xml configuration just point to a > >> detached tc-config.xml? > >> 2. The POM already describes dependencies like spring, > libraries, > >> whether or not it's a web application, app. servers, etc. - > >> can we use this to auto-generate a tc-config.xml for 1) > above? > >> 3. Is support for JUnit testing enough initially? TestNG? > Others? > >> > >> > >> I realize this is very high level and a lot of details need to be > sorted > >> out, but hopefully this gives some kind of coherent overview of where > we > >> are trying to go. Please reply if you have feedback or ideas on the > >> matter so we can take them into consideration as we try to hammer this > >> out over the next week. > >> > >> Thanks, > >> Nat > >> _______________________________________________ > >> tc-dev mailing list > >> [email protected] > >> http://lists.terracotta.org/mailman/listinfo/tc-dev > >> > > _______________________________________________ > > tc-dev mailing list > > [email protected] > > http://lists.terracotta.org/mailman/listinfo/tc-dev > > > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
