Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BBD8BCB.9B7901BA@apache.org>
Date: Fri, 05 Oct 2001 12:30:35 +0200
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Cocoon web applications
References: <A5374D237E78D41195810090279CC91A03E0435F@xcup04.cup.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"KUMAR,PANKAJ (HP-Cupertino,ex1)" wrote:
> 
> Hi,
> 
> I am not really an expert on Cocoon's internal architecture but have been
> using it for something other than web publishing. Hope, this brings a
> different perspective to the discussion ( I have keenly read the exchange
> between Stefano and Berin ).
> 
> I do have some thoughts on the **need** to have easily deployable "Cocoon
> Web Application".

Great, the more input we receive, the better.

> The way I have been looking at Cocoon is that it gives me a framework to
> assemble my processing pipelines.

This is exactly how users should look at it.

> I develop my application as a set of
> processing pipelines ( and the underlying components, XSPs and whatever else
> you need ), and test it by modifying the sitemap.xmap, cocoon.xconf, copying
> .jar and other files at appropriate locations.
>
> How do I release my application? I could build a huge .war with everything
> in it ( including the Cocoon stuff ). As Stefano pointed out and I believe
> most of us would agree, it is not the most desirable situation. Currently I
> do it this way, but it is not elegant. What I would really love to have is
> mechanism by which I could supply just my stuff ( as an archive file with
> certain directory structure ) and make an existing Cocoon deployment to run
> it. I believe this is what Stefano proposed.

Exactly.

> For some time, I wondered whether Cocoon needs to do this ( classloader and
> security context mgmt. ) or are J2EE Containers ( Servlet Container, EJB
> Container etc. ) better suited for this job. Two things make me think that a
> separate context mgmt. by Cocoon is desirable: (i) Servelt containers do not
> allow a "hierarchy" of deployable units ( so Cocoon can't have its
> deployable units as servlets and still allow them to use its classes and
> resources );

Correct, even if there are hacks to go around this, but they are not
portable across servlet engines.

> (ii) Cocoon may be deployed as containers other than Servlet.
> Let me elaborate on this: as usage of XML becomes more and more widespread,
> people would need Cocoon like framework for areas other than Web publishing.
> Examples include: building "Business Service Interface" compliant to higher
> level protocols such as ebXML, RNIF or BizTalk; building web services that
> need signficant XML handling ( say a program that validates and manipulates
> RosettaNet PIP ).
> 
> Now, one could argue that Cocoon is Web Publishing Framework and it doesn't
> need to worry about other usage. Well, isn't the beauty of a technology is
> its usage and extension in ways not thought out by its originators?

I think both your points are good ones and clearly make us think that it
is definately worthwhile to work on internal context management that
better suits our needs.

Thanks for you comments: the more people see cocoon extending in
different directions, the more users we can attract, the better the
community becomes, the better the software evolves.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

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