date:20030910

Christopher Oliver wrote:

Unfortunately I think 2.1.1 contains a Rhino regression I temporarily 
introduced while trying to fix bug 22513 which will cause any scripts 
with nested functions to fail. This includes some of the flow samples 
like PetStore and JXForms.
Duh. Showstopper?

/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java  XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Regression tests (was Re: Announcing 2.1.1)

2003-09-10 Thread Guido Casper

Christopher Oliver [EMAIL PROTECTED] wrote:
 Unfortunately I think 2.1.1 contains a Rhino regression I temporarily
 introduced while trying to fix bug 22513 which will cause any scripts
 with nested functions to fail. This includes some of the flow samples
 like PetStore and JXForms.

 IMO we are in serious need of regression tests for flowscript. In the
 meantime any help others can provide with respect to testing the flow
 implementation is appreciated.

I agree that automated functional tests would be of equivalent
importance as the unit tests Stephan enabled.
There are some Anteater tests in CVS. However you need to uncomment
these in the test target as they require you to have a local Anteater
on your HD.
I wonder whether it would be to heavy to put a trimmed down Anteater
in the CVS so that these tests can be enabled by default (and each block
have its own Anteater tests as well) so that you just need to run:
cocoon servlet
build functional-tests

(Anteater could even be configured to start its own servlet container
to test against IIUC)

Guido

Re: JXForms and selectBoolean

2003-09-10 Thread Christopher Oliver

Barzilai Spinak wrote:

Christopher Oliver wrote:
 BarZ,

 Feel free to submit patches to JXForms, for example for 
selectBoolean. Nobody is responsible for JXForms or other Cocoon 
development per se. It's voluntary.

Well, thanks for your confidence hehe.
I may do just that when I feel more compfortable with the code.  In 
fact I have a few ideas.
But before doing that I wanted to know for example what the philosphy 
behind the JXForms project is, or if
someone is already planning to do something about it.
Sometimes, when I find problems in other people's code/API's,  I fear 
that it may be me who just don't get it.
There's only one way to find out - by showing them your code.

Also, although it's an open source project and anyone can contribute, 
there's generally one or
two people who do most of the work on a certain part (JXForms in this 
case). They are usually
the ones who started the subproject, with some idea and vision in 
mind, and generally have the final word
on whether a new submitted patch is going to be implemented.  
Not so, IMO. There should be no code or idea ownership in open source. 
Once you've contributed your ideas or code it belongs to the community 
and others can change it..

At least they have CVS permission
to do it which is not my case!!  :-) 
You can submit patches to Cocoon via bugzilla even if you're not a 
committer.

If I start adding my xf:BarZRules tags and you add xf:OliverRocks 
tags and so on, pretty soon the
project becomes a mess.

So are you this special JXForms someone?  
No. For JXForms (or any project) to be truly successful, there should be 
no such person.

And what did you think about my questions?
Am I on the right path or did I just not get the whole idea? :-)
Your assessment of the need for selectBoolean sounds right on track to me.

Regards,

Chris

Re: New protocol for in-memory resources

Vadim Gritsenko wrote:

Sylvain Wallez wrote:

Tuomo L wrote:

It would be convinient,
if one could use a protocolthat defines a source (FilePart) located 
in memory.
This could be for example: multipart://foo.zip . Then it would
be possible to extract that in-memory zip-file to the target-dir.

Is this possible already, or am I going to wrong direction here?


You know that you can access files inside zip using jar: protocol, right? 


Yeah, but the jar: protocol needs a JDK URL to designate the archive 
file. We need a fancier jar source that would allow us to use sources 
instead, e.g. jar:context://foo.zip!/data.txt.

... or even jar:cocoon:/blah.zip!/data.txt ;-)

This is not possible today, but really is the right direction, and 
would be a valuable addition.


Wouldn't it be too much strain on system's resources (read: memory) in 
production environment (with the exception of light uses like 
departamental server) to render this feature useless? I agree though 
that it might be actually convinient.

Just wondering, ;-) 


I agree that uploading in memory may not be the right choice. When we'll 
have environment-adapters as proposed by Stefano, the choice of in 
memory/in temp file will be up to the sitemap writer. What's really 
interesting though, is to be able to access uploaded files (either 
real or in memory) using a Source.

PS Do we have TraversableInspectableRestrictableZipSource? 


You forgot that we can write in an archive : 
TraversableModifiableInspectableRestrictableZipSource ;-D

Sylvain

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

Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js

Christopher Oliver wrote:

BTW that flowscript code was written with the intention of supporting 
multi-page Woody forms with automated back/forward navigation as in 
JXForms. However, when I looked into implementing this I discovered 
that Woody forms cannot be presented in multiple pages because 
apparently the entire form is submitted with each request. As a 
result the fields that are not presented in the first page fail 
validation because they have no values. Or am I missing something? 


No, you got it right : Woody always validates the whole form.

In addition, the validator function in show() was not intended to 
return a value. I did that originally simply because it wasn't 
possible to programatically add validation errors to the form widgets 
themselves at the time it was written (not sure if that's still the case).


It is possible now, as I added access to the real widgets in order to do 
this. But problem is that the form is not informed of this manual 
validation, and therefore there must be a way for the validator function 
to express this.

Another way could be for the validator to set an invalidate property 
on the form. Don't know...

Sylvain

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

on better release and version management

Hi folks,

forgive me for putting on my BOFH hat, while making the following 
observations...

1) We suck at freezing and stabilizing the codebase prior to releases.

I would suggest that, from now on, the Release Manager puts forward a 
release date after discussion on the dev list, and that there's a 
two-day (!) freeze period where only glaring bugs can be fixed after a 
vote (!) on the list.

The Release Manager him/herself is also only allowed to commit obvious 
version number changes and all that during this two-day Sperr-zone.

During the past few releases, there was a flurry of quick fixes and 
commits happening just hours before Carsten made the tarball, and while 
I'm not immediately aware of any nasty side-effects caused by this, it 
sure doesn't look like there was time for any peer review on these late 
commits, neither did it look organized at all.

2) We need to break from the impasse of 2.1.1 vs 2.2

I suggested yesterday night that the reshuffling of docs that Carsten 
started really seems more apt for a 2.2 release. Also, the switch to 
Fortress and Real Blocks are destined towards that 2.2 release. I 
understand some Avalon peeps are glad to dive in and help us with that, 
which is great, but we should facilitate them.

Some people want to start with a 2.2 CVS module right away, others seem 
more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to 
decide on this, since it's blocking progress.

My personal opinion is that 2.2 might warrant its own module, but we 
need to discuss its structure and coexistence with old-style blocks code 
in more depth before we ask for its creation to the infrastructure peeps.

3) Given the breakage in the Rhino stuff, and the lack of serious 
testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not 
retracting it, though) and go for a new target release date for 2.1.2 on 
September 24th. That way, we can discuss at leisure what we are going to 
do with the docs-reshuffling, and people can spend more time on testing 
new stuff.

Please comment!

/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java  XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: [RT] Implementing Cocoon Blocks

2003-09-10 Thread Bruno Dumon

On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
 Bruno Dumon wrote:
  (catching up on block discussions...)
  
  On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:
  snip/
  
 Implementation Phases
 -
 
 Phase 1: definition of the contract between the block manager inside 
 cocoon and the standalone block deployer. These contracts include:
 
  1) description of the file system layout (see above for a suggestion)
  2) description of the wiring document schema
  3) description of the block metadata schema
 
 Ok, the file system seems fine - how about starting the discussion with 
 the following for the wiring document?  (I'm assuming stuff will have to 
 change - just trying to get the ball rolling)
 
 ?xml version=1.0 encoding=UTF-8?
 blocks version=1.0
block uri=cob:mycompany.com/webmail/1.3.43 wire-id=384938958499
  mount/mail//mount
  connections
connection
 name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/connection
connection 
 name=internal-skincob:mycompany.com/skins/corporate/34.3.345/connection
connection 
 name=repositorycob:mycompany.com/repositories/email/exchange/3.2.1/connection
  /connections
  configuration
param name=userguest/param
param name=passwordsj3u493/param
  /configuration
/block
block uri=cob:mycompany.com/repositories/email/exchange/3.2.1 
 wire-id=394781274834
  configuration
param name=hostmail.blah.org/param
  /configuration
/block
block uri=cob:yetanothercompany.com/skins/fancy/1.2.2 
 wire-id=947384127832/
block uri=cob:mycompany.com/skins/corporate/34.3.345 
 wire-id=746394782637/
 /blocks
 
 Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
 
 For sake of discussion, I recorded a wire-id instead of the location. 
 Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
 
 I also considered recording the wire-id instead of the uri for 
 connections between blocks - what are the arguments for each?
 
 connection was out of the blue using the wiring metaphore.  Other 
 options?  Free association: connect, attach, solder, wire, use ...
  
  Avalon Phoenix uses the words assembly and provide instead of
  wiring and connection, which I quite like (I mean the assembly 
  provide).
 
 I don't quite see where these terms would be used - can you explain a 
 little more?  Maybe a proposed set of changes to the example above?
 

Yep. I meant that the connection tag would become provide:
 provide
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/provide

And the wiring.xml would be called assembly.xml

OTOH, I'm meanwhile becoming accustomed to the wiring and connection
terms, so let's leave it as wiring and connection for now.

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

Re: [RT] Implementing Cocoon Blocks

2003-09-10 Thread Bruno Dumon

On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:
 Bruno Dumon wrote:
  On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
  snip/
  
 But this brings up another point - what to do if the wiring.xml and 
 others is deleted?  Presumably, all blocks are uninstalled in this 
 state, but what does this do to persistence requirements.
 
 Also, how to recreate the deploy step efficiently?  For example:
 
 You deploy a block with some dependencies and configuration.  The block 
 deploy process walks you through setting configs and resolving 
 dependencies.  You then have no record of these deployment choices 
 except in wiring.xml which is not meant for human consumption.  Perhaps 
 it would be good to record these human-step deployment time 
 configurations in a conf file which could be easily reprocessed to 
 easily re-deploy all blocks to their last configuration.
  
  
  I think the conf file you're speaking of here is simply the wiring.xml
  file itself? Remember, the block deployer has read-write access to this
  file, so it can first read the existing information, then let the
  administrator modify it, and then write it back. It's not like each time
  you want to modify the configuration of one block you'll have to
  re-enter all the parameters for other blocks as well.
 
 Ugh, I see now that I didn't explain well the scenario I was thinking of 
 and now can't remember!  IIRC I was trying to think through the process 
 of replication and/or staging.  In this case, would I copy over 
 wiring.xml and all blocks directories? (presumably)  But, what if some 
 of the deploy-time configurations need to change on the way?  For 
 instance, on a staging server, you use a different database.  So, I was 
 just trying to get a picture in my head of how that would work and what 
 the pitfalls were.

Aha, I understand the issue now. And next to staging and live servers
there are of course also the development servers or workstations. So
there are parameters which will be common for all installations and
parameters which can be different, and it would indeed be useful if we
can feed those common parameters to the block deployer, so that only
system-dependent parameters need to be completed.

Hmm, now that I think of it, it would also be useful to feed the
system-dependent parameters to the block deployer, because I don't want
to re-enter those either when I do a clean block deploy.

Basically what I'm arriving at is that the block deployer should be able
to run in an interaction-less mode by providing it with input files
giving it all the information.

Or then maybe it becomes more useful to write the wiring.xml by hand and
place a few @token@'s here and there which are replaced by an ant script
based on the values in a local.properties file.

Need to think more about this...

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

RE: on better release and version management

2003-09-10 Thread Reinhard Poetz


From: Steven Noels

 Hi folks,
 
 forgive me for putting on my BOFH hat, while making the following 
 observations...
 
 1) We suck at freezing and stabilizing the codebase prior to releases.
 
 I would suggest that, from now on, the Release Manager puts forward a 
 release date after discussion on the dev list, and that there's a 
 two-day (!) freeze period where only glaring bugs can be 
 fixed after a 
 vote (!) on the list.

+1

 
 The Release Manager him/herself is also only allowed to 
 commit obvious 
 version number changes and all that during this two-day Sperr-zone.

+1

 
 During the past few releases, there was a flurry of quick fixes and 
 commits happening just hours before Carsten made the tarball, 
 and while 
 I'm not immediately aware of any nasty side-effects caused by 
 this, it 
 sure doesn't look like there was time for any peer review on 
 these late 
 commits, neither did it look organized at all.
 
 2) We need to break from the impasse of 2.1.1 vs 2.2
 
 I suggested yesterday night that the reshuffling of docs that Carsten 
 started really seems more apt for a 2.2 release. Also, the switch to 
 Fortress and Real Blocks are destined towards that 2.2 release. I 
 understand some Avalon peeps are glad to dive in and help us 
 with that, 
 which is great, but we should facilitate them.

Yep, I have the same concerns.

 
 Some people want to start with a 2.2 CVS module right away, 
 others seem 
 more relunctant and want the HEAD of 2.1 to evolve into 2.2. 
 We need to 
 decide on this, since it's blocking progress.

Carsten made a good proposal how we can continue having 3 repositories
and how this can be done with only little code duplicating:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106076740711234w=2

I'm +1 with his proposal - the reason is simple: Some people (and
customers too!) asked me if we have gone crazy and how they can update
Cocoon in the future without being alpha/beta-tester for 'real' blocks
and Fortress. We *must* be able to maintain 2.1 without all new features
like blocks and Fortress because IMNSHO these steps are to big for 2.1
and I'm -1 on the changes in the current repository.

(the -1 is of course no veto only a vote! BTW: Do we have voting
guidelines?)

 My personal opinion is that 2.2 might warrant its own module, but we 
 need to discuss its structure and coexistence with old-style 
 blocks code 
 in more depth before we ask for its creation to the 
 infrastructure peeps.
 
 3) Given the breakage in the Rhino stuff, and the lack of serious 
 testing on the 2.1.1 release, I would refrain from announcing 
 2.1.1 (not 
 retracting it, though) 

Technically it has been released and I think many users monitoring our
lists are already using it. But a release is a release ... So +1 for
leaving it where it is but we should add a warning to the dowload pages
and we should send an 'official' mail having a subject like Cocoon
2.1.1 unstable to our mailling lists.

 and go for a new target release date 
 for 2.1.2 on 
 September 24th. 

I would prefer a release next week. I can help with tests.

 That way, we can discuss at leisure what we 
 are going to 
 do with the docs-reshuffling, and people can spend more time 
 on testing 
 new stuff.
 
 Please comment!

Additionally we have to think more about auto-testing our code. We have
some good unit tests and an Anteater script but that's not enough as we
have seen with 2.1.1.

Would it be enough to extend our Anteater scripts (see Guido's mail) and
add Anteater to our codebase and include it automatically to our build
system? 

So my question is: What kind of problems can't be found with
- unit tests
- regression tests?

BTW, unfortunatly the latest Anteater release needs Java 1.4.x ...

Cheers,
Reinhard


 
 /Steven
 -- 
 Steven Noelshttp://outerthought.org/
 Outerthought - Open Source Java  XMLAn Orixo Member
 Read my weblog athttp://blogs.cocoondev.org/stevenn/
 stevenn at outerthought.orgstevenn at apache.org

Re: on better release and version management

2003-09-10 Thread Bertrand Delacretaz

Le Mercredi, 10 sep 2003, à 11:26 Europe/Zurich, Reinhard Poetz a écrit 
:
...Would it be enough to extend our Anteater scripts (see Guido's 
mail) and
add Anteater to our codebase and include it automatically to our build
system? ...
certainly a Good Thing it tests are not too hard to write - anteater 
tests things from the user's point of view which would make us very 
confident that things actually work.

...BTW, unfortunatly the latest Anteater release needs Java 1.4.x ...
Not too big a problem IMHO, as tests will probably not be required to 
do a normal build.

-Bertrand

Re: Exception during undeploy

JBoss has its own concurrent.jar, what's loaded prior to Cocoon's jar. I 
tried to patch JBoss libs using jboss.patch.url pointing to Cocoon's 
concurrent.jar (it should at least work similar to endorsed dirs), but first 
it does not work and second one webapp should not influence the server.

At the end I changed the servlet class to ParanoidCocoonServlet in the 
web.xml of this Cocoon instance. Is there a better option?

Joerg

Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:30, Joerg Heinicke wrote:

As somebody might remember we had a problem with the undeployment with 
Tomcat. This was fixed in Cocoon 2.1.1 by updating excalibur event and util 
concurrent IIRC. Now the undeployment works and no process hangs but I get 
an exception (see below). Does any body has an idea (JBoss 3.0.6, Tomcat 
4.1.18, Cocoon 2.1.1, Java 1.4.1_03)? This exception did not occur in the 
three weeks old Cocoon version.


Could there be an older version of the PooledExecutor class somewhere in
the classpath?


2003-09-09 17:23:37,338 ERROR [org.jboss.web.localhost.Engine] - Root 
Cause -
java.lang.NoSuchMethodError: 
EDU.oswego.cs.dl.util.concurrent.PooledExecutor.shutdownNow()V
at 
org.apache.excalibur.event.command.TPCThreadManager.doDispose(TPCThreadManager.java:179)
at 
org.apache.excalibur.event.command.AbstractThreadManager.dispose(AbstractThreadManager.java:231)
at 
--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Re: Exception during undeploy

And I know why I asked for a better option: I get now

java.lang.LinkageError: duplicate class definition: 
org/apache/xml/dtm/ref/DTMManagerDefault
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at 
org.apache.cocoon.servlet.ParanoidClassLoader.loadClass(ParanoidClassLoader.java:153)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at org.apache.xml.dtm.FactoryFinder.newInstance(FactoryFinder.java:243)
at org.apache.xml.dtm.FactoryFinder.find(FactoryFinder.java:200)
at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:173)
at org.apache.xpath.XPathContext.init(XPathContext.java:125)
at 
org.apache.xalan.transformer.TransformerImpl.init(TransformerImpl.java:398)
at 
org.apache.xalan.templates.StylesheetRoot.newTransformer(StylesheetRoot.java:197)
at 
org.apache.xalan.processor.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:698)
at 
org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:328)

as similar described by Sylvain at 
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem. He suggests to 
remove the standard libraries from Cocoon's WEB-INF/lib, but then the webapp 
is again dependent on the server.

Joerg

Joerg Heinicke wrote:
JBoss has its own concurrent.jar, what's loaded prior to Cocoon's jar. I 
tried to patch JBoss libs using jboss.patch.url pointing to Cocoon's 
concurrent.jar (it should at least work similar to endorsed dirs), but 
first it does not work and second one webapp should not influence the 
server.

At the end I changed the servlet class to ParanoidCocoonServlet in the 
web.xml of this Cocoon instance. Is there a better option?

Joerg

Bruno Dumon wrote:

On Tue, 2003-09-09 at 17:30, Joerg Heinicke wrote:

As somebody might remember we had a problem with the undeployment 
with Tomcat. This was fixed in Cocoon 2.1.1 by updating excalibur 
event and util concurrent IIRC. Now the undeployment works and no 
process hangs but I get an exception (see below). Does any body has 
an idea (JBoss 3.0.6, Tomcat 4.1.18, Cocoon 2.1.1, Java 1.4.1_03)? 
This exception did not occur in the three weeks old Cocoon version.


Could there be an older version of the PooledExecutor class somewhere in
the classpath?



2003-09-09 17:23:37,338 ERROR [org.jboss.web.localhost.Engine] - 
Root Cause -
java.lang.NoSuchMethodError: 
EDU.oswego.cs.dl.util.concurrent.PooledExecutor.shutdownNow()V
at 
org.apache.excalibur.event.command.TPCThreadManager.doDispose(TPCThreadManager.java:179) 

at 
org.apache.excalibur.event.command.AbstractThreadManager.dispose(AbstractThreadManager.java:231) 

at 


--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

RE: Exception during undeploy

2003-09-10 Thread Reinhard Poetz


From: Joerg Heinicke 

 And I know why I asked for a better option: I get now
 
 java.lang.LinkageError: duplicate class definition: 
 org/apache/xml/dtm/ref/DTMManagerDefault
snip/

 as similar described by Sylvain at 
 http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem. 
 He suggests to 
 remove the standard libraries from Cocoon's WEB-INF/lib, but 
 then the webapp 
 is again dependent on the server.

After reading Sylvains good docs I think that the error you have should
*not* happen if you use the ParanoidCocoonServlet. 
The remaining problem with the ParanoidCocoonServlet is its strong
shielding mechanism: This means that if you get an object from the
servlet engine whose class is defined by the engine's classloader and
try to cast it to a class with the same class name, but loaded by the
ParanoidClassLoader, the cast will fail because the classes are
different. (see
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem - the
Downside)

HTH
Reinhard

 
 Joerg
 
 
 Joerg Heinicke wrote:
  JBoss has its own concurrent.jar, what's loaded prior to 
 Cocoon's jar. 
  I
  tried to patch JBoss libs using jboss.patch.url pointing 
 to Cocoon's 
  concurrent.jar (it should at least work similar to endorsed 
 dirs), but 
  first it does not work and second one webapp should not 
 influence the 
  server.
  
  At the end I changed the servlet class to 
 ParanoidCocoonServlet in the
  web.xml of this Cocoon instance. Is there a better option?
  
  Joerg
  
  Bruno Dumon wrote:
  
  On Tue, 2003-09-09 at 17:30, Joerg Heinicke wrote:
 
  As somebody might remember we had a problem with the undeployment
  with Tomcat. This was fixed in Cocoon 2.1.1 by updating excalibur 
  event and util concurrent IIRC. Now the undeployment works and no 
  process hangs but I get an exception (see below). Does 
 any body has 
  an idea (JBoss 3.0.6, Tomcat 4.1.18, Cocoon 2.1.1, Java 
 1.4.1_03)? 
  This exception did not occur in the three weeks old 
 Cocoon version.
 
 
 
  Could there be an older version of the PooledExecutor 
 class somewhere 
  in the classpath?
  
  
  
  2003-09-09 17:23:37,338 ERROR 
 [org.jboss.web.localhost.Engine] -
  Root Cause -
  java.lang.NoSuchMethodError: 
  EDU.oswego.cs.dl.util.concurrent.PooledExecutor.shutdownNow()V
  at 
  
 org.apache.excalibur.event.command.TPCThreadManager.doDispose(
TPCThreadManager.java:179) 
 
  at
  
 org.apache.excalibur.event.command.AbstractThreadManager.dispo
 se(AbstractThreadManager.java:231) 
 
  at
  
  
 
 -- 
 System Development
 VIRBUS AG
 Fon  +49(0)341-979-7419
 Fax  +49(0)341-979-7409
 [EMAIL PROTECTED]
 www.virbus.de

What is a suri?

2003-09-10 Thread Upayavira

In the CLI code, there is a variable called suri. I've never been able 
to work out what its name means, and thus what its purpose is. Can 
anyone explain?

Also, there are points in the code where a URI is deparameterized and 
then reparameterized. What is the point in this?

Regards, Upayavira

Re: Cocoon's FOP hardcoded with JAI?

Jeff Turner wrote:

I'd be interested to know if any other users experience this problem, and
also why Cocoon needs a recompiled FOP jar in the first place.
Me too, as I'm experiencing the exact same problem as you described, 
with jimi.jar on the classpath. Even worse, there isn't a supported 
version of JAI for Mac OSX.

With the latest binary release version of FOP, I have no problems at 
all, so unless someone objects, I'll revert to that one.

/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java  XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

DO NOT REPLY [Bug 23061] New: - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)

   Summary: BetwixtTransformer (analog to CastorTransformer)
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
   URL: http://jakarta.apache.org/commons/betwixt/
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Could you please add the Transformer to the scratchpad.

 can you briefly explain the differences between the two transformers.
 Whilst I am very familiar with the CastorTransformer (and Castor XML/JDO),
 I'd appreciate a quick overview of the functionality of the
 BetwixtTransformer, and what advantages it would offer to using the
 CastorTransformer.

I just compared some XML-Binding frameworks like JAXB, Castor, XMLBeans,
JiBX etc.
The one I most liked was Betwixt. It is very easy to use, produces SAX
events, it works with EJBs RemoteInterface, easy to use mapping files, clean
XML, supports Maps and Collection in a way I like it. And it is more
Beans-centric, good if you want to use your existing beans (Castor is more
Schema-centric, I think).

Some links:
How does Betwixt compare to technologies like JAXB and Castor?
http://jakarta.apache.org/commons/betwixt/faq.html#comparison

Writing Entity Beans
http://jakarta.apache.org/commons/betwixt/guide/writing.html#EJB

And the javadoc for BetwixtTransformer:

Betwixt transformer marshals a object from the Sitemap, Session, Request
or the Conext into a series of SAX events.
Configuation: The betwixt transformer can be configured to not output
  element reference ids. The default setting is to output
  reference IDs.
map:transformer
name=betwixt
src=org.apache.cocoon.transformation.BetwixtTransformer
  ref-idstrue/ref-ids
/map:transformer

Sample:
root xmlns:betwixt=http://apache.org/cocoon/betwixt-transfomer;
  betwixt:include name=invoice/
  betwixt:include name=product scope=sitemap/
  betwixt:include name=product2 element=other-product/
/root

The BetwixtTransfomer support only one Element betwixt:include.
This element is replaced with the marshalled object. The Object given
through the attribute name will be searched in the request, session,
context and at least in sitemap.
If the scope is explicitly given, the object will ge located only there.
The attribute element can be given to specify an alternativ
root element for the object. Collections are marshalled by marshalling
each object it contains.

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 11:27 ---
Created an attachment (id=8128)
org/apache/cocoon/transformation/BetwixtTransformer.java

Re: New protocol for in-memory resources

2003-09-10 Thread Geoff Howard

Tuomo L wrote:
On Tue, 9 Sep 2003, Vadim Gritsenko wrote:


Sylvain Wallez wrote:


Tuomo L wrote:


It would be convinient,
if one could use a protocolthat defines a source (FilePart) located
in memory.
This could be for example: multipart://foo.zip . Then it would
be possible to extract that in-memory zip-file to the target-dir.
Is this possible already, or am I going to wrong direction here?

You know that you can access files inside zip using jar: protocol, right?


This is an example scenario:

1. Client sends a server a request to send some files to another server
2. The first server zips up the files requested (for example with
   ZipArchiveSerializer) and does a HTTP Post to the second server
   also running Cocoon (Can be done with a custom action).
3. The second server receives the file, and extracts its contents to a
   directory defined in sitemap (Custom action here too).
4. The second server then automatically deletes the file. (Cocoon normal
   behaviour? Seems to me!)
So, if the file cannot be reacted on while it is in memory, it's lost. That's
why we need that kind of source. (Forget the zip-stuff, it's just an
example.)


This is not possible today, but really is the right direction, and
would be a valuable addition.


Wouldn't it be too much strain on system's resources (read: memory) in
production environment (with the exception of light uses like
departamental server) to render this feature useless? I agree though
that it might be actually convinient.


Isn't the uploaded file stored in memory at somepoint anyway, and then
dumped on disk? After the request/response is complete, the memory is
released, right?
Question: Is it even possible to react on an uploaded file
(if autosave-uploads=true), if it's deleted right after it arrives? At
which point of request/response does Cocoon delete the uploaded file?
Tuomo,

The file is in place before any processing begins (even before actions 
are executed) and deleted after the full request processing is over.  I 
had assumed you already knew about this -- if not, be sure to see the 
wiki resources on file uploads (search for upload should find at least 
three).  There is an example action and flow snippet for dealing with 
the uploaded file while you still have access to it.  If you are using 
2.1, you'll need to read the flow wiki document even if you're not using 
 flow (it gives an action example at the bottom).  This begs to get 
written up in a full-blown doc which I've been planning to do for some 
time.  If you get stuck, write back for more info (users list would 
probably be better).

If you knew all that and just wanted to propose a shortcut source view 
into uploaded files, I don't see why not. (Sylvain, did you mean it 
can't be implemented now or hasn't yet been implemented?)

Geoff

Re: BetwixtGenerator (was: EJB + Cocoon, Best Practices / Betwixt)

2003-09-10 Thread Christoph Gaffga

 Could you add an entry at Bugzilla and create an attachement containing
 your generator and an example showing its features?
 If you do it I will take care of it and add it to the scratchpad.

I have added it to bugzilla, bug #23061.
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061)

regards
Christoph

Re: [RT] Implementing Cocoon Blocks

2003-09-10 Thread Geoff Howard

Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:02, Geoff Howard wrote:
...

I also considered recording the wire-id instead of the uri for 
connections between blocks - what are the arguments for each?

connection was out of the blue using the wiring metaphore.  Other 
options?  Free association: connect, attach, solder, wire, use ...
Avalon Phoenix uses the words assembly and provide instead of
wiring and connection, which I quite like (I mean the assembly 
provide).
I don't quite see where these terms would be used - can you explain a 
little more?  Maybe a proposed set of changes to the example above?
Yep. I meant that the connection tag would become provide:
 provide
name=external-skincob:yetanothercompany.com/skins/fancy/1.2.2/provide
I think of the provide verb as applying more the the block.xml 
configuration (which isn't yet on the table).  The wiring.xml describes 
not what a block provides, but which services provided by other blocks 
plug in to its named dependencies.  OTOH, I guess the block manager 
could be seen as providing the solution to the named dependency...

And the wiring.xml would be called assembly.xml

OTOH, I'm meanwhile becoming accustomed to the wiring and connection
terms, so let's leave it as wiring and connection for now.
Ok, sounds good.

Geoff

Re: [RT] Implementing Cocoon Blocks

2003-09-10 Thread Geoff Howard

Bruno Dumon wrote:
On Tue, 2003-09-09 at 17:14, Geoff Howard wrote:

Bruno Dumon wrote:

On Sat, 2003-08-30 at 04:57, Geoff Howard wrote:
snip/
But this brings up another point - what to do if the wiring.xml and 
others is deleted?  Presumably, all blocks are uninstalled in this 
state, but what does this do to persistence requirements.

Also, how to recreate the deploy step efficiently?  For example:

You deploy a block with some dependencies and configuration.  The block 
deploy process walks you through setting configs and resolving 
dependencies.  You then have no record of these deployment choices 
except in wiring.xml which is not meant for human consumption.  Perhaps 
it would be good to record these human-step deployment time 
configurations in a conf file which could be easily reprocessed to 
easily re-deploy all blocks to their last configuration.


I think the conf file you're speaking of here is simply the wiring.xml
file itself? Remember, the block deployer has read-write access to this
file, so it can first read the existing information, then let the
administrator modify it, and then write it back. It's not like each time
you want to modify the configuration of one block you'll have to
re-enter all the parameters for other blocks as well.
Ugh, I see now that I didn't explain well the scenario I was thinking of 
and now can't remember!  IIRC I was trying to think through the process 
of replication and/or staging.  In this case, would I copy over 
wiring.xml and all blocks directories? (presumably)  But, what if some 
of the deploy-time configurations need to change on the way?  For 
instance, on a staging server, you use a different database.  So, I was 
just trying to get a picture in my head of how that would work and what 
the pitfalls were.


Aha, I understand the issue now. And next to staging and live servers
there are of course also the development servers or workstations. So
there are parameters which will be common for all installations and
parameters which can be different, and it would indeed be useful if we
can feed those common parameters to the block deployer, so that only
system-dependent parameters need to be completed.
Hmm, now that I think of it, it would also be useful to feed the
system-dependent parameters to the block deployer, because I don't want
to re-enter those either when I do a clean block deploy.
Basically what I'm arriving at is that the block deployer should be able
to run in an interaction-less mode by providing it with input files
giving it all the information.
Exactly.

Or then maybe it becomes more useful to write the wiring.xml by hand and
place a few @token@'s here and there which are replaced by an ant script
based on the values in a local.properties file.
Although the stated intention was that wiring.xml was not meant to be 
edited by hand (except by experts suppose).  So, wild thinking of 
options:

- ant filtering tokens as you propose
- good old xml xpath-based manipulation between servers (xsl or xpatch tool)
- option to deploy with variables/propertynames instead of literal 
values?  For instance, if for servername you can either provide a 
literal value or $property.name and have a .properties file which 
defines property.name=mydevserver.com.  That way, you manage only which 
properties file exists on each server?

Need to think more about this...
Yup, and there are probably a number of solutions which could work 
without modifying the wiring.xml structure at all so it could probably 
be revisited at implementation time.

Geoff

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]

Re: on better release and version management

2003-09-10 Thread Guido Casper

Steven Noels [EMAIL PROTECTED] wrote:
 3) Given the breakage in the Rhino stuff, and the lack of serious
 testing on the 2.1.1 release, I would refrain from announcing 2.1.1

How about putting a hotfix on the dist site like Tomcat is doing
http://nagoya.apache.org/mirror/jakarta/tomcat-4/binaries/

Currently that would just be the Rhino jar.

Guido

Re: New protocol for in-memory resources

Tuomo L wrote:

Isn't the uploaded file stored in memory at somepoint anyway,

No.


and then dumped on disk?

No. Cocoon should be able to process files which are larger than amount 
of memory on a box.


After the request/response is complete, the memory is
released, right?
 

Yes.

Vadim

Using FOP's Batik in Cocoon (Re: Cocoon's FOP hardcoded with JAI?)

2003-09-10 Thread Jeff Turner

On Wed, Sep 10, 2003 at 12:59:07PM +0200, Steven Noels wrote:
 Jeff Turner wrote:
 
 I'd be interested to know if any other users experience this problem, and
 also why Cocoon needs a recompiled FOP jar in the first place.
 
 Me too, as I'm experiencing the exact same problem as you described, 
 with jimi.jar on the classpath. Even worse, there isn't a supported 
 version of JAI for Mac OSX.
 
 With the latest binary release version of FOP, I have no problems at 
 all, so unless someone objects, I'll revert to that one.

+1

While you're at it, we should consider replacing Cocoon's Batik with that
from FOP 0.20.5.  Building FOP's site with CVS Forrest (fop 0.20.5 +
Batik from CVS) results in this error:

* [0] dev/svg/text.svg
Exception in thread main java.lang.NoSuchMethodError: 
org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/util/UnitProcessor$Context;
at org.apache.fop.svg.SVGElement.layout(SVGElement.java:218)
at 
org.apache.fop.fo.flow.InstreamForeignObject.layout(InstreamForeignObject.java:251)
at org.apache.fop.fo.flow.Block.layout(Block.java:257)
at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154)

Apparently this is a symptom of FOP requiring its own version of Batik:

http://archives.real-time.com/pipermail/cocoon-users/2003-June/035132.html
http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03372.html

When I switch in FOP's Batik, the problem disappears.  So I've committed
it for Forrest.

It's not clear-cut though.  Quoting the first referenced email:

  This [using FOP's Batik] may have negative impacts on Cocoons SVG
  serializer though, so you should not use a PDF generating pipeline
  which uses embedded or referenced SVGs and a SVG generating pipeline at
  the same time.

Cc'ing fop-dev's who better know the pros and cons of this move.


--Jeff

 
 /Steven
 -- 
 Steven Noelshttp://outerthought.org/
 Outerthought - Open Source Java  XMLAn Orixo Member
 Read my weblog athttp://blogs.cocoondev.org/stevenn/
 stevenn at outerthought.orgstevenn at apache.org

Re: Using FOP's Batik in Cocoon (Re: Cocoon's FOP hardcoded with JAI?)

The exception below was the reason for building our own FOP and not taking
the released fop.jar. Immediately before releasing Cocoon 2.1 somebody told
us that Cocoon's FOP and Batik are incompatible, but a rebuild of FOP using
Cocoon's Batik helped, so I did it too and committed the fop.jar.

I know FOP should be built with JAI and JIMI and I thought I have done it.
Sorry for any inconvenience.

The remaining question: Is Fop 0.20.5 incompatible to Batik 1.5? Is building
a fop.jar for Cocoon the correct way or must we downgrade the Batik version?

Joerg

Jeff Turner wrote:
On Wed, Sep 10, 2003 at 12:59:07PM +0200, Steven Noels wrote:

Jeff Turner wrote:

I'd be interested to know if any other users experience this problem, and
also why Cocoon needs a recompiled FOP jar in the first place.
Me too, as I'm experiencing the exact same problem as you described,
with jimi.jar on the classpath. Even worse, there isn't a supported
version of JAI for Mac OSX.

With the latest binary release version of FOP, I have no problems at
all, so unless someone objects, I'll revert to that one.

While you're at it, we should consider replacing Cocoon's Batik with that
from FOP 0.20.5. Building FOP's site with CVS Forrest (fop 0.20.5 +
Batik from CVS) results in this error:
* [0] dev/svg/text.svg
Exception in thread main java.lang.NoSuchMethodError:
org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/util/UnitProcessor$Context;
at org.apache.fop.svg.SVGElement.layout(SVGElement.java:218)
at
org.apache.fop.fo.flow.InstreamForeignObject.layout(InstreamForeignObject.java:251)
at org.apache.fop.fo.flow.Block.layout(Block.java:257)
at org.apache.fop.fo.flow.AbstractFlow.layout(AbstractFlow.java:154)
Apparently this is a symptom of FOP requiring its own version of Batik:

http://archives.real-time.com/pipermail/cocoon-users/2003-June/035132.html
http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03372.html
When I switch in FOP's Batik, the problem disappears. So I've committed
it for Forrest.
It's not clear-cut though. Quoting the first referenced email:

This [using FOP's Batik] may have negative impacts on Cocoons SVG
serializer though, so you should not use a PDF generating pipeline
which uses embedded or referenced SVGs and a SVG generating pipeline at
the same time.
Cc'ing fop-dev's who better know the pros and cons of this move.

--Jeff

/Steven
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Re: Using FOP's Batik in Cocoon (Re: Cocoon's FOP hardcoded with JAI?)

Joerg Heinicke wrote:

I know FOP should be built with JAI and JIMI and I thought I have done 
it. Sorry for any inconvenience.
No problem - it brings a sense of reality about our user base and their 
upgrade frequency, when we discover these things ourselves only after a 
few weeks or so. ;-)

The remaining question: Is Fop 0.20.5 incompatible to Batik 1.5? Is 
building a fop.jar for Cocoon the correct way or must we downgrade the 
Batik version?
From what I see on forrest-dev, Jeff has switched back to 
batik-1.5b4-fop.jar which comes with FOP. Maybe we should do that as well.

I'm on JDK1.4.1 without need for SVG processing though, so I cannot 
easily test eventual 1.3.1 issues.

/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java  XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

Re: Exception during undeploy

Hmm, I read it the other way around: This is exactly the error that can 
occur when using ParanoidCocoonServlet. Does anybody know more about such 
issues?

Joerg

Reinhard Poetz wrote:
From: Joerg Heinicke 


And I know why I asked for a better option: I get now

java.lang.LinkageError: duplicate class definition: 
org/apache/xml/dtm/ref/DTMManagerDefault
snip/

as similar described by Sylvain at 
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem. 
He suggests to 
remove the standard libraries from Cocoon's WEB-INF/lib, but 
then the webapp 
is again dependent on the server.


After reading Sylvains good docs I think that the error you have should
*not* happen if you use the ParanoidCocoonServlet. 
The remaining problem with the ParanoidCocoonServlet is its strong
shielding mechanism: This means that if you get an object from the
servlet engine whose class is defined by the engine's classloader and
try to cast it to a class with the same class name, but loaded by the
ParanoidClassLoader, the cast will fail because the classes are
different. (see
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem - the
Downside)

HTH
Reinhard
--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Re: New protocol for in-memory resources

Geoff Howard wrote:

Tuomo L wrote:

On Tue, 9 Sep 2003, Vadim Gritsenko wrote:


Sylvain Wallez wrote:


Tuomo L wrote:


It would be convinient,
if one could use a protocolthat defines a source (FilePart) located
in memory.
This could be for example: multipart://foo.zip . Then it would
be possible to extract that in-memory zip-file to the target-dir.
Is this possible already, or am I going to wrong direction here?


You know that you can access files inside zip using jar: protocol, 
right?


This is an example scenario:

1. Client sends a server a request to send some files to another server
2. The first server zips up the files requested (for example with
   ZipArchiveSerializer) and does a HTTP Post to the second server
   also running Cocoon (Can be done with a custom action).
3. The second server receives the file, and extracts its contents to a
   directory defined in sitemap (Custom action here too).
4. The second server then automatically deletes the file. (Cocoon normal
   behaviour? Seems to me!)
So, if the file cannot be reacted on while it is in memory, it's 
lost. That's
why we need that kind of source. (Forget the zip-stuff, it's just an
example.)



This is not possible today, but really is the right direction, and
would be a valuable addition.


Wouldn't it be too much strain on system's resources (read: memory) in
production environment (with the exception of light uses like
departamental server) to render this feature useless? I agree though
that it might be actually convinient.


Isn't the uploaded file stored in memory at somepoint anyway, and then
dumped on disk? After the request/response is complete, the memory is
released, right?
Question: Is it even possible to react on an uploaded file
(if autosave-uploads=true), if it's deleted right after it arrives? At
which point of request/response does Cocoon delete the uploaded file?


Tuomo,

The file is in place before any processing begins (even before actions 
are executed) and deleted after the full request processing is over.  
I had assumed you already knew about this -- if not, be sure to see 
the wiki resources on file uploads (search for upload should find at 
least three).  There is an example action and flow snippet for dealing 
with the uploaded file while you still have access to it.  If you are 
using 2.1, you'll need to read the flow wiki document even if you're 
not using  flow (it gives an action example at the bottom).  This begs 
to get written up in a full-blown doc which I've been planning to do 
for some time.  If you get stuck, write back for more info (users list 
would probably be better).

If you knew all that and just wanted to propose a shortcut source 
view into uploaded files, I don't see why not. (Sylvain, did you mean 
it can't be implemented now or hasn't yet been implemented?) 


I just said it's not implemented now but would be nice to have. I would 
love to hide the storage details of the uploaded content (memory, 
filesystem, whatever) behind a multipart protocol.

Sylvain

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

Re: Flow and map:handle-errors

2003-09-10 Thread Timothy Larson

--- Sylvain Wallez [EMAIL PROTECTED] wrote:
 Error-handlers are not invoked on internal requests, which is what the 
 flow uses behind sendPage[AndWait](). In that case, the exception are 
 propagated.

How do you catch these exceptions in a flowscript?  I tried a simple
  try{sendPageAndWait(some-page-with-an-error)}
  catch(){sendPageAndWait(some-custom-error-page}
but the catch never caught an exception.  Instead I just got the standard
error page in the browser.

 Internal requests are created in 2 circumstances :
 - use of SitemapSource: SourceResolver.resolveURI(cocoon:/blah)
 - use of internal redirects: map:redirect-to uri=cocoon:/blah/ or 
 Redirector.redirect(cocoon:/blah)
 
 The flow uses an internal redirect to handle an external request. This 
 means that the propagated exception is only catched by the top-level 
 Cocoon object which outputs the default error page (if configured to do 
 so). So we can say that the behaviour of not executing error handlers 
 for internal requests is not suitable for internal redirects.

Does this mean that we cannot catch the exception from the flowscript?
That would be bad.

 There are 2 solutions to solve this :
 1/ apply the same policy for internal redirects than the one that was 
 active before the redirect (i.e. handle errors on internal redirects 
 resulting from external requests)
 2/ let the user choose the behaviour through the a new attribute such as 
 handle-internal=true on handle-errors.

 Thinking further, these 2 solutions are complementary if we consider 
 that 2/ applies only to internal requests produced by the SitemapSource.
 
 What do you think ?

I personally would be happy if the flowscript could catch errors as
exceptions and create its own responses, such as sending an alternate page
or an error page.

It would be nice to also have the option of letting the sitemap handle-errors
pipeline take care of it, but I am not too worried about this if I can get my
first wish.  I guess this last part is asking for a way to make solution 1
optional, possibly per call to sendPage[AndWait](), but I am not sure since
my current use case gives me no hints.

--Tim Larson


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 15:05 ---
I added your transformer to the scratchpad block - only some minor changes:

- made element attribute optional
- code formating
- changed namespace to http://apache.org/cocoon/betwixt/1.0

Please test it and it would be nice if you could add some more examples.

Re: New protocol for in-memory resources

Upayavira wrote:

Don't know if you've seen Carsten Ziegler and Matthew Langham's book 
on Cocoon. It cover's how to add protocols/sources to Cocoon (on 
2.0.4, but once you've understood that, doing it on 2.1 shouldn't be 
hard). 


It basically consists in writing an implementation of SourceFactory and 
Source (those in Avalon Excalibur, for Cocoon 2.1), and add the 
SourceFactory class name to cocoon.xconf.

There are several implementations in Excalibur and in Cocoon, and 
writing a simple source (not writeable, not traversable, not etc...) 
should be quite easy.

Sylvain

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

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 15:42 ---

I noticed a strange behaviour: The first time I call the transformer it doesn't
work. The next attempts are successful. Could you please check this.

Reinhard

Re: on better release and version management

Steven Noels wrote:
Hi folks,

forgive me for putting on my BOFH hat, while making the following 
observations...

1) We suck at freezing and stabilizing the codebase prior to releases.

I would suggest that, from now on, the Release Manager puts forward a 
release date after discussion on the dev list, and that there's a 
two-day (!) freeze period where only glaring bugs can be fixed after a 
vote (!) on the list.

The Release Manager him/herself is also only allowed to commit obvious 
version number changes and all that during this two-day Sperr-zone.

During the past few releases, there was a flurry of quick fixes and 
commits happening just hours before Carsten made the tarball, and while 
I'm not immediately aware of any nasty side-effects caused by this, it 
sure doesn't look like there was time for any peer review on these late 
commits, neither did it look organized at all.
+1 Yes, we should handle the release process more restrictive.

2) We need to break from the impasse of 2.1.1 vs 2.2

I suggested yesterday night that the reshuffling of docs that Carsten 
started really seems more apt for a 2.2 release. Also, the switch to 
Fortress and Real Blocks are destined towards that 2.2 release. I 
understand some Avalon peeps are glad to dive in and help us with that, 
which is great, but we should facilitate them.

Some people want to start with a 2.2 CVS module right away, others seem 
more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to 
decide on this, since it's blocking progress.

My personal opinion is that 2.2 might warrant its own module, but we 
need to discuss its structure and coexistence with old-style blocks code 
in more depth before we ask for its creation to the infrastructure peeps.
But we should priorize all maintenance tasks first. For example the patches 
in Bugzilla: it will be more and more effort to patch Cocoon's code. What 
happens? The older Cocooon versions are as nearly as dead. See 2.0 - who 
cares about it? The same will happen with 2.1 if we open a 2.2 CVS module. 
c'est la vie? Evolution?

3) Given the breakage in the Rhino stuff, and the lack of serious 
testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not 
retracting it, though) and go for a new target release date for 2.1.2 on 
September 24th. That way, we can discuss at leisure what we are going to 
do with the docs-reshuffling, and people can spend more time on testing 
new stuff.
I guess the 2.1 had more and harder errors (e.g. the impossible undeployment 
in Tomcat), so I think it's no problem to announce this as improvement 
including the notice, that there is now another problem. It's ok IMO, if the 
2.1.2 follows in a little while.

Joerg

--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 16:29 ---
Thanks for adding the file so quickly

 I noticed a strange behaviour: The first time I call the transformer
 it doesn't work. The next attempts are successful. Could you please
 check this.

I will check this as fast as possible. I've some other work to be done, but we 
want to have the BetwixtTransfomer to be in production on our servers before 
sunday. So I will post a patch this week.

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 16:57 ---

The problem is line 234 

   synchronized (introspector)

I throws a NullPointerException because introspector has never been instantiated.

HTH
Reinhard

Re: Removing usage of LogKitManager / LogKitManagable

2003-09-10 Thread Peter Royal

On Tuesday, September 9, 2003, at 03:30  PM, Joerg Heinicke wrote:
Ok, done. The vote for the change was unambiguous. Please review my 
commits and change the code if necessary.
Done. your changes mirrored mine for the most part, and I just layered 
a few more on top (complete eviction of LogKitManager/able from the 
codebase) as well as allowing logging in CocoonServlet to be replaces 
by a subclass (so now a Log4JCocoonServlet should be pretty easy, if 
someone wants to do it)
-pete

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 18:10 ---
The NullPointerException caused by the synchronized block should be gone.

DO NOT REPLY [Bug 23061] - BetwixtTransformer (analog to CastorTransformer)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23061

BetwixtTransformer (analog to CastorTransformer)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 18:11 ---

patch applied, bug fixed

Re: Flow and map:handle-errors

Sylvain Wallez wrote:

The flow uses an internal redirect to handle an external request. This 
means that the propagated exception is only catched by the top-level 
Cocoon object which outputs the default error page (if configured to 
do so). So we can say that the behaviour of not executing error 
handlers for internal requests is not suitable for internal redirects.


Can you clarify something first. If exception has happened during 
map:call function=.../ processing (which called some other internal 
resource, but it does not matter right now), will sitemap catch this 
exception and proceed to the map:handle-erorrs/?

If yes: what's the issue than? Use handle-errors!
If no: we clearly have the bug of enormous size! :)
Vadim

Re: Flow and map:handle-errors

Sylvain Wallez wrote:

There are 2 solutions to solve this :
1/ apply the same policy for internal redirects than the one that 
was active before the redirect (i.e. handle errors on internal 
redirects resulting from external requests)

This totally makes sense.


2/ let the user choose the behaviour through the a new attribute 
such as handle-internal=true on handle-errors.

Might be unnecessary complication.
...
I would say that 1/ is required as it can be considered as a bug.


Agreed.

Vadim

[vote] Remove org.apache.cocoon.components.xpath.*