Re: Identifier used in FragmentExtractorTransformer

[Ralph Goers]

Joerg Heinicke wrote:


On 25.10.2005 09:06, Bart Molenkamp wrote:

(Can it be discussed here, or do I need to add them as comments to 
the issue too?)



Of course.


I don't totally agree with your latest comment. The CacheValidity
won't solve the problem, IMO it's a problem with the ID being generated
that is not unique.



Yes, the non-unique ID is a problem as you can see with the issues 
described by Sarah. For her repeated calls to the same URI brought 
always the same fragment. Generating unique URIs solved the problem 
for her - but also switches off any caching.



In my case, the URI for a report is always the same,
but the contents of that report is based on who is calling it. Multiple
users can call the same URI, each resulting in different content.


Breaking caching by generating unique ids doesn't seem like much of a 
solution.  I have pipelines that operate in the same manner that you are 
describing.  The src parameter is the same for every client.  I solved 
it by implementing my own source resolver.  It adds something unique 
about the client to the url that is returned on  the get URI call 
causing each client to have their own copy cached.


Ralph

Re: Identifier used in FragmentExtractorTransformer

[Joerg Heinicke]

On 25.10.2005 09:06, Bart Molenkamp wrote:


(Can it be discussed here, or do I need to add them as comments to the issue 
too?)


Of course.


I don't totally agree with your latest comment. The CacheValidity
won't solve the problem, IMO it's a problem with the ID being generated
that is not unique.


Yes, the non-unique ID is a problem as you can see with the issues 
described by Sarah. For her repeated calls to the same URI brought 
always the same fragment. Generating unique URIs solved the problem for 
her - but also switches off any caching.



In my case, the URI for a report is always the same,
but the contents of that report is based on who is calling it. Multiple
users can call the same URI, each resulting in different content.


How do you differentiate the user? The same way you have to do it for 
the cache key of the original XML, haven't you? This is why I thought it 
is just a matter of caching.



A cache validity won't solve this, there is just a need to store
multiple fragments in the same store.


And where is the problem to generate different cache keys per user?


Besides that I think that caching is done at the pipeline level: if
the generator, transformers and the serializer indicate that the cache
is valid, then the cached content will be returned and in that content
of course the link to the extracted fragment - but the fragment isn't
extracted again.


FragmentExtractorTransformer and FragmentExtractorGenerator are sitemap 
components, so where is the problem?



So I think that it is just as simple as to generate an unique ID.
Maybe some UUID, maybe something with a SecureRandom (like how
continuation IDs are generated). Also, I suggested to move this ID
generation to a protected method, so that users can override that method
in the transformer and implement their own method to generate an ID
(won't break the current way that the extractor is working).


UUIDs won't solve the problem as they remove any caching as described 
above or in the bug report.


The protected method can solve the problem, but IMO it should be 
possible to solve it once for all use cases, not individually by every user.


Jörg

ForrestBot build for cocoon-docs FAILED

[Forrestbot]

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 28 October 08:13 PM
Using Forrest 0.8-dev
Forrestbot administrator: Ross Gardler
--

 [echo] 
  ... Forrest render START 2005-10-28 08:02:34
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.output.pdf

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:

unpack-plugin:

install-plugin:

configure-cocoon:
 [copy] Warning: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf
 not found.

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy

check-plugin:
 [echo] org.apache.forrest.plugin.input.Daisy is not available in the build 
dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] .
  [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] .
  [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

fetch-plugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

findPlugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-versioned-plugin:

fetch-unversioned-plugin:
 [echo] Versioned plugin unavailable, trying to get versionless plugin...
  [get] Getting: 
http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip
  [get] .
  [get] last modified = Tue Oct 18 23:07:04 GMT+00:00 2005

final-check:
 [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install

fetchplugin:

unpack-plugin:

extract-plugin:
[unzip] Expanding: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip
 into 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy
   [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins

install-plugin:

configure-cocoon:
 [copy] Warni

Re: Using Daisy as Wiki

[Ross Gardler]

Pier Fumagalli wrote:

On 28 Oct 2005, at 19:05, Steven Noels wrote:


On 28 Oct 2005, at 16:26, Pier Fumagalli wrote:

5. How will the system perform? How well does it scale? Will it  
handle the expected load?


...



And insofar, no takers on static writing of HTMLs a-la MovableType...


Forrest *may* be able to do this. However, I've not got the time right 
now to explore the reality of this. The meme has been planted, one day I 
(or someone) will be able to look into this.


Ross

Re: Using Daisy as Wiki

[Pier Fumagalli]

On 28 Oct 2005, at 19:05, Steven Noels wrote:

On 28 Oct 2005, at 16:26, Pier Fumagalli wrote:

5. How will the system perform? How well does it scale? Will it  
handle the expected load?


Given that I run a fairly big site on Cocoon, I'm fairly scared  
about possible links from sites such as Slashdot...


Cough: http://science.slashdot.org/article.pl?sid=04/11/22/1342203 :)

Sorry, it's just me getting nervous when Daisy is being compared to  
a Python CGI.


I'm not saying it's impossible... The current VNUNET sites pump out  
more than 10 mbps constant now, and we spike to more than 30mbps  
kinda twice a week...


BUT, they're not running on the ASF infrastructure (therefore, when  
s**t hits the fan, the [EMAIL PROTECTED] people are the first to run, not  
us), and they're not shared by a number of other projects (therefore  
when s**t hits the fan, we hurt the wider Apache community).


Each project we individually build on Cocoon has the same technical  
merits inherited from the platform, but has a quite different  
deployment scenario.


My concerns are simply along the lines of "let's play this game  
nicely", not "it's impossible"...


And insofar, no takers on static writing of HTMLs a-la MovableType...

Pier



smime.p7s
Description: S/MIME cryptographic signature

Re: Using Daisy as Wiki

[Steven Noels]

On 28 Oct 2005, at 16:26, Pier Fumagalli wrote:

5. How will the system perform? How well does it scale? Will it 
handle the expected load?


Given that I run a fairly big site on Cocoon, I'm fairly scared about 
possible links from sites such as Slashdot...


Cough: http://science.slashdot.org/article.pl?sid=04/11/22/1342203 :)

Sorry, it's just me getting nervous when Daisy is being compared to a 
Python CGI.



--
Steven Noelshttp://outerthought.org/
Outerthought  Open Source Java & XML
stevenn at outerthought.orgstevenn at apache.org

ForrestBot build for cocoon-docs FAILED

[Forrestbot]

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 28 October 05:09 PM
Using Forrest 0.8-dev
Forrestbot administrator: Ross Gardler
--

 [echo] 
  ... Forrest render START 2005-10-28 05:02:07
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.output.pdf

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:

unpack-plugin:

install-plugin:

configure-cocoon:
 [copy] Warning: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf
 not found.

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy

check-plugin:
 [echo] org.apache.forrest.plugin.input.Daisy is not available in the build 
dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] .
  [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] .
  [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

fetch-plugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

findPlugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-versioned-plugin:

fetch-unversioned-plugin:
 [echo] Versioned plugin unavailable, trying to get versionless plugin...
  [get] Getting: 
http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip
  [get] 
  [get] last modified = Tue Oct 18 23:07:04 GMT+00:00 2005

final-check:
 [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install

fetchplugin:

unpack-plugin:

extract-plugin:
[unzip] Expanding: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip
 into 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy
   [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins

install-plugin:

configure-cocoon:
 [copy] Warnin

Re: ImageMap sample is not working

[Stavros Kounis]

hi luca

i have notice that its a path problem

i have set the widget to get image (cocoon's logo) form [/images/cocoon.gif].

This is fine for a local build of cocoon where run at
http://localhost: and http://localhost:/images/cocoon.gif
return the image.

in "zones"
the widget try to get image from
"http://cocoon.zones.apache.org/images/cocoon.gif";

unfortunatelly i dont have time to provide this small patch

regards

stavros


2005/10/27, Luca Morandini <[EMAIL PROTECTED]>:
> In both 2.1.8-rc1 and 2.2-dev hosted on cocoon.zones, the logo doesn't
> appear.
>
> Regards,
>
> 
> Luca Morandini
> www.lucamorandini.it
> 
>
>


--
Stavros S. Kounis
Osmosis networks & consulting   http://www.osmosis.gr
Read my weblog at   http://tools.osmosis.gr/blog

Re: Using Daisy as Wiki

[Ralph Goers]

Reinhard Poetz wrote:



Bertrand, your comment makes me think why we don't use Daisy as Wiki 
too? Any reasons for this? It would also make it much simpler to move 
over docs from a wiki zone into our official documentation.


Well, here is another option.  Geronimo was proposing to use confluence 
for its wiki.  Now I haven't looked at it at all, but if it has better 
features for what we are trying to do it might be better just to support 
their request.  I believe the reason they wanted to use it is that it 
apparently integrates with Jira.


Ralph

Cocoon's use of Daisy on the Cocoon Zone

[Upayavira]

[[This is copied to [EMAIL PROTECTED] for informational purposes. For the
moment please keep infrastructure at apache.org as the principal list
for this discussion, as the issues discussed are wider than just Cocoon]]

= Cocoon and Daisy =
We have discussed this within the Cocoon PMC, and would like to start
discussions with infrastructure about our Daisy instance.

Let me start by saying that, previous to this installation, Cocoon's
documentation saw next to no movement. Now, we are regularly seeing
updates by multiple people, as can be witnessed by the
docs@cocoon.apache.org list.

That change is significant for the Cocoon project.

== How it all Works ==

When we wish to publish a new document, we go to our Daisy instance and
log in. Users have various access levels. Anonymous access is allowed,
however we plan to have a robots.txt file blocking crawlers, and to put
large warnings "this content is not live content" or some such when
content is viewed anonymously.

Anyone can create an account. Logging in gives you the ability to add
comments to documents.

Users can be granted "doc-editor" rights (a lightweight proposal on the
mailing list is sufficient for this), which allows a user to edit
documents, but not publish them. (Unpublished docs will not appear on
the anonymous Daisy site). Any committer will be given doc-committer
rights, which allows them to mark a document as published after reviewing.

This allows for Stefano's lightweight documentation authorship ideas
from Doco (http://wiki.apache.org/cocoon/Doco) - we will encourage our
users to start contributing to our documentation and make it easy for
them to do so.

When we do a new release of Cocoon, we will publish the site. This will
currently use Forrest and its Daisy plugin. The Forrest community
already have a Forrestbot set up on their zone which generates the
Cocoon site every 3 hours. We would then just need to commit that
generated site to SVN, and check that out on Minotaur for publishing.

I believe the data is stored in a combination of filesystem and Mysql.
Data is versioned in the repository, and commit notices go to our
docs@cocoon.apache.org mailing list.

As explained, we do not intend to have this Daisy instance used by the
public for our live documentation, although we do want to encourage
people to use it where they see the need for modifications to our docs.

== What Next ==

So, we have definitely moved from an experiment to an 'in use'
installation. I believe our system is working well for us, and would
like to discuss further here about how we should proceed.

I believe also that our system might be of interest to other ASF
projects and thus it may be worth exploring whether it can be installed
on an alternative ASF machine.

So, where do we go from here? :-)

Regards, Upayavira

Re: Using Daisy as Wiki

[Pier Fumagalli]

On 28 Oct 2005, at 16:03, Upayavira wrote:

Mark Lundquist wrote:

On Oct 28, 2005, at 7:26 AM, Pier Fumagalli wrote:

And maybe a shared Solaris 10 box is not the place where I would  
like

to see massive hits coming through...


What do the stats show about the current Wiki, i.e. how high a bar  
would

the Daisy server have to clear (for today + future), and could we run
enough of a load test on Daisy to get an idea?  JMeter?


Extremely high. I wouldn't go near it myself.

It took about a month after upgrading to the latest MoinMoin to get it
sufficiently stable to not bring down the whole www.apache.org server.
We had to block crawlers for some time, and eventually fixed it by
placing a new version of mod_cache in front of the Python based  
MoinMoin

wiki for all anonymous requests.

I'm afraid I don't have any figures, but can say that Cocoon's wiki is
amongst the top three Apache wikis in terms of size.


Exactly my thoughts... The only way in which I could see Daisy fit to  
handle that load, if it were to publish the pages entered as static  
files, then served off by Apache itself, without involving Cocoon  
(the same technique used by MovableType, for example).


Without that in place, I'd be -1 on hosting anything live of Cocoon  
on the ASF infrastructure, even with massive caching, because of the  
maintenance task we'd put on the infrastructure team, and the  
possible impact this would have on projects other than Cocoon itself  
(it's a shared infrastructure, we have to play it nice).


Pier



smime.p7s
Description: S/MIME cryptographic signature

Re: Using Daisy as Wiki

[Upayavira]

Mark Lundquist wrote:
> 
> On Oct 28, 2005, at 7:26 AM, Pier Fumagalli wrote:
> 
>> And maybe a shared Solaris 10 box is not the place where I would like
>> to see massive hits coming through...
> 
> 
> What do the stats show about the current Wiki, i.e. how high a bar would
> the Daisy server have to clear (for today + future), and could we run
> enough of a load test on Daisy to get an idea?  JMeter?

Extremely high. I wouldn't go near it myself.

It took about a month after upgrading to the latest MoinMoin to get it
sufficiently stable to not bring down the whole www.apache.org server.
We had to block crawlers for some time, and eventually fixed it by
placing a new version of mod_cache in front of the Python based MoinMoin
wiki for all anonymous requests.

I'm afraid I don't have any figures, but can say that Cocoon's wiki is
amongst the top three Apache wikis in terms of size.

Regards, Upayavira

Re: Using Daisy as Wiki

[Mark Lundquist]

On Oct 28, 2005, at 7:26 AM, Pier Fumagalli wrote:

And maybe a shared Solaris 10 box is not the place where I would like 
to see massive hits coming through...


What do the stats show about the current Wiki, i.e. how high a bar 
would the Daisy server have to clear (for today + future), and could we 
run enough of a load test on Daisy to get an idea?  JMeter?

Re: Using Daisy as Wiki

[Pier Fumagalli]

On 28 Oct 2005, at 15:13, Ralph Goers wrote:

5. How will the system perform? How well does it scale? Will it  
handle the expected load?


Given that I run a fairly big site on Cocoon, I'm fairly scared about  
possible links from sites such as Slashdot...


If we rely on the ASF-Wiki, then it's their problem to make sure it  
works, but if we're using daisy, well, it's up to us. And maybe a  
shared Solaris 10 box is not the place where I would like to see  
massive hits coming through...


Pier




smime.p7s
Description: S/MIME cryptographic signature

ForrestBot build for cocoon-docs FAILED

[Forrestbot]

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 28 October 02:10 PM
Using Forrest 0.8-dev
Forrestbot administrator: Ross Gardler
--

 [echo] 
  ... Forrest render START 2005-10-28 02:02:16
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.output.pdf

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:

unpack-plugin:

install-plugin:

configure-cocoon:
 [copy] Warning: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf
 not found.

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy

check-plugin:
 [echo] org.apache.forrest.plugin.input.Daisy is not available in the build 
dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] .
  [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] .
  [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

fetch-plugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

findPlugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-versioned-plugin:

fetch-unversioned-plugin:
 [echo] Versioned plugin unavailable, trying to get versionless plugin...
  [get] Getting: 
http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip
  [get] .
  [get] last modified = Tue Oct 18 23:07:04 GMT+00:00 2005

final-check:
 [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install

fetchplugin:

unpack-plugin:

extract-plugin:
[unzip] Expanding: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip
 into 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy
   [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins

install-plugin:

configure-cocoon:
 [copy] Warni

Re: Using Daisy as Wiki

[Ralph Goers]

Reinhard Poetz wrote:



Bertrand, your comment makes me think why we don't use Daisy as Wiki 
too? Any reasons for this? It would also make it much simpler to move 
over docs from a wiki zone into our official documentation.


Well, I'm +1 but this raises a significant issue.  There was a request 
by geronimo on the infra list a couple of weeks ago to allow them to use 
different wiki software.  It wasn't what I would call a "concrete" 
proposal in that I don't recall seeing them post the specifics of where 
it would run and who would maintain it.  infra pushed back as they don't 
want too many things to support.


Now the subject of Cocoon using Daisy has already come up there, 
although there was only a single email and no follow-up.  At some point 
we have to approach infra regarding our use of Daisy for documentation 
as we are doing something that really isn't approved - it was only 
supposed to be an experiment when it started.


So if we want to use Daisy for both our documentation and the wiki we 
need to answer several questions:

1. Where is it going to run?
2. Who will administer it?
3. How is the data backed up?
4. Is the data versioned such that every change can be tracked back to 
the individual who did it?
5. How will the system perform? How well does it scale? Will it handle 
the expected load?


Those are just the questions I thought of off the top of my head.

Ralph

Re: Daisy is down

[Bruno Dumon]

I have started the repository server again. I think it was shutdown by
the backup script, which apparently did that (now that cron works).

On Fri, 2005-10-28 at 14:12 +0100, Ross Gardler wrote:
> The daisy repository server is failing to respond.
> 
> Daisy needs rebooting but I do not have the privs.
> 
> Ross
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Daisy is down

[Ross Gardler]

The daisy repository server is failing to respond.

Daisy needs rebooting but I do not have the privs.

Ross

Re: [docs] Livesites by working area

[Ross Gardler]

hepabolu wrote:

Steven Noels wrote:


On 28 Oct 2005, at 12:52, Arje Cahn wrote:


Sounds good. Problem with having it alongside is that we'd
then need to
maintain two lists.




Yes... We can't get Daisy to autogenerate those lists based on 
metadata can we?




Of course you can. :)

IIRC, Helma did set up a specific Live Site Document Type for these 
pages. She might have done this for similar reasons.



Ah no, I didn't. I merely wanted to prevent xdoc editing so I moved it 
over to Daisy as quickly as possible. There isn't very much about it, 
although I have been thinking that the current layout/setup could be 
much different, so go ahead and feel free to move things around.


RT: what if there is a LiveSiteDocumentType that can hold the info we 
currently ask people to add to Jira/Bugzilla and each site is in 
separate documents. IIUC we could then create queries that could present 
the info either by Cocoon version or by category (provided we have added 
that to a metadata field).


Steven, am I correct to think that I could recreate the current page of 
Cocoon version X by doing a query include of "all LiveSiteDocument with 
version=X"?


Yes, create a doc typoe, add a few relevant fields (including one of tags.

Create a query to list the sites within a specific release, with a 
specific tag etc.


Query include will put the documents content in the page, a straight 
query will give a list of results with links to the details page.


If you want to create a doc type and a few sample pages, I'll show you 
how to create the query (not that it is hard, it is as close as possible 
to SQL).


Ross

Ross

Re: Using Daisy as Wiki

[Pier Fumagalli]

On 28 Oct 2005, at 12:02, Steven Noels wrote:

On 28 Oct 2005, at 11:03, Bertrand Delacretaz wrote:


BUT: we should make sure the daisy stuff is backed up,


For starters, it would be nice if someone Solaris-knowledgeable  
figures out why the crontab entry for the daisy user isn't doing  
what it should.


It's now correct. The entry in the /etc/shadow file indicated that  
"daisy" was a locked user (password *LK*)... I now unlocked it and  
crons work like a charm...


Pier (an old solaris fart)



smime.p7s
Description: S/MIME cryptographic signature

Re: Using Daisy as Wiki

[Steven Noels]

On 28 Oct 2005, at 13:08, Pier Fumagalli wrote:


I can give it a shot, but am not in sudoers!


Not not anymore. Thanks!


--
Steven Noelshttp://outerthought.org/
Outerthought  Open Source Java & XML
stevenn at outerthought.orgstevenn at apache.org

Re: [docs] Livesites by working area

[hepabolu]

Steven Noels wrote:

On 28 Oct 2005, at 12:52, Arje Cahn wrote:


Sounds good. Problem with having it alongside is that we'd
then need to
maintain two lists.



Yes... We can't get Daisy to autogenerate those lists based on 
metadata can we?



Of course you can. :)

IIRC, Helma did set up a specific Live Site Document Type for these 
pages. She might have done this for similar reasons.


Ah no, I didn't. I merely wanted to prevent xdoc editing so I moved it 
over to Daisy as quickly as possible. There isn't very much about it, 
although I have been thinking that the current layout/setup could be 
much different, so go ahead and feel free to move things around.


RT: what if there is a LiveSiteDocumentType that can hold the info we 
currently ask people to add to Jira/Bugzilla and each site is in 
separate documents. IIUC we could then create queries that could present 
the info either by Cocoon version or by category (provided we have added 
that to a metadata field).


Steven, am I correct to think that I could recreate the current page of 
Cocoon version X by doing a query include of "all LiveSiteDocument with 
version=X"?


Bye, Helma

Re: ForrestBot build for cocoon-docs FAILED

[Ross Gardler]

[EMAIL PROTECTED] wrote:

Automated build for cocoon-docs FAILED


Just to reassure everyone, I'm fixing this. It's caused by my work on 
geting the URLspace to look good. I've actually finished this work, I'm 
just removing the hacks now so that I can commit to Forrest SVN.


Will most likely be done today (but I am still baby sitting a poorly 
baby so still no promisses ;-)


Ross

ForrestBot build for cocoon-docs FAILED

[Forrestbot]

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 28 October 11:09 AM
Using Forrest 0.8-dev
Forrestbot administrator: Ross Gardler
--

 [echo] 
  ... Forrest render START 2005-10-28 11:02:06
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.output.pdf

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:

unpack-plugin:

install-plugin:

configure-cocoon:
 [copy] Warning: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf
 not found.

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy

check-plugin:
 [echo] org.apache.forrest.plugin.input.Daisy is not available in the build 
dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] .
  [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] .
  [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

fetch-plugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

findPlugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-versioned-plugin:

fetch-unversioned-plugin:
 [echo] Versioned plugin unavailable, trying to get versionless plugin...
  [get] Getting: 
http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip
  [get] .
  [get] last modified = Tue Oct 18 23:07:04 GMT+00:00 2005

final-check:
 [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install

fetchplugin:

unpack-plugin:

extract-plugin:
[unzip] Expanding: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip
 into 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy
   [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins

install-plugin:

configure-cocoon:
 [copy] Warni

Re: Using Daisy as Wiki

[Pier Fumagalli]

On 28 Oct 2005, at 12:02, Steven Noels wrote:

On 28 Oct 2005, at 11:03, Bertrand Delacretaz wrote:


BUT: we should make sure the daisy stuff is backed up,


For starters, it would be nice if someone Solaris-knowledgeable  
figures out why the crontab entry for the daisy user isn't doing  
what it should.


I can give it a shot, but am not in sudoers!

Pier




smime.p7s
Description: S/MIME cryptographic signature

Re: Using Daisy as Wiki

[Steven Noels]

On 28 Oct 2005, at 11:03, Bertrand Delacretaz wrote:


BUT: we should make sure the daisy stuff is backed up,


For starters, it would be nice if someone Solaris-knowledgeable figures 
out why the crontab entry for the daisy user isn't doing what it 
should.



--
Steven Noelshttp://outerthought.org/
Outerthought  Open Source Java & XML
stevenn at outerthought.orgstevenn at apache.org

Re: [docs] Livesites by working area

[Steven Noels]

On 28 Oct 2005, at 12:52, Arje Cahn wrote:


Sounds good. Problem with having it alongside is that we'd
then need to
maintain two lists.


Yes... We can't get Daisy to autogenerate those lists based on 
metadata can we?


Of course you can. :)

IIRC, Helma did set up a specific Live Site Document Type for these 
pages. She might have done this for similar reasons.



--
Steven Noelshttp://outerthought.org/
Outerthought  Open Source Java & XML
stevenn at outerthought.orgstevenn at apache.org

RE: [docs] Livesites by working area

[Arje Cahn]

> Sounds good. Problem with having it alongside is that we'd 
> then need to
> maintain two lists. 

Yes... We can't get Daisy to autogenerate those lists based on metadata can we?

> Perhaps yours is more useful?
> 
> > I would be happy to set this up (need karma! :) ).
> 
> Create yourself an account on Daisy, and I'll give you karma.

Ok, account "arje". Thanks Upayavira!

Arje

Re: [docs] Livesites by working area

[Upayavira]

Arje Cahn wrote:
> Hello,
> 
> I was browsing through the Livesites pages in Daisy and I was thinking that 
> it might be nice to have the Live Sites categorized by "target group" instead 
> of Cocoon version number
> 
> If I were a possible new Cocoon user, I might not be very interested in what 
> version of Cocoon is running which site, but I would be interested in seeing 
> how succesfull others were in the same field.. (especially my competitors)
> 
> "Cocoon is used for / by..."
> - Magazine publishers: VNUNet.com, PCActive.co.uk, ..
> - Libraries: GoPubMed, ..
> - Booking sites: World Stay, ..
> - E-commerce sites: ..
> - Corporate sites: ..
> - Design Agencies: Frontage, ..
> - Product Catalogues: ebigchina.com, ..
> - Online tutorials: The Connecticut Tutorials, ..
> - Education: ...
> - Governmental institutes: ..
> - Small businesses: ..
> - BIG businesses: .. ;)
> 
> This could exist next to the current presentation of Live Sites.
> 
> WDYT? 

Sounds good. Problem with having it alongside is that we'd then need to
maintain two lists. Perhaps yours is more useful?

> I would be happy to set this up (need karma! :) ).

Create yourself an account on Daisy, and I'll give you karma.

Regards, Upayavira

[docs] Livesites by working area

[Arje Cahn]

Hello,

I was browsing through the Livesites pages in Daisy and I was thinking that it 
might be nice to have the Live Sites categorized by "target group" instead of 
Cocoon version number

If I were a possible new Cocoon user, I might not be very interested in what 
version of Cocoon is running which site, but I would be interested in seeing 
how succesfull others were in the same field.. (especially my competitors)

"Cocoon is used for / by..."
- Magazine publishers: VNUNet.com, PCActive.co.uk, ..
- Libraries: GoPubMed, ..
- Booking sites: World Stay, ..
- E-commerce sites: ..
- Corporate sites: ..
- Design Agencies: Frontage, ..
- Product Catalogues: ebigchina.com, ..
- Online tutorials: The Connecticut Tutorials, ..
- Education: ...
- Governmental institutes: ..
- Small businesses: ..
- BIG businesses: .. ;)

This could exist next to the current presentation of Live Sites.

WDYT? 

I would be happy to set this up (need karma! :) ).



Kind regards,

Arjé Cahn

Hippo  

Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
-
[EMAIL PROTECTED] / www.hippo.nl
--

Re: Using Daisy as Wiki

[Bertrand Delacretaz]

Le 28 oct. 05, à 10:58, Ross Gardler a écrit :


Reinhard Poetz wrote:
...Bertrand, your comment makes me think why we don't use Daisy as 
Wiki too? Any reasons for this? It would also make it much simpler to 
move over docs from a wiki zone into our official documentation.


+1

We can set up a new collction that has open access to all and restrict 
access to registered users for the docs themselves.


Any pages that we want to use from the Wiki in the Docs can then just 
be moved across to the relevant docs collection...


sounds great, I'm basically +1
BUT: we should make sure the daisy stuff is backed up, and that infra 
is ok with us having important stuff on the zone...


-Bertrand

Re: FlowScript: Enforcing exlplicit declaration blocks dynamic loading

[Sylvain Wallez]

Rob Berens wrote:

In 2.1.6. explicit declaration of variables in global scope was enforced
(fix 25951).
This was implemented by locking the scope after the main part of the main
script has been loaded and processed.
In our situation we have one generic script loaded form the sitemap once,
that determines the name of the script to be loaded based on the request and
than loads that script. Simplified it's like this.
The sitemap loads the script main.js:

main.js:

function loadScript() {
var scriptURI = "determineScriptURIFromRequest";
cocoon.load(scriptURI);
}


When a request comes in, the sitemap calls the function loadScript(). Let's
say loadScript determines that it needs to load myScript.js.


myScript.js:

var myVar = "myValue"; // This results in an error when loaded from main.js.

"doSomething";


In this way we have a mechanism to load scripts dynamically without knowing
their names before hand.
The problem is that after loading the initial main.js the global scope is
locked, which results in an error on "var myVar = .".

I solved by changing the jsFunction_Load method in
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.java into:

public Object jsFunction_load( String filename )
throws Exception {
org.mozilla.javascript.Context cx =
org.mozilla.javascript.Context.getCurrentContext();
FOM_JavaScriptInterpreter.ThreadScope scope =
(FOM_JavaScriptInterpreter.ThreadScope)getParentScope();
Script script = getInterpreter().compileScript(cx, filename);
Object obj;
synchronized(scope) {
scope.setLock(false);
obj = script.exec( cx, scope );
scope.setLock(true);
}
return obj;
}


In this way the scope is temporarily unlocked during the load of the script.
This works fine. There is however one problem. The scope in FOM_Cocoon will
always be an instance of FOM_JavaScriptInterpreter.ThreadScope, but this is
not explicitly known in FOM_Cocoon. I just made this assumption to get
things working. So we might need a better solution..

Is there any GURU who can help? Can this be solved in 2.1.8?
  


There's a big problem with this approach: since the actual script to 
load is defined by the currently executing request, what happens when 
different scripts are loaded? You fill the global (and session-bound) 
scope with request-dependent items.


To solve your issue, what we need is to extend cocoon.load() so that it 
accepts a second parameter, which will be the scope used to load the script.


That way, you can write:

function foo() {
   var scriptURI = "determineScriptURIFromRequest";
   var scope = {}; // new empty object
   cocoon.load(scriptURI, scope);
   // use something in the loaded script
   print(scope.myVar);
}

Sylvain

--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: complete version of form i18n zh_CN file

[Pier Fumagalli]

On 28 Oct 2005, at 08:15, Bertrand Delacretaz wrote:

Le 28 oct. 05, à 05:49, roy huang a écrit :


...


I cannot check the translation though, we trust you on that one!


That's when you use  (or a  
wife who can read chinese)...


I triple checked, all is good! :-P

Pier



smime.p7s
Description: S/MIME cryptographic signature

FlowScript: Enforcing exlplicit declaration blocks dynamic loading

[Rob Berens]

In 2.1.6. explicit declaration of variables in global scope was enforced
(fix 25951).
This was implemented by locking the scope after the main part of the main
script has been loaded and processed.
In our situation we have one generic script loaded form the sitemap once,
that determines the name of the script to be loaded based on the request and
than loads that script. Simplified it's like this.
The sitemap loads the script main.js:

main.js:

function loadScript() {
var scriptURI = "determineScriptURIFromRequest";
cocoon.load(scriptURI);
}


When a request comes in, the sitemap calls the function loadScript(). Let's
say loadScript determines that it needs to load myScript.js.


myScript.js:

var myVar = "myValue"; // This results in an error when loaded from main.js.

"doSomething";


In this way we have a mechanism to load scripts dynamically without knowing
their names before hand.
The problem is that after loading the initial main.js the global scope is
locked, which results in an error on "var myVar = .".

I solved by changing the jsFunction_Load method in
org.apache.cocoon.components.flow.javascript.fom.FOM_Cocoon.java into:

public Object jsFunction_load( String filename )
throws Exception {
org.mozilla.javascript.Context cx =
org.mozilla.javascript.Context.getCurrentContext();
FOM_JavaScriptInterpreter.ThreadScope scope =
(FOM_JavaScriptInterpreter.ThreadScope)getParentScope();
Script script = getInterpreter().compileScript(cx, filename);
Object obj;
synchronized(scope) {
scope.setLock(false);
obj = script.exec( cx, scope );
scope.setLock(true);
}
return obj;
}


In this way the scope is temporarily unlocked during the load of the script.
This works fine. There is however one problem. The scope in FOM_Cocoon will
always be an instance of FOM_JavaScriptInterpreter.ThreadScope, but this is
not explicitly known in FOM_Cocoon. I just made this assumption to get
things working. So we might need a better solution..

Is there any GURU who can help? Can this be solved in 2.1.8?

Rob Berens
Osirion B.V.
Gagelveld 41
6596 CC  Milsbeek
The Netherlands
Tel: +31 (0)485-54 02 03
Fax: +31 (0)485-54 02 04
E-mail: [EMAIL PROTECTED]

Re: Using Daisy as Wiki

[Upayavira]

Ross Gardler wrote:
> Reinhard Poetz wrote:
> 
>> Apache Wiki wrote:
>>
>>> Dear Wiki user,
>>>
>>> You have subscribed to a wiki page or wiki category on "Cocoon Wiki"
>>> for change notification.
>>>
>>> The following page has been changed by BertrandDelacretaz:
>>> http://wiki.apache.org/cocoon/ReleaseTests218
>>>
>>> --
>>>
>>>   ||JVM||Jetty Linux||Jetty Windows||Jetty MacOS||Tomcat 5.5.12
>>> Linux||Tomcat 5.5.12 Windows||Tomcat 4.1 Linux||Tomcat 4.1 Windows||
>>>   ||1.3||   || ||   ||  
>>> || ||   
>>> ||||
>>>   ||1.4.2_08||  ||1666 ||   ||  
>>> || ||||  ||
>>> + ||1.4.2-38||  || ||rev 329128: htmlunit-tests
>>> ok[[BR]]junit-tests: 1668,1669||  
>>> || ||||  ||
>>>   ||1.5.0_05||  || ||   ||  
>>> || ||||   ||
>>>   + ''(aargh this table editing stuff is AWFUL ;-)''
>>> +
>>
>>
>>
>> Bertrand, your comment makes me think why we don't use Daisy as Wiki
>> too? Any reasons for this? It would also make it much simpler to move
>> over docs from a wiki zone into our official documentation.
>>
> 
> +1
> 
> We can set up a new collction that has open access to all and restrict
> access to registered users for the docs themselves.
> 
> Any pages that we want to use from the Wiki in the Docs can then just be
> moved across to the relevant docs collection.

I would say we should wait until we have had discussions with Infra
(which I intend to initiate today). It is one thing to use Daisy for
content management (something Apache doesn't otherwise help us with),
and another to start running our own Wiki on our Zone.

Questions for me would be: how do we decide what content on the Daisy
wiki is public? When it is public, can our wiki handle the load that can
occur? (Note, it took about a month of an httpd committer's time to get
MoinMoin able to handle the load by putting mod_cache in front.
Otherwise it just died horribly). Note also that Cocoon's current wiki
is one of the ASF's larger wikis (within the top three, I'd say without
looking).

So, I'm open to it, but let's go slowly :-)

Regards, Upayavira

Re: Using Daisy as Wiki

[Ross Gardler]

Reinhard Poetz wrote:

Apache Wiki wrote:


Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" 
for change notification.


The following page has been changed by BertrandDelacretaz:
http://wiki.apache.org/cocoon/ReleaseTests218

-- 

  ||JVM||Jetty Linux||Jetty Windows||Jetty MacOS||Tomcat 5.5.12 
Linux||Tomcat 5.5.12 Windows||Tomcat 4.1 Linux||Tomcat 4.1 Windows||
  ||1.3||   || ||   ||   
|| ||
||||
  ||1.4.2_08||  ||1666 ||   ||   
|| ||||  ||
+ ||1.4.2-38||  || ||rev 329128: htmlunit-tests 
ok[[BR]]junit-tests: 1668,1669||   
|| ||||  ||
  ||1.5.0_05||  || ||   ||   
|| ||||   ||

  + ''(aargh this table editing stuff is AWFUL ;-)''
+



Bertrand, your comment makes me think why we don't use Daisy as Wiki 
too? Any reasons for this? It would also make it much simpler to move 
over docs from a wiki zone into our official documentation.




+1

We can set up a new collction that has open access to all and restrict 
access to registered users for the docs themselves.


Any pages that we want to use from the Wiki in the Docs can then just be 
moved across to the relevant docs collection.


Ross

ForrestBot build for cocoon-docs FAILED

[Forrestbot]

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 28 October 08:09 AM
Using Forrest 0.8-dev
Forrestbot administrator: Ross Gardler
--

 [echo] 
  ... Forrest render START 2005-10-28 08:02:08
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.output.pdf

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:

unpack-plugin:

install-plugin:

configure-cocoon:
 [copy] Warning: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.output.pdf/conf
 not found.

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] Installing plugin: org.apache.forrest.plugin.input.Daisy

check-plugin:
 [echo] org.apache.forrest.plugin.input.Daisy is not available in the build 
dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] .
  [get] last modified = Wed Oct 19 20:52:08 GMT+00:00 2005
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] .
  [get] last modified = Tue Sep 13 01:07:06 GMT+00:00 2005
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

fetch-plugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

findPlugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-versioned-plugin:

fetch-unversioned-plugin:
 [echo] Versioned plugin unavailable, trying to get versionless plugin...
  [get] Getting: 
http://forrest.apache.org/plugins/org.apache.forrest.plugin.input.Daisy.zip
  [get] .
  [get] last modified = Tue Oct 18 23:07:04 GMT+00:00 2005

final-check:
 [echo] org.apache.forrest.plugin.input.Daisy downloaded, ready to install

fetchplugin:

unpack-plugin:

extract-plugin:
[unzip] Expanding: 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy.zip
 into 
/export/opt/forrest-trunk/build/plugins/org.apache.forrest.plugin.input.Daisy
   [delete] Deleting 1 files from /export/opt/forrest-trunk/build/plugins

install-plugin:

configure-cocoon:
 [copy] Warni

Re: complete version of form i18n zh_CN file

[roy huang]

Hi,Bertrand
  I have update form the svn,only 
src\webapp\samples\i18n\translations\messages_zh_CN.xml is 
update,src\blocks\forms\java\org\apache\cocoon\forms\system\i18n\messages_zh_CN.xml
 is not updated.I think this file should be update too.

  Thanks.

Roy Huang

Re: [docs] docs now links back to daisy

[Bruno Dumon]

On Thu, 2005-10-27 at 11:57 +0100, Upayavira wrote:
> Bruno Dumon wrote:
> > On Thu, 2005-10-27 at 10:50 +0100, Upayavira wrote:

> >>I really do not want to see Daisy serving content to anyone who is not
> >>logged in. (but am happy to give away logins quite freely).
> > 
> > Any reason for that? I saw the earlier discussion on this, but don't
> > recall any better reason than "I don't like it". If it is to avoid
> > confusion, then I think it should be possible by putting appropriate
> > warnings in place.
> 
> Yes, I don't want the Daisy content to become the source for
> documentation. So suitably large warnings would do the job.
> 
> Would it be possible to have the warnings either disappear or get
> smaller when someone logs in?

yes, that's no problem.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Using Daisy as Wiki

[Reinhard Poetz]

Apache Wiki wrote:

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change 
notification.

The following page has been changed by BertrandDelacretaz:
http://wiki.apache.org/cocoon/ReleaseTests218

--
  ||JVM||Jetty Linux||Jetty Windows||Jetty MacOS||Tomcat 5.5.12 Linux||Tomcat 
5.5.12 Windows||Tomcat 4.1 Linux||Tomcat 4.1 Windows||
  ||1.3||   || ||   ||   || 
||||||
  ||1.4.2_08||  ||1666 ||   ||   || 
||||  ||
+ ||1.4.2-38||  || ||rev 329128: htmlunit-tests 
ok[[BR]]junit-tests: 1668,1669||   || ||
||  ||
  ||1.5.0_05||  || ||   ||   || 
||||   ||
  
+ ''(aargh this table editing stuff is AWFUL ;-)''
+ 



Bertrand, your comment makes me think why we don't use Daisy as Wiki too? Any 
reasons for this? It would also make it much simpler to move over docs from a 
wiki zone into our official documentation.


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

[jira] Created: (COCOON-1670) portal tools i18n doesn't work

[roy huang (JIRA)]

portal  tools i18n doesn't work
---

 Key: COCOON-1670
 URL: http://issues.apache.org/jira/browse/COCOON-1670
 Project: Cocoon
Type: Bug
  Components: Blocks: Portal  
Versions: 2.1.8-dev (Current SVN)
Reporter: roy huang


check archive mail-list 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111692234511897&w=2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Releasing 2.1.8 next friday [was: [Vote] Releasing 2.1.8]

[Ralph Goers]

OK.

While I think the table in the wiki is a good idea, the wiki's table 
handling leaves a lot to be desired. If anyone has a better idea please 
suggest it. But it does (or will - once more data is filled in) give a 
nice overall picture of how much the release has been tested.


Ralph

Carsten Ziegeler wrote:


It seems that it's better to not rush the release and give us all one
more week time to get everything working.

So I'll start another vote next thursday and then hopefully release on
friday.

Carsten
 

[jira] Updated: (COCOON-1668) o.a.c.forms.formmodel.GroupTestCase fails

[Bertrand Delacretaz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1668?page=all ]

Bertrand Delacretaz updated COCOON-1668:


Fix Version: 2.1.8-dev (Current SVN)

> o.a.c.forms.formmodel.GroupTestCase fails
> -
>
>  Key: COCOON-1668
>  URL: http://issues.apache.org/jira/browse/COCOON-1668
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Forms
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Bertrand Delacretaz
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Fix For: 2.1.8-dev (Current SVN)

>
> In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on 
> my macosx/JDK 1.4.2-38 system, the core problem seems to be "class 
> org.apache.cocoon.core.container.DefaultServiceSelector not found".
> testInheritance:
> Could not get class
> org.apache.avalon.framework.configuration.ConfigurationException: Could not 
> get class at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162)
>  at 
> org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused
>  by: java.lang.ClassNotFoundException: 
> org.apache.cocoon.core.container.DefaultServiceSelector at 
> java.net.URLClassLoader$1.run(URLClassLoader.java:199) at 
> java.security.AccessController.doPrivileged(Native Method) at 
> java.net.URLClassLoader.findClass(URLClassLoader.java:187) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:289) at 
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:235) at 
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444)
>  ... 14 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: complete version of form i18n zh_CN file

[Bertrand Delacretaz]

Le 28 oct. 05, à 05:49, roy huang a écrit :


...


Committed to both 21branch and trunk - I cannot check the translation 
though, we trust you on that one!


-Bertrand

[jira] Closed: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.

[Ralph Goers (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1666?page=all ]
 
Ralph Goers closed COCOON-1666:
---

Resolution: Invalid

> Saving of JSR-168 preferences does not appear to be working.
> 
>
>  Key: COCOON-1666
>  URL: http://issues.apache.org/jira/browse/COCOON-1666
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Portal
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Ralph Goers
> Assignee: Ralph Goers
>  Fix For: 2.1.8-dev (Current SVN)

>
> Saving of JSR-168 preferences does not appear to be working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1669) o.a.c.jcr.source.JCRSourceTestCase fails

[Bertrand Delacretaz (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1669?page=all ]

Bertrand Delacretaz updated COCOON-1669:


Version: 2.1.8-dev (Current SVN)

> o.a.c.jcr.source.JCRSourceTestCase fails
> 
>
>  Key: COCOON-1669
>  URL: http://issues.apache.org/jira/browse/COCOON-1669
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: JCR
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Bertrand Delacretaz
> Assignee: Cocoon Developers Team
> Priority: Minor
>  Fix For: 2.1.8-dev (Current SVN)

>
> All tests fail with "Cannot access configuration information at null:36:21" 
> on my macosx/JDK 1.4.2-38 system.
> Details: Cannot access configuration information at null:36:21
> org.apache.avalon.framework.configuration.ConfigurationException: Cannot 
> access configuration information at null:36:21 at 
> org.apache.cocoon.jcr.JackrabbitRepository.configure(JackrabbitRepository.java:98)
>  at 
> org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201)
>  at 
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289)
>  at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.

[Ralph Goers (JIRA)]

 [ http://issues.apache.org/jira/browse/COCOON-1666?page=all ]

Ralph Goers updated COCOON-1666:


Assign To: Ralph Goers

The test was with page labels and marshalling enabled.  I missed one 
configuration item - uncommenting the parameter-name for the request-parameter 
aspect.  I verified that it does indeed work.

I will close this.

> Saving of JSR-168 preferences does not appear to be working.
> 
>
>  Key: COCOON-1666
>  URL: http://issues.apache.org/jira/browse/COCOON-1666
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Portal
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Ralph Goers
> Assignee: Ralph Goers
>  Fix For: 2.1.8-dev (Current SVN)

>
> Saving of JSR-168 preferences does not appear to be working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1669) o.a.c.jcr.source.JCRSourceTestCase fails

[Bertrand Delacretaz (JIRA)]

o.a.c.jcr.source.JCRSourceTestCase fails


 Key: COCOON-1669
 URL: http://issues.apache.org/jira/browse/COCOON-1669
 Project: Cocoon
Type: Bug
  Components: Blocks: JCR  
Reporter: Bertrand Delacretaz
 Assigned to: Cocoon Developers Team 
Priority: Minor
 Fix For: 2.1.8-dev (Current SVN)


All tests fail with "Cannot access configuration information at null:36:21" on 
my macosx/JDK 1.4.2-38 system.

Details: Cannot access configuration information at null:36:21

org.apache.avalon.framework.configuration.ConfigurationException: Cannot access 
configuration information at null:36:21 at 
org.apache.cocoon.jcr.JackrabbitRepository.configure(JackrabbitRepository.java:98)
 at 
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerUtil.java:201)
 at 
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:289)
 at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (COCOON-1668) o.a.c.forms.formmodel.GroupTestCase fails

[Bertrand Delacretaz (JIRA)]

o.a.c.forms.formmodel.GroupTestCase fails
-

 Key: COCOON-1668
 URL: http://issues.apache.org/jira/browse/COCOON-1668
 Project: Cocoon
Type: Bug
  Components: Blocks: Forms  
Versions: 2.1.8-dev (Current SVN)
Reporter: Bertrand Delacretaz
 Assigned to: Cocoon Developers Team 
Priority: Minor


In revision 329128, org.apache.cocoon.forms.formmodel.GroupTestCase fails on my 
macosx/JDK 1.4.2-38 system, the core problem seems to be "class 
org.apache.cocoon.core.container.DefaultServiceSelector not found".

testInheritance:
Could not get class

org.apache.avalon.framework.configuration.ConfigurationException: Could not get 
class at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:458)
 at 
org.apache.cocoon.core.container.ContainerTestCase.setupManagers(ContainerTestCase.java:267)
 at 
org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:190)
 at 
org.apache.cocoon.core.container.ContainerTestCase.prepare(ContainerTestCase.java:162)
 at 
org.apache.cocoon.core.container.ContainerTestCase.setUp(ContainerTestCase.java:146)Caused
 by: java.lang.ClassNotFoundException: 
org.apache.cocoon.core.container.DefaultServiceSelector at 
java.net.URLClassLoader$1.run(URLClassLoader.java:199) at 
java.security.AccessController.doPrivileged(Native Method) at 
java.net.URLClassLoader.findClass(URLClassLoader.java:187) at 
java.lang.ClassLoader.loadClass(ClassLoader.java:289) at 
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at 
java.lang.ClassLoader.loadClass(ClassLoader.java:235) at 
org.apache.avalon.excalibur.component.ExcaliburComponentManager.configure(ExcaliburComponentManager.java:444)
 ... 14 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (COCOON-1666) Saving of JSR-168 preferences does not appear to be working.

[Carsten Ziegeler (JIRA)]

[ 
http://issues.apache.org/jira/browse/COCOON-1666?page=comments#action_12356177 
] 

Carsten Ziegeler commented on COCOON-1666:
--

Just tested the portal demo from latest svn, and it works for me

> Saving of JSR-168 preferences does not appear to be working.
> 
>
>  Key: COCOON-1666
>  URL: http://issues.apache.org/jira/browse/COCOON-1666
>  Project: Cocoon
> Type: Bug
>   Components: Blocks: Portal
> Versions: 2.1.8-dev (Current SVN)
> Reporter: Ralph Goers
>  Fix For: 2.1.8-dev (Current SVN)

>
> Saving of JSR-168 preferences does not appear to be working.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira