dev@cocoon.apache.org Archives

[jira] Created: (COCOON-2272) CLONE -Calling SitemapSource.getInputStream() twice

2009-12-06T06:51:20Z

CLONE -Calling SitemapSource.getInputStream() twice
---------------------------------------------------

                 Key: COCOON-2272
                 URL: https://issues.apache.org/jira/browse/COCOON-2272
             Project: Cocoon
          Issue Type: Bug
          Components: * Cocoon Core
         Environment: Operating System: other
Platform: Other
            Reporter: josh
            Priority: Critical


Hello,

It seems that Cocoon is broken WRT calling SitemapSource.getInputStream() twice.
 The first invocation is okay, but the second one is doing a refresh().  Then
the environment's context is reset, which is making the request fail.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: closeLoudly()

2009-12-05T14:02:28Z

Hi Jos,
please don't think so, were are a community and we should help each other :)
In the past I did errors, but Reinhard and Steven kindly helped me as well ;)
Have a nice day,
Simo

On Sat, Dec 5, 2009 at 9:51 AM, Jos Snellings  wrote:
> I attached the patch. Is this the proper way to submit?
> Thanks, and please excuse me my ignorance. It is the first time.
> (first times can be traumatic, so far I am feeling well).
>
> Jos
>
> On Sat, 2009-12-05 at 09:28 +0100, Jos Snellings wrote:
>> Thank you, Simone. I will do that.
>>
>> On Sat, 2009-12-05 at 09:21 +0100, Simone Tripodi wrote:
>> > Hi Jos,
>> > nice to meet you :) Usually suggestions of this kind have to be
>> > submitted by the issue tracker:
>> >
>> > http://issues.apache.org/jira/browse/COCOON3
>> >
>> > Make your own patch through the command line:
>> >
>> > svn diff -x -u Main.java > arg-fix.patch
>> >
>> > giving your patch file meaningful name.
>> > Goof job!
>> > Simo
>> >
>> > On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings 
wrote:
>> > > URLResponse.java:
>> > >
>> > > Modifying the finally-clause to remain silent:
>> > >
>> > > finally {
>> > >            if (servletConnection != null)
>> > > URLConnectionUtils.closeQuietly(servletConnection);
>> > >        }
>> > >
>> > > Jos
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
>
>



-- 
http://www.google.com/profiles/simone.tripodi

Re: [jira] Commented: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null

2009-12-05T10:18:44Z

Oh, you're right :-) I only read your mail on the mailing list, not the 
complete issue text.

Joerg

On 05.12.2009 11:04, Jos Snellings wrote:
> That is what I did.
> 
> On Sat, 2009-12-05 at 09:50 +0000, Jörg Heinicke (JIRA) wrote:
>> [ https://issues.apache.org/jira/browse/COCOON3-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786368#action_12786368
] 
>>
>> Jörg Heinicke commented on COCOON3-46:
>> --------------------------------------
>>
>> Isn't it more convenient if closeQuietly(..) just handles null?
>>
>>> URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
>>> -------------------------------------------------------------------------------
>>>
>>>                 Key: COCOON3-46
>>>                 URL: https://issues.apache.org/jira/browse/COCOON3-46
>>>             Project: Cocoon 3
>>>          Issue Type: Improvement
>>>          Components: cocoon-pipeline
>>>    Affects Versions: 3.0.0-alpha-2
>>>            Reporter: Jos Snellings
>>>            Assignee: Cocoon Developers Team
>>>            Priority: Minor
>>>             Fix For: 3.0.0-alpha-3
>>>
>>>
>>> finally clause in URLResponse method execute()
>>> contains call to URLConnectionUtils.closeQuietly.
>>> If  servletConnection = this.url.openConnection(); fails, servletConnection is
null.
>>> In that case closeQuietly causes a stacktrace to be output.
>>> Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);,
guard the call with a test,
>>> or even better, take into account in closeQuietly that the input parameter may
be null.
> 
>

Re: [jira] Commented: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null

2009-12-05T10:04:53Z

That is what I did.

On Sat, 2009-12-05 at 09:50 +0000, Jörg Heinicke (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/COCOON3-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786368#action_12786368
] 
> 
> Jörg Heinicke commented on COCOON3-46:
> --------------------------------------
> 
> Isn't it more convenient if closeQuietly(..) just handles null?
> 
> > URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
> > -------------------------------------------------------------------------------
> >
> >                 Key: COCOON3-46
> >                 URL: https://issues.apache.org/jira/browse/COCOON3-46
> >             Project: Cocoon 3
> >          Issue Type: Improvement
> >          Components: cocoon-pipeline
> >    Affects Versions: 3.0.0-alpha-2
> >            Reporter: Jos Snellings
> >            Assignee: Cocoon Developers Team
> >            Priority: Minor
> >             Fix For: 3.0.0-alpha-3
> >
> >
> > finally clause in URLResponse method execute()
> > contains call to URLConnectionUtils.closeQuietly.
> > If  servletConnection = this.url.openConnection(); fails, servletConnection is null.
> > In that case closeQuietly causes a stacktrace to be output.
> > Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);,
guard the call with a test,
> > or even better, take into account in closeQuietly that the input parameter may be
null.
>

[jira] Commented: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null

2009-12-05T09:50:20Z


    [ https://issues.apache.org/jira/browse/COCOON3-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786368#action_12786368
] 

Jörg Heinicke commented on COCOON3-46:
--------------------------------------

Isn't it more convenient if closeQuietly(..) just handles null?

> URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
> -------------------------------------------------------------------------------
>
>                 Key: COCOON3-46
>                 URL: https://issues.apache.org/jira/browse/COCOON3-46
>             Project: Cocoon 3
>          Issue Type: Improvement
>          Components: cocoon-pipeline
>    Affects Versions: 3.0.0-alpha-2
>            Reporter: Jos Snellings
>            Assignee: Cocoon Developers Team
>            Priority: Minor
>             Fix For: 3.0.0-alpha-3
>
>
> finally clause in URLResponse method execute()
> contains call to URLConnectionUtils.closeQuietly.
> If  servletConnection = this.url.openConnection(); fails, servletConnection is null.
> In that case closeQuietly causes a stacktrace to be output.
> Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);,
guard the call with a test,
> or even better, take into account in closeQuietly that the input parameter may be null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: closeLoudly()

2009-12-05T08:51:29Z

I attached the patch. Is this the proper way to submit?
Thanks, and please excuse me my ignorance. It is the first time.
(first times can be traumatic, so far I am feeling well).

Jos

On Sat, 2009-12-05 at 09:28 +0100, Jos Snellings wrote:
> Thank you, Simone. I will do that.
> 
> On Sat, 2009-12-05 at 09:21 +0100, Simone Tripodi wrote:
> > Hi Jos,
> > nice to meet you :) Usually suggestions of this kind have to be
> > submitted by the issue tracker:
> > 
> > http://issues.apache.org/jira/browse/COCOON3
> > 
> > Make your own patch through the command line:
> > 
> > svn diff -x -u Main.java > arg-fix.patch
> > 
> > giving your patch file meaningful name.
> > Goof job!
> > Simo
> > 
> > On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings  wrote:
> > > URLResponse.java:
> > >
> > > Modifying the finally-clause to remain silent:
> > >
> > > finally {
> > >            if (servletConnection != null)
> > > URLConnectionUtils.closeQuietly(servletConnection);
> > >        }
> > >
> > > Jos
> > >
> > >
> > 
> > 
> > 
> 
> 
>

[jira] Created: (COCOON3-46) URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null

2009-12-05T08:41:20Z

URLConnectionUtils.closeQuietly() complains loudly if servletConnection == null
-------------------------------------------------------------------------------

                 Key: COCOON3-46
                 URL: https://issues.apache.org/jira/browse/COCOON3-46
             Project: Cocoon 3
          Issue Type: Improvement
          Components: cocoon-pipeline
    Affects Versions: 3.0.0-alpha-2
            Reporter: Jos Snellings
            Assignee: Cocoon Developers Team
            Priority: Minor
             Fix For: 3.0.0-alpha-3


finally clause in URLResponse method execute()
contains call to URLConnectionUtils.closeQuietly.

If  servletConnection = this.url.openConnection(); fails, servletConnection is null.

In that case closeQuietly causes a stacktrace to be output.

Solution is if (servletConnection != null) URLConnectionUtils.closeQuietly(servletConnection);,
guard the call with a test,
or even better, take into account in closeQuietly that the input parameter may be null.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: closeLoudly()

2009-12-05T08:28:52Z

Thank you, Simone. I will do that.

On Sat, 2009-12-05 at 09:21 +0100, Simone Tripodi wrote:
> Hi Jos,
> nice to meet you :) Usually suggestions of this kind have to be
> submitted by the issue tracker:
> 
> http://issues.apache.org/jira/browse/COCOON3
> 
> Make your own patch through the command line:
> 
> svn diff -x -u Main.java > arg-fix.patch
> 
> giving your patch file meaningful name.
> Goof job!
> Simo
> 
> On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings  wrote:
> > URLResponse.java:
> >
> > Modifying the finally-clause to remain silent:
> >
> > finally {
> >            if (servletConnection != null)
> > URLConnectionUtils.closeQuietly(servletConnection);
> >        }
> >
> > Jos
> >
> >
> 
> 
>

Re: closeLoudly()

2009-12-05T08:21:13Z

Hi Jos,
nice to meet you :) Usually suggestions of this kind have to be
submitted by the issue tracker:

http://issues.apache.org/jira/browse/COCOON3

Make your own patch through the command line:

svn diff -x -u Main.java > arg-fix.patch

giving your patch file meaningful name.
Goof job!
Simo

On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings  wrote:
> URLResponse.java:
>
> Modifying the finally-clause to remain silent:
>
> finally {
>            if (servletConnection != null)
> URLConnectionUtils.closeQuietly(servletConnection);
>        }
>
> Jos
>
>



-- 
http://www.google.com/profiles/simone.tripodi

closeLoudly()

2009-12-05T07:29:46Z

URLResponse.java:

Modifying the finally-clause to remain silent:

finally {
            if (servletConnection != null)
URLConnectionUtils.closeQuietly(servletConnection);
        }

Jos

Re: Cocoon3 Wicket integration

2009-12-04T13:41:03Z

Hi Reinhard, and thanks for this. 

I have in mind to create - one day :) - a "Form module" for Lenya.

----- Here the main line of the idea : -----
[[..]] (pick up from a lenya thread)
Year, IMO forms is a good and user-friendly solution for pick-up structured
data from user.

IMO, a great cform module can be composed by something like that : 

0) user interface for defining the "form container" {can be done by
advanced user} (the last step in developping)

1) xml "form container"  {can be done by xml-compliant user), that contain
: 
--- the xml form declaration (a cform file ?) ==> define all inputs and
authorized values
--- the action connector : define what doing with the filled result (eg :
send a mail, create a new lenya doc, fire a pipeline, ...)

2) a set of "actionners" (send a mail, create a lenya doc, calculate result
from filling,...)

------ With wicket ? (point 1) )------

- So IMO with this ""specifications"" and wicket : 

-- cocoon pick-up the "form container" and pass the "form declaration" to
wicket
-- wicket deal with presentation, validation,... and put the result into
cocoon
-- cocoon retrieve the filling result and apply the "action connector" on
it (send a mail, create a doc, etc...) 

------ Questions -----

I don't have jump into cocoon 3 for now, so maybe my questions are
stupid...

- What do you think about this solution ?

- What is the ideas (of the five) that can answer to this ?

- One of your samples can give me some pointer on it ?

Thanks
++

On Thu, 26 Nov 2009 09:13:52 +0100, Reinhard Pötz 
wrote:
> Since I was asked several times off-list and there have also been some
> mails on the users list asking about the best way to integrate Cocoon
> with Wicket, I invested some time into a first implementation. Actually
> there are five ideas that I have:
> 
>  a) An IRequestTargetUrlCodingStrategy wrapping a Cocoon sitemap
>  b) An IRequestTargetUrlCodingStrategy wrapping a Cocoon pipeline
>  c) A page component wrapping a Cocoon pipeline
>  d) A Wicket reader to be used in Cocoon sitemaps
>  e) Wicket generator/transformer, again to be used in sitemaps
> 
> a) and b) are useful to add a couple of pipelines to your Wicket
> application. c) helps if you want to use a Cocoon pipeline to provide
> the content of some parts of a page.
> 
> d) and e) help to run a Wicket application in parallel with Cocoon while
> Cocoon remains the "leading" framework.
> 
>                                    - o -
> 
> I added implementations and samples for a, c and d to the SVN. The
> generic parts are in the cocoon-wicket module, the Cocoon/Wicket samples
> in cocoon-samples and the Wicket/Cocoon samples in
> cocoon-samples-wicket-webapp.
> 
> I also wrote some initial documentation that you can find at
> http://people.apache.org/~reinhard/c3-ref/html/wicket-integration.html
> 
>                                    - o -
> 
> Currently it's rather a proof-of-concept (especially the reader) than
> something that you should use in production, but hopefully a first step
> and a basis for further discussions if this is of help to others.
> 
> Let me know if this is of interest to you and what you think about the
> different approaches.
> 
> And finally many thanks to Steven who helped me to hunt down some
> bugs in the reader component.

Re: Cocoon documentation

2009-12-04T12:52:17Z

Jos Snellings wrote:
> What editor do you use?.
> (I mostly use XMLMind)

yes, either XMLMind or I use use a schema-aware editor.

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Re: Cocoon documentation

2009-12-04T12:35:15Z

What editor do you use?.
(I mostly use XMLMind)

On Fri, 2009-12-04 at 12:09 +0100, Reinhard Pötz wrote:
> Jos Snellings wrote:
> > Currently there is an initialisation problem. 
> > Anyway, Reinhard, you had a great table of contents. That is a good way
> > to get started: what nodes are missing? That way, we may fill in the
> > gaps, whilst trying our best to preserve unity of presentation & writing
> > style
> > All docbook, I guess?
> 
> Yes, cocoon-docs is based on docbook and a Maven 2 docbook plugin that
> creates html and pdf docs:
> 
> See
> http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs/src/docbkx/reference/
> 
> You can generate the documentation yourself by invoking 'mvn site' from
> the base directory of the cocoon-docs module.
>

Re: Cocoon documentation

2009-12-04T11:09:16Z

Jos Snellings wrote:
> Currently there is an initialisation problem. 
> Anyway, Reinhard, you had a great table of contents. That is a good way
> to get started: what nodes are missing? That way, we may fill in the
> gaps, whilst trying our best to preserve unity of presentation & writing
> style
> All docbook, I guess?

Yes, cocoon-docs is based on docbook and a Maven 2 docbook plugin that
creates html and pdf docs:

See
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs/src/docbkx/reference/

You can generate the documentation yourself by invoking 'mvn site' from
the base directory of the cocoon-docs module.

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Re: Cocoon documentation

2009-12-04T10:45:34Z

Currently there is an initialisation problem. 
Anyway, Reinhard, you had a great table of contents. That is a good way
to get started: what nodes are missing? That way, we may fill in the
gaps, whilst trying our best to preserve unity of presentation & writing
style
All docbook, I guess?

Jos


On Fri, 2009-12-04 at 10:15 +0100, Reinhard Pötz wrote:
> Matt Whipple wrote:
> > Reinhard Pötz wrote:
> >> Matt Whipple wrote:
> >>   
> >>> Jos Snellings wrote:
> >>>     
> >>>> The documentation of cocoon-3 can be checked out as:
> >>>> svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
> >>>>   
> >>>>       
> >>> I stumbled upon the HTML deliverable of that on
> >>> http://people.apache.org/~reinhard/c3-ref/html/ after sending my email.

> >>> I'd think it would be best if the official documentation focused on
> >>> being primarily a comprehensive reference with a quick bootstrap guide.

> >>> A community documentation site could then supplement that with all the
> >>> typical tutorials/how-to's and tips & tricks which gets the reader where
> >>> he wants to be with a straightforward, minimalist approach which then
> >>> references the official docs and other more enlightening sources. 
> >>> Regular articles/blog entries could then highlight the activity in the
> >>> community, and the possibilities of various Cocoon components could be
> >>> showcased.  Guides to all of the overlapping processes which can be
> >>> [easily] extrapolated from existing material can be given a home so that
> >>> a potential new developer with a specific need is provided with an
> >>> apparent foot in the door.  Basically a site which presents a welcoming,
> >>> active community rather than seemingly a group of scattered people
> >>> developing in Cocoons and enabling me to make bad wordplay (such is the
> >>> price).  To that end, an agreed upon forum would be ideal. 
> >>>     
> >> Agreed. When I started to write the C3 documentation, I had the Spring
> >> reference documentation in mind. I think it's one of the best examples
> >> because it focuses on describing the technology and the concepts.
> >>
> >> As a forum for everything beyond reference docs we could either use
> >> Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon)
> >>
> >>   
> > My thought would be Daisy (cocoondev.org?) so the site itself can be
> > Cocoon powered and then the wiki can remain legacy docs.
> 
> The Cocoon project runs its own Daisy instance at
> http://cocoon.zones.apache.org/daisy/
> 
> We could setup a Cocoon 3 wiki site there.
>

Re: Cocoon documentation

2009-12-04T09:15:45Z

Matt Whipple wrote:
> Reinhard Pötz wrote:
>> Matt Whipple wrote:
>>   
>>> Jos Snellings wrote:
>>>     
>>>> The documentation of cocoon-3 can be checked out as:
>>>> svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
>>>>   
>>>>       
>>> I stumbled upon the HTML deliverable of that on
>>> http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. 
>>> I'd think it would be best if the official documentation focused on
>>> being primarily a comprehensive reference with a quick bootstrap guide. 
>>> A community documentation site could then supplement that with all the
>>> typical tutorials/how-to's and tips & tricks which gets the reader where
>>> he wants to be with a straightforward, minimalist approach which then
>>> references the official docs and other more enlightening sources. 
>>> Regular articles/blog entries could then highlight the activity in the
>>> community, and the possibilities of various Cocoon components could be
>>> showcased.  Guides to all of the overlapping processes which can be
>>> [easily] extrapolated from existing material can be given a home so that
>>> a potential new developer with a specific need is provided with an
>>> apparent foot in the door.  Basically a site which presents a welcoming,
>>> active community rather than seemingly a group of scattered people
>>> developing in Cocoons and enabling me to make bad wordplay (such is the
>>> price).  To that end, an agreed upon forum would be ideal. 
>>>     
>> Agreed. When I started to write the C3 documentation, I had the Spring
>> reference documentation in mind. I think it's one of the best examples
>> because it focuses on describing the technology and the concepts.
>>
>> As a forum for everything beyond reference docs we could either use
>> Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon)
>>
>>   
> My thought would be Daisy (cocoondev.org?) so the site itself can be
> Cocoon powered and then the wiki can remain legacy docs.

The Cocoon project runs its own Daisy instance at
http://cocoon.zones.apache.org/daisy/

We could setup a Cocoon 3 wiki site there.

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Re: Initialization of variables

2009-12-04T05:50:14Z

Hi Johannes,

I must say, I do not completely understand your point. Talking about
such things as 'transactions': you could setup in the system what needs
to be setup once in a separate class.
Below is an example from the real world where database connections are
set up in a separate spring bean:




On Fri, 2009-12-04 at 02:06 +0100, Johannes Lichtenberger wrote:
> Hello,
> 
> how do I initialize an object (a transaction), which I then have to
> access in a self written pipeline component (generator)?
> 
> My concern is, that the session can only be bound once to a path/file,
> so subsequent requests throw errors.
> 
> regards,
> Johannes
> 
> 
package org.herein.thesaurus.cocoon;

import java.util.Map;
import java.util.Set;

import javax.servlet.http.HttpServletRequest;

import org.apache.cocoon.pipeline.caching.CacheKey;
import org.apache.cocoon.pipeline.caching.SimpleCacheKey;
import org.apache.cocoon.pipeline.component.CachingPipelineComponent;
import org.apache.cocoon.sax.AbstractSAXGenerator;
import org.apache.cocoon.xml.sax.AttributesImpl;
import org.apache.cocoon.sax.SAXConsumer;

import org.apache.cocoon.rest.controller.annotation.SitemapParameter;
import org.apache.cocoon.servlet.util.HttpContextHelper;

import org.xml.sax.SAXException;

import org.herein.thesaurus.ThesaurusBrowser;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;

public class ToptermsGenerator extends AbstractSAXGenerator  implements
CachingPipelineComponent, ApplicationContextAware {
  
	private ApplicationContext applicationContext;
	
    @SitemapParameter
    private String language;
    
    @SitemapParameter
    private String deep;  
    
    private String showClass;  
    private String id;
    private String editing;
    
// String language = "en";

public void setup(Map parameters)  {
     HttpServletRequest request =
HttpContextHelper.getRequest(parameters);
     language = request.getParameter("language");
     deep = request.getParameter("all");     
     showClass = request.getParameter("class");
     id = request.getParameter("nr");
     editing = request.getParameter("edit");
}

public void execute() {
	
	
        SAXConsumer consumer = this.getSAXConsumer();
        try {
            consumer.startDocument();

            consumer.startElement("", "page", "page", new
AttributesImpl());
            
            if (deep == null) {
            	AttributesImpl attr = new AttributesImpl();
            	consumer.startElement("", "searchform", "searchform",
attr);
            	consumer.endElement("", "searchform", "searchform");      
            	}
            
            ThesaurusBrowser T;
            
            if (editing != null) T =  (ThesaurusBrowser)
applicationContext.getBean("EditThesaurusBrowser");
            else T = (ThesaurusBrowser)
applicationContext.getBean("ThesaurusBrowser");
            
            if ((showClass != null) && showClass.equals("1")) {
            	T.showClass(consumer,id);
            	}
            else if ((deep != null) && (deep.equals("1"))) {
            	T.listClassesDeep(consumer, language);
                }
            else if (language != null) {
            	T.listClasses(consumer, language);
            	}
            consumer.endElement("","page","page");
            consumer.endDocument();
        } catch (SAXException e) {
            throw new RuntimeException(e);
        }
    }
	
	
public CacheKey constructCacheKey() {
	        return new SimpleCacheKey();
	    }
	
public void setApplicationContext(ApplicationContext applicationContext)
{
    this.applicationContext = applicationContext;
}


}

Initialization of variables

2009-12-04T01:06:32Z

Hello,

how do I initialize an object (a transaction), which I then have to
access in a self written pipeline component (generator)?

My concern is, that the session can only be bound once to a path/file,
so subsequent requests throw errors.

regards,
Johannes

[jira] Subscription: COCOON-open-with-patch

2009-12-02T10:40:21Z

Issue Subscription
Filter: COCOON-open-with-patch (110 issues)
Subscriber: cocoon
        
Key         Summary
COCOON-2268 To extend the image reader we need to change the visibility to the parameter of
the ImageReader
            https://issues.apache.org/jira/browse/COCOON-2268
COCOON-2262 container.refresh() is called before embeddedServlet.init()
            https://issues.apache.org/jira/browse/COCOON-2262
COCOON-2260 wrong parent version in pom of cocoon-flowscript-impl
            https://issues.apache.org/jira/browse/COCOON-2260
COCOON-2259 Memory leak in PoolableProxyHandler
            https://issues.apache.org/jira/browse/COCOON-2259
COCOON-2250 Wrong error message in Element.java (jx:element)
            https://issues.apache.org/jira/browse/COCOON-2250
COCOON-2249 XHTMLSerializer uses entity references " and ' which cause JavaScript
parse errors
            https://issues.apache.org/jira/browse/COCOON-2249
COCOON-2246 HttpRequest  should handle encoding in getParameter and getParameterValues in
the same way
            https://issues.apache.org/jira/browse/COCOON-2246
COCOON-2233 Update archetypes to current trunk artifact versions
            https://issues.apache.org/jira/browse/COCOON-2233
COCOON-2222 Add SaxParser configuration properties
            https://issues.apache.org/jira/browse/COCOON-2222
COCOON-2216 IncludeCacheManager can not perfom parallel includes
            https://issues.apache.org/jira/browse/COCOON-2216
COCOON-2212 jx:attribute does not check name is correct before proceeding
            https://issues.apache.org/jira/browse/COCOON-2212
COCOON-2197 Making the cocoon-auth-block acegi-security-sample work
            https://issues.apache.org/jira/browse/COCOON-2197
COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other
            https://issues.apache.org/jira/browse/COCOON-2173
COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page
            https://issues.apache.org/jira/browse/COCOON-2162
COCOON-2137 XSD Schemas for CForms Development
            https://issues.apache.org/jira/browse/COCOON-2137
COCOON-2114 fix sorting in TraversableGenerator
            https://issues.apache.org/jira/browse/COCOON-2114
COCOON-2108 xmodule:flow-attr Does not accept document objects
            https://issues.apache.org/jira/browse/COCOON-2108
COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer
            https://issues.apache.org/jira/browse/COCOON-2104
COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow
            https://issues.apache.org/jira/browse/COCOON-2100
COCOON-2041 WebDAV Returns improper status on PUT
            https://issues.apache.org/jira/browse/COCOON-2041
COCOON-2040 Union widget does not work with booleanfield set as case widget
            https://issues.apache.org/jira/browse/COCOON-2040
COCOON-2037 New DynamicGroup widget
            https://issues.apache.org/jira/browse/COCOON-2037
COCOON-2035 NPE in the sorter of the EnhancedRepeater
            https://issues.apache.org/jira/browse/COCOON-2035
COCOON-2032 [PATCH] Sort order in paginated repeater
            https://issues.apache.org/jira/browse/COCOON-2032
COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type="checkbox"
            https://issues.apache.org/jira/browse/COCOON-2030
COCOON-2018 Use thread context class loader to load custom binding classes
            https://issues.apache.org/jira/browse/COCOON-2018
COCOON-2017 More output beautification options for serializers
            https://issues.apache.org/jira/browse/COCOON-2017
COCOON-2015 Doctype added twice because root element (html) is inlined
            https://issues.apache.org/jira/browse/COCOON-2015
COCOON-2002 HTML transformer  only works with latin-1 characters
            https://issues.apache.org/jira/browse/COCOON-2002
COCOON-1974 Donating ContextAttributeInputModule
            https://issues.apache.org/jira/browse/COCOON-1974
COCOON-1973 CaptchaValidator: allow case-insensitive matching
            https://issues.apache.org/jira/browse/COCOON-1973
COCOON-1964 Redirects inside a block called via the servlet protocol fail
            https://issues.apache.org/jira/browse/COCOON-1964
COCOON-1963 Add a redirect action to the browser update handler
            https://issues.apache.org/jira/browse/COCOON-1963
COCOON-1960 Pipeline errors for "generator/reader already set" should provide more information
            https://issues.apache.org/jira/browse/COCOON-1960
COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object
            https://issues.apache.org/jira/browse/COCOON-1949
COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing
cform templates
            https://issues.apache.org/jira/browse/COCOON-1946
COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early
            https://issues.apache.org/jira/browse/COCOON-1943
COCOON-1932 [PATCH] correct styling of disabled suggestion lists
            https://issues.apache.org/jira/browse/COCOON-1932
COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2
            https://issues.apache.org/jira/browse/COCOON-1929
COCOON-1917 Request Encoding problem: multipart/form vs. url encoded
            https://issues.apache.org/jira/browse/COCOON-1917
COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList
            https://issues.apache.org/jira/browse/COCOON-1915
COCOON-1914 Text as XMLizable in EmptySelectionList
            https://issues.apache.org/jira/browse/COCOON-1914
COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
            https://issues.apache.org/jira/browse/COCOON-1899
COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin
            https://issues.apache.org/jira/browse/COCOON-1898
COCOON-1893 XML-Binding: Problem creating a new element
            https://issues.apache.org/jira/browse/COCOON-1893
COCOON-1877 [PATCH] Pageable Repeater
            https://issues.apache.org/jira/browse/COCOON-1877
COCOON-1870 Lucene block does not store attributes when instructed so
            https://issues.apache.org/jira/browse/COCOON-1870
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the rigth time
with IE
            https://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
            https://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
            https://issues.apache.org/jira/browse/COCOON-1842
COCOON-1810 [PATCH] JMSEventMessageListener does not work
            https://issues.apache.org/jira/browse/COCOON-1810
COCOON-1807 Workaround for IE Bug in

Re: Cocoon documentation

2009-12-01T20:42:32Z

Matt Whipple wrote:
> Jos Snellings wrote:
>> The documentation of cocoon-3 can be checked out as:
>> svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
>>   
> I stumbled upon the HTML deliverable of that on
> http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. 
> I'd think it would be best if the official documentation focused on
> being primarily a comprehensive reference with a quick bootstrap guide. 
> A community documentation site could then supplement that with all the
> typical tutorials/how-to's and tips & tricks which gets the reader where
> he wants to be with a straightforward, minimalist approach which then
> references the official docs and other more enlightening sources. 
> Regular articles/blog entries could then highlight the activity in the
> community, and the possibilities of various Cocoon components could be
> showcased.  Guides to all of the overlapping processes which can be
> [easily] extrapolated from existing material can be given a home so that
> a potential new developer with a specific need is provided with an
> apparent foot in the door.  Basically a site which presents a welcoming,
> active community rather than seemingly a group of scattered people
> developing in Cocoons and enabling me to make bad wordplay (such is the
> price).  To that end, an agreed upon forum would be ideal. 

Agreed. When I started to write the C3 documentation, I had the Spring
reference documentation in mind. I think it's one of the best examples
because it focuses on describing the technology and the concepts.

As a forum for everything beyond reference docs we could either use
Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon)

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

[jira] Updated: (COCOON3-3) Provide an XInclude transformer as a PipelineComponent

2009-12-01T20:19:20Z


     [ https://issues.apache.org/jira/browse/COCOON3-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simone Tripodi updated COCOON3-3:
---------------------------------

    Attachment: XIncludeTransformer.patch

Last uploaded patch (XIncludeTransformer.patch ~92K) contains a new implementation of the
XInclude processor based strictly only on SAX APIs, no more DOM to extract elements by ids
or by xpath expressions.

Like always, don't hesitate to contact me if some help or extra work is needed to apply the
patch.

> Provide an XInclude transformer as a PipelineComponent
> ------------------------------------------------------
>
>                 Key: COCOON3-3
>                 URL: https://issues.apache.org/jira/browse/COCOON3-3
>             Project: Cocoon 3
>          Issue Type: Improvement
>          Components: cocoon-sax
>    Affects Versions: 3.0.0-alpha-1
>            Reporter: Simone Tripodi
>            Assignee: Cocoon Developers Team
>            Priority: Minor
>             Fix For: 3.0.0-alpha-3
>
>         Attachments: XInclude.patch, XIncludeTransformer.patch, XIncludeTransformerFixedAndApacheHeaders.patch
>
>
> Oldest versions of cocoon already contain an XInclude transformer, it could be a good
starting point:
> http://svn.eu.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XIncludeTransformer.java
> XPointer package's dependencies should be reduced to be imported in the new pipeline:
> http://svn.eu.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/xpointer
> An alternative solution could be using xerces2 APIs:
> http://xerces.apache.org/xerces2-j/faq-xinclude.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cocoon documentation

2009-12-01T16:54:54Z

Reinhard Pötz wrote:
> Matt Whipple wrote:
>   
>> Jos Snellings wrote:
>>     
>>> The documentation of cocoon-3 can be checked out as:
>>> svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
>>>   
>>>       
>> I stumbled upon the HTML deliverable of that on
>> http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. 
>> I'd think it would be best if the official documentation focused on
>> being primarily a comprehensive reference with a quick bootstrap guide. 
>> A community documentation site could then supplement that with all the
>> typical tutorials/how-to's and tips & tricks which gets the reader where
>> he wants to be with a straightforward, minimalist approach which then
>> references the official docs and other more enlightening sources. 
>> Regular articles/blog entries could then highlight the activity in the
>> community, and the possibilities of various Cocoon components could be
>> showcased.  Guides to all of the overlapping processes which can be
>> [easily] extrapolated from existing material can be given a home so that
>> a potential new developer with a specific need is provided with an
>> apparent foot in the door.  Basically a site which presents a welcoming,
>> active community rather than seemingly a group of scattered people
>> developing in Cocoons and enabling me to make bad wordplay (such is the
>> price).  To that end, an agreed upon forum would be ideal. 
>>     
>
> Agreed. When I started to write the C3 documentation, I had the Spring
> reference documentation in mind. I think it's one of the best examples
> because it focuses on describing the technology and the concepts.
>
> As a forum for everything beyond reference docs we could either use
> Daisy or the Apache Wiki. (http://wiki.apache.org/cocoon)
>
>   
My thought would be Daisy (cocoondev.org?) so the site itself can be
Cocoon powered and then the wiki can remain legacy docs.

Re: Cocoon documentation

2009-12-01T16:31:49Z

Yes, that would be it...
agreed.
On Tue, 2009-12-01 at 06:23 -0500, Matt Whipple wrote:
> Jos Snellings wrote:
> > The documentation of cocoon-3 can be checked out as:
> > svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
> >   
> I stumbled upon the HTML deliverable of that on
> http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. 
> I'd think it would be best if the official documentation focused on
> being primarily a comprehensive reference with a quick bootstrap guide. 
> A community documentation site could then supplement that with all the
> typical tutorials/how-to's and tips & tricks which gets the reader where
> he wants to be with a straightforward, minimalist approach which then
> references the official docs and other more enlightening sources. 
> Regular articles/blog entries could then highlight the activity in the
> community, and the possibilities of various Cocoon components could be
> showcased.  Guides to all of the overlapping processes which can be
> [easily] extrapolated from existing material can be given a home so that
> a potential new developer with a specific need is provided with an
> apparent foot in the door.  Basically a site which presents a welcoming,
> active community rather than seemingly a group of scattered people
> developing in Cocoons and enabling me to make bad wordplay (such is the
> price).  To that end, an agreed upon forum would be ideal. 
> > The cocoon community will be delighted at some good documentation.
> > Talking about community I fear such as an active community is to be
> > reestablished, so I think we'd better provide some sweet stuff.
> >
> > What would Reinhard think of starting with as a table of contents?
> > I will be glad to write some documentation as well. I have some goose
> > feathers available after Christmas, when I will be through the
> > experience of creating a first
> > How about you? 
> > Jos
> >
> >
> > On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote:
> >   
> >> I'm a recent transplant to Cocoon (and Java), in particular because
> >> Cocoon 3 appears as though it is/will be closely in line with my own
> >> perspective on web application development.  I'm interested in
> >> contributing to the development of the framework itself, but likely
> >> won't be able to produce anything remotely useful  for a couple months
> >> as I familiarize myself with all of the related technologies. 
> >>
> >> I've just read some of the attacks on the poor documentation of the
> >> project and the resulting difficult entry for those unfamiliar.  This
> >> is, of course, easily confirmed by the combination of woefully out of
> >> date references and dead links on the Web site (i.e. to the Daisy
> >> site).  As I am (obviously) hopeful to see Cocoon succeed, I certainly
> >> don't want it to become mired in isolation like so many good projects. 
> >>
> >> As such I'd like to try to contribute some documentation.  Is there any
> >> idea among the community as to where documentation should end up, or
> >> should I just create a new site?  Also, I'd lean towards focusing on
> >> Cocoon 3, as having documentation in place for a new release would
> >> likely have larger impact than attaching possibly overdue docs to an
> >> older, in the process of being superseded one.  This would be premature
> >> if there's no foreseeable beta....
> >>
> >>     
> >
> >
> >   
> 
>

Re: REST / Can't find URLResponseBuilder

2009-12-01T16:20:40Z

Steven Dolg schrieb:
> Johannes Lichtenberger schrieb:
>> On Sun, 2009-11-29 at 07:32 +0100, Jos Snellings wrote:
>>  
>>> In the samples, a typical use of StringTemplate is shown: a page is to
>>> be interpreted by the StringTemplate engine, and a number of properties
>>> are passed via the hashtable.
>>> The idea is that you would open a view on the object.
>>> So, - the query points to a resource
>>> - the controller decodes what the resource is and what you want (view
>>> it, update it?)
>>> - the way to view it could be: pass my resource to a StringTemplate
>>> invocation:  new Page('stringtemplateinvocation',resource);
>>>  
>>> However, I have not tried to elaborate this so far. Shall I post it 
>>> when
>>> i have a useable example?
>>>     
>>
>> Yes it would be great. My concern is that I don't want to display a
>> template page. I want to process the request (the parameters Google
>> Earth sends when zooming in) and within my Generator query a native XML
>> database system and built the algorithmic logic inside the generator
>> (what data out of the shreddered xml file is needed and has to be
>> transformed with an XSLT stylesheet). So I basically know how RESTful
>> webservices work, but I don't know how to use cocoon3 in this case (I
>> assume new Page(...) isn't the right thing to return when I just want to
>> pass the request params to my generator. So I don't want to use
>> StringTemplate in this case (but it's nontheless a great thing). So the
>> query points to a controller, which decides that it's a GET request
>> (view) and passes the parameters on to my generator (which I still have
>> to write).
>> Would be great if you or someone else could help me out (it's a project
>> in a course of our university ;-) and I thought cocoon is great for this
>> concern (get RESTful parameters, hand it on to a generator which selects
>> the needed data out of a shreddered xml file according to the
>> parameters, then transform the xml fragments with a XSLT stylesheet and
>> serialize the result, so that Google Earth can use the KML fragments
>> generated).
>>   
>
> Hi,
>
> I'm not entirely sure I understand what you want to do (or to be more 
> precise which parts already exist and which don't), but I'll try to 
> improvise.

I just found your other mail from earlier ("REST / own generator") and 
it seems your only problem is to access the HTTP request parameters.
If that's the case ditch the controller and access them in your 
generator like I explained in the first approach below.
They are already there - no need to use a controller to make them 
accessible...

> I can imagine two approaches:
>
> 1.
> You can access HTTP request parameters from a generator (or any other 
> PipelineComponent - a Controller is just a fancy PipelineComponent) as 
> well.
> The SitemapServlet will add all HTTP request parameters to the 
> invocation that is built to handle the request and will be passed to 
> every PipelineComponent in the 
> "org.apache.cocoon.pipeline.component.PipelineComponent.setup(Map Object>)" method. The keys will be the names of the HTTP request 
> parameters.
> Read the parameters in your generator, and then perform the rest of 
> your logic.
>
>
> 2.
> Keep the controller and do all pre-processing necessary within the 
> controller: the XML DB, XSLT (if you just want to use XLST have a look 
> at org.apache.cocoon.sax.util.TransformationUtils) etc.
> When you are ready, store the data required for your generator in a 
> parameter map (just like you did in the code fragment you posted) and 
> delegate to a pipeline that uses your generator.
> The generator will be able to access the data the same way I described 
> above.
> Only difference would be that in this case the key would be defined by 
> your controller, while in the approach above the key would be 
> determined by the name of the HTTP request parameter.
>
>
> hth,
> Steven
>
>> Thank you,
>> Johannes
>>
>>   
>

Re: REST / Can't find URLResponseBuilder

2009-12-01T16:14:07Z

Johannes Lichtenberger schrieb:
> On Sun, 2009-11-29 at 07:32 +0100, Jos Snellings wrote:
>   
>> In the samples, a typical use of StringTemplate is shown: a page is to
>> be interpreted by the StringTemplate engine, and a number of properties
>> are passed via the hashtable.
>> The idea is that you would open a view on the object.
>> So, 
>> - the query points to a resource
>> - the controller decodes what the resource is and what you want (view
>> it, update it?)
>> - the way to view it could be: pass my resource to a StringTemplate
>> invocation:  new Page('stringtemplateinvocation',resource);
>>  
>> However, I have not tried to elaborate this so far. Shall I post it when
>> i have a useable example?
>>     
>
> Yes it would be great. My concern is that I don't want to display a
> template page. I want to process the request (the parameters Google
> Earth sends when zooming in) and within my Generator query a native XML
> database system and built the algorithmic logic inside the generator
> (what data out of the shreddered xml file is needed and has to be
> transformed with an XSLT stylesheet). So I basically know how RESTful
> webservices work, but I don't know how to use cocoon3 in this case (I
> assume new Page(...) isn't the right thing to return when I just want to
> pass the request params to my generator. So I don't want to use
> StringTemplate in this case (but it's nontheless a great thing). So the
> query points to a controller, which decides that it's a GET request
> (view) and passes the parameters on to my generator (which I still have
> to write). 
>
> Would be great if you or someone else could help me out (it's a project
> in a course of our university ;-) and I thought cocoon is great for this
> concern (get RESTful parameters, hand it on to a generator which selects
> the needed data out of a shreddered xml file according to the
> parameters, then transform the xml fragments with a XSLT stylesheet and
> serialize the result, so that Google Earth can use the KML fragments
> generated).
>   

Hi,

I'm not entirely sure I understand what you want to do (or to be more 
precise which parts already exist and which don't), but I'll try to 
improvise.
I can imagine two approaches:

1.
You can access HTTP request parameters from a generator (or any other 
PipelineComponent - a Controller is just a fancy PipelineComponent) as well.
The SitemapServlet will add all HTTP request parameters to the 
invocation that is built to handle the request and will be passed to 
every PipelineComponent in the 
"org.apache.cocoon.pipeline.component.PipelineComponent.setup(Map)" method. The keys will be the names of the HTTP request parameters.
Read the parameters in your generator, and then perform the rest of your 
logic.

2.
Keep the controller and do all pre-processing necessary within the 
controller: the XML DB, XSLT (if you just want to use XLST have a look 
at org.apache.cocoon.sax.util.TransformationUtils) etc.
When you are ready, store the data required for your generator in a 
parameter map (just like you did in the code fragment you posted) and 
delegate to a pipeline that uses your generator.
The generator will be able to access the data the same way I described 
above.
Only difference would be that in this case the key would be defined by 
your controller, while in the approach above the key would be determined 
by the name of the HTTP request parameter.

hth,
Steven

> Thank you,
> Johannes
>
>

Re: StringTemplateGenerator

2009-12-01T15:55:14Z

Jos Snellings schrieb:
> Dear,
>
> Just a small question, testing:
> When I get:
> java.lang.NullPointerException
> 	at
> org.apache.cocoon.stringtemplate.StringTemplateGenerator.constructCacheKey(StringTemplateGenerator.java:75)
>
> I notice that StringTemplateGenerator has two constructors: one with a
> 'source' argument, and one without.
> The one without source argument is called.
> Does this make sense? Am I making a mistake in the sitemap?
> Here's the code:
>   
>        type="string-template"/>
>        
>   
>   

Hi,

the two constructors serve two different purposes:
* the default contructor is used by the sitemap to assemble pipelines in 
the way described by the sitemap definition (so that one being called is 
expected in your case)
* the constructor with the source parameter is intended for the 
programmatic use (pure convenience)

Looking at the code in the StringTemplateGenerator suggests that the 
source you're passing "testcases/{map:name}.st" cannot be resolved for 
the "name" you are using, thus resolving in the URL being null and 
causing a NPE.

URL resolution in your case (using a sitemap) is performed by the 
GenerateNode, which delegates back to the Invocation(Impl).
No logging in that area *sigh* so you will either need to double check 
your "name" parameter and resources and/or go debugging...

The sitemap fragment you posted is perfectly fine BTW.


hth,
Steven

> Thanks,
> Jos
>
>

Re: Cocoon documentation

2009-12-01T11:23:12Z


Jos Snellings wrote:
> The documentation of cocoon-3 can be checked out as:
> svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs\
>   
I stumbled upon the HTML deliverable of that on
http://people.apache.org/~reinhard/c3-ref/html/ after sending my email. 
I'd think it would be best if the official documentation focused on
being primarily a comprehensive reference with a quick bootstrap guide. 
A community documentation site could then supplement that with all the
typical tutorials/how-to's and tips & tricks which gets the reader where
he wants to be with a straightforward, minimalist approach which then
references the official docs and other more enlightening sources. 
Regular articles/blog entries could then highlight the activity in the
community, and the possibilities of various Cocoon components could be
showcased.  Guides to all of the overlapping processes which can be
[easily] extrapolated from existing material can be given a home so that
a potential new developer with a specific need is provided with an
apparent foot in the door.  Basically a site which presents a welcoming,
active community rather than seemingly a group of scattered people
developing in Cocoons and enabling me to make bad wordplay (such is the
price).  To that end, an agreed upon forum would be ideal. 
> The cocoon community will be delighted at some good documentation.
> Talking about community I fear such as an active community is to be
> reestablished, so I think we'd better provide some sweet stuff.
>
> What would Reinhard think of starting with as a table of contents?
> I will be glad to write some documentation as well. I have some goose
> feathers available after Christmas, when I will be through the
> experience of creating a first
> How about you? 
> Jos
>
>
> On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote:
>   
>> I'm a recent transplant to Cocoon (and Java), in particular because
>> Cocoon 3 appears as though it is/will be closely in line with my own
>> perspective on web application development.  I'm interested in
>> contributing to the development of the framework itself, but likely
>> won't be able to produce anything remotely useful  for a couple months
>> as I familiarize myself with all of the related technologies. 
>>
>> I've just read some of the attacks on the poor documentation of the
>> project and the resulting difficult entry for those unfamiliar.  This
>> is, of course, easily confirmed by the combination of woefully out of
>> date references and dead links on the Web site (i.e. to the Daisy
>> site).  As I am (obviously) hopeful to see Cocoon succeed, I certainly
>> don't want it to become mired in isolation like so many good projects. 
>>
>> As such I'd like to try to contribute some documentation.  Is there any
>> idea among the community as to where documentation should end up, or
>> should I just create a new site?  Also, I'd lean towards focusing on
>> Cocoon 3, as having documentation in place for a new release would
>> likely have larger impact than attaching possibly overdue docs to an
>> older, in the process of being superseded one.  This would be premature
>> if there's no foreseeable beta....
>>
>>     
>
>
>

Re: [OT] [Job] Cocoon developer required (London)

2009-12-01T09:16:59Z

in the HTML
Robby Pelssers wrote:
> What did you do to make it crash? ;-)  I can open the home page without
> any issues.
>   

I've tried it on another XP machine and an Ubuntu system and... Doh! 
both work fine.

I suspect my machine doesn't like the video object in the HTML for some 
reason.  I have performed video editing on it before so maybe I have an 
errant codec installed somewhere.

As you were! ;-)

Regards,
David Legg

Re: Cocoon documentation

2009-12-01T06:22:46Z

The documentation of cocoon-3 can be checked out as:
svn co http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs

The cocoon community will be delighted at some good documentation.
Talking about community I fear such as an active community is to be
reestablished, so I think we'd better provide some sweet stuff.

What would Reinhard think of starting with as a table of contents?
I will be glad to write some documentation as well. I have some goose
feathers available after Christmas, when I will be through the
experience of creating a first app.

How about you? 
Jos


On Mon, 2009-11-30 at 08:07 -0500, Matt Whipple wrote:
> I'm a recent transplant to Cocoon (and Java), in particular because
> Cocoon 3 appears as though it is/will be closely in line with my own
> perspective on web application development.  I'm interested in
> contributing to the development of the framework itself, but likely
> won't be able to produce anything remotely useful  for a couple months
> as I familiarize myself with all of the related technologies. 
> 
> I've just read some of the attacks on the poor documentation of the
> project and the resulting difficult entry for those unfamiliar.  This
> is, of course, easily confirmed by the combination of woefully out of
> date references and dead links on the Web site (i.e. to the Daisy
> site).  As I am (obviously) hopeful to see Cocoon succeed, I certainly
> don't want it to become mired in isolation like so many good projects. 
> 
> As such I'd like to try to contribute some documentation.  Is there any
> idea among the community as to where documentation should end up, or
> should I just create a new site?  Also, I'd lean towards focusing on
> Cocoon 3, as having documentation in place for a new release would
> likely have larger impact than attaching possibly overdue docs to an
> older, in the process of being superseded one.  This would be premature
> if there's no foreseeable beta....
>

RE: [OT] [Job] Cocoon developer required (London)

2009-11-30T17:25:46Z

What did you do to make it crash? ;-)  I can open the home page without
any issues.

Robby

-----Original Message-----
From: David Legg [mailto:david.legg@searchevent.co.uk] 
Sent: Monday, November 30, 2009 3:42 PM
To: dev@cocoon.apache.org
Subject: Re:[OT] [Job] Cocoon developer required (London)

Hi Robin,

I thought I'd take a peek at your site jacaranda.co.uk and do you know 
what.... it crashed my Firefox browser!  Thinking it was some 
peculiarity of Firefox I tried IE7 and do you now what... it crashed 
that too :-)

Regards,
David Legg

Robin Wyles wrote:
> Hi everyone,
>
> It's been a very long time since I've posted here (apologies, and 
> hopefully more on that soon!)...
>
> We're looking for a Cocoon developer to help me out with the support 
> and further development of our Cocoon based applications.
>
> We need strong skills in Cocoon, Spring, Linux, and preferably someone

> based in or near to London, UK. We're looking for someone which we can

> work with on a regular basis, and possibly even as a full-time
position.
>
> If you're at all interested drop me an email with a little info about 
> yourself: robin@jacaranda.co.uk
>
> Thanks!
>
> Robin
>
>
>
>
>
>
>
>
>

Re:[OT] [Job] Cocoon developer required (London)

2009-11-30T14:41:33Z

Hi Robin,

I thought I'd take a peek at your site jacaranda.co.uk and do you know 
what.... it crashed my Firefox browser!  Thinking it was some 
peculiarity of Firefox I tried IE7 and do you now what... it crashed 
that too :-)

Regards,
David Legg

Robin Wyles wrote:
> Hi everyone,
>
> It's been a very long time since I've posted here (apologies, and 
> hopefully more on that soon!)...
>
> We're looking for a Cocoon developer to help me out with the support 
> and further development of our Cocoon based applications.
>
> We need strong skills in Cocoon, Spring, Linux, and preferably someone 
> based in or near to London, UK. We're looking for someone which we can 
> work with on a regular basis, and possibly even as a full-time position.
>
> If you're at all interested drop me an email with a little info about 
> yourself: robin@jacaranda.co.uk
>
> Thanks!
>
> Robin
>
>
>
>
>
>
>
>
>

Cocoon documentation

2009-11-30T13:07:16Z

I'm a recent transplant to Cocoon (and Java), in particular because
Cocoon 3 appears as though it is/will be closely in line with my own
perspective on web application development.  I'm interested in
contributing to the development of the framework itself, but likely
won't be able to produce anything remotely useful  for a couple months
as I familiarize myself with all of the related technologies. 

I've just read some of the attacks on the poor documentation of the
project and the resulting difficult entry for those unfamiliar.  This
is, of course, easily confirmed by the combination of woefully out of
date references and dead links on the Web site (i.e. to the Daisy
site).  As I am (obviously) hopeful to see Cocoon succeed, I certainly
don't want it to become mired in isolation like so many good projects. 

As such I'd like to try to contribute some documentation.  Is there any
idea among the community as to where documentation should end up, or
should I just create a new site?  Also, I'd lean towards focusing on
Cocoon 3, as having documentation in place for a new release would
likely have larger impact than attaching possibly overdue docs to an
older, in the process of being superseded one.  This would be premature
if there's no foreseeable beta....

[Job] Cocoon developer required (London)

2009-11-30T13:05:39Z

Hi everyone,

It's been a very long time since I've posted here (apologies, and  
hopefully more on that soon!)...

We're looking for a Cocoon developer to help me out with the support  
and further development of our Cocoon based applications.

We need strong skills in Cocoon, Spring, Linux, and preferably  
someone based in or near to London, UK. We're looking for someone  
which we can work with on a regular basis, and possibly even as a  
full-time position.

If you're at all interested drop me an email with a little info about  
yourself: robin@jacaranda.co.uk

Thanks!

Robin

Re: REST / Can't find URLResponseBuilder

2009-11-29T12:19:06Z

On Sun, 2009-11-29 at 07:32 +0100, Jos Snellings wrote:
> In the samples, a typical use of StringTemplate is shown: a page is to
> be interpreted by the StringTemplate engine, and a number of properties
> are passed via the hashtable.
> The idea is that you would open a view on the object.
> So, 
> - the query points to a resource
> - the controller decodes what the resource is and what you want (view
> it, update it?)
> - the way to view it could be: pass my resource to a StringTemplate
> invocation:  new Page('stringtemplateinvocation',resource);
>  
> However, I have not tried to elaborate this so far. Shall I post it when
> i have a useable example?

Yes it would be great. My concern is that I don't want to display a
template page. I want to process the request (the parameters Google
Earth sends when zooming in) and within my Generator query a native XML
database system and built the algorithmic logic inside the generator
(what data out of the shreddered xml file is needed and has to be
transformed with an XSLT stylesheet). So I basically know how RESTful
webservices work, but I don't know how to use cocoon3 in this case (I
assume new Page(...) isn't the right thing to return when I just want to
pass the request params to my generator. So I don't want to use
StringTemplate in this case (but it's nontheless a great thing). So the
query points to a controller, which decides that it's a GET request
(view) and passes the parameters on to my generator (which I still have
to write). 

Would be great if you or someone else could help me out (it's a project
in a course of our university ;-) and I thought cocoon is great for this
concern (get RESTful parameters, hand it on to a generator which selects
the needed data out of a shreddered xml file according to the
parameters, then transform the xml fragments with a XSLT stylesheet and
serialize the result, so that Google Earth can use the KML fragments
generated).

Thank you,
Johannes

Re: REST / Can't find URLResponseBuilder

2009-11-29T06:32:40Z

In the samples, a typical use of StringTemplate is shown: a page is to
be interpreted by the StringTemplate engine, and a number of properties
are passed via the hashtable.
The idea is that you would open a view on the object.
So, 
- the query points to a resource
- the controller decodes what the resource is and what you want (view
it, update it?)
- the way to view it could be: pass my resource to a StringTemplate
invocation:  new Page('stringtemplateinvocation',resource);
 
However, I have not tried to elaborate this so far. Shall I post it when
i have a useable example?

Cheers,
Jos



On Sat, 2009-11-28 at 14:14 +0100, Johannes Lichtenberger wrote:
> 
> > It is now a bit hard to keep everything consistent, as there are
> still
> > changes made in the interfaces.
> 
> Hm, it can't find alpha-2 (it really seems to be alpha-2 specific --
> http://cocoon.apache.org/3.0/changes-report.html and it isn't
> released)
> and I'm not sure how to integrate the trunk version with maven. I've
> used the mvn commands described uhm somewhere (for mysite, myparent,
> mysample und mywebapp)... 
> 
> Downloading:
> http://repo1.maven.org/maven2/org/apache/cocoon/rest/cocoon-rest/3.0.0-alpha-2/cocoon-rest-3.0.0-alpha-2.jar
> [INFO] Unable to find resource

Re: REST / Can't find URLResponseBuilder

2009-11-28T13:14:05Z

On Sat, 2009-11-28 at 07:43 +0100, Jos Snellings wrote:
> org.apache.cocoon.rest.jaxrs.response.URLResponseBuilder.java
> What version do you have in your project pom? It should be alpha 2 I
> guess.
> Or build it from the svn trunk, 
> svn co http://svn.apache.org/repos/asf/cocoon/cocoon3
> 
> It is now a bit hard to keep everything consistent, as there are still
> changes made in the interfaces.

Hm, it can't find alpha-2 (it really seems to be alpha-2 specific --
http://cocoon.apache.org/3.0/changes-report.html and it isn't released)
and I'm not sure how to integrate the trunk version with maven. I've
used the mvn commands described uhm somewhere (for mysite, myparent,
mysample und mywebapp)... 

Downloading:
http://repo1.maven.org/maven2/org/apache/cocoon/rest/cocoon-rest/3.0.0-alpha-2/cocoon-rest-3.0.0-alpha-2.jar
[INFO] Unable to find resource
'org.apache.cocoon.rest:cocoon-rest:jar:3.0.0-alpha-2' in repository
central (http://repo1.maven.org/maven2)

Now I've changed it back to:

	return new Page("servlet:/controller/screen", data);

and I have a generator, let's say:

public class GoogleEarthGenerator extends AbstractGenerator {

  public void execute() {
    System.out.println();
  }
  
}

How do I print out the reqparam from the data HashMap?

I'm really new to Cocoon, but I need REST ;-)

regards,
Johannes

Re: REST / Can't find URLResponseBuilder

2009-11-28T06:43:53Z

org.apache.cocoon.rest.jaxrs.response.URLResponseBuilder.java
What version do you have in your project pom? It should be alpha 2 I
guess.
Or build it from the svn trunk, 
svn co http://svn.apache.org/repos/asf/cocoon/cocoon3

It is now a bit hard to keep everything consistent, as there are still
changes made in the interfaces.

Jos


On Sat, 2009-11-28 at 05:02 +0100, Johannes Lichtenberger wrote:
> URLResponseBuilder

REST / Can't find URLResponseBuilder

2009-11-28T04:02:00Z

Hello,

the class URLResponseBuilder can't be resolved :(

Now I have the following controller:

public class GoogleEarthController implements Get {
  @SitemapParameter
  private String mGearth;
  
  @RequestParameter
  private String reqparam;
  
  @Override
  public RestResponse doGet() throws Exception {
    final Map data = new HashMap();

    data.put("mGearth", mGearth);
    data.put("reqparam", reqparam);
    
    return new
URLResponseBuilder.newInstance("servlet:/controller/screen",
data).build();
  }

}

And I'm still not sure how to get acess to my HashMap _within_ a
pipeline:

    
      
        
          
        
      
      
        
        
      
    

Precisely within the gearth generator (which should serve dynamically
KML content (well out of a native xml database which has to be
transformed) to GoogleEarth depending on the parameters Google sent
(should be fairly trivial once I figured out how to get acess to my
HashMap and if returnin a URLResponseBuilder object is the right thing.

regards,
Johannes

Re: Cocoon3 <-> Wicket integration

2009-11-27T17:53:15Z

Gabriel Gruber wrote:
> 
> Hi Reinhard,
> 
> many thanks for your effort... this is definitly the way to go and a
> step towards giving more value to cocoon again...
> as you know we are searching for alternatives in our product-development
> which is currently cocoon / cforms based. your wicket reader seems very
> interesting for us...   as soon as I have some time I will try it out!
> 
> BTW: does the reader also work for cocoon 2.2?

No but it shouldn't be difficult to migrate it to work with 2.2 interfaces.

-- 
Reinhard P�tz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Re: Cocoon3 <-> Wicket integration

2009-11-27T17:12:54Z

Hi Reinhard,

many thanks for your effort... this is definitly the way to go and a step 
towards giving more value to cocoon again...
as you know we are searching for alternatives in our product-development 
which is currently cocoon / cforms based. your wicket reader seems very 
interesting for us...   as soon as I have some time I will try it out!

BTW: does the reader also work for cocoon 2.2?

cheers,
Gabriel




Reinhard P�tz  
26.11.2009 09:13
Please respond to
dev@cocoon.apache.org


To
dev@cocoon.apache.org
cc

Subject
Cocoon3 <-> Wicket integration







Since I was asked several times off-list and there have also been some
mails on the users list asking about the best way to integrate Cocoon
with Wicket, I invested some time into a first implementation. Actually
there are five ideas that I have:

 a) An IRequestTargetUrlCodingStrategy wrapping a Cocoon sitemap
 b) An IRequestTargetUrlCodingStrategy wrapping a Cocoon pipeline
 c) A page component wrapping a Cocoon pipeline
 d) A Wicket reader to be used in Cocoon sitemaps
 e) Wicket generator/transformer, again to be used in sitemaps

a) and b) are useful to add a couple of pipelines to your Wicket
application. c) helps if you want to use a Cocoon pipeline to provide
the content of some parts of a page.

d) and e) help to run a Wicket application in parallel with Cocoon while
Cocoon remains the "leading" framework.

                                   - o -

I added implementations and samples for a, c and d to the SVN. The
generic parts are in the cocoon-wicket module, the Cocoon/Wicket samples
in cocoon-samples and the Wicket/Cocoon samples in
cocoon-samples-wicket-webapp.

I also wrote some initial documentation that you can find at
http://people.apache.org/~reinhard/c3-ref/html/wicket-integration.html

                                   - o -

Currently it's rather a proof-of-concept (especially the reader) than
something that you should use in production, but hopefully a first step
and a basis for further discussions if this is of help to others.

Let me know if this is of interest to you and what you think about the
different approaches.

And finally many thanks to Steven who helped me to hunt down some
bugs in the reader component.

-- 
Reinhard P�tz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________