Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Upayavira" <uv@upaya.co.uk>
To: cocoon-dev@xml.apache.org
Date: Fri, 20 Jun 2003 12:52:27 +0100
MIME-Version: 1.0
Subject: RE: Cocoon resource publishing
Message-ID: <3EF3038B.17808.4AFF4B4@localhost>
Priority: normal
In-reply-to: <84F0A43A4248CE45B5C0E20F4C40779C36CA50@naomi.webworks.nl>
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body

On 20 Jun 2003 at 10:24, Unico Hommes wrote:
> > I don't see why the bean couldn't be instantiated with a 
> > cocoon instance:
> > 
> > CocoonBean bean = new CocoonBean(cocoon);
> > 
> > or something like that. So long as the bean code can handle 
> > both possibilities.
> 
> I think the alternative constructor would do it definitely. Although I
> would miss all the functionality that CocoonBean provides for creating
> and initializing Cocoon.

So what functionality are you referring to here? Surely you don't want to go 
configuring the Cocoon instance if it has already been configured elsewhere (by its 
containing servlet).

Are you suggesting that we might want the bean to be able to generate a page from a 
webapp that isn't being served by the servlet?

> > > I also noticed that there is some state associated with CocoonBean
> > > that prevents it from being shared among clients. So 
> > although there is 
> > > a lot of functionality there I'm not sure how to use it in this
> > > multi-threaded multi-client situation.
> > 
> > The bean started as (and still pretty much is) a simple 
> > separation of the CLI Main.java class into two parts. So it 
> > doesn't think at all in terms of multi-threaded environments. 
> > However, I don't see why it couldn't be improved.
> >
> > What 'state' are you referring to?
> 
> I mean state that controls the way processing is done such as
> followLinks flag and state that holds information about a single
> processing run such as the brokenLinks List for instance.
> 
> I'm wondering whether we should split up CocoonBean into a class for
> creating and setting up Cocoon and one that holds all the code related
> to a single run. The former would follow a singleton lifestyle and the
> latter a transient one. What do you think?

So, what do you mean by 'shared between clients'? Would you have the same bean 
running in multiple threads? If so, all of the private variables would need to be 
handled differently. Let's understand exactly what your requirements are, then we can 
look at how we might achieve it.

> > Have you looked at the Target class? Does it seem helpful? 
> > I've added info to the wiki 
> > (wiki.cocoondev.org/Wiki.jsp?page=CommandLine), see section 
> > 7, that explains them a bit more.
> 
> Ah that is a very helpful page. The Target class definitely seems to
> cover my use case.

Great. Glad to hear my ideas work for you!

Regards, Upayavira