You are viewing a plain text version of this content. The canonical link for it is here.

Posted to community@apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/10/30 14:29:12 UTC

[important proposal] Cocoon as official Apache project

Ladies and gentlemen,

it is with *great* pleasure that I'm finally feel confident enough to 
ask you about something that is been in the back of my mind for more 
than a year now.

The proposal of making cocoon an official top-level Apache project.

                                  - o -

Before I state the proposal and its implications, allow me to introduce 
the context.

Currently, Cocoon is not officially considered a 'project' under the ASF 
bylaws. Cocoon is, in fact, part of the Apache XML Project just like 
Xalan Xerces Fop Batik and the others.

The ASF was designed round the concept of having one big legal umbrella 
(the foundation) and several focused development communities (the projects).

The original idea was, in fact, modeled after how the Apache Group 
managed the Apache HTTPD project.

Unfortunately, the ASF members thought that the same model could well 
apply to projects which did not release software directly (unlike HTTPD 
did) and decided to use the same model for jakarta and xml (which don't 
release software directly, but add another level of indirection with 
subprojects).

The concept and the term "subproject" was, in fact, invented to separate 
the development community from the container.

Over the years, it became clear that project containment yields several 
drawbacks:

  1) container PMCs don't do anything since they are too detached from 
the actual code (it's impossible they know all about all the code hosted 
by the single containers!)

  2) the subproject committers never have a way to interact directly 
with the foundation, thus they perceive it as a distant and bureaucratic 
thing

  3) the ASF doesn't have proper legal oversight on the code contained 
in all sub-projects

  4) the trend of sub-projecting created sub-containers (avalon and 
turbine, for example), thus making all this even worse.

  5) the creation of sub-brands and the confusion this created. Example: 
is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?

Over the last 18 months, several members tried to convince the ASF board 
that this situation was potentially very dangerous since, in fact, the 
container projects started to behave more and more as sub-foundations, 
but without the proper legal understanding. This situation was 
potentially inflammable in the case of a legal action against a 
committer since the foundation might not have been able to properly 
legally shield that committer since it operated outside the bylaws and 
without proper PMC oversight.

Over the same period, several very influential members and board 
officials were against this notion, stating that it was just a human 
problem with the people elected on the PMC and *not* a problem in the 
design of the foundation.

After a few new PMC elections, and after finally having a jakarta/xml 
member elected on the board (Sam Ruby), things are finally starting to 
change.

The ASF board agrees on an open policy on the creation of new top-level 
Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.

So, in the light of this, I would like to hear your comments on the idea 
of moving out of xml.apache.org into our own project.

                             - o -

Before you start asking a bunch of questions, let me answer a few of 
them that I might consider FAQs.

1) what are the contract changes that the proposal implies? [note, all 
these are not carved in stone, but just here to give you an idea]

Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org 
redirected.

The cocoon-*@xml.apache.org mail lists will be moved to 
{1}@cocoon.apache.org.

The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module 
moved into hybernation state and stored for historical reasons only.

NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no 
need to change anything there. [I planned this in advance at least two 
years ago, so that's why the namespace was already clean]

2) what does it mean for the developers?

An official Cocoon project will have an official PMC which is what is 
legally reponsible for the code and reports directly to the board. The 
PMC officer becomes a vice-president of the ASF.

In order to avoid stupid PMC elections, I'll be in favor of having the 
PMC composed by *all* committers that ask to be part of it. This to 
imply that committers and legal protector share the same duties and 
priviledges.

In short, it means that if any of us screws legally, the foundation will 
protect us. Today, this is not the case.

3) what does it mean for Cocoon?

Being a project allows us to host several different incubation-stage 
efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins 
could be possible additions. Of course, with the idea of promoting them 
as top-level projects when they are successful from a community perspective.

Also, it means that we could have our own machine running the entire 
cocoon.apache.org web site (that means: finally having Cocoon serving 
its own pages!)

Last but not least, it will give much more visibility to Cocoon since it 
will be visible directly from www.apache.org

4) what are the drawbacks?

moving stuff around is always annoying, but I think this is the only 
major drawback.

5) isn't this unfair against the other sub-projects that remain 
contained, therefore with less visibility?

I don't know. Here I'm just stating the intention to move Cocoon to 
top-level and I know the ASF board is very open to projects willing to 
move out of their containers.

But the ASF will *NOT* force projects to take this action. If other 
communities feel they should deserve top-level projects, they should 
make a proposal like this and ask the board instead of complaining with 
us that we do it.

6) isn't a cocoon-related project too specific? wouldn't it be better to 
have something like 'publishing.apache.org' and host all 
publishing-related stuff there?

No, it would be a smaller container, but still a container where the PMC 
and the committers are not the same entity.

HTTPD is a project about a modular HTTP server written in C, it's not a 
container for all HTTP-related server technology, nor it would be of any 
help if it became one.

I think the ASF should stop forcing project to remain in containers but 
simply allow them to choose to step up.

Cocoon.apache.org will be the community of people around Cocoon and will 
host, develop and distribute cocoon and cocoon-related software. And the 
PMC will be directly supervising because it will be composed by all 
committers of all cvs modules it will host.

Also, stuff like Cocoon is very hard to make it fit into a single category.


7) how do we move this further?

First thing to do is to have a formal votation. All committers should 
express their vote on this, right here:

  [ ] +1  I think it's a good idea
  [ ]  0  I really don't care.
  [ ] -1, I don't think it's a good idea.

Please, vote clearly so that it's easy to make good summaries. If you 
vote -1, please state your reasoning and propose a creative solution for 
the problems this proposal tries to address.

After the votation we'll see what to do.

Thanks.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------

Re: [important proposal] Cocoon as official Apache project

Posted by Stefano Mazzocchi <st...@apache.org>.

Steven Noels wrote:

> Stefano Mazzocchi wrote:
>
> > I think that having a machine name detached from any domain name would
> > help a lot both in communication and in perception of hardware
> > neutrality. If Nagoya was called 'e4500.sunlabs.org' I think people
> > would be less friendly to that, don't you think?
>
>
> or nagoya.betaversion.org :-D

No, you didn't get my point. I don't want to be dense, but I think this 
is a very important.

The name of the machine is 'nagoya' and there are at least two different 
DNSs that point to it: 'apache.org' and 'betaversion.org' (the second 
being mostly for critical fail-over, nagoya acts as secondary DNS for 
betaversion.org but just that)

If we keep 'cocoondev.org' as the machine name and we move it to the 
Apache DNS, do you think people will like to have a DNS entry like

  cocoondev.org.apache.org

I already hear Pierpaolo screaming *very* loud if you propose that :)

> > To avoid having to explicitly indicating this to *every* ASF
> > individual we'll have to confront to about this (and there will be a
> > lot, ASF members tend to be very conservative, expecially about
> > infrastructural issues), I strongly suggest you give a name to that
> > machine and start referring to it with that name instead of with the
> > domain name it currently binds to.
>
>
> any idea? The machine name IS cocoondev.org - so if it really must be
> changed, I'd rather let the community decide. OTOH, nagoya's machine
> name hasn't much to do with apache, neither.

Neither deadalus or icarus.

But you're right, we should have this community decide the name.

Just let's do this after the votation is over, please.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------




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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Stefano Mazzocchi wrote:

> I think that having a machine name detached from any domain name would 
> help a lot both in communication and in perception of hardware 
> neutrality. If Nagoya was called 'e4500.sunlabs.org' I think people 
> would be less friendly to that, don't you think?

or nagoya.betaversion.org :-D

> To avoid having to explicitly indicating this to *every* ASF individual 
> we'll have to confront to about this (and there will be a lot, ASF 
> members tend to be very conservative, expecially about infrastructural 
> issues), I strongly suggest you give a name to that machine and start 
> referring to it with that name instead of with the domain name it 
> currently binds to.

any idea? The machine name IS cocoondev.org - so if it really must be 
changed, I'd rather let the community decide. OTOH, nagoya's machine 
name hasn't much to do with apache, neither.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Ivelin Ivanov wrote:

> What are the machines there? CPU, RAM, HDD, OS, etc.
> Steven probably mentioned that on the cocoondev list already,
> but I must have missed it.

Intel P4 2.0 GHz, 2*80 Gig HD, 1 Gig RAM

[stevenn@cocoondev stevenn]$ uname -a
Linux cocoondev.org 2.4.18-17.7.x #1 Tue Oct 8 13:33:14 EDT 2002 i686 
unknown

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

Where is cocoondev.org hosted? Kansas?

Ping from Austin, Texas is good: ~30ms.

What are the machines there? CPU, RAM, HDD, OS, etc.
Steven probably mentioned that on the cocoondev list already,
but I must have missed it.



Ivelin


----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Cc: "Dirk-Willem van Gulik" <di...@covalent.net>
Sent: Thursday, October 31, 2002 6:07 PM
Subject: Re: [important proposal] Cocoon as official Apache project


> Steven Noels wrote:
>
> > Carsten Ziegeler wrote:
> >
> > > But, *if* Cocoon becomes a top-level project, I'm not sure if it is
also
> > > a good thing to use cocoondev.org as the infrastructure. Now I see
> > > two possible problems:
> > >
> > > a) What is hosted where? Is a mailing list hosted at apache or at
> > >    cocoondev.org etc. Of course, this might not be a big thing, but
> > >    it could confuse others.
> > >    We could use cocoondev.org for example for show casing Cocoon
> > >    and everything else is hosted at apache.
> >
> >
> > First things first: cocoondev.org is simply a machine name, and it is
> > currently listening to/hosting outerthought.org, forrest.cocoondev.org,
> > and whatever name we could invent for it: the joy of DNS :-)
> >
> > So when I say cocoondev.org, I simply mean the machine (and its
> > primary name, which even could be changed if we really would like to).
>
> I think that having a machine name detached from any domain name would
> help a lot both in communication and in perception of hardware
> neutrality. If Nagoya was called 'e4500.sunlabs.org' I think people
> would be less friendly to that, don't you think?
>
> > Technically, I was thinking along these lines: we use cocoondev.org
> > (the machine) to host the new website and the developers community
> > website, which is being ProxyPassed [1] by daedalus or nagoya as
> > cocoon.apache.org. That way, we leverage [2] the existing bandwidth
> > availability and are able to use the lowered load on our (= the cocoon
> > community) own machine for 'cool stuff'. The main website can make use
> > of all dynamic features we would like to use, but with some clever
> > expiry header setting we still can benefit of a reverse proxy, formed
> > by nagoya or daedalus.
> >
> > [1] http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypass
> > [2] buzzword bingo: 1 point :-)
>
> I like that very much! In fact, I was planning to have a transparent
> proxy on top of any live cocoon system to reduce its load using
> proxy-friendly http headers.
>
> >
> > Lists for Cocoon-core development should stay at daedalus, as cvs for
> > Cocoon-core should stay at icarus, but maybe, if someone builds a cool
> > webmailarchive using Cocoon, we would be able to run that software on
> > our own machine, without heavy lobbying of 'the powers that be' at
> > infrastructure@apache.org.
>
> I love it.
>
> > Mind you that I really appreciate the hardware resources so kindly
> > offered by Collab & Sun, but given the broad range of projects &
> > services they have to support, and the inevitable burden that comes
> > with this, I believe everybody will be better off if we do our own
> > thing ("we" and "our" as in the Cocoon developers community), maybe
> > reverse proxied by nagoya for load & bandwidth purposes.
>
> Amen.
>
> > Along the Cocoon-core website and the possible developers community
> > website (of which the Wiki could be part), there is still space to
> > host other Cocoon-related projects, part of the initial version behind
> > cocoondev.org.
>
> I see no problems with that.
>
> Just understand that anything that is not contained into a *.apache.org
> domain will not be protected by the ASF legal umbrella. So, I like the
> parallel between mozilla.org and mozdev.org and I think it would make
> sanse to do so here, maybe using cocoondev.org as an incubator for
> cocoon-related stuff with greater visibility than simply throwing it
> into sourceforge and get lost.
>
> >
> > > b) Legal issues. To be honest, I don't know much about legal things,
> > >    but I guess that it might make a difference if something is done
> > >    on a server hosted by apache or on a server not hosted by apache.
> >
> >
> > See Ovidiu's remark - those machines aren't necesserally owned by the
> > ASF, I believe - and I'm pretty sure the bandwidth bills are paid by
> > Collab, not by the ASF. The reason for investigating possible official
> > endorsement by the ASF (dunnow how that would look like, but anyhow -
> > maybe http://xml.apache.org/ack.html comes close ;-) is exactly to
> > make sure that eventual legal issues are covered (Dirk?).
>
> I think the legal protection comes from the URL space not from the
> actual location of the machine or by who pays the bandwidth. Also note
> that php.apache.org redirects to www.php.net which is an official ASF
> project (even if many members are not that happy with the way PHP has
> managed to have special status, but this is a different story)
>
> >
> >
> > > Don't get me wrong, I really like the idea of cocoondev.org and as
long
> > > as Cocoon is not a top-level project, it's the only way.
> > > But if we become a top-level project, I really like the idea to "fix
> > > the current problems/shortcommings" here at Apache.
> > >
> > > Perhaps we can talk more about this at the gettogether.
> >
> >
> > Yeah, but let's try to use the list so that non-attendees are being
> > informed, too. We've just seen what happens if people don't understand
> > each other because of non-explicit communication :-)
>
> Or when people use domain names to refer to machines ;-P
>
> When you told me privately that you wanted to have cocoondev.org under
> the Cocoon PMC and I said 'hmmm, maybe this is too much' and you pissed
> off, it was simply because I thought you wanted the Cocoon PMC to
> superview a non-ASF web site. See where all this non-explicitness came
> from? [not saying this is your fault, but I think that I didn't make
> anything implicit]
>
> To avoid having to explicitly indicating this to *every* ASF individual
> we'll have to confront to about this (and there will be a lot, ASF
> members tend to be very conservative, expecially about infrastructural
> issues), I strongly suggest you give a name to that machine and start
> referring to it with that name instead of with the domain name it
> currently binds to.
>
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

RE: [important proposal] Cocoon as official Apache project

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

Stefano Mazzocchi wrote:
> 
> Steven Noels wrote:
> 
> > Carsten Ziegeler wrote:
> >

> 
> I see no problems with that.
> 
> Just understand that anything that is not contained into a *.apache.org 
> domain will not be protected by the ASF legal umbrella. So, I like the 
> parallel between mozilla.org and mozdev.org and I think it would make 
> sanse to do so here, maybe using cocoondev.org as an incubator for 
> cocoon-related stuff with greater visibility than simply throwing it 
> into sourceforge and get lost.
> 
I didn't know it, but I guessed that everything which is not reachable
by *.apache.org is not protected by the ASF, so in fact that was/is my
greatest concern.
By all the answers I get, this problem seems to be solved now. So let's
see if Cocoon becomes an official Apache project - I really hope so.

Carsten

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

Re: [important proposal] Cocoon as official Apache project

Posted by Stefano Mazzocchi <st...@apache.org>.

Steven Noels wrote:

> Carsten Ziegeler wrote:
>
> > But, *if* Cocoon becomes a top-level project, I'm not sure if it is also
> > a good thing to use cocoondev.org as the infrastructure. Now I see
> > two possible problems:
> >
> > a) What is hosted where? Is a mailing list hosted at apache or at
> >    cocoondev.org etc. Of course, this might not be a big thing, but
> >    it could confuse others.
> >    We could use cocoondev.org for example for show casing Cocoon
> >    and everything else is hosted at apache.
>
>
> First things first: cocoondev.org is simply a machine name, and it is
> currently listening to/hosting outerthought.org, forrest.cocoondev.org,
> and whatever name we could invent for it: the joy of DNS :-)
>
> So when I say cocoondev.org, I simply mean the machine (and its 
> primary name, which even could be changed if we really would like to).

I think that having a machine name detached from any domain name would 
help a lot both in communication and in perception of hardware 
neutrality. If Nagoya was called 'e4500.sunlabs.org' I think people 
would be less friendly to that, don't you think?

> Technically, I was thinking along these lines: we use cocoondev.org 
> (the machine) to host the new website and the developers community 
> website, which is being ProxyPassed [1] by daedalus or nagoya as
> cocoon.apache.org. That way, we leverage [2] the existing bandwidth
> availability and are able to use the lowered load on our (= the cocoon
> community) own machine for 'cool stuff'. The main website can make use
> of all dynamic features we would like to use, but with some clever
> expiry header setting we still can benefit of a reverse proxy, formed 
> by nagoya or daedalus.
>
> [1] http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypass
> [2] buzzword bingo: 1 point :-)

I like that very much! In fact, I was planning to have a transparent 
proxy on top of any live cocoon system to reduce its load using 
proxy-friendly http headers.

>
> Lists for Cocoon-core development should stay at daedalus, as cvs for
> Cocoon-core should stay at icarus, but maybe, if someone builds a cool
> webmailarchive using Cocoon, we would be able to run that software on
> our own machine, without heavy lobbying of 'the powers that be' at
> infrastructure@apache.org.

I love it.

> Mind you that I really appreciate the hardware resources so kindly
> offered by Collab & Sun, but given the broad range of projects &
> services they have to support, and the inevitable burden that comes 
> with this, I believe everybody will be better off if we do our own 
> thing ("we" and "our" as in the Cocoon developers community), maybe 
> reverse proxied by nagoya for load & bandwidth purposes.

Amen.

> Along the Cocoon-core website and the possible developers community
> website (of which the Wiki could be part), there is still space to 
> host other Cocoon-related projects, part of the initial version behind
> cocoondev.org.

I see no problems with that.

Just understand that anything that is not contained into a *.apache.org 
domain will not be protected by the ASF legal umbrella. So, I like the 
parallel between mozilla.org and mozdev.org and I think it would make 
sanse to do so here, maybe using cocoondev.org as an incubator for 
cocoon-related stuff with greater visibility than simply throwing it 
into sourceforge and get lost.

>
> > b) Legal issues. To be honest, I don't know much about legal things,
> >    but I guess that it might make a difference if something is done
> >    on a server hosted by apache or on a server not hosted by apache.
>
>
> See Ovidiu's remark - those machines aren't necesserally owned by the
> ASF, I believe - and I'm pretty sure the bandwidth bills are paid by
> Collab, not by the ASF. The reason for investigating possible official
> endorsement by the ASF (dunnow how that would look like, but anyhow -
> maybe http://xml.apache.org/ack.html comes close ;-) is exactly to 
> make sure that eventual legal issues are covered (Dirk?).

I think the legal protection comes from the URL space not from the 
actual location of the machine or by who pays the bandwidth. Also note 
that php.apache.org redirects to www.php.net which is an official ASF 
project (even if many members are not that happy with the way PHP has 
managed to have special status, but this is a different story)

>
>
> > Don't get me wrong, I really like the idea of cocoondev.org and as long
> > as Cocoon is not a top-level project, it's the only way.
> > But if we become a top-level project, I really like the idea to "fix
> > the current problems/shortcommings" here at Apache.
> >
> > Perhaps we can talk more about this at the gettogether.
>
>
> Yeah, but let's try to use the list so that non-attendees are being
> informed, too. We've just seen what happens if people don't understand
> each other because of non-explicit communication :-)

Or when people use domain names to refer to machines ;-P

When you told me privately that you wanted to have cocoondev.org under 
the Cocoon PMC and I said 'hmmm, maybe this is too much' and you pissed 
off, it was simply because I thought you wanted the Cocoon PMC to 
superview a non-ASF web site. See where all this non-explicitness came 
from? [not saying this is your fault, but I think that I didn't make 
anything implicit]

To avoid having to explicitly indicating this to *every* ASF individual 
we'll have to confront to about this (and there will be a lot, ASF 
members tend to be very conservative, expecially about infrastructural 
issues), I strongly suggest you give a name to that machine and start 
referring to it with that name instead of with the domain name it 
currently binds to.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------

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

Re: [important proposal] Cocoon as official Apache project

Posted by Vadim Gritsenko <va...@verizon.net>.

Jeremy Quinn wrote:

>
> On Monday, Nov 4, 2002, at 14:53 Europe/London, Vadim Gritsenko wrote:
>
>> You need to use CachingCInclude transformer which provides caching 
>> abilities. Result will be cached as long as all parts are valid, i.e. 
>> validity of whole pipeline is created using validities of aggregated 
>> parts.
>>
>
> Hi Vadim,
>
> I got a bit confused with the different includers available .....
>
> Looking at CInclude and CachingCInclude Transformers, they appear to 
> have diverged quite a bit with regards to their parameterisation.
>
> The CIncludeTransformer has an 'ignoreErrors' parameter in it's new 
> form, that looks quite useful for my component system.
>
> Oh well ..... when this project's out the door, I can have a look at 
> synchronising them (if no one else has done it by then ;) 


Ping Andrew (acoliver@apache.org) - he expressed once desire to create 
one codebase out of all Cocoon includes.

Vadim



> Thanks for your suggestion.
>
> regards Jeremy




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

Re: [important proposal] Cocoon as official Apache project

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Monday, Nov 4, 2002, at 14:53 Europe/London, Vadim Gritsenko wrote:

> You need to use CachingCInclude transformer which provides caching 
> abilities. Result will be cached as long as all parts are valid, i.e. 
> validity of whole pipeline is created using validities of aggregated 
> parts.
>

Hi Vadim,

I got a bit confused with the different includers available .....

Looking at CInclude and CachingCInclude Transformers, they appear to 
have diverged quite a bit with regards to their parameterisation.

The CIncludeTransformer has an 'ignoreErrors' parameter in it's new 
form, that looks quite useful for my component system.

Oh well ..... when this project's out the door, I can have a look at 
synchronising them (if no one else has done it by then ;)

Thanks for your suggestion.

regards Jeremy

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

Re: [important proposal] Cocoon as official Apache project

Posted by Vadim Gritsenko <va...@verizon.net>.

Ivelin Ivanov wrote:

>Interesting question.
>I am not sure if and how CInclude treats Cache and Expire headers.
>I think it simply reads the URL resource.
>

Ivelin,

Jeremy aggregates internal pipelines, thus there is no URL resources 
here, but Cocoon internal pipelines.


>If it was using Jakarta HttpClient as the WebServiceProxyGenerator is,
>it would cache content.
>If you have time you can probably consider contributing this improvement.
>

Jeremy,

You need to use CachingCInclude transformer which provides caching 
abilities. Result will be cached as long as all parts are valid, i.e. 
validity of whole pipeline is created using validities of aggregated parts.

Vadim


>Ivelin
>
>
>----- Original Message ----- 
>From: "Jeremy Quinn" <je...@media.demon.co.uk>
>To: <co...@xml.apache.org>
>Sent: Sunday, November 03, 2002 4:55 AM
>Subject: Re: [important proposal] Cocoon as official Apache project
>
>
>  
>
>>On Saturday, Nov 2, 2002, at 15:51 Europe/London, Ivelin Ivanov wrote:
>>
>>    
>>
>>>So the expire tag has a double benefit. First it lightens the load on 
>>>the
>>>app server, because the web server caches and second it lightens the 
>>>load on
>>>the web server when the the browser has read the content once.
>>>
>>>      
>>>
>>Thanks for this, yes it really works well!
>>
>>Do you have any recommendations how to manage caching on internal 
>>pipelines?
>>
>>I have a <component/> architecture in my current project that uses 
>>cinclude to import internal pipelines into documents that helps keep 
>>component implementation separate from usage (even from main sitemap).
>>
>>I am struggling to work out what gets cached, and what does not ;)
>>
>>
>>regards Jeremy
>>    
>>



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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

Interesting question.
I am not sure if and how CInclude treats Cache and Expire headers.
I think it simply reads the URL resource.
If it was using Jakarta HttpClient as the WebServiceProxyGenerator is,
it would cache content.
If you have time you can probably consider contributing this improvement.


Ivelin


----- Original Message ----- 
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Sunday, November 03, 2002 4:55 AM
Subject: Re: [important proposal] Cocoon as official Apache project


> 
> On Saturday, Nov 2, 2002, at 15:51 Europe/London, Ivelin Ivanov wrote:
> 
> > So the expire tag has a double benefit. First it lightens the load on 
> > the
> > app server, because the web server caches and second it lightens the 
> > load on
> > the web server when the the browser has read the content once.
> >
> 
> Thanks for this, yes it really works well!
> 
> Do you have any recommendations how to manage caching on internal 
> pipelines?
> 
> I have a <component/> architecture in my current project that uses 
> cinclude to import internal pipelines into documents that helps keep 
> component implementation separate from usage (even from main sitemap).
> 
> I am struggling to work out what gets cached, and what does not ;)
> 
> 
> regards Jeremy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


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

Re: Lucene Problems

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Sunday, Nov 3, 2002, at 20:34 Europe/London, Bernhard Huber wrote:

>> Before I started to have the indexing failures, I had another  
>> problem,  this time much more difficult to replicate.
>>
>> About every 10 searches, I would get a "Bad Resource" error from   
>> LuceneGenerator. A simple reload of the page would give me the search  
>>  hits I expected.
>>
>> Can anyone think of a Cocoon cause for these problems, or should I  
>> get  onto the Lucene team about them?
>
> Do you have anymore detailed exception stack traces?
>

Now I have the indexing fixed, I have started getting this intermittent  
bug again, here is the stacktrace you asked for.

Incidentally, you can see from the fragment of my page, at the bottom  
of the stacktrace, that Lucene appeared to find 30 hits.

The actual Lucene exception appears in the 3rd chunk, I am CIncluding  
this search from an internal pipeline.

Thanks for your help

regards Jeremy

An error occurred
The org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode  
notifies that org.apache.cocoon.ProcessingException says:

Failed to execute pipeline.

More precisely:

org.apache.cocoon.ProcessingException: Failed to execute pipeline.:  
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:  
java.util.NoSuchElementException: no more hits: Bad file descriptor

extra info
full exception chain stacktrace
Original exception : org.apache.cocoon.ProcessingException: Failed to  
execute pipeline.: java.util.NoSuchElementException: no more hits: Bad  
file descriptor
at  
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSour 
ce.java:380)
at  
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironm 
ent.java:532)
at  
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElem 
ent(CIncludeTransformer.java:384)
at  
org.apache.cocoon.transformation.CIncludeTransformer.startTransformingEl 
ement(CIncludeTransformer.java:176)
at  
org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(Abs 
tractSAXTransformer.java:333)
at  
org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java 
:118)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteS 
treamInterpreter.java:134)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XM 
LByteStreamInterpreter.java:110)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:271)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(Containe 
rNode.java:68)
at  
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallN 
ode.java:133)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
at java.lang.Thread.run(Thread.java:491)

Original exception : org.apache.cocoon.ProcessingException: Failed to  
execute pipeline.: java.util.NoSuchElementException: no more hits: Bad  
file descriptor
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
XMLPipeline(AbstractProcessingPipeline.java:518)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:650)
at  
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSour 
ce.java:371)
at  
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironm 
ent.java:532)
at  
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElem 
ent(CIncludeTransformer.java:384)
at  
org.apache.cocoon.transformation.CIncludeTransformer.startTransformingEl 
ement(CIncludeTransformer.java:176)
at  
org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(Abs 
tractSAXTransformer.java:333)
at  
org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java 
:118)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteS 
treamInterpreter.java:134)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XM 
LByteStreamInterpreter.java:110)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:271)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(Containe 
rNode.java:68)
at  
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallN 
ode.java:133)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
at java.lang.Thread.run(Thread.java:491)
java.util.NoSuchElementException: no more hits: Bad file descriptor
at  
org.apache.cocoon.components.search.LuceneCocoonPager.next(LuceneCocoonP 
ager.java:272)
at  
org.apache.cocoon.generation.SearchGenerator.generateHit(SearchGenerator 
.java:621)
at  
org.apache.cocoon.generation.SearchGenerator.generateHits(SearchGenerato 
r.java:603)
at  
org.apache.cocoon.generation.SearchGenerator.generateResults(SearchGener 
ator.java:580)
at  
org.apache.cocoon.generation.SearchGenerator.generate(SearchGenerator.ja 
va:514)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
XMLPipeline(AbstractProcessingPipeline.java:496)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:650)
at  
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSour 
ce.java:371)
at  
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironm 
ent.java:532)
at  
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElem 
ent(CIncludeTransformer.java:384)
at  
org.apache.cocoon.transformation.CIncludeTransformer.startTransformingEl 
ement(CIncludeTransformer.java:176)
at  
org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(Abs 
tractSAXTransformer.java:333)
at  
org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java 
:118)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteS 
treamInterpreter.java:134)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XM 
LByteStreamInterpreter.java:110)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:271)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(Containe 
rNode.java:68)
at  
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallN 
ode.java:133)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
at java.lang.Thread.run(Thread.java:491)

Original exception : java.util.NoSuchElementException: no more hits:  
Bad file descriptor
at  
org.apache.cocoon.components.search.LuceneCocoonPager.next(LuceneCocoonP 
ager.java:272)
at  
org.apache.cocoon.generation.SearchGenerator.generateHit(SearchGenerator 
.java:621)
at  
org.apache.cocoon.generation.SearchGenerator.generateHits(SearchGenerato 
r.java:603)
at  
org.apache.cocoon.generation.SearchGenerator.generateResults(SearchGener 
ator.java:580)
at  
org.apache.cocoon.generation.SearchGenerator.generate(SearchGenerator.ja 
va:514)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
XMLPipeline(AbstractProcessingPipeline.java:496)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:650)
at  
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSour 
ce.java:371)
at  
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironm 
ent.java:532)
at  
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElem 
ent(CIncludeTransformer.java:384)
at  
org.apache.cocoon.transformation.CIncludeTransformer.startTransformingEl 
ement(CIncludeTransformer.java:176)
at  
org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(Abs 
tractSAXTransformer.java:333)
at  
org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java 
:118)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteS 
treamInterpreter.java:134)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XM 
LByteStreamInterpreter.java:110)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:271)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(Containe 
rNode.java:68)
at  
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallN 
ode.java:133)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
at java.lang.Thread.run(Thread.java:491)

stacktrace
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:  
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:  
java.util.NoSuchElementException: no more hits: Bad file descriptor
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:293)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(Containe 
rNode.java:68)
at  
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallN 
ode.java:133)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
at java.lang.Thread.run(Thread.java:491)
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:  
java.util.NoSuchElementException: no more hits: Bad file descriptor
at  
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSour 
ce.java:380)
at  
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironm 
ent.java:532)
at  
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElem 
ent(CIncludeTransformer.java:384)
at  
org.apache.cocoon.transformation.CIncludeTransformer.startTransformingEl 
ement(CIncludeTransformer.java:176)
at  
org.apache.cocoon.transformation.AbstractSAXTransformer.startElement(Abs 
tractSAXTransformer.java:333)
at  
org.apache.cocoon.components.sax.XMLTeePipe.startElement(XMLTeePipe.java 
:118)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.parse(XMLByteS 
treamInterpreter.java:134)
at  
org.apache.cocoon.components.sax.XMLByteStreamInterpreter.deserialize(XM 
LByteStreamInterpreter.java:110)
at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:271)
at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.ContainerNode.invoke(Containe 
rNode.java:68)
at  
org.apache.cocoon.components.treeprocessor.sitemap.CallNode.invoke(CallN 
ode.java:133)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
at java.lang.Thread.run(Thread.java:491)
original message java.util.NoSuchElementException: no more hits: Bad  
file descriptor

If you need help and this information is not enough, you are invited to  
read the cocoon faq.
If you still don't find the answers you need, can send a mail to the  
Cocoon users mailing list, remembering to

     * specify the version of Cocoon you're using, or we suppose that  
you are talking about the latest version;
     * specify the taglibs and sitemap components that are pertinent;
     * specify the platform-operating system-version-servlet container  
version;
     * send any pertinent error message;
     * send pertinent log snippets;
     * send pertinent sitemap snippets;
     * send pertinent parts of the page that gives you problems.

For more detailed technical information, take a look at the log files  
in the log directory of cocoon, which is /WEB-INF/logs by default.
Logging configuration is by default in /WEB-INF/logkit.xconf.

If you think you found a bug, please report it to Apache's Bugzilla; a  
message will be sent to the developer mailing list.

[ jump to main content ]
soft season
09/-12/02
all seasons4site search4

institute of international visual arts.
inIVA
On this page:
search form
search results
4

[ jump to page title ]
inIVA online
search

[ jump to search results ]
Search form

enter a query into the text field below, then click the 'search'  
button, see the examples for ideas about how to use our search facility

[ jump to page title ]
Search results
hits: 30, pages: 3

Pages:

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

Re: Lucene Problems

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Monday, Nov 4, 2002, at 15:12 Europe/London, Vadim Gritsenko wrote:

> This might be of help tp you:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=101879850601501&w=2
>
> And it has a link to explanation of this merge factor parameter...
>

Very useful, it's great to have another line of attack!

regards Jeremy


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

Re: Lucene Problems

Posted by Vadim Gritsenko <va...@verizon.net>.

Jeremy,

This might be of help tp you:

http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=101879850601501&w=2

And it has a link to explanation of this merge factor parameter...


Vadim



Jeremy Quinn wrote:

>
> On Sunday, Nov 3, 2002, at 20:34 Europe/London, Bernhard Huber wrote:
>
>> hi,
>>
>
> Many thanks for your reply, Bernhard.
>
>>>  IOException in index()
>>
>
>>> This causes the index to be incomplete, and causes further 
>>> problems   when you try to search using the index.
>>>
>>> If I use the Lucene Samples in Cocoon, and index my Cocoon   
>>> documentation, I always get this error.
>>
>>
>> Hm, i once got this kind of error, too,
>> but i can't remember exactly how i did solve it,
>> perhaps you must set the mergefactor of lucene differently.
>> As much as i remember lucene has some options about how many files 
>> are  kept opened in case of indexing,
>> it later merges the indexes files, ....
>
>
> Ah Ha! I was beginning to think it was some weakness of MacOSX JVM 
> (or  maybe it still is ....).
>
> Have you any idea where this is configured?
>
>>> Before I started to have the indexing failures, I had another  
>>> problem,  this time much more difficult to replicate.
>>>
>>> About every 10 searches, I would get a "Bad Resource" error from   
>>> LuceneGenerator. A simple reload of the page would give me the 
>>> search   hits I expected.
>>>
>>> Can anyone think of a Cocoon cause for these problems, or should I  
>>> get  onto the Lucene team about them?
>>
>>
>> Do you have anymore detailed exception stack traces?
>
>
> I do for the indexing, but not for the intermittent fault, which has  
> not happened again since the indexing started failing.
>
> Here is the indexing exception report:
>
> Cocoon 2 - Internal server error
>
> type fatal
>
> message IOException in index()
>
> description org.apache.cocoon.ProcessingException: IOException in  
> index(): java.io.FileNotFoundException:  
> /Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
> files/index/_1d.f30 (Too many open files)
>
> sender org.apache.cocoon.servlet.CocoonServlet
>
> source Cocoon servlet
>
> stack-trace
>
> org.apache.cocoon.ProcessingException: IOException in index():  
> java.io.FileNotFoundException:  
> /Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
> files/index/_1d.f30 (Too many open files)
>     at  
> org.apache.cocoon.components.search.SimpleLuceneCocoonIndexerImpl.index( 
> SimpleLuceneCocoonIndexerImpl.java:261)
>     at  
> org.apache.cocoon.www.samples.search.create_index_xsp.createIndex(/ 
> Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
> files/org/apache/cocoon/www/samples/search/create_index_xsp.java:106)
>     at  
> org.apache.cocoon.www.samples.search.create_index_xsp.generate(/Users/ 
> jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon-files/org/ 
> apache/cocoon/www/samples/search/create_index_xsp.java:190)
>     at  
> org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGe 
> nerator.java:269)
>     at  
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
> XMLPipeline(AbstractProcessingPipeline.java:512)
>     at  
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
> line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
>     at  
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
> (AbstractProcessingPipeline.java:483)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
> SerializeNode.java:149)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:85)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
> nvoke(PreparableMatchNode.java:166)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
> ipelineNode.java:153)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
> PipelinesNode.java:143)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:326)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:308)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
> tNode.java:131)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:85)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
> nvoke(PreparableMatchNode.java:166)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
> ipelineNode.java:153)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
> PipelinesNode.java:143)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:326)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:308)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
> tNode.java:131)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:85)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
> nvoke(PreparableMatchNode.java:166)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
> ipelineNode.java:153)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
> PipelinesNode.java:143)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:326)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:308)
>     at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
>     at  
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at  
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
> tionFilterChain.java:247)
>     at  
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
> erChain.java:193)
>     at  
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
> e.java:260)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
> e.java:191)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
> 6)
>     at  
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
> :180)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
> lve.java:170)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:641)
>     at  
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
> :172)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:641)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
> java:174)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
>     at  
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
> 5)
>     at  
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
> onnection(Http11Protocol.java:380)
>     at  
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
> 8)
>     at  
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
> .java:533)
>     at java.lang.Thread.run(Thread.java:491)
> java.io.FileNotFoundException:  
> /Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
> files/index/_1d.f30 (Too many open files)
>     at java.io.RandomAccessFile.open(Native Method)
>     at java.io.RandomAccessFile.(RandomAccessFile.java:93)
>     at java.io.RandomAccessFile.(RandomAccessFile.java:138)
>     at org.apache.lucene.store.FSInputStream$Descriptor.(Unknown Source)
>     at org.apache.lucene.store.FSInputStream.(Unknown Source)
>     at org.apache.lucene.store.FSDirectory.openFile(Unknown Source)
>     at org.apache.lucene.index.SegmentReader.openNorms(Unknown Source)
>     at org.apache.lucene.index.SegmentReader.(Unknown Source)
>     at org.apache.lucene.index.IndexWriter.mergeSegments(Unknown Source)
>     at org.apache.lucene.index.IndexWriter.optimize(Unknown Source)
>     at  
> org.apache.cocoon.components.search.SimpleLuceneCocoonIndexerImpl.index( 
> SimpleLuceneCocoonIndexerImpl.java:259)
>     at  
> org.apache.cocoon.www.samples.search.create_index_xsp.createIndex(/ 
> Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
> files/org/apache/cocoon/www/samples/search/create_index_xsp.java:106)
>     at  
> org.apache.cocoon.www.samples.search.create_index_xsp.generate(/Users/ 
> jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon-files/org/ 
> apache/cocoon/www/samples/search/create_index_xsp.java:190)
>     at  
> org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGe 
> nerator.java:269)
>     at  
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
> XMLPipeline(AbstractProcessingPipeline.java:512)
>     at  
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
> line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
>     at  
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
> (AbstractProcessingPipeline.java:483)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
> SerializeNode.java:149)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:85)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
> nvoke(PreparableMatchNode.java:166)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
> ipelineNode.java:153)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
> PipelinesNode.java:143)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:326)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:308)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
> tNode.java:131)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:85)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
> nvoke(PreparableMatchNode.java:166)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
> ipelineNode.java:153)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
> PipelinesNode.java:143)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:326)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:308)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
> tNode.java:131)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:85)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
> nvoke(PreparableMatchNode.java:166)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
> ipelineNode.java:153)
>     at  
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
> invokeNodes(AbstractParentProcessingNode.java:109)
>     at  
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
> PipelinesNode.java:143)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:326)
>     at  
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
> cessor.java:308)
>     at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
>     at  
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>     at  
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
> tionFilterChain.java:247)
>     at  
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
> erChain.java:193)
>     at  
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
> e.java:260)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
> e.java:191)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
> 6)
>     at  
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
> :180)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
> lve.java:170)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:641)
>     at  
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
> :172)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:641)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
> java:174)
>     at  
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
> nvokeNext(StandardPipeline.java:643)
>     at  
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
> 80)
>     at  
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
>     at  
> org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
>     at  
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
> 5)
>     at  
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
> onnection(Http11Protocol.java:380)
>     at  
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
> 8)
>     at  
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
> .java:533)
>     at java.lang.Thread.run(Thread.java:491)
>
> request-uri
>
> /cocoon/samples/search/create
>
> path-info
>
> samples/search/create
>
>
>
> Thanks again
>
> regards Jeremy




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

Re: Lucene Problems

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Sunday, Nov 3, 2002, at 20:34 Europe/London, Bernhard Huber wrote:

> hi,
>

Many thanks for your reply, Bernhard.

>>  IOException in index()

>> This causes the index to be incomplete, and causes further problems   
>> when you try to search using the index.
>>
>> If I use the Lucene Samples in Cocoon, and index my Cocoon   
>> documentation, I always get this error.
>
> Hm, i once got this kind of error, too,
> but i can't remember exactly how i did solve it,
> perhaps you must set the mergefactor of lucene differently.
> As much as i remember lucene has some options about how many files are  
> kept opened in case of indexing,
> it later merges the indexes files, ....

Ah Ha! I was beginning to think it was some weakness of MacOSX JVM (or  
maybe it still is ....).

Have you any idea where this is configured?

>> Before I started to have the indexing failures, I had another  
>> problem,  this time much more difficult to replicate.
>>
>> About every 10 searches, I would get a "Bad Resource" error from   
>> LuceneGenerator. A simple reload of the page would give me the search  
>>  hits I expected.
>>
>> Can anyone think of a Cocoon cause for these problems, or should I  
>> get  onto the Lucene team about them?
>
> Do you have anymore detailed exception stack traces?

I do for the indexing, but not for the intermittent fault, which has  
not happened again since the indexing started failing.

Here is the indexing exception report:

Cocoon 2 - Internal server error

type fatal

message IOException in index()

description org.apache.cocoon.ProcessingException: IOException in  
index(): java.io.FileNotFoundException:  
/Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
files/index/_1d.f30 (Too many open files)

sender org.apache.cocoon.servlet.CocoonServlet

source Cocoon servlet

stack-trace

org.apache.cocoon.ProcessingException: IOException in index():  
java.io.FileNotFoundException:  
/Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
files/index/_1d.f30 (Too many open files)
	at  
org.apache.cocoon.components.search.SimpleLuceneCocoonIndexerImpl.index( 
SimpleLuceneCocoonIndexerImpl.java:261)
	at  
org.apache.cocoon.www.samples.search.create_index_xsp.createIndex(/ 
Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
files/org/apache/cocoon/www/samples/search/create_index_xsp.java:106)
	at  
org.apache.cocoon.www.samples.search.create_index_xsp.generate(/Users/ 
jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon-files/org/ 
apache/cocoon/www/samples/search/create_index_xsp.java:190)
	at  
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGe 
nerator.java:269)
	at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
XMLPipeline(AbstractProcessingPipeline.java:512)
	at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
	at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
	at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
	at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
	at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
	at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
	at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
	at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
	at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
	at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
	at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
	at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
	at java.lang.Thread.run(Thread.java:491)
java.io.FileNotFoundException:  
/Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
files/index/_1d.f30 (Too many open files)
	at java.io.RandomAccessFile.open(Native Method)
	at java.io.RandomAccessFile.(RandomAccessFile.java:93)
	at java.io.RandomAccessFile.(RandomAccessFile.java:138)
	at org.apache.lucene.store.FSInputStream$Descriptor.(Unknown Source)
	at org.apache.lucene.store.FSInputStream.(Unknown Source)
	at org.apache.lucene.store.FSDirectory.openFile(Unknown Source)
	at org.apache.lucene.index.SegmentReader.openNorms(Unknown Source)
	at org.apache.lucene.index.SegmentReader.(Unknown Source)
	at org.apache.lucene.index.IndexWriter.mergeSegments(Unknown Source)
	at org.apache.lucene.index.IndexWriter.optimize(Unknown Source)
	at  
org.apache.cocoon.components.search.SimpleLuceneCocoonIndexerImpl.index( 
SimpleLuceneCocoonIndexerImpl.java:259)
	at  
org.apache.cocoon.www.samples.search.create_index_xsp.createIndex(/ 
Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
files/org/apache/cocoon/www/samples/search/create_index_xsp.java:106)
	at  
org.apache.cocoon.www.samples.search.create_index_xsp.generate(/Users/ 
jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon-files/org/ 
apache/cocoon/www/samples/search/create_index_xsp.java:190)
	at  
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGe 
nerator.java:269)
	at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
XMLPipeline(AbstractProcessingPipeline.java:512)
	at  
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipe 
line.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
	at  
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process 
(AbstractProcessingPipeline.java:483)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke( 
SerializeNode.java:149)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun 
tNode.java:131)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:85)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i 
nvoke(PreparableMatchNode.java:166)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P 
ipelineNode.java:153)
	at  
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. 
invokeNodes(AbstractParentProcessingNode.java:109)
	at  
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( 
PipelinesNode.java:143)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:326)
	at  
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro 
cessor.java:308)
	at org.apache.cocoon.Cocoon.process(Cocoon.java:595)
	at  
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1069)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at  
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica 
tionFilterChain.java:247)
	at  
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt 
erChain.java:193)
	at  
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv 
e.java:260)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv 
e.java:191)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:239 
6)
	at  
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java 
:180)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherVa 
lve.java:170)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
	at  
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java 
:172)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:641)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. 
java:174)
	at  
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.i 
nvokeNext(StandardPipeline.java:643)
	at  
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 
80)
	at  
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at  
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
	at  
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:40 
5)
	at  
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC 
onnection(Http11Protocol.java:380)
	at  
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:50 
8)
	at  
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool 
.java:533)
	at java.lang.Thread.run(Thread.java:491)

request-uri

/cocoon/samples/search/create

path-info

samples/search/create



Thanks again

regards Jeremy


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

Re: Lucene Problems

Posted by Bernhard Huber <be...@a1.net>.

hi,

>  IOException in index()
>
> description org.apache.cocoon.ProcessingException: IOException in  
> index(): java.io.FileNotFoundException:  
> /Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
> files/index/_1d.f30 (Too many open files)
>
> This causes the index to be incomplete, and causes further problems  
> when you try to search using the index.
>
> If I use the Lucene Samples in Cocoon, and index my Cocoon  
> documentation, I always get this error.

Hm, i once got this kind of error, too,
but i can't remember exactly how i did solve it,
perhaps you must set the mergefactor of lucene differently.
As much as i remember lucene has some options about how many files are 
kept opened in case of indexing,
it later merges the indexes files, ....

>
>
> Before I started to have the indexing failures, I had another 
> problem,  this time much more difficult to replicate.
>
> About every 10 searches, I would get a "Bad Resource" error from  
> LuceneGenerator. A simple reload of the page would give me the search  
> hits I expected.
>
> Can anyone think of a Cocoon cause for these problems, or should I 
> get  onto the Lucene team about them?

Do you have anymore detailed exception stack traces?

>


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

Lucene Problems

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

Dear All,


I am getting some problems with Lucene, and would like to see if  
any-one else is getting the same. They are not reported on the Lucene  
bug-list.

I am getting these problems on MacOSX 10.2.1, JVM 1.3.1.

Indexing:

When my site got over a certain size, Lucene started throwing an  
exception during the indexing process saying:

  IOException in index()

description org.apache.cocoon.ProcessingException: IOException in  
index(): java.io.FileNotFoundException:  
/Users/jermq/Library/TomCat/work/Standalone/localhost/cocoon/cocoon- 
files/index/_1d.f30 (Too many open files)

This causes the index to be incomplete, and causes further problems  
when you try to search using the index.

If I use the Lucene Samples in Cocoon, and index my Cocoon  
documentation, I always get this error.


Before I started to have the indexing failures, I had another problem,  
this time much more difficult to replicate.

About every 10 searches, I would get a "Bad Resource" error from  
LuceneGenerator. A simple reload of the page would give me the search  
hits I expected.

Can anyone think of a Cocoon cause for these problems, or should I get  
onto the Lucene team about them?


Thanks for any help

regards Jeremy


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

Re: [important proposal] Cocoon as official Apache project

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Saturday, Nov 2, 2002, at 15:51 Europe/London, Ivelin Ivanov wrote:

> So the expire tag has a double benefit. First it lightens the load on 
> the
> app server, because the web server caches and second it lightens the 
> load on
> the web server when the the browser has read the content once.
>

Thanks for this, yes it really works well!

Do you have any recommendations how to manage caching on internal 
pipelines?

I have a <component/> architecture in my current project that uses 
cinclude to import internal pipelines into documents that helps keep 
component implementation separate from usage (even from main sitemap).

I am struggling to work out what gets cached, and what does not ;)

regards Jeremy

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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.


The pipeline expire tag is awesome, because it allows me to organize
expiration time based on url name spaces.
It does a great job even for my mini portal and blog demo.
Not only the app server is not hit for an hour, but the browser will not
even hit the web server until the expiration time has elapsed or you hit
refresh.
I've added some documentation to the Performance doc and it is show cased in
one of the webserviceproxy demos:

http://xml.apache.org/cocoon/performancetips.html

http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/webservicep
roxy/cocoonhive/sitemap.xmap?rev=HEAD&content-type=text/vnd.viewcvs-markup


So the expire tag has a double benefit. First it lightens the load on the
app server, because the web server caches and second it lightens the load on
the web server when the the browser has read the content once.


Ivelin


----- Original Message -----
From: "Steven Noels" <st...@outerthought.org>
To: <co...@xml.apache.org>
Cc: "Pier Fumagalli" <pi...@apache.org>; <in...@apache.org>;
"Dirk-Willem van Gulik" <di...@webweaving.org>
Sent: Friday, November 01, 2002 6:36 AM
Subject: Re: [important proposal] Cocoon as official Apache project


> Pier Fumagalli wrote:
>
> > Can't you just redirect? I mean... If you have to showcase static
content
> > (that's where mod_cache could help), you can generate it offline, and
put it
> > up on daedalus as static HTML files, and forget about it...
>
> I believe we (Forrest/Cocoon-people) went already at much length
> explaining the current publication mechanism using CVS as a deployment
> mechanism of (generated HTML) is far from optimal, given CVS's
> 'interesting treatment' of new directories and the headaches one
> encounters when removing unlinked/old pages.
>
> > If you're generating dynamic content, mod_cache wouldn't help (as it's
> > dynamic), and it would only make things harder...
>
> A lot of the content would be dynamically generated from static XML
> content, i.e. documentation. Content expiry headers could set making
> sure content is only expirying daily (just an idea). Still, having one
> global generation mechanism (Cocoon) for the entire site will provide us
> with unified treatment (look&feel, navigation) of both dynamic and
> 'not-so-dynamic' content. It will be nice challenge for us Cocoonies to
> set up the website so that cache expiry is transparently configured,
> dependent on the nature of the pages, but it's the kind of challenges we
> like, and it will be yet another great test for the
> scalability/performance of our framework :-)
>
> > (what's "not-so-dynamic content, btw?)
> >
> > Or am I _waaay_ off the hook here?
>
> Nope - I was expecting this debate ;-)
>
> Do my arguments help? Or am I simply dead wrong?
>
> </Steven>--
> Steven Noels                            http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> stevenn@outerthought.org                      stevenn@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

Re: [important proposal] Cocoon as official Apache project

Posted by Pier Fumagalli <pi...@betaversion.org>.

"Steven Noels" <st...@outerthought.org> wrote:
> Pier Fumagalli wrote:
> 
>> Can't you just redirect? I mean... If you have to showcase static content
>> (that's where mod_cache could help), you can generate it offline, and put it
>> up on daedalus as static HTML files, and forget about it...
> 
> I believe we (Forrest/Cocoon-people) went already at much length
> explaining the current publication mechanism using CVS as a deployment
> mechanism of (generated HTML) is far from optimal, given CVS's
> 'interesting treatment' of new directories and the headaches one
> encounters when removing unlinked/old pages.

There's not only CVS... You can use "rsync"...

>> If you're generating dynamic content, mod_cache wouldn't help (as it's
>> dynamic), and it would only make things harder...
> 
> A lot of the content would be dynamically generated from static XML
> content, i.e. documentation. Content expiry headers could set making
> sure content is only expirying daily (just an idea). Still, having one
> global generation mechanism (Cocoon) for the entire site will provide us
> with unified treatment (look&feel, navigation) of both dynamic and
> 'not-so-dynamic' content. It will be nice challenge for us Cocoonies to
> set up the website so that cache expiry is transparently configured,
> dependent on the nature of the pages, but it's the kind of challenges we
> like, and it will be yet another great test for the
> scalability/performance of our framework :-)

If you make it expire once a day, daedalus will end up refetching the entire
website every day (shuvload of HTTP requests, unless you don't use GZIP as a
filter, all your content will be passed on the wire uncompressed - and I
don't know how to deal GZIP compression between server and proxy and
differently between proxy and client)...

Use "rsync". It works, it's nice, it compresses all content, it's
one-connection per a number of files, it doesn't have problems with
added/removed directories and or content, and it transfer _only_ what has
changed between the server and the client (so, the "expiry" of a document
gets set only when that document is actually _changed_)...

    Pier

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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Pier Fumagalli wrote:

> Can't you just redirect? I mean... If you have to showcase static content
> (that's where mod_cache could help), you can generate it offline, and put it
> up on daedalus as static HTML files, and forget about it...

I believe we (Forrest/Cocoon-people) went already at much length 
explaining the current publication mechanism using CVS as a deployment 
mechanism of (generated HTML) is far from optimal, given CVS's 
'interesting treatment' of new directories and the headaches one 
encounters when removing unlinked/old pages.

> If you're generating dynamic content, mod_cache wouldn't help (as it's
> dynamic), and it would only make things harder...

A lot of the content would be dynamically generated from static XML 
content, i.e. documentation. Content expiry headers could set making 
sure content is only expirying daily (just an idea). Still, having one 
global generation mechanism (Cocoon) for the entire site will provide us 
with unified treatment (look&feel, navigation) of both dynamic and 
'not-so-dynamic' content. It will be nice challenge for us Cocoonies to 
set up the website so that cache expiry is transparently configured, 
dependent on the nature of the pages, but it's the kind of challenges we 
like, and it will be yet another great test for the 
scalability/performance of our framework :-)

> (what's "not-so-dynamic content, btw?)
> 
> Or am I _waaay_ off the hook here?

Nope - I was expecting this debate ;-)

Do my arguments help? Or am I simply dead wrong?

</Steven>--
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org

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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

----- Original Message -----
From: "Pier Fumagalli" <pi...@betaversion.org>
To: "Steven Noels" <st...@outerthought.org>
Cc: <co...@xml.apache.org>; "Dirk-Willem van Gulik"
<di...@covalent.net>; <in...@apache.org>
Sent: Friday, November 01, 2002 6:13 AM
Subject: Re: [important proposal] Cocoon as official Apache project


> "Steven Noels" <st...@outerthought.org> wrote:
>
> > Pier Fumagalli wrote:
> >
> >> Daedalus and Icarus are located in San Francisco, and Proxy-Pass is
(IMVHO),
> >> a quite silly idea... Not only we need bandwidth to _deliver_ pages, we
also
> >> need bandwidth to _retrieve_ the pages...
> >
> > Agree, but it would be a nice solution to distribute the load,
> > especially for not-so-dynamic content. I was thinking of the combination
> > of mod_proxy together with mod_cache anyhow. I'll be testing this
> > somewhere next week on a private server.

Works. I've used it quite a bit.

> >
> > Given this setup, the Cocoon community has the ability to showcase its
> > technology while still benefiting from the kind bandwidth donation of
> > Collab/Sun. I know it sounds like piggybacking, but it would provide us
> > with a nice balance of being able to do our own thing, possibly
> > attracting other co-sponsors, until we are able to provide both CPU
> > cycles and bandwidth ourselves.
>
> Can't you just redirect? I mean... If you have to showcase static content
> (that's where mod_cache could help), you can generate it offline, and put
it
> up on daedalus as static HTML files, and forget about it...
>
> If you're generating dynamic content, mod_cache wouldn't help (as it's
> dynamic), and it would only make things harder...
>
> (what's "not-so-dynamic content, btw?)

Many of the dynamically generated Cocoon pages are cacheable and provide
expiration header.
Which means that they are static for some period of time, say 1 hour or 1
day. During that time all request for the URL can be served by a cacheing
proxy server without loading the app server.


>
> Or am I _waaay_ off the hook here?
>
>     Pier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

Re: XSLTC Problems

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Tuesday, Nov 5, 2002, at 03:50 Europe/London, Ivelin Ivanov wrote:

> Did you update the jar in C2 CVS HEAD?
>

No, I thought that would be presumptuous, after all, I had done very 
little testing.

regards Jeremy

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

Re: XSLTC Problems

Posted by Ivelin Ivanov <iv...@apache.org>.

Jeremy,

Did you update the jar in C2 CVS HEAD?

Ivelin


----- Original Message ----- 
From: "Jeremy Quinn" <je...@media.demon.co.uk>
To: <co...@xml.apache.org>
Sent: Monday, November 04, 2002 12:48 PM
Subject: Re: XSLTC Problems


> Dear Tom,
> 
> Thanks for this, yes it appears to solve the problem.
> 
> Just to make sure I did the right test .....
> 
> I could not re-compile Cocoon 2.1 dev with the new xalan, because there 
> is currently some code in Cocoon's scratchpad that does not compile on 
> my MacOSX JVM 1.3.1 system.
> 
> I just dropped the new (2.4.1) xajan.jar, xml-apis.jar and xsltc.jar 
> into cocoon/WEB-INF/lib, replacing the older ones, then reset my 
> sitemap to use the xsltc engine again.
> 
> Thanks
> 
> regards Jeremy
> 
> On Monday, Nov 4, 2002, at 15:23 Europe/London, Tom Amiro wrote:
> 
> > Hi,
> >
> > I took the problematic stylesheet (attached) and tried it with
> > the latest XSLTC. There was no error. Could you try with the
> > latest build -- actually 2.4.1 release should be fine -- to
> > see if the problem is still reproducible?
> >
> > Tom
> >
> > Ivelin Ivanov wrote:
> >>
> >> Tom is probably still the point man, but just in case,
> >> I have added to the CC list all the XSLTC contacts that we used in 
> >> the past.
> >>
> >> Ivelin
> >>
> >> ----- Original Message -----
> >> From: "Jeremy Quinn" <sh...@mac.com>
> >> To: <co...@xml.apache.org>
> >> Sent: Friday, November 01, 2002 7:41 AM
> >> Subject: XSLTC Problems
> >>
> >>> Dear All,
> >>>
> >>> As soon as XSLTC was switched on by default, I had to switch it off!
> >>>
> >>> I have a stylesheet that work fine with xalan, but does not work in
> >>> XSLTC, to whom, and how, should I report this?
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


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

Re: XSLTC Problems

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

Dear Tom,

Thanks for this, yes it appears to solve the problem.

Just to make sure I did the right test .....

I could not re-compile Cocoon 2.1 dev with the new xalan, because there 
is currently some code in Cocoon's scratchpad that does not compile on 
my MacOSX JVM 1.3.1 system.

I just dropped the new (2.4.1) xajan.jar, xml-apis.jar and xsltc.jar 
into cocoon/WEB-INF/lib, replacing the older ones, then reset my 
sitemap to use the xsltc engine again.

Thanks

regards Jeremy

On Monday, Nov 4, 2002, at 15:23 Europe/London, Tom Amiro wrote:

> Hi,
>
> I took the problematic stylesheet (attached) and tried it with
> the latest XSLTC. There was no error. Could you try with the
> latest build -- actually 2.4.1 release should be fine -- to
> see if the problem is still reproducible?
>
> Tom
>
> Ivelin Ivanov wrote:
>>
>> Tom is probably still the point man, but just in case,
>> I have added to the CC list all the XSLTC contacts that we used in 
>> the past.
>>
>> Ivelin
>>
>> ----- Original Message -----
>> From: "Jeremy Quinn" <sh...@mac.com>
>> To: <co...@xml.apache.org>
>> Sent: Friday, November 01, 2002 7:41 AM
>> Subject: XSLTC Problems
>>
>>> Dear All,
>>>
>>> As soon as XSLTC was switched on by default, I had to switch it off!
>>>
>>> I have a stylesheet that work fine with xalan, but does not work in
>>> XSLTC, to whom, and how, should I report this?

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

Re: XSLTC Problems

Posted by Tom Amiro <To...@Sun.COM>.

Hi,

I took the problematic stylesheet (attached) and tried it with 
the latest XSLTC. There was no error. Could you try with the 
latest build -- actually 2.4.1 release should be fine -- to 
see if the problem is still reproducible?

Tom

Ivelin Ivanov wrote:
> 
> Tom is probably still the point man, but just in case,
> I have added to the CC list all the XSLTC contacts that we used in the past.
> 
> Ivelin
> 
> ----- Original Message -----
> From: "Jeremy Quinn" <sh...@mac.com>
> To: <co...@xml.apache.org>
> Sent: Friday, November 01, 2002 7:41 AM
> Subject: XSLTC Problems
> 
> > Dear All,
> >
> > As soon as XSLTC was switched on by default, I had to switch it off!
> >
> > I have a stylesheet that work fine with xalan, but does not work in
> > XSLTC, to whom, and how, should I report this?
> >
> > The culprit :
> >
> > <?xml version="1.0"?>
> >
> > <xsl:stylesheet version="1.0"
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >
> >
> >
> > <xsl:variable name="int-links"
> > select="/doc/meta/link[@rel='section-link']|/doc/meta/
> > link[@rel='chapter-link']"/>
> >
> > <!-- places int-link elements in sections with labels, with href
> > pointing to next section, skipping chapters, or to the beginning, if
> > there are no more sections -->
> > <xsl:template match="section[@link]">
> > <xsl:variable name="link" select="concat('#',@link)"/>
> > <xsl:variable name="to"
> > select="$int-links[@href=$link]/following-sibling::link[@rel='section-
> > link'][position()=1]"/>
> > <section region="{@region}" label="{@label}">
> > <int-link name="{@link}">
> > <xsl:attribute name="href">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@href"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > <xsl:attribute name="title">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of
> > select="$to/@title"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@title"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > </int-link>
> > <xsl:apply-templates/>
> > </section>
> > </xsl:template>
> >
> > <!-- places int-link elements in chapters with labels, with href
> > pointing to next chapter, or section, if there are no more chapters -->
> > <xsl:template match="chapter[@link]|menu[@link]|image[@link]">
> > <xsl:variable name="link" select="concat('#',@link)"/>
> > <xsl:variable name="to"
> > select="$int-links[@href=$link]/following-sibling::*[position()=1]"/>
> > <xsl:copy>
> > <xsl:attribute name="type"><xsl:value-of
> > select="@type"/></xsl:attribute>
> > <xsl:attribute name="label"><xsl:value-of
> > select="@label"/></xsl:attribute>
> > <int-link name="{@link}">
> > <xsl:attribute name="href">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@href"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > <xsl:attribute name="title">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of
> > select="$to/@title"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@title"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > </int-link>
> > <xsl:apply-templates/>
> > </xsl:copy>
> > </xsl:template>
> >
> > <xsl:template match="link[@rel='chapter-link']">
> > <link href="{@href}" rel="Chapter" title="{@title}"/>
> > </xsl:template>
> >
> > <xsl:template match="link[@rel='section-link']"/>
> >
> >    <xsl:template match="@*|node()"
> > priority="-2"><xsl:copy><xsl:apply-templates
> > select="@*|node()"/></xsl:copy></xsl:template>
> >    <xsl:template match="text()" priority="-1"><xsl:value-of
> > select="."/></xsl:template>
> >
> > </xsl:stylesheet>
> >
> >
> > This appears to be the reported error:
> >
> > root cause
> >
> > java.lang.VerifyError: (class: make_chapter_links$4, method: test
> > signature:
> > (IIIILorg/apache/xalan/xsltc/runtime/AbstractTranslet;Lorg/apache/
> > xalan/xsltc/NodeIterator;)Z) Incompatible argument to function
> > at make_chapter_links.applyTemplates()
> > at make_chapter_links.applyTemplates()
> > at make_chapter_links.applyTemplates()
> > at make_chapter_links.transform()
> > at
> > org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTransl
> > et.java:540)
> > at
> > org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.ja
> > va:635)
> >
> > regards Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >

-- 
 Tom Amiro -- SQE Engineer
 WTS - Interoperability and Quality
 voice: 781-442-0589 Fax: 781-442-1437
 eMail: tom.amiro@.sun.com

Re: XSLTC Problems

Posted by Tom Amiro <To...@Sun.COM>.

Hi,

I took the problematic stylesheet (attached) and tried it with 
the latest XSLTC. There was no error. Could you try with the 
latest build -- actually 2.4.1 release should be fine -- to 
see if the problem is still reproducible?

Tom

Ivelin Ivanov wrote:
> 
> Tom is probably still the point man, but just in case,
> I have added to the CC list all the XSLTC contacts that we used in the past.
> 
> Ivelin
> 
> ----- Original Message -----
> From: "Jeremy Quinn" <sh...@mac.com>
> To: <co...@xml.apache.org>
> Sent: Friday, November 01, 2002 7:41 AM
> Subject: XSLTC Problems
> 
> > Dear All,
> >
> > As soon as XSLTC was switched on by default, I had to switch it off!
> >
> > I have a stylesheet that work fine with xalan, but does not work in
> > XSLTC, to whom, and how, should I report this?
> >
> > The culprit :
> >
> > <?xml version="1.0"?>
> >
> > <xsl:stylesheet version="1.0"
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> >
> >
> >
> > <xsl:variable name="int-links"
> > select="/doc/meta/link[@rel='section-link']|/doc/meta/
> > link[@rel='chapter-link']"/>
> >
> > <!-- places int-link elements in sections with labels, with href
> > pointing to next section, skipping chapters, or to the beginning, if
> > there are no more sections -->
> > <xsl:template match="section[@link]">
> > <xsl:variable name="link" select="concat('#',@link)"/>
> > <xsl:variable name="to"
> > select="$int-links[@href=$link]/following-sibling::link[@rel='section-
> > link'][position()=1]"/>
> > <section region="{@region}" label="{@label}">
> > <int-link name="{@link}">
> > <xsl:attribute name="href">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@href"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > <xsl:attribute name="title">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of
> > select="$to/@title"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@title"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > </int-link>
> > <xsl:apply-templates/>
> > </section>
> > </xsl:template>
> >
> > <!-- places int-link elements in chapters with labels, with href
> > pointing to next chapter, or section, if there are no more chapters -->
> > <xsl:template match="chapter[@link]|menu[@link]|image[@link]">
> > <xsl:variable name="link" select="concat('#',@link)"/>
> > <xsl:variable name="to"
> > select="$int-links[@href=$link]/following-sibling::*[position()=1]"/>
> > <xsl:copy>
> > <xsl:attribute name="type"><xsl:value-of
> > select="@type"/></xsl:attribute>
> > <xsl:attribute name="label"><xsl:value-of
> > select="@label"/></xsl:attribute>
> > <int-link name="{@link}">
> > <xsl:attribute name="href">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@href"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > <xsl:attribute name="title">
> > <xsl:choose>
> > <xsl:when test="$to"><xsl:value-of
> > select="$to/@title"/></xsl:when>
> > <xsl:otherwise><xsl:value-of
> > select="$int-links[1]/@title"/></xsl:otherwise>
> > </xsl:choose>
> > </xsl:attribute>
> > </int-link>
> > <xsl:apply-templates/>
> > </xsl:copy>
> > </xsl:template>
> >
> > <xsl:template match="link[@rel='chapter-link']">
> > <link href="{@href}" rel="Chapter" title="{@title}"/>
> > </xsl:template>
> >
> > <xsl:template match="link[@rel='section-link']"/>
> >
> >    <xsl:template match="@*|node()"
> > priority="-2"><xsl:copy><xsl:apply-templates
> > select="@*|node()"/></xsl:copy></xsl:template>
> >    <xsl:template match="text()" priority="-1"><xsl:value-of
> > select="."/></xsl:template>
> >
> > </xsl:stylesheet>
> >
> >
> > This appears to be the reported error:
> >
> > root cause
> >
> > java.lang.VerifyError: (class: make_chapter_links$4, method: test
> > signature:
> > (IIIILorg/apache/xalan/xsltc/runtime/AbstractTranslet;Lorg/apache/
> > xalan/xsltc/NodeIterator;)Z) Incompatible argument to function
> > at make_chapter_links.applyTemplates()
> > at make_chapter_links.applyTemplates()
> > at make_chapter_links.applyTemplates()
> > at make_chapter_links.transform()
> > at
> > org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTransl
> > et.java:540)
> > at
> > org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.ja
> > va:635)
> >
> > regards Jeremy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >

-- 
 Tom Amiro -- SQE Engineer
 WTS - Interoperability and Quality
 voice: 781-442-0589 Fax: 781-442-1437
 eMail: tom.amiro@.sun.com

Re: XSLTC Problems

Posted by Ivelin Ivanov <iv...@apache.org>.

Tom is probably still the point man, but just in case,
I have added to the CC list all the XSLTC contacts that we used in the past.

Ivelin

----- Original Message -----
From: "Jeremy Quinn" <sh...@mac.com>
To: <co...@xml.apache.org>
Sent: Friday, November 01, 2002 7:41 AM
Subject: XSLTC Problems


> Dear All,
>
> As soon as XSLTC was switched on by default, I had to switch it off!
>
> I have a stylesheet that work fine with xalan, but does not work in
> XSLTC, to whom, and how, should I report this?
>
> The culprit :
>
> <?xml version="1.0"?>
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>
>
>
> <xsl:variable name="int-links"
> select="/doc/meta/link[@rel='section-link']|/doc/meta/
> link[@rel='chapter-link']"/>
>
> <!-- places int-link elements in sections with labels, with href
> pointing to next section, skipping chapters, or to the beginning, if
> there are no more sections -->
> <xsl:template match="section[@link]">
> <xsl:variable name="link" select="concat('#',@link)"/>
> <xsl:variable name="to"
> select="$int-links[@href=$link]/following-sibling::link[@rel='section-
> link'][position()=1]"/>
> <section region="{@region}" label="{@label}">
> <int-link name="{@link}">
> <xsl:attribute name="href">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@href"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> <xsl:attribute name="title">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of
> select="$to/@title"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@title"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> </int-link>
> <xsl:apply-templates/>
> </section>
> </xsl:template>
>
> <!-- places int-link elements in chapters with labels, with href
> pointing to next chapter, or section, if there are no more chapters -->
> <xsl:template match="chapter[@link]|menu[@link]|image[@link]">
> <xsl:variable name="link" select="concat('#',@link)"/>
> <xsl:variable name="to"
> select="$int-links[@href=$link]/following-sibling::*[position()=1]"/>
> <xsl:copy>
> <xsl:attribute name="type"><xsl:value-of
> select="@type"/></xsl:attribute>
> <xsl:attribute name="label"><xsl:value-of
> select="@label"/></xsl:attribute>
> <int-link name="{@link}">
> <xsl:attribute name="href">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@href"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> <xsl:attribute name="title">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of
> select="$to/@title"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@title"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> </int-link>
> <xsl:apply-templates/>
> </xsl:copy>
> </xsl:template>
>
> <xsl:template match="link[@rel='chapter-link']">
> <link href="{@href}" rel="Chapter" title="{@title}"/>
> </xsl:template>
>
> <xsl:template match="link[@rel='section-link']"/>
>
>    <xsl:template match="@*|node()"
> priority="-2"><xsl:copy><xsl:apply-templates
> select="@*|node()"/></xsl:copy></xsl:template>
>    <xsl:template match="text()" priority="-1"><xsl:value-of
> select="."/></xsl:template>
>
> </xsl:stylesheet>
>
>
> This appears to be the reported error:
>
> root cause
>
> java.lang.VerifyError: (class: make_chapter_links$4, method: test
> signature:
> (IIIILorg/apache/xalan/xsltc/runtime/AbstractTranslet;Lorg/apache/
> xalan/xsltc/NodeIterator;)Z) Incompatible argument to function
> at make_chapter_links.applyTemplates()
> at make_chapter_links.applyTemplates()
> at make_chapter_links.applyTemplates()
> at make_chapter_links.transform()
> at
> org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTransl
> et.java:540)
> at
> org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.ja
> va:635)
>
> regards Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

Re: XSLTC Problems

Posted by Ivelin Ivanov <iv...@apache.org>.

Tom is probably still the point man, but just in case,
I have added to the CC list all the XSLTC contacts that we used in the past.

Ivelin

----- Original Message -----
From: "Jeremy Quinn" <sh...@mac.com>
To: <co...@xml.apache.org>
Sent: Friday, November 01, 2002 7:41 AM
Subject: XSLTC Problems


> Dear All,
>
> As soon as XSLTC was switched on by default, I had to switch it off!
>
> I have a stylesheet that work fine with xalan, but does not work in
> XSLTC, to whom, and how, should I report this?
>
> The culprit :
>
> <?xml version="1.0"?>
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>
>
>
> <xsl:variable name="int-links"
> select="/doc/meta/link[@rel='section-link']|/doc/meta/
> link[@rel='chapter-link']"/>
>
> <!-- places int-link elements in sections with labels, with href
> pointing to next section, skipping chapters, or to the beginning, if
> there are no more sections -->
> <xsl:template match="section[@link]">
> <xsl:variable name="link" select="concat('#',@link)"/>
> <xsl:variable name="to"
> select="$int-links[@href=$link]/following-sibling::link[@rel='section-
> link'][position()=1]"/>
> <section region="{@region}" label="{@label}">
> <int-link name="{@link}">
> <xsl:attribute name="href">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@href"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> <xsl:attribute name="title">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of
> select="$to/@title"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@title"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> </int-link>
> <xsl:apply-templates/>
> </section>
> </xsl:template>
>
> <!-- places int-link elements in chapters with labels, with href
> pointing to next chapter, or section, if there are no more chapters -->
> <xsl:template match="chapter[@link]|menu[@link]|image[@link]">
> <xsl:variable name="link" select="concat('#',@link)"/>
> <xsl:variable name="to"
> select="$int-links[@href=$link]/following-sibling::*[position()=1]"/>
> <xsl:copy>
> <xsl:attribute name="type"><xsl:value-of
> select="@type"/></xsl:attribute>
> <xsl:attribute name="label"><xsl:value-of
> select="@label"/></xsl:attribute>
> <int-link name="{@link}">
> <xsl:attribute name="href">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@href"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> <xsl:attribute name="title">
> <xsl:choose>
> <xsl:when test="$to"><xsl:value-of
> select="$to/@title"/></xsl:when>
> <xsl:otherwise><xsl:value-of
> select="$int-links[1]/@title"/></xsl:otherwise>
> </xsl:choose>
> </xsl:attribute>
> </int-link>
> <xsl:apply-templates/>
> </xsl:copy>
> </xsl:template>
>
> <xsl:template match="link[@rel='chapter-link']">
> <link href="{@href}" rel="Chapter" title="{@title}"/>
> </xsl:template>
>
> <xsl:template match="link[@rel='section-link']"/>
>
>    <xsl:template match="@*|node()"
> priority="-2"><xsl:copy><xsl:apply-templates
> select="@*|node()"/></xsl:copy></xsl:template>
>    <xsl:template match="text()" priority="-1"><xsl:value-of
> select="."/></xsl:template>
>
> </xsl:stylesheet>
>
>
> This appears to be the reported error:
>
> root cause
>
> java.lang.VerifyError: (class: make_chapter_links$4, method: test
> signature:
> (IIIILorg/apache/xalan/xsltc/runtime/AbstractTranslet;Lorg/apache/
> xalan/xsltc/NodeIterator;)Z) Incompatible argument to function
> at make_chapter_links.applyTemplates()
> at make_chapter_links.applyTemplates()
> at make_chapter_links.applyTemplates()
> at make_chapter_links.transform()
> at
> org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTransl
> et.java:540)
> at
> org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.ja
> va:635)
>
> regards Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

Re: XSLTC Problems

Posted by Peter Royal <pr...@apache.org>.

On Friday, November 1, 2002, at 08:41  AM, Jeremy Quinn wrote:
> As soon as XSLTC was switched on by default, I had to switch it off!
>
> I have a stylesheet that work fine with xalan, but does not work in 
> XSLTC, to whom, and how, should I report this?

File a bug report against Xalan/XSLTC. Include sample XML and your 
stylesheet. I had a stylesheet that was crashing XSLT (found a new bug, 
whoohoo! since fixed) and the Xalan guys were *very* helpful in getting 
it resolved. They want to make it work on all stylesheets :)
-pete
-- 
peter royal -> proyal@apache.org


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

XSLTC Problems

Posted by Jeremy Quinn <sh...@mac.com>.

Dear All,

As soon as XSLTC was switched on by default, I had to switch it off!

I have a stylesheet that work fine with xalan, but does not work in  
XSLTC, to whom, and how, should I report this?

The culprit :

<?xml version="1.0"?>

<xsl:stylesheet version="1.0"
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">



	<xsl:variable name="int-links"  
select="/doc/meta/link[@rel='section-link']|/doc/meta/ 
link[@rel='chapter-link']"/>

	<!-- places int-link elements in sections with labels, with href  
pointing to next section, skipping chapters, or to the beginning, if  
there are no more sections -->
	<xsl:template match="section[@link]">
		<xsl:variable name="link" select="concat('#',@link)"/>
		<xsl:variable name="to"  
select="$int-links[@href=$link]/following-sibling::link[@rel='section- 
link'][position()=1]"/>
		<section region="{@region}" label="{@label}">
			<int-link name="{@link}">
				<xsl:attribute name="href">
					<xsl:choose>
						<xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
						<xsl:otherwise><xsl:value-of  
select="$int-links[1]/@href"/></xsl:otherwise>
					</xsl:choose>
				</xsl:attribute>
				<xsl:attribute name="title">
					<xsl:choose>
						<xsl:when test="$to"><xsl:value-of  
select="$to/@title"/></xsl:when>
						<xsl:otherwise><xsl:value-of  
select="$int-links[1]/@title"/></xsl:otherwise>
					</xsl:choose>
				</xsl:attribute>
			</int-link>
			<xsl:apply-templates/>
		</section>
	</xsl:template>

	<!-- places int-link elements in chapters with labels, with href  
pointing to next chapter, or section, if there are no more chapters -->
	<xsl:template match="chapter[@link]|menu[@link]|image[@link]">
		<xsl:variable name="link" select="concat('#',@link)"/>
		<xsl:variable name="to"  
select="$int-links[@href=$link]/following-sibling::*[position()=1]"/>
		<xsl:copy>
			<xsl:attribute name="type"><xsl:value-of  
select="@type"/></xsl:attribute>
			<xsl:attribute name="label"><xsl:value-of  
select="@label"/></xsl:attribute>
			<int-link name="{@link}">
				<xsl:attribute name="href">
					<xsl:choose>
						<xsl:when test="$to"><xsl:value-of select="$to/@href"/></xsl:when>
						<xsl:otherwise><xsl:value-of  
select="$int-links[1]/@href"/></xsl:otherwise>
					</xsl:choose>
				</xsl:attribute>
				<xsl:attribute name="title">
					<xsl:choose>
						<xsl:when test="$to"><xsl:value-of  
select="$to/@title"/></xsl:when>
						<xsl:otherwise><xsl:value-of  
select="$int-links[1]/@title"/></xsl:otherwise>
					</xsl:choose>
				</xsl:attribute>
			</int-link>
			<xsl:apply-templates/>
		</xsl:copy>
	</xsl:template>

	<xsl:template match="link[@rel='chapter-link']">
		<link href="{@href}" rel="Chapter" title="{@title}"/>
	</xsl:template>

	<xsl:template match="link[@rel='section-link']"/>

   <xsl:template match="@*|node()"  
priority="-2"><xsl:copy><xsl:apply-templates  
select="@*|node()"/></xsl:copy></xsl:template>
   <xsl:template match="text()" priority="-1"><xsl:value-of  
select="."/></xsl:template>

</xsl:stylesheet>


This appears to be the reported error:

root cause

java.lang.VerifyError: (class: make_chapter_links$4, method: test  
signature:  
(IIIILorg/apache/xalan/xsltc/runtime/AbstractTranslet;Lorg/apache/ 
xalan/xsltc/NodeIterator;)Z) Incompatible argument to function
	at make_chapter_links.applyTemplates()
	at make_chapter_links.applyTemplates()
	at make_chapter_links.applyTemplates()
	at make_chapter_links.transform()
	at  
org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTransl 
et.java:540)
	at  
org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.ja 
va:635)

regards Jeremy


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

Re: [important proposal] Cocoon as official Apache project

Posted by Pier Fumagalli <pi...@betaversion.org>.

"Steven Noels" <st...@outerthought.org> wrote:

> Pier Fumagalli wrote:
> 
>> Daedalus and Icarus are located in San Francisco, and Proxy-Pass is (IMVHO),
>> a quite silly idea... Not only we need bandwidth to _deliver_ pages, we also
>> need bandwidth to _retrieve_ the pages...
> 
> Agree, but it would be a nice solution to distribute the load,
> especially for not-so-dynamic content. I was thinking of the combination
> of mod_proxy together with mod_cache anyhow. I'll be testing this
> somewhere next week on a private server.
> 
> Given this setup, the Cocoon community has the ability to showcase its
> technology while still benefiting from the kind bandwidth donation of
> Collab/Sun. I know it sounds like piggybacking, but it would provide us
> with a nice balance of being able to do our own thing, possibly
> attracting other co-sponsors, until we are able to provide both CPU
> cycles and bandwidth ourselves.

Can't you just redirect? I mean... If you have to showcase static content
(that's where mod_cache could help), you can generate it offline, and put it
up on daedalus as static HTML files, and forget about it...

If you're generating dynamic content, mod_cache wouldn't help (as it's
dynamic), and it would only make things harder...

(what's "not-so-dynamic content, btw?)

Or am I _waaay_ off the hook here?

    Pier


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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Pier Fumagalli wrote:

> Daedalus and Icarus are located in San Francisco, and Proxy-Pass is (IMVHO),
> a quite silly idea... Not only we need bandwidth to _deliver_ pages, we also
> need bandwidth to _retrieve_ the pages...

Agree, but it would be a nice solution to distribute the load, 
especially for not-so-dynamic content. I was thinking of the combination 
of mod_proxy together with mod_cache anyhow. I'll be testing this 
somewhere next week on a private server.

Given this setup, the Cocoon community has the ability to showcase its 
technology while still benefiting from the kind bandwidth donation of 
Collab/Sun. I know it sounds like piggybacking, but it would provide us 
with a nice balance of being able to do our own thing, possibly 
attracting other co-sponsors, until we are able to provide both CPU 
cycles and bandwidth ourselves.

I went shopping around for other sponsors (some Belgian ISPs) some 
months ago, but since Cocoon hasn't reached that level of market 
recognition yet, we are basically on our own. But hopefully, if we are 
able to showcase our technology, that will change (and we are very much 
open to it).

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org

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

Re: [important proposal] Cocoon as official Apache project

Posted by Pier Fumagalli <pi...@betaversion.org>.

"Steven Noels" <st...@outerthought.org> wrote:

>>> However, I wonder if proxypassing from San Diego (IIRC this is where
>>> icarus and daedalus are) to Ghent or another european location is
>>> technically ok?
>> 
>> Don't use geographical topology as a metric. Steven, what is the network
>> topology between the ASF machines and the one we would be using?
> 
> From daedalus:
> 
> bash-2.05a$ traceroute cocoondev.org
> traceroute to cocoondev.org (209.15.201.32), 64 hops max, 44 byte packets
> 1  fa3-13.br1.sfo.collab.net (63.251.56.130)  0.293 ms  0.239 ms  0.161 ms
> [...]
> 14  cocoondev.org (209.15.201.32)  56.805 ms  57.370 ms  57.527 ms
> 
> The machine is located in Kansas City, US, not in Ghent. And maybe we
> can tweak routing tables from daedalus to cocoondev.org.
> 
> Ping times are averaging 60ms. Cannot test from nagoya, don't have an
> account there. While it doesn't reach the level of interconnectedness as
> daedalus & nagoya, I think the interconnection is more than decent
> enough for a proxypass solution. Let's ask the network gurus of
> infrastructure@apache.org (I feel like in a 'coming-out' mode anyhow :-)

Daedalus and Icarus are located in San Francisco, and Proxy-Pass is (IMVHO),
a quite silly idea... Not only we need bandwidth to _deliver_ pages, we also
need bandwidth to _retrieve_ the pages...

    Pier


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

Re: [important proposal] Cocoon as official Apache project

Posted by Brian Behlendorf <br...@collab.net>.

On Fri, 1 Nov 2002, Steven Noels wrote:
> Ping times are averaging 60ms. Cannot test from nagoya, don't have an
> account there. While it doesn't reach the level of interconnectedness as
> daedalus & nagoya, I think the interconnection is more than decent
> enough for a proxypass solution. Let's ask the network gurus of
> infrastructure@apache.org (I feel like in a 'coming-out' mode anyhow :-)

I would really really really prefer not to proxypass to a server that
isn't right next door to the proxy.  Let's say the network has a bad hair
day; requests back up on the proxy.  I'd much rather just assign a
.apache.org hostname to this other host.

	Brian




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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
> 
>> I like this idea, as we need, as shown by cocoondev.org, to host some
>> live Cocoon apps. But we *must* also use the common infrastructure
>> provided by daedalus and icarus when it makes sense : static website,
>> distros, mailing lists and cvs (IMHO including the ones of
>> cocoondev.org). 
> 
> 
> Absolutely. It would be plain silly to redo something that already works 
> great (CVS/mail/static web are just great and managed very well, IMO).

Sure: the CVS/list services on cocoondev.org would only be for 
non-Apache Cocoon-based projects.

> What we lack is the ability to host our own web applications and this is 
>  what we want to fix.
> 
>> This ensures we won't be tempted by a "Cocoon software
>> foundation" (even if I'm sure Stefano will take great care to avoid
>> this), save bandwidth, CPU and administration costs for 
>> people/entities offering resource for live applications.
> 
> 
> Oh, you can bet your ass here :)

No worries here too: while Cocoon is a great project & community, I 
would never started working with it if it wasn't an Apache project. And 
I'd opt for the proxypass solution rather than switching DNS.

>> Proxypassing will also allow to have _several_ machines behind
>> cocoon.apache.org. This can provide simple load partitioning and allow
>> different members of the community to offer CPU and bandwidth (nothing
>> sure for now, but I'd like my company to offer some).
> 
> 
> Yep. Also, as Steven and I discussed on the phone, most of the bandwidth 
> is used by distributions and Pier told me that infrastructure@ is 
> building a pretty nice rsync-based mirroring system.
> 
> So it makes perfect sense to use the ASF machinery when it works and 
> just *patch* what we need.
> 
>> However, I wonder if proxypassing from San Diego (IIRC this is where
>> icarus and daedalus are) to Ghent or another european location is
>> technically ok?
> 
> 
> Don't use geographical topology as a metric. Steven, what is the network 
> topology between the ASF machines and the one we would be using?

 From daedalus:

bash-2.05a$ traceroute cocoondev.org
traceroute to cocoondev.org (209.15.201.32), 64 hops max, 44 byte packets
  1  fa3-13.br1.sfo.collab.net (63.251.56.130)  0.293 ms  0.239 ms  0.161 ms
  2  200.ge2-0.er2b.sjc3.us.mfnx.net (64.124.78.35)  0.657 ms  0.280 ms 
  0.438 ms
  3  so-1-2-0.cr1.sjc3.us.mfnx.net (208.185.175.193)  0.554 ms  0.406 ms 
  10.012 ms
  4  pos9-1.mpr1.pao1.us.mfnx.net (208.184.232.178)  0.940 ms  0.891 ms 
  0.877 ms
  5  64.124.11.198.cogent-above.above.net (64.124.11.198)  1.464 ms 
1.525 ms  1.466 ms
  6  p6-0.core02.sfo01.atlas.cogentco.com (66.28.4.149)  1.512 ms  1.948 
ms  1.577 ms
  7  p15-0.core01.den01.atlas.cogentco.com (66.28.4.129)  43.539 ms 
43.037 ms  43.010 ms
  8  p5-0.core01.mci01.atlas.cogentco.com (66.28.4.30)  43.073 ms 
42.990 ms  43.088 ms
  9  g50.ba01.b006121-1.mci01.atlas.cogentco.com (66.28.65.130)  43.142 
ms  43.001 ms  43.050 ms
10  hosting4u.demarc.cogentco.com (66.250.5.98)  56.774 ms  56.990 ms 
56.631 ms
11  core2-POS3-0.KCY.hosting4u.net (209.15.6.97)  58.486 ms  56.611 ms 
56.589 ms
12  net2-vlan1-sup2.KCY.hosting4u.net (209.15.116.246)  56.965 ms 
57.326 ms  56.902 ms
13  fw.kc.aoindustries.com (209.15.126.2)  56.802 ms  57.651 ms  57.188 ms
14  cocoondev.org (209.15.201.32)  56.805 ms  57.370 ms  57.527 ms

The machine is located in Kansas City, US, not in Ghent. And maybe we 
can tweak routing tables from daedalus to cocoondev.org.

Ping times are averaging 60ms. Cannot test from nagoya, don't have an 
account there. While it doesn't reach the level of interconnectedness as 
daedalus & nagoya, I think the interconnection is more than decent 
enough for a proxypass solution. Let's ask the network gurus of 
infrastructure@apache.org (I feel like in a 'coming-out' mode anyhow :-)

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


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

Re: [important proposal] Cocoon as official Apache project

Posted by Stefano Mazzocchi <st...@apache.org>.

Sylvain Wallez wrote:

> I like this idea, as we need, as shown by cocoondev.org, to host some
> live Cocoon apps. But we *must* also use the common infrastructure
> provided by daedalus and icarus when it makes sense : static website,
> distros, mailing lists and cvs (IMHO including the ones of
> cocoondev.org). 

Absolutely. It would be plain silly to redo something that already works 
great (CVS/mail/static web are just great and managed very well, IMO).

What we lack is the ability to host our own web applications and this is 
  what we want to fix.

> This ensures we won't be tempted by a "Cocoon software
> foundation" (even if I'm sure Stefano will take great care to avoid
> this), save bandwidth, CPU and administration costs for 
> people/entities offering resource for live applications.

Oh, you can bet your ass here :)

> Proxypassing will also allow to have _several_ machines behind
> cocoon.apache.org. This can provide simple load partitioning and allow
> different members of the community to offer CPU and bandwidth (nothing
> sure for now, but I'd like my company to offer some).

Yep. Also, as Steven and I discussed on the phone, most of the bandwidth 
is used by distributions and Pier told me that infrastructure@ is 
building a pretty nice rsync-based mirroring system.

So it makes perfect sense to use the ASF machinery when it works and 
just *patch* what we need.

> However, I wonder if proxypassing from San Diego (IIRC this is where
> icarus and daedalus are) to Ghent or another european location is
> technically ok?

Don't use geographical topology as a metric. Steven, what is the network 
topology between the ASF machines and the one we would be using?

>  Don't you fear about tcp packets making a trip around
> the earth when you send a request through cocoon.apache.org to the
> machine that's in the room next door ?

Here in Italy is many times faster to download from cupertino than it is 
from germany :) Like I said, it's a matter of pipes, bandwidth and 
hosts, and this has nothing to do with geographical location.

Anyway, I think it would be a great challenge for us to run that system. 
It would really show off the power of Cocoon and dissipate some of those 
'it doesn't handle load' myths that I've heard flying around :)

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------

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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>
Sent: Friday, November 01, 2002 5:20 AM
Subject: Re: [important proposal] Cocoon as official Apache project


> Advantages to the Apache reverse proxy solution is that
> 1) Many Cocoon pages can be cached, incurring much lighter load on the
> actual application servers. Also if there is a temporary downtime for the
> app server, visitors are likely to see at least the top level site pages.

> How would we split the site then? Keep the current one on the apache
machine
and have only the samples and dynamic pages served by cocoondev.org?


Well, if we are given our own directory on the apache server,
we can configure and reconfigure mod_proxy on it without affecting the main
httpd.conf. With mod_proxy and mod_disk_cache, we won't need to host any
content on the web server. mod_cache automatically stores locally cacheable
content and content withe expiration dates. I am using this combination on
production systems.

http://httpd.apache.org/docs-2.0/mod/mod_cache.html
http://httpd.apache.org/docs-2.0/mod/mod_proxy.html

> 2) It is much easier to modify an apache config file, then it is to modify
> a DNS table. I don't mean editing the files, but the process it involves
to
> obtain permission for modification.

>aggreed. IMO we should use DNS only if cocoondev.org makes it under the
umbrella of apache anyway.

>Does anyone know if mod_proxy still supports only HTTP 1.0?

>From the 2.0 docs:
"This module implements a proxy/gateway for Apache. It implements proxying
capability for FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1. The
module can be configured to connect to other proxy modules for these and
other protocols."



Ivelin



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

Re: [important proposal] Cocoon as official Apache project

Posted by Torsten Curdt <tc...@dff.st>.

> Advantages to the Apache reverse proxy solution is that
> 1) Many Cocoon pages can be cached, incurring much lighter load on the
> actual application servers. Also if there is a temporary downtime for the
> app server, visitors are likely to see at least the top level site pages.

How would we split the site then? Keep the current one on the apache machine 
and have only the samples and dynamic pages served by cocoondev.org?

> 2) It is much easier to modify an apache config file, then it is to modify
> a DNS table. I don't mean editing the files, but the process it involves to
> obtain permission for modification.

aggreed. IMO we should use DNS only if cocoondev.org makes it under the 
umbrella of apache anyway.

Does anyone know if mod_proxy still supports only HTTP 1.0?
--
Torsten

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

Re: [important proposal] Cocoon as official Apache project

Posted by Ovidiu Predescu <ov...@cup.hp.com>.

On Thursday, Oct 31, 2002, at 19:51 US/Pacific, Ivelin Ivanov wrote:

>
> Advantages to the Apache reverse proxy solution is that
> 1) Many Cocoon pages can be cached, incurring much lighter load on the
> actual application servers. Also if there is a temporary downtime for 
> the
> app server, visitors are likely to see at least the top level site 
> pages.

You can still put a proxy in front of each server, thus effectively 
having a network of machines hosting Cocoon, each with its own proxy.

> 2) It is much easier to modify an apache config file, then it is to 
> modify a
> DNS table. I don't mean editing the files, but the process it involves 
> to
> obtain permission for modification.

How would that be different from obtaining the permission to modify the 
config file of Apache on the main server of apache.org? The DNS server 
and the Web server run on the same machine.

Also I wish we could have every day a company willing to allocate 
hardware resources for hosting Cocoon. In reality, we'll have very few 
such machines, perhaps only a couple to start with. So the DNS 
modification process is really a non-issue.

The Apache proxy solution has its own problems, the biggest one being 
the assumption of a central HTTP server (read single point of failure) 
which needs to direct the traffic to the backend servers.

The DNS load balancing solution was the easiest solution I came up 
with, I'm sure more knowledgeable people than me have better solutions.

> ----- Original Message -----
> From: "Ovidiu Predescu" <ov...@cup.hp.com>
> To: <co...@xml.apache.org>
> Sent: Thursday, October 31, 2002 5:50 PM
> Subject: Re: [important proposal] Cocoon as official Apache project
>
>
>>
>> On Thursday, Oct 31, 2002, at 14:07 US/Pacific, Sylvain Wallez wrote:
>>
>>> Steven Noels wrote:
>>>
>>>> Lists for Cocoon-core development should stay at daedalus, as cvs 
>>>> for
>>>> Cocoon-core should stay at icarus, but maybe, if someone builds a
>>>> cool webmailarchive using Cocoon, we would be able to run that
>>>> software on our own machine, without heavy lobbying of 'the powers
>>>> that be' at infrastructure@apache.org.
>>>>
>>>> Mind you that I really appreciate the hardware resources so kindly
>>>> offered by Collab & Sun, but given the broad range of projects &
>>>> services they have to support, and the inevitable burden that comes
>>>> with this, I believe everybody will be better off if we do our own
>>>> thing ("we" and "our" as in the Cocoon developers community), maybe
>>>> reverse proxied by nagoya for load & bandwidth purposes.
>>>>
>>>> Along the Cocoon-core website and the possible developers community
>>>> website (of which the Wiki could be part), there is still space to
>>>> host other Cocoon-related projects, part of the initial version
>>>> behind cocoondev.org.
>>>
>>>
>>> I like this idea, as we need, as shown by cocoondev.org, to host some
>>> live Cocoon apps. But we *must* also use the common infrastructure
>>> provided by daedalus and icarus when it makes sense : static website,
>>> distros, mailing lists and cvs (IMHO including the ones of
>>> cocoondev.org). This ensures we won't be tempted by a "Cocoon 
>>> software
>>> foundation" (even if I'm sure Stefano will take great care to avoid
>>> this), save bandwidth, CPU and administration costs for
>>> people/entities offering resource for live applications.
>>>
>>> Proxypassing will also allow to have _several_ machines behind
>>> cocoon.apache.org. This can provide simple load partitioning and 
>>> allow
>>> different members of the community to offer CPU and bandwidth 
>>> (nothing
>>> sure for now, but I'd like my company to offer some).
>>>
>>> However, I wonder if proxypassing from San Diego (IIRC this is where
>>> icarus and daedalus are) to Ghent or another european location is
>>> technically ok ? Don't you fear about tcp packets making a trip 
>>> around
>>> the earth when you send a request through cocoon.apache.org to the
>>> machine that's in the room next door ?
>>
>> There's no need for proxying via HTTP, we can solve the problem a lot
>> easier from DNS. Just change the main DNS at apache.org point to the 
>> IP
>> address of the machine which hosts cocoondev.org and we're set. If 
>> need
>> be to do load balancing, we can do that from DNS as well using a 
>> simple
>> rotating DNS policy. If other companies want to support it, we can
>> simply add their machines to the DNS pool.
>>
>> The point is we need a machine to host live Cocoon instances, most
>> likely the machines at collab.net will not have the resources to do 
>> it.
>> We need other machine(s) for this task, and since Steven and
>> outerthought have already thrown hardware and money at it why not use
>> them?
>>
>> Greetings,
>> --
>> Ovidiu Predescu <ov...@apache.org>
>> http://webweavertech.com/ovidiu/weblog/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

Advantages to the Apache reverse proxy solution is that
1) Many Cocoon pages can be cached, incurring much lighter load on the
actual application servers. Also if there is a temporary downtime for the
app server, visitors are likely to see at least the top level site pages.

2) It is much easier to modify an apache config file, then it is to modify a
DNS table. I don't mean editing the files, but the process it involves to
obtain permission for modification.


Ivelin


----- Original Message -----
From: "Ovidiu Predescu" <ov...@cup.hp.com>
To: <co...@xml.apache.org>
Sent: Thursday, October 31, 2002 5:50 PM
Subject: Re: [important proposal] Cocoon as official Apache project


>
> On Thursday, Oct 31, 2002, at 14:07 US/Pacific, Sylvain Wallez wrote:
>
> > Steven Noels wrote:
> >
> >> Lists for Cocoon-core development should stay at daedalus, as cvs for
> >> Cocoon-core should stay at icarus, but maybe, if someone builds a
> >> cool webmailarchive using Cocoon, we would be able to run that
> >> software on our own machine, without heavy lobbying of 'the powers
> >> that be' at infrastructure@apache.org.
> >>
> >> Mind you that I really appreciate the hardware resources so kindly
> >> offered by Collab & Sun, but given the broad range of projects &
> >> services they have to support, and the inevitable burden that comes
> >> with this, I believe everybody will be better off if we do our own
> >> thing ("we" and "our" as in the Cocoon developers community), maybe
> >> reverse proxied by nagoya for load & bandwidth purposes.
> >>
> >> Along the Cocoon-core website and the possible developers community
> >> website (of which the Wiki could be part), there is still space to
> >> host other Cocoon-related projects, part of the initial version
> >> behind cocoondev.org.
> >
> >
> > I like this idea, as we need, as shown by cocoondev.org, to host some
> > live Cocoon apps. But we *must* also use the common infrastructure
> > provided by daedalus and icarus when it makes sense : static website,
> > distros, mailing lists and cvs (IMHO including the ones of
> > cocoondev.org). This ensures we won't be tempted by a "Cocoon software
> > foundation" (even if I'm sure Stefano will take great care to avoid
> > this), save bandwidth, CPU and administration costs for
> > people/entities offering resource for live applications.
> >
> > Proxypassing will also allow to have _several_ machines behind
> > cocoon.apache.org. This can provide simple load partitioning and allow
> > different members of the community to offer CPU and bandwidth (nothing
> > sure for now, but I'd like my company to offer some).
> >
> > However, I wonder if proxypassing from San Diego (IIRC this is where
> > icarus and daedalus are) to Ghent or another european location is
> > technically ok ? Don't you fear about tcp packets making a trip around
> > the earth when you send a request through cocoon.apache.org to the
> > machine that's in the room next door ?
>
> There's no need for proxying via HTTP, we can solve the problem a lot
> easier from DNS. Just change the main DNS at apache.org point to the IP
> address of the machine which hosts cocoondev.org and we're set. If need
> be to do load balancing, we can do that from DNS as well using a simple
> rotating DNS policy. If other companies want to support it, we can
> simply add their machines to the DNS pool.
>
> The point is we need a machine to host live Cocoon instances, most
> likely the machines at collab.net will not have the resources to do it.
> We need other machine(s) for this task, and since Steven and
> outerthought have already thrown hardware and money at it why not use
> them?
>
> Greetings,
> --
> Ovidiu Predescu <ov...@apache.org>
> http://webweavertech.com/ovidiu/weblog/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

Re: [important proposal] Cocoon as official Apache project

Posted by Ovidiu Predescu <ov...@cup.hp.com>.

On Thursday, Oct 31, 2002, at 14:07 US/Pacific, Sylvain Wallez wrote:

> Steven Noels wrote:
>
>> Lists for Cocoon-core development should stay at daedalus, as cvs for 
>> Cocoon-core should stay at icarus, but maybe, if someone builds a 
>> cool webmailarchive using Cocoon, we would be able to run that 
>> software on our own machine, without heavy lobbying of 'the powers 
>> that be' at infrastructure@apache.org.
>>
>> Mind you that I really appreciate the hardware resources so kindly 
>> offered by Collab & Sun, but given the broad range of projects & 
>> services they have to support, and the inevitable burden that comes 
>> with this, I believe everybody will be better off if we do our own 
>> thing ("we" and "our" as in the Cocoon developers community), maybe 
>> reverse proxied by nagoya for load & bandwidth purposes.
>>
>> Along the Cocoon-core website and the possible developers community 
>> website (of which the Wiki could be part), there is still space to 
>> host other Cocoon-related projects, part of the initial version 
>> behind cocoondev.org.
>
>
> I like this idea, as we need, as shown by cocoondev.org, to host some 
> live Cocoon apps. But we *must* also use the common infrastructure 
> provided by daedalus and icarus when it makes sense : static website, 
> distros, mailing lists and cvs (IMHO including the ones of 
> cocoondev.org). This ensures we won't be tempted by a "Cocoon software 
> foundation" (even if I'm sure Stefano will take great care to avoid 
> this), save bandwidth, CPU and administration costs for 
> people/entities offering resource for live applications.
>
> Proxypassing will also allow to have _several_ machines behind 
> cocoon.apache.org. This can provide simple load partitioning and allow 
> different members of the community to offer CPU and bandwidth (nothing 
> sure for now, but I'd like my company to offer some).
>
> However, I wonder if proxypassing from San Diego (IIRC this is where 
> icarus and daedalus are) to Ghent or another european location is 
> technically ok ? Don't you fear about tcp packets making a trip around 
> the earth when you send a request through cocoon.apache.org to the 
> machine that's in the room next door ?

There's no need for proxying via HTTP, we can solve the problem a lot 
easier from DNS. Just change the main DNS at apache.org point to the IP 
address of the machine which hosts cocoondev.org and we're set. If need 
be to do load balancing, we can do that from DNS as well using a simple 
rotating DNS policy. If other companies want to support it, we can 
simply add their machines to the DNS pool.

The point is we need a machine to host live Cocoon instances, most 
likely the machines at collab.net will not have the resources to do it. 
We need other machine(s) for this task, and since Steven and 
outerthought have already thrown hardware and money at it why not use 
them?

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/


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

Re: [important proposal] Cocoon as official Apache project

Posted by Sylvain Wallez <sy...@anyware-tech.com>.

Steven Noels wrote:

> Carsten Ziegeler wrote:
>
>> But, *if* Cocoon becomes a top-level project, I'm not sure if it is also
>> a good thing to use cocoondev.org as the infrastructure. Now I see
>> two possible problems:
>>
>> a) What is hosted where? Is a mailing list hosted at apache or at
>>    cocoondev.org etc. Of course, this might not be a big thing, but
>>    it could confuse others.
>>    We could use cocoondev.org for example for show casing Cocoon
>>    and everything else is hosted at apache.
>
>
> First things first: cocoondev.org is simply a machine name, and it is 
> currently listening to/hosting outerthought.org, 
> forrest.cocoondev.org, and whatever name we could invent for it: the 
> joy of DNS :-)
>
> So when I say cocoondev.org, I simply mean the machine (and its 
> primary name, which even could be changed if we really would like to).
>
> Technically, I was thinking along these lines: we use cocoondev.org 
> (the machine) to host the new website and the developers community 
> website, which is being ProxyPassed [1] by daedalus or nagoya as 
> cocoon.apache.org. That way, we leverage [2] the existing bandwidth 
> availability and are able to use the lowered load on our (= the cocoon 
> community) own machine for 'cool stuff'. The main website can make use 
> of all dynamic features we would like to use, but with some clever 
> expiry header setting we still can benefit of a reverse proxy, formed 
> by nagoya or daedalus.
>
> [1] http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypass
> [2] buzzword bingo: 1 point :-)

Hey, we're also using the "XML" buzzword all the time ;-)

> Lists for Cocoon-core development should stay at daedalus, as cvs for 
> Cocoon-core should stay at icarus, but maybe, if someone builds a cool 
> webmailarchive using Cocoon, we would be able to run that software on 
> our own machine, without heavy lobbying of 'the powers that be' at 
> infrastructure@apache.org.
>
> Mind you that I really appreciate the hardware resources so kindly 
> offered by Collab & Sun, but given the broad range of projects & 
> services they have to support, and the inevitable burden that comes 
> with this, I believe everybody will be better off if we do our own 
> thing ("we" and "our" as in the Cocoon developers community), maybe 
> reverse proxied by nagoya for load & bandwidth purposes.
>
> Along the Cocoon-core website and the possible developers community 
> website (of which the Wiki could be part), there is still space to 
> host other Cocoon-related projects, part of the initial version behind 
> cocoondev.org.


I like this idea, as we need, as shown by cocoondev.org, to host some 
live Cocoon apps. But we *must* also use the common infrastructure 
provided by daedalus and icarus when it makes sense : static website, 
distros, mailing lists and cvs (IMHO including the ones of 
cocoondev.org). This ensures we won't be tempted by a "Cocoon software 
foundation" (even if I'm sure Stefano will take great care to avoid 
this), save bandwidth, CPU and administration costs for people/entities 
offering resource for live applications.

Proxypassing will also allow to have _several_ machines behind 
cocoon.apache.org. This can provide simple load partitioning and allow 
different members of the community to offer CPU and bandwidth (nothing 
sure for now, but I'd like my company to offer some).

However, I wonder if proxypassing from San Diego (IIRC this is where 
icarus and daedalus are) to Ghent or another european location is 
technically ok ? Don't you fear about tcp packets making a trip around 
the earth when you send a request through cocoon.apache.org to the 
machine that's in the room next door ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Carsten Ziegeler wrote:

> Anyway, we should not discuss on this little issue further, 
> I think we all agree on the same with this aspect.

For sure - no bad feelings here anymore.

Cheers,

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


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

RE: [important proposal] Cocoon as official Apache project

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Thursday, October 31, 2002 9:32 PM
> To: cocoon-dev@xml.apache.org
> Cc: Dirk-Willem van Gulik
> Subject: Re: [important proposal] Cocoon as official Apache project

> > Perhaps we can talk more about this at the gettogether.
> 
> Yeah, but let's try to use the list so that non-attendees are being 
> informed, too. We've just seen what happens if people don't understand 
> each other because of non-explicit communication :-)
> 
And we also saw the opposite :)

I see no problem with this because discussing something in private
is something completly different thatn deciding this. 
What is the difference between one person doing a RT or
three people creating together in private this RT?
Anyway, we should not discuss on this little issue further, 
I think we all agree on the same with this aspect.

Thanks
Carsten



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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Carsten Ziegeler wrote:

> But, *if* Cocoon becomes a top-level project, I'm not sure if it is also
> a good thing to use cocoondev.org as the infrastructure. Now I see
> two possible problems:
> 
> a) What is hosted where? Is a mailing list hosted at apache or at
>    cocoondev.org etc. Of course, this might not be a big thing, but
>    it could confuse others.
>    We could use cocoondev.org for example for show casing Cocoon
>    and everything else is hosted at apache.

First things first: cocoondev.org is simply a machine name, and it is 
currently listening to/hosting outerthought.org, forrest.cocoondev.org, 
and whatever name we could invent for it: the joy of DNS :-)

So when I say cocoondev.org, I simply mean the machine (and its primary 
name, which even could be changed if we really would like to).

Technically, I was thinking along these lines: we use cocoondev.org (the 
machine) to host the new website and the developers community website, 
which is being ProxyPassed [1] by daedalus or nagoya as 
cocoon.apache.org. That way, we leverage [2] the existing bandwidth 
availability and are able to use the lowered load on our (= the cocoon 
community) own machine for 'cool stuff'. The main website can make use 
of all dynamic features we would like to use, but with some clever 
expiry header setting we still can benefit of a reverse proxy, formed by 
nagoya or daedalus.

[1] http://httpd.apache.org/docs-2.0/mod/mod_proxy.html#proxypass
[2] buzzword bingo: 1 point :-)

Lists for Cocoon-core development should stay at daedalus, as cvs for 
Cocoon-core should stay at icarus, but maybe, if someone builds a cool 
webmailarchive using Cocoon, we would be able to run that software on 
our own machine, without heavy lobbying of 'the powers that be' at 
infrastructure@apache.org.

Mind you that I really appreciate the hardware resources so kindly 
offered by Collab & Sun, but given the broad range of projects & 
services they have to support, and the inevitable burden that comes with 
this, I believe everybody will be better off if we do our own thing 
("we" and "our" as in the Cocoon developers community), maybe reverse 
proxied by nagoya for load & bandwidth purposes.

Along the Cocoon-core website and the possible developers community 
website (of which the Wiki could be part), there is still space to host 
other Cocoon-related projects, part of the initial version behind 
cocoondev.org.

> b) Legal issues. To be honest, I don't know much about legal things,
>    but I guess that it might make a difference if something is done
>    on a server hosted by apache or on a server not hosted by apache.

See Ovidiu's remark - those machines aren't necesserally owned by the 
ASF, I believe - and I'm pretty sure the bandwidth bills are paid by 
Collab, not by the ASF. The reason for investigating possible official 
endorsement by the ASF (dunnow how that would look like, but anyhow - 
maybe http://xml.apache.org/ack.html comes close ;-) is exactly to make 
sure that eventual legal issues are covered (Dirk?).

> Don't get me wrong, I really like the idea of cocoondev.org and as long
> as Cocoon is not a top-level project, it's the only way.
> But if we become a top-level project, I really like the idea to "fix
> the current problems/shortcommings" here at Apache.
> 
> Perhaps we can talk more about this at the gettogether.

Yeah, but let's try to use the list so that non-attendees are being 
informed, too. We've just seen what happens if people don't understand 
each other because of non-explicit communication :-)

Thanks for your remarks!

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org

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

Re: [important proposal] Cocoon as official Apache project

Posted by Ovidiu Predescu <ov...@apache.org>.

Carsten,

I don't think we have a problem here. So far Apache has been using 
machines offered by collab.net if I'm not mistaken to host all the Web 
sites and the overall infrastructure (mailing lists, CVS etc.). For 
them this incurs some costs and administrative headaches obviously. If 
some projects choose to offload them and host at least their Web site 
on a different machine, it should be no problem.

We can still maintain the mailing lists, CVS at collab.net as they are 
right now, but place the Web site on the same machine which hosts 
cocoondev.org. We can arrange to have cocoon.apache.org point to this 
machine.

IMO cocoon.apache.org and cocoondev.org should remain separate, 
preferably the later under the same ASF umbrella:

- cocoon.apache.org should host Cocoon, the project

- cocoondev.org should host applications using Cocoon, which may or may 
not be free of commercial interests

Using the same infrastructure will help us minimize the administrative 
costs which translates into more time spent on useful work.

I don't think there's any legal issue having the machine hosted 
elsewhere, but I may be wrong. Dirk?

Best regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/

On Thursday, Oct 31, 2002, at 03:04 US/Pacific, Carsten Ziegeler wrote:

>
> Steven Noels wrote:
>> <snipped good explanation I really value/>
>
> I really value your effort, Steven, and of course of those others 
> helping
> you
> in createing cocoondev.org. It's a great idea! And I don't want that 
> you
> have to throw away all the effort already put into cocoondev.org.
>
> But, *if* Cocoon becomes a top-level project, I'm not sure if it is 
> also
> a good thing to use cocoondev.org as the infrastructure. Now I see
> two possible problems:
>
> a) What is hosted where? Is a mailing list hosted at apache or at
>    cocoondev.org etc. Of course, this might not be a big thing, but
>    it could confuse others.
>    We could use cocoondev.org for example for show casing Cocoon
>    and everything else is hosted at apache.
>
> b) Legal issues. To be honest, I don't know much about legal things,
>    but I guess that it might make a difference if something is done
>    on a server hosted by apache or on a server not hosted by apache.
>
> Don't get me wrong, I really like the idea of cocoondev.org and as long
> as Cocoon is not a top-level project, it's the only way.
> But if we become a top-level project, I really like the idea to "fix
> the current problems/shortcommings" here at Apache.
>
> Perhaps we can talk more about this at the gettogether.
>
> Carsten
>

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

RE: [important proposal] Cocoon as official Apache project

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

Steven Noels wrote:
> <snipped good explanation I really value/>

I really value your effort, Steven, and of course of those others helping
you
in createing cocoondev.org. It's a great idea! And I don't want that you
have to throw away all the effort already put into cocoondev.org.

But, *if* Cocoon becomes a top-level project, I'm not sure if it is also
a good thing to use cocoondev.org as the infrastructure. Now I see
two possible problems:

a) What is hosted where? Is a mailing list hosted at apache or at
   cocoondev.org etc. Of course, this might not be a big thing, but
   it could confuse others.
   We could use cocoondev.org for example for show casing Cocoon
   and everything else is hosted at apache.

b) Legal issues. To be honest, I don't know much about legal things,
   but I guess that it might make a difference if something is done
   on a server hosted by apache or on a server not hosted by apache.

Don't get me wrong, I really like the idea of cocoondev.org and as long
as Cocoon is not a top-level project, it's the only way.
But if we become a top-level project, I really like the idea to "fix
the current problems/shortcommings" here at Apache.

Perhaps we can talk more about this at the gettogether.

Carsten


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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Stefano Mazzocchi wrote:

  > Steven Noels wrote:
  >

  > NOTE for others: Steven called me on the phone to apologize for the
  > tone of this email. So, please, people, let's keep the tone of the
  > conversation constructive.

That's a nice way of summarizing our phone call, even though its main
purpose was finding out that we were effectively misunderstanding each
other ;-)

But all is quiet now, and we live in peace & happily ever after.

<snip type="agree"/>

Maybe it's time for some clarification right now: what is this
cocoondev.org stuff all about?

Well, basically it's the itch/scratch scenario all too common to us. I
wasn't happy with the infrastructure ASF so kindly provides to us, it
being FreeBSD machines without decent Java support, and a Solaris
machine of which I heard already that it was quite difficult to
administer, let alone get access to it. And Forrest wanted to run its
automated bots on ASF equipment instead of on outerthought.net.

Besides, we (Outerthought) had been hosting our own website for quite
some time with http://www.aoindustries.com/, and were very happy with
those people. We found out on a regular basis that other Apache people
were using the services of AO, too. AO positions themselves as an
Application Infrastructure Provider, basically managed server hosting,
but servers specifically configured for Java web hosting, with multiple
accounts/projects on one machine without interfering with each other.

So what I started thinking of was some kind of Sourceforge-like
infrastructure, but specifically aimed at Cocoon projects. The 'big
problem' I had with Cocoon-based development using the current ASF
infrastructure was that we had email lists and CVS, but no place to
'showcase' what we have been building _on_top_of_ Cocoon, or you had to
rent your own webserver - so I thought it would be nice to offer that as
a service to the community: a server where people can show what they
have been building using Cocoon, and host a number of other
community-related resources like the Cocoon Documentation Project, its
Wiki, the webapp version of Forrest, and whatelse: very similar to the
relationship between mozilla.org and mozdev.org

Funding the kickstart of such a thing was possible at that moment for
us, so I went talking with AO and we now have a machine up & running,
mostly ready to create user accounts and host projects. Finding the
time for readying a website explaining all this however was difficult,
so I was doing some background discussion with the people listed at the
bottom of http://cocoondev.org/, trying to find fellow supporters
(remember: supporters-subscribe@lists.cocoondev.org) so that we had some
kind of contingency plan of my own company failed to continue supporting
this initiative at some point in time.

I had the intention of broadly announcing this initiative on the Cocoon
GetTogether, and also to use cocoondev.org as a platform for releasing
xReporter, our little database reporting engine on top of Avalon &
Cocoon, later during the year.

Then came the reorg@apache.org list, and the idea of
levelling/flattifying the current project hierarchy of the ASF, 
basically what has lead to Stefano's proposal of 'going top-level' with
cocoon.apache.org. Already, I had been searching for a way for
cocoondev.org to become somehow 'officially endorsed' by the ASF, also
to provide some contingency to the community when Outerthought fails to
further support it. But again time constraints were cropping up, and I
didn't find the time nor the energy to write a proposal. The issue of an 
Infrastructure PMC at the ASF level has now been put on the todo list of 
Dirk-Willem van Gulik, which I happen to meet in two weeks on a 
conference, so maybe we'll be able to talk about it. All in all, the 
entire reorg thing has speeded up the willingness to change in the 
overall Apache community, it has provided the momentum to change things, 
but also it has increased the speed of conversation to a pace which is 
very difficult to keep up with, hence me being p*ssed off when Stefano 
comes up with a proposal basically ignoring what I had been doing before 
this entire reorg thing - luckily we were misunderstanding each other.

When Stefano wrote up his proposal about cocoon.apache.org, I thought 
this would be the best way to go for cocoondev.org - as Ivelin also 
suggested: all of us (current cocoondev supporters) are 'valued members 
of the Cocoon community' (speaking in all modesty!!!), and us managing 
the infrastructural concern of Stefano's proposal seemed like a Good 
Thing to me: this way, other people could come and help us, other
Cocoon-friendly companies could start sponsoring the hosting costs, etc etc.

Basically it's the scale of things and passing a certain treshhold that
brings the right people together to support this wonderful community:
the GetTogether for instance is the result of Bruno & I idleing away
over lunch, thinking what we (Outerthought) could do for our first
birthday. So we just decided to move forward with the idea of hosting 
some social/informative event around Cocoon - and suddenly, we found out 
we had an outstanding list of speakers volunteering to show up, the 
number of attendees started increasing much faster than we expected, so 
we had to find some additional sponsors, etc etc: given a certain number 
of people volunteering to share (relatively small) costs, we are able to 
provide this community with the resources it needs to further accelerate 
the further growth of Cocoon.

I was hoping to group also these infrastructure resources under one 
umbrella, to make sure people interested in Cocoon could come to a 
reference place, listing and showcasing all wonderful Cocoon-things. So 
I was very happy with Ugo willing to migrate Cocoblog to cocoondev.org 
in the future, Andreas interested in migrating/merging cocooncenter.de, 
the Wiki being filled, and various people showing interest in 
cocoondev.org (thanks Matthew, David, Ovidiu to name but a few).

And I hope this will become reality for cocoondev.org: being a
community-operated infrastructure resource for the cocooon.apache.org 
community.

And doing this while 'top-leveling' Cocoon seems like the right time to me.

So this has been on my mind since the end of Summer. Hope this clears up 
things, and that we can work from here :-)

Take care,

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org

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

Re: [important proposal] Cocoon as official Apache project

Posted by David Crossley <cr...@indexgeo.com.au>.

Stefano Mazzocchi wrote:
> Steven Noels wrote:
> > Stefano Mazzocchi wrote:
> >
> >  > 3) what does it mean for Cocoon?
> >  >
> >  > Being a project allows us to host several different incubation-stage
> >  >  efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
> >  > plugins could be possible additions. Of course, with the idea of
> >  > promoting them as top-level projects when they are successful from a
> >  > community perspective.
> >  >
> >  > Also, it means that we could have our own machine running the entire
> >  >  cocoon.apache.org web site (that means: finally having Cocoon
> >  > serving its own pages!)
> >  >
> >  > Last but not least, it will give much more visibility to Cocoon since
> >  > it will be visible directly from www.apache.org
> >
> > Seems you hit the sweet spot pretty hard :-|
> >
> > OK. I won't be doing this all by myself. But I don't want to see
> > something we have been preparing for such a long time willingly 
> > ignored by this proposal.
> 
> NOTE for others: Steven called me on the phone to apologize for the tone 
> of this email. So, please, people, let's keep the tone of the 
> conversation constructive.

Steven's tone *was* constructive, the concern was correct,
and there is no need to apologise. This concern would have
been quickly addressed if we had discussed the top-level
proposal before voting.

Thanks Stefano for your comments below, which allay the fears.
--David

> I think I mixed concerns.
> 
> One concern is moving cocoon higher up in the legal structure of the ASF.
> 
> Another concern is what infrastructure will empower that.
> 
> This proposal is about the first concern. It does *NOT* nor was intended 
> to contain a proposal for the second concern that will be dealt with 
> *after* the first is solved.
> 
> So after this votation ends and all committers voted.
<snip/>



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

Re: [important proposal] Cocoon as official Apache project

Posted by Stefano Mazzocchi <st...@apache.org>.

Steven Noels wrote:

> Stefano Mazzocchi wrote:
>
>  > 3) what does it mean for Cocoon?
>  >
>  > Being a project allows us to host several different incubation-stage
>  >  efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
>  > plugins could be possible additions. Of course, with the idea of
>  > promoting them as top-level projects when they are successful from a
>  > community perspective.
>  >
>  > Also, it means that we could have our own machine running the entire
>  >  cocoon.apache.org web site (that means: finally having Cocoon
>  > serving its own pages!)
>  >
>  > Last but not least, it will give much more visibility to Cocoon since
>  > it will be visible directly from www.apache.org
>
> Seems you hit the sweet spot pretty hard :-|
>
> OK. I won't be doing this all by myself. But I don't want to see
> something we have been preparing for such a long time willingly 
> ignored by this proposal.

NOTE for others: Steven called me on the phone to apologize for the tone 
of this email. So, please, people, let's keep the tone of the 
conversation constructive.

I think I mixed concerns.

One concern is moving cocoon higher up in the legal structure of the ASF.

Another concern is what infrastructure will empower that.

This proposal is about the first concern. It does *NOT* nor was intended 
to contain a proposal for the second concern that will be dealt with 
*after* the first is solved.

So after this votation ends and all committers voted.

>
>
> So I would like to make a sub-proposal attached to this vote:
>
> The dream of cocoon.apache.org having its own hardware resources can 
> be realized by working further on the foundations of 
> http://cocoondev.org/.
> I'm ready to see the proposed cocoondev.org board being subsumed by 
> the Cocoon PMC for that matter. Also, what we have set up as 
> guidelines should be scrutinized and fleshed out further to bring in 
> line with the new PMC's ideas. The main benefit of cocoondev.org is 
> that it has been
> set up with sufficient compartimentization in mind, both on a security
> and classloading level. So all these cocoon-based apps can be developed
> and showcased independently from each other. And that the machine is
> there and available, of course.

I have absolutely no problems in considering cocoondev.org as the 
hosting space for our own infrastructure, just like the PHP people 
manage their own machines.

In fact, I think the ASF infrastructure has been a severe bottleneck for 
the growth and showoff of our own technologies (unlike on php.apache.org)

>
> I'm all +1 for cocoon.apache.org being a top-level project, of course. 
> I sent you a mail suggesting to move forward with this 5 days ago.

Great, +1 counted.

>
> But I would be very sad to see what we have been doing for 
> cocoondev.org going lost in the turmoil. Especially on my 32nd 
> birthday :-|

Happy birthday. Here is the present for you: it will not!

>
> All: if you were not aware of http://cocoondev.org/, please take a 
> look.  If you are interested and want to discuss further , please 
> subscribe yourself using supporters-subscribe@lists.cocoondev.org
>
> But hopefully, this list might soon become something like
> infrastructure@cocoon.apache.org

Wouldn't it be cool to have our own community server based on Cocoon and 
  handled by ourselves? might even be a subproject that we could host on 
cocoon.apache.org

Yeah, Steven, don't worry, your efforts will not be thrown away.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------




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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

I also support Steven's effort to unite everyone that was planning to run a
Cocoon application server.
I think that the cocoondev best practices and documentation should be
consulted for the upcoming cocoon.apache.org contracts.
It also makes most sense for the cocoondev.org people to move over to the
PMC.


Very importantly, we have to formalize the clear separation of the open
source project from any commercial interests.
I am sure Stefano, Carsten, Steven, Vadim and probably other people have
thought a lot about this and can write up a draft which we can start
discussing.
It is vital to keep Cocoon clean from influence of private interests not
driven by the project's success itself.
At the same time allowing individuals to take full material advantage of
their expert knowledge.


Ivelin


----- Original Message -----
From: "Steven Noels" <st...@outerthought.org>
To: <co...@xml.apache.org>
Cc: <su...@lists.cocoondev.org>
Sent: Wednesday, October 30, 2002 11:04 AM
Subject: Re: [important proposal] Cocoon as official Apache project


> Stefano Mazzocchi wrote:
>
>  > 3) what does it mean for Cocoon?
>  >
>  > Being a project allows us to host several different incubation-stage
>  >  efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
>  > plugins could be possible additions. Of course, with the idea of
>  > promoting them as top-level projects when they are successful from a
>  > community perspective.
>  >
>  > Also, it means that we could have our own machine running the entire
>  >  cocoon.apache.org web site (that means: finally having Cocoon
>  > serving its own pages!)
>  >
>  > Last but not least, it will give much more visibility to Cocoon since
>  > it will be visible directly from www.apache.org
>
> Seems you hit the sweet spot pretty hard :-|
>
> OK. I won't be doing this all by myself. But I don't want to see
> something we have been preparing for such a long time willingly ignored
> by this proposal.
>
> So I would like to make a sub-proposal attached to this vote:
>
> The dream of cocoon.apache.org having its own hardware resources can be
> realized by working further on the foundations of http://cocoondev.org/.
> I'm ready to see the proposed cocoondev.org board being subsumed by the
> Cocoon PMC for that matter. Also, what we have set up as guidelines
> should be scrutinized and fleshed out further to bring in line with the
> new PMC's ideas. The main benefit of cocoondev.org is that it has been
> set up with sufficient compartimentization in mind, both on a security
> and classloading level. So all these cocoon-based apps can be developed
> and showcased independently from each other. And that the machine is
> there and available, of course.
>
> I'm all +1 for cocoon.apache.org being a top-level project, of course. I
> sent you a mail suggesting to move forward with this 5 days ago.
>
> But I would be very sad to see what we have been doing for cocoondev.org
> going lost in the turmoil. Especially on my 32nd birthday :-|
>
> All: if you were not aware of http://cocoondev.org/, please take a look.
>   If you are interested and want to discuss further , please subscribe
> yourself using supporters-subscribe@lists.cocoondev.org
>
> But hopefully, this list might soon become something like
> infrastructure@cocoon.apache.org
>
> </Steven>
> --
> Steven Noels                            http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> stevenn@outerthought.org                      stevenn@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: supporters-unsubscribe@lists.cocoondev.org
> For additional commands, e-mail: supporters-help@lists.cocoondev.org
>


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

Re: [important proposal] Cocoon as official Apache project

Posted by Steven Noels <st...@outerthought.org>.

Stefano Mazzocchi wrote:

 > 3) what does it mean for Cocoon?
 >
 > Being a project allows us to host several different incubation-stage
 >  efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
 > plugins could be possible additions. Of course, with the idea of
 > promoting them as top-level projects when they are successful from a
 > community perspective.
 >
 > Also, it means that we could have our own machine running the entire
 >  cocoon.apache.org web site (that means: finally having Cocoon
 > serving its own pages!)
 >
 > Last but not least, it will give much more visibility to Cocoon since
 > it will be visible directly from www.apache.org

Seems you hit the sweet spot pretty hard :-|

OK. I won't be doing this all by myself. But I don't want to see 
something we have been preparing for such a long time willingly ignored 
by this proposal.

So I would like to make a sub-proposal attached to this vote:

The dream of cocoon.apache.org having its own hardware resources can be 
realized by working further on the foundations of http://cocoondev.org/. 
I'm ready to see the proposed cocoondev.org board being subsumed by the 
Cocoon PMC for that matter. Also, what we have set up as guidelines 
should be scrutinized and fleshed out further to bring in line with the 
new PMC's ideas. The main benefit of cocoondev.org is that it has been 
set up with sufficient compartimentization in mind, both on a security 
and classloading level. So all these cocoon-based apps can be developed 
and showcased independently from each other. And that the machine is 
there and available, of course.

I'm all +1 for cocoon.apache.org being a top-level project, of course. I 
sent you a mail suggesting to move forward with this 5 days ago.

But I would be very sad to see what we have been doing for cocoondev.org 
going lost in the turmoil. Especially on my 32nd birthday :-|

All: if you were not aware of http://cocoondev.org/, please take a look. 
  If you are interested and want to discuss further , please subscribe 
yourself using supporters-subscribe@lists.cocoondev.org

But hopefully, this list might soon become something like 
infrastructure@cocoon.apache.org

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org

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

Re: [important proposal] Cocoon as official Apache project

Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.

On 30.Oct.2002 -- 02:29 PM, Stefano Mazzocchi wrote:
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
> 
  [X] +1  I think it's a good idea
  [ ]  0  I really don't care.
  [ ] -1, I don't think it's a good idea.

Funny, I seem to remember something like "cocoon should search its own place and
may stay at apache until then". That must have been 2000 or something and it is  only
a dim memory  :-)

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

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

Re: [important proposal] Cocoon as official Apache project

Posted by Nicola Ken Barozzi <ni...@apache.org>.

> 
>>Stefano Mazzocchi wrote:
>>...
>>
>>>First thing to do is to have a formal votation. All committers should
>>>express their vote on this, right here:

  [X] +1  I think it's a good idea
  [ ]  0  I really don't care.
  [ ] -1, I don't think it's a good idea.

Finally! :-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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

Re: [important proposal] Cocoon as official Apache project

Posted by Stephan Michels <st...@apache.org>.



On Wed, 30 Oct 2002, Vadim Gritsenko wrote:

> Stefano Mazzocchi wrote:
> ...
>
> > First thing to do is to have a formal votation. All committers should
> > express their vote on this, right here:
> >
> >  [X] +1  I think it's a good idea
> >  [ ]  0  I really don't care.
> >  [ ] -1, I don't think it's a good idea.
>
>
> Let's do it.


+1, for Cocoon as official Apache project.

Stephan.


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

Re: [important proposal] Cocoon as official Apache project

Posted by Vadim Gritsenko <va...@verizon.net>.

Stefano Mazzocchi wrote:
...

> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
>
>  [X] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.


Let's do it.

Vadim


> Thanks.

Re: [important proposal] Cocoon as official Apache project

Posted by Sanjiva Weerawarana <sa...@wow.lk>.

Given the revelation of lack of legal cover for non-PMC
committers I'm all for making every codebase a separate
PMC and allowing everyone committer to be a PMCer.

So, +1.

Sanjiva.

----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Apache Cocoon" <co...@xml.apache.org>
Cc: <co...@apache.org>
Sent: Wednesday, October 30, 2002 7:29 PM
Subject: [important proposal] Cocoon as official Apache project


> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to
> ask you about something that is been in the back of my mind for more
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
>                                   - o -
>
> Before I state the proposal and its implications, allow me to introduce
> the context.
>
> Currently, Cocoon is not officially considered a 'project' under the ASF
> bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal umbrella
> (the foundation) and several focused development communities (the
projects).
>
> The original idea was, in fact, modeled after how the Apache Group
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well
> apply to projects which did not release software directly (unlike HTTPD
> did) and decided to use the same model for jakarta and xml (which don't
> release software directly, but add another level of indirection with
> subprojects).
>
> The concept and the term "subproject" was, in fact, invented to separate
> the development community from the container.
>
> Over the years, it became clear that project containment yields several
> drawbacks:
>
>   1) container PMCs don't do anything since they are too detached from
> the actual code (it's impossible they know all about all the code hosted
> by the single containers!)
>
>   2) the subproject committers never have a way to interact directly
> with the foundation, thus they perceive it as a distant and bureaucratic
> thing
>
>   3) the ASF doesn't have proper legal oversight on the code contained
> in all sub-projects
>
>   4) the trend of sub-projecting created sub-containers (avalon and
> turbine, for example), thus making all this even worse.
>
>   5) the creation of sub-brands and the confusion this created. Example:
> is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF board
> that this situation was potentially very dangerous since, in fact, the
> container projects started to behave more and more as sub-foundations,
> but without the proper legal understanding. This situation was
> potentially inflammable in the case of a legal action against a
> committer since the foundation might not have been able to properly
> legally shield that committer since it operated outside the bylaws and
> without proper PMC oversight.
>
> Over the same period, several very influential members and board
> officials were against this notion, stating that it was just a human
> problem with the people elected on the PMC and *not* a problem in the
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml
> member elected on the board (Sam Ruby), things are finally starting to
> change.
>
> The ASF board agrees on an open policy on the creation of new top-level
> Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>
> So, in the light of this, I would like to hear your comments on the idea
> of moving out of xml.apache.org into our own project.
>
>                              - o -
>
> Before you start asking a bunch of questions, let me answer a few of
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> moved into hybernation state and stored for historical reasons only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> need to change anything there. [I planned this in advance at least two
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is
> legally reponsible for the code and reports directly to the board. The
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the
> PMC composed by *all* committers that ask to be part of it. This to
> imply that committers and legal protector share the same duties and
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation will
> protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> could be possible additions. Of course, with the idea of promoting them
> as top-level projects when they are successful from a community
perspective.
>
> Also, it means that we could have our own machine running the entire
> cocoon.apache.org web site (that means: finally having Cocoon serving
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since it
> will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to
> top-level and I know the ASF board is very open to projects willing to
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other
> communities feel they should deserve top-level projects, they should
> make a proposal like this and ask the board instead of complaining with
> us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better to
> have something like 'publishing.apache.org' and host all
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the PMC
> and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not a
> container for all HTTP-related server technology, nor it would be of any
> help if it became one.
>
> I think the ASF should stop forcing project to remain in containers but
> simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and will
> host, develop and distribute cocoon and cocoon-related software. And the
> PMC will be directly supervising because it will be composed by all
> committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single
category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:
>
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you
> vote -1, please state your reasoning and propose a creative solution for
> the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>

Re: [important proposal] Cocoon as official Apache project

Posted by Torsten Curdt <tc...@dff.st>.

> >  [ ] +1  I think it's a good idea
> >  [ ]  0  I really don't care.
> >  [ ] -1, I don't think it's a good idea.

a big +1 !!
--
Torsten

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

Re: [important proposal] Cocoon as official Apache project

Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.

On Wed, Oct 30, 2002 at 02:29:12PM +0100, Stefano Mazzocchi wrote:
> 7) how do we move this further?
> 
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
> 
>  [ ] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.
> 
> Please, vote clearly so that it's easy to make good summaries. If you 
> vote -1, please state your reasoning and propose a creative solution for 
> the problems this proposal tries to address.

	+1 - I think it's a great idea :)
	
	Cheers,
	
	Marcus


-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:

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

Re: [important proposal] Cocoon as official Apache project

Posted by Gerhard Froehlich <g-...@gmx.de>.

Stefano Mazzocchi wrote:

> The proposal of making cocoon an official top-level Apache project.

+1

- Gerhard


-- 

---------------------------------
Me, Ambivalent? Well, yes and no.
---------------------------------

Blog at: http://radio.weblogs.com/0107791/


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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

>   [X] +1  I think it's a good idea

Cocoon's maturity, development community, amount of code and features has
grown big enough to ask for a top level seat.

I am also interested to participate in the PMC.

And I have a Cocoon application (named CocoonHive) which is a candidate to
be hosted on the cocoon.apache.org box along with CocoBlog, Wyona, Forrest
and friends.
It is now under webapp/samples/webserviceproxy/cocoonhive, but it will
eventually grow bigger, and the samples directory may not be the most
appropriate.


Regards,

Ivelin



----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Apache Cocoon" <co...@xml.apache.org>
Cc: <co...@apache.org>
Sent: Wednesday, October 30, 2002 7:29 AM
Subject: [important proposal] Cocoon as official Apache project


> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to
> ask you about something that is been in the back of my mind for more
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
>                                   - o -
>
> Before I state the proposal and its implications, allow me to introduce
> the context.
>
> Currently, Cocoon is not officially considered a 'project' under the ASF
> bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal umbrella
> (the foundation) and several focused development communities (the
projects).
>
> The original idea was, in fact, modeled after how the Apache Group
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well
> apply to projects which did not release software directly (unlike HTTPD
> did) and decided to use the same model for jakarta and xml (which don't
> release software directly, but add another level of indirection with
> subprojects).
>
> The concept and the term "subproject" was, in fact, invented to separate
> the development community from the container.
>
> Over the years, it became clear that project containment yields several
> drawbacks:
>
>   1) container PMCs don't do anything since they are too detached from
> the actual code (it's impossible they know all about all the code hosted
> by the single containers!)
>
>   2) the subproject committers never have a way to interact directly
> with the foundation, thus they perceive it as a distant and bureaucratic
> thing
>
>   3) the ASF doesn't have proper legal oversight on the code contained
> in all sub-projects
>
>   4) the trend of sub-projecting created sub-containers (avalon and
> turbine, for example), thus making all this even worse.
>
>   5) the creation of sub-brands and the confusion this created. Example:
> is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF board
> that this situation was potentially very dangerous since, in fact, the
> container projects started to behave more and more as sub-foundations,
> but without the proper legal understanding. This situation was
> potentially inflammable in the case of a legal action against a
> committer since the foundation might not have been able to properly
> legally shield that committer since it operated outside the bylaws and
> without proper PMC oversight.
>
> Over the same period, several very influential members and board
> officials were against this notion, stating that it was just a human
> problem with the people elected on the PMC and *not* a problem in the
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml
> member elected on the board (Sam Ruby), things are finally starting to
> change.
>
> The ASF board agrees on an open policy on the creation of new top-level
> Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>
> So, in the light of this, I would like to hear your comments on the idea
> of moving out of xml.apache.org into our own project.
>
>                              - o -
>
> Before you start asking a bunch of questions, let me answer a few of
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> moved into hybernation state and stored for historical reasons only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> need to change anything there. [I planned this in advance at least two
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is
> legally reponsible for the code and reports directly to the board. The
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the
> PMC composed by *all* committers that ask to be part of it. This to
> imply that committers and legal protector share the same duties and
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation will
> protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> could be possible additions. Of course, with the idea of promoting them
> as top-level projects when they are successful from a community
perspective.
>
> Also, it means that we could have our own machine running the entire
> cocoon.apache.org web site (that means: finally having Cocoon serving
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since it
> will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to
> top-level and I know the ASF board is very open to projects willing to
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other
> communities feel they should deserve top-level projects, they should
> make a proposal like this and ask the board instead of complaining with
> us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better to
> have something like 'publishing.apache.org' and host all
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the PMC
> and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not a
> container for all HTTP-related server technology, nor it would be of any
> help if it became one.
>
> I think the ASF should stop forcing project to remain in containers but
> simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and will
> host, develop and distribute cocoon and cocoon-related software. And the
> PMC will be directly supervising because it will be composed by all
> committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single
category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:
>
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you
> vote -1, please state your reasoning and propose a creative solution for
> the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


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

Re: [important proposal] Cocoon as official Apache project

Posted by Joe Schaefer <jo...@sunstarsys.com>.

[Not Cc'd to Apache Cocoon <co...@xml.apache.org>]

Stefano Mazzocchi <st...@apache.org> writes:

[...]

> Also, note that community@ is *NOT* asked to vote but only Cocoon 
> committes. I copied community@ to let people know the process is 
> underway and I wanted to do it in a very open way.

Whew- That's a relief!  I didn't catch the CC: to cocoon-dev in your
original post.

[...]

> >
> > How many cocoon committers are there right now?
> >
> As you can see from http://xml.apache.org/cocoon/who.html there are:
> 
>   19 active committers
>    5 inactive committers
>   14 emeritus committers
> 
> see the page for a definition of their status and their names.

Thanks for the link.  Prior to posting, I did try looking for this 
info myself on the xml.apache.org site.  There seems to be a link 
loop though:

  http://xml.apache.org/whoweare.html 
                                     -> /roles.html 
                                            -> /whoweare.html ...

I got frustrated after a few cycles, so I figured it's just easier
to ask :-)

[...]

> Hope this helps.

It did. Thanks again.

-- 
Joe Schaefer

Re: [important proposal] Cocoon as official Apache project

Posted by Gary Benson <gb...@redhat.com>.

On Friday, Nov 1, 2002, at 00:47 Europe/London, Stefano Mazzocchi wrote:

>NOTE: so far, the counts is 16 positive votes (including mine) and not 
>all committers have voted.
>

+1

Re: [important proposal] Cocoon as official Apache project

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Friday, Nov 1, 2002, at 00:47 Europe/London, Stefano Mazzocchi wrote:

> NOTE: so far, the counts is 16 positive votes (including mine) and not 
> all committers have voted.
>

Sorry!

+1, the time has come!

regards Jeremy


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

Re: [important proposal] Cocoon as official Apache project

Posted by Jeremy Quinn <je...@media.demon.co.uk>.

On Friday, Nov 1, 2002, at 00:47 Europe/London, Stefano Mazzocchi wrote:

> NOTE: so far, the counts is 16 positive votes (including mine) and not 
> all committers have voted.
>

Sorry!

+1, the time has come!

regards Jeremy

Re: [important proposal] Cocoon as official Apache project

Posted by Stefano Mazzocchi <st...@apache.org>.

Joe Schaefer wrote:

> Stefano Mazzocchi  writes:
>
> [ I want to preface my comments by first thanking you for community@.

You are welcome.

>   Secondly, at the moment I'm inclined to affirm your proposal, but I
>   need to develop some guiding criterion on which to base a vote.  I
>   don't want to be in a position where I feel obligated vote "+1" on
>   every similar request, especially when I have no feeling for how many
>   of them are coming :-) ]

Great. Thanks much for asking these specific questions, I think they 
might help much other people in the future.

Also, note that community@ is *NOT* asked to vote but only Cocoon 
committes. I copied community@ to let people know the process is 
underway and I wanted to do it in a very open way.

NOTE: so far, the counts is 16 positive votes (including mine) and not 
all committers have voted.

> >Unfortunately, the ASF members thought that the same model could well
> >apply to projects which did not release software directly (unlike HTTPD
> >did) and decided to use the same model for jakarta and xml (which don't
> >release software directly, but add another level of indirection with
> >subprojects).
>
>
> Can you describe the current release process for cocoon,
> emphasizing the problems with the current system?  Is there
> a public document that chronicles the issues?
>
Maybe you got me wrong: there is no problem with the actual release of 
the software.

The problem I have is that a container PMC is 'by design' composed by a 
selected number of committers while a software-driven PMC can be 
composed only by people that care about the software and know how to 
take action.

I think the second model is more effective than the first in any 
possible situation where legal issues emerge. And this is why I want 
Cocoon to have its own PMC: less indirection, more effectivness and 
better legal protection.

> >In order to avoid stupid PMC elections, I'll be in favor of having the
> >PMC composed by *all* committers that ask to be part of it. This to
> >imply that committers and legal protector share the same duties and
> >priviledges.
>
>
> How many cocoon committers are there right now?
>
As you can see from http://xml.apache.org/cocoon/who.html there are:

  19 active committers
   5 inactive committers
  14 emeritus committers

see the page for a definition of their status and their names.

If the PMC was created today, I would like it to be composed of those 19 
active committers.

> >3) what does it mean for Cocoon?
> >
> >Being a project allows us to host several different incubation-stage
> >efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
> >plugins could be possible additions. Of course, with the idea of
> >promoting them as top-level projects when they are successful from a
> >community perspective.
>
>
> How will the cocoon PMC be better positioned to address the needs
> of such "subprojects" than the current jakarta/xml PMC?

In one word: focus. A PMC managing a project with a wide scope and 
hundreds of committers looses direct connection with the software being 
developped.

This has seveal big issues:

  - less legal protection (the PMC has a hard time to know what everyone 
is doing)

  - less communication (sub-projects tend to isolate from one another)

  - less foundation visibility (sub-projects tend to see the project as 
a sub-foundation, thus ignoring the foundation and reducing "vertical" 
communication between all layers of the foundation)

> How do you foresee cocoon's PMC addressing the current troubles with 
> subproject releases?

Like I said, there are no 'release problems', but the question is still 
valid if rephrased.

If a Cocoon PMC starts to become more and more a container, it will 
slowly start to behave like a sub-foundation (or to be perceived as 
such) and will then loose focus.

I honestly have no idea on how to handle this, but the intention is 
*NOT* to start having tons of new subprojects, but to go on with it 
*very easily* exactly to avoid this containment effect. At the end, 
Darwin will tell us what to do. As usual.

> >5) isn't this unfair against the other sub-projects that remain
> >contained, therefore with less visibility?
> >
> >I don't know. Here I'm just stating the intention to move Cocoon to
> >top-level and I know the ASF board is very open to projects willing to
> >move out of their containers.
> >
> >But the ASF will *NOT* force projects to take this action. If other
> >communities feel they should deserve top-level projects, they should
> >make a proposal like this and ask the board instead of complaining
> >with us that we do it.
>
>
> Among jakarta/xml projects, how widespread is the desire to abandon
> the container PMC?

Honestly, I have no idea. But I'm sure we'll find out really soon :)

Anyway, keep in mind that community@ is *not* directly involved in the 
process from a legal point of view. In fact, it's the ASF board that 
decides after the development community explicitly asks so (and that's 
why I started the vote on cocoon-dev@, our intention is to have the 
board pronounce at the next board meeting at the apachecon)

> Have there been other reorganization attempts in the past?

No, this is the first time.

Hope this helps.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------

Re: [important proposal] Cocoon as official Apache project

Posted by Stefano Mazzocchi <st...@apache.org>.

Joe Schaefer wrote:

> Stefano Mazzocchi  writes:
>
> [ I want to preface my comments by first thanking you for community@.

You are welcome.

>   Secondly, at the moment I'm inclined to affirm your proposal, but I
>   need to develop some guiding criterion on which to base a vote.  I
>   don't want to be in a position where I feel obligated vote "+1" on
>   every similar request, especially when I have no feeling for how many
>   of them are coming :-) ]

Great. Thanks much for asking these specific questions, I think they 
might help much other people in the future.

Also, note that community@ is *NOT* asked to vote but only Cocoon 
committes. I copied community@ to let people know the process is 
underway and I wanted to do it in a very open way.

NOTE: so far, the counts is 16 positive votes (including mine) and not 
all committers have voted.

> >Unfortunately, the ASF members thought that the same model could well
> >apply to projects which did not release software directly (unlike HTTPD
> >did) and decided to use the same model for jakarta and xml (which don't
> >release software directly, but add another level of indirection with
> >subprojects).
>
>
> Can you describe the current release process for cocoon,
> emphasizing the problems with the current system?  Is there
> a public document that chronicles the issues?
>
Maybe you got me wrong: there is no problem with the actual release of 
the software.

The problem I have is that a container PMC is 'by design' composed by a 
selected number of committers while a software-driven PMC can be 
composed only by people that care about the software and know how to 
take action.

I think the second model is more effective than the first in any 
possible situation where legal issues emerge. And this is why I want 
Cocoon to have its own PMC: less indirection, more effectivness and 
better legal protection.

> >In order to avoid stupid PMC elections, I'll be in favor of having the
> >PMC composed by *all* committers that ask to be part of it. This to
> >imply that committers and legal protector share the same duties and
> >priviledges.
>
>
> How many cocoon committers are there right now?
>
As you can see from http://xml.apache.org/cocoon/who.html there are:

  19 active committers
   5 inactive committers
  14 emeritus committers

see the page for a definition of their status and their names.

If the PMC was created today, I would like it to be composed of those 19 
active committers.

> >3) what does it mean for Cocoon?
> >
> >Being a project allows us to host several different incubation-stage
> >efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
> >plugins could be possible additions. Of course, with the idea of
> >promoting them as top-level projects when they are successful from a
> >community perspective.
>
>
> How will the cocoon PMC be better positioned to address the needs
> of such "subprojects" than the current jakarta/xml PMC?

In one word: focus. A PMC managing a project with a wide scope and 
hundreds of committers looses direct connection with the software being 
developped.

This has seveal big issues:

  - less legal protection (the PMC has a hard time to know what everyone 
is doing)

  - less communication (sub-projects tend to isolate from one another)

  - less foundation visibility (sub-projects tend to see the project as 
a sub-foundation, thus ignoring the foundation and reducing "vertical" 
communication between all layers of the foundation)

> How do you foresee cocoon's PMC addressing the current troubles with 
> subproject releases?

Like I said, there are no 'release problems', but the question is still 
valid if rephrased.

If a Cocoon PMC starts to become more and more a container, it will 
slowly start to behave like a sub-foundation (or to be perceived as 
such) and will then loose focus.

I honestly have no idea on how to handle this, but the intention is 
*NOT* to start having tons of new subprojects, but to go on with it 
*very easily* exactly to avoid this containment effect. At the end, 
Darwin will tell us what to do. As usual.

> >5) isn't this unfair against the other sub-projects that remain
> >contained, therefore with less visibility?
> >
> >I don't know. Here I'm just stating the intention to move Cocoon to
> >top-level and I know the ASF board is very open to projects willing to
> >move out of their containers.
> >
> >But the ASF will *NOT* force projects to take this action. If other
> >communities feel they should deserve top-level projects, they should
> >make a proposal like this and ask the board instead of complaining
> >with us that we do it.
>
>
> Among jakarta/xml projects, how widespread is the desire to abandon
> the container PMC?

Honestly, I have no idea. But I'm sure we'll find out really soon :)

Anyway, keep in mind that community@ is *not* directly involved in the 
process from a legal point of view. In fact, it's the ASF board that 
decides after the development community explicitly asks so (and that's 
why I started the vote on cocoon-dev@, our intention is to have the 
board pronounce at the next board meeting at the apachecon)

> Have there been other reorganization attempts in the past?

No, this is the first time.

Hope this helps.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------

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

Re: [important proposal] Cocoon as official Apache project

Posted by Joe Schaefer <jo...@sunstarsys.com>.

Stefano Mazzocchi <st...@apache.org> writes:

[ I want to preface my comments by first thanking you for community@.
  Secondly, at the moment I'm inclined to affirm your proposal, but I 
  need to develop some guiding criterion on which to base a vote.  I 
  don't want to be in a position where I feel obligated vote "+1" on
  every similar request, especially when I have no feeling for how many 
  of them are coming :-) ]

[...]

> Unfortunately, the ASF members thought that the same model could well 
> apply to projects which did not release software directly (unlike HTTPD 
> did) and decided to use the same model for jakarta and xml (which don't 
> release software directly, but add another level of indirection with 
> subprojects).

Can you describe the current release process for cocoon, 
emphasizing the problems with the current system?  Is there
a public document that chronicles the issues?

[...]

> In order to avoid stupid PMC elections, I'll be in favor of having the 
> PMC composed by *all* committers that ask to be part of it. This to 
> imply that committers and legal protector share the same duties and 
> priviledges.

How many cocoon committers are there right now?

[...]

> 3) what does it mean for Cocoon?
> 
> Being a project allows us to host several different incubation-stage 
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE
> plugins could be possible additions. Of course, with the idea of
> promoting them as top-level projects when they are successful from a
> community perspective. 

How will the cocoon PMC be better positioned to address the needs 
of such "subprojects" than the current jakarta/xml PMC?  How do
you foresee cocoon's PMC addressing the current troubles with subproject 
releases?

[...]

> 5) isn't this unfair against the other sub-projects that remain 
> contained, therefore with less visibility?
> 
> I don't know. Here I'm just stating the intention to move Cocoon to 
> top-level and I know the ASF board is very open to projects willing to 
> move out of their containers.
> 
> But the ASF will *NOT* force projects to take this action. If other 
> communities feel they should deserve top-level projects, they should 
> make a proposal like this and ask the board instead of complaining
> with us that we do it.

Among jakarta/xml projects, how widespread is the desire to abandon
the container PMC?  Have there been other reorganization attempts
in the past?

-- 
Joe Schaefer

Re: [important proposal] Cocoon as official Apache project

Posted by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com>.

+1 :-D

Antonio Gallardo

El Miércoles, 30 de Octubre de 2002 07:29, Stefano Mazzocchi escribió:
> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to
> ask you about something that is been in the back of my mind for more
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
>                                   - o -
>
> Before I state the proposal and its implications, allow me to introduce
> the context.
>
> Currently, Cocoon is not officially considered a 'project' under the ASF
> bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal umbrella
> (the foundation) and several focused development communities (the
> projects).
>
> The original idea was, in fact, modeled after how the Apache Group
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well
> apply to projects which did not release software directly (unlike HTTPD
> did) and decided to use the same model for jakarta and xml (which don't
> release software directly, but add another level of indirection with
> subprojects).
>
> The concept and the term "subproject" was, in fact, invented to separate
> the development community from the container.
>
> Over the years, it became clear that project containment yields several
> drawbacks:
>
>   1) container PMCs don't do anything since they are too detached from
> the actual code (it's impossible they know all about all the code hosted
> by the single containers!)
>
>   2) the subproject committers never have a way to interact directly
> with the foundation, thus they perceive it as a distant and bureaucratic
> thing
>
>   3) the ASF doesn't have proper legal oversight on the code contained
> in all sub-projects
>
>   4) the trend of sub-projecting created sub-containers (avalon and
> turbine, for example), thus making all this even worse.
>
>   5) the creation of sub-brands and the confusion this created. Example:
> is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF board
> that this situation was potentially very dangerous since, in fact, the
> container projects started to behave more and more as sub-foundations,
> but without the proper legal understanding. This situation was
> potentially inflammable in the case of a legal action against a
> committer since the foundation might not have been able to properly
> legally shield that committer since it operated outside the bylaws and
> without proper PMC oversight.
>
> Over the same period, several very influential members and board
> officials were against this notion, stating that it was just a human
> problem with the people elected on the PMC and *not* a problem in the
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml
> member elected on the board (Sam Ruby), things are finally starting to
> change.
>
> The ASF board agrees on an open policy on the creation of new top-level
> Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>
> So, in the light of this, I would like to hear your comments on the idea
> of moving out of xml.apache.org into our own project.
>
>                              - o -
>
> Before you start asking a bunch of questions, let me answer a few of
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> moved into hybernation state and stored for historical reasons only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> need to change anything there. [I planned this in advance at least two
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is
> legally reponsible for the code and reports directly to the board. The
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the
> PMC composed by *all* committers that ask to be part of it. This to
> imply that committers and legal protector share the same duties and
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation will
> protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> could be possible additions. Of course, with the idea of promoting them
> as top-level projects when they are successful from a community
> perspective.
>
> Also, it means that we could have our own machine running the entire
> cocoon.apache.org web site (that means: finally having Cocoon serving
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since it
> will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to
> top-level and I know the ASF board is very open to projects willing to
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other
> communities feel they should deserve top-level projects, they should
> make a proposal like this and ask the board instead of complaining with
> us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better to
> have something like 'publishing.apache.org' and host all
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the PMC
> and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not a
> container for all HTTP-related server technology, nor it would be of any
> help if it became one.
>
> I think the ASF should stop forcing project to remain in containers but
> simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and will
> host, develop and distribute cocoon and cocoon-related software. And the
> PMC will be directly supervising because it will be composed by all
> committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:
>
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you
> vote -1, please state your reasoning and propose a creative solution for
> the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.

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

Re: [important proposal] Cocoon as official Apache project

Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.

On Wed, Oct 30, 2002 at 02:29:12PM +0100, Stefano Mazzocchi wrote:
> 7) how do we move this further?
> 
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
> 
>  [ ] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.
> 
> Please, vote clearly so that it's easy to make good summaries. If you 
> vote -1, please state your reasoning and propose a creative solution for 
> the problems this proposal tries to address.

	+1 - I think it's a great idea :)
	
	Cheers,
	
	Marcus


-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:

Re: [important proposal] Cocoon as official Apache project

Posted by Sylvain Wallez <sy...@anyware-tech.com>.

Stefano Mazzocchi wrote:

> So, in the light of this, I would like to hear your comments on the 
> idea of moving out of xml.apache.org into our own project.


>  [X] +1  I think it's a *very* good idea and will allow Cocoon to have 
> the visibility it deserves.


I'm currently not very active because we are facing a flood of projects, 
and I can tell you that Cocoon is slowly but strongly spreading the 
world (at least my part of if).

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



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

Re: [important proposal] Cocoon as official Apache project

Posted by David Crossley <cr...@indexgeo.com.au>.

Stefano Mazzocchi wrote:
> Ladies and gentlemen,
> 
> it is with *great* pleasure that I'm finally feel confident enough to 
> ask you about something that is been in the back of my mind for more 
> than a year now.
> 
> The proposal of making cocoon an official top-level Apache project.
> 
<snip proposal/>

> 7) how do we move this further?
> 
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
> 
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.
> 
> Please, vote clearly so that it's easy to make good summaries. If you 
> vote -1, please state your reasoning and propose a creative solution for 
> the problems this proposal tries to address.
> 
> After the votation we'll see what to do.

I would have thought that the answer to 7)
is to discuss the proposal a bit, then vote.

Anyway now that you have, here is my vote:
[X] +1  I think it's a good idea

--David





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

Re: [important proposal] Cocoon as official Apache project

Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.

On Wednesday 30 October 2002 14:29, Stefano Mazzocchi wrote:
>. . .that means: finally having Cocoon serving
> its own pages!)

yoo-hooh!

> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:

[X ] +1  I think it's a good idea

-Bertrand

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

Re: [important proposal] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

>   [X] +1  I think it's a good idea

Cocoon's maturity, development community, amount of code and features has
grown big enough to ask for a top level seat.

I am also interested to participate in the PMC.

And I have a Cocoon application (named CocoonHive) which is a candidate to
be hosted on the cocoon.apache.org box along with CocoBlog, Wyona, Forrest
and friends.
It is now under webapp/samples/webserviceproxy/cocoonhive, but it will
eventually grow bigger, and the samples directory may not be the most
appropriate.


Regards,

Ivelin



----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Apache Cocoon" <co...@xml.apache.org>
Cc: <co...@apache.org>
Sent: Wednesday, October 30, 2002 7:29 AM
Subject: [important proposal] Cocoon as official Apache project


> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to
> ask you about something that is been in the back of my mind for more
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
>                                   - o -
>
> Before I state the proposal and its implications, allow me to introduce
> the context.
>
> Currently, Cocoon is not officially considered a 'project' under the ASF
> bylaws. Cocoon is, in fact, part of the Apache XML Project just like
> Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal umbrella
> (the foundation) and several focused development communities (the
projects).
>
> The original idea was, in fact, modeled after how the Apache Group
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well
> apply to projects which did not release software directly (unlike HTTPD
> did) and decided to use the same model for jakarta and xml (which don't
> release software directly, but add another level of indirection with
> subprojects).
>
> The concept and the term "subproject" was, in fact, invented to separate
> the development community from the container.
>
> Over the years, it became clear that project containment yields several
> drawbacks:
>
>   1) container PMCs don't do anything since they are too detached from
> the actual code (it's impossible they know all about all the code hosted
> by the single containers!)
>
>   2) the subproject committers never have a way to interact directly
> with the foundation, thus they perceive it as a distant and bureaucratic
> thing
>
>   3) the ASF doesn't have proper legal oversight on the code contained
> in all sub-projects
>
>   4) the trend of sub-projecting created sub-containers (avalon and
> turbine, for example), thus making all this even worse.
>
>   5) the creation of sub-brands and the confusion this created. Example:
> is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF board
> that this situation was potentially very dangerous since, in fact, the
> container projects started to behave more and more as sub-foundations,
> but without the proper legal understanding. This situation was
> potentially inflammable in the case of a legal action against a
> committer since the foundation might not have been able to properly
> legally shield that committer since it operated outside the bylaws and
> without proper PMC oversight.
>
> Over the same period, several very influential members and board
> officials were against this notion, stating that it was just a human
> problem with the people elected on the PMC and *not* a problem in the
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml
> member elected on the board (Sam Ruby), things are finally starting to
> change.
>
> The ASF board agrees on an open policy on the creation of new top-level
> Apache projects in the spirit of HTTPD: that is 'one PMC one codebase'.
>
> So, in the light of this, I would like to hear your comments on the idea
> of moving out of xml.apache.org into our own project.
>
>                              - o -
>
> Before you start asking a bunch of questions, let me answer a few of
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 module
> moved into hybernation state and stored for historical reasons only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no
> need to change anything there. [I planned this in advance at least two
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is
> legally reponsible for the code and reports directly to the board. The
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the
> PMC composed by *all* committers that ask to be part of it. This to
> imply that committers and legal protector share the same duties and
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation will
> protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins
> could be possible additions. Of course, with the idea of promoting them
> as top-level projects when they are successful from a community
perspective.
>
> Also, it means that we could have our own machine running the entire
> cocoon.apache.org web site (that means: finally having Cocoon serving
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since it
> will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to
> top-level and I know the ASF board is very open to projects willing to
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other
> communities feel they should deserve top-level projects, they should
> make a proposal like this and ask the board instead of complaining with
> us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better to
> have something like 'publishing.apache.org' and host all
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the PMC
> and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not a
> container for all HTTP-related server technology, nor it would be of any
> help if it became one.
>
> I think the ASF should stop forcing project to remain in containers but
> simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and will
> host, develop and distribute cocoon and cocoon-related software. And the
> PMC will be directly supervising because it will be composed by all
> committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single
category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should
> express their vote on this, right here:
>
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you
> vote -1, please state your reasoning and propose a creative solution for
> the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> --
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>

Re: [important proposal] Cocoon as official Apache project

Posted by Vadim Gritsenko <va...@verizon.net>.

Stefano Mazzocchi wrote:
...

> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
>
>  [X] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.


Let's do it.

Vadim


> Thanks.





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

Re: [important proposal] Cocoon as official Apache project

Posted by Ovidiu Predescu <ov...@apache.org>.

This is a bold step for Cocoon! Here's my enthusiastic +1 for this 
proposal!

My only concern is that Cocoon will have a lot more pressure on it when 
this happens, but in the long run this pressure should help us polarize 
in the right direction.

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/

On Wednesday, Oct 30, 2002, at 05:29 US/Pacific, Stefano Mazzocchi 
wrote:

> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to 
> ask you about something that is been in the back of my mind for more 
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
>                                  - o -
>
> Before I state the proposal and its implications, allow me to 
> introduce the context.
>
> Currently, Cocoon is not officially considered a 'project' under the 
> ASF bylaws. Cocoon is, in fact, part of the Apache XML Project just 
> like Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal 
> umbrella (the foundation) and several focused development communities 
> (the projects).
>
> The original idea was, in fact, modeled after how the Apache Group 
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well 
> apply to projects which did not release software directly (unlike 
> HTTPD did) and decided to use the same model for jakarta and xml 
> (which don't release software directly, but add another level of 
> indirection with subprojects).
>
> The concept and the term "subproject" was, in fact, invented to 
> separate the development community from the container.
>
> Over the years, it became clear that project containment yields 
> several drawbacks:
>
>  1) container PMCs don't do anything since they are too detached from 
> the actual code (it's impossible they know all about all the code 
> hosted by the single containers!)
>
>  2) the subproject committers never have a way to interact directly 
> with the foundation, thus they perceive it as a distant and 
> bureaucratic thing
>
>  3) the ASF doesn't have proper legal oversight on the code contained 
> in all sub-projects
>
>  4) the trend of sub-projecting created sub-containers (avalon and 
> turbine, for example), thus making all this even worse.
>
>  5) the creation of sub-brands and the confusion this created. 
> Example: is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta > Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF 
> board that this situation was potentially very dangerous since, in 
> fact, the container projects started to behave more and more as 
> sub-foundations, but without the proper legal understanding. This 
> situation was potentially inflammable in the case of a legal action 
> against a committer since the foundation might not have been able to 
> properly legally shield that committer since it operated outside the 
> bylaws and without proper PMC oversight.
>
> Over the same period, several very influential members and board 
> officials were against this notion, stating that it was just a human 
> problem with the people elected on the PMC and *not* a problem in the 
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml 
> member elected on the board (Sam Ruby), things are finally starting to 
> change.
>
> The ASF board agrees on an open policy on the creation of new 
> top-level Apache projects in the spirit of HTTPD: that is 'one PMC one 
> codebase'.
>
> So, in the light of this, I would like to hear your comments on the 
> idea of moving out of xml.apache.org into our own project.
>
>                             - o -
>
> Before you start asking a bunch of questions, let me answer a few of 
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all 
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org 
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to 
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 
> module moved into hybernation state and stored for historical reasons 
> only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no 
> need to change anything there. [I planned this in advance at least two 
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is 
> legally reponsible for the code and reports directly to the board. The 
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the 
> PMC composed by *all* committers that ask to be part of it. This to 
> imply that committers and legal protector share the same duties and 
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation 
> will protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage 
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE 
> plugins could be possible additions. Of course, with the idea of 
> promoting them as top-level projects when they are successful from a 
> community perspective.
>
> Also, it means that we could have our own machine running the entire 
> cocoon.apache.org web site (that means: finally having Cocoon serving 
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since 
> it will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only 
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain 
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to 
> top-level and I know the ASF board is very open to projects willing to 
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other 
> communities feel they should deserve top-level projects, they should 
> make a proposal like this and ask the board instead of complaining 
> with us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better 
> to have something like 'publishing.apache.org' and host all 
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the 
> PMC and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not 
> a container for all HTTP-related server technology, nor it would be of 
> any help if it became one.
>
> I think the ASF should stop forcing project to remain in containers 
> but simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and 
> will host, develop and distribute cocoon and cocoon-related software. 
> And the PMC will be directly supervising because it will be composed 
> by all committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single 
> category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
>
>  [ ] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you 
> vote -1, please state your reasoning and propose a creative solution 
> for the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> -- 
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------


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

Re: [important proposal] Cocoon as official Apache project

Posted by Ovidiu Predescu <ov...@apache.org>.

This is a bold step for Cocoon! Here's my enthusiastic +1 for this 
proposal!

My only concern is that Cocoon will have a lot more pressure on it when 
this happens, but in the long run this pressure should help us polarize 
in the right direction.

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://webweavertech.com/ovidiu/weblog/

On Wednesday, Oct 30, 2002, at 05:29 US/Pacific, Stefano Mazzocchi 
wrote:

> Ladies and gentlemen,
>
> it is with *great* pleasure that I'm finally feel confident enough to 
> ask you about something that is been in the back of my mind for more 
> than a year now.
>
> The proposal of making cocoon an official top-level Apache project.
>
>                                  - o -
>
> Before I state the proposal and its implications, allow me to 
> introduce the context.
>
> Currently, Cocoon is not officially considered a 'project' under the 
> ASF bylaws. Cocoon is, in fact, part of the Apache XML Project just 
> like Xalan Xerces Fop Batik and the others.
>
> The ASF was designed round the concept of having one big legal 
> umbrella (the foundation) and several focused development communities 
> (the projects).
>
> The original idea was, in fact, modeled after how the Apache Group 
> managed the Apache HTTPD project.
>
> Unfortunately, the ASF members thought that the same model could well 
> apply to projects which did not release software directly (unlike 
> HTTPD did) and decided to use the same model for jakarta and xml 
> (which don't release software directly, but add another level of 
> indirection with subprojects).
>
> The concept and the term "subproject" was, in fact, invented to 
> separate the development community from the container.
>
> Over the years, it became clear that project containment yields 
> several drawbacks:
>
>  1) container PMCs don't do anything since they are too detached from 
> the actual code (it's impossible they know all about all the code 
> hosted by the single containers!)
>
>  2) the subproject committers never have a way to interact directly 
> with the foundation, thus they perceive it as a distant and 
> bureaucratic thing
>
>  3) the ASF doesn't have proper legal oversight on the code contained 
> in all sub-projects
>
>  4) the trend of sub-projecting created sub-containers (avalon and 
> turbine, for example), thus making all this even worse.
>
>  5) the creation of sub-brands and the confusion this created. 
> Example: is Apache Tomcat? or Jakarta Tomcat? or Apache Jakarta > Tomcat?
>
> Over the last 18 months, several members tried to convince the ASF 
> board that this situation was potentially very dangerous since, in 
> fact, the container projects started to behave more and more as 
> sub-foundations, but without the proper legal understanding. This 
> situation was potentially inflammable in the case of a legal action 
> against a committer since the foundation might not have been able to 
> properly legally shield that committer since it operated outside the 
> bylaws and without proper PMC oversight.
>
> Over the same period, several very influential members and board 
> officials were against this notion, stating that it was just a human 
> problem with the people elected on the PMC and *not* a problem in the 
> design of the foundation.
>
> After a few new PMC elections, and after finally having a jakarta/xml 
> member elected on the board (Sam Ruby), things are finally starting to 
> change.
>
> The ASF board agrees on an open policy on the creation of new 
> top-level Apache projects in the spirit of HTTPD: that is 'one PMC one 
> codebase'.
>
> So, in the light of this, I would like to hear your comments on the 
> idea of moving out of xml.apache.org into our own project.
>
>                             - o -
>
> Before you start asking a bunch of questions, let me answer a few of 
> them that I might consider FAQs.
>
> 1) what are the contract changes that the proposal implies? [note, all 
> these are not carved in stone, but just here to give you an idea]
>
> Cocoon will be moved on cocoon.apache.org, all pages on xml.apache.org 
> redirected.
>
> The cocoon-*@xml.apache.org mail lists will be moved to 
> {1}@cocoon.apache.org.
>
> The xml-cocoon2 module will be renamed 'cocoon'. The xml-cocoon1 
> module moved into hybernation state and stored for historical reasons 
> only.
>
> NOTE: cocoon namespaces all start with http://apache.org/cocoon/ so no 
> need to change anything there. [I planned this in advance at least two 
> years ago, so that's why the namespace was already clean]
>
> 2) what does it mean for the developers?
>
> An official Cocoon project will have an official PMC which is what is 
> legally reponsible for the code and reports directly to the board. The 
> PMC officer becomes a vice-president of the ASF.
>
> In order to avoid stupid PMC elections, I'll be in favor of having the 
> PMC composed by *all* committers that ask to be part of it. This to 
> imply that committers and legal protector share the same duties and 
> priviledges.
>
> In short, it means that if any of us screws legally, the foundation 
> will protect us. Today, this is not the case.
>
> 3) what does it mean for Cocoon?
>
> Being a project allows us to host several different incubation-stage 
> efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE 
> plugins could be possible additions. Of course, with the idea of 
> promoting them as top-level projects when they are successful from a 
> community perspective.
>
> Also, it means that we could have our own machine running the entire 
> cocoon.apache.org web site (that means: finally having Cocoon serving 
> its own pages!)
>
> Last but not least, it will give much more visibility to Cocoon since 
> it will be visible directly from www.apache.org
>
> 4) what are the drawbacks?
>
> moving stuff around is always annoying, but I think this is the only 
> major drawback.
>
> 5) isn't this unfair against the other sub-projects that remain 
> contained, therefore with less visibility?
>
> I don't know. Here I'm just stating the intention to move Cocoon to 
> top-level and I know the ASF board is very open to projects willing to 
> move out of their containers.
>
> But the ASF will *NOT* force projects to take this action. If other 
> communities feel they should deserve top-level projects, they should 
> make a proposal like this and ask the board instead of complaining 
> with us that we do it.
>
> 6) isn't a cocoon-related project too specific? wouldn't it be better 
> to have something like 'publishing.apache.org' and host all 
> publishing-related stuff there?
>
> No, it would be a smaller container, but still a container where the 
> PMC and the committers are not the same entity.
>
> HTTPD is a project about a modular HTTP server written in C, it's not 
> a container for all HTTP-related server technology, nor it would be of 
> any help if it became one.
>
> I think the ASF should stop forcing project to remain in containers 
> but simply allow them to choose to step up.
>
> Cocoon.apache.org will be the community of people around Cocoon and 
> will host, develop and distribute cocoon and cocoon-related software. 
> And the PMC will be directly supervising because it will be composed 
> by all committers of all cvs modules it will host.
>
> Also, stuff like Cocoon is very hard to make it fit into a single 
> category.
>
>
> 7) how do we move this further?
>
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
>
>  [ ] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.
>
> Please, vote clearly so that it's easy to make good summaries. If you 
> vote -1, please state your reasoning and propose a creative solution 
> for the problems this proposal tries to address.
>
> After the votation we'll see what to do.
>
> Thanks.
>
> -- 
> Stefano Mazzocchi                               <st...@apache.org>
> --------------------------------------------------------------------

Re: [important proposal] Cocoon as official Apache project

Posted by Diana Shannon <sh...@apache.org>.

On Wednesday, October 30, 2002, at 08:29  AM, Stefano Mazzocchi wrote:

+1 Hooray!

Diana


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

Re: [important proposal] Cocoon as official Apache project

Posted by Peter Royal <pr...@apache.org>.

On Wednesday, October 30, 2002, at 08:29  AM, Stefano Mazzocchi wrote:
>  [X] +1  I think it's a good idea
>  [ ]  0  I really don't care.
>  [ ] -1, I don't think it's a good idea.

-pete

-- 
peter royal -> proyal@apache.org


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

Re: [Any Progress ?] Cocoon as official Apache project

Posted by Ivelin Ivanov <iv...@apache.org>.

Stefano,

is there any progress as a result of the voting procedure?


Ivelin





----- Original Message ----- 
From: "Giacomo Pati" <gi...@apache.org>
To: <co...@xml.apache.org>
Sent: Tuesday, November 26, 2002 8:01 AM
Subject: RE: [important proposal] Cocoon as official Apache project


> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> >   [X] +1  I think it's a good idea
> >   [ ]  0  I really don't care.
> >   [ ] -1, I don't think it's a good idea.
> 
> Late, but wholeheartedly
> 
> Giacomo
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 


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

RE: [important proposal] Cocoon as official Apache project

Posted by Giacomo Pati <gi...@apache.org>.

> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
>   [X] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.

Late, but wholeheartedly

Giacomo



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

RE: [important proposal] Cocoon as official Apache project

Posted by John Morrison <jo...@ntlworld.com>.

> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.

+1

J.

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

Re: [important proposal] Cocoon as official Apache project

Posted by Gianugo Rabellino <gi...@apache.org>.

[note: I replied a couple of days ago to this one, but it's not showing 
up in my mail or in the archives. Just in case, sorry for the duplicate]

 >First thing to do is to have a formal votation. All committers should
 >express their vote on this, right here:

 >  [X] +1  I think it's a good idea
 >  [ ]  0  I really don't care.
 >  [ ] -1, I don't think it's a good idea.
 >

Let's make it happen.

Ciao,

-- 
Gianugo Rabellino



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

RE: [important proposal] Cocoon as official Apache project

Posted by Carsten Ziegeler <cz...@s-und-n.de>.

Stefano Mazzocchi wrote:
> First thing to do is to have a formal votation. All committers should 
> express their vote on this, right here:
> 
>   [ ] +1  I think it's a good idea
>   [ ]  0  I really don't care.
>   [ ] -1, I don't think it's a good idea.
> 
As we discussed this in detail already ;), a definit big +1

Carsten

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