cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject RE: [Q] Conceptual difficulties
Date Wed, 17 Jul 2002 08:10:07 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message