from:"Jos Snellings"


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

Jos Snellings updated COCOON3-126:
--

Attachment: cocoon-sitemap-COCOON3-126-2.patch

Changes to PrototypePipelineComponentFactory

> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, 
> cocoon-sax-COCOON3-126.patch, cocoon-sitemap-COCOON3-126-1.patch, 
> cocoon-sitemap-COCOON3-126-2.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not


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

Jos Snellings updated COCOON3-126:
--

Attachment: cocoon-sitemap-COCOON3-126-1.patch

> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, 
> cocoon-sax-COCOON3-126.patch, cocoon-sitemap-COCOON3-126-1.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not


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

Jos Snellings updated COCOON3-126:
--

Attachment: cocoon-sax-COCOON3-126.patch

Changes in XSLTTransformer.

> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, 
> cocoon-sax-COCOON3-126.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not


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

Jos Snellings updated COCOON3-126:
--

Attachment: CachingXSLTTransformer.java

The XLSTTransformer with internal LRU cache.

> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: CachingXSLTTransformer.java, cocoon3-126.patch, 
> cocoon-sax-COCOON3-126.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not


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

Jos Snellings commented on COCOON3-126:
---

True, so here is a solution that uses the injection in cocoon-sitemap.


> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: cocoon3-126.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: COCOON3-126, xslt cache

2013-07-05 Thread Jos Snellings

Hi Simo (et al),

1. I do not get the point defining the 'cache' interface.
The simplest would be to allow a switch in the constructor:

In that case, forget the injection:   "@Autowire private Settings settings;"

public XSLTTransformer(boolean enableLRUCache)
public XSLTTransformer(final URL url, boolean enableLRUCache)

If the behaviour 'without LRU Cache' is only desired from within the
sitemap, the first constructor is enough.
The parameter can be passed through through "setConfiguration" or setup().
Aren't 'settings'  already a part of the
cocoon object that comes with the setup parameters.

2. Alternative: create two classes:

public class XSLTTransformerLRU extends AbstractSAXTransformer implements
CachingPipelineComponent

public class XSLTTransformer extends AbstractSAXTransformer implements
CachingPipelineComponent

I would say: the first is simpler.

Cheers,
Jos



On Tue, Jul 2, 2013 at 11:38 AM, Simone Tripodi wrote:

> Hi Jos,
>
> the most important thing is IMHO having the XSLT transformer
> dependencies-less as much as we can - I suggest to define a "cache"
> interface (with a basic implementation) provided to XSLT transformer
> (via constructor), then users are free to use whatever implementation
> they need/prefer.
>
> Having a default implementation would be a strict constraint, while
> users should be able to plug their integration module depending to
> their use case.
>
> Does it sound reasonable?
>
> I have ~0 spare cycles to OSS ATM, but I promise to have a look at
> your patch during the WE, so I can at least provide you more
> feedbacks.
>
> Have a nice day, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
>
> On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings
>  wrote:
> > Hi Francesco et al,
> >
> > I proposed a patch for COCOON3-126, on the configurability of using an
> LRU
> > cache for
> > xslt transformations. I am not too happy with it though.
> >
> > I would like to have a member function to set "isCacheEnabled", or to set
> > this at setup.
> > However, the resource is loaded in the constructor.
> > Would it be better to add a boolean "isCacheEnabled' to a constructor,
> > leaving the default
> > to "yes"?
> >
> > What do you think?
> >
> > Kind regards,
> > Jos
> >
> > --
> > We should be careful to get out of an experience only the wisdom that is
> > in it - and stay there, lest we be like the cat that sits down on a hot
> > stove-lid.  She will never sit down on a hot stove-lid again - and that
> > is well; but also she will never sit down on a cold one any more.
> > -- Mark Twain
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 <http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html>

Re: [jira] [Commented] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not

2013-07-02 Thread Jos Snellings

I completely agree !
(see also Simo's idea)


On Wed, Jul 3, 2013 at 12:30 AM, Thorsten Scherler (JIRA)
wrote:

>
> [
> https://issues.apache.org/jira/browse/COCOON3-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13698330#comment-13698330]
>
> Thorsten Scherler commented on COCOON3-126:
> ---
>
> I do not think it is a good idea to use the spring injection  here.
>
> Have a look at
> http://svn.apache.org/viewvc?view=revision&revision=r1447255 I think
> passing the config via parameter is much more flexible and do not force to
> use spring.
>
> Can you attach a patch that is more in the spirit of the commit I linked
> above?
>
>
>
> > Make configurable whether xslt transformer component uses LRU cache or
> not
> >
> --
> >
> > Key: COCOON3-126
> > URL: https://issues.apache.org/jira/browse/COCOON3-126
> > Project: Cocoon 3
> >  Issue Type: Improvement
> >  Components: cocoon-sax
> >Affects Versions: 3.0.0-beta-1
> >Reporter: Jos Snellings
> >Priority: Minor
> > Fix For: 3.0.0-beta-1
> >
> > Attachments: cocoon3-126.patch
> >
> >
> > The XSLT pipeline component should be aware of the following setting in
>  
> >  value="true|false|True|False"/>
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 <http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html>

Re: COCOON3-126, xslt cache

2013-07-02 Thread Jos Snellings

Yet, as a Roman, you enjoy a different likelihood for sunny weather :-).
Nonetheless, getting inspiration is very important!

Jos


On Tue, Jul 2, 2013 at 1:12 PM, Simone Tripodi wrote:

> >
> > We can work out a proposal during the weekend, (though it will be very
> nice
> > weather in Belgium).
> >
>
> we are having sunny days in Rome as well (finally!) so I'll do some
> work in the night on the terrace :)
>
> have a nice day, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain

Re: COCOON3-126, xslt cache

2013-07-02 Thread Jos Snellings

Yes, Simo, that is a good approach!
I think it is worth the work in order to keep the cocoon base classes tidy.

We can work out a proposal during the weekend, (though it will be very nice
weather in Belgium).

Cheers,
Jos


On Tue, Jul 2, 2013 at 11:38 AM, Simone Tripodi wrote:

> Hi Jos,
>
> the most important thing is IMHO having the XSLT transformer
> dependencies-less as much as we can - I suggest to define a "cache"
> interface (with a basic implementation) provided to XSLT transformer
> (via constructor), then users are free to use whatever implementation
> they need/prefer.
>
> Having a default implementation would be a strict constraint, while
> users should be able to plug their integration module depending to
> their use case.
>
> Does it sound reasonable?
>
> I have ~0 spare cycles to OSS ATM, but I promise to have a look at
> your patch during the WE, so I can at least provide you more
> feedbacks.
>
> Have a nice day, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
>
> On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings
>  wrote:
> > Hi Francesco et al,
> >
> > I proposed a patch for COCOON3-126, on the configurability of using an
> LRU
> > cache for
> > xslt transformations. I am not too happy with it though.
> >
> > I would like to have a member function to set "isCacheEnabled", or to set
> > this at setup.
> > However, the resource is loaded in the constructor.
> > Would it be better to add a boolean "isCacheEnabled' to a constructor,
> > leaving the default
> > to "yes"?
> >
> > What do you think?
> >
> > Kind regards,
> > Jos
> >
> > --
> > We should be careful to get out of an experience only the wisdom that is
> > in it - and stay there, lest we be like the cat that sits down on a hot
> > stove-lid.  She will never sit down on a hot stove-lid again - and that
> > is well; but also she will never sit down on a cold one any more.
> > -- Mark Twain
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain
 <http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html>

COCOON3-126, xslt cache

2013-07-02 Thread Jos Snellings

Hi Francesco et al,

I proposed a patch for COCOON3-126, on the configurability of using an LRU
cache for
xslt transformations. I am not too happy with it though.

I would like to have a member function to set "isCacheEnabled", or to set
this at setup.
However, the resource is loaded in the constructor.
Would it be better to add a boolean "isCacheEnabled' to a constructor,
leaving the default
to "yes"?

What do you think?

Kind regards,
Jos

-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain

Use LRU cache

2013-06-24 Thread Jos Snellings

Hi,

Just reported the issue and proposed a patch, though I am not very happy
with it.

+ :  it intervenes only in cocoon-sax
-  : it introduces a new dependency (on spring).
Question: would it be better to decide in cocoon-sitemap if an LRU cache is
used?

The constructor would have an extra parameter then. the template is loaded
(or not) in the
constructor, which is a bit early.

What do you think?

Cheers,
Jos


-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain

[jira] [Updated] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not

2013-06-24 Thread Jos Snellings (JIRA)


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

Jos Snellings updated COCOON3-126:
--

Attachment: cocoon3-126.patch

Patch solving the issue from xslt transformer alone.

Not too happy with it:
Should it not be chosen in cocoon-sitemap if an lru 
cache is to be used? Leave it up to you.

> Make configurable whether xslt transformer component uses LRU cache or not
> --
>
> Key: COCOON3-126
> URL: https://issues.apache.org/jira/browse/COCOON3-126
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-sax
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: cocoon3-126.patch
>
>
> The XSLT pipeline component should be aware of the following setting in  
> 
>  value="true|false|True|False"/>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COCOON3-126) Make configurable whether xslt transformer component uses LRU cache or not

2013-06-24 Thread Jos Snellings (JIRA)

Jos Snellings created COCOON3-126:
-

 Summary: Make configurable whether xslt transformer component uses 
LRU cache or not
 Key: COCOON3-126
 URL: https://issues.apache.org/jira/browse/COCOON3-126
 Project: Cocoon 3
  Issue Type: Improvement
  Components: cocoon-sax
Affects Versions: 3.0.0-beta-1
Reporter: Jos Snellings
Priority: Minor
 Fix For: 3.0.0-beta-1


The XSLT pipeline component should be aware of the following setting in  





--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Getting Exception.getMessage in map:handle-errors

2013-04-17 Thread Jos Snellings

Hi Ivan,

Please try : jexl:cocoon.exception.messsage

I don't have my cocoon environment handy here, but odds are good that it
works.
Jos


On Wed, Apr 17, 2013 at 5:35 PM, Ivan Lagunov  wrote:

> Hello,
>
> ** **
>
> Is it possible to access fields of the thrown Exception inside
> map:handle-errors?
>
> ** **
>
> I want to do something like this:
>
> 
>
>   
>
> 
>
>   
>
> 
>
>   
>
>   
>
> 
>
>   
>
> 
>
> ** **
>
> Where selector is defined as following:
>
>src="org.apache.cocoon.selection.ExceptionSelector">
>
>  class="org.apache.cocoon.ProcessingException"/>
>
>   
>
> ** **
>
> Any ideas how to achieve this?
>
> ** **
>
> Best regards,
>
> Ivan Lagunov
>
> ** **
>
> ** **
>



-- 
We should be careful to get out of an experience only the wisdom that is
in it - and stay there, lest we be like the cat that sits down on a hot
stove-lid.  She will never sit down on a hot stove-lid again - and that
is well; but also she will never sit down on a cold one any more.
-- Mark Twain

Re: [DISCUSS] Fix for COCOON3-105

2012-12-07 Thread Jos Snellings

In shorthand: What are the implications then?
Bottomline:
- "a block context" is addressable within the sitemap
  load resource from another block context is possible via 'classpath'.
  The root of every block is available on the classpath?
- different web applications relying on cocoon3 can deploy blocks with the
same name
  they won't interfere with each other?

Best,
Jos

On Fri, Dec 7, 2012 at 12:56 PM, Robby Pelssers wrote:

> I might have time to check this weekend but I can't guarantee it.
>
> Robby
>
> -Original Message-
> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
> Sent: Friday, December 07, 2012 12:50 PM
> To: dev@cocoon.apache.org
> Subject: Re: [DISCUSS] Fix for COCOON3-105
>
> Hi all,
> any reaction on this? Shall I just apply such huge patch without anyone
> else's confirmation??!?
>
> Regards.
>
> On 03/12/2012 16:38, Francesco Chicchiriccò wrote:
> > Hi all,
> > I have finally elaborated a fix for COCOON3-105 and now I am able to
> > run more C3-based webapps in the same servlet container.
> >
> > I have also added a comment explaining the way I have fixed the issue:
> > as you can see, it is a considerable change, so I'd like to get your
> > feedback before applying.
> >
> > Please take a look and let me know.
> >
> > Regards.
> >
> > On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote:
> >>  [
> >> https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.
> >> jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1
> >> 3508800#comment-13508800
> >> ]
> >>
> >> Francesco Chicchiriccò commented on COCOON3-105:
> >> 
> >>
> >> Please evaluate the attached patch (COCOON3-105.patch).
> >>
> >> The patch is quite pervasive and I've seen that it might also cause
> >> some troubles when applying: if you find any .rej or .orig files
> >> (after application), please remove.
> >>
> >> This patch basically removes any reference to the blockcontext:/
> >> protocol - as you can see there is no more dependency on
> >> cocon-block-deployment.
> >> The blockcontext:/ protocol has been replaced by a classpath:/
> >> protocol implementation, working together with the JVM's jar:/ protocol.
> >>
> >> I have also prepared a demo project for this [1]: after having "mvn
> >> clean install" on the patched C3 source tree, just clone, switch to
> >> branch COCOON3-105 and compile by running
> >>
> >> mvn clean package
> >>
> >> then launch via
> >>
> >> mvn cargo:run
> >>
> >> You will get an Apache Tomcat instance listening on  containing
> >> two distinct C3 webapps; access URLs are
> >>
> >> http://localhost:/mywebapp/
> >> http://localhost:/mywebapp2/mysite/
> >> http://localhost:/mywebapp2/mysite2/
> >>
> >> e.g. 3 distinct blocks across 2 distinct webapps.
> >>
> >> Please note that this fix should also work for C2.2, as far as the
> >> ClasspathURLStreamHandlerFactory class is provided - I've put this
> >> class in cocoon-servlet but we can think to move it to
> >> cocoon-servlet-service-impl, for example.
> >>
> >> [1] https://github.com/ilgrosso/cocoon3EmptyProject
> >>
> >>> webapp fails if on the same servlet container is a c2.2.1 or other
> >>> c3 webapp running
> >>> 
> >>> -
> >>>
> >>>
> >>>  Key: COCOON3-105
> >>>  URL:
> https://issues.apache.org/jira/browse/COCOON3-105
> >>>  Project: Cocoon 3
> >>>   Issue Type: Bug
> >>>   Components: cocoon-webapp
> >>> Affects Versions: 3.0.0-beta-1
> >>> Reporter: Thorsten Scherler
> >>> Assignee: Francesco Chicchiriccò
> >>> Priority: Blocker
> >>>  Fix For: 3.0.0-beta-1
> >>>
> >>>  Attachments: COCOON3-105.npe.diff, COCOON3-105.patch,
> >>> COCOON3-105.patch, cocoon-block-deployment.patch,
> >>> cocoon-servlet-service-impl.patch
> >>>
> >>>
> >>> I noticed that you cannot run 2 c3 based war in a tomcat.
> >>> To reproduce:
> >>> - seed parent via archetype
> >>> - seed block in parent via archetype
> >>> - seed block2 in parent via archetype
> >>> - seed webapp in parent via archetype
> >>> - seed webapp2 in parent via archetype where webapp depends on block
> >>> one and webapp2 depends on block2.
> >>> My sample was:
> >>> [INFO] Reactor Summary:
> >>> [INFO]
> >>> [INFO] myparent .. SUCCESS
> >>> [1.163s] [INFO] myblock ...
> >>> SUCCESS [3.611s] [INFO] mywebapp
> >>> .. SUCCESS [1.924s] [INFO]
> >>> myblock2 .. SUCCESS [1.498s]
> >>> [INFO] mywebapp2 . SUCCESS
> >>> [1.230s] [INFO]
> >>> 
> >>> 
> >>>
> >>> Now take a tomcat (I used 6) and first deploy the mywebap

Re: avalon version

2012-10-22 Thread Jos Snellings

All OK!

Maven got confused over fop dependencies. After removing a few frameworks
from the repositories it finds its way back.
All builds well now.

Thanks Francesco,
Jos

On Mon, Oct 22, 2012 at 9:11 AM, Francesco Chicchiriccò  wrote:

> On 22/10/2012 07:50, Jos Snellings wrote:
> > Dear cocooners,
> >
> > Since today, it is not possible to package cocoon 3 apps via maven
> > anymore.
> > Build is requesting:
> > org.apache.avalon.framework:avalon-framework-api:jar:4.2.0
> >
> > as well as its implementation.
> >
> > Who still needs avalon?
> > - jnet
> > - fop
> > -  ... are there others?
> >
> > Latest version of Avalon I can get is 4.3.1
> >
> > Maven is having trouble getting version 4.2.0.
>
> Which version of C3 are you running?
> Latest snapshots (3.0.0-beta-1-SNAPSHOT) don't suffer from this at all:
>
> find ~/.m2/ -name '*avalon*' -exec rm -rf {} \;
> . it.sh
> ...
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Cocoon 3: Parent ... SUCCESS [5.524s]
> [INFO] Apache Cocoon 3: Utilities  SUCCESS [2.710s]
> [INFO] Apache Cocoon 3: Pipeline . SUCCESS [1.445s]
> [INFO] Apache Cocoon 3: SAX .. SUCCESS [6.711s]
> [INFO] Apache Cocoon 3: CLI .. SUCCESS [2.794s]
> [INFO] Apache Cocoon 3: Sitemap .. SUCCESS [1.863s]
> [INFO] Apache Cocoon 3: Controller ... SUCCESS [0.757s]
> [INFO] Apache Cocoon 3: Servlet .. SUCCESS [1.137s]
> [INFO] Apache Cocoon 3: Optional . SUCCESS [7.556s]
> [INFO] Apache cocoon 3: Databases integration components . SUCCESS [1.023s]
> [INFO] Apache Cocoon 3: Monitoring ... SUCCESS [3.784s]
> [INFO] Apache Cocoon 3: REST support . SUCCESS [2.261s]
> [INFO] Apache Cocoon 3: Profiling  SUCCESS [1.546s]
> [INFO] Apache cocoon 3: Optional REST components . SUCCESS [2.826s]
> [INFO] Apache Cocoon 3: String Templates . SUCCESS [1.713s]
> [INFO] Apache Cocoon 3: Shiro integration  SUCCESS [1.062s]
> [INFO] Apache Cocoon 3: StAX . SUCCESS [2.237s]
> [INFO] Apache Cocoon 3: Wicket Integration ... SUCCESS [1.076s]
> [INFO] Apache Cocoon 3: All dependencies . SUCCESS [1.017s]
> [INFO] Apache Cocoon 3: Databases sample integration . SUCCESS [1.428s]
> [INFO] Apache Cocoon 3: Sample ... SUCCESS
> [21.878s]
> [INFO] Apache Cocoon 3: Shiro sample integration . SUCCESS [1.480s]
> [INFO] Apache Cocoon 3: Webapplication sample  SUCCESS
> [34.077s]
> [INFO] Apache Cocoon 3: Wicket Integration Webapp Sample . SUCCESS [2.606s]
> [INFO] Apache Cocoon 3: Block Archetype .. SUCCESS [2.493s]
> [INFO] Apache Cocoon 3: Parent Archetype . SUCCESS [0.508s]
> [INFO] Apache Cocoon 3: Sample Archetype . SUCCESS [3.447s]
> [INFO] Apache Cocoon 3: Web Application Archetype  SUCCESS [0.691s]
> [INFO] Apache Cocoon 3: Root . SUCCESS [0.092s]
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 1:59.295s
> [INFO] Finished at: Mon Oct 22 09:03:05 CEST 2012
> [INFO] Final Memory: 83M/500M
> [INFO]
> 
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>
>


-- 
All generous minds have a horror of what are commonly called "Facts". They
are the brute beasts of the intellectual domain.
-- Thomas Hobbes
 <http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html>

Re: avalon version

2012-10-22 Thread Jos Snellings

Hi Francesco,

This is my problem: I use FOP, and that is where the problem arises:
 Path to dependency:
  1) org.herein:thesaurus:jar:1.0.0-SNAPSHOT
  2) org.apache.xmlgraphics:fop:jar:LATEST
  3) org.apache.avalon.framework:avalon-framework-api:jar:4.2.0

Jos



On Mon, Oct 22, 2012 at 9:11 AM, Francesco Chicchiriccò  wrote:

> On 22/10/2012 07:50, Jos Snellings wrote:
> > Dear cocooners,
> >
> > Since today, it is not possible to package cocoon 3 apps via maven
> > anymore.
> > Build is requesting:
> > org.apache.avalon.framework:avalon-framework-api:jar:4.2.0
> >
> > as well as its implementation.
> >
> > Who still needs avalon?
> > - jnet
> > - fop
> > -  ... are there others?
> >
> > Latest version of Avalon I can get is 4.3.1
> >
> > Maven is having trouble getting version 4.2.0.
>
> Which version of C3 are you running?
> Latest snapshots (3.0.0-beta-1-SNAPSHOT) don't suffer from this at all:
>
> find ~/.m2/ -name '*avalon*' -exec rm -rf {} \;
> . it.sh
> ...
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Cocoon 3: Parent ... SUCCESS [5.524s]
> [INFO] Apache Cocoon 3: Utilities  SUCCESS [2.710s]
> [INFO] Apache Cocoon 3: Pipeline . SUCCESS [1.445s]
> [INFO] Apache Cocoon 3: SAX .. SUCCESS [6.711s]
> [INFO] Apache Cocoon 3: CLI .. SUCCESS [2.794s]
> [INFO] Apache Cocoon 3: Sitemap .. SUCCESS [1.863s]
> [INFO] Apache Cocoon 3: Controller ... SUCCESS [0.757s]
> [INFO] Apache Cocoon 3: Servlet .. SUCCESS [1.137s]
> [INFO] Apache Cocoon 3: Optional . SUCCESS [7.556s]
> [INFO] Apache cocoon 3: Databases integration components . SUCCESS [1.023s]
> [INFO] Apache Cocoon 3: Monitoring ... SUCCESS [3.784s]
> [INFO] Apache Cocoon 3: REST support . SUCCESS [2.261s]
> [INFO] Apache Cocoon 3: Profiling  SUCCESS [1.546s]
> [INFO] Apache cocoon 3: Optional REST components . SUCCESS [2.826s]
> [INFO] Apache Cocoon 3: String Templates . SUCCESS [1.713s]
> [INFO] Apache Cocoon 3: Shiro integration  SUCCESS [1.062s]
> [INFO] Apache Cocoon 3: StAX . SUCCESS [2.237s]
> [INFO] Apache Cocoon 3: Wicket Integration ... SUCCESS [1.076s]
> [INFO] Apache Cocoon 3: All dependencies . SUCCESS [1.017s]
> [INFO] Apache Cocoon 3: Databases sample integration . SUCCESS [1.428s]
> [INFO] Apache Cocoon 3: Sample ... SUCCESS
> [21.878s]
> [INFO] Apache Cocoon 3: Shiro sample integration . SUCCESS [1.480s]
> [INFO] Apache Cocoon 3: Webapplication sample  SUCCESS
> [34.077s]
> [INFO] Apache Cocoon 3: Wicket Integration Webapp Sample . SUCCESS [2.606s]
> [INFO] Apache Cocoon 3: Block Archetype .. SUCCESS [2.493s]
> [INFO] Apache Cocoon 3: Parent Archetype . SUCCESS [0.508s]
> [INFO] Apache Cocoon 3: Sample Archetype . SUCCESS [3.447s]
> [INFO] Apache Cocoon 3: Web Application Archetype  SUCCESS [0.691s]
> [INFO] Apache Cocoon 3: Root . SUCCESS [0.092s]
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time: 1:59.295s
> [INFO] Finished at: Mon Oct 22 09:03:05 CEST 2012
> [INFO] Final Memory: 83M/500M
> [INFO]
> 
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~ilgrosso/
>
>


-- 
All generous minds have a horror of what are commonly called "Facts". They
are the brute beasts of the intellectual domain.
-- Thomas Hobbes
 <http://www.brainyquote.com/quotes/quotes/t/thomashobb118630.html>

avalon version

2012-10-21 Thread Jos Snellings

Dear cocooners,

Since today, it is not possible to package cocoon 3 apps via maven anymore.

Build is requesting:
org.apache.avalon.framework:avalon-framework-api:jar:4.2.0

as well as its implementation.

Who still needs avalon?
- jnet
- fop
-  ... are there others?

Latest version of Avalon I can get is 4.3.1

Maven is having trouble getting version 4.2.0.

Kind regards,
Jos

-- 
All generous minds have a horror of what are commonly called "Facts". They
are the brute beasts of the intellectual domain.
-- Thomas Hobbes

Re: Cocoon Get Together on ACEU 2012 Sinsheim (was Re: Cocoon presentation link and questions about new contributions)

2012-10-13 Thread Jos Snellings

Hi all,

I can think of only one real show stopper:
the multiple web application deployment issue (block reference/name
ambiguity).
Are there any others?

Kind regards,
Jos

On Fri, Oct 12, 2012 at 2:14 PM, Francesco Chicchiriccò  wrote:

> On 11/10/2012 11:08, Thorsten Scherler wrote:
>
>  On 10/11/2012 09:22 AM, Francesco Chicchiriccò wrote:
>>
>>> On 11/10/2012 00:38, Javier Puerto wrote:
>>> ...
>>>
 I hope to see you soon in the ApacheCon,

>>> Yep, me too: who's coming??? Chance to have a small Cocoon Get Together
>>> (or just a beer) there?
>>>
>>
>> Hi all,
>>
>> I was up to write a similar mail asking about a CGT.
>>
>> We from codebusters.es will come in total 4 pers. Andy tries to come as
>> well and Simone and Francesco are there since they are speakers. Meaning we
>> have a pretty strong group and should get together to get some work on
>> cocoon done and directly commit it. ;)
>>
>
> Great idea: maybe we'll be able to remove any obstacle for a new C3
> release ;-)
>
>
>  codebusters.es is right now moving papers to be official sponsor for a
>> CocoonGetTogether on ACEU 2012 so that we could get some drink and food for
>> the hackathon.
>>
>> What is the best day for everyone? I guess Monday 05.11 would be the best
>> day, or?
>>
>> BTW 3 of us will fly in already on 1.11 and the 4th will come on the 4th.
>> We booked a private house in the area and plan to see some sights on the
>> weekend. If somebody is interested in a private house I have some contacts
>> that still may have some space left, further if somebody is interested to
>> get a beer on the weekend before let us talk. ;)
>>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~**ilgrosso/
>
>


-- 
All generous minds have a horror of what are commonly called "Facts". They
are the brute beasts of the intellectual domain.
-- Thomas Hobbes

Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)

2012-09-28 Thread Jos Snellings

Thanks, Thorsten, that makes it a lot clearer.
I will give it a second thought and get back.
Just another question: are there other use cases than:
- within xslt : document() construct
- sitemap
- controller->modelAndView
?
Now that we reanimated the thread, has anyone else ideas? I feel it is an
important issue and I would love to see it solved,
as I have myself two cocoon apps that I would like to deploy to one server.

Kind regards,
Jos

On Fri, Sep 28, 2012 at 2:29 PM, Thorsten Scherler wrote:

>  On 09/28/2012 07:24 AM, Jos Snellings wrote:
>
> Dear all,
>
> Noticing that is very interesting discussion is getting silent, I'd like
> to ask a question.
> First of all, pardon me my ignorance. (blonde, can't help it).
> So from just a high-level understanding, can I rephrase the problem?
> What we seek to accomplish is:
> * in a sitemap, being able to load resources from another sitemap,
>   according to the scheme:
>   
> * within an xslt calling
> 
> * within controller logic:  redirect, or send the reference of a
> ModelAndView
>
>
> Well the cocoon:/ is/was never a java.net handler but resolved via
> avalon/excalibur. Further the c3 correspond  would be more servlet:/
>
>
>
> So now, in C3, we want to address resources cross-block to accomplish
> modularity, right?
>
> 
>
>
> well yes and no. blockcontext:/ refers to static (resources) and not
> matches in the blockcontext sitemap. If you would want to call the block
> sitemap you would request servlet:${blockId}:/...
>
>
>
> This should be restricted to the instance of the cocoon servlet itself, so
> it can peacefully coexist with another cocoon servlet in the same JVM.
>
>
> The blockcontext protocol once installed only will work for the first
> called servlet. With the change of Fran. we do what you describe but on a
> specific point in the app. BUT we never install the protocol which makes it
> unusable outside the java route where you can pass a URLHandler to the
> context.
>
>  So you would like to avoid tweaking "URL" for the servlet without
> interfering with the rest.
>
> - something less invasive than URL.setURLStreamHandlerFactory ?
> - mechanism that keeps track of wich cocoon servlet deployed wich blocks?
>
> Is that a correct way of stating it? Not even my 10 cents, just a question.
>
>
> If we want to keep using blockcontext protocol, the handler needs a
> central place where the different paths are resolved. However due to the
> nature of the problem we can have the same name for a block in 2 different
> servlet but if we resolve the url in the connection we will have the
> problem deciding which path to return to the caller, since it can happen
> that the underlying request has no servlet context associated meaning it is
> impossible to determine which block to use.
>
> Thanks for keeping the thread alive.
>
> salu2
>
>
>
> Cheers,
> Jos
>
>
> On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler wrote:
>
>> On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:
>>
>>> Francesco Chicchiriccò created COCOON3-107:
>>> --
>>>
>>>   Summary: With latest cocoon-block-deployment and
>>> cocoon-service-impl SNAPSHOTs, integration tests fail
>>>   Key: COCOON3-107
>>>   URL: https://issues.apache.org/jira/browse/COCOON3-107
>>>   Project: Cocoon 3
>>>Issue Type: Bug
>>>Components: cocoon-sample-webapp, cocoon-servlet,
>>> cocoon-sitemap
>>>  Affects Versions: 3.0.0-beta-1
>>>  Reporter: Francesco Chicchiriccò
>>>  Priority: Critical
>>>   Fix For: 3.0.0-beta-1
>>>
>>>
>>> This is happening as a consequence of COCOON3-105.
>>>
>>> Basically, since there is no more an installed URLStreamHandlerFactory,
>>> every "new URL()" should include an instance of
>>> BlockContextURLStreamHandler.
>>>
>>> This makes every other URL loading (including XSLT sheets in a separate
>>> block, like happening for cocoon-sample-webapp) unaware of
>>> "blockcontext://" URLs.
>>>
>>>
>> Meaning we are back to square one.
>>
>> Andreas Hartman is ATM in our office and we had a small chat about the
>> underlying problem.
>> We think that blockcontext cannot work as protocol as it is for now.
>>
>> The above report shows that we need to use a URLStreamHandlerFactory to
>> be able to resolve this protocol.
>>
>> {mybl

Re: blockcontext protocol (part 2) (was Re: [jira] [Created] (COCOON3-107) ...)

2012-09-27 Thread Jos Snellings

Dear all,

Noticing that is very interesting discussion is getting silent, I'd like to
ask a question.
First of all, pardon me my ignorance. (blonde, can't help it).
So from just a high-level understanding, can I rephrase the problem?
What we seek to accomplish is:
* in a sitemap, being able to load resources from another sitemap,
  according to the scheme:
  
* within an xslt calling

* within controller logic:  redirect, or send the reference of a
ModelAndView

So now, in C3, we want to address resources cross-block to accomplish
modularity, right?



This should be restricted to the instance of the cocoon servlet itself, so
it can peacefully coexist with another cocoon servlet in the same JVM.
So you would like to avoid tweaking "URL" for the servlet without
interfering with the rest.

- something less invasive than URL.setURLStreamHandlerFactory ?
- mechanism that keeps track of wich cocoon servlet deployed wich blocks?

Is that a correct way of stating it? Not even my 10 cents, just a question.

Cheers,
Jos


On Wed, Sep 26, 2012 at 3:05 PM, Thorsten Scherler wrote:

> On 09/26/2012 10:10 AM, Francesco Chicchiriccò (JIRA) wrote:
>
>> Francesco Chicchiriccò created COCOON3-107:
>> --**
>>
>>   Summary: With latest cocoon-block-deployment and
>> cocoon-service-impl SNAPSHOTs, integration tests fail
>>   Key: COCOON3-107
>>   URL: https://issues.apache.org/**
>> jira/browse/COCOON3-107
>>   Project: Cocoon 3
>>Issue Type: Bug
>>Components: cocoon-sample-webapp, cocoon-servlet,
>> cocoon-sitemap
>>  Affects Versions: 3.0.0-beta-1
>>  Reporter: Francesco Chicchiriccò
>>  Priority: Critical
>>   Fix For: 3.0.0-beta-1
>>
>>
>> This is happening as a consequence of COCOON3-105.
>>
>> Basically, since there is no more an installed URLStreamHandlerFactory,
>> every "new URL()" should include an instance of
>> BlockContextURLStreamHandler.
>>
>> This makes every other URL loading (including XSLT sheets in a separate
>> block, like happening for cocoon-sample-webapp) unaware of
>> "blockcontext://" URLs.
>>
>>
> Meaning we are back to square one.
>
> Andreas Hartman is ATM in our office and we had a small chat about the
> underlying problem.
> We think that blockcontext cannot work as protocol as it is for now.
>
> The above report shows that we need to use a URLStreamHandlerFactory to be
> able to resolve this protocol.
>
> {myblock2=file:/home/thorsten/**src/apache/apache-tomcat-6.0.**
> 20/work/Catalina/localhost/**mywebapp2-1.0-SNAPSHOT/blocks/**myblock2/}
>
> Now if we look on the above and how we defined it, we have:
>
> in block-servlet-service.xml
>
> 
>
> will then produce the following blockcontext object:
> ${blockId}=${tomcat.work}/${**servlet_which uses the
> block}/blocks/${blockId}/
>
> Meaning that blockcontext:/ will be resolved to "${tomcat.work}/${servlet_
> **which uses the block}/blocks/"
>
> There are various problematic parts:
>
> As of the looks of it a block is treated as "servlet" mounted to a
> context.  Problematic is that the mount-path in some cases needs to become
> ="" to catch all incoming request, which means root context.
> Blocks are treated as servlets meaning you can only mount once a block (in
> a specific version of that block). If another block use this blockId it is
> not possible to use the same mount point. However that has the ultimate
> consequence that you need to manage the name of your block manually or
> ideally the ${blockId} is unique and contains the version of the block!
> However blocks are more servlets within a servlet, since without a servlet
> that has deps on them they would be not reachable.
>
> This leads to to the "real" mount point "${servlet_which uses the
> block}/{@mount-path_as defined in the block}" in the servlet context and
> the path as above. For example "blockcontext:/test" could refer to
>  "${tomcat.work}/${servlet1}/**blocks/test" or
> "${tomcat.work}/${servlet2}/**blocks/test", depending from which servlet
> the request is issued. Meaning the blockcontext protocol does not resolve
> url (Uniform (or universal) resource locator) since the resources it
> describes are not universal (due to the fixed connection to the underlying
> servlet).
>
> With all the above said the logical consequence is that the pattern of
> blockcontext would need the ${servlet_which uses the block} in it
> somewhere, but that would render the whole block concept useless if used
> within the block. That however would force a url rewritting on the fly
> where the ${servlet_which uses the block} prefixed would be injected prior
> of resolving.
>
> We tested to push the resolving logic into the handler but that failed
> since some calls have no resolvable servlet context while they issue the
> call. We succeed to inject the handler in the servlet c

[jira] [Updated] (COCOON3-106) Add cocoon site


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

Jos Snellings updated COCOON3-106:
--

Attachment: herein.patch

I am sorry, this must be a mistake ;-0


On Tue, Sep 25, 2012 at 4:36 PM, Francesco Chicchiriccò (JIRA) <




-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson


> Add cocoon site
> ---
>
> Key: COCOON3-106
> URL: https://issues.apache.org/jira/browse/COCOON3-106
> Project: Cocoon 3
>  Issue Type: Wish
>  Components: cocoon-sample-webapp
>    Reporter: Jos Snellings
>Priority: Minor
> Attachments: herein.patch, herein.patch
>
>
> I'd like the site 'thesaurus on line Editor' for the European Heritage Network
> to the cocoon 3 production sites.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COCOON3-106) Add cocoon site


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

Jos Snellings updated COCOON3-106:
--

Attachment: herein.patch

just additional 

> Add cocoon site
> ---
>
> Key: COCOON3-106
> URL: https://issues.apache.org/jira/browse/COCOON3-106
> Project: Cocoon 3
>  Issue Type: Wish
>  Components: cocoon-sample-webapp
>Reporter: Jos Snellings
>Priority: Minor
> Attachments: herein.patch
>
>
> I'd like the site 'thesaurus on line Editor' for the European Heritage Network
> to the cocoon 3 production sites.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: map:mount

2012-09-25 Thread Jos Snellings

Thanks Francesco, I added the link.
Issue COCOON3-106 ("wish").

Cheers,
Jos

On Tue, Sep 25, 2012 at 4:14 PM, Francesco Chicchiriccò  wrote:

>  On 25/09/2012 16:11, Jos Snellings wrote:
>
> Yes, please!
>
>
> Easy: just create an issue and attach a patch (an additional ...)
> of
>
>
> https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-main-site/src/site/xdoc/live_sites_3.0.xml
>
> Regards.
>
> [1]
> https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-main-site/src/site/xdoc/live_sites_3.0.xml
>
>
>  On Tue, Sep 25, 2012 at 4:07 PM, Francesco Chicchiriccò <
> ilgro...@apache.org> wrote:
>
>>  On 25/09/2012 16:05, Jos Snellings wrote:
>>
>> Hi Javier,
>>
>> Thank you, this is clear.
>> 1. I agree with the fact that the "blocks" mechanism (SSF) is more
>> modular than mounting submaps.
>> 2. That been said, I need to bear that in mind to estimate the work. Just
>> need to assess if they
>> translate into each other.
>>
>> By the way, to my knowledge there is a production site with Apache Cocoon
>> 3:
>>
>> http://thesaurus.european-heritage.net
>>
>> That is the one that I created.
>> is there another one?
>>
>>
>>  Yep: http://cocoon.apache.org/live_sites_3.0.html
>>
>> Do you want yours to be added?
>>
>> Regards.
>>
>>
>> On Tue, Sep 25, 2012 at 3:58 PM, Javier Puerto  wrote:
>>
>>> Hi Jos
>>>
>>>  2012/9/25 Jos Snellings 
>>>
>>>> Dear all,
>>>>
>>>> Considering the upgrade cost of an existing project to cocoon-3,
>>>
>>>
>>> You have to bear in mind that it's still in beta and there's some
>>> components that's are not migrated yet but we have one production site
>>> working with Apache Cocoon 3.
>>>
>>>
>>>> I have the following question:
>>>>
>>>> what happened to map:mount?
>>>>
>>>
>>> Was deprecated for 2.2.x version.
>>>
>>>
>>>>
>>>> As in:
>>>>  
>>>> >>> uri-prefix="" />
>>>>  
>>>>
>>>> It was a handy modularity mechanism to reduce the size of sitemaps.
>>>>
>>>> Is it no longer there?
>>>> Do we need it? Do we want it?
>>>>
>>>
>>> For Apache Cocoon 2.2.x and 3.0, the "block" is the new unit of
>>> modularization. You can see some examples here:
>>> http://cocoon.apache.org/2.2/1291_1_1.html
>>>
>>> It's based on Servlet Service Framework subproject. More info here:
>>>
>>> http://cocoon.apache.org/subprojects/servlet-service/servlet-service-impl/architecture.html
>>>
>>   --
>> Francesco Chicchiriccò
>>
>> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC 
>> Memberhttp://people.apache.org/~ilgrosso/
>>
>>
>
>
> --
> The doctrine of human equality reposes on this: that there is no man
> really clever who has not found that he is stupid.
> -- Gilbert K. Chesterson
>
>
>
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC 
> Memberhttp://people.apache.org/~ilgrosso/
>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

[jira] [Created] (COCOON3-106) Add cocoon site

Jos Snellings created COCOON3-106:
-

 Summary: Add cocoon site
 Key: COCOON3-106
 URL: https://issues.apache.org/jira/browse/COCOON3-106
 Project: Cocoon 3
  Issue Type: Wish
  Components: cocoon-sample-webapp
Reporter: Jos Snellings
Priority: Minor


I'd like the site 'thesaurus on line Editor' for the European Heritage Network
to the cocoon 3 production sites.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: map:mount

2012-09-25 Thread Jos Snellings

Yes, please!

On Tue, Sep 25, 2012 at 4:07 PM, Francesco Chicchiriccò  wrote:

>  On 25/09/2012 16:05, Jos Snellings wrote:
>
> Hi Javier,
>
> Thank you, this is clear.
> 1. I agree with the fact that the "blocks" mechanism (SSF) is more modular
> than mounting submaps.
> 2. That been said, I need to bear that in mind to estimate the work. Just
> need to assess if they
> translate into each other.
>
> By the way, to my knowledge there is a production site with Apache Cocoon
> 3:
>
> http://thesaurus.european-heritage.net
>
> That is the one that I created.
> is there another one?
>
>
> Yep: http://cocoon.apache.org/live_sites_3.0.html
>
> Do you want yours to be added?
>
> Regards.
>
>
> On Tue, Sep 25, 2012 at 3:58 PM, Javier Puerto  wrote:
>
>> Hi Jos
>>
>>  2012/9/25 Jos Snellings 
>>
>>> Dear all,
>>>
>>> Considering the upgrade cost of an existing project to cocoon-3,
>>
>>
>> You have to bear in mind that it's still in beta and there's some
>> components that's are not migrated yet but we have one production site
>> working with Apache Cocoon 3.
>>
>>
>>> I have the following question:
>>>
>>> what happened to map:mount?
>>>
>>
>> Was deprecated for 2.2.x version.
>>
>>
>>>
>>> As in:
>>>  
>>> >> uri-prefix="" />
>>>  
>>>
>>> It was a handy modularity mechanism to reduce the size of sitemaps.
>>>
>>> Is it no longer there?
>>> Do we need it? Do we want it?
>>>
>>
>> For Apache Cocoon 2.2.x and 3.0, the "block" is the new unit of
>> modularization. You can see some examples here:
>> http://cocoon.apache.org/2.2/1291_1_1.html
>>
>> It's based on Servlet Service Framework subproject. More info here:
>>
>> http://cocoon.apache.org/subprojects/servlet-service/servlet-service-impl/architecture.html
>>
>  --
> Francesco Chicchiriccò
>
> ASF Member, Apache Cocoon PMC and Apache Syncope PPMC 
> Memberhttp://people.apache.org/~ilgrosso/
>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

Re: map:mount

2012-09-25 Thread Jos Snellings

Hi Javier,

Thank you, this is clear.
1. I agree with the fact that the "blocks" mechanism (SSF) is more modular
than mounting submaps.
2. That been said, I need to bear that in mind to estimate the work. Just
need to assess if they
translate into each other.

By the way, to my knowledge there is a production site with Apache Cocoon 3:

http://thesaurus.european-heritage.net

That is the one that I created.
is there another one?

Kind regards,
Jos

On Tue, Sep 25, 2012 at 3:58 PM, Javier Puerto  wrote:

> Hi Jos
>
> 2012/9/25 Jos Snellings 
>
>> Dear all,
>>
>> Considering the upgrade cost of an existing project to cocoon-3,
>
>
> You have to bear in mind that it's still in beta and there's some
> components that's are not migrated yet but we have one production site
> working with Apache Cocoon 3.
>
>
>> I have the following question:
>>
>> what happened to map:mount?
>>
>
> Was deprecated for 2.2.x version.
>
>
>>
>> As in:
>>  
>> > uri-prefix="" />
>>  
>>
>> It was a handy modularity mechanism to reduce the size of sitemaps.
>>
>> Is it no longer there?
>> Do we need it? Do we want it?
>>
>
> For Apache Cocoon 2.2.x and 3.0, the "block" is the new unit of
> modularization. You can see some examples here:
> http://cocoon.apache.org/2.2/1291_1_1.html
>
> It's based on Servlet Service Framework subproject. More info here:
>
> http://cocoon.apache.org/subprojects/servlet-service/servlet-service-impl/architecture.html
>
>
>>
>> Kind regards,
>> Jos
>>
>
> Salu2.
>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

map:mount

2012-09-25 Thread Jos Snellings

Dear all,

Considering the upgrade cost of an existing project to cocoon-3, I have the
following question:

what happened to map:mount?

As in:
 

 

It was a handy modularity mechanism to reduce the size of sitemaps.

Is it no longer there?
Do we need it? Do we want it?

Kind regards,
Jos

[jira] [Closed] (COCOON3-103) Cannot pass 's to components inside of a


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

Jos Snellings closed COCOON3-103.
-

Resolution: Not A Problem

Within nested blocks, sitemap parameters should be referred to by a relative 
path
to the (ancestor) node in which they are declared.
It is just semantically not clear. 
It is not a problem, but this should be documented. I had to look in the source 
code to discover this.




> Cannot pass 's to components inside of a  
> -
>
> Key: COCOON3-103
> URL: https://issues.apache.org/jira/browse/COCOON3-103
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-sitemap
>Affects Versions: 3.0.0-beta-1
>Reporter: Jos Snellings
>  Labels: clarification
> Fix For: 3.0.0-beta-1
>
>
> Following construct is in a sitemap match of:
>   
>  
> 
> 
> 
> 
> 
> 
> 
>  value="{jexl:cocoon.request.parameter.element}"/>
> 
> 
> 
> 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: {../parameter}

2012-09-25 Thread Jos Snellings

Sorry, I want to revoke this message. (my error ;-)

On Tue, Sep 25, 2012 at 1:45 PM, Jos Snellings
wrote:

> Dear,
>
> Just did a test and saw that:
>
> parameters in "relative path" notation get translated as:
>
> 
>  
>  
>   
> 
> {../map:parameter1} ==> they do not translate.
>
> Let me have a closer look...
> Meanwhile:
>  - anyone used this notation/behaviour?
>
> Strange this did not get observed before.
>
> Jos
>



-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

{../parameter}

2012-09-25 Thread Jos Snellings

Dear,

Just did a test and saw that:

parameters in "relative path" notation get translated as:




  

{../map:parameter1}==> they do not translate.

Let me have a closer look...
Meanwhile:
 - anyone used this notation/behaviour?

Strange this did not get observed before.

Jos

Re: COCOON3-103

2012-09-25 Thread Jos Snellings

Hi Javier,

What is the best to do then?
Close the issue and keep in mind that "absolute" parameter addressing is
not used?
I think we can live with relative paths. It is just a bit awkward that a
when-matcher does
introduce a new 'level' (well, all depends on how you want to see it ;-)
but, OK, if you know it it works.

And, there is another question I had:
what happened to map:mount?

As in:
 

 


Cheers,
Jos


On Tue, Sep 25, 2012 at 12:27 PM, Javier Puerto  wrote:

> Hi Jos
>
> 2012/9/25 Jos Snellings 
>
>> Yesterday, I had a closer look upon COCOON3-103.
>> Here is a better restatement of the problem:
>> The "ObjectModel" keeps hold of the sitemap parameters and other
>> variables.
>> In SitemapParametersStack, a series of parameters is pushed upon the
>> stack
>> - whenever a 'pattern match ' occurs  (map:match element)
>> - when a "when" condition matches
>>
>> Here is a simple case that does not work:
>>
>> 
>> 
>> 
>> 
>> 
>>
>
> AFAIK, It should be:
> 
>
> (in this case, para1 = "one") :)
>
>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>> The trouble is with "getParameter" of SitemapParametersStack:
>>  - in this case, there is a match for relativeParameterMatcher,
>>  but subsequently the variable "level" is not correctly computed and only
>> the last entry is taken to hold the parameter.
>>
>> I can fix that, so that parameters always get matched if they are on the
>> stack, but my real question is:
>> what is meant to happen? Is there a "scope" foreseen for sitemap
>> parameters? Is there an 'absolute' and a 'relative' matching,
>> are notations foreseen that look like:
>>
>>  bla/blu
>>   or
>>  ../../../bla
>>
>
> I think that this was the only way to get the parameters because you can
> have nested another matcher inside with a different parameter. The "../" is
> just the notation to climb up the tree.
>
>
>>
>> and what with  /{justAName} ?
>>
>
> Also I think that absolute is not used.
>
>
>>
>> In any case, this mechanism does not work for the moment.
>>
>> If you folks can explain me what the idea is, I can gladly provide a
>> patch. I have nothing to do these days.
>>
>
> Thanks, that would be great, I've explained how I remember that it works
> but maybe someone wants to add something.
>
>
>>
>> Cheers,
>> Jos
>>
>
> Salu2
>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

COCOON3-103

2012-09-25 Thread Jos Snellings

Yesterday, I had a closer look upon COCOON3-103.
Here is a better restatement of the problem:
The "ObjectModel" keeps hold of the sitemap parameters and other variables.
In SitemapParametersStack, a series of parameters is pushed upon the stack
- whenever a 'pattern match ' occurs  (map:match element)
- when a "when" condition matches

Here is a simple case that does not work:
   














The trouble is with "getParameter" of SitemapParametersStack:
 - in this case, there is a match for relativeParameterMatcher,
 but subsequently the variable "level" is not correctly computed and only
the last entry is taken to hold the parameter.

I can fix that, so that parameters always get matched if they are on the
stack, but my real question is:
what is meant to happen? Is there a "scope" foreseen for sitemap
parameters? Is there an 'absolute' and a 'relative' matching,
are notations foreseen that look like:

 bla/blu
  or
 ../../../bla

and what with  /{justAName} ?

In any case, this mechanism does not work for the moment.

If you folks can explain me what the idea is, I can gladly provide a patch.
I have nothing to do these days.

Cheers,
Jos

Re: [jira] [Commented] (COCOON3-105) webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running

2012-09-16 Thread Jos Snellings

Hi Thorsten,

I believe having encountered this problem once.
However, it is not systematic.

Jos

On Mon, Sep 17, 2012 at 12:06 AM, Thorsten Scherler (JIRA)
wrote:

>
> [
> https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456689#comment-13456689]
>
> Thorsten Scherler commented on COCOON3-105:
> ---
>
> The problem lies in in
> org.apache.cocoon.blockdeployment.BlockContextURLStreamHandlerFactory.createURLStreamHandler
> here we create a  BlockContextURLStreamHandler extends URLStreamHandler
>
> Regarding URLStreamHandler
> /**
>  * The abstract class URLStreamHandler is the common
>  * superclass for all stream protocol handlers. A stream protocol
>  * handler knows how to make a connection for a particular protocol
>  * type, such as http, ftp, or
>  * gopher.
>  * 
>  * In most cases, an instance of a URLStreamHandler
>  * subclass is not created directly by an application. Rather, the
>  * first time a protocol name is encountered when constructing a
>  * URL, the appropriate stream protocol handler is
>  * automatically loaded.*/
>
> Which is exactly the problem in our case. Once the URLStreamHandler is
> setup for the first blockcontext as protocol the second servlet will
> directly use the java.net.URLStreamHandler and use that protocol.
>
> Meaning if you start tomcat with both apps deployed the first request of
> the first app decides which blockcontext will be associate with the block
> context protocol
>
> That happens in BlockContextURLStreamHandlerFactory where
> createURLStreamHandler is only called once with the first request the
> second then uses the old block context.
>
>
> > webapp fails if on the same servlet container is a c2.2.1 or other c3
> webapp running
> >
> -
> >
> > Key: COCOON3-105
> > URL: https://issues.apache.org/jira/browse/COCOON3-105
> > Project: Cocoon 3
> >  Issue Type: Bug
> >  Components: cocoon-webapp
> >Affects Versions: 3.0.0-beta-1
> >Reporter: Thorsten Scherler
> >Priority: Blocker
> >
> > I noticed that you cannot run 2 c3 based war in a tomcat.
> > To reproduce:
> > - seed parent via archetype
> > - seed block in parent via archetype
> > - seed block2 in parent via archetype
> > - seed webapp in parent via archetype
> > - seed webapp2 in parent via archetype
> > where webapp depends on block one and webapp2 depends on block2.
> > My sample was:
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] myparent .. SUCCESS
> [1.163s]
> > [INFO] myblock ... SUCCESS
> [3.611s]
> > [INFO] mywebapp .. SUCCESS
> [1.924s]
> > [INFO] myblock2 .. SUCCESS
> [1.498s]
> > [INFO] mywebapp2 . SUCCESS
> [1.230s]
> > [INFO]
> 
> > Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy
> it before you start to webapp or if you have it enable deploy it on a
> running instance. You should see the welcome page under something like
> http://localhost:8080/mywebapp-1.0-SNAPSHOT/
> > side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
> StringIndexOutOfBoundsException but that is another ticket I guess.
> > Now if you deploy the second webapp on a running instance it will deploy
> without problem but requesting
> > http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
> > will return a blank page and in
> > /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
> > you find:
> > 2012-09-13 22:12:46,056 ERROR http-8080-1
> org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
> RequestProcessor correctly.
> > org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't
> build sitemap from blockcontext:/myblock2/sitemap.xmap
> >   at
> org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70)
> ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> >   at
> org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
> ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
> > ...
> > Caused by: java.lang.RuntimeException: There is no block 'myblock2'
> deployed. The available blocks are
> {myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks/myblock/}.
> >   at
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getConnection(BlockContextURLConnection.java:76)
> ~[cocoon-block-deployment-1.2.1.jar:1.2.1]
> >   at
> org.apache.cocoon.blockdeployment.BlockContextURLConnection.getInputStream(BlockContextURLConnection

[jira] [Created] (COCOON3-103) Cannot pass 's to components inside of a

2012-08-28 Thread Jos Snellings (JIRA)

Jos Snellings created COCOON3-103:
-

 Summary: Cannot pass 's to components inside of a 
 
 Key: COCOON3-103
 URL: https://issues.apache.org/jira/browse/COCOON3-103
 Project: Cocoon 3
  Issue Type: Bug
  Components: cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Jos Snellings
 Fix For: 3.0.0-beta-1


Following construct is in a sitemap match of:
  

 













--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1337109 - /cocoon/cocoon3/trunk/cocoon-shiro-sample/src/main/resources/META-INF/cocoon/spring/block-application-context.xml

2012-05-11 Thread Jos Snellings

I wish that would be real soon.
I have a C3 application live. Based on my best judgement, I decided that
the beta version was stable enough.
Last winter I was bad-mouthed by some colleagues for having done this.

Jos


On Fri, May 11, 2012 at 9:04 PM, Michael Müller <
michael.muel...@mueller-bruehl.de> wrote:

> Hi Thorsten (and other cocoon developers),
>
> I recognized some activities (svn commits etc.). On the other hand, cocoon
> 3.0 is in alpha and beta stage for a long time, feeling like ages.
> Is there a roadmap available? When might it be release?
>
> Herzliche Grüße - Best Regards,
> Michael Müller
>
>
> Am 11.05.2012 13:06, schrieb thors...@apache.org:
>
>> Author: thorsten
>> Date: Fri May 11 11:06:56 2012
>> New Revision: 1337109
>>
>> URL: 
>> http://svn.apache.org/viewvc?**rev=1337109&view=rev
>> Log:
>> white noise - formating changes
>>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

COCOON3-99: cross-cultural issue

2012-05-10 Thread Jos Snellings

Dear cocooners,

COCOON3-99 is about applying a user configuration to FopFactory in
FopSerializer.
To pass the location of the configuration file in a nice and portable way,
it is addressed in the jar:
configurationUrl = this.getClass().getResource("/COB-INF/" +
userConfigurationPath);

Fine, but I am still not satisfied. I would like to locate the font file as
well in the block.
FOP however, expects , the path relative to the configuration
file to be a real directory.

As we can see from an example fragment from FOURIResolver.java:

 baseURI = new URI(base);
 String scheme = baseURI.getScheme();
 boolean directoryExists = true;
 if ("file".equals(scheme)) {
dir = FileUtils.toFile(baseURI.toURL());
directoryExists = dir.isDirectory();
}
 if (scheme == null || !directoryExists) {
String message = "base " + base + " is not a valid
directory";
if (throwExceptions) {
throw new MalformedURLException(message);
}

(this is just an example, FO is coded to read resources from expanded
archives).

What do we do?
- live in an imperfect world?
- submit patch to FOP, but to be consistent, maintenance in more places is
necessary
- cross-post this mail to FO?

I should deliver a war to a party without me having server access. I can
hear them complain when I tell that there is some maintenance necessary.

Kind regards,
Jos

-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

patch

2012-05-08 Thread Jos Snellings

Hi Francesco,

I opened issue COCOON3-99 and added a patch.
(I hope I did it right).

Ciao,
Jos

-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

[jira] [Updated] (COCOON3-99) Provide FopSerializer with an embedded user configuration present in the cocoon block

2012-05-08 Thread Jos Snellings (JIRA)


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

Jos Snellings updated COCOON3-99:
-

Attachment: patch-fopserializer.txt

A patch for adding the user configuration to
the fop serializer via a sitemap construct.

> Provide FopSerializer with an embedded user configuration present in the 
> cocoon block
> -
>
> Key: COCOON3-99
> URL: https://issues.apache.org/jira/browse/COCOON3-99
> Project: Cocoon 3
>  Issue Type: Improvement
>  Components: cocoon-optional
>Affects Versions: 3.0.0-beta-1
>    Reporter: Jos Snellings
>Priority: Minor
> Fix For: 3.0.0-beta-1
>
> Attachments: patch-fopserializer.txt
>
>
> The current FopSerializer creates an instance of FopFactory. Only the 
> defaults are used. This is a problem if you want to generate PDFs 
> from Unicode data. The Cyrillic and Greek characters have no glyphs in these 
> fonts, causing those strings to be displayed as "#" sequences.
> This patch adds an override for the method "setConfiguration" to add a user 
> configuration location via a sitemap parameter.
> In sitemap.xmap of the block, add the parameter "userConfigurationPath" 
> indicating the location of the user configuration file.
> Example:
>  
>   
>   
>
>  value="fopconf/fop.xconf"/>
>
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COCOON3-99) Provide FopSerializer with an embedded user configuration present in the cocoon block

2012-05-08 Thread Jos Snellings (JIRA)

Jos Snellings created COCOON3-99:


 Summary: Provide FopSerializer with an embedded user configuration 
present in the cocoon block
 Key: COCOON3-99
 URL: https://issues.apache.org/jira/browse/COCOON3-99
 Project: Cocoon 3
  Issue Type: Improvement
  Components: cocoon-optional
Affects Versions: 3.0.0-beta-1
Reporter: Jos Snellings
Priority: Minor
 Fix For: 3.0.0-beta-1


The current FopSerializer creates an instance of FopFactory. Only the defaults 
are used. This is a problem if you want to generate PDFs 
from Unicode data. The Cyrillic and Greek characters have no glyphs in these 
fonts, causing those strings to be displayed as "#" sequences.

This patch adds an override for the method "setConfiguration" to add a user 
configuration location via a sitemap parameter.
In sitemap.xmap of the block, add the parameter "userConfigurationPath" 
indicating the location of the user configuration file.
Example:
 
  
  
   

   
  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: userconfig for FOP in Cocoon3

2012-05-08 Thread Jos Snellings

I will do that, Francesco!
However, this patch alters the constructor. This could cause other updates.
Better override "setup"?
I think that every pipeline's component setup method is called. I will try
that and log it in the ticket.

Ciao,
Jos

On Tue, May 8, 2012 at 9:51 AM, Francesco Chicchiriccò
wrote:

> On 08/05/2012 09:48, Jos Snellings wrote:
>
>> Dear cocooners,
>>
>> We use FOP to generate a PDF publication of a thesaurus. Needing cyrillic
>> & greek we have to setup
>> a user configuration. This is not yet foreseen in the current
>> FOPSerializer.
>> Yesterday Robby and Ivan were so kind to send me a working Cocoon 2.2
>> configuration.
>> This morning, there was room to adapt it to C3.
>>
>> I suggest that we extend FOPSerializer.java a bit, to include an internal
>> configuration file & resources.:
>>
>>  public FlopSerializer(String outputFormat, String userConfigurationPath)
>> {
>>if (outputFormat == null) {
>>throw new IllegalArgumentException("The parameter
>> 'outputFormat' mustn't be null.");
>>}
>>
>>URL configurationURL = this.getClass().getResource("/**COB-INF/"
>> + userConfigurationPath);
>>
>>try {
>>DefaultConfigurationBuilder cfgBuilder = new
>> DefaultConfigurationBuilder();
>>Configuration cfg = cfgBuilder.build(**
>> configurationURL.openStream())**;
>>FOP_FACTORY.setUserConfig(cfg)**;
>>
>>this.outputFormat = outputFormat;
>>}
>>
>> This way, we can package our custom configuration and the font in the
>> block jar.
>>
>
> Hi Jos,
> this looks very nice: could you open an issue on JIRA and provide a proper
> patch for this? I would be glad to take it, then. Thanks!
>
> Regards.
>
> --
> Francesco Chicchiriccò
>
> Apache Cocoon PMC and Apache Syncope PPMC Member
> http://people.apache.org/~**ilgrosso/<http://people.apache.org/%7Eilgrosso/>
>
>


-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

userconfig for FOP in Cocoon3

2012-05-08 Thread Jos Snellings

Dear cocooners,

We use FOP to generate a PDF publication of a thesaurus. Needing cyrillic &
greek we have to setup
a user configuration. This is not yet foreseen in the current FOPSerializer.
Yesterday Robby and Ivan were so kind to send me a working Cocoon 2.2
configuration.
This morning, there was room to adapt it to C3.

I suggest that we extend FOPSerializer.java a bit, to include an internal
configuration file & resources.:

 public FlopSerializer(String outputFormat, String userConfigurationPath) {
if (outputFormat == null) {
throw new IllegalArgumentException("The parameter
'outputFormat' mustn't be null.");
}

URL configurationURL = this.getClass().getResource("/COB-INF/" +
userConfigurationPath);

try {
DefaultConfigurationBuilder cfgBuilder = new
DefaultConfigurationBuilder();
Configuration cfg =
cfgBuilder.build(configurationURL.openStream());
FOP_FACTORY.setUserConfig(cfg);

this.outputFormat = outputFormat;
}

This way, we can package our custom configuration and the font in the block
jar.

Kind regards,
Jos Snellings



-- 
The doctrine of human equality reposes on this: that there is no man
really clever who has not found that he is stupid.
-- Gilbert K. Chesterson

Re: [c3] XincludeTransformer.java weirdness

2012-01-19 Thread Jos Snellings


Hi Thorsten,

They are under 
generated-sources/javacc/org/apache/cocoon/sax/xpointer/ParseException.java
Apparently the java is only generated at build time. Don't know details 
(pom.xml has javacc-maven-plugin).


Jos


On 01/19/2012 10:56 AM, Thorsten Scherler wrote:

Hi all,

in
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XIncludeTransformer.java 



we do

import org.apache.cocoon.sax.xpointer.ParseException;
...
import org.apache.cocoon.sax.xpointer.XPointerFrameworkParser;

but in
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/xpointer/ 



There is no such classes.

I do not understand since we can build with cli without problems. In 
eclipse I can fix the project setup by adding the cocoon-sax beta jar 
to the classpath. However that is the same jar as the project, which 
does not make sense at all.


Somebody has an idea?

salu2

Re: Porting to current cocoon version

2012-01-16 Thread Jos Snellings

HI again, Wolfram,

It is not a string template script AND a generator. It is rather 'either'.
If you make a list with all the data modifying operations that the
application offers, how many would that be?
   - Let us call them "commands". They would go into a "cocoon controller".
(Or two, or three).

Some xsp will only be about presenation of data. You may have a choice
there.

You may be able to group some xsp's together.
You will probably want to move application control and navigation apart.

It all depends, I guess. But I agree it is quite some work and demands
re-verification.
However, once you get the hang of it, I guess you will find C3 more
convenient to work with that the older versions, especially if you are
familiar with spring.

I am sorry I have no better news.

Jos

On Mon, Jan 16, 2012 at 4:39 PM, Wolfram  wrote:

> It's a 10 year old app with more than 100 XSP's and specialized
> tag-librarys depending heavily on the XSP-concept.
>
> So that mean's I have to create a generator and a StringTemplate for each
> XSP. Am I right?
>
> Wolfram
>
>
>
>

Re: Porting to current cocoon version

2012-01-16 Thread Jos Snellings


Hello Wolfram,

The first. Cocoon 3 is rather a complete rewrite of the framework.
The benefit: the dependencies of the framework have been limited to a 
minimum.
A half-advantage: the scripting capabilities have been limited to 
stringtemplate. This sort of enforces scripts to do 'strictly presentation'.

The minus side:  old xsp scripts have to be rewritten.
It all depends on how many xsp and flow scripts you have out there.

Kind regards,
Jos

On 01/16/2012 02:54 PM, Wolfram Eisert wrote:

Hello Jos,

does that mean there is no xsp available in Cocoon 3 at all or that 
it's just not recommended?


Wolfram

2012/1/16 Jos Snellings <mailto:jos.snelli...@pandora.be>>


Dear mr. Eisert,

1.  I believe it does. I am using the beta version in a
"preproduction environment" for quite some time and it is stable.
2. It depends on what you mean by configuration. The sitemap will
need some slight adaptations.
Specifics from cocoon 2.2 will no longer hold.
- no flowscripts
- xsp is "banned"
There is a nonvanishing upgrade effort.
3. no, it should be written. I never used all of cocoon 2.x, but
from my experience:
- start project from 'cocoon sample and cocoon sample webapp'
- plan need for conversion scripts
- adapt sitemap
- adjust configuration (which is now essentially spring
configuration)

it depends a great deal on what you have been using in cocoon 2.x.

Jos


On 01/16/2012 12:51 PM, Wolfram Eisert wrote:

Dear List,

we are currently using Cocoon 2.0.4 and plan to update to a newer
version during this year.

For that I have a few questions:

* Does it make sense to wait for Cocoon 3.0?
* Is the configuration compatible between Cocoon 2.2 and
  Cocoon 3.0?
* Is there a "howto" for moving from Cocoon 2.0.4 to a
  current Version?

Thank you for your answers.

Wolfram





--
_
_
Philasearch.com GmbH
Lindenweg 1
D-63877 Sailauf
Tel. 06093-932933

Geschäftsführer: Franz Fedra, Wolfram Eisert, Walter Christ
Steuer-Nr.:204 135 10911 Finanzamt Aschaffenburg
Umsatzsteuer-
Identifikationsnummer
gemäß § 27 a Umsatzsteuergesetz: DE 112156180

Re: Porting to current cocoon version

2012-01-16 Thread Jos Snellings


Dear mr. Eisert,

1.  I believe it does. I am using the beta version in a "preproduction 
environment" for quite some time and it is stable.
2. It depends on what you mean by configuration. The sitemap will need 
some slight adaptations.

Specifics from cocoon 2.2 will no longer hold.
- no flowscripts
- xsp is "banned"
There is a nonvanishing upgrade effort.
3. no, it should be written. I never used all of cocoon 2.x, but from my 
experience:

- start project from 'cocoon sample and cocoon sample webapp'
- plan need for conversion scripts
- adapt sitemap
- adjust configuration (which is now essentially spring configuration)

it depends a great deal on what you have been using in cocoon 2.x.

Jos

On 01/16/2012 12:51 PM, Wolfram Eisert wrote:

Dear List,

we are currently using Cocoon 2.0.4 and plan to update to a newer 
version during this year.


For that I have a few questions:

* Does it make sense to wait for Cocoon 3.0?
* Is the configuration compatible between Cocoon 2.2 and Cocoon 3.0?
* Is there a "howto" for moving from Cocoon 2.0.4 to a current
  Version?

Thank you for your answers.

Wolfram

Re: where is org.apache.cocoon.components?

2012-01-06 Thread Jos Snellings

Thanks, Simo!
We should document these dependencies, I think.
The "cocoon side projects" are not always easy to find.

Cheers,
Jos

On Fri, Jan 6, 2012 at 11:05 AM, Simone Tripodi wrote:

> Hi Jos!
>
> Looks like the class
> org/apache/cocoon/components/serializers/util/XMLSerializer is
> contained in C2 cocoon-serializers-charsets, you have to add the
> following dependency in your pom:
>
> 
>  org.apache.cocoon
>  cocoon-serializers-charsets
>  1.0.0
> 
>
> I found it in
>
>
> jar:file:~/.m2/repository/org/apache/cocoon/cocoon-serializers-charsets/1.0.0/cocoon-serializers-charsets-1.0.0.jar!/org/apache/cocoon/components/serializers/util/XMLSerializer.class
>
> HTH, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Jan 6, 2012 at 8:16 AM, Jos Snellings
>  wrote:
> > Dear cocooners,
> >
> > When trying to load cocoon-optional, spring complains loudly about not
> being
> > able to find class:
> >
> > org/apache/cocoon/components/
> > serializers/util/XMLSerializer
> >
> > In effect, this class is not within the cocoon distribution.
> > To my best knowledge, there is no sub project
> > cocoon-components
> >
> > The problematic declaration is:
> > public class EncodingXMLSerializer extends
> > org.apache.cocoon.components.serializers.util.XMLSerializer implements
> > SAXPipelineComponent, Finisher, SAXConsumer, CachingPipelineComponent {
> >
> > Can anybody shed some light upon this one?
> >
> >
> > Thank you !
> > Jos
>

revoke "where is org.apache.cocoon.components"

2012-01-05 Thread Jos Snellings

Dear Cocooners,

Sorry, sent message in title in haste;
answering my own question:

/org/apache/cocoon/cocoon-serializers-charsets/1.0.0

As "side module" it does not come with the distribution when getting the
source code, that is why I did not see it.

Cheers,
Jos

where is org.apache.cocoon.components?

2012-01-05 Thread Jos Snellings

Dear cocooners,

When trying to load cocoon-optional, spring complains loudly about not
being able to find class:

org/apache/cocoon/components/
serializers/util/XMLSerializer

In effect, this class is not within the cocoon distribution.
To my best knowledge, there is no sub project
cocoon-components

The problematic declaration is:
public class EncodingXMLSerializer extends
org.apache.cocoon.components.serializers.util.XMLSerializer implements
SAXPipelineComponent, Finisher, SAXConsumer, CachingPipelineComponent {

Can anybody shed some light upon this one?


Thank you !
Jos

dependency

2011-11-07 Thread Jos Snellings


Hi !

Just glancing through recent evolutions in cocoon 3.
When building a block, based upon the sample, I notice a dependency:
- avalon-framework-api
- avalon-framework implementation

Just curious: what does it come from?What needs it?
I am running an application with minimum dependencies. Never needed it.

Cheers,
Jos

Re: status c3

2011-11-02 Thread Jos Snellings


True, Simone, I am delighted to find a renewed activity these days!
Projects that stem from the archetypes show:
  1. dependency from cocoon parent, but path is relative. I would like 
to avoid that
  2. they are configured with the plugin for the 'reloading class 
loader', fine when developing, but not for production


This is what I am going to try:
 - make a mvn cocoon project based on maven's latest versions
 - using just the dependencies I need
 - packaging just the war for the webapp

Kind regards,
Jos


On 11/02/2011 09:21 AM, Simone Tripodi wrote:

Hi Jos!
As you noticed, the 'alpha' status - which is related to APIs only,
not software stability - is finally terminated, we are on the beta
way, but the first beta release has not been released yet!
If I recall correctly, core APIs you are interested on, have not
changed, so your application should continue working with the new
artifacts - problem would be they are still SNAPSHOTs... :S
There is not an official plan, with roadmaps and deadlines,
unfortunately, since no one of Cocoon developers has the chance to
work fulltime on it, so it is currently maintained in our spare time -
that's why there are times where activity increases, but sometimes is
very low :P
Just let us know if you need details about C3, we would be more than
pleased to help you!
All the best, have a nice day,
Simo

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



On Wed, Nov 2, 2011 at 5:45 AM, Jos Snellings  wrote:

Hi everybody,

What is the current status of cocoon-3?
- I notice that the archetypes in the trunk are still on alpha-3, whereas,
- most of the artifacts have shifted to beta-1?

Here is the news:
- I have been using what I could call c3 "core" for quite some time now (>
1y)
  no complaints
  (core = servlet, pipeline, sax, sitemap, controller)
- I have a possible case for a nice c3 application, but I am afraid that
cocoons official status ("alpha" according to the documentation)
  will scare the customer

What's the plan on short notice?
Could live with beta, I guess.

Kind regards,
Jos

status c3

2011-11-01 Thread Jos Snellings


Hi everybody,

What is the current status of cocoon-3?
- I notice that the archetypes in the trunk are still on alpha-3, whereas,
- most of the artifacts have shifted to beta-1?

Here is the news:
- I have been using what I could call c3 "core" for quite some time now 
(> 1y)

  no complaints
  (core = servlet, pipeline, sax, sitemap, controller)
- I have a possible case for a nice c3 application, but I am afraid that 
cocoons official status ("alpha" according to the documentation)

  will scare the customer

What's the plan on short notice?
Could live with beta, I guess.

Kind regards,
Jos

Re: [C3] Passing parameters from sitemap to generator

2011-07-01 Thread Jos Snellings


Hi,

Maybe the Generator is sufficient?
To pass parameters from the sitemap is not it is not a big deal.
What sort of parameters do you want? Parts of the path?

controlStuff{tat}/{tit}/{tot}
request parameters?

Kind regards,
Jos

On 07/01/2011 10:33 AM, Thomas Markus wrote:

Hi,

JXGenerator is really useful, its a must have for me.

Thomas

Am 01.07.2011 10:25, schrieb Francesco Chicchiriccò:

Hi all,
recently I have been in the situation for which I need to parametrize 
an XML file of my application; I thought there was a simpler way but 
I ended up by using an additional XSLT transformation step (since the 
XSLTTransformer can accep parameters from the pipeline).


With C2.1 I used to put in place the JXGenerator [1] (or 
JXTransformer [2] depending on the case): this saved me, in many 
cases, from an additional transformation step in the pipeline.


Even though it is true that everything you could do with JXGenerator 
can always be done with XMLGenerator + XSLTTransformer, do you think 
that such component can be a "nice to have" in C3?


Cheers.

[1] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[2] http://cocoon.apache.org/2.1/userdocs/jx-template-transformer.html

Re: Latest on Cocoon?

2010-12-17 Thread Jos Snellings


Will turn out well, I guess!
I have a cocoon 3 application running with happy users.
The core is not so like to undergo dramatic changes. What is evolving a 
bit is 'goodies' and 'integration'.
What I like very much is that unnecessary dependencies have been 
removed. Also the separation between jars is better. For instance, if 
you do not need StringTemplate you can skip it;

same with cocoon-wicket.

Cheers,
Jos

On 12/17/2010 02:13 PM, Robby Pelssers wrote:

I really can't understand why you would still like to use XSP while there are 
far better alternatives out there?  I was in the exact same position 6 years 
ago where we had this large Cocoon application using solely xsp's. We took the 
decision to rewrite all functionality to flowscript / jxtemplate and we never 
regretted this decision.  And 2 years back I decided to switch to Cocoon 2.2 
and yet again no regrets.  Sure, you have to do quite a bit of additional work 
but postponing an upgrade will fire back at you in the long run.  Not saying 
you have to be an early adapter but once those early birds have used it for 1 
year in production environments and most bugs are removed... you should 
definitely consider it.

I'm about to start writing my first Cocoon 3 app while it's still in alpha-2 
...  See how that turns out ;-)

Kind regards,
Robby Pelssers


-Oorspronkelijk bericht-
Van: Johan Cwiklinski [mailto:johan.cwiklin...@ajlsm.com]
Verzonden: vr 17-12-2010 9:54
Aan: dev@cocoon.apache.org
Onderwerp: Re: Latest on Cocoon?

Le 17/12/2010 09:43, Laurent Medioni a écrit :

Unfortunately, if you are stuck as we are with XSPs, 2.2 is not an option...
We are even decommissioning our pageflow implementation based on Flowscript to 
switch to a plain Java stateless implementation...
So definitely not the 2.2 direction from what I understood...

XSP block is not longer maintained under cocoon>  2.1. Anyaway, I was
able to build and use the 2.1 xsp block with cocoon 2.2 a few months
ago, for testing pruposes.
That seems to work pretty well (all my tests on existing XSPs were
successfull.
Although, I did not plan to use that on production environments...


Laurent

Regards,

Re: [C3] Pipeline DSL

2010-12-07 Thread Jos Snellings

Good point.
I would say: everything you need and even more is there!

For people who were familiar with 2.2 or who want to port their
application: they are going to miss flowscript.
For people who lost contact in version 2.1 or so, they will probably be
missing xsp as a presentation scripting, and then get used to the rigid
separation line imposed by StringTemplate.

So my message would be: cocoon3 is 'gewöhnungsbedürftig', but you can
safely choose for it.

There is a non-vanishing upgrade effort involved.

Jos

On 12/07/2010 10:54 PM, Robby Pelssers wrote:

Hi Simoni,

i think it's indeed more fluent and more explicit. So I think it certainly is
an improvement. Only a few days back I wrote a mail to my fellow Java team
members complaining that Java feels like a big fat bloated beast more and more
with lack of expressiveness and higher order functions. Especially after
playing with functional languages. And Guava and functionaljava are good
examples...

Hell,
I even am experimenting myself with similar stuff ;-)
http://code.google.com/p/functionalprogramming/wiki/Introduction

By the way...
If I were to jump on the Cocoon 3 wagon... would i be able to do the same stuff
already as with 2.2? Or let me rephrase the question... is most stuff already
ported to 3.0?

Cheers,
Robby Pelssers

-Oorspronkelijk bericht-
Van: Simone Tripodi [mailto:simone.trip...@gmail.com]
Verzonden: di 7-12-2010 21:39
Aan: dev@cocoon.apache.org
Onderwerp: [C3] Pipeline DSL

Hi all guys,
I just committed a first working spike of a Pipeline DSL[1] to expose
more fluent APIs to final users to help them correctly creating and
running pipelines, built on top of pipeline APIs.
I also modified a test to show how to use the new APIs.
WDYT? Every feedback/suggestion would be much more than appreciated!!!
Have a nice day,
Simo

[1]
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/builder
[2]
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/PipelineTest.java#testPipelineWithCompiledXSLT()

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

Cocoon 3: the three sisters as OSGi bundles?

2010-06-24 Thread Jos Snellings


Dear all,

Some weeks ago, I was coding a servlet in an OSGi context (apache 
felix/sling).
In the process, of course, I wanted to use the triplet cocoon-pipeline, 
cocoon-sax, cocoon-xml, which as a result of the
design goals of Cocoon 3, can be used without further dependencies. A 
wise thing !


Of course, a first rough attempt is to just embed the jars in the 
bundle. This worked.
But now, I would like to take the thing an obvious step further: prepare 
OSGi bundles for the three sisters.


When I checked out the trunk again, I was pleasantly surprised to notice 
that ... cocoon-xml already is!
That means that I am not the only guy in the world thinking this would 
be a good idea.


I prepared bundles for the other two, but ... there is a class loading 
issue with cocoon-sax.

Summarising:
1. in spite of adding the xerces bundle to felix, inside the SAX2 
classes a class.forName("") gives a

ClassNotFoundException.:
  org.apache.cocoon.pipeline.ProcessingException: Cannot create and 
prepare an XMLReader.
at 
org.apache.cocoon.sax.util.XMLUtils.createXMLReader(XMLUtils.java:138)

  and this is because:
Caused by: java.lang.ClassNotFoundException: 
org.apache.xerces.parsers.SAXParser
at 
org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:189)

2.  On the other hand, inside 'my' bundle a code like:

XMLReader reader = new SAXParser();
reader = null;
String className = System.getProperty("org.xml.sax.driver");
try {
reader = 
(XMLReader)(Class.forName(className).newInstance());

}
catch (Exception e) {
System.err.println("No love...");
e.printStackTrace();
}


URL here = new 
URL("http://localhost:8080/some/nice/xml/content";);


URLConnection hc = here.openConnection();
InputStream in = hc.getInputStream();


ContentHandler contentHandler = new MyFavoriteContentHandler();
reader.setContentHandler(contentHandler);

InputSource input = new InputSource(in);
try {
reader.parse(input);
}
catch (Exception e) {
System.err.println("Can't parse your file");
e.printStackTrace();
}

works.

So, clearly there is a classloader confusion.
But the question is: is this the right way to go inside OSGi? Probably 
it would be better to ask the framework what parser

services it has available for us, and then use XMLParserActivator?
We could think about adding such a method to XMLUtils.

Of course I can take the embedded solution, but this is really a 
third-class solution. I really think there is an interest

to transform cocoon-sax into a genuine OSGi bundle.
I do not expect problems with cocoon-pipeline, being nicely insulated 
from the JAXP-loading issues.

Is there any interest in this group to dig into the matter?

Please let me know. If we can set up a discussion on this matter I am 
willing to address the issues in my own time.


Cheers,
Jos

[jira] Closed: (COCOON3-53) Cocoon 3: XMLSerializer caches all


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

Jos Snellings closed COCOON3-53.


Resolution: Fixed

The observed problem was due to using a SimpleCacheKey.
It remains a strange fact that this is only observed when the end point is an 
XMLSerializer.

> Cocoon 3: XMLSerializer caches all
> --
>
> Key: COCOON3-53
> URL: https://issues.apache.org/jira/browse/COCOON3-53
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-pipeline
>Reporter: Jos Snellings
>
> After startup, any pipeline/matcher ending in an xml-serializer will
> produce the output of the first request after server startup, regardless of 
> the url, let alone parameters.
> So the first xml pipe that is activated produces the expected output.
> All subsequent calls will echo that output, whatever the url or parameters.
> It takes a server restart to make a pipeline ending in an xml serializer work 
> again.

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

[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all


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

Jos Snellings commented on COCOON3-53:
--

ParameterCacheKey, constructed with the request parameters effectively cures 
the problem.
This issue is closed!

Suggestion:
Developers starting out with cocoon 3 are very much likely to leave the routine 
"constructCacheKey()"
as they find it. It would be good to provide a lightly annotated example in the 
samples! I will post one.

> Cocoon 3: XMLSerializer caches all
> --
>
> Key: COCOON3-53
> URL: https://issues.apache.org/jira/browse/COCOON3-53
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-pipeline
>Reporter: Jos Snellings
>
> After startup, any pipeline/matcher ending in an xml-serializer will
> produce the output of the first request after server startup, regardless of 
> the url, let alone parameters.
> So the first xml pipe that is activated produces the expected output.
> All subsequent calls will echo that output, whatever the url or parameters.
> It takes a server restart to make a pipeline ending in an xml serializer work 
> again.

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

[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all


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

Jos Snellings commented on COCOON3-53:
--

Yes, I thought about that, SimpleCacheKey is all too Simple. I kept it mainly 
because it was in the samples: 
it is not expected that a generator produces the same result.
but why do pipelines with the same Starters (Termgenerator or 
WorkspaceProvider) are perfectly OK with the cache when they end in html 
serialization?
Anyway, I will use a parameter cache and verify the cache behaviour is correct. 
If it does, I close this issue.

> Cocoon 3: XMLSerializer caches all
> --
>
> Key: COCOON3-53
> URL: https://issues.apache.org/jira/browse/COCOON3-53
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-pipeline
>Reporter: Jos Snellings
>
> After startup, any pipeline/matcher ending in an xml-serializer will
> produce the output of the first request after server startup, regardless of 
> the url, let alone parameters.
> So the first xml pipe that is activated produces the expected output.
> All subsequent calls will echo that output, whatever the url or parameters.
> It takes a server restart to make a pipeline ending in an xml serializer work 
> again.

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

[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all


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

Jos Snellings commented on COCOON3-53:
--

Cocoon 3, checked out from SVN on 5 march, and built with eclipse.
Detail:   three urls, activating a pipe ending with an xml serializer.  (Note: 
all other pipes work correctly as far as I could verify) 

http://localhost:8080/thesaurus/hierarchies?language=el, result = the greek 
hierarchies in the thesaurus
http://localhost:8080/thesaurus/showterm.xml?id=1004, visualize a term
http://localhost:8080/thesaurus/editor/workspace.xml?random=23948783
Here is what happens:
SETUP, manufacturing cacheKey:
  ~ adding SimpleCacheKey(hashCode=3116185) for component 
ToptermsGenerator(hashCode=21535750)
  ~ adding org.apache.cocoon.pipeline.caching.parametercache...@f91f7142 for 
component XMLSerializer(hashCode=10730286)
Creating  CompoundCacheKey(hashCode=22406408 
key=[SimpleCacheKey(hashCode=3116185), 
org.apache.cocoon.pipeline.caching.parametercache...@f91f7142]) for pipeline 
CachingPipeline(hashCode=33258683 
components=[ToptermsGenerator(hashCode=21535750), 
XMLSerializer(hashCode=10730286)])

SETTING CACHE: org.apache.cocoon.pipeline.caching.SimpleCache 
(CachingPipeline.setCache() called)

SETUP, manufacturing cacheKey for 2nd: 
  ~ adding SimpleCacheKey(hashCode=4540490) for component 
TermGenerator(hashCode=16199287)
  ~ adding org.apache.cocoon.pipeline.caching.parametercache...@f91f7142 for 
component XMLSerializer(hashCode=23533966)
Creating  CompoundCacheKey(hashCode=16471030 
key=[SimpleCacheKey(hashCode=4540490), 
org.apache.cocoon.pipeline.caching.parametercache...@f91f7142]) for pipeline 
CachingPipeline(hashCode=772032 components=[TermGenerator(hashCode=16199287), 
XMLSerializer(hashCode=23533966)])
The value is "FOUND" in cache!!!, Here is the xml for:  
cacheValue.writeTo(System.out): 
JDB: CachingPipeline Write cache value to output stream:
κυβέρνηση / 
διοίκησηοργανισμοίφορείςπολιτιστικό αγαθόπεριοχέςενδιαφέρον πολιτιστικής 
κληρονομιάςκληρονομιάκαταγραφή και τεκμηρίωσηαρχεία καταγραφήςκατάλογος προστατευόμενων 
αγαθώννομικά μέσαπολεοδομικό σύστημαδιαχείριση κληρονομιάςιδιοκτησίαπαράνομες ενέργειεςτύποι επεμβάσεωνπολιτική 
επεμβάσεωνπρογράμματα επεμβάσεωνεργαλεία επέμβασηςεπαγγέλματαδεξιότητεςεκπαίδευση / 
επιμόρφωσηπρόσβαση και ερμηνείαχρηματο-οικονομικά 
συστήματαγενικές έννοιεςSETTING CACHE: 
org.apache.cocoon.pipeline.caching.SimpleCache

Surprise! The Greek hierarchies!

SETUP, now the call of "workspace":
  ~ adding SimpleCacheKey(hashCode=30181678) for component 
WorkspaceProvider(hashCode=27011377)
  ~ adding org.apache.cocoon.pipeline.caching.parametercache...@f91f7142 for 
component XMLSerializer(hashCode=28014118)
Creating  CompoundCacheKey(hashCode=31048679 
key=[SimpleCacheKey(hashCode=30181678), 
org.apache.cocoon.pipeline.caching.parametercache...@f91f7142]) for pipeline 
CachingPipeline(hashCode=22316052 
components=[WorkspaceProvider(hashCode=27011377), 
XMLSerializer(hashCode=28014118)])
JDB: CachingPipeline Write cache value to output stream:
κυβέρνηση / 
διοίκησηοργανισμοίφορείςπολιτιστικό αγαθόπεριοχέςενδιαφέρον πολιτιστικής 
κληρονομιάςκληρονομιάκαταγραφή και τεκμηρίωσηαρχεία καταγραφήςκατάλογος προστατευόμενων 
αγαθώννομικά μέσαπολεοδομικό σύστημαδιαχείριση κληρονομιάςιδιοκτησίαπαράνομες ενέργειεςτύποι επεμβάσεωνπολιτική 
επεμβάσεωνπρογράμματα επεμβάσεωνεργαλεία επέμβασηςεπαγγέλματαδεξιότητεςεκπαίδευση / 
επιμόρφωσηπρόσβαση και ερμηνείαχρηματο-οικονομικά 
συστήματαγενικές έννοιες

Surprise: the Greek hierarchies come again! Although the cache key is different 
in all three cases.
So the thing to do is here to make the cache break news about its members and 
keys, and how equality is decided.

By the way:
1. jmx-group-name plays no role herein as expected
2. should the url not be included in a key hash?






> Cocoon 3: XMLSerializer caches all
> --
>
> Key: COCOON3-53
> URL: https://issues.apache.org/jira/browse/COCOON3-53
> Project: Cocoon 3
>  Issue Type: Bug
>  Components: cocoon-pipeline
>Reporter: Jos Snellings
>
> After startup, any pipeline/matcher ending in an xml-serializer will
> produce the output of the first request after server startup, regardless of 
> the url, let alone parameters.
> So the first xml pipe that is activated produces the expected output.
> All subsequent calls will echo that output, whatever the url or parameters.
> It takes a server restart to make a pipeline ending in an xml serializer work 
> again.

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

[jira] Commented: (COCOON3-53) Cocoon 3: XMLSerializer caches all