Return-Path: 
 <cocoon-dev-return-12273-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 75011 invoked by uid 500); 10 Apr 2001 14:10:49 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 74905 invoked from network); 10 Apr 2001 14:10:44 -0000
Message-ID: <3AD313DE.76D79DB3@apache.org>
Date: Tue, 10 Apr 2001 10:08:30 -0400
From: Berin Loritsch <bloritsch@apache.org>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: AW: [C2]: Avalon Component Configuration
References: <NEBBLPMLKKCJBKEOKNFHGEGLDPAA.cziegeler@sundn.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Carsten Ziegeler wrote:
> 
> > Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cziegeler@sundn.de>:
> >
> > > Hi,
> > >
> > > I am trying to add new avalon components to the
> > > cocoon.xconf (yes, for caching of course....) and am
> > > now a little bit confused about the format.
> > >
> > > E.g. the parser has the following entries:
> > >   <parser class="org.apache.cocoon.components.parser.JaxpParser"/>
> > >
> > >  <role name="org.apache.cocoon.components.parser.Parser"
> > >        shorthand="parser"
> > >        default-class="org.apache.cocoon.components.parser.JaxpParser"/>
> > >
> > > Is the first one obsolete? I thought the second declaration adds
> > > a component with the role name "parser".
> >
> > I'm not sure if the definition of the role is sufficent to define
> > the component
> > without the absolute minimum component definition (which in this
> > case would be
> > <parser/>). Berin, have you any comments on this handy?
> >
> > > For the URL Factory I found:
> > >   <url-factory>
> > >     <protocol name="resource"
> > > class="org.apache.cocoon.components.url.ResourceURLFactory"/>
> > >     <protocol name="context"
> > > class="org.apache.cocoon.components.url.ContextURLFactory"/>
> > >   </url-factory>
> > >
> > >  <role name="org.apache.cocoon.components.url.URLFactory"
> > >        shorthand="url-factory"
> > >        default-class="org.apache.cocoon.components.url.URLFactoryImpl"/>
> > >
> > > Is the second one the definition for the role and the first one the
> > > configuration for this role?
> >
> > Here the role states that a component specified as <url-factory>
> > (because of the
> > shorthand attribute) represented by class
> > org.apache.cocoon.components.url.URLFactoryImpl will implement
> > the working
> > interface org.apache.cocoon.components.url.URLFactory. It might
> > be possible to
> > rewrite that using a ComponentSelector similar to the
> > specification of the
> > DataSource component.
> >
> > Generally the role element defines shorthands for component
> > definition. Thus the
> > complete definition for the URLFactory without a role definition will be:
> >
> >  <component role="org.apache.cocoon.components.url.URLFactory"
> >            class="org.apache.cocoon.components.url.URLFactoryImpl">
> >    <protocol name="resource"
> >        class="org.apache.cocoon.components.url.ResourceURLFactory"/>
> >    <protocol name="context"
> >        class="org.apache.cocoon.components.url.ContextURLFactory"/>
> >  </component>
> >
> > And yes, the <protocol> elements are configurations for the
> > url-factory only.
> >
> And the lookup of the components is done via the role name, correct?
> So, looking up "org.apache.cocoon.components.url.URLFactory" would
> work. Would it be also sufficient to lookup "url-factory"?

No.  That is a configuration time only convenience mapping.

> I am asking this, because I want to use the Store for storing the
> cached content. This would allow to use existing interfaces and
> implementations for the caching.
> But I don't want to use the normal <store> component but an explicit
> Store for the caching which might have another implementation.
> Is this possible?

If the Component has a discrete role that is separate from the "store"
role, then it is a different role altogether.  In other words,  You
can use more than one instance of the MemoryStore component when the
roles are different.  The <store/> instance is for caching of Templates
and other runtime objects.  You can create a <cache/> role that uses
another instance of that Store object.

Or, you can simply share the MemoryStore object.

> I know, I could create another Interface, like XMLStore, which
> extends Store and implement that - but then I could not use any
> Store implementation for caching. An own (inheriting) implementation
> is required to implement the XMLStore interface.

The role name is a String, and by pattern, it is mapped to the Interface
that the Component implements.  However, there can be deviations based
on certain criteria: Components that are accessed via selectors usually
append "Selector" to the interface name, and Components that share API
but not purpose may have an artificially distinct role name from the
interface--but try to maintain concistancy.

IOW:

Component Interface:

org.apache.cocoon.components.store.Store      (Interface Name)

Roles:

org.apache.cocoon.components.store.Store      (current role for object cache)
org.apache.cocoon.components.store.Repository (role for XSP repository)
org.apache.cocoon.components.store.Cache      (new role for XML cache)

The Store and Cache roles can both implement instances of the MemmoryStore
object, and all three can share the Store interface, but the roles are
distinct from each other and follow Avalon patterns.

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