Re: Next steps?

[Peter Hunsberger]

On Sat, May 11, 2024 at 12:18 PM Christofer Dutz 
wrote:

> So, as this project is so low-volume … I think I’ll do what I did with
> similar projects.
>
>
>
> So, if I don’t hear anything else within the next 72h, I’ll initiate the
> Git migration.
>
>
+1

>
>
> Chris
>
>
>
>
>
>
>
> *Von: *Christofer Dutz 
> *Datum: *Samstag, 11. Mai 2024 um 19:12
> *An: *dev@cocoon.apache.org 
> *Betreff: *Next steps?
>
> Hi all,
>
>
>
> So, it’s been a while and I think we were waiting for the results of the
> survey.
>
>
>
> Not quite sure what we agreed upon what the next steps were.
>
>
>
> So far, I think one of the first steps I recall was a formal migration to
> using Git as a primary SCM.
>
> If that’s the case I would volunteer to do that.
>
>
>
>
>
> Chris
>

Re: [VOTE] Retire 2.1/3.0 and keep 2.x

[Peter Hunsberger]

On 2023/12/13 14:00:09 Cédric Damioli wrote:
> Hi,
> 
> Following and according to last weeks' discussions, it seems that the 
> general consensus would be to retire 2.1 (too old to be maintained) and 
> 3.0 (too alpha to be maintained), and keep 2.x around for now.
> 
> If I try to summarize what have been said, refocusing on a single 
> product would give the project a chance to 1) provide a clear upgrade 
> path to existing 2.1 users and 2) gather renewed interest.
> For the still many existing 2.1 users, this would give a clear signal 
> that it's time to consider other options.
> 
> It's now time to formally vote:
> 
 [X] +1 accept (retire and officially stop the maintenance of 2.1/3.0 
> branches, only keeping 2.x)
> [ ] -1 reject (explanation required)
> 
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are 
> required to pass.
> This vote will be open for at least 72 hours.
> 

+1 to retire and officially stop the maintenance of 2.1/3.0 
 branches, only keeping 2.x

Peter Hunsberger

> Best regards,
> Cédric
> 

Re: Probably first user-question since many years ;-)

[Peter Hunsberger]

On Thu, Dec 14, 2023 at 1:51 AM Christofer Dutz 
wrote:

> Hi all,
>
>
>
> as we’re thinking of giving 2.3 another try … I’m trying to make the ideas
> I had a bit more concrete …
>
>
>
> As some of you might know, I’m working mainly in the Industrial IoT area …
> here we have loads of data in odd data-structures and in general industial
> IoT consists of converting one odd format into another odd format.
>
> Currently most use some super tricky conversion tools …. I would love to
> try setup Cocoon pipelines, that validate and transform this information.
>

Interesting, I've done industrial IoT and have considered Cocoon just for
IoT in general. I've often debated just handling binary and allowing
arbitrary data handlers in the pipeline... That was sort of where Cocoon 3
was headed but I didn't get a chance to explore it for this purpose.  If
you get somewhere with this I might be able to make time to play with it
some.


>
>
> So, my question is: Can Cocoon also be run as a pure xml pipelining
> framework that doesn’t necessarily serve Web-clients?
>
>
>
> Chris
>
>
>

Re: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)

[Peter Hunsberger]

On Fri, Dec 1, 2023 at 11:00 AM Cédric Damioli  wrote:

> Hi,
>
> Second thread to discuss about Cocon 2.x branch, with the latest
> release, 2.3.0, just being rolled out.
> Cocoon 2.2 was initially meant to implements all stuff developed during
> the 2.1 cycle on top of Spring and Maven, to drop old Avalon dependencies.
>
> We'd like to know whether you'd prefer:
> [-1 ] retiring Cocoon 2.x
>


> [+0] reviving/maintaining Cocoon 2.x, meaning that you volunteer to be
> somehow involved
>
> Please note that the above proposal is not a formal vote, but more like
> a open poll, so that everyone could speak out.
>
> Should we continue the project and this branch particularly, there are
> recent threads on this list proposing to switch to Git, to upgrade
> dependencies, build system, ...
>
> Cédric
>

Not sure I can really commit to helping much, other than testing releases,
I don't see having the time to dive into the code anymore but I do still
see people using this code base.

Peter Hunsberger


> Le 30/11/2023 à 19:53, Cédric Damioli a écrit :
> > Dear Cocoon users and developers,
> >
> > Sorry for crossposting here, I wanted to be sure that all involved
> > people were aware of the ongoing discussions.
> >
> > We recently pushed a new release of Cocoon, 11 years after the
> > previous one. This release gathers all changes made in between as well
> > as two security fixes discovered last year.
> > The journey to roll this release out was definitively not an easy one,
> > and it's now time to think about what should be next for the project.
> >
> > We currently officially maintain 3 branches, not compatible with each
> > others and having evolved differently over the years : 2.1.x, 2.2/2.3
> > and 3.0, and we do not have enough active developers to be able to
> > continue to properly and correctly maintain them.
> >
> > For a project as old as Cocoon (21 years!), there may be many users
> > around here still using one branch or another, which could be
> > interested to step up, contribute and try to revive the project, or at
> > least some parts of it.
> >
> > I will soon start 3 threads on the developers list to decide what to
> > do about each of the 3 branches (retiring or not), so I encourage
> > volunteers to bring their voices.
> >
> > Best regards,
> > Cédric, on behalf of the Apache Cocoon PMC
> >
>
> --
> Cédric Damioli
> CMS - Java - Open Source
> www.ametys.org
>
>

Re: [DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)

[Peter Hunsberger]

On Fri, Dec 1, 2023 at 10:41 AM Cédric Damioli  wrote:

> Hi,
>
> First of the sub-project to be discussed, the Cocoon 3 project.
> Never released, it only reached the alpha status 12 years ago.
> Its goal was to provide a pure Java API on top of pipelines and sitemaps
> concept, to be able to easily implements lightweight REST applications.
>
> We'd like to know whether you'd prefer:

[+1 ] retiring Cocoon 3.0
>


> [ ] reviving/maintaining Cocoon 3.0, meaning that you volunteer to be
> somehow involved
>
> Please note that the above proposal is not a formal vote, but more like
> a open poll, so that everyone could speak out.
>
> Cédric
>
I too had some fun building stuff with 3.0 but I can't see a use for it any
more.

+1 to retiring it (if it's not obvious from above)

Peter Hunsberger



> Le 30/11/2023 à 19:53, Cédric Damioli a écrit :
> > Dear Cocoon users and developers,
> >
> > Sorry for crossposting here, I wanted to be sure that all involved
> > people were aware of the ongoing discussions.
> >
> > We recently pushed a new release of Cocoon, 11 years after the
> > previous one. This release gathers all changes made in between as well
> > as two security fixes discovered last year.
> > The journey to roll this release out was definitively not an easy one,
> > and it's now time to think about what should be next for the project.
> >
> > We currently officially maintain 3 branches, not compatible with each
> > others and having evolved differently over the years : 2.1.x, 2.2/2.3
> > and 3.0, and we do not have enough active developers to be able to
> > continue to properly and correctly maintain them.
> >
> > For a project as old as Cocoon (21 years!), there may be many users
> > around here still using one branch or another, which could be
> > interested to step up, contribute and try to revive the project, or at
> > least some parts of it.
> >
> > I will soon start 3 threads on the developers list to decide what to
> > do about each of the 3 branches (retiring or not), so I encourage
> > volunteers to bring their voices.
> >
> > Best regards,
> > Cédric, on behalf of the Apache Cocoon PMC
> >
>
> --
> Cédric Damioli
> CMS - Java - Open Source
> www.ametys.org
>
>

Re: Now that the release is out, what's next?

[Peter Hunsberger]

On Tue, Nov 21, 2023 at 12:15 AM Christofer Dutz 
wrote:

> Well guess I haven't stated it yet: I would be willing to work on it (I've
> especially for some ideas on streaming industrial data from plc4x).
>
> Personally I would let the pre-2.2 branch rest in peace. All is
> dependencies are so extremely old and the jdks for some are no longer
> available. At least I probably wouldn't touch it and focus on the
> "middle"...
>
 +1 !


> Possibly have a look at 3.0 (haven't done that yet).
>

I tried using 3.0 for a project.  Some good ideas and simple enough
implementation but I don't think there is enough there for it to be worth
saving

>
> Chris
>
> Gesendet von Outlook für Android 
> --
> *From:* Cédric Damioli 
> *Sent:* Monday, November 20, 2023 3:47:14 PM
> *To:* dev@cocoon.apache.org 
> *Subject:* Re: Now that the release is out, what's next?
>
> Hi,
>
> On top of that, as a community, we now have to formally answer to the
> below question (going or not to the Attic) not only once, but three times,
> one time for each subproject we still officially maintain since more than
> 10 years :
>  - Cocoon 2.1.x (pre-Spring, pre-Maven). Last release 2.1.13 was rolled
> out 3 years ago.
>  - Cocoon 2.2x (now 2.3.x). Last release these days.
>  - Cocoon 3.0.x. Last release 3.0.0-alpha-3 back in 2011
>
> Those 3 versions are not compatible with each other, are not meant as
> drop-in replacements, and have evolved differently over the years.
>
> The community could either decide to stop the project as-is and go to the
> Attic, or start over maintaining only one or two branches.
>
> Cédric
>
> Le 19/11/2023 à 18:20, Christofer Dutz a écrit :
>
> Hi folks,
>
>
>
> So, it seems that we finally have finished the last missing steps to
> formally get the release out the door. Now I think comes a time where we
> should reflect and discuss, what should happen with the Project.
>
>
>
> So instead of simply saying: Releasing it was such a struggle (not
> technically, but from a participation side) I wouldn’t say this project is
> healthy and we should discuss a move into the Attic.
>
>
>
> However, I could also imagine that the changes I implemented in the build
> might encourage some folks to give it another go.
>
>
>
> I know when I was doing projects with Cocoon as part of my day-job 20
> years ago, Cocoon 2.2 sort of completely broke my flow. Not only my
> inexperience with Maven, but also that of Spring and the versioning scheme
> where all sorts of cocoon modules had different versions just made me give
> up at that time and switch to Adobe Flex ;-)
>
>
>
> Now (15 years later) Maven and Spring have evolved and with the cleanups
> in the build, it should be a lot simpler to work with Cocoon and with all
> modules sharing the same version, also this should be a lot simpler.
>
>
>
> So, I would like to ask you folks:
>
>- Should we aim directly for the Attic?
>- Does anyone want to revive the project? (I’m intentionally not only
>addressing committers and PMC members, but also people wanting to keep the
>project alive)
>
>
>
>
>
> Chris
>
>
> --
> Cédric Damioli
> CMS - Java - Open Sourcewww.ametys.org
>
>

Re: Now that the release is out, what's next?

[Peter Hunsberger]

On Mon, Nov 20, 2023 at 3:35 AM Christofer Dutz 
wrote:

> Hi Gabriel,
>
>
>
> I was more referring to the first response and I have seen loads of
> similar responses when initiating Attic discussions in the past with other
> projects. I just wanted to make it clear, that a projects livelihood is
> defined by the people giving and not the people wanting ;-)
>
>
>
> Becoming a contributor is easy. Perhaps it would make sense for us to
> formally switch to Git, because then it would be a lot simpler:
>
>- Create a fork
>- Do your changes in that fork
>- Create a PR
>- Have someone merge these changes
>- Hopefully get voted in as committer soon
>
> Perhaps switching to Git would be a good first step.
>
>
>
+1 for switching to Git

Peter Hunsberger



> Chris
>
>
>
>
>
> *Von: *Gabriel Gruber 
> *Datum: *Montag, 20. November 2023 um 10:26
> *An: *dev@cocoon.apache.org 
> *Betreff: *Re: Now that the release is out, what's next?
>
> Hello Christopher,
>
> just to make it clear. I AM willing to participate and contribute. I was
> the pushing force on the Spring 4 dependency upgrade. And meanwhile our
> cocoon 2 instance runs on spring 5 and java 11 – so I have some stuff,
> which I would love to get into the OS project again.
>
> As I said I would like to contribute further to make cocoon 2 compatible
> with state-of-the-art dependencies like java 21 and spring 6.
>
> However I need some help to become a formal contributor. Maybee you could
> help me in that?
>
> Thank you
>
> Gabriel
>
>
>
>
>
> *From: *Christofer Dutz 
> *Date: *Monday, 20. November 2023 at 10:08
> *To: *dev@cocoon.apache.org 
> *Subject: *AW: Now that the release is out, what's next?
>
> Hi all,
>
>
>
> let me mention one thing here … Open-Source is not a need-driven thing,
> that anyone is entitled to exist to solve one owns needs. It’s an
> initiative-driven thing that anyone can participate.
>
>
>
> So, if you need some open-source solution, you should consider actively
> contributing. Because if nobody contributes, then the open-source project
> will die and move into the attic.
>
>
>
> An alternative for this is that people and companies can pay someone else
> to participate in their place.
>
>
>
> But in the end, if nobody works on it, it’s going to go into the attic.
>
>
>
> I hope with my general overhaul of the build and project structure, I have
> made contributing and releasing a lot simpler, but I’m not planning on
> keeping the lights on, if I’m the only one working.
>
>
>
> Chris
>
>
>
>
>
>
>
> *Von: *Gabriel Gruber 
> *Datum: *Sonntag, 19. November 2023 um 19:55
> *An: *dev@cocoon.apache.org 
> *Betreff: *Re: Now that the release is out, what's next?
>
> Hi cocoon team,
>
>
>
> as we are still using cocoon 2.2 in PROD as base for our product, we have
> a high interest that the open source project stays alive.  Our main
> motivation here would be framework and java compatibility as well as
> security patches.
>
>
>
> Of course I am also willing to actively support and maintain. A great
> improvement would be, if the source-code could move to github.
>
>
>
> Thanks Chris for your enormous efforts to get this release through! Thanks
> to all the committers for building such a great and long lasting project.
>
>
>
> Gabriel
>
>
>
> *From: *insigh...@gmail.com 
> *Date: *Sunday, 19. November 2023 at 19:36
> *To: *dev@cocoon.apache.org 
> *Subject: *Re: Now that the release is out, what's next?
>
> I mentioned this early, the DSpace Content Management project used Cocoon
> 2.2 until version 6.4 (v7 moved to Angular JS). They integrated with Solr
> and did a bunch of other things that may be worth a look.
>
> The Cocoon interface was called xmlui (look for the subfolder), and
> available via Github:
>
> https://github.com/DSpace/DSpace/releases
>
> Source Code:
> https://github.com/DSpace/DSpace/archive/refs/tags/dspace-6.4.tar.gz
>
> Great work on continuing the Cocoon legacy!
>
> Dan
>
>
>
> On 2023-11-19 10:20 a.m., Christofer Dutz wrote:
>
> Hi folks,
>
>
>
> So, it seems that we finally have finished the last missing steps to
> formally get the release out the door. Now I think comes a time where we
> should reflect and discuss, what should happen with the Project.
>
>
>
> So instead of simply saying: Releasing it was such a struggle (not
> technically, but from a participation side) I wouldn’t say this project is
> healthy and we should discuss a move into the Attic.
>
>
>
> However, I could 

Re: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Peter Hunsberger]

Everything looks good except I can't check the signature, I get "No public
key" from gpg.  I believe I need a copy of your public key to import?

Peter Hunsberger


On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
wrote:

> Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
>
> on accepting it for release. All Maven artifacts are available under [1].
>
> Voting will be open for 72hr.
>
>
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>
> are required to pass.
>
>
>
> Release tag:
> https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
>
> Director revision of the tag: 1913422
>
>
>
> Per [3] "Before voting +1 PMC members are required to download
>
> the signed source code package, compile it as provided, and test
>
> the resulting executable on their own platform, along with also
>
> verifying that the package meets the requirements of the ASF policy
>
> on releases."
>
>
>
> You can achieve the above by following the guide of a fellow Apache
> project [4].
>
>
>
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
>
> [ ]  -1 reject (explanation required)
>
>
>
>
>
> [1]
> https://repository.apache.org/content/repositories/orgapachecocoon-1007
>
> [2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> [3] https://www.apache.org/dev/release.html#approving-a-release
>
> [4]
> https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release
>
>
>

Re: Content-Length header

[Peter Hunsberger]

Think you can likely just hard code it to skip HEAD and maybe OPTIONS if
you need to?  Document the change and if we some day finally get a new
release out the door people will just have to test against their existing
applications.  I don't see how they would break but maybe there are ways?

Peter Hunsberger

On Thu, Mar 30, 2017 at 7:53 AM, Cédric Damioli <cdami...@apache.org> wrote:

> I've searched archives but only found [1], which is only partly related.
>
> Of course, commitResponse could be overridden in HttpEnvironment to filter
> out some HTTP methods, but which ones ? Should we have a black list, a
> white list, or a mean to configure it somewhere ? I don't want to break
> some compatibility somewhere.
> BTW, maybe only HEAD requests are concerned, after all ...
>
> Cédric
>
> [1] http://cocoon.markmail.org/search/?q=content-length#
> query:content-length+page:4+mid:ddsqo5ezsstshh7a+state:results
>
> Le 29/03/2017 à 19:14, Peter Hunsberger a écrit :
>
> This sounds somewhat familiar, you may want to search the mailing list
> archives to see if this has been discussed before Can commitResponse
> tell what kind of request it is dealing with or if not can that be passed
> in so that it knows?
>
> Peter Hunsberger
>
> On Wed, Mar 29, 2017 at 10:14 AM, Cédric Damioli <cdami...@apache.org>
> wrote:
>
>> Hi,
>>
>> I recently noticed that, at least for 2.1.x and 2.2.x, after any request
>> processing, Environment.commitResponse() is called which has the side
>> effect to compute the actual response body size and then set the response
>> content length.
>> While this is perfectly fine for GET requests, it's obviously useless for
>> OPTIONS and even wrong for HEAD requests.
>>
>> Looking at code, an immediate workaround is to disable output buffering
>> but it's not satisfying.
>>
>> Did someone encountered the same issue ?
>>
>> I don't know exactly how to solve this without breaking legacy behaviour.
>> Any thoughts ?
>>
>> Regards,
>>
>> --
>> Cédric Damioli
>> CMS - Java - Open Source
>> www.ametys.org
>>
>>
>
> --
> Cédric Damioli
> CMS - Java - Open Sourcewww.ametys.org
>
>

Re: Content-Length header

[Peter Hunsberger]

This sounds somewhat familiar, you may want to search the mailing list
archives to see if this has been discussed before Can commitResponse
tell what kind of request it is dealing with or if not can that be passed
in so that it knows?

Peter Hunsberger

On Wed, Mar 29, 2017 at 10:14 AM, Cédric Damioli <cdami...@apache.org>
wrote:

> Hi,
>
> I recently noticed that, at least for 2.1.x and 2.2.x, after any request
> processing, Environment.commitResponse() is called which has the side
> effect to compute the actual response body size and then set the response
> content length.
> While this is perfectly fine for GET requests, it's obviously useless for
> OPTIONS and even wrong for HEAD requests.
>
> Looking at code, an immediate workaround is to disable output buffering
> but it's not satisfying.
>
> Did someone encountered the same issue ?
>
> I don't know exactly how to solve this without breaking legacy behaviour.
> Any thoughts ?
>
> Regards,
>
> --
> Cédric Damioli
> CMS - Java - Open Source
> www.ametys.org
>
>

Re: Cocoon 2.2 in servlet 3.0 environment fails to initialize when webjars present on classpath.

[Peter Hunsberger]

Hi Leszek,

although there are a few of us still hanging around I suspect you're
going to have to figure this one out on your own.  Running Cocoon
under Jetty is interesting to me personally but I won't have any time
to look at this in the near future...
Peter Hunsberger


On Wed, Sep 28, 2016 at 4:11 AM, Leszek Gawron <lgaw...@mobilebox.pl> wrote:
> I wonder if there is still anyone able to answer my question but still:
>
> I have found a problem that prevents deploying cocoon to 3.0 containers if
> the webapp contains webjars - by webjar I mean a jar containing
> META-INF/resources folder which is specially treated by sevlet container
> (the resources from that folder are served by container itself bypassing any
> webapp setup).
>
> This happens on jetty 9.x. No matter if I set webapp to be 2.5 servlet
> compliant or 3.0.
> Does not happen on jetty 8 which is ancient as of now.
>
>
> I try running my app in embedded Jetty 9 - it works - as long as there is no
> actual .war - there is no scanning for META-INF resources.
>
> As soon as I build a war this is how a configured context looks like:
>
>
> startup of context o.e.j.w.WebAppContext@5bcab519{/,[
>
> file:///C:/cygwin/tmp/jetty-0.0.0.0-8080-root.war-_-any-1513195852101013802.dir/webapp/,
> jar:file:///C:/temp/jetty/mywebapp/smart-libs/modernizr-2.8.3.jar!/META-INF/resources,
> jar:file:///C:/temp/jetty/mywebapp/smart-libs/openlayers-3.2.0.jar!/META-INF/resources,
> jar:file:///C:/temp/jetty/mywebapp/smart-libs/bootstrap-3.3.2.jar!/META-INF/resources,
> jar:file:///C:/temp/jetty/mywebapp/smart-libs/jquery-1.11.1.jar!/META-INF/resources],UNAVAILABLE}
> {C:\temp\jetty-gemini\gemini/root.war}
>
> suddenly there is more than one root for static resources.
>
> This yields following error:
>
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'org.apache.cocoon.Processor': Initialization of bean failed;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Unable to initialize Avalon component with role org.apache.cocoon.Processor;
> nested exception is
> org.apache.avalon.framework.configuration.ConfigurationException: Cannot
> resolve context://sitemap.xmap
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:547)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
> at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:755)
> at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:759)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
> at
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:434)
> at
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
> at
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
> at
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:843)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:533)
> at
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:816)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:345)
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:778)
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
> at
> org.eclipse.jetty.ut

Re: [jira] Updated: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart

[Peter Hunsberger]

It's likely going to be some difference in the class paths used in the two
systems and what libraries are sitting in which parts of the class path.
To check, work backwards from the error; what library is the class in,
where do those libraries sit on your class path, is the 1st one found the
right version?  If it is, are there dependencies it has on other
libraries?  If yes. rep[eat the check for those libraries.  Usually you'll
find the system has set a class path that includes a version of some
duplicate library that will be found earlier than the version Cocoon
wants.  If you can change the class path order, or move libraries around
you should be able to fix the problem.

Peter Hunsberger

On Fri, Oct 23, 2015 at 2:07 AM, josepascual <
josepascual.gim...@softwareag.es> wrote:

> Hi francesco,
> thanks for your answer ...
>
> in our case, the problem is that we try to deploy the web application in
> our
> local environment under our pc windows 7 system.
>
> We can deploy the app under client environment without any problem, the
> customer can use it correctly. We received the maintenance of this
> application several years ago, and when we have to modify something we work
> in our computers and prove over client systems, in Integration environment.
>
> As you will guess this is very difficult manner  to work, because all
> developers share the same environment to prove.
>
> So we decided to try install in our local environment the Sun One over our
> windows and install the app to work. I'm trying to do this for two weeks
> and
> unfortunately it doesn't work.
>
> thanks for advance.
> Regards
> Jose Pascual
>
>
>
> --
> View this message in context:
> http://cocoon.10839.n7.nabble.com/jira-Created-COCOON-2146-Using-EventAware-cache-implementation-breaks-persistent-cache-restore-on-ret-tp45160p58529.html
> Sent from the Cocoon - Dev mailing list archive at Nabble.com.
>

Re: [VOTE] Apache Cocoon Integration Test Framework 1.0.1

[Peter Hunsberger]

On Thu, Dec 13, 2012 at 3:16 AM, Francesco Chicchiriccò ilgro...@apache.org
 wrote:

 I've created a Cocoon Integration Test Framework 1.0.1 release, with the
 following artifacts up for a vote:

 Vote will be open for 72 hours.


Can't really test at the moment but +1

Re: using both Xalan and Saxon with C3

[Peter Hunsberger]

We've had to do that on Cocoon 2.x in the past when we had a mix of XSLT
1.0 and XSLT 2.0 stylesheets.  With XSLT 3.0 coming along you may in fact
need three xslt processors in a single application...

Peter Hunsberger


On Thu, Dec 6, 2012 at 6:44 PM, Mansour Al Akeel
mansour.alak...@gmail.comwrote:

 Ok, I see what you mean now.

 Just out of curiosity, why would anyone need to use more than one xslt
 processor in one application ??

 Thank you.

Re: Caching improvement ( from: Cocoon presentation link and questions about new contributions)

[Peter Hunsberger]

Hi Javier,

ok, that makes sense now. In what seem like the distant past we talked
about a bunch of things that could be done to the C2 caching systems. I
haven't ever dug into what has been done with C3 so I can't really guess at
how any of that would apply, but if I was starting from scratch I'd be
giving some consideration to event driven cache invalidation and maybe even
using memcached.

Peter Hunsberger


On Fri, Oct 12, 2012 at 6:58 AM, Javier Puerto jpue...@gmail.com wrote:

 Hi Peter,

 I've open a new thread as Thorsten did because I opened too many things in
 a single mail. :)

 2012/10/11 Peter Hunsberger peter.hunsber...@gmail.com

 Hi Javier,

 not quite sure what you are asking about?  I know you're asking about
 caching implementations, but it's not clear what the problem is in general
 that you are addressing, or is this just a solution for a very specific
 problem?  Is this caching Cocoon resources, HTTP level caching or maybe
 even something in between?


 There's no problems in Apache Cocoon 3.0 caching system. It's working OK
 but I think that it could be better. With old cocoon releases, the caching
 system relies on the now discontinued framework Apache Excalibur [1].

 Cocoon 3.0 was rewritten to remove dependencies for these frameworks. Now,
 it has something similar now but it's lacks support for fragment caching
 [2] [3]. If a pipeline has a component that is not cacheable, the whole
 pipeline will be processed. With fragment caching all the components
 results are cached so the pipeline will start the execution with the first
 non-cacheable component. This can be minimized splitting big pipelines into
 smaller ones but sometimes is not desirable.

 When Francesco and I worked making the XIncludeTransformer and
 IncludeTransformer cacheable respectively, we found that we had to create
 something similar to old caching style. So I wonder if we can put some
 effort to migrate the old caching system, see discussion in [4].

 At end we need to add Javadoc to the current caching interfaces [5].

 Salu2

 [1] http://excalibur.apache.org/
 [2] http://cocoon.apache.org/2.2/core-modules/core/2.2/675_1_1.html
 [3] http://cocoon.apache.org/2.2/core-modules/core/2.2/690_1_1.html
 [4] https://issues.apache.org/jira/browse/COCOON3-102
 [5] https://issues.apache.org/jira/browse/COCOON3-92




 Peter Hunsberger



 On Wed, Oct 10, 2012 at 5:38 PM, Javier Puerto jav...@apache.org wrote:

 Hi all,

 I had working for an introduction talk about cocoon and I want lo leave
 the github link. The presentation is in Spanish because was for the
 http://barcampspain.com/ and http://www.congresohispanoluso.com/en/.
 Comes with examples made with cocoon 3.0 parsing a F1 sport webpage and
 serve the contents in different formats. If you are interested I can
 translate the presentation to English (examples and code are in English).

 Link: https://github.com/jpuerto/barcampes2012-cocoon

 Working on the presentation I did a proof of concept creating an Apache
 Tika generator. It's working but needs to enable caching and add the proper
 test cases and samples. If you are interested, I can finish it and commit
 changes.

 While I was working with cocoon at work time I started a
 OptimizerTransformer but I've found that IncludeTransformer is not
 cacheable so I worked first to get it cacheable (COCOON3-100)
 The transformer development is just at the beginning but before I
 continue to work with it I want your opinion. The idea is to use YUI
 compressor (BSD license) and define a custom language to define the static
 resources as CSS and JS. The transformer should review the resources,
 respect the order, compress the files and create optimized resources in a
 given path (to serve from Apache HTTPD with mod_cache and different
 domain). As this operation has a high cost, the transformer must control if
 the resource files changed. Finally, the transformer will place the proper
 tag with the URL for optimized static resources.

 WDYT? maybe there's better solutions (I know google HTTPD mod_pagespeed
 but it's always in beta state). The advantage is that you don't need to
 define everything at build time, with maven plugin for example so you can
 organize your static resources like you want (no one big file for all). On
 the other hand it has a high processor cost, but caching should minimize it.

 I didn't had time to work in Apache Cocoon 3.0 caching system since a
 couple of months ago. Recently, I had to switch the project and ATM I'm not
 working directly with cocoon. I want to take a closer look to the caching
 system when I can get some free time (COCOON3-30 and fragment caching),
 probably at December. Anyway, I will try to help in the mailing list and
 make some contributions like described above.

 I hope to see you soon in the ApacheCon,
 Salu2.

Re: Cocoon presentation link and questions about new contributions

[Peter Hunsberger]

Hi Javier,

not quite sure what you are asking about?  I know you're asking about
caching implementations, but it's not clear what the problem is in general
that you are addressing, or is this just a solution for a very specific
problem?  Is this caching Cocoon resources, HTTP level caching or maybe
even something in between?

Peter Hunsberger


On Wed, Oct 10, 2012 at 5:38 PM, Javier Puerto jav...@apache.org wrote:

 Hi all,

 I had working for an introduction talk about cocoon and I want lo leave
 the github link. The presentation is in Spanish because was for the
 http://barcampspain.com/ and http://www.congresohispanoluso.com/en/.
 Comes with examples made with cocoon 3.0 parsing a F1 sport webpage and
 serve the contents in different formats. If you are interested I can
 translate the presentation to English (examples and code are in English).

 Link: https://github.com/jpuerto/barcampes2012-cocoon

 Working on the presentation I did a proof of concept creating an Apache
 Tika generator. It's working but needs to enable caching and add the proper
 test cases and samples. If you are interested, I can finish it and commit
 changes.

 While I was working with cocoon at work time I started a
 OptimizerTransformer but I've found that IncludeTransformer is not
 cacheable so I worked first to get it cacheable (COCOON3-100)
 The transformer development is just at the beginning but before I continue
 to work with it I want your opinion. The idea is to use YUI compressor (BSD
 license) and define a custom language to define the static resources as CSS
 and JS. The transformer should review the resources, respect the order,
 compress the files and create optimized resources in a given path (to serve
 from Apache HTTPD with mod_cache and different domain). As this operation
 has a high cost, the transformer must control if the resource files
 changed. Finally, the transformer will place the proper tag with the URL
 for optimized static resources.

 WDYT? maybe there's better solutions (I know google HTTPD mod_pagespeed
 but it's always in beta state). The advantage is that you don't need to
 define everything at build time, with maven plugin for example so you can
 organize your static resources like you want (no one big file for all). On
 the other hand it has a high processor cost, but caching should minimize it.

 I didn't had time to work in Apache Cocoon 3.0 caching system since a
 couple of months ago. Recently, I had to switch the project and ATM I'm not
 working directly with cocoon. I want to take a closer look to the caching
 system when I can get some free time (COCOON3-30 and fragment caching),
 probably at December. Anyway, I will try to help in the mailing list and
 make some contributions like described above.

 I hope to see you soon in the ApacheCon,
 Salu2.

Re: [Discuss] Sitemap NG

[Peter Hunsberger]

Hi Simone,

long time ago we had discussions on alternate languages for the C2 Sitemap,
I used to want to do them in XSLT (as opposed to XML) with Java extensions
to implement the actual interface from the XSLT to the resulting Cocoon
object tree for the sitemap. These days I sometimes wonder if I could build
sitemaps in Neo4J and have Cocoon read them in via it's Neo4Js REST
interface (or more directly)...

In some ways it seems Cocoon 3 is already aimed at  most of what you
outline or is this in addition to the way you can do Java pipelines there?

Peter Hunsberger


On Mon, Aug 6, 2012 at 2:50 AM, Simone Tripodi simonetrip...@apache.orgwrote:

 Hi all guys,

 I've had this mail draft for a long while and I think it's time to
 shout it out to get your feedbacks.

 Due to my involvement in Apache Commons and being strongly influenced
 by the Google-Guice design, I think we could get benefit from a vision
 that mixes the power of:

  * modularity;
  * Embedded DSL.

 The current situation is that the sitemap takes tons of Kb of Spring
 dependencies (please assume I'm not a big fan of Spring so my POV is
 influenced :P) and the sitemap is described via XML. Since we can
 still take the XML configuration, I'm sure - but I haven't had the
 time to write even a kickoff spike, so I still don't have the proof on
 hands - we could simplify the foundation of sitemap design, getting
 benefits from the javac using directly the Java language to describe
 the sitemap.

 What I'd suggest is introducing Sitemap(s) to describe how  the
 sitemap is organized, i.e.

 +-+
 interface Sitemap
 {

 void configure( SitemapBinder binder );

 }
 +-+

 where the {{SitemapBinder}} contains a set of APIs to allow describing
 the path-matching;  a possible case could be:

 +-+
 public class MySitemap
 implements Sitemap
 {

 public void configure( SitemapBinder binder )
 {
 binder.when( linkmap.xml )
  .newCachingPipeline()
  .setStarter( new XMLGenerator(new URL( feed.xml ) )
  .addComponent( new
 XSLTTransformer(this.getClass().getResource(/trax.xslt) )
  .setFinisher( XMLSerializer.createXMLSerializer );

 ...

 binder.when( linkmap2.xml )
  .newCachingPipeline()
  .setStarter( new XMLGenerator(new URL( feed2.xml ) )
  .addComponent( new
 XSLTTransformer(this.getClass().getResource(/trax2.xslt) )
  .setFinisher( XMLSerializer.createXMLSerializer );

 ...
 }

 }
 +-+

 that would reflect what in XML would be expressed as:

 +-+
 map:match pattern=linkmap.xml
   map:generate src=classpath:feed /
   map:transform src={lm:transform.linkmap.document}/
   map:serialize type=xml /
 /map:match

 ...

 map:match pattern=linkmap2.xml
   map:generate src=classpath:feed2 /
   map:transform src={lm:transform.linkmap.document}/
   map:serialize type=xml /
 /map:match

 ...
 +-+

 of course, XML looks compact, but please take in consideration that
 XML is not type checking, we can get errors at runtime only; that
 means that a transformer can be erroneously set as generator, while
 using Java APIs it would be notified at compile time.

 An AbstractSitemap would help to reduce the `binder` variable verbose
 and redundant call:


 +-+
 public class MySitemap
 extends AbstractSitemap
 {

 @Override
 public void configure()
 {
when( linkmap.xml )
  .newCachingPipeline()
  .setStarter( new XMLGenerator(new URL( feed.xml ) )
  .addComponent( new
 XSLTTransformer(this.getClass().getResource(/trax.xslt) )
  .setFinisher( XMLSerializer.createXMLSerializer );

 ...

when( linkmap2.xml )
  .newCachingPipeline()
  .setStarter( new XMLGenerator(new URL( feed2.xml ) )
  .addComponent( new
 XSLTTransformer(this.getClass().getResource(/trax2.xslt) )
  .setFinisher( XMLSerializer.createXMLSerializer );

 ...
 }

 }
 +-+

 we could also work by Sitemap composition:


 +-+
 public class MySitemap
 implements Sitemap
 {

 public void configure( SitemapBinder binder )
 {
 binder.when( linkmap.xml )
  .newCachingPipeline()
  .setStarter( new XMLGenerator(new URL( feed.xml ) )
  .addComponent( new
 XSLTTransformer(this.getClass().getResource(/trax.xslt) )
  .setFinisher( XMLSerializer.createXMLSerializer );

 ...

 binder.include( new MySitemap2() );

 ...
 }

 }
 +-+

 then a special loader is used to create the application

Re: [Discuss] Sitemap NG

[Peter Hunsberger]

Hi Simone,

I guess the part I'm missing is how would this differ from what is already
in Cocoon 3 as an API?  I do get that part (most, all?) of you objective is
to get rid of the Spring layer, so maybe the end result is essentially the
same as the C3 API in the end?

Peter Hunsberger


On Mon, Aug 6, 2012 at 10:33 AM, Simone Tripodi simonetrip...@apache.orgwrote:

 Hi Peter!

 My proposal is writing an intermediate layer to create sitemaps, it
 doesn't aim to replace the existing infrastructure but IMHO it could
 be used as the foundation to create sitemaps; while all textual
 configurations work fine, having a more expressive and type checking
 APIs could help - and users could still wrap them in their bigger
 picture, making the tree objects construction easier.

 You could have a look at the Apache Commons Digester binder[1] APIs,
 which are wrapped by the XML configuration[2] and annotated
 elements[3]. One expressive layer to create the sitemap, multiple way
 to bind them.

 I agree that building tree objects would still work, but Fluent
 Interfaces would help on respecting the configuration status, i.e. the
 first element of a Pipeline can only be a Starter, when using the old
 way users are still able to setup a pipeline with no starter and find
 the error only when executing it.

 I am sure there are cases I am not taking in consideration that would
 break my PoC as well :P

 what do you think? You would be still able to load a graph from Neo4j
 and setup the pipeline using directly native Java APIs - no parsing,
 no transforming, a little faster :P

 Many thanks in advance, all the best!
 -Simo

 [1] http://commons.apache.org/digester/guide/binder.html
 [2] http://commons.apache.org/digester/guide/xmlrules.html
 [3] http://commons.apache.org/digester/guide/annotations.html

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/


 On Mon, Aug 6, 2012 at 4:21 PM, Peter Hunsberger

Re: some generic questions about dynamicity C3

[Peter Hunsberger]

Hi Robby,

we did a lot of dynamic pipeline composition with C2 at a previous job.
 Because of the way it works we did not try to generate any part of the
sitemap dynamically.  My basic conclusion was that you'd need to replace
some components of C2 but it would have been possible.  It was just easier
to use request parameters to figure out what data to grab and what to
produce and use the sitemap to classify the major categories for which we
did this...  So we ended up with a fixed sitemap and a bunch of fixed
major categories.  Within each category you could dynamically vary the
results to some extent.

Peter Hunsberger


On Mon, Jul 23, 2012 at 6:21 AM, Robby Pelssers robby.pelss...@nxp.comwrote:

 Hi people,

 ** **

 We have the plan to go cloud with Cocoon (3).   Our old way of working was
 to embed typical resources (css/xslt/js/xqueries) into the war itself.  I
 am currently considering storing all resources into a database (mysql/…).
 Is someone already doing the same?

 ** **

 Besides that, I am wondering if someone already considered some way of
 having a more dynamic sitemap. The end goal would be that I would not need
 to redeploy the app for each sitemap change.  A few options come to mind:*
 ***

 **-  **Investigate if we not also can store the sitemap into a
 db.  Is cocoon really expecting the sitemap to be at a certain location
 inside the war?

 **-  **Use a similar approach to Apache servicemix where you can
 install services (in our case restful endpoints) on the fly (osgi)

 ** **

 I’m really interested to find out if I’m stepping on unknown territory or
 if this has been already done in practice.

 ** **

 Kind regards,

 Robby Pelssers

Timezones on reports

[Peter Hunsberger]

Hi everyone,

while working with Fleet FYI we have noticed that the reporting process
uses the RoamTimestampPrintPolicy currentTimeZone to determine how times
are specified and displayed on reports. Given how this works, as a result
the times zones associated with time parameters on reports are always with
respect to GMT (essentially hard coded). For our users, I'd like to change
the report processor to pick up the time zone of the user creating the
report. Given some of the changes that Fleet FYI would like to see I am
eventually going to have to create a new set of report pages specifically
for them.  I can do that now, and make this new behavior specific to those
pages, or I can make the current reporting pages pick up this behavior and
worry about the changes specific to Fleet FYI later on.  So I guess the
question is, will changing to using the User Time zone settings on the
reporting pages be too big of change for existing customers or would this
be something they would like to see? A third option would be to add a
Customer or User level setting that said whether to use the user time zone
on reports, and then if it is set to true, switch to the new behavior.
 However, it's not clear that this level of configuration can be picked up
when the reports are run.

Thanks for any thoughts anyone might have,

Peter Hunsberger

Vice President Systems,
*Phone: 678-597-4229Fax: 678-563-0016
Skype: peter.hunsberger*

[image: RWfullcolor150ppi.png]

http://www.roamworks.com

 http://www.roamworks.com/

**

ROAMWORKS FZ LLC, Office 111/110, Building 14, Dubai Internet City,
P.O. Box 500229, Dubai, UAE, Tel: +971-4-3900270, Fax: +971-4-3908521

ROAMWORKS Research  Development GmbH, Poppelsdorfer Allee 114, 53115 
Bonn**, **Germany, Tel: +49-228-965769-0, Fax: +49-228-965769-29

*ROAMWORKS U.S.A. Inc. 11555 Medlock Bridge Road, Suite 100, Duluth, Georgia
 30097, USA, Tel: +1-678-597-4229, Fax  +1-678-563-0016*

*Confidentiality Notice from ROAMWORKS*

The information contained in this electronic message and any attachments
are intended for the exclusive use of the addressee(s) and may contain
confidential or privileged information. If you are not the intended
recipient, please notify the sender at ROAMWORKS or email this message to
postmas...@roamworks.com immediately and destroy all copies of this message
and any attachments.
image003.png

Re: [VOTE] Apache Cocoon JNet 1.2.2

[Peter Hunsberger]

+1
Peter Hunsberger


On Tue, Jun 19, 2012 at 8:09 AM, Francesco Chicchiriccò ilgro...@apache.org
 wrote:

 I've created a Cocoon JNet 1.2.2 release, with the
 following artifacts up for a vote:

Re: [VOTE] Apache Cocoon XML Utilities 2.0.4

[Peter Hunsberger]

+1
Peter Hunsberger


On Fri, Jun 15, 2012 at 2:40 AM, Francesco Chicchiriccò ilgro...@apache.org
 wrote:

 I've created a Cocoon XML Utilities 2.0.4 release, with the following
 artifacts up for a vote:

Re: [VOTE] Apache Cocoon Maven Plugin 1.0.2

[Peter Hunsberger]

+1
Peter Hunsberger


On Fri, Jun 15, 2012 at 2:47 AM, Francesco Chicchiriccò ilgro...@apache.org
 wrote:

 I've created a Cocoon Maven Plugin 1.0.2 release, with the following
 artifacts up for a vote:

Re: [VOTE] Apache Cocoon Spring Configurator 2.2.1

[Peter Hunsberger]

+1
Peter Hunsberger


On Fri, Jun 15, 2012 at 2:56 AM, Francesco Chicchiriccò ilgro...@apache.org
 wrote:

 I've created a Cocoon Spring Configurator 2.2.1 release, with the
 following artifacts up for a vote:

Re: [VOTE] Apache Cocoon Integration Test Framework 1.0.0

[Peter Hunsberger]

On Fri, Jun 8, 2012 at 5:16 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:

 I've created a Cocoon Integration Test Framework 1.0.0 release, with the
 following artifacts up for a vote:


Great, +1

Peter Hunsberger

Re: [VOTE] Apache Cocoon Configuration API 1.0.4

[Peter Hunsberger]

On Fri, Jun 8, 2012 at 5:55 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:

 I've created a Cocoon Configuration API 1.0.4 release, with the following
 artifacts up for a vote:

 +1 here also

Peter Hunsberger

Re: [VOTE] Apache Cocoon Reloading ClassLoader - Spring reloader 1.0.2

[Peter Hunsberger]

On Fri, Jun 8, 2012 at 6:05 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:

 I've created a Cocoon Reloading ClassLoader - Spring reloader 1.0.2
 release, with the following artifacts up for a vote:

 +1  again

Peter Hunsberger

Re: [VOTE] Apache Cocoon Reloading ClassLoader - Webapp Wrapper 1.0.2

[Peter Hunsberger]

On Fri, Jun 8, 2012 at 6:13 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:

 I've created a Cocoon Reloading ClassLoader - Webapp Wrapper 1.0.2
 release, with the following artifacts up for a vote:

 Took me a moment to figure out I hand't already voted on this...

+1

Peter Hunsberger

Re: [VOTE] Apache Cocoon parent 9

[Peter Hunsberger]

On Tue, Jun 5, 2012 at 4:59 AM, Francesco Chicchiriccò
ilgro...@apache.orgwrote:

  I've created a Cocoon parent 9 release, with the following artifacts up
 for a vote:

 Vote will be open for 72 hours.

 [X ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)


 +1, though I won't get much if any chance to validate things...

Re: [DISCUSS] Moving subprojects tools under /

[Peter Hunsberger]

Makes sense from what I understand of the issue. I think you should just
take a vote...

Peter Hunsberger


2012/4/9 Francesco Chicchiriccò ilgro...@apache.org

  HI all,
 a while ago [1] we discussed (and almost agreed) a new structure for our
 SVN, even though we haven't yet been able to agree on a schedule for
 performing all related activities.

 A part of [1] was about moving some modules, used by both C2.2 and C3, to
 an independent place.
 Recently I also proposed to apply some pending changes to some of such
 modules (cocoon-xml, cocoon-servlet-service, ...).

 Hence, I would like to move modules under [2], [3] and [4] under a new
 directory [5], create separate trunk, branches and tags subdirs, and modify
 POMs in order to make each module independent.

 Do you see any issue with this?

 TIA.
 Regards.

 [1]
 http://markmail.org/search/?q=subprojects#query:subprojects%20list%3Aorg.apache.cocoon.dev+page:1+mid:d3sinv7vo66pko4m+state:results
 [2] https://svn.apache.org/repos/asf/cocoon/trunk/subprojects/
 [3] https://svn.apache.org/repos/asf/cocoon/trunk/tools/
 [4]
 https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-serializers/cocoon-serializers-charsets/
 [5] https://svn.apache.org/repos/asf/cocoon/subprojects/

 --
 Francesco Chicchiriccò

 Apache Cocoon PMC and Apache Syncope PPMC 
 Memberhttp://people.apache.org/~ilgrosso/

Re: [DISCUSS] Moving subprojects tools under /

[Peter Hunsberger]

That's a good question, thought you already had that more-or-less from the
last time this got discussed?

If that's all you need at this point then +1 as far as I'm concerned...

Peter Hunsberger


On Mon, Apr 9, 2012 at 12:58 PM, Simone Tripodi simonetrip...@apache.orgwrote:

 @Francesco: no objections from my side, +1

 @Peter: why do we have the proceed a vote? Isn't lazy consensus enough
 for that situation? TIA!!!

 -Simo

 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/



 On Mon, Apr 9, 2012 at 4:43 PM, Peter Hunsberger
 peter.hunsber...@gmail.com wrote:
  Makes sense from what I understand of the issue. I think you should just
  take a vote...
 
  Peter Hunsberger
 
 
 
  2012/4/9 Francesco Chicchiriccò ilgro...@apache.org
 
  HI all,
  a while ago [1] we discussed (and almost agreed) a new structure for our
  SVN, even though we haven't yet been able to agree on a schedule for
  performing all related activities.
 
  A part of [1] was about moving some modules, used by both C2.2 and C3,
 to
  an independent place.
  Recently I also proposed to apply some pending changes to some of such
  modules (cocoon-xml, cocoon-servlet-service, ...).
 
  Hence, I would like to move modules under [2], [3] and [4] under a new
  directory [5], create separate trunk, branches and tags subdirs, and
 modify
  POMs in order to make each module independent.
 
  Do you see any issue with this?
 
  TIA.
  Regards.
 
  [1]
 
 http://markmail.org/search/?q=subprojects#query:subprojects%20list%3Aorg.apache.cocoon.dev+page:1+mid:d3sinv7vo66pko4m+state:results
  [2] https://svn.apache.org/repos/asf/cocoon/trunk/subprojects/
  [3] https://svn.apache.org/repos/asf/cocoon/trunk/tools/
  [4]
 
 https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-serializers/cocoon-serializers-charsets/
  [5] https://svn.apache.org/repos/asf/cocoon/subprojects/
 
  --
  Francesco Chicchiriccò
 
  Apache Cocoon PMC and Apache Syncope PPMC Member
  http://people.apache.org/~ilgrosso/
 
 

Re: Porting to current cocoon version

[Peter Hunsberger]

On Mon, Jan 16, 2012 at 9:39 AM, Wolfram eis...@philasearch.com wrote:

 It's a 10 year old app with more than 100 XSP's and specialized
 tag-librarys depending heavily on the XSP-concept.


Seems it might be a better fight for 2.1 than 3.0...  ??

Re: cocoon-sample home page

[Peter Hunsberger]

On Fri, Jan 6, 2012 at 9:36 AM, Antonio Gallardo agalla...@agssa.netwrote:

  Hi Peter,

 I was wondering if we should care much about it. I found a link with the
 result of the most common used browsers:

 http://html5test.com/results.html

 Perhaps we can move to HTML5 and use a bare minimum of it. :)


Don't think we can ignore older browsers.  Cocoon get's used inside a lot
of fairly large companies that  move fairly slowly on upgrades.  We
probably should always support at least one version back.  However, if
things are still usable (but just not pretty) I'm ok with that...

Re: cocoon-sample home page

[Peter Hunsberger]

I like the look, what's the non HTML 5 / CSS 3 fallback do or look like?

Peter Hunsberger


On Thu, Jan 5, 2012 at 2:01 PM, Robby Pelssers robby.pelss...@nxp.comwrote:

 Hi guys,

 ** **

 I took a stab at giving the sample home page a more modern look using htm5
 /css3.  I was wondering what you think about it so far and if I can commit
 my changes.

 ** **

 Robby

Re: Robby Pelssers as committer and PMC member

[Peter Hunsberger]

+ 1

On Dec 12, 2011 10:23 PM, David Crossley cross...@apache.org wrote:

Been around Cocoon for a long time. On dev around late 2004.
He seems very helpful and respectful.
Late 2009 he asked for Daisy edit rights (and immediately sent iCLA).
Has been keen on Cocoon-2.1, even in recent past.

He was mentioned here, back in July-2008 when we considered a
batch of new ones. IIRC then some people thought that we were
adding too many at once.

-David

Re: Compatibility Check Windows 7 Movares DIV-consultants

[Peter Hunsberger]

 On 28 September 2011 13:23, Peter Hunsberger peter.hunsber...@gmail.com 
 wrote:

 On Wed, Sep 28, 2011 at 1:14 AM, Jasha Joachimsthal
 j.joachimst...@onehippo.com wrote:
 
  Hi Jurgen,
  In short: Cocoon is not an application but a 
  framework http://cocoon.apache.org/1363_1_1.html
  Jasha Joachimsthal


  On 27 September 2011 18:00, Derksen JEC (Jurgen) 
  jurgen.derk...@movares.nl wrote:
 
  Dear Sir / Madam
 
  To understand the compatibility of
 
 
 
  RPC READER
 
  3.5
 

 Suspect this must be spam of some kind, as far as I know RPC Reader
 has nothing to do with Cocoon...?  Second time one of these has shown
 up, last time it was a different product.

 It looks like spam to me too, but we do have an RPC reader: 
 http://cocoon.apache.org/2.1/userdocs/optional/axisrpc-reader.html

Sorta makes sense but where does the version 3..5 come from?  I think
last time the connection with Cocoon was a bit more obvious but still
a stretch.  I'd still say we ignore them...?

Re: Compatibility Check Windows 7 Movares DIV-consultants

[Peter Hunsberger]

On Wed, Sep 28, 2011 at 1:14 AM, Jasha Joachimsthal
j.joachimst...@onehippo.com wrote:

 Hi Jurgen,
 In short: Cocoon is not an application but a 
 framework http://cocoon.apache.org/1363_1_1.html
 Jasha Joachimsthal


 On 27 September 2011 18:00, Derksen JEC (Jurgen) jurgen.derk...@movares.nl 
 wrote:

 Dear Sir / Madam

 To understand the compatibility of



 RPC READER

 3.5


Suspect this must be spam of some kind, as far as I know RPC Reader
has nothing to do with Cocoon...?  Second time one of these has show
up, last time it was a different product.

Re: [VOTE] Require Java 1.6 for Cocoon3

[Peter Hunsberger]

On Mon, Sep 19, 2011 at 4:03 PM, Nathaniel, Alfred
alfred.nathan...@six-group.com wrote:


 Therefore I’ call the vote on Code Modification [3]:



 +1 = Yes, Cocoon3 shall require Java 1.6

 -1 = No, Cocoon3 must remain usable with Java 1.5 (with justification for the 
 veto)


+1

Re: Reuse of pipelines in java

[Peter Hunsberger]

[snip...]

 Now everything is working fine for the first time I use the pipeline.
 However the second time it is not working anymore. I am using
 this.addEventToQueue(event) in the transformer to add the events to the
 queue. However the second time I am calling the transformer I get
 org.apache.cocoon.pipeline.ProcessingException: Error during writing
 output elements.

 Whiles debug I found that the summaryTransformer is adding correctly the
 StartDocument/EndDocument however in the second call the
 XMLSerializer is getting in initiatePullProcessing() as first event a
 START_DOCUMENT (which is expected), however
 resulting in
 javax.xml.stream.XMLStreamException: Can not output XML declaration,
 after other output has already been done.

 I debugged  summaryTransformer.setup(...) and I figured that
 StAXConsumer consumer = this.getConsumer();
 the first time is null, but the second time is the old consumer. Can
 it be related?


Don't know about C3, but certainly in C2 that  is an issue.  Don't
recall how to fix it but I think you are looking at the right issue.
You've either got to clean up after you are done or reset things
properly when you use it again.  You've got a setup() method to work
with so that seems the place to start, since adding a new finis() (or
whatever) method to cleanup after you are done would obviously have
much broader implications...

Re: Fwd: Cocoon-trunk - Build # 49 - Unstable

[Peter Hunsberger]

 AFAIK, there should be no issue in making profiling results volatile, but I 
 am really not familiar with profiling internals: who knows better?


One could argue that the profiling should match up against the regular
release just so that we know the results correspond.  As long as
everyone know what is going on I don't see a big issue leaving it the
way it is, but that means documenting it in an obvious way some how.
Any ideas?

Re: [C3] Java version 1.6

[Peter Hunsberger]

 Hi all guys!!!
 My question is instead: is there any advantage we can get by targeting
 Cocoon to Java6? Is there any specific Java6 APIs we need to improve

[...]

 some of my favorite Java 6 features that Cocoon codebase could profit from:

 * Collections Framework Enhancements and ServiceLoader [1]: Cocoon source 
 code makes large use of collections, thus usage of these features can 
 improve quality and performance

 * Internationalization Enhancements [2]: especially now that we should start 
 working on the new i18n transformer [3]

 * JMX [4] and Management [5] enhancements: will we ever put this great 
 Cocoon 3 stuff in production?

 Last but not least, Cocoon 3 depends on many other frameworks and libraries 
 that will eventually require Java 6 (and 7, soon) capabilities.

 Regards.

 That's a good list and some fine reasons to switch to Java 6.

[...]


 C3 is still set to 1.5 as source and target version.

 Java5 is end of life since almost two years now.



 Is there any good reason not to go 1.6?

 Not that I know, so +1 for me to move to 1.6.


We seem to have this discussion every few years.  There's always
people that can't upgrade.  Personally I think it's time to do it and
I wish we had done it long ago.  With C3 in particular, people should
have no dependencies in production since it is still officially Beta.
Even if they do, they can stay on a previous version after all, if it
is good enough to use at all why can't they stick with what they are
using?  Unless someone can come up with a reason not to I'd say it's
time to start a vote.

Peter Hunsberger

Re: [proposal] cocoonstuff.org

[Peter Hunsberger]

 Hmm... needing additional documentation is often the sign of some sort of 
 problem. In this case, we may simply have too many modules. Why don't we have 
 a cocoon-core module, so that people can know where to look at to 
 understand what Cocoon is about? And this core module should not only be the 
 cocoon-pipeline module, but should also include cocoon-util (3 classes!), 
 cocoon-sax, cocoon-sitemap, cocoon-controller (3 classes again) and even 
 cocoon-stax (Stax is provided in JDK 1.6).


This sounds like a good idea, +1

 Also, along with providing more meat in the core, let's be opinionated and 
 clearly say what Cocoon is about. For 2.2, the website says Apache Cocoon is 
 a Spring-based framework (since version 2.2 of Cocoon) built around the 
 concepts of separation of concerns and component-based development.

 Er... and what does this mean for a newcomer, particularly when Spring 
 already has this huge amount of components and whose large number of 
 interfaces and abstract classes could well be confused with separation of 
 concerns ?

 What about a probably restrictive but clearer Cocoon is a versatile pipeline 
 processing engine, particularly suited for XML processing and multi-format 
 document publication, but also capable of processing binary content such as 
 images. It provides integration modules with popular frameworks like Spring, 
 Wicket and JAX-RS?


Maybe not the best sentence in the world, but I like the intent here.
Again I'd say +1

Re: vitality of Cocoon: a good basket to put eggs in?

[Peter Hunsberger]

On Mon, Jul 11, 2011 at 10:10 AM, Lars Huttar lars_hut...@sil.org wrote:


 I guess my main question is, how reliable is the Cocoon dev team's
 commitment to Cocoon 3.0? How likely are we to see a release version in
 the next 6 months to a year? Will there be bug-fix releases, or will 3.0
 be dropped in favor of another rewrite?


Hi Lars,  a couple of thoughts.  I think  C2.1 is pretty stable and as
a result doesn't see a lot of activity.  It is however still widely
used.  Personally, I hope to start a C3 project some time in the next
year or so.  Like any Open Source project it's as active and safe as
the participants make it.  If you see it as being attractive you
should check it out and see to what extent it meets your needs and if
it doesn't how much work you think it would take to get it where it
needs to be.  I suspect that for the XML pipeline world C3 is still
more cost / time effective than a lot of other approaches. Also, C3
seems to be slowly attracting more attention, I don't think it would
take much to tip it over to being a pretty active project.  It
certainly isn't going anywhere!

Re: c3 anf i18n

[Peter Hunsberger]

 However I guess c3 only for is easiest for
 everyone more familiar with c3. If we have a rewrite I can create the
 c2.2 wrapper quite easy so I say do the c3 and when finish I do the
 rest. ;)

 Basically:

 AbstractI18n = spring based transformer no deps to either c3/2.2

 - c3I18n extends AbstractI18n implements c3CorrespondingInterfaces
 - c2I18n extends AbstractI18n implements c2CorrespondingInterfaces


Sounds like a plan to me...

Re: c3 anf i18n

[Peter Hunsberger]

On Wed, Apr 27, 2011 at 4:59 AM, Thorsten Scherler scher...@gmail.com wrote:

 On Wed, 2011-04-27 at 09:45 +0200, Francesco Chicchiriccò wrote:
  On 27/04/2011 07:26, Francesco Chicchiriccò wrote:
   On 26/04/2011 19:04, Thorsten Scherler wrote:
   Hi all,
  
   I could not find anything related to i18n/locale in c3.
  
   Did I not look hard enough or did we not have implemented in that
   direction yet?
  
   You're right, there seems to be nothing in C3 sources related to i18n.
  
   If so should we look into porting the old i18n transformer?
  
   That sounds interesting: how much complex do you see this task? Can
   you take care of it? ;-)
 
  I have created the issue COCOON3-64 [1] for this: who would like to
  catch it?
 
  [1] https://issues.apache.org/jira/browse/COCOON3-64

 Actually it should not that be hard to port the i18n. IMO that is a MUST
 HAVE featured and was very surprised to not find anything.


I'd agree, if we are going to use C3 in the future we will also need
this feature.  I like your option of having a single Spring based
transformer that works for both C2.2 and C3 but don't know if it is
any simpler to do?  I'd go with whatever is easiest to do at this
point...

Re: [C3] Releasing alpha-3 (and beyond)?

[Peter Hunsberger]

2011/4/15 Francesco Chicchiriccò ilgro...@apache.org

 Having said that, and taking into account the need that still seems to be 
 around of having a stable Cocoon 3 release as soon as possible, what do you 
 think if we close COCOON3-58 and do a fresh alpha-3 release?

+1


 Moreover, only 8 issues (including the above-mentioned COCOON3-58) are still 
 open [4], so we could catch the chance to try to fix them and do a clamorous 
 beta release! What do you think about this?


+42 if you can find the people / time to pull it off.  I know I won't
have the time to contribute for the next couple of months...

Re: [c3] Image reader, does c3 have one?

[Peter Hunsberger]

On Thu, Mar 31, 2011 at 5:39 AM, Thorsten Scherler thors...@apache.org wrote:

 On Thu, 2011-03-31 at 12:01 +0200, Francesco Chicchiriccò wrote:
 ...
  
 
  Nice idea: such checklist can start from some concrete examples and grow
  up to a more general approach in migrating from 2.X to 3. Again: do you
  have some of such concrete examples? ;-)

 Not really yet but I guess I will run into that challenge soonish, if
 somebody can share her experience in that field I would more then
 welcome that.


Good to see someone working with C3 and that it is getting some
attention.  I hope to convince some people here that we should look at
it, but that will take a long time :-(

In any case, it seems you already have your first concrete (albeit
simple) example.  Just document what was required to move the image
reader over as the first example in the How to migrate Cocoon 2.2
components to Cocoon 3.0 section of the documentation and web site
(yeah, I know, there needs to be a place to put the examples first,
but that is left as an exercise for the reader)...

Re: [vote] Release Cocoon JNet 1.2.0, Cocoon Maven Plugin 1.0.0 Cocoon Maven Site Skin 1.0.0

[Peter Hunsberger]

On Tue, Jan 18, 2011 at 11:22 AM, Reinhard Pötz reinh...@apache.org wrote:

 I created release artifacts for following modules:

 This majority vote stays open for at least 72 hours. Please cast your
 votes. Thanks.


Won't be able to look at these until I get home tonight, but +1 

--
Peter Hunsberger

Re: Preparing releases: cocoon-maven-plugin, cocoon-jnet, cocoon-thien-maven-site-skin

[Peter Hunsberger]

On Tue, Jan 4, 2011 at 1:51 AM, Reinhard Pötz reinh...@apache.org wrote:
 On 01/04/2011 03:38 AM, Peter Hunsberger wrote:

 On Mon, Jan 3, 2011 at 5:36 PM, Reinhard Pötzreinh...@apache.org  wrote:



 +1  - I'm not completely sure about whether 1.0 is completely correct
 in some cases, but OTOH I don't think it's worth worrying about...

 Neither am I but changing any contracts without some deprecation phase in
 the cocoon-maven-plugin or the site-skin wouldn't be very helpful to the
 existing users. And, there's always the chance of a 2.x release ;-)

Hah.  I won't say, not in my life time, but I'm sure not going to
hold my breath

-- 
Peter Hunsberger

Re: Preparing releases: cocoon-maven-plugin, cocoon-jnet, cocoon-thien-maven-site-skin

[Peter Hunsberger]

On Mon, Jan 3, 2011 at 5:36 PM, Reinhard Pötz reinh...@apache.org wrote:

 For the last couple of months I haven't been following Cocoon development 
 closely, but I want to work again on a couple of things related to Cocoon.

 First I'd like to start with the release of some long overdue modules:

  * cocoon-maven-plugin (plus cocoon-rcl-*):

   It has been in use for quite a while, hence I'd like to
   release it as 1.0.0

  * cocoon-jnet

   Since it's only a bug fix release that can be used as a
   drop-in replacement for 1.1.0, I suggest releasing it as
   1.1.1

  * cocoon-thien-maven-site-skin

   It has been in use for quite a while, hence I'd like to
   release it as 1.0.0

 Since the Cocoon Maven plugin and the cocoon-rcl-* modules are used in Cocoon 
 2 and 3 I'd like to move them to a more general place. For that purpose I 
 suggest moving them to cocoon/trunk/subprojects.

 WDYT?


+1  - I'm not completely sure about whether 1.0 is completely correct
in some cases, but OTOH I don't think it's worth worrying about...

--
Peter Hunsberger

Re: State of Cocoon Builds in Gump

[Peter Hunsberger]

On Tue, Jul 27, 2010 at 1:48 AM, Stefan Bodewig bode...@apache.org wrote:
 Hi,

 we've been building a large part of Cocoon 3 and almost everything Lenya
 and Coccoon3 need of Cocoon 2.2 for weeks now.

[...]

 The one remaining failure I can see is in flowscript-impl and this is
 due to a backwards incompatible change to the continuation API in rhino
 between 1.7R1 and 1.7R2 AFAICT.  I guess you already know about that.

 Before I start to fiddle with Gump's config so that Cocoon does not see
 rhino's trunk I wanted to ask whether there were any plans to migrate to
 the newer continuation API (in which case I wouldn't need to hide
 rhino).


Stefan, many thanks for taking this on.  I don't expect you will get
much response, all of Cocoon seems quite these days.  I think it just
mostly works so very few people see much reason to touch the code
base

-- 
Peter Hunsberger

Re: [2.1] Is Cocoon 2.1.x officially dead ?

[Peter Hunsberger]

2010/3/22 Cédric Damioli cedric.dami...@anyware-services.com:

 So I'm wondering if someone around here was still willing to
 maintain the Cocoon-2.1 branch ? If not, I volunteer to do the
 job, as this branch is important for us, and I don't want to have
 to fork it in our own repository. Otherwise, do you have other
 solutions for me ?

 BTW, is there still many Cocoon-2.1 users around here ?


Not sure who might be able to do a commit, in theory I could, but
we're no where close to current on 2.1 and I really don't have time to
bring up a current version and test.  Have you submitted the patch?
If it's a trivial I'm pretty sure someone should be able to look at
it, and maybe even if it's big.

We are using 2.1, but we're still on 2.1.8.

-- 
Peter Hunsberger

Re: [vote] Release Cocoon 3.0.0-alpha-2

[Peter Hunsberger]

On Mon, Jan 4, 2010 at 9:36 AM, Reinhard Pötz reinh...@apache.org wrote:
 I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2.
 Since it has been more than a year since alpha-1 was released, there are
 many improvements and enhancements:

[...]

 This majority vote stays open for at least 72 hours. Please cast your votes!


+1

-- 
Peter Hunsberger

Re: [vote] Simone Tripodi as new Cocoon committer

[Peter Hunsberger]

On Sun, Dec 13, 2009 at 7:58 AM, Reinhard Pötz reinh...@apache.org wrote:

 I propose Simone Tripodi as a new Cocoon committer and PMC member.


+1 !
-- 
Peter Hunsberger

Re: Cocoon and Sling

[Peter Hunsberger]

2009/4/7 Juan José Vázquez Delgado juanjo.vazq...@gmail.com

 Hi all,

 As discussed in a previous thread [1], some people think it would be a
 good idea to take advantage of Cocoon´s pipelining and Sling request
 processing capabilities working together.

 We (Sling team) have implemented a first approach to this cooperation
 using Cocoon 3 pipeline engine [2] and the W3C XProc recomendation [3]
 in order to specify the pipelines to be performed. At least in the
 beginning, the Cocoon sitemap concept has been discarded because of
 quite overlapping between this one and Sling resource resolution.

 The code is available here [4] and details about how it works here [5].

 From now on, I wonder whether Sling is the right place to keep on
 implementing W3C XProc or it´s Cocoon instead. Is this stuff
 interesting to Cocoon community and team?.


This is sort of  interesting, but I can't really say I'd personally
want to use XProc with Cocoon 3.0.  Many years ago I proposed
implementing the Cocoon sitemap using XSLT (essentially combining the
current sitemap with the flow processor all in one spot and one
language); IMO XProc looks like a rather poor reimplementation of
XSLT, almost as complex, with a quarter of the capabilities?  Some
days I wonder if the W3C hasn't gotten just a little too carried away
with some of these standards?

If the Cocoon project was to take on an XProc implementation I'd
really want to see it a completely optional implementation for Cocoon
3.0, it's not the kind of complexity I want in the base code.
However, I'm not sure pluggable sitemap processors are the kind of
complexity I'd want to see either...

--
Peter Hunsberger

Re: New Spring Maintenance policy

[Peter Hunsberger]

On Wed, Sep 24, 2008 at 10:10 AM, Antonio Gallardo [EMAIL PROTECTED] wrote:
 Hi,

 There is a worst case scenario now: What if they don't collect enough
 money from subscriptions and do the next step: remove the 3 months
 window or worse go full closed source?

 I think changing the rules is not fair at all. That should rings our
 bells. Most important, our own user base will suffer. Any of our user
 now have to have in the pocket 16k yearly in order to deploy a cocoon
 2.2 based application. That does not sounds good at all.

 There are many ways to describe the spirit of the apache community, but
 there is one that I like more than all the others: 'we care about people
 more than we care about code'. We have to do something.


I'm not convinced that anything needs to be done at the moment.  I
don't like what they've done but I also don't think they are stupid,
they are not going to piss off their entire user base.  I'd suggest we
simply continue to watch what happens for  the next three months (at
least) before we conclude that any action is necessary.  If at that
point we see real problems it won't be too late, we should still
have a stable base that can continue to work for another 6 months or
so.

At this point maybe the best thing to do is scope out possible
directions to head if this does indeed turn out to be an issue?

-- 
Peter Hunsberger

Re: New Spring Maintenance policy

[Peter Hunsberger]

On Tue, Sep 23, 2008 at 3:35 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:
 On 22.09.2008 21:09, Antonio Gallardo wrote:

 Perhaps an old news for some, but I would like to know how you guys
 think this affects cocoon:

 http://www.theserverside.com/news/thread.tss?thread_id=50727

 Are we going to take some actions on that?

 IMO it's a shame, I'm really disappointed. Not even JBoss did something
 similar to that. I wonder if they can keep this up.

 The source is supposed to be available though meaning we aren't forced to
 take any actions. Also it might be enough to just use the available
 releases. If somebody has more recent releases due to enterprise service
 support he will be free to use those.

 Joerg


Don't think the impact is anything major:

---

What the maintenance policy will mean to you:

For the open source community: If you are happy to track the latest
major release of Spring (e.g. 3.0, 3.1 or 4.0), all fixes go into the
next major release. You get all the latest features and up-to-date
fixes--what you would expect from any healthy open source project.

For enterprise production users: If you are an enterprise customer
that cannot or will not regularly upgrade to the latest release--that
is, your use of open source differs from normal open source culture of
following the latest release--you can subscribe to our SpringSource
Enterprise products. By doing this you help to ensure that innovation
continues to be available to the community. Given that such customers
have little tolerance for risk, running open source in the core of
their applications without support makes no sense anyway.

As the number of versions of Spring used in production grows, it is
impossible for us to provide free maintenance for multiple releases
and perform backports of issues. Doing so would unfairly subsidize
conservative customers who want to remain on a previous version, at
the cost of the open source community.

SpringSource contributes a huge and growing amount of open source to
the community. Check out the around one hundred releases this year
across the many open source projects we are involved in. Providing a
clear maintenance policy will ensure that we can continue to do so.

Rod Johnson, Spring Founder  CEO, SpringSource
--

-- 
Peter Hunsberger

Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI

[Peter Hunsberger]

On Mon, Aug 25, 2008 at 7:41 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:
 On 21.08.2008 23:53, Reinhard Pötz wrote:


 These namespaces are without a version number.

 Since I don't see how version numbers could help, I propose

  http://apache.org/cocoon/sitemap
  http://apache.org/cocoon/servlet
  http://apache.org/cocoon/controller

 I know I'm rather late ...

 Don't these version numbers just help in the same way as versioned jars
 help? It's possible to signal additional functionality or incompatibilities.
 Just look at the Spring framework.


Sure, but you can always add them as you need them:

eg. http://apache.org/cocoon/sitemap-3.1

can come along if it is needed.

-- 
Peter Hunsberger

Re: [vote] Cocoon 3: Versioning, SVN, Maven, namespaces, issue tracking and CI

[Peter Hunsberger]

On Thu, Aug 21, 2008 at 4:53 PM, Reinhard Pötz [EMAIL PROTECTED] wrote:

 After having already discussed the details, let's make a formal decision
 about versioning, SVN, Maven, namespaces issue tracking and CI for Cocoon 3.


 +1

-- 
Peter Hunsberger

Re: Renaming Corona to Cocoon 3.0 and infrastructure [version 2]

[Peter Hunsberger]

On Wed, Aug 20, 2008 at 7:44 AM, Reinhard Pötz [EMAIL PROTECTED] wrote:

 After our recent discussions, here is my reworked proposal:

snipGood looking proposal/snip

 Or do I need a vote before? If so I will start the voting process asap.
 Any opinions?


I think you should run a vote, if only for completeness.  I don't see
anything controversial (other than the already discussed 3.0 issue) so
I'd imagine it should be straight forward enough.

-- 
Peter Hunsberger

Re: [vote] Cocoon 3.0

[Peter Hunsberger]

On Wed, Aug 6, 2008 at 6:19 AM, Reinhard Pötz [EMAIL PROTECTED] wrote:

 Following the result of our recent discussion about the future of Corona, I
  propose Corona to become Cocoon 3.


+1


Seems a little weird but I certainly don't have any better alternatives.

-- 
Peter Hunsberger

Re: [vote] Java 1.5 as minimal requirement for trunk

[Peter Hunsberger]

On Tue, Aug 5, 2008 at 8:07 AM, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
 Hello,

 As discussed in thread Cocoon-jms-sample requires Java = 1.5[1] there are
 more and more problems with keeping Java 1.4 compatibility in trunk.

 After a while it turned out that everybody agrees on the need for dropping
 Java 1.4 compatibility and in that case, switching to Java 1.5 as minimal
 required version seems to be the best solution.

 In order to do that, we need a formal vote that I'm calling now.


+1
-- 
Peter Hunsberger

Re: [vote] David Legg as new Cocoon committer

[Peter Hunsberger]

On Mon, Aug 4, 2008 at 6:46 AM, Grzegorz Kossakowski [EMAIL PROTECTED]wrote:

 Dear community,

 I would like to propose David Legg as a new Cocoon committer and PMC
 Member.


+1

-- 
Peter Hunsberger

Re: Cocoon-jms-sample requires Java = 1.5

[Peter Hunsberger]

On Wed, Jul 30, 2008 at 8:47 AM, Felix Knecht [EMAIL PROTECTED] wrote:


  Then I think the solution is rather clear: we need to migrate to 1.5. If
 Sun is not supporting Java 1.4 then I don't want to support it as well in
 our _trunk_.

 People that need to stick to Java 1.4 still have a choice: We have
 released 2.2 that works with Java 1.4.

 Therefore I propose to switch to 1.5 and focus on getting real work done.

  But when switching the version why don't switch to 1.6 (I think it's on
 MacOSX now also available). Otherwise we have to switch again in 1 year or
 so (see http://java.sun.com/products/archive/eol.policy.html). EOL for 1.5
 is  October 2009.

 WDYT?



There might be people who can't run 1.6 yet.  In particular we know some
people are still stuck on old versions of Websphere and similar.  We've had
this discussion before and I'm on the side that we can't support legacy code
forever.  However, I do feel that a jump to 1.6 might be a bit premature. We
just had this discussion internally over the last couple of weeks and we
found several 1.6 incompatibilities forcing us to stay on 1.5 for the
moment.  If we do have a need to move to 1.6 in the future it shouldn't be
that much of an issue to change at that point?

-- 
Peter Hunsberger

Re: Find a new name for Corona

[Peter Hunsberger]

On Wed, Jul 30, 2008 at 10:53 AM, Bertrand Delacretaz 
[EMAIL PROTECTED] wrote:

 On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz [EMAIL PROTECTED]
 wrote:
  :-( that's bad. Any other suggestions?

 I still think that Cocoon 3.0 could be the name, if people are going
 to invest a significant effort in what's Corona today. For Sling we'd
 like to use the pipelines implementation, so some of us Sling folks
 are planning to contribute and help maintain that. I am not interested
 in the other parts at the moment.


I think that at the moment Corona is far too much of an experiment to be
considered 3.0.  Parts of it or all may become 3.0 but who knows?

Almost any name we choose will overlap with an existing product to some
extent.  If it's not trademarked I'm ok with the overlap.  As such I think
Silk is still one of the best options I've seen suggested..

-- 
Peter Hunsberger

Re: [vote] Luca Morandini as new Cocoon committer

[Peter Hunsberger]

On Tue, Jul 29, 2008 at 12:29 AM, David Crossley [EMAIL PROTECTED]wrote:

 I would like to propose Luca Morandini as a new Cocoon committer
 and PMC member.


+1

-- 
Peter Hunsberger

Re: [vote] Thorsten Scherler as new Cocoon committer

[Peter Hunsberger]

On Tue, Jul 29, 2008 at 1:27 AM, David Crossley [EMAIL PROTECTED] wrote:

 I propose Thorsten Scherler as a new Cocoon committer
 and PMC member.


+1

-- 
Peter Hunsberger

Re: [vote] Andreas Hartmann as new Cocoon committer

[Peter Hunsberger]

On Tue, Jul 29, 2008 at 1:27 AM, David Crossley [EMAIL PROTECTED] wrote:

 I propose Andreas Hartmann as a new Cocoon committer
 and PMC member.


+1

-- 
Peter Hunsberger

Re: [Vote] Jasha Joachimsthal as new Cocoon committer

[Peter Hunsberger]

On Tue, Jul 29, 2008 at 4:18 AM, Andrew Savory [EMAIL PROTECTED] wrote:

 Hi,

 It's my pleasure to propose Jasha Joachimsthal as a new committer on
 the Apache Cocoon project.


+1

-- 
Peter Hunsberger

Re: [vote] Steven Dolg as committer

[Peter Hunsberger]

On Mon, Jul 28, 2008 at 10:26 AM, Reinhard Pötz [EMAIL PROTECTED] wrote:
 Dear community,

 it's a great honor for me to propose Steven Dolg as a committer.


+1

-- 
Peter Hunsberger

Re: Custom Xpath Selector

[Peter Hunsberger]

On Wed, Jul 23, 2008 at 2:04 AM, Richard McKenzie
[EMAIL PROTECTED] wrote:
 Cheers Peter

 Thanks for the advice, we are trying to avoid using flow script if
 possible. I just thought I'd post the question in case anybody had
 created a selector which did something similar, after decompiling all
 the cocoon selectors I suspected that it was not possible to do
 elegantly.


Personally, I'd prefer to use flow script over a selector any day; the
code's much easier to maintain and understand...

---
Peter Hunsberger

Re: Custom Xpath Selector

[Peter Hunsberger]

On Tue, Jul 22, 2008 at 10:04 AM, Richard McKenzie
[EMAIL PROTECTED] wrote:

snip/

 Perhaps I am barking up the wrong tree and a selector is not the best
 solution, it would be nice to be able to do different things bassed on the
 contents of the xml passed through a pipeline


If you have complicated use cases I suspect you're going to want to
use a Java transformer to inspect the XML in the pipeline and have it
make the decisions on what should be done.  This can be done from flow
script by firing off the pipeline at that point and then inspecting
some returned result.  I'm not sure about 2.1 but in 2.0 this looks
like

 var sourceURI = run/_checkXML/;
var destinationURI = xmodule:request-attr:checkXMLresult;

var resolver = null;
var destination = null;
var output = null;
try {
resolver = cocoon.getComponent(
Packages.org.apache.cocoon.environment.SourceResolver.ROLE );
destination = resolver.resolveURI( destinationURI );
output = destination.getOutputStream();
cocoon.processPipelineTo( sourceURI, {}, output );
output.close();

if ( cocoon.request.getAttribute( checkXMLresult ) == ...) {
  //see what happened in the XML checking pipeline
   // Do whatever should be done based on the results...

return true;
}
}
finally {
if (destination != null) {
resolver.release( destination );
}
cocoon.releaseComponent( resolver );
}
-- 
Peter Hunsberger

Re: [Corona] PIpeline API

[Peter Hunsberger]

On Thu, Jul 17, 2008 at 9:22 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote:
 Andreas Hartmann wrote:


 I don't think that the calling code has to know the actual components,
 but rather the environment-specific interfaces of the components. It
 only makes sense to pass an environment to a pipeline component if the
 component is designed to use this environment.


Yeah, but if you've got really generic code this can be hard to figure out

 Agreed.

 Maybe I can try to come

 up with a more generic example:

 public interface WebappPipelineComponent extends PipelineComponent {
  void setRequest(Request request);
 }

 Client code inside a web application:

 public void parameterizeComponents(Request req, Pipeline pipeline) {
  for (Iterator i = pipeline.getComponents().iterator(); … ) {
PipelineComponent c = (PipelineComponent) i.next();
if (c instanceof WebappPipelineComponent) {
  WebappPipelineComponent wpc = (…) c;
  wpc.setRequest(req);
}
  }
 }

 The pipeline is executed in a specific environment. The actual
 pipeline object itself is oblivious of the environment information, but
 the pipeline components are directly dependent on the environment.

 Hmm, yes this would work, but :) this would make it harder to have a
 reusable pipeline implementation that frees my application from passing the
 information to the components.
 Currently the app creates a map, passed it to the pipeline implementation
 and this implementation passes the map on to the components.
 With the approach above, I would need a custom pipeline implementation to do
 this. Furthermore there might be a lot of marker interfaces to test.
 Actually I'm not sure which approach is nicer :)

I keep wondering if this perhaps an Adapter type pattern?  You've
potentially got a lot of different types of applications that each
could have different requirements for setting up pipelines.
Similarly, you've potentially got a lot of different types of
pipelines (in particular since Corona isn't just SAX).   So what you
do is define some adapter that gets passed around and leave it up to
the adapter to manage the use case specifics,

Adaper adp = new MyUseCaseAdapter();
adp.setRequest(  req );
   .
   .
   .
  for (Iterator i = pipeline.getComponents().iterator(); … ) {
PipelineComponent c = (PipelineComponent) i.next();
  c.setup(adp);
}

And then in the component:

Object myConfigParam = adp.getParam( NAME );

has no knowledge of how the param (or params) was passed into the adapter.

The app is responsible for setting up the adapter with app specific
data and the adapter has multiple standard methods for allowing this
(and can be extended for new use cases).  The adapter is responsible
for passing it into the components in some more standardized way.
Think of the adapter as a data class with extra logic for converting
use case specific data into generic data.
As such, the adapter can also be responsible for more than
initialization data, it can become the use case specific way of
communicating between the app and the components.  Instead of using
marker interfaces to define the use case specific responsibilities you
end up with the adapter having multiple methods for different use
cases as needed.

-- 
Peter Hunsberger

Re: [Corona] PIpeline API

[Peter Hunsberger]

On Thu, Jul 17, 2008 at 11:22 AM, Andreas Hartmann [EMAIL PROTECTED] wrote:
 Hi Peter,

 Peter Hunsberger schrieb:

 On Thu, Jul 17, 2008 at 9:22 AM, Carsten Ziegeler [EMAIL PROTECTED]
 wrote:

 Andreas Hartmann wrote:

 I don't think that the calling code has to know the actual components,
 but rather the environment-specific interfaces of the components. It
 only makes sense to pass an environment to a pipeline component if the
 component is designed to use this environment.

 Yeah, but if you've got really generic code this can be hard to figure
 out

 IMO there are two types of components which have to be generic:

 * the pipeline implementation
 * multi-purpose pipeline components

 The application itself is not generic, it knows which environment
 information to provide to the application-specific components.

Well yes and no.  In our case the application is generic, but that's
not the issue;  you're right that the application knows what to pass
in to the adapter (for any given application), the point is that
multiple applications can exist and all use the same adapter but pass
in different things.  For example, a servlet may have a Map of request
parameters but a CLI app may have a Array of command line parameters.

 For
 multi-purpose pipeline components (e.g., an event logger), an adapter class
 could be used (e.g., to pass an application-specific output stream to log
 the events to).



Yup...

[…]

 I keep wondering if this perhaps an Adapter type pattern?  You've
 potentially got a lot of different types of applications that each
 could have different requirements for setting up pipelines.
 Similarly, you've potentially got a lot of different types of
 pipelines (in particular since Corona isn't just SAX).   So what you
 do is define some adapter that gets passed around and leave it up to
 the adapter to manage the use case specifics,

 Adaper adp = new MyUseCaseAdapter();
 adp.setRequest(  req );
   .
   .
   .
  for (Iterator i = pipeline.getComponents().iterator(); … ) {
PipelineComponent c = (PipelineComponent) i.next();
  c.setup(adp);
}

 I'm not quite sure what c.setup() would look like. Perhaps like this?

 class XsltTransformer {
  public void setup(Adapter adp) {
setXsltParams(adp.getXsltParams());
  }
 }

 In this case, the Adapter implementation would have to provide methods for
 various types of pipeline components …

 And then in the component:

 Object myConfigParam = adp.getParam( NAME );

 But wouldn't this require a contract between the application and the
 components based on parameter names? I thought this is what we wanted to
 avoid, otherwise we could just use the Map suggested by Carsten …

Well yes, but that's a loose example.  I'd rather have specific setter
/ getters that the adapter knows how to handle.  But if someone (eg.
Carsten) has a pipelines that use maps with named parameters that's
fine,  one should be able to write (or extend) a generic adapter to
handle the specific expectations of a given pipeline.


 But I guess I'm misunderstanding something :)

 has no knowledge of how the param (or params) was passed into the adapter.

 The app is responsible for setting up the adapter with app specific
 data and the adapter has multiple standard methods for allowing this
 (and can be extended for new use cases).  The adapter is responsible
 for passing it into the components in some more standardized way.
 Think of the adapter as a data class with extra logic for converting
 use case specific data into generic data.

 Hmm, what does the term generic data refer to? Would you mind giving an
 example? TIA!

In this case it would be up to the pipeline.  Like in the example
above, where someone  has a pipeline expecting a Map.


 As such, the adapter can also be responsible for more than
 initialization data, it can become the use case specific way of
 communicating between the app and the components.  Instead of using
 marker interfaces to define the use case specific responsibilities you
 end up with the adapter having multiple methods for different use
 cases as needed.

 As I understand it, one would have to provide application-specific adapters
 to environmentalize multi-purpose components; I don't see a way how this
 could be handled by a single adapter class for the whole application …

You do end up extending adapters for specific applications, but in
general you don't need a lot of them for any given application.
Instead of adding new adapters for new use cases you end up adding
methods to the adapters for the new use cases. The main reason to add
new adapters is to reduce unnecessary work; you don't want the adapter
converting  data into generic formats if it's not needed, but most of
the time this can be avoided by having the getters do the conversion
and not the setters.

 I'll think a bit more about this, sorry if my remarks are rubbish :)


This is such an abstract discussion I don't see how any of this could
be rubbish! Go back to your

Re: [Corona] PIpeline API

[Peter Hunsberger]

On Thu, Jul 17, 2008 at 5:27 PM, Steven Dolg [EMAIL PROTECTED] wrote:
 Peter Hunsberger schrieb:


snip/

 AFAIK an adapter is used to adapt one interface or class to another.
 So what does the adapter adapt - what's the adapted class/interface?

Well given that the entire discussion is abstract that's sort of hard
to answer.  However, I sort of covered a bit of this, if Corona is
going to support non SAX pipelines they you've to assume source and
sinks that you'll want to mix and match.  In addition you can assume
multiple  types of applications, for example Servlets and Command Line
(and I'm sure others).  Whenever I see three distinct orthogonal class
dimensions like this it seems that you end up with a multitude of
constructors or initialization methods each taking a set of different
of classes. I'm basically proposing that instead we end up with a
single set of Adapter classes instead.  The exterior classes (being
adapted from)  come from  the application specific environments and
may be Servlet context, pipeline config, command line params or even
the output of other pipelines (I've got a secret agenda here).  The
interior classes (those we adapting to) are yet to be defined but are
basically going to configure the pipeline components.



 Since c.setup(adp) belongs to the general PipelineComponent, the
 MyUseCaseAdapter has to be passed as Adapter (exactly as described above).
 So this way providing parameters might become easier, but IMO reading
 parameters (inside the component) is just the same as using a map (also
 exactly as described above).
 Except you want to go for a downcast... ;-)

Umm no,  I'm trying to move away from something like a Map, the
example was just  because Carsten was already using a Map and there
shoudl be no reason that the Adapter shouldn't make it easy for him to
retain most of his existing code.


 Furthermore MyUseCaseAdapter would have to account for every possible
 configuration requirement of every component that might be in the pipeline.
 This could be become quite messy if the pipeline is assembled dynamically.


nto sure how you figure this?  If there is a mess the adapter makes it
easier to handle, not worse, since you;'re basically converting to a
canonical form instead of having something like N X M transforms.


 The other thing I'm sure about:
 Why would I want to iterate over the pipeline components?

That was from the previous code as an example of pipeline
configuration (I think).  I'm guessing this is similar to Cocoon where
all the Setup methods are run for the pipelnie.

 Somehow I think it should not be necessary that client (or sitemap) code
 directly accesses the components of a pipeline after it is assembled.
 That's also the reason, why there is no method to expose the components on
 the pipeline interface.

Yea, the implementation sketched out is part of the internal Corona
code, it's not something the client / app code should see.

Gotta run, hope that doesn't confuse things even more...

-- 
Peter Hunsberger

Re: [Corona] PIpeline API

[Peter Hunsberger]

On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz [EMAIL PROTECTED] wrote:

 Are you talking about passing the input parameters as parameters of the
 setup() method?

 void setup(MapString, Object inputParameters)

 I'd be fine by this.


I hate seeing Maps used as dumping grounds for randomly typed objects.
Could you use something that gives a little more strong typing?
Perhaps more like a ServletContext though I don't think I'd go that
far in this case?

-- 
Peter Hunsberger

Re: [Corona] PIpeline API

[Peter Hunsberger]

On Fri, Jul 11, 2008 at 8:19 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote:
 Hi,

 I'm currently looking for a nice and simple pipeline api to be integrated
 with Apache Sling :)
 And of course I had a quick look at Corona (as everything else I found was
 not what I was searching for) which would be the prefered way of
 implementing pipelines :)

[snip] Corona refactoring ideas [/snip]


 WDYT?


This sounds like what I'm looking for one project we have.   It makes
sense to me

-- 
Peter Hunsberger

Re: Upgrade Cocoon 2.1 to ehcache 1.3

[Peter Hunsberger]

On Tue, Jun 3, 2008 at 5:00 AM, Andrew Savory [EMAIL PROTECTED] wrote:
 Hi,

 Now that the vote to switch to a more recent baseline JDK has passed, I'd
 like to upgrade to ehcache 1.3.0, which gives us nicer shutdown and jmx
 instrumentation.

+1 (Please, please)



-- 
Peter Hunsberger

Re: [VOTE] Drop JDK1.3 support for Cocoon 2.1.11 and newer versions

[Peter Hunsberger]

On Wed, May 28, 2008 at 2:03 AM, Jeroen Reijn [EMAIL PROTECTED] wrote:
 Hi all,

 I recently ran across problems while trying to upload cocoon 2.1.11 jars to
 the maven1 repository[1]. Building Cocoon with JDK 1.3 failed due to
 multiple errors. Therefor I would like to suggest setting the minimum JDK to
 1.4 for cocoon 2.1.11 and newer versions. A bit more then a year ago we had
 the same vote for 2.1.10. See [2] for more info.

 We decided then that we should release 2.1.10 as soon as possible and move
 on to Cocoon 2.2 where we already had a higher JDK version as a minimum. I
 think it's a good idea to do a revote, since there might even be a 2.1.12.

 Please cast your votes!


+1   (one more time...)


-- 
Peter Hunsberger

Re: Avoiding OutOfMemory Errors by limiting data in pipeline

[Peter Hunsberger]

On Sun, May 11, 2008 at 6:59 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:
 On 09.05.2008 09:41, Peter Hunsberger wrote:


 
  I haven't looked at the code here, but couldn't you just introduce a
  second getOutputStream( int bufferSize ) method where the current
  interface method continues with the current default logic if it is
  used?
 

  getOutputStream() actually already takes an int parameter, the flush buffer
 size.

Yeah, I saw that...

 Whether to add another getOutputStream() method or modify the existing
 one there is not really a difference IMO. Environment is a kind of internal
 interface (or SPI how it used to be called lately, isn't it?). This means
 there should be only very few implementations besides the one we provide if
 at all (Forrest, Lenya, CLI environment?). And in Cocoon we would change all
 usages of the single-parameterized method to the one with 2 parameters. So
 whoever provides such an Environment implementation has to adapt his
 implementation in a meaningful way anyway (empty implementation returning
 null, throwing NotSupportedException, whatever would not work). So it's the
 same effort for them whether to add a new method or changing existing one on
 the interface.

I don't see that, you can continue the existing behaviour for those
who don't change?

  IMO the decision should be made purely from a design perspective. Should  a
 configuration parameter passed around as method parameter though it is
 static through the whole lifecycle of the Environment instance? In a perfect
 world I'd say no :)

That makes sense.  Guess the question in that case is; are the are any
use cases where people could use such a parameter as not static?

 Which leaves the question how to inject the parameter.
 One place is on instantiation (e.g. CocoonServlet.getEnvironment(..) in 2.1,
 RequestProcessor.getEnvironment(..) in 2.2) which leaves us with the web.xml
 init parameter (or analogical alternatives for other environments) as
 described.

  Another option I found is to setup the environment (i.e. injecting the
 parameter) while setting up the pipeline. AbstractProcessingPipeline is the
 place where we have access to the current flush buffer size parameter and
 call getOutputStream(..) on the environment. It has a method
 setupPipeline(Environment). Why not injecting the parameter(s) here? Due to
 its lifecycle changing the property of the environment should not cause any
 problem since it's a one-time usage object, no threading problems or
 something like that.


Seems reasonable.

[snip/]

-- 
Peter Hunsberger

Re: Avoiding OutOfMemory Errors by limiting data in pipeline

[Peter Hunsberger]

On Fri, May 9, 2008 at 12:08 AM, Joerg Heinicke [EMAIL PROTECTED] wrote:
 On 08.05.2008 11:53, Bruce Atherton wrote:

snip/

 I think this is rather hard to do. The place where we instantiate the
 BufferedOutputStreams (both java.io and o.a.c.util) is
 AbstractEnvironment.getOutputStream(int bufferSize). So in order to pass a
 second buffer size argument to the BufferedOutputStream constructor we need
 to have it available there. One option would be to add it to
 getOutputStream() - which is an interface change and not really nice.

I haven't looked at the code here, but couldn't you just introduce a
second getOutputStream( int bufferSize ) method where the current
interface method continues with the current default logic if it is
used?


 The second option would be to pass it to the Environment instance. Since
 environments can be wrapped it needs again an interface change (but just
 adding a method, which is much better). And you have to look where
 environments are instantiated, e.g. HttpServletEnvironment in CocoonServlet.
 From what I see from a quick look only potential way to provide a
 configuration would be as servlet init parameter. That makes it two
 different places to configure these two different buffer sizes - not very
 intuitive.

Yuck.

-- 
Peter Hunsberger

Re: [OT] Mac OS X and Java development

[Peter Hunsberger]

On Thu, May 8, 2008 at 10:35 PM, Joerg Heinicke [EMAIL PROTECTED] wrote:

 Actually the consistency is what I love the most:
  Emacs keybindings (Ctrl-{A,E,P,N,K,Y, etc}) work *everywhere*, even
 the single-line textfields like the search box in web browsers.

 But not in Eclipse ;) Anyways, I don't want to get started with letters for
 cursor navigation.


You do know that there's an EMACs plugin for Eclipse?

-- 
Peter Hunsberger

Re: JNet integration

[Peter Hunsberger]

On Wed, Mar 26, 2008 at 4:46 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote:

snip/

  The question is now if we need support for caching in the low level apis
  or if it is possible to have a layered approach - which would make the
  entry barrier much easier.


We've ended up layering our own caching on top (or maybe under,
depending on your POV) of much of the Cocoon caching.  This is because
we mainly use a single generator and serve most of our content from a
database.  In our case different database resources have very
different cache lifetimes, we have very granular resources with very
aggressive caching (very simplified example; metadata and data is
pulled from the same pipeline.)  Basically I've found a couple of
things:

- Cache key construction is the thing that matters.  We allow
polymorphic behavior in the cache keys so that multiple resources can
resolve to the same resource.  It is up to the cache key to determine
what underlying resource is being accessed and not the URI.

- Since we allow cache key polymorphisim we cannot use a Hashmap since
a hash code look up doesn't allow two objects with different hash
values to occupy the same object space. Instead we use a TreeMap that
tests equality explicitly, a seperate equality test can use whatever
rules it needs.

- all of the call context is made available for the cache key
construction, we make no assumptions on how the cache key is going
manage itself, there is no such thing as different types of cache keys
any cache key might be based on time to live, events, URI, request
parameters and attributes, or whatever.

- cache keys can register other cache keys that they are dependent on
and invalidating a cache key causes resources defendant on it to also
be invalidated.  The important thing here is that all caching
decisions are contained in a single place (the cache key).

- all resource access goes through the same path.  Non cached
resources simply do not get a cache key, if no cache key is built the
attempt to retrieve the resource from the cache is skipped (duh).

Don't know if this helps any, but for us, having made this design
decision our caching is completely decoupled form URI resolving (and
in fact the rest of the Cocoon infrastructure).

-- 
Peter Hunsberger

Re: Micro-Cocoon ... Corona

[Peter Hunsberger]

On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
 Reinhard Poetz wrote:

sniplots of cool stuff/snip


  So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me)
  behind closed doors but we would like to change that, if this community is
  interested in adopting it in this or that way. Is there any interest and if 
 yes,
  how should we proceed?

Very interested.  I'd second throwing it into the white board if
you're willing?

-- 
Peter Hunsberger

Re: Releasing Cocoon 2.2, finally!

[Peter Hunsberger]

On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:

  It's time to release Cocoon 2.2, finally!

Good news indeed.

 We have been working on it for years
  and I think it's time to ship the *final* release. I want to do this in three
  phases:

  1) During the first phase I will release our two sub-projects Cocoon
  Configuration and Cocoon Servlet-Service-Framework. This time I will 
 create
  the Maven 2 release artifacts and normal zip/tar release artifacts for
  non-Maven users.


Can you explain exactly what the difference is between these?

  I think that I will be able to finish it by the end of next week.

  2) The second phase is Cocoon Core and all the blocks that were released as
  release candidates.

Can you explain how this differs from the first two?  I think I know, but..

 Additionally I want to release the Cocoon Maven plugin
  (milestone 2), the Cocoon integration test framework (milestone 1), our
  archetypes and a starter package for non-Maven users.
  Again, this time I will create normal zip/tar release artifacts, except 
 those
  cases where it doesn't make sense (e.g. the Maven plugin, the POM artifacts 
 and
  the archetypes).

  I think that I will manage to finish this work by the end of March.


Guess the biggest question is what will the minimal package be to get started?

  3) The third phase is releasing our samples. It would be great if somebody 
 else
  could help out with this task because I don't know if I will have the 
 necessary
  cycles anytime soon. I guess that there is some work left in order to get 
 this
  done and there are a couple of things to be discuessed before:

We'll need to package up our own code to drop into the base but really
we wouldn't need the samples for any other reason than to get ides on
the best way to do this

   . What do we want to ship? A WAR file only, or a WAR file + a pre-configured
 Jetty packaged as ZIP, etc?

Are the above release artifacts separate downloads?  I think I'd
like to see the basic minimal WAR for people who need nothing else and
a complete Zip of everything you could possibly want for those who
don't want to do multiple downloads.

   . Do we ship snapshots of our blocks and samples? Or the released blocks and
 the snapshots of the samples? Or do we want to release our samples 
 offically?
   . Are there any open legal issues? (e.g. we have to make sure that all the
 licenses of 3-party libs are added, etc.)
   . Or, should we only provide nightly snapshots of our samples? (though we 
 would
 still have to check what this means legally for us ...)
   . etc.

Ideally I'd love to see each sample as a separate download  complete
with some way of tracking version updates, but initially I'd settle
for a single download.



  I know that there are still open isses but I don't see any blockers. Since 
 this
  will probably be the last time when our sub-projects, core and a lot of 
 blocks
  are released together, I think it will be easy to ship upgrades of one 
 module as
  soon as we have something better available without having to wait for all the
  rest getting stable.

  As soon as I'm ready for the actual release work, I will announce a partly 
 code
  freeze of our repository.


 +1 :-)

-- 
Peter Hunsberger

Re: Releasing Cocoon 2.2, finally!

[Peter Hunsberger]

On Thu, Mar 6, 2008 at 9:25 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
 Peter Hunsberger wrote:
   On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:

snip/

1) During the first phase I will release our two sub-projects Cocoon
Configuration and Cocoon Servlet-Service-Framework. This time I will 
 create
the Maven 2 release artifacts and normal zip/tar release artifacts for
non-Maven users.
  
  
   Can you explain exactly what the difference is between these?

  The Maven release artifacts are those files deployed to repo1.maven.org, see
  http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-apples-impl/1.0.0-RC2/
  for example.

  A normal release artifact is a zip/tar archive that contains the sources, the
  packaged binaries, the javadocs and the user documention.


Sorry, I meant, what's the difference between Cocoon Configuration
and Cocoon Servlet-Service-Framework ?

snip/

-- 
Peter Hunsberger

Re: Releasing Cocoon 2.2, finally!

[Peter Hunsberger]

On Thu, Mar 6, 2008 at 9:45 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
 Peter Hunsberger wrote:
   On Thu, Mar 6, 2008 at 9:25 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:
   Peter Hunsberger wrote:
 On Thu, Mar 6, 2008 at 7:58 AM, Reinhard Poetz [EMAIL PROTECTED] 
 wrote:
  
   snip/
  
  1) During the first phase I will release our two sub-projects Cocoon
  Configuration and Cocoon Servlet-Service-Framework. This time I 
 will create
  the Maven 2 release artifacts and normal zip/tar release artifacts 
 for
  non-Maven users.


 Can you explain exactly what the difference is between these?
  
The Maven release artifacts are those files deployed to repo1.maven.org, 
 see

 http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-apples-impl/1.0.0-RC2/
for example.
  
A normal release artifact is a zip/tar archive that contains the 
 sources, the
packaged binaries, the javadocs and the user documention.
  
  
   Sorry, I meant, what's the difference between Cocoon Configuration
   and Cocoon Servlet-Service-Framework ?

  see http://cocoon.apache.org/subprojects/


Ah, ok, makes sense. Given I've seen both of these numerous times and
didn't recognize the terminology I think you're going to need a very
good explanation as to what they are and why you'd want to use them as
part of the release announcements


-- 
Peter Hunsberger

Re: [RT] RESTful web applications

[Peter Hunsberger]

On Dec 5, 2007 8:16 AM, Reinhard Poetz [EMAIL PROTECTED] wrote:


 Recently I've been thinking more and more about some kind of Micro-Cocoon[*]
 that consists of

   o a slimmed-down sitemap language available in as an XML and as a Java 
 dialect
 (no component declarations, no sub-sitemaps, no resources, merged
  match/select),
   o a controller implementation that is optimized for being used in RESTful
 scenarios (similar to Apples) and
   o a lean forms framework that borrows some ideas from Webforms 2.0 and
 follows the principles of REST. Daniel and I had some discussions about 
 it in
 Rome and I've started with some experiments but don't have anything
 substantial so far.

 All the parts mentioned above should be useable in parallel with a
 traditional Cocoon 2.2 application. Thanks to the servlet-service framework 
 this
 shouldn't be too hard to be achieved.

 If this sounds interesting to anybody, just let me know.


That's been on my wish list for about three years now.  Either Cocoon
2.2 has to grow into a system that can be pared down into a sort of
micro sized core or we'll end up finding another solution.  We just
don't need all the extra _stuff_ (-- technical term)...

-- 
Peter Hunsberger

Re: cocoon demos on cocoon.zones.apache.org

[Peter Hunsberger]

On Nov 16, 2007 8:43 AM, Vadim Gritsenko [EMAIL PROTECTED] wrote:
 Hey all,

 Cocoon branch and trunk demos on zones are up and running.

http://cocoon.zones.apache.org/demos/trunk/
http://cocoon.zones.apache.org/demos/21branch/


 (branch was broken because of removed svn externals; trunk was not set up)


Good stuff!  Your work in getting these up is appreciated.

In some random exploration I discovered that the image-op to grayscale
example produced a stack trace:


http://cocoon.zones.apache.org/demos/trunk/cocoon-imageop-sample/logo2.png/grayscale

Also the rotation examples on the image-op page result in a pure black image.


-- 
Peter Hunsberger

Re: cocoon demos on cocoon.zones.apache.org

[Peter Hunsberger]

On Nov 16, 2007 9:07 AM, Vadim Gritsenko [EMAIL PROTECTED] wrote:
 Peter Hunsberger wrote:
  In some random exploration I discovered that the image-op to grayscale
  example produced a stack trace:
 
  
  http://cocoon.zones.apache.org/demos/trunk/cocoon-imageop-sample/logo2.png/grayscale
 
  Also the rotation examples on the image-op page result in a pure black 
  image.

 Do you have same effect when running it locally or is it specific to the zones
 instance?


Sorry, don't have 2.2 running locallly at the moment.  It will
probably be a couple of months before I get back to having it up;
we're buried under the rolllout of a major release which isn't really
expected to let up until after Christmas...  Maybe someone else can
check the imageOp samples locally?

-- 
Peter Hunsberger

Re: [vote] Releasing from trunk: Cocoon 2.2-RC2 others

[Peter Hunsberger]

On 10/15/07, Reinhard Poetz [EMAIL PROTECTED] wrote:

 I've prepared another series of releases from trunk, see the list of all 45
 artifacts below. This time most of the modules are proposed to be released as
 RC2 (release candidate 2) or RC1.


Nicely done.  +1

-- 
Peter Hunsberger

Re: RIA technologies

[Peter Hunsberger]

On 8/30/07, Leszek Gawron [EMAIL PROTECTED] wrote:

 Client side javascript has exactly the same problem our flowscript has:
snip/
- debug tools are: print( here I am ) and nothing more (apart from
 GWT which uses 'advanced magic').


Not quite: Firebug for FireFox is wonderful for debugging AJAX code.
Let's you see the request the response, the current value of any form
field, etc.

FWIW, we have replaced all of our front end code that previously used
Flash with AJAX code, the developers are more productive and the
results are more esthetically pleasing.  I personally feel that there
are major advances to be made on front end scripting, but the current
crop of AJAX tools are a major leap forward from anything else we've
had available for complex cross browser UI functionality in the last
10 years.

-- 
Peter Hunsberger

Re: Pipeline components and Object Model issues

[Peter Hunsberger]

On 8/19/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:

snip/

 Same goes for all other SAX events. It's actually one extra get and two puts 
 calls on Map. Rather
 lightweight, yes?


I don't really have time to dive into all the details of the
discussion, but Map calls themselves are not necessarily
lightweight.  If the map itself can grow to any large size then a
get or a put isn't necessarily trivial...?

snip/

-- 
Peter Hunsberger

Re: GSoC final report

[Peter Hunsberger]

On 8/20/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:

snip/

Very nice, many thanks for all yoru hard work.

-- 
Peter Hunsberger

Re: How to register MockProcessInfoProvider?

[Peter Hunsberger]

On 7/30/07, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
 Carsten Ziegeler skrev:
  Grzegorz Kossakowski wrote:

snip/

+100


 So to summarize, it would be a great benefit to let our environment
 abstractions extend the http servlet ones and the cost would be low. So
 it is time to do it.

-- 
Peter Hunsberger

Re: HttpServletRequest vs o.a.c.e.Request saga continues

[Peter Hunsberger]

On 7/26/07, Carsten Ziegeler [EMAIL PROTECTED] wrote:

Grzegorz Kossakowski wrote:


Now all you really need are some more committers who would like to
support this plan - and that's the really hard part. One indication of
interest is the very low participation in this thread



I can say +1 to everything you've discussed.  However, I haven't had a
chance to try and build 2.2 recently since we're closing in on a
deadline for a huge project (3 years in development) at the end of the
month.  It will be another month of bug shooting before I even get a
chance to sync up SVN on the dev branch again.

I bet a lot of other people are on vacation and doing summer type
stuff and just nnot paying a lot of attention to Cocoon at the
moment...

--
Peter Hunsberger

Re: spring webflow

[Peter Hunsberger]

On 7/17/07, Daniel Fagerstrom [EMAIL PROTECTED] wrote:

snip/


I will start from the WebFlow tutorial and give an outline on what needs
to be modified:

* The root application context (services-config.xml) needs to be
extended with the Cocoon components. See
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/applicationContext.xml
for what is needed. This in turn will load all bean configs frm the
Cocoon blocks.
* If you want to use Cocoon in the classic style the
o.a.c.servlet.SitemapServlet needs to be configured in the web.xml. If
you want to use the servlet service style the
o.a.c.servletservice.DispatcherServlet needs to be configured
(http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-webapp/src/main/webapp/WEB-INF/web.xml).


Can you explain why someone would prefer one approach over the other?

snip/
--
Peter Hunsberger

Re: RT: map:call as generic non-redirecting controller code

[Peter Hunsberger]

On 7/4/07, Daniel Fagerstrom [EMAIL PROTECTED] wrote:

snip/


 So at the minimum we'd only need to:
 a) change the Interpreter API to allow a function to return a value.



I think that Interpreter is part of our official API, so we must
consider back compatibility and our deprecation policy. Does changing
the return value from void to Object create back incompatibility? If it
does the simplest way is probably to add a new method that has a return
value, and possibly deprecating the current one. Also one have to keep
in mind that javaflow and apples depends on the flow API.



I think we had this discussion once before (though I'm too lazy to go
look it up)?  I don't see how adding a returned object could break
anything if a function currently returns void?  I'd say you don't need
a new method, but you may need to put it to a vote...

snip/

--
Peter Hunsberger

Re: FYI: Ohloh.net is evolving

[Peter Hunsberger]

On 6/26/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:

Grzegorz Kossakowski wrote:
 It would be nice if you registered and set
 your coordinates on Google's map. It would create nice overview of
 Cocoon's developers scattered on the world.

I think you have not seen this yet:
http://people.apache.org/map.html



Ok, I'll bite, how do you update this info?


--
Peter Hunsberger

Re: FYI: Ohloh.net is evolving

[Peter Hunsberger]

On 6/27/07, Ralph Goers [EMAIL PROTECTED] wrote:

Click on Managing your details. Basically, you need to create a file
in committers/info as apacheid.rdf where apacheid is your apache userid.
You can look at other people's files there or you can use the tool at
http://people.apache.org/foaf/foafamatic.html.


I do have a FOAF file that has been committed.  The more challenging
part seems to be how to determine longitude and latitude for a
location...

--
Peter Hunsberger