On Tue, 17 Jul 2001, Ovidiu Predescu wrote:
> On Tue, 17 Jul 2001 11:26:58 +0200 (CEST), Giacomo Pati <[EMAIL PROTECTED]> wrote:
>
> > Quoting Sylvain Wallez <[EMAIL PROTECTED]>:
> >
> > > What's really missing is a way for components to formally describe their
> > > configuration. For now, the configuration is sometimes specified
> > > textually in the javadoc and often you have to dig in the code to know
> > > what the component expects. This would allow for verification of
> > > configuration and building user-friendly assembly tools.
> >
> > We've started to build up our Avalon components in our company to
> > have a X.role file which contains the role definition and a X.xconf
> > file which contains the configuration definition for the component
> > X. We have planned to build a tool/ant task to combine those
> > fragments into a main roles and xconf file (depending on ant
> > properties which itself may depends on the presence of some classes
> > in the classpath during the build, etc.). Adding to that one can
> > augment the xconf fragment with documentation tags which can be
> > gathered together to build a overall configuration guide by the
> > mentioned tool/task. But so far we haven't had the time to building
> > that tool/task.
> >
> > This tool/task in fact could be usable for C2 as well as there is
> > activity going on to make it more customizable (minimal C2, maximal
> > C2, etc.). And also if we move the <map:components> section into the
> > cocoon.xconf file this is indead very convenient to build up a
> > cocooon.xconf file.
> >
> > Any additional thoughts or even volunteers ;-)
>
> What I think is rather needed is a way to read the X.conf and X.role
> files dynamically at runtime, without the need to append all of them
> in a single file. This is along the same lines as sub-sitemaps.
Well, this thread was started upon documentation thoughts.
> The need for this appears in a totally different environment than Web
> publishing, but could probably be applicable to Web publishing as
> well. In my group at HP, we are looking at Cocoon2 as a framework for
> building Web services (the server side), not only for accessing them
> (the client side).
>
> In this environment the notion of deploying a Web service under
> Cocoon2 should be no different than deploying a new war file. A
> Cocoon2 developed service should be totally contained within a war
> file. This means we should be able to register all the components,
> logicsheets etc. with the main Cocoon2 framework without having to
> rebuild the Cocoon2 war file. The ability to register dynamically
> components, transformers, generators, logicsheets etc. makes a lot of
> sense.
>
> Since all these resources become known to Cocoon2, it would be nice
> for other Web services to reuse some of the resources provided by
> other Web services. A packaging system that lists all the dependencies
> of the package, and the things it provides, very much a la CPAN, would
> be really nice.
I think you'll need to have a look at avalon-phoenix. It would be cool
to have Avalon Blocks around Cocoon2 and deploy it independantly from a
servlet engine into a general server environment which can take all your
needs into account.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
