cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: Avalon Context from FlowScript
Date Mon, 14 Jun 2004 10:29:24 GMT

On 14 Jun 2004, at 09:59, Jeremy Quinn wrote:

>
> On 13 Jun 2004, at 22:27, Sylvain Wallez wrote:
>
>> Jeremy Quinn wrote:
>>
>>> Hi All
>>>
>>> I am working on a search form to add to the Lucene samples, that 
>>> uses CForms to manipulate a QueryBean that performs queries for you. 
>>> The Bean assembles LuceneQueries directly, so you don't use text 
>>> expressions, you add Criteria to the Query's CForms repeater.
>>>
>>> I am trying to work out how to get the Avalon Context's 
>>> "Constants.CONTEXT_WORK_DIR" from within FlowScript.
>>>
>>> I think I must be confused between 
>>> org.apache.avalon.framework.context.Context and
>>> org.apache.cocoon.environment.Context.
>>>
>>> My FlowScript gets a LuceneCocoonSearcher and needs to set it's 
>>> Directory, all of the other Components that use this Searcher are 
>>> contextualized, so have access to the work directory (which is the 
>>> default location for Lucene Indexes).
>>>
>>> Is there a way to do this from FlowScript?
>>
>>
>> Yes, indirectly, by calling cocoon.createObject on the following 
>> class:
>>
>> public void ContextAccess implements Contextualizable {
>>    Context avalonContext;
>>
>>    public void contextualize(Context avalonContext) {
>>        this.avalonContext = avalonContext;
>>    }
>>
>>    Context getAvalonContext() {
>>        return this.avalonContext;
>>    }
>> }
>>
>> And in your flowscript just type:
>>  var avalonContext = 
>> cocoon.createObject(my.package.ContextAccess).avalonContext;
>>
>
> Many thanks.
>
>
>>
>> This also has some interesting side effects as the full, unrestricted 
>> object model is available through the Avalon context (see 
>> ContextHelper).
>>
>> Remember "Less is more... or less" [1]? I really think it's time to 
>> remove the arbitrary limitations of the FOM.
>
> Because I would otherwise be committing this class to Cocoon, as it is 
> needed for what I am adding to Lucene, and it makes a mockery of the 
> limitations .....
>
>> Sylvain
>
> many thanks for your help.

Then again, this whole issue has arisen because of the decision to keep 
Lucene indexes by default in the Servlet's Work Directory (where they 
are vulnerable to being deleted by the Servlet engine, as they are 
considered to be temporary data).

This is not the greatest place to keep them IMHO.

In our projects, we keep them in WEB-INF :

	{realpath:/WEB-INF}/lucene/my-index

This is much easier, as you can find out this location from the sitemap 
and pass it to whatever needs it, rather than having to have a 
contextualizable component look it up for you.

Is it possible that we could come up with a different default location?
Is WEB-INF/lucene/* a realistic candidate, or does the need to work 
with uncompressed .war files or other environments kibosh this one?

WDYT?

regards Jeremy



--------------------------------------------------------

                   If email from this address is not signed
                                 IT IS NOT FROM ME

                         Always check the label, folks !!!!!
--------------------------------------------------------

Mime
View raw message