cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <...@onclave.com>
Subject RE: [Q] Conceptual difficulties
Date Wed, 17 Jul 2002 07:59:05 GMT
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.

> > 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.

> > - 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

> > - 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?

I presume you mean the active servlet context.

Thanks Giacomo. You made it worth staying up on the U.S. east coast for your
morning ;-)

Per


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message