On Wed, 17 Jul 2002, Per Kreipke wrote: > Giacomo, > > > > I feel like a newbie again. > > > > > > It seems as if with every new page or problem to solve, I have > > a large set > > > of choices about where I can store information. But where I > > choose to store > > > something depends on its lifetime, cachability, granularity, etc. > > > > > > In a typical servlet model, I understand the difference in lifetime and > > > scope between contexts (e.g. session, servlet, etc). But in > > Cocoon I don't. > > > > It's the same in Cocoon as it abstracts the Servlet environment. > > You're right of course, I can get at those things from the ObjectModelHelper > and their rules haven't changed. > > What I meant to ask: > - what are the corresponding lifetimes and scopes of Cocoon objects: sitemap > components (generators, etc), the sitemap itself, descriptor files it > references? It confuses me when some things are poolable or in external > files. I can't tell if editing a descriptor file reloads it or whether an > action I wrote is in memory once, twice, once per request, etc.
This is implementation responsability of the corresponding component. > > > I'm having trouble figuring out where to keep application vs. user level > > > settings in a web applicaton using Cocoon without every user > > getting a copy > > > of a global setting, etc. I think most of the confusion centers > > around the > > > repeated use of Source objects and Resolvers throughout C2. > > > > > > Note: I've looked through a most of the C2 code (esp. sunshine) > > and still am > > > fuzzy on some basics. I've also looked through most of the documentation > > > both online and in the 2.0.3 build on my machine. > > > > > > - is the Cocoon Source object the same as the Source in > > Excalibur (doesn't > > > seem so, yet they both seem to be used)? > > > > This might be a migration issue from the porting of the Source package > > from Cocoon to Excalibur. > > Ok. Got it. > > > > - does the resolver automatically cache the source object if > > possible, and > > > also watch for changes (it doesn't seem as if any of the Source's are > > > caching)? > > > > > > - that is, is there little cost to requesting an XML file repeatedly? > > > > > > - does it depend on which protocol (cocoon:, resource:, file:, context:, > > > ...)? > > > > > > - sitemap components have their own config info, and some have external > > > config info (e.g. ValidatorAction descriptor files). Are the > > external config > > > files automatically cached in memory and kept up to date if they change? > > > How: by simply using Source and a resolver? > > > > Component configuration are usually read in at startup and never again. > > Aha. Even external descriptor files? THere's code in some actions about > "reloadable" that makes me wonder. Again, this is implementation responsability of the corresponding component. > > > - sitemap components are stored in and returned from pools, > > each potentially > > > with its own settings, etc. But is the pool a pool of _all_ components > > > together, separate pools for each component type (e.g. one for > > generators, > > > one for matchers), or separate pools for each specific component (e.g. a > > > pool of CIncludeTransformer's, each with their own default settings)? > > > > If a component is Poolable there will be a separate pool for that > > component (one for FileGenerator, CIncludeTransformer, etc.). > > Ok but is it pooled by role or by class name? I assume that each instance > loads its own configurations and only once. Conceptually, I could treat my > own Action with its own configuration as a 'singleton' even if there were > multiple instances in a pool, as long as they all reloaded when necessary You definitively need to read http://jakarta.apache.org/avalon/developing/index.html. This was mentioned several time and IIRC the docs say so, too. > > > - the sun* code expects config information directly in the > > sitemap instead > > > of a separate file. When using the compiled sitemap, that's a > > real nuisance. > > > Is there a way around that? > > > > You need to rewrite the component to have it expect the configuration > > elsewhere and read it in by itself. > > I've looked at the AbstractComplementaryConfigurableAction class and it's > able to load external configurations. I might try to use that to load my > 'app' info. > > > > - when you access the application context in the sun* code, is > > it accessing > > > a single copy for everyone? Where is it actually stored? > > > > I don't know the sun code in depth but generally application context *is* > > one single copy in the system. > > Sorry, should have been explicit: the SunShine code in the 2.0.3. scratchpad > is what I meant. Specifically, the <sunshine:getxml > context="/application"... /> syntax. > > > > - in summary, how/where would one store an XML snippet as essentially a > > > singleton object for use by all users? > > > > Put it in the Context object. > > Ok. I really hate to be a bother but... > > - the new Context interface in 2.1? > - the ServletContext? > - other? Well, generally you should use the Context from the ObjectModel (do not depend on the ServletContext therein as your code might not run if used with the Cocoon CLI version) > I presume you mean the active servlet context. No, the general Context from the ObjectModel: Context ctx = ObjectModelHelper.getContext( objectModel ); > Thanks Giacomo. You made it worth staying up on the U.S. east coast for your > morning ;-) You're welcome :) Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
