Re: [RT] Attribute Rendering and CForms Convertors

[Jonas Ekstedt]

On Wed, 2004-11-10 at 12:15 +0100, Daniel Fagerstrom wrote:

> CForms Convertor Integration
> 
> 
> Here is the Convertor interface:
> 
> public interface Convertor {
> 
> /**
>  * Converts string representation into the object of convertor's type.
>  *
>  * @param formatCache can be null if not needed
>  */
> ConversionResult convertFromString(String value, Locale locale, 
> FormatCache formatCache);
> 
> String convertToString(Object value, Locale locale, FormatCache 
> formatCache);
> 
> Class getTypeClass();
> 
> /**
>  * Generates a bit of information about this convertor (optional).
>  */
> void generateSaxFragment(ContentHandler contentHandler, Locale locale) 
> throws SAXException;
> 
> public interface FormatCache {
> public Object get();
> public void store(Object object);
> }
> }
> 
> The main problem is the ConversionResult. It is a class that in turn 
> uses some CForms specific stuff, (ValidationError, I18NMessage and 
> Cosntants). I think the idea of having a ConversionResult is ok, but we 
> need to make it independent of the rest of CForms.
> 
> AFAICS we don't need the formatCache in a convertion component, each 
> convertor will only be needed to be defined once. The 
> generateSaxFragment is also somewhat specific for my taste, I wonder if 
> that is part of the convertion concern. Furthermore it has an empty 
> implementation in all the convertors within CForms, so it is hard to see 
> what it is supposed to be good for.
> 
> The CForms convertors is not configured the standard Avalon way. Mainly 
> because the Avalon configuration doesn't handle name spaces.

How about an interface like this:

public interface Convertor {

public String getId();
public void setId(String id);
public Class getTypeClass();
public String convertToString(Object value, Locale locale) 
throws Exception;
public Object convertFromString(String value, Locale locale) 
throws Exception;

}

Each convertor has an id (useful for error reporting when conversion
fails) and a typeClass (ie the class type it converts to/from). Those
convertors that need extra configuration would implement Configurable.

The convertors would be created by a ConvertorManager configured by
something like:


  

  
short
  

  
full
  

  
MM/dd/
-MM-dd
  



The convertors are accessed from a ConvertorManager:
public Convertor getConvertor(String id);

The id's of each convertor would take the form of className#type so that
whoever uses the convertors can do something like:

String className = obj.getClass().getName();
convertor = convManager.getConvertor(className + "#" + type);
String str = convertor.convertToString(obj, locale);

One problem with this type of configuration would be that it is hard to
implement a fallback mechanisms (eg if we don't have a
"java.util.Date#full" converter use "java.util.Date"). However I don't
know how useful fallback would be anyway (see below).

> 
> What lacks in CForms Convertor from our POV, is a way to use 
> presentation classes. Maybe also would like to have more general 
> convertion between objects in general. I have no use cases for that and 
> I would prefer keeping it as simple as possible.

One possible use case for other types of conversion would be Iterator
conversion. This could be useful in forEach template tags. Eg:


  ...


Then you could use forEach for any object type that has an Object <->
Iterator convertor.

> 
> 
> Presentation Classes
> 
> 
> We need to find a good syntax for presentation classes. I'm not 
> completely convinced about the '#' selector, as it normally is connected 
> to positions, but I don't have any better suggestions. The 
> ${date?class=short} is unecesarilly verbose as class is the only 
> attribute that we use. Using specialized tags might also be an 
> alternative. But that is rather clumsy for xml attributes, and it would 
> be nicer to have a mechanism that is not connected to a certain template 
> language.

I think the choice of separator character is rather limited as it cannot
be either a legal variable name character nor a legal operator
character. Someone might want to do ${1+1#decimal}.

> 
> How does type, locale and class interact? I would propose to have the 
> priority order type > locale > class. Meaning that if type, locale and 
> class are given the convertion component will first look for convertions 
> having the right type, if none is given a default convertor (.toString) 
> is used. If there are convertors of the right type but not the right 
> locale, the default convertor for the type is used. If there are 
> convertors of the right type and locale, but not with the right class, 
> the default convertor for the type and locale is used.

Wouldn't it be easier to just throw an exception if the correct type of
convertor couldn't be found. The fallback con

DO NOT REPLY [Bug 32219] - [PATCH] Ensures that a DatatypeBuilders convertor-builder selector is disposed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32219

[PATCH] Ensures that a DatatypeBuilders  convertor-builder selector is disposed





--- Additional Comments From [EMAIL PROTECTED]  2004-11-13 02:05 ---
Created an attachment (id=13424)
patch for AbstractDatatypeBuilder

DO NOT REPLY [Bug 32219] New: - [PATCH] Ensures that a DatatypeBuilders convertor-builder selector is disposed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32219

[PATCH] Ensures that a DatatypeBuilders  convertor-builder selector is disposed

   Summary: [PATCH] Ensures that a DatatypeBuilders  convertor-
builder selector is disposed
   Product: Cocoon 2
   Version: Current SVN 2.2
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: CocoonForms
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Currently a datatypes convertor-builder selector is not disposed. This becomes a
problem if any of the convertor builders implements Disposable as it will never
be called.

Re: [cli] Problem / Question with context directory needing to be writable

[David Crossley]

Sylvain Wallez wrote:
Upayavira wrote:
Says:
if (!(d.canRead() && d.canWrite())) {
   log.error("Directory '" + d + "' is not readable/writable");
   throw new IOException("Directory '" + d + "' is not 
readable/writable");
   }

Hmm. This has been in the CLI since Cocoon 2.0. I've no idea why it is 
there. Assuming that everything still works after removing the 
d.canWrite(), I'm quite happy with it being removed.
+1.
If Carsten agrees, it would be good for this bug fix to go in 2.1.6 so 
that Forrest can close the issue with a released version of Cocoon.
Forrest uses cocoon-2.2 at the moment, so no need to
do it solely for us.
--David

JSR-168 Portlets

[Ralph Goers]

I have been working for the last 2 days trying to figure out how to get 
JSR-168 portlets, packaged as their own webapp, to work with the Cocoon 
portal.  Has anyone ever gotten this to work?  I have come to the 
conclusion that, due to the design of Pluto, it is not realistically 
possible.

The problem I am seeing is that Pluto has a couple of singleton classes 
that it needs to share between the Portal webapp (i.e. Cocoon) and the 
portlet webapp. This requires that the pluto jar file be placed in 
Tomcat's shared/lib directory.  However, because Tomcat places the 
WEB-INF/lib above shared/lib in the class loader chain any Cocoon 
classes that reference pluto classes will get a ClassNotFoundException 
unless they are also placed in shared lib.  Needless to say, this will 
end up with all of Cocoon and everything it uses in shared/lib in short 
order.

Maybe I'm missing something, but I just don't understand why Pluto has 
to require the singleton classes.  It would make more sense to me for 
Pluto to store references to the singleton objects in ServletContext 
attributes and then anchor those into a singleton in the Portlet webapp 
when Pluto's PortletServlet is entered.

Comments?
Ralph

Re: [cli] Problem / Question with context directory needing to be writable

[Rick Tessner]

Upayavira wrote:
Says:
if (!(d.canRead() && d.canWrite())) {
   log.error("Directory '" + d + "' is not readable/writable");
   throw new IOException("Directory '" + d + "' is not 
readable/writable");
   }

Hmm. This has been in the CLI since Cocoon 2.0. I've no idea why it is 
there. Assuming that everything still works after removing the 
d.canWrite(), I'm quite happy with it being removed.
Patch for this can be found in bugzilla:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=32214
--
Rick Tessner
[EMAIL PROTECTED]


smime.p7s
Description: S/MIME Cryptographic Signature

DO NOT REPLY [Bug 32208] - [PATCH] lucene block contribution : a AnalyzerManager component

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32208

[PATCH] lucene block contribution : a AnalyzerManager component





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 22:54 ---
(sorry for my english)

I was frustrated with the LuceneIndexTransformer because i CAN'T use custom
analyzer with a constructor with parameters.

Re: CForms Wizards

[Sylvain Wallez]

Sylvain Wallez wrote:
That could be something like:
function validateWizard() {
 currentPage.setState(WidgetState.INVISIBLE); // another one may be 
chosen below
 for (page in pageList) {
   page.setState(WidgetState.ACTIVE);
   if (page.validate()) {
 page.setState(WidgetState.INVISIBLE);
   } else {
 return false; // validation failed
   }
 }

return true; // all pages validated
}

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

Re: [cli] Problem / Question with context directory needing to be writable

[Sylvain Wallez]

Upayavira wrote:
Says:
if (!(d.canRead() && d.canWrite())) {
   log.error("Directory '" + d + "' is not readable/writable");
   throw new IOException("Directory '" + d + "' is not 
readable/writable");
   }

Hmm. This has been in the CLI since Cocoon 2.0. I've no idea why it is 
there. Assuming that everything still works after removing the 
d.canWrite(), I'm quite happy with it being removed.

+1.
If Carsten agrees, it would be good for this bug fix to go in 2.1.6 so 
that Forrest can close the issue with a released version of Cocoon.

Sylvain

Rick Tessner wrote:
 Hi all,
 Over in the Forrest world, we've stumbled across an issue with the
 Cocoon CLI. It appears that the CLI requires that the context
 directory (--contextDir option to the cocoon cli) be writable by the
 CLI process. For reference, see
 http://issues.cocoondev.org//browse/FOR-356
 The Use Case  This applies to any Cocoon CLI based
 application that can be run as a servlet as well. I'll just use
 Forrest as the example case.
 Forrest is installed on a multiuser system with the intent that
 multiple users will be running the application.
 The Problem --- User runs "forrest run" which runs Forrest in
 a local servlet container (jetty) as a live application. This works
 just fine.
 User runs "forrest site" which uses the Cocoon CLI and is presented
 with a Cocoon error about the context directory not being
 readable/writable. The context directory is certainly readable. It
 is not writable tho.
 The stack-trace is as follows: ERROR 2004-11-11 18:32:20.353 [
 ] (): Directory '.' is not readable/writable Exception in thread
 "main" java.io.IOException: Directory '.' is not readable/writable at
 org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
 at
 org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
 at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
 at org.apache.cocoon.Main.main(Main.java:320)
 The Question  Since the local servlet instance works fine
 with the context directory being non-writable, I'm wondering if there
 is some requirement that the context directory is writable when
 running the Cocoon CLI?
 If the answer is "no, there is no requirement that the context
 directory is writable by the Cocoon CLI", I'll open an issue in
 bugzilla and provide a patch. (I'm hoping this is the case since
 making the context directory for Cocoon writable to all users doesn't
 leave me with a warm fuzzy feeling. :)

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

Re: CForms Wizards

[Sylvain Wallez]

Reinhard Poetz wrote:
Sylvain Wallez wrote:
Sylvain Wallez wrote:
Sorry to rain on the party, but the new widget state stuff in CForms 
should make building multi-page forms a piece of cake.

Off writing an example

Done, I wrote my first wizard with CForms :-)
Please update branch 2.1.x and point your browser to 
http://localhost:/forms-samples/do-multipage.flow

Enjoy!

Great, thanks for the example! One question: IIUC the wizard is driven 
by the widget states and the event handling mechanism.

Yes: the various "pages" are widget groups (fd:struct) whose state is 
set either to active or invisible depending on the displayed page. The 
initial state, in the form definition, is to have only page1 being 
active, others being invisible. Navigation is managed by fd:action that 
change the page state. "next" validates the current page whereas "prev" 
doesn't. On the last page, a fd:submit goes back to flowscript if 
validation is successful.

This may solve many use cases but would it be possible to control 
which part of the form is shown by the controller (flowscript) which 
would bring some more flexibility (mix in non-forms pages, jump to 
different sub-pages)?

That is possible if you use fd:submit instead of fd:action when control 
has to come back to flowscript. Since only the active widgets are 
validated, the submit will be sucessful if the widgets in the current 
page are valid, not taking other pages into account. It's then the 
flowscript's responsibility to display the appropriate page when calling 
again form.showForm().

[some pseudocode ...]
var myFlow() {
  var form = new Form("myForm");
  form.load(myBean);
  form.showSubForm("myPipeline", "../page1");
  cocoon.sendPageAndWait("showAnotherPage");
  form.showSubForm("myPipeline", "../page");
  form.save(myBean);
}

The "showSubForm" above would simply set all pages to invisible state 
except the one defined by the second parameter (which should be "pageX" 
rather than "../pageX").

And while writing this, another question came up: What's the best way 
to deal with validation errors? example: On page 2 the users enters 
something that wouldn't let page 1 validate any more. Can we handle this?

Validation of the last page could revalidate previous pages in order, 
and switch back to the first one that doesn't validate successfully.

That could be something like:
function validateWizard() {
 currentPage.setState(WidgetState.INVISIBLE); // another one may be 
chosen below
 for (page in pageList) {
   page.setState(WidgetState.ACTIVE);
   if (page.validate()) {
 page.setState(WidgetState.INVISIBLE);
   } else {
 return false; // validation failed
   }
 }
}

Setting the page state to active before calling validate() is important 
as non-active widgets are not validated. That isn't a problem here since 
we must redisplay a page that doesn't validate, but I'm thinking of 
adding a Widget.validate(boolean force) method, that would, when "force" 
is true, validate widgets whatever their state.

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

DO NOT REPLY [Bug 30040] - JS 'popups' are rendered behind select lists and applets.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30040

JS 'popups' are rendered behind select lists and applets.





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 22:07 ---
Created an attachment (id=13422)
Patch does not work for forms with tabs

DO NOT REPLY [Bug 32214] - [PATCH] context directory not required to be writable by the CLI

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32214

[PATCH] context directory not required to be writable by the CLI





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 21:35 ---
Created an attachment (id=13421)
Remove requirement that context directory be writable.  Patch created against 
rev 57496 (trunk)

DO NOT REPLY [Bug 32214] New: - [PATCH] context directory not required to be writable by the CLI

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32214

[PATCH] context directory not required to be writable by the CLI

   Summary: [PATCH] context directory not required to be writable by
the CLI
   Product: Cocoon 2
   Version: Current SVN 2.2
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


See http://marc.theaimsgroup.com/?t=11002936324&r=1&w=2 for details on the
issue.

The Cocoon CLI cannot be used in a multi-user environment without making the
context directory writable by all.  This requirement does not exist when running
cocoon as a local live app (via jetty).

DO NOT REPLY [Bug 32213] New: - Error handling and subsitemaps - errors not handled in subsitemap in special cases

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32213

Error handling and subsitemaps - errors not handled in subsitemap in special 
cases

   Summary: Error handling and subsitemaps - errors not handled in
subsitemap in special cases
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Consider this code:
=
root sitemap:





[...]


[...]

[...]


=
subsitemap :



[...]


[...]



Now, lets try this URL: "subsite/sth.html"; "sth" pipeline throws
exception but it will never reach handle-errors block in subsitemap.
It's handled by root sitemap exception handler.
I check it out even with no exception selector.

Well, I'm sure that's becouse of "*/**.html" pipeline is first matched;

It looks like busting error handlig conception - subsitemap specific errors
shouldn't be handled in root sm.

Re: [cli] Problem / Question with context directory needing to be writable

[Upayavira]

Says:
if (!(d.canRead() && d.canWrite())) {
   log.error("Directory '" + d + "' is not readable/writable");
   throw new IOException("Directory '" + d + "' is not 
readable/writable");
   }

Hmm. This has been in the CLI since Cocoon 2.0. I've no idea why it is 
there. Assuming that everything still works after removing the 
d.canWrite(), I'm quite happy with it being removed.

Regards, Upayavira
Rick Tessner wrote:
 Hi all,
 Over in the Forrest world, we've stumbled across an issue with the
 Cocoon CLI. It appears that the CLI requires that the context
 directory (--contextDir option to the cocoon cli) be writable by the
 CLI process. For reference, see
 http://issues.cocoondev.org//browse/FOR-356
 The Use Case  This applies to any Cocoon CLI based
 application that can be run as a servlet as well. I'll just use
 Forrest as the example case.
 Forrest is installed on a multiuser system with the intent that
 multiple users will be running the application.
 The Problem --- User runs "forrest run" which runs Forrest in
 a local servlet container (jetty) as a live application. This works
 just fine.
 User runs "forrest site" which uses the Cocoon CLI and is presented
 with a Cocoon error about the context directory not being
 readable/writable. The context directory is certainly readable. It
 is not writable tho.
 The stack-trace is as follows: ERROR 2004-11-11 18:32:20.353 [
 ] (): Directory '.' is not readable/writable Exception in thread
 "main" java.io.IOException: Directory '.' is not readable/writable at
 org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
 at
 org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
 at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
 at org.apache.cocoon.Main.main(Main.java:320)
 The Question  Since the local servlet instance works fine
 with the context directory being non-writable, I'm wondering if there
 is some requirement that the context directory is writable when
 running the Cocoon CLI?
 If the answer is "no, there is no requirement that the context
 directory is writable by the Cocoon CLI", I'll open an issue in
 bugzilla and provide a patch. (I'm hoping this is the case since
 making the context directory for Cocoon writable to all users doesn't
 leave me with a warm fuzzy feeling. :)

[cli] Problem / Question with context directory needing to be writable

[Rick Tessner]

Hi all,
Over in the Forrest world, we've stumbled across an issue with the 
Cocoon CLI. It appears that the CLI requires that the context directory 
(--contextDir option to the cocoon cli) be writable by the CLI process.
For reference, see http://issues.cocoondev.org//browse/FOR-356

The Use Case

This applies to any Cocoon CLI based application that can be run as a 
servlet as well.  I'll just use Forrest as the example case.

Forrest is installed on a multiuser system with the intent that multiple 
users will be running the application.

The Problem
---
User runs "forrest run" which runs Forrest in a local servlet container 
(jetty) as a live application.  This works just fine.

User runs "forrest site" which uses the Cocoon CLI and is presented with 
a Cocoon error about the context directory not being readable/writable. 
 The context directory is certainly readable.  It is not writable tho.

The stack-trace is as follows:
ERROR   2004-11-11 18:32:20.353 [] (): Directory '.' is not 
readable/writable
Exception in thread "main" java.io.IOException: Directory '.' is not
readable/writable
at
org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
at
org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
at
org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
at org.apache.cocoon.Main.main(Main.java:320)

The Question

Since the local servlet instance works fine with the context directory 
being non-writable, I'm wondering if there is some requirement that the 
context directory is writable when running the Cocoon CLI?

If the answer is "no, there is no requirement that the context directory 
is writable by the Cocoon CLI", I'll open an issue in bugzilla and 
provide a patch.  (I'm hoping this is the case since making the context 
directory for Cocoon writable to all users doesn't leave me with a warm 
fuzzy feeling. :)

--
Rick Tessner
[EMAIL PROTECTED]


smime.p7s
Description: S/MIME Cryptographic Signature

CForms Wizards

[Reinhard Poetz]

Sylvain Wallez wrote:
Sylvain Wallez wrote:
Sorry to rain on the party, but the new widget state stuff in CForms 
should make building multi-page forms a piece of cake.

Off writing an example

Done, I wrote my first wizard with CForms :-)
Please update branch 2.1.x and point your browser to 
http://localhost:/forms-samples/do-multipage.flow

Enjoy!
Great, thanks for the example! One question: IIUC the wizard is driven by the 
widget states and the event handling mechanism. This may solve many use cases 
but would it be possible to control which part of the form is shown by the 
controller (flowscript) which would bring some more flexibility (mix in 
non-forms pages, jump to different sub-pages)?

[some pseudocode ...]
var myFlow() {
  var form = new Form("myForm");
  form.load(myBean);
  form.showSubForm("myPipeline", "../page1");
  cocoon.sendPageAndWait("showAnotherPage");
  form.showSubForm("myPipeline", "../page");
  form.save(myBean);
}
And while writing this, another question came up: What's the best way to deal 
with validation errors? example: On page 2 the users enters something that 
wouldn't let page 1 validate any more. Can we handle this?

--
Reinhard

DO NOT REPLY [Bug 32212] - [PATCH] Enable development of blocks outside of cocoon source tree

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32212

[PATCH] Enable development of blocks outside of cocoon source tree





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 20:08 ---
Created an attachment (id=13420)
patch for tools/src/blocks-build.xsl

DO NOT REPLY [Bug 32212] New: - [PATCH] Enable development of blocks outside of cocoon source tree

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32212

[PATCH] Enable development of blocks outside of cocoon source tree

   Summary: [PATCH] Enable development of blocks outside of cocoon
source tree
   Product: Cocoon 2
   Version: Current SVN 2.2
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This patch enables development of new blocks outside of the cocoon source tree.
Suppose you're developing a block called myblock then you can write in your
local.blocks.properties:

block.myblock.dir=/path/to/myblock

You also need to add myblock to gump.xml. In /path/to/myblock you need to have a
directory layout similar to what normal blocks have ie conf, java, lib, samples 
etc.

RE: svn commit: rev 57536 - in cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples: . flow forms resources

[Carsten Ziegeler]

Sylvain Wallez wrote:
> Well, this is a new sample that illustrates some of the new 
> CForms features that were written before the code freeze.
> 
> So if the release is done from a fresh checkout, and not rev 
> 57527, let's include them! Otherwise, that's not that important ;-)
> 
Ah, ok, thanks - I just wanted to figure out, if I have to use 
rev 57527 or safely can include your changes. Thanks

Carsten

Cocoon PMC report, November 2004

[Sylvain Wallez]

Hi board,
Here's the November 2004 report for the Cocoon project.
Community:
- The 3rd Cocoon GetTogether, yearly meeting of Cocoon users and 
developers, whas held as is usual now in Gent (Belgium) in early 
october. That was again a great success with 140 people coming from 17 
countries, an active hackaton and interesting presentations.

- There was a relative traffic slowdown on the dev list during spring 
and summer, mostly because people were very busy. After the GetTogether, 
the activity on the dev list raised back to its usual traffic and lots 
of interesting discussions are happening.

- We have two new committers, Ralph Goers and Leszek Gawron.
- Cocoon 2.1.6, is planned to be released next week, this is a 
maintainance release while development continues on the 2.2 branch.

- Lenya is no more a in the Cocoon TLP as it successfully exited 
incubation and moved to top-level.

- The death of Avalon and the fact that our component manager is 
considered as deprecated by the Excalibur project led us to fork it. 
These are only 15 source files, which allow us to master the foundations 
on which Cocoon is built.

Legal:
The legal issues we had with the Rhino fork supporting continuations are 
about to be solved, as the Mozilla Rhino team has added continuation 
support in the official Rhino, and Cocoon will therefore abandon the 
fork in favor in the official distribution.

Sylvain
PS: cc'ing pmc@ for archival and dev@ to keep the community informed
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Dynamic bookmars and portal's BookmarkAction

[Ralph Goers]

Sylvain Wallez wrote:
Hi all,
We had an interesting bug today: we use the portal's BookmarkAction 
with a "cocoon:" source, as bookmarks are the aggregation of a 
constant bookmark file and a project-specific one (this is a reuseable 
portal infrastructure + per-project customization).

The "cocoon:" source maps to a pipeline in a child sitemap of the one 
where the action is declared, and the result is that we enter an 
infinite loop, because the "cocoon:" is loaded within the action's 
parameterize() method when the sitemap is being built, and that again 
triggers the loading of the sitemap (a new instance since the previous 
one isn't yet active), which creates an instance of the action, calls 
its parameterize() method, etc, etc.

Now the funny thing is that it *used to work* in 2.1.5.1 release, but 
no more in a recent update of the 2.1.x branch. And although I 
understand what happens now, I have hard times understanding why it 
did work before.

Any hint on this?
A way to solve this could be to defer loading of the bookmark source 
until the first call to act(), but we potentially then hit the problem 
of relative sources whose resolving dependends on the current sitemap, 
and not the place where the action is declared.

So the workaround I finally found is to add a "lazy-load" boolean 
parameter to the bookmark action which, if true, defers loading until 
the first call to act(). That way, the moment where loading occurs is 
under the developper's responsibility. Seems hacky but that's the only 
solution I found so far.

Any idea on a better solution?
Sylvain
I don't know if it will solve your problem, but you might look at the 
PageLabel stuff I added as an alternative to bookmarks.

Ralph

DO NOT REPLY [Bug 32208] - [PATCH] lucene block contribution : a AnalyzerManager component

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32208

[PATCH] lucene block contribution : a AnalyzerManager component





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 18:57 ---
Created an attachment (id=13419)
the source + build.xml + a sample configuration

DO NOT REPLY [Bug 32208] New: - [PATCH] lucene block contribution : a AnalyzerManager component

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32208

[PATCH] lucene block contribution : a AnalyzerManager component

   Summary: [PATCH] lucene block contribution : a AnalyzerManager
component
   Product: Cocoon 2
   Version: 2.1.5
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


i was frusted with the LuceneIndexTransformer because i can use custom analyzer
because the constructor needed parameters.
So i developped a analyzerManager.
The goal of the analyzerManager is to

1 - register all the necessary analyzers. Two main methods: 
public   void register(key,analyzer);
public   analyzer get(key);
(in a hacked version of LuceneIndexTransformer, in the xml input format you can
replace analyzer="myclass" by analyzer="mykey" and access to all the analyzers
you want)

you can configure all the necessary analyzers in the cocoon.xconf

2 - allow to configure with a custom xml file a analyzer that need to be
configured to work (PerFieldAnalyzer for multilingue document or a custom
stopwordanalayzer).=> allow multiple analyzers of the same class but with
different configurations   
(see ConfigurableAnalyzer class)



with build.xml to deploy to a cocoon webapp
see analyzer_manager tag in the cocoon.xconf after the deployment

Nicolas Maisonneuve

Re: svn commit: rev 57536 - in cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples: . flow forms resources

[Sylvain Wallez]

Carsten Ziegeler wrote:
Ehm, should this go into the release as well?
 

Well, this is a new sample that illustrates some of the new CForms 
features that were written before the code freeze.

So if the release is done from a fresh checkout, and not rev 57527, 
let's include them! Otherwise, that's not that important ;-)

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

Re: Learning from XForms

[Sylvain Wallez]

Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:


After this experience and especially after Sylvain's letter, there 
seem to have been a feeling in the community that XForms is not 
relevant for Cocoon.

Let me correct this: in the now famous "XMLForms vs Woody" post, the 
conclusion wasn't that XForms was not relevant for Cocoon, but that 
the XForm event model was IMO too rich to be implemented in a simple 
and efficient manner by a server-side implementation. 

Do you talk about the event model there? Anyway after your post 
whether it was influential or not, (I would say it was), there have 
been a concensus on the list among "key players" that XForms not is 
suited for server side implementation (search the archive for XForms). 
I don't know, but I am interested in Micah's opinion about it. The 
Chiba guys think it is suitable for server side implementation and 
maybe even prove it (http://chiba.sourceforge.net/features.html).

Woody on the contrary was less ambitious, but had good foundations 
for a server-side form framework. It later evolved into the CForms we 
have today, which does have an event model which, although simple, 
fits many complex needs as it runs server side. 

Sure, I think it was the best choice back then. What I'm discussing 
now is how to evolve our form processing so that we both keep back 
compatibillity and makes it an open framework where we can plug in new 
modules.


Another thing is having a request processor that writes into the 
widget tree instead of letting the widgets read from the request. 
This makes it possible to plug in an XML based request processor 
instead of the request parameters based, e.g.

The danger here is to fall again in the XMLForm trap, where all 
request parameters where checked to see if they corresponded to some 
valid XPath expression.

As long as one uses a separate form model, this danger can be avoided 
by either letting the business model (or a binding framw work) pull 
data from the form model, or by having a schema that restrict what can 
be added to the form model.

One can also use the mechanism that Jonas Ekstedt and also Reinhard 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2) 
have proposed. One register all used widgets during form rendering and 
then only read from registred widgets during request processing. With 
this solution one is safe even without using a form model.

Note also that most widgets only call getParameter() on the request, 
and that we could easily cut that dependency by passing e.g. a Map 
implementation wrapping the request. That's what JSF does to abstract 
the request between servlet and portlet, as they have no abstraction 
of the environment as Cocoon does. 

Might be a possiblity, the important thing is getting better separation.
In my view it is possible to break up the rather heavy widget 
interface in more focused concern areas, and especially to give a 
more focused model-view interface, without breaking back compabillity.

Could you elaborate on this?

Yes, my main interested ATM is give a better model-view separation in 
the framework. Taking a look at e.g. your helper class for the JX 
macro implementation, a subset of the interaface is used for rendering 
the widget hierarchy. That part of the inteface could be factored out 
to a separate interface.

Do you mean the widget tree crawling methods?
In 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2, 
I discuss what would be needed in a "populate" interface.

As I mentioned previously, either abstracting the request parameters 
through a Map could be a way to achieve this.

We could also add a setValue(String), but that may not be enough, as 
some widgets do more than reading a single value. For example, an action 
checks its own parameter (e.g. "ok"), but also parameters corresponding 
to an image button (i.e. "ok.x").

Furthermore, traversing the tree in order is important, as some 
containers prepare a context for their children. This is for example the 
case of repeater (creating rows if "repeater-id.size" is present) or 
aggregate-field that splits its request parameter and feeds its children.

And also that convertion/rendering IMO should be done in a separate 
component.

I agree with this. CForms convertors should be usable not only in CForms.
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

RE: svn commit: rev 57536 - in cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples: . flow forms resources

[Carsten Ziegeler]

Ehm, should this go into the release as well?

Carsten 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 12, 2004 7:34 PM
> To: [EMAIL PROTECTED]
> Subject: svn commit: rev 57536 - in 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples: . flow 
> forms resources
> 
> Author: sylvain
> Date: Fri Nov 12 10:33:30 2004
> New Revision: 57536
> 
> Added:
>
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_binding.xml   (contents, props changed)
>
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_model.xml   (contents, props changed)
>
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_template.xml   (contents, props changed)
> Modified:
>
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/flow/for
> ms_flow_example.js
>
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/resource
> s/forms-lib.js
>cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/welcome.xml
> Log:
> adding multipage wizard sample
> 
> Modified: 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/flow/for
> ms_flow_example.js
> ==
> 
> --- 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/flow/for
> ms_flow_example.js(original)
> +++ 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/flow/for
> ms_flow_example.jsFri Nov 12 10:33:30 2004
> @@ -121,3 +121,22 @@
>  );
>  }
>  
> +// import WidgetState for direct access in event handlers.
> +// FIXME(SW) would be better to import it implicitely within 
> Forms.js 
> +importClass(org.apache.cocoon.forms.formmodel.WidgetState);
> +
> +function do_multipage() {
> +var form = new Form("forms/multipage_model.xml");
> +form.showForm("multipage-display-pipeline.jx");
> +
> +var doc = 
> Packages.javax.xml.parsers.DocumentBuilderFactory.newInstance(
> ).newDocumentBuilder().newDocument();
> +doc.appendChild(doc.createElement("result"));
> +form.createBinding("forms/multipage_binding.xml");
> +form.save(doc);
> +
> +cocoon.sendPage("xmlresult-display-pipeline.jx",
> +{title: "Here's the resulting document", document: doc}
> +);
> +}
> +
> +
> 
> Added: 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_binding.xml
> ==
> 
> --- (empty file)
> +++ 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_binding.xml   Fri Nov 12 10:33:30 2004
> @@ -0,0 +1,46 @@
> +
> +
> +
> +
> +
> +http://apache.org/cocoon/forms/1.0#binding";
> +xmlns:fd="http://apache.org/cocoon/forms/1.0#definition";
> +path="result">
> +  
> +  
> +
> +
> +
> + style="short"/>
> +
> +  
> +  
> +  
> +
> +
> +
> +  
> +  
> +  
> +
> + row-path="drink"/>  
> + 
> +  
> +
> 
> Added: 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_model.xml
> ==
> 
> --- (empty file)
> +++ 
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/mu
> ltipage_model.xml Fri Nov 12 10:33:30 2004
> @@ -0,0 +1,221 @@
> +
> +
> +
> +
> +
> +http://apache.org/cocoon/forms/1.0#definition";
> + xmlns:i18n="http://apache.org/cocoon/i18n/2.1";>
> +
> +  
> +
> +
> +  
> +
> +  
> +  
> +  
> +
> +  
> +  Enter an email address:
> +  
> +An email address must be in 
> [EMAIL PROTECTED] format.
> +
> +And if you do not know what email address 
> is, then well, chances are
> +that you do not have it. However, if you have 
> access to the Internet,
> +you can easily get yourself one!
> +
> +Choose one of the following options:
> +
> +  Yahoo! 
> Mail
> +  Hotmail
> +
> +Anyway, the point of all this was to show 
> a popup help with mixed html content.
> +  
> +
> +  
> + 
> +   Select something that's 4 characters 
> long:
> +   
> +   
> + 
> +   
> +   
> + 
> +  
> + 
> +   Your birthdate (dd/MM/):
> +   
> + 
> +   
> + dd/MM/
> + 
> +   
> + 
> +   
> +   
> + 
> +   Dead and not born yet should 
> not bother filling this form
> + 
> +   
> + 
> +   
> + 
> +   Next
> +   
> + 
> +   var parent = event.source.parent;
> +   if (parent.validate()) {
> +   parent.se

Re: Learning from XForms

[Sylvain Wallez]

Sylvain Wallez wrote:
Sorry to rain on the party, but the new widget state stuff in CForms 
should make building multi-page forms a piece of cake.

Off writing an example

Done, I wrote my first wizard with CForms :-)
Please update branch 2.1.x and point your browser to 
http://localhost:/forms-samples/do-multipage.flow

Enjoy!
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Learning from XForms

[Sylvain Wallez]

Daniel Fagerstrom wrote:
Torsten Curdt wrote:

Exactly! For a secure system we need to keep the indirect population
approach. Although I had some continuation related RT on this...
What actually is suspected to be populated on the next request
is available through the result of the last continuation!
Given this technique an automated and still secure population
mechanism could be put in place.
...but since I not yet got into the CForms codebase I am
not sure how CForms could benefit from this idea.

Have you seen Jonas proposal 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 ? I currently 
working on combining that with the "old" back button continuation 
stuff from JXForm 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106684461526770&w=2)  
and actually have a working prototype. It took quite some while to 
make the continuations work in the way I wanted. Excpect some code and 
an RT in the near future :)

Sorry to rain on the party, but the new widget state stuff in CForms 
should make building multi-page forms a piece of cake.

Off writing an example
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Learning from XForms

[Daniel Fagerstrom]

Torsten Curdt wrote:

Exactly! For a secure system we need to keep the indirect population
approach. Although I had some continuation related RT on this...
What actually is suspected to be populated on the next request
is available through the result of the last continuation!
Given this technique an automated and still secure population
mechanism could be put in place.
...but since I not yet got into the CForms codebase I am
not sure how CForms could benefit from this idea.
Have you seen Jonas proposal 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32169 ? I currently 
working on combining that with the "old" back button continuation stuff 
from JXForm 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106684461526770&w=2)  
and actually have a working prototype. It took quite some while to make 
the continuations work in the way I wanted. Excpect some code and an RT 
in the near future :)

/Daniwl

Re: Learning from XForms

[Daniel Fagerstrom]

Sylvain Wallez wrote:
Daniel Fagerstrom wrote:

After this experience and especially after Sylvain's letter, there 
seem to have been a feeling in the community that XForms is not 
relevant for Cocoon.
Let me correct this: in the now famous "XMLForms vs Woody" post, the 
conclusion wasn't that XForms was not relevant for Cocoon, but that 
the XForm event model was IMO too rich to be implemented in a simple 
and efficient manner by a server-side implementation. 
Do you talk about the event model there? Anyway after your post whether 
it was influential or not, (I would say it was), there have been a 
concensus on the list among "key players" that XForms not is suited for 
server side implementation (search the archive for XForms). I don't 
know, but I am interested in Micah's opinion about it. The Chiba guys 
think it is suitable for server side implementation and maybe even prove 
it (http://chiba.sourceforge.net/features.html).

Woody on the contrary was less ambitious, but had good foundations for 
a server-side form framework. It later evolved into the CForms we have 
today, which does have an event model which, although simple, fits 
many complex needs as it runs server side. 
Sure, I think it was the best choice back then. What I'm discussing now 
is how to evolve our form processing so that we both keep back 
compatibillity and makes it an open framework where we can plug in new 
modules.


Another thing is having a request processor that writes into the 
widget tree instead of letting the widgets read from the request. 
This makes it possible to plug in an XML based request processor 
instead of the request parameters based, e.g.
The danger here is to fall again in the XMLForm trap, where all 
request parameters where checked to see if they corresponded to some 
valid XPath expression.
As long as one uses a separate form model, this danger can be avoided by 
either letting the business model (or a binding framw work) pull data 
from the form model, or by having a schema that restrict what can be 
added to the form model.

One can also use the mechanism that Jonas Ekstedt and also Reinhard 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106672364131946&w=2) 
have proposed. One register all used widgets during form rendering and 
then only read from registred widgets during request processing. With 
this solution one is safe even without using a form model.

Note also that most widgets only call getParameter() on the request, 
and that we could easily cut that dependency by passing e.g. a Map 
implementation wrapping the request. That's what JSF does to abstract 
the request between servlet and portlet, as they have no abstraction 
of the environment as Cocoon does. 
Might be a possiblity, the important thing is getting better separation.
In my view it is possible to break up the rather heavy widget 
interface in more focused concern areas, and especially to give a 
more focused model-view interface, without breaking back compabillity.
Could you elaborate on this?
Yes, my main interested ATM is give a better model-view separation in 
the framework. Taking a look at e.g. your helper class for the JX macro 
implementation, a subset of the interaface is used for rendering the 
widget hierarchy. That part of the inteface could be factored out to a 
separate interface. In 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109960841308357&w=2, I 
discuss what would be needed in a "populate" interface. And also that 
convertion/rendering IMO should be done in a separate component. These 
are examples of more focused concern areas. By splitting the widget 
interface in a number of sub interfaces it would be easier to replace 
one of the components with something else.


/Daniel

RE: [IMP] Code freeze

[Carsten Ziegeler]

Antonio Gallardo wrote: 
> 
> Carsten Ziegeler dijo:
> > The test-candidate can be accessed here:
> >
> > http://cvs.apache.org/~cziegeler/cocoon-rc/
> >
> > Please use this download only if you want to test the release 
> > candidate as it is build from current SVN using "build dist".
> >
> > IT IS NOT AN OFFICIAL RELEASE!!!
> 
> Can you post the SVN revision #? ;-)
> 
Sure: 57527

Carsten

RE: Dynamic bookmars and portal's BookmarkAction

[Carsten Ziegeler]

Sylvain Wallez wrote:
> 
> Yep. Could this be that the initialization strategy of 
> ThreadSafe components has changed in ECM inbetween? Was it 
> lazy before and immediate now?
> 
Ah, hmm, we haven't changed ECM and ThreadSafe components were instatiated
immediate before. Perhaps we initialized our sitemap manager in 
a lazy way?

> Any comment of the workaround I wrote, is this something acceptable?
> 
Sorry, forget about it: yes I think it's acceptable.

Carsten

Re: Dynamic bookmars and portal's BookmarkAction

[Sylvain Wallez]

Carsten Ziegeler wrote:
Sylvain Wallez  wrote:
 

We had an interesting bug today: we use the portal's 
BookmarkAction with a "cocoon:" source, as bookmarks are the 
aggregation of a constant bookmark file and a 
project-specific one (this is a reuseable portal 
infrastructure + per-project customization).

The "cocoon:" source maps to a pipeline in a child sitemap of 
the one where the action is declared, and the result is that 
we enter an infinite loop, because the "cocoon:" is loaded 
within the action's
parameterize() method when the sitemap is being built, and 
that again triggers the loading of the sitemap (a new 
instance since the previous one isn't yet active), which 
creates an instance of the action, calls its parameterize() 
method, etc, etc.

Now the funny thing is that it *used to work* in 2.1.5.1 
release, but no more in a recent update of the 2.1.x branch. 
And although I understand what happens now, I have hard times 
understanding why it did work before.

Any hint on this?
   

Hmm, is it related to this?
  
Refactor TreeProcessor to avoid constant reloading of sitemap if its
modification date is in the future and occasional ECM-related
exceptions
when a sitemap is reloaded.
  
 

I thought about this also, but even in 2.1.5 the Processor only had a 
root processing node once the sitemap was fully initialized, including 
its component manager.

I'm really wondering myself why it worked before. Strange..
 

Yep. Could this be that the initialization strategy of ThreadSafe 
components has changed in ECM inbetween? Was it lazy before and 
immediate now?

Any comment of the workaround I wrote, is this something acceptable?
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

RE: [IMP] Code freeze

[Antonio Gallardo]

Carsten Ziegeler dijo:
> The test-candidate can be accessed here:
>
> http://cvs.apache.org/~cziegeler/cocoon-rc/
>
> Please use this download only if you want to test the release
> candidate as it is build from current SVN using "build dist".
>
> IT IS NOT AN OFFICIAL RELEASE!!!

Can you post the SVN revision #? ;-)

Best Regards,

Antonio Gallardo
>
> Carsten
>
> Carsten Ziegeler wrote:
>>
>> Code freeze starts NOW  !
>>
>> Carsten
>>
>> > -Original Message-
>> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
>> > Sent: Friday, November 12, 2004 1:49 PM
>> > To: Cocoon-Dev
>> > Subject: [IMP] Code freeze
>> >
>> > starts at 15:00 cet (which is 70 minutes from now).
>> >
>> > Of course this freezes just the 2.1.x branch; Bug fixes etc.
>> > can still be applied.
>> >
>> > Carsten
>> >
>> > Carsten Ziegeler
>> > Open Source Group, S&N AG
>> > http://www.s-und-n.de
>> > http://www.osoco.net/weblogs/rael/
>> >
>> >
>>
>>
>

RE: [IMP] Code freeze

[Carsten Ziegeler]

The test-candidate can be accessed here:

http://cvs.apache.org/~cziegeler/cocoon-rc/

Please use this download only if you want to test the release
candidate as it is build from current SVN using "build dist".

IT IS NOT AN OFFICIAL RELEASE!!!

Carsten

Carsten Ziegeler wrote: 
> 
> Code freeze starts NOW  !
> 
> Carsten
> 
> > -Original Message-
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> > Sent: Friday, November 12, 2004 1:49 PM
> > To: Cocoon-Dev
> > Subject: [IMP] Code freeze
> > 
> > starts at 15:00 cet (which is 70 minutes from now).
> > 
> > Of course this freezes just the 2.1.x branch; Bug fixes etc.
> > can still be applied.
> > 
> > Carsten
> > 
> > Carsten Ziegeler
> > Open Source Group, S&N AG
> > http://www.s-und-n.de
> > http://www.osoco.net/weblogs/rael/
> > 
> > 
> 
> 

RE: [IMP] Code freeze

[Carsten Ziegeler]

The test-candidate can be accessed here:


Carsten Ziegeler wrote: 
> 
> Code freeze starts NOW  !
> 
> Carsten
> 
> > -Original Message-
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> > Sent: Friday, November 12, 2004 1:49 PM
> > To: Cocoon-Dev
> > Subject: [IMP] Code freeze
> > 
> > starts at 15:00 cet (which is 70 minutes from now).
> > 
> > Of course this freezes just the 2.1.x branch; Bug fixes etc.
> > can still be applied.
> > 
> > Carsten
> > 
> > Carsten Ziegeler
> > Open Source Group, S&N AG
> > http://www.s-und-n.de
> > http://www.osoco.net/weblogs/rael/
> > 
> > 
> 
> 

RE: Dynamic bookmars and portal's BookmarkAction

[Carsten Ziegeler]

Sylvain Wallez  wrote:
> 
> We had an interesting bug today: we use the portal's 
> BookmarkAction with a "cocoon:" source, as bookmarks are the 
> aggregation of a constant bookmark file and a 
> project-specific one (this is a reuseable portal 
> infrastructure + per-project customization).
> 
> The "cocoon:" source maps to a pipeline in a child sitemap of 
> the one where the action is declared, and the result is that 
> we enter an infinite loop, because the "cocoon:" is loaded 
> within the action's
> parameterize() method when the sitemap is being built, and 
> that again triggers the loading of the sitemap (a new 
> instance since the previous one isn't yet active), which 
> creates an instance of the action, calls its parameterize() 
> method, etc, etc.
> 
> Now the funny thing is that it *used to work* in 2.1.5.1 
> release, but no more in a recent update of the 2.1.x branch. 
> And although I understand what happens now, I have hard times 
> understanding why it did work before.
> 
> Any hint on this?
> 
Hmm, is it related to this?

   
 Refactor TreeProcessor to avoid constant reloading of sitemap if its
 modification date is in the future and occasional ECM-related
exceptions
 when a sitemap is reloaded.
   

I'm really wondering myself why it worked before. Strange..

Carsten

Dynamic bookmars and portal's BookmarkAction

[Sylvain Wallez]

Hi all,
We had an interesting bug today: we use the portal's BookmarkAction with 
a "cocoon:" source, as bookmarks are the aggregation of a constant 
bookmark file and a project-specific one (this is a reuseable portal 
infrastructure + per-project customization).

The "cocoon:" source maps to a pipeline in a child sitemap of the one 
where the action is declared, and the result is that we enter an 
infinite loop, because the "cocoon:" is loaded within the action's 
parameterize() method when the sitemap is being built, and that again 
triggers the loading of the sitemap (a new instance since the previous 
one isn't yet active), which creates an instance of the action, calls 
its parameterize() method, etc, etc.

Now the funny thing is that it *used to work* in 2.1.5.1 release, but no 
more in a recent update of the 2.1.x branch. And although I understand 
what happens now, I have hard times understanding why it did work before.

Any hint on this?
A way to solve this could be to defer loading of the bookmark source 
until the first call to act(), but we potentially then hit the problem 
of relative sources whose resolving dependends on the current sitemap, 
and not the place where the action is declared.

So the workaround I finally found is to add a "lazy-load" boolean 
parameter to the bookmark action which, if true, defers loading until 
the first call to act(). That way, the moment where loading occurs is 
under the developper's responsibility. Seems hacky but that's the only 
solution I found so far.

Any idea on a better solution?
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: svn commit: rev 57516 - cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel

[Tim Larson]

On Fri, Nov 12, 2004 at 01:35:27PM -, [EMAIL PROTECTED] wrote:
> Author: sylvain
> Date: Fri Nov 12 05:35:27 2004
> New Revision: 57516
> 
> Modified:
>
> cocoon/branches/BRANCH_2_1_X/src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Field.java
> Log:
> Optimize lazy parsing of value. Tim, I think we finally got it :-)

Thanks :)

--Tim Larson

Re: svn commit: rev 57484 - cocoon/branches/BRANCH_2_1_X/lib

[Giacomo Pati]

On Fri, 12 Nov 2004, Joerg Heinicke wrote:
On 12.11.2004 02:56, [EMAIL PROTECTED] wrote:
Author: vgritsenko
Date: Thu Nov 11 17:56:24 2004
New Revision: 57484
Modified:
  cocoon/branches/BRANCH_2_1_X/lib/jars.xml
Log:
event is gone
vs.
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110016446216689&w=4
Is event impl needed or not?
It's definitely gone. The axis block has been corrected today (couldn't 
find the commit mail anymore)

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

RE: [IMP] Code freeze

[Carsten Ziegeler]

Code freeze starts NOW  !

Carsten

> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 12, 2004 1:49 PM
> To: Cocoon-Dev
> Subject: [IMP] Code freeze
> 
> starts at 15:00 cet (which is 70 minutes from now).
> 
> Of course this freezes just the 2.1.x branch; Bug fixes etc.
> can still be applied.
> 
> Carsten 
> 
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.net/weblogs/rael/
> 
> 

Re: Cocoon-2.1.X Tests Failure 11/12/04

[Giacomo Pati]

On Fri, 12 Nov 2004, Vadim Gritsenko wrote:
Automated Cocoon Unit tests failed!
Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20041112.log
Ok, thread package tests look good now.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

RE: svn commit: rev 57484 - cocoon/branches/BRANCH_2_1_X/lib

[Carsten Ziegeler]

It's not needed anymore - someone removed the sample from Axis.

Carsten 

> -Original Message-
> From: Joerg Heinicke [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 12, 2004 2:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: svn commit: rev 57484 - cocoon/branches/BRANCH_2_1_X/lib
> 
> On 12.11.2004 02:56, [EMAIL PROTECTED] wrote:
> 
> > Author: vgritsenko
> > Date: Thu Nov 11 17:56:24 2004
> > New Revision: 57484
> > 
> > Modified:
> >cocoon/branches/BRANCH_2_1_X/lib/jars.xml
> > Log:
> > event is gone
> 
> vs.
> 
> http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110016446216689&w=4
> 
> Is event impl needed or not?
> 
> Joerg
> 

Re: svn commit: rev 57484 - cocoon/branches/BRANCH_2_1_X/lib

[Joerg Heinicke]

On 12.11.2004 02:56, [EMAIL PROTECTED] wrote:
Author: vgritsenko
Date: Thu Nov 11 17:56:24 2004
New Revision: 57484
Modified:
   cocoon/branches/BRANCH_2_1_X/lib/jars.xml
Log:
event is gone
vs.
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=110016446216689&w=4
Is event impl needed or not?
Joerg

Cocoon-2.1.X Tests Failure 11/12/04

[Vadim Gritsenko]

Automated Cocoon Unit tests failed!

Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20041112.log

Last messages from the log file:
==
  [foreach] reader-mime-type.xml:39: Starting 
http://localhost:1///samples/test/reader-mime-type/test20.html
  [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = 
text/html ... done (1ms)
  [foreach] reader-mime-type.xml:39: Finished 
http://localhost:1///samples/test/reader-mime-type/test20.html (53ms)
  [foreach] reader-mime-type.xml:44: Starting 
http://localhost:1///samples/test/reader-mime-type/test20.html
  [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:44: Finished 
http://localhost:1///samples/test/reader-mime-type/test20.html (28ms)
  [foreach] reader-mime-type.xml:50: Starting 
http://localhost:1///samples/test/reader-mime-type/test30.html
  [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = 
text/html ... done (1ms)
  [foreach] reader-mime-type.xml:50: Finished 
http://localhost:1///samples/test/reader-mime-type/test30.html (389ms)
  [foreach] reader-mime-type.xml:55: Starting 
http://localhost:1///samples/test/reader-mime-type/test30.html
  [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:55: Finished 
http://localhost:1///samples/test/reader-mime-type/test30.html (83ms)
  [foreach] reader-mime-type.xml:61: Starting 
http://localhost:1///samples/test/reader-mime-type/test40.html
  [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:61: Finished 
http://localhost:1///samples/test/reader-mime-type/test40.html (29ms)
  [foreach] reader-mime-type.xml:66: Starting 
http://localhost:1///samples/test/reader-mime-type/test40.html
  [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = 
text/html ... done (0ms)
  [foreach] reader-mime-type.xml:66: Finished 
http://localhost:1///samples/test/reader-mime-type/test40.html (25ms)
  [foreach] reader-mime-type.xml:72: Starting 
http://localhost:1///samples/test/reader-mime-type/test50.html
  [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = 
text/html  Failure: 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.6-dev/test/anteater/reader-mime-type.xml:74:
  message doesn't match because header 'content-type' is not present
  [foreach] ... done (8ms)
  [foreach] reader-mime-type.xml:72: Finished 
http://localhost:1///samples/test/reader-mime-type/test50.html (45ms)
BUILD FAILED
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.6-dev/test/anteater/reader-mime-type.xml:72:
 Task at 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.6-dev/test/anteater/reader-mime-type.xml:72:
  failed
Total time: 24 seconds

Last messages from the server console:
==
[EMAIL PROTECTED]: Startup sequence initiated from main() method
[EMAIL PROTECTED]: Loaded properties from 
[/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties]
[EMAIL PROTECTED]: Initiating startup sequence...
[EMAIL PROTECTED]: Server socket opened successfully in 4 ms.
[EMAIL PROTECTED]: Database [index=0, id=0, 
db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb,
 alias=] opened sucessfully in 1331 ms.
[EMAIL PROTECTED]: Startup sequence completed in 1388 ms.
[EMAIL PROTECTED]: 2004-11-12 05:44:53.321 HSQLDB server 1.7.2 is online
[EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL
[EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly
- The database 'db' root directory has been set to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind 
that if a war upgrade will take place the database will be lost.
- Database points to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db
- [main] '/db/system/SysSymbols' Set object system_SysConfig
- [main] '/db/system/SysConfig' Set document database.xml
- [main] '/db/system/SysSymbols' Set object meta_Metas
- [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig
- Database 'db' successfully opened
- Xindice server successfully started
parameter = @PARAMETER@  replaceme = replaceme-abc
parameter = @PARAMETER@  replaceme = replaceme-123
- VM shutting down with the disk store for cocoon-ehcache-1 still active. The 
disk store is persistent. Calling dispose...
- Database 'db' successfully closed
- Scheduler Cocoon_$_Fri_Nov_12_05:44:50_PST_2004 paused.
- Scheduler Cocoon_$_Fri_Nov_12_05:4

DO NOT REPLY [Bug 32199] - Error-uri double instatiations in the new portal.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32199

Error-uri double instatiations in the new portal.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 13:28 ---
This is fixed in the latest SVN - please check if it works for you and then 
close the bug. Thanks!!

Re: [IMP] Outstanding issues for 2.1.6?

[Vadim Gritsenko]

Giacomo Pati wrote:
On Fri, 12 Nov 2004, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Are there any outstanding issues that *really* have to be done before
the 2.1.6 release?

Fixing the failing test would be nice.

Already done so for the thread package (hopefully). They run without 
problems on my side. Maybe someone else could test as well.
Ok, I kicked it off manually... Mail should come in 1/2 hour or so when test run 
is complete (nagoya has slooow filesystem, or something)

Vadim

DO NOT REPLY [Bug 32199] - Error-uri double instatiations in the new portal.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32199

Error-uri double instatiations in the new portal.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

Re: [IMP] Outstanding issues for 2.1.6?

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Which one is failing?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110025247606363
http://nagoya.apache.org/~vadim/cocoon-test-log-20041112.log
Running org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase
Tests run: 11, Failures: 10, Errors: 0, Time elapsed: 0.99 sec
Testsuite: org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase
Tests run: 11, Failures: 10, Errors: 0, Time elapsed: 0.99 sec
Testcase: testConfigureDaemonPool took 0.477 sec
FAILED
And when this fixed, there is one anteater test failing:
Failure: 
file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.6-dev/test/anteater/reader-mime-type.xml:74: 
 message doesn't match because header 'content-type' is not present

Test page is at
  http://localhost:1///samples/test/reader-mime-type/test50.html
Vadim

Re: [IMP] Outstanding issues for 2.1.6?

[Giacomo Pati]

On Fri, 12 Nov 2004, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Are there any outstanding issues that *really* have to be done before
the 2.1.6 release?
Fixing the failing test would be nice.
Already done so for the thread package (hopefully). They run without 
problems on my side. Maybe someone else could test as well.

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

RE: [IMP] Outstanding issues for 2.1.6?

[Carsten Ziegeler]

Which one is failing?

Carsten 

> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 12, 2004 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [IMP] Outstanding issues for 2.1.6?
> 
> Carsten Ziegeler wrote:
> > Are there any outstanding issues that *really* have to be 
> done before 
> > the 2.1.6 release?
> 
> Fixing the failing test would be nice.
> 
> Vadim
> 

[IMP] Code freeze

[Carsten Ziegeler]

starts at 15:00 cet (which is 70 minutes from now).

Of course this freezes just the 2.1.x branch; Bug fixes etc.
can still be applied.

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.net/weblogs/rael/

Re: [IMP] Outstanding issues for 2.1.6?

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Are there any outstanding issues that *really* have to be done before
the 2.1.6 release?
Fixing the failing test would be nice.
Vadim

DO NOT REPLY [Bug 32199] New: - Error-uri double instatiations in the new portal.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32199

Error-uri double instatiations in the new portal.

   Summary: Error-uri double instatiations in the new portal.
   Product: Cocoon 2
   Version: 2.1.5
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi! 

I've found a bug in the new portal. 
If a coplet has an error, the error should be handled by the pipeline defined 
in the attribute  tag 'error-uri', that was set in the copletdata/portal.xml 
file.

Actually this happens, but the problem is that this happens twice. if the 
coplet has an error, the content ('error-uri' pipeline), is instantiated two 
times.

Thanks in advance.
Hugo.

RE: [IMP] Outstanding issues for 2.1.6?

[Antonio Gallardo]

Carsten Ziegeler dijo:
>
> Antonio Gallardo wrote:
>>
>> One big problem was:
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=31760
>>
>> But seems to be solved.
>>
>> OK. How many hours we have? I want to see other small things: ;-)
>>
> I wanted to announce the code freeze in two hours - so this means
> after that you still can add fixes and doc updates etc.
> Is that ok?

Yep! I want to install Fedora 3 before starting. I already downloaded and
burned the CD's. ;-)

Best Regards,

Antonio Gallardo

RE: [IMP] Outstanding issues for 2.1.6?

[Carsten Ziegeler]

 
Antonio Gallardo wrote:
> 
> One big problem was:
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=31760
> 
> But seems to be solved.
> 
> OK. How many hours we have? I want to see other small things: ;-)
> 
I wanted to announce the code freeze in two hours - so this means
after that you still can add fixes and doc updates etc.
Is that ok?

Carsten

Re: svn commit: rev 57381 - cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms

[Sylvain Wallez]

[EMAIL PROTECTED] wrote:
Author: tim
Date: Wed Nov 10 13:43:30 2004
New Revision: 57381
Modified:
  
cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/datasource_chooser_binding.xml
Log:
sync with trunk: Fix incomplete binding that prevents saving the file name 
(finally I found it Sylvain, file and filename is not the same, fine and 
filename is not the same ;-)
Modified: 
cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/datasource_chooser_binding.xml
==
--- 
cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/datasource_chooser_binding.xml
  (original)
+++ 
cocoon/branches/BRANCH_2_1_X/src/blocks/forms/samples/forms/datasource_chooser_binding.xml
  Wed Nov 10 13:43:30 2004
@@ -37,7 +37,9 @@
  


-  
+  
+
+  

  

 

Thanks for investigating this :-)
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [IMP] Outstanding issues for 2.1.6?

[Antonio Gallardo]

Carsten Ziegeler dijo:
> Are there any outstanding issues that *really* have to be done before
> the 2.1.6 release?
>
> I just tested the current SVN (57502) and it seems to run on JDK 1.3
> as well.
>
> If there are no issues I will make the dist for this version available
> for testing and start the code freeze in some hours.

One big problem was:

http://issues.apache.org/bugzilla/show_bug.cgi?id=31760

But seems to be solved.

OK. How many hours we have? I want to see other small things: ;-)

Best Regards,

Antonio Gallardo

Re: [IMP] Outstanding issues for 2.1.6?

[Ralph Goers]

Ralph Goers wrote:
I cannot seem to get a JSR-168 portlet to work when it is installed as 
a separate webapp.  There was a message in the user list 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=110001301923383&w=2 
which is similar to the problem I am having, except I don't install 
Pluto.The process I followed was:
1. Take a raw JSR-168 portlet (RssPortlet - one of the samples that is 
downloadable from somewhere).
2. Create a valid web.xml
3. Create a cocoon.xml file with crossContext="true" specified (for 
Tomcat).
(At this point if you try to invoke the portlet an error occurs when 
Pluto's PortletServlet init method is called saying the prepare method 
was never called.)
4. Move the pluto and portlet-api jars to shared/lib (to resolve the 
above).
Now the error occurs with the Quartz Scheduler saying a Scheduler 
named "Cocoon" already exists.

Never mind, I guess.  I see in the log that I am getting a ClassNotFound 
exception on a Pluto class so my cocoon servlet init is failing. I guess 
in that case the scheduler is left running.

Ralph

Re: [IMP] Outstanding issues for 2.1.6?

[Ralph Goers]

Carsten Ziegeler wrote:
Are there any outstanding issues that *really* have to be done before
the 2.1.6 release?
I just tested the current SVN (57502) and it seems to run on JDK 1.3
as well.
If there are no issues I will make the dist for this version available
for testing and start the code freeze in some hours.
Carsten
 

I cannot seem to get a JSR-168 portlet to work when it is installed as a 
separate webapp.  There was a message in the user list 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=110001301923383&w=2 
which is similar to the problem I am having, except I don't install 
Pluto.The process I followed was:
1. Take a raw JSR-168 portlet (RssPortlet - one of the samples that is 
downloadable from somewhere).
2. Create a valid web.xml
3. Create a cocoon.xml file with crossContext="true" specified (for Tomcat).
(At this point if you try to invoke the portlet an error occurs when 
Pluto's PortletServlet init method is called saying the prepare method 
was never called.)
4. Move the pluto and portlet-api jars to shared/lib (to resolve the above).
Now the error occurs with the Quartz Scheduler saying a Scheduler named 
"Cocoon" already exists.

Cocoon-2.1.X Tests Failure 11/12/04

[Vadim Gritsenko]

Automated Cocoon Unit tests failed!

Full log file if this unit test run is available here:
http://nagoya.apache.org/~vadim/cocoon-test-log-20041112.log

Last messages from the log file:
==
Testcase: testSimple took 4.897 sec
Testcase: testCatch took 0.003 sec
Testcase: testFormFlow took 0.734 sec
Testcase: testAbstract took 0.002 sec
Testcase: testDelegate took 0.879 sec
Running org.apache.cocoon.components.flow.java.test.InheritanceFlowTest
Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.615 sec
Testsuite: org.apache.cocoon.components.flow.java.test.InheritanceFlowTest
Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.615 sec
- Standard Output ---
suspending
continuing
suspending
continuing
suspending
continuing
-  ---
Testcase: testSimpleContinuable took 1.091 sec
Testcase: testWrapperContinuable took 0.16 sec
Testcase: testExtendedContinuable took 0.082 sec

junit-tests-report:
Created dir: 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.6-dev/test/report
Transform time: 48227ms
Unit report is at build/cocoon-2.1.6-dev/test/report/index.html

Last messages from the server console:
==
[EMAIL PROTECTED]: [Thread[Thread-3,5,main]]: checkRunning(false) entered
[EMAIL PROTECTED]: [Thread[Thread-3,5,main]]: checkRunning(false) exited
[EMAIL PROTECTED]: Startup sequence initiated from main() method
[EMAIL PROTECTED]: Loaded properties from 
[/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties]
[EMAIL PROTECTED]: Initiating startup sequence...
[EMAIL PROTECTED]: Server socket opened successfully in 3 ms.
[EMAIL PROTECTED]: Database [index=0, id=0, 
db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb,
 alias=] opened sucessfully in 1380 ms.
[EMAIL PROTECTED]: Startup sequence completed in 1435 ms.
[EMAIL PROTECTED]: 2004-11-12 01:28:43.832 HSQLDB server 1.7.2 is online
[EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL
[EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly
- The database 'db' root directory has been set to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind 
that if a war upgrade will take place the database will be lost.
- Database points to 
/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db
- [main] '/db/system/SysSymbols' Set object system_SysConfig
- [main] '/db/system/SysConfig' Set document database.xml
- [main] '/db/system/SysSymbols' Set object meta_Metas
- [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig
- Database 'db' successfully opened
- Xindice server successfully started
- VM shutting down with the disk store for cocoon-ehcache-1 still active. The 
disk store is persistent. Calling dispose...
- Database 'db' successfully closed
- Scheduler Cocoon_$_Fri_Nov_12_01:28:41_PST_2004 paused.
- Scheduler Cocoon_$_Fri_Nov_12_01:28:41_PST_2004 shutting down.
- Scheduler Cocoon_$_Fri_Nov_12_01:28:41_PST_2004 paused.
- Scheduler Cocoon_$_Fri_Nov_12_01:28:41_PST_2004 shutdown complete.

DO NOT REPLY [Bug 31760] - Handle / Semaphore Leak?

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31760

Handle / Semaphore Leak?





--- Additional Comments From [EMAIL PROTECTED]  2004-11-12 08:07 ---
cocoon 2.1.6 svn rev 57433 / tomcat 5.0.28 /sun jdk1.4.2_06 on Win NT
server vm, args -Xms64m -Xmx256m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

results after 15h uptime:
RAM 110m, 1480 handles

identical configuration with 2.1.5 uses a minimum of 1 handles. Migration
from Excalibur Event to RunnableManager fixes this bug IMO.
thanks!