Re: Avalon Context from FlowScript

[Jeremy Quinn]

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

smime.p7s
Description: S/MIME cryptographic signature