[Q] Conceptual difficulties

[Per Kreipke <pe...@onclave.com>]

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.

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

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

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

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

- when you access the application context in the sun* code, is it accessing
a single copy for everyone? Where is it actually stored?

- in summary, how/where would one store an XML snippet as essentially a
singleton object for use by all users?

- is there an architectural overview I've missed (it's not really covered by
the UML diagrams in the Dev section of the docs)?

Thanks in advance,
Per Kreipke


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

Re: [Q] Conceptual difficulties

[Ugo Cei <u....@cbim.it>]

Sylvain Wallez wrote:
> Ugo Cei wrote:
>> Isn't the interpreted sitemap the default in 2.0.3?
> Yes and no :
> - the interpreted sitemap is used if your cocoon.xconf contains only 
> <sitemap/>
> - the shipped cocoon.xconf explicitely specifies <sitemap 
> class="org.apache.cocoon.sitemap.SitemapManager"/> which is the compiled 
> engine.

That's nice to know. Thanks.

	Ugo


-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it


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

Re: [Q] Conceptual difficulties

[Sylvain Wallez <sy...@anyware-tech.com>]

Ugo Cei wrote:

> Carsten Ziegeler wrote:
>
>> No, there is no way around it - again with 2.1 the interpreted sitemap
>> is used instead and this is no longer a problem. Remember, the sunshine
>> components are for the 2.0.3 branch in the scratchpad.
>
>
> Isn't the interpreted sitemap the default in 2.0.3?


Yes and no :
- the interpreted sitemap is used if your cocoon.xconf contains only 
<sitemap/>
- the shipped cocoon.xconf explicitely specifies <sitemap 
class="org.apache.cocoon.sitemap.SitemapManager"/> which is the compiled 
engine.

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




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

Re: [Q] Conceptual difficulties

[Ugo Cei <u....@cbim.it>]

Carsten Ziegeler wrote:
> No, there is no way around it - again with 2.1 the interpreted sitemap
> is used instead and this is no longer a problem. Remember, the sunshine
> components are for the 2.0.3 branch in the scratchpad.

Isn't the interpreted sitemap the default in 2.0.3?

	Ugo

-- 
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it


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

RE: [Q] Conceptual difficulties

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
>
> Carsten,
>
> Good morning, thanks for your reply.
>
Thanks - I try to do my best...

> <snip/>
>
> > > - 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)?
> > >
> > The current impl. does no caching - it is possible to implement it.
>
> Hmm. Let me state it differently: many times, the result of loading (an
> Action's) configuration is kept in memory and then if the source is
> modified, it is reloaded. This is, in effect, an in memory cache (it's not
> re-parsed upon every request).
>
Yes.

> The annoyance I see everywhere is that the same code/checks are
> repeated in
> every Action that wants this behavior (e.g. the Validators, DB actions,
> etc). I was hoping there was an easy way to load an XML fragment in memory
> and keep it current with respect to the file on disk. But not to reread it
> on every access. I'm pretty sure you do some things like this in the
> SunShine code.
>
Hmm, I'm not so sure if the sunShine code does this. But the general pattern
I know is exactly the one you describe above: you get a source object,
load your XML in memory and each time you use it, you first check the source
object if it is still valid - if not, you have to reload it.
I'm currently not aware of a better solution - but perhaps it exists.

>
> > No, there is no way around it - again with 2.1 the interpreted sitemap
> > is used instead and this is no longer a problem. Remember, the sunshine
> > components are for the 2.0.3 branch in the scratchpad.
>
> In the docs, there is an example that suggests the application
> config being
> loaded. Snippet:
>
> <handler ...>
>    ...
>    <application ...>
>        <load uri="" />
>
>
Ah, ok - it's perhaps a little bit misnamed - it is the configuration for
the application but on a per user base! So each user gets his own set
of configuration for the application for customizing it.

> Aside: I like the SunShine concept a lot, and would love to use it instead
> of futzing around with building something similar but I can't
> figure out how
> to integrate logic with the sunshine tags since they get handled by a
> transformer, not a generator. I'll detail some questions about that in a
> separate thread.
>
You make me curious!

> > > - when you access the application context in the sun* code, is it
> > > accessing
> > > a single copy for everyone? Where is it actually stored?
> > >
> > Yes, each user has his own context. It's therefore stored in
> the session.
>
> Ok. But some things aren't user specific, they're application specific.
> Every user should share a single copy of those settings, no?

Yes, I agree with you, but unfortunately the current implementation does it
on a per user base as described above.
But this can be extended of course.

>
> <no-fault-critique>
> I wish they weren't called contexts, it confuses things a bit since that
> terminology already exists.
> </no-fault-critique>
Yes, I agree here, too, that's why they are called SessionContext...
No, seriously, Context is really overloaded but we felt that it is the
right name for this at that time.

Regards
Carsten


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

RE: [Q] Conceptual difficulties

[Per Kreipke <pe...@onclave.com>]

Carsten,

Good morning, thanks for your reply.

> > <snip/>
> >
> > - is the Cocoon Source object the same as the Source in
> Excalibur (doesn't
> > seem so, yet they both seem to be used)?
> In 2.0.3 (or from 2.0 to 2.0.4-dev) only the Cocoon source object is used.
> We moved the source resolving to excalibur and starting with 2.1 only the
> excalibur source resolving is used. As this is an incompatible change,
> this will happen when we release 2.1. There are additional wrapper classes
> to maintain as much compatibility as possible.

Ok.

> > - 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)?
> >
> The current impl. does no caching - it is possible to implement it.

Hmm. Let me state it differently: many times, the result of loading (an
Action's) configuration is kept in memory and then if the source is
modified, it is reloaded. This is, in effect, an in memory cache (it's not
re-parsed upon every request).

The annoyance I see everywhere is that the same code/checks are repeated in
every Action that wants this behavior (e.g. the Validators, DB actions,
etc). I was hoping there was an easy way to load an XML fragment in memory
and keep it current with respect to the file on disk. But not to reread it
on every access. I'm pretty sure you do some things like this in the
SunShine code.

> > - 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?
> >
> I assume you mean the sunshine, sunrise etc. code and not something from
> Sun...

Sorry, yes, the SunShine code.

> No, there is no way around it - again with 2.1 the interpreted sitemap
> is used instead and this is no longer a problem. Remember, the sunshine
> components are for the 2.0.3 branch in the scratchpad.

In the docs, there is an example that suggests the application config being
loaded. Snippet:

<handler ...>
   ...
   <application ...>
       <load uri="" />


Aside: I like the SunShine concept a lot, and would love to use it instead
of futzing around with building something similar but I can't figure out how
to integrate logic with the sunshine tags since they get handled by a
transformer, not a generator. I'll detail some questions about that in a
separate thread.

> > - when you access the application context in the sun* code, is it
> > accessing
> > a single copy for everyone? Where is it actually stored?
> >
> Yes, each user has his own context. It's therefore stored in the session.

Ok. But some things aren't user specific, they're application specific.
Every user should share a single copy of those settings, no?

<no-fault-critique>
I wish they weren't called contexts, it confuses things a bit since that
terminology already exists.
</no-fault-critique>

Thanks, Per


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

RE: [Q] Conceptual difficulties

[Carsten Ziegeler <cz...@s-und-n.de>]

Per Kreipke wrote:
> <snip/>
>
> - is the Cocoon Source object the same as the Source in Excalibur (doesn't
> seem so, yet they both seem to be used)?
In 2.0.3 (or from 2.0 to 2.0.4-dev) only the Cocoon source object is used.
We moved the source resolving to excalibur and starting with 2.1 only the
excalibur source resolving is used. As this is an incompatible change,
this will happen when we release 2.1. There are additional wrapper classes
to maintain as much compatibility as possible.

>
> - 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)?
>
The current impl. does no caching - it is possible to implement it.

> - 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?
>
I assume you mean the sunshine, sunrise etc. code and not something from
Sun...
No, there is no way around it - again with 2.1 the interpreted sitemap
is used instead and this is no longer a problem. Remember, the sunshine
components are for the 2.0.3 branch in the scratchpad.

> - when you access the application context in the sun* code, is it
> accessing
> a single copy for everyone? Where is it actually stored?
>
Yes, each user has his own context. It's therefore stored in the session.

Carsten


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

RE: [Q] Conceptual difficulties

[Giacomo Pati <gi...@apache.org>]

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

RE: [Q] Conceptual difficulties

[Per Kreipke <pe...@onclave.com>]

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

Re: [Q] Conceptual difficulties

[Giacomo Pati <gi...@apache.org>]

On Wed, 17 Jul 2002, Per Kreipke wrote:

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

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

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

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

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

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

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

Giacomo


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