cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <>
Subject RE: Cocoon resource publishing
Date Mon, 23 Jun 2003 10:33:56 GMT

Hi, sorry for replying so late, I have been experiencing mail problems
and had to dig this one up from the archives.

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

No, but I could use it wherever I do create and configure it. Be that in
a servlet or in an Avalon embedded component. Although it wouldn't be a
problem to do that without the help of a utility class and I am doing
exactly that right now, my suggestion was that it might be useful.

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'm saying that I see two separate areas of concern that CocoonBean
could be useful for me. One is to help create and configure Cocoon, the
other is to help run Cocoon and gather information about these runs. The
former would be useful for me in a thread safe type component where I
create and manage a shared cocoon instance, the latter I'd like to use
in the per-thread situation of a publication request.

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

I mean that the same Cocoon instance be accessible from different
locations in the system. One client of this "Cocoon service" would the
HttpServlet that handles regular http calls. Another a mail system that
publishes pages over smtp, and yet another that receives commands to
push pages onto a remote server as part of a publication action.

Actually that was what I started out from, because the publication
system I have now follows this exact approach. It accesses the same
Cocoon instance that is used to handle http requests as well. Since it
is separated from the http servlet I needed to put the Cocoon instance
somewhere from where I could access it from both locations. 

But it isn't necessarily required for me to keep these two clients
separated. It's just the way it works for me now, and divorcing Cocoon
management from the code using it, is something that would be generally
useful I think.

Would you have the same bean running in multiple threads?

No, the bean can be single threaded, but I would be running multiple
CocoonBeans sharing the same Cocoon concurrently.

Let's understand exactly what your requirements are, then we can 
look at how we might achieve it.

OK, thanks for sticking with me so long, I hope I am not being too
annoying ;)

The basic requirement that I have is that of a webservice that pushes
files onto a target location such as a remote FTP server. I consider two
different approaches. One is to integrate the service with Cocoon as it
now runs as a servlet or come up with an implementation that is separate
from it. 

In the former case, publication requests might involve a protocol that
is similar to Cocoon views. I am thinking that the sitemap could have a
"targets" section that defines publication locations, the default being
just the stream to the requesting client browser. Then, similar to the
way views work, a cocoon request could be made by optionally specifying
the target to publish to:

The other possibility is keeping the publication service separate from
the CocoonServlet. Configuration would be outside the sitemap and I
would need a way to share CocoonServlet's Cocoon and
PublicationService's Cocoon.

I think I prefer the first approach because it wouldn't require
additional setup and configuration is right where you'd expect it to be.
Seems cleaner somehow. It also circumvents the issue of sharing the
Cocoon instances we were discussing before. On the other hand, http
being a request-response type of affair, the browser response is not
well defined. There's also the additional complexity added to the core
of Cocoon.


View raw message