date:20040119

Guys,

I've tried to follow this discussion as much as I can. I thought it might
help to introduce a "real world" example.

Working on a medical application I'm running into HL7 V3 and CEN/TC251 13606
which are going to be the new standard definitions for storing and
exchanging medical data. If this is totally unfamiliar to you, it doesn't
matter. What they have is a list of specialized datatypes, one of them is
called GTS which is a TimeStamp kind of datatype. It can store a date or a
time range in various ways:
- a single point in time
- a range with start and end time
- a range with a point and a "radius" before and after.

If I remember correctly there are more variations, but I'll have to look
them up to be certain.

If this datatype had to be entered through Woody I suppose a struct would be
needed to keep range information together and a union would be needed to
allow for all the variations.

Would this be a helpful example?

Bye, Helma

> -Original Message-
> From: Marc Portier [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 09 January 2004 12:17
> To: [EMAIL PROTECTED]
> Subject: Re: [cforms] Forwarding: Explanation of "dynamic 
> stuff in form model"
> 
> 
> Tim Larson wrote:
> 
> > --- Marc Portier <[EMAIL PROTECTED]> wrote:
> > 
> >>Tim Larson wrote:
> >>
> >>>--- Marc Portier <[EMAIL PROTECTED]> wrote:
> >>>
> 1/ to me this sounds like the use of @id on new and class 
> was fraudulous:
> what I mean is: it is abusing that field in the 
> implementation classes, 
> but with utterly different semantics:  not to be mapped 
> onto actual 
> request-parameter-names, but rather a type-def/type-ref mechanism
> >>>
> >>>This is all true, except for the small detail that the class id is
> >>>currently occupying space in the same namespace as the 
> regular widget
> >>
> >>which seems to be more of a consequence of current approach 
> then a goal, no?
> > 
> > 
> > I think so; see "red flag" comment below.
> > 
> > 
> >>>We also need to be able to distinguish between 
> just-create-prototype
> >>>versus create-widgets-and-create-prototype-at-the-same-time.
> >>
> >>see my other posting... distinguishing is done by looking at the 
> >>combination of present attributes
> >>
> >>   --> classic use, create widget
> >> --> prototype-only (ie 
> equivalent of wrapping with wd:class )
> >> --> create and prototype
> >>
> >>so one of @type-def or @id always would need to be present
> >>@id would say: give this a place in the active tree of nodes
> >>@type-def would say: add this to the active registry of 
> reusable prototypes
> > 
> > 
> > This separation of widget and prototype namespaces seems good.
> > Instead of letting any widget act as a prototype, only the ones
> > marked with a type-def attribute are available as prototypes.
> > This provides a red flag to anyone modifying the widget, alerting
> > them that their changes may affect other parts of the form.
> > 
> 
> indeed, didn't even think about that extra bonus
> 
> > 
> >>>In addition, how would you handle a class containing two 
> or more widgets?
> >>>For this case I think we still need a wrapping element 
> without namespacing.
> >>>Example with current (possibly soon to be old) syntax:
> >>>  
> >>>
> >>>
> >>>  
> >>>  
> >>>which should be functionally equivalent to:
> >>>  
> >>>  
> >>>
> >>touche, but let's cheat by changing the rules of the game:
> >>I don't like this feature, and I don't think you need it :-)
> > 
> > 
> > I will describe below how to support the feature cheaply, and
> > further down, the reasons why it is needed.
> > 
> > 
> >>Here is why I don't like it
> >>suppose this:
> >>
> >>  
> >>  
> >>
> >>
> >>then using this:
> >>
> >>
> >>
> >>
> >>would lead to a conflict, right?
> >>if we like to extend the re-use paradigm to central catalogs, then 
> >>having this feature would expect me to know the internals 
> of the 'asdf' 
> >>class to make sure this doesn't happen, right?
> > 
> > 
> > Quoting myself:
> > 
> >>>Not good.  When reusing, currently with "new", you should 
> not need to
> >>>know or restate what type(s) of widget(s) the class 
> contains.  I.e. we
> > 
> > 
> > I am going to relax this statement from "should not need to know or
> > restate" to just "should not need to restate", because if 
> you write a
> > custom template or binding for an instance of a prototype (currently
> > called a "class"), then you already need to know the types 
> and ids of
> > the widgets the prototype contains.  Just like "type-def" 
> acts as a red
> > flag, informing the form designer to be careful when a 
> widget is acting
> > as a prototype, a special element (currently "new", but 
> could be "inline",
> > etc.) could be required to create an instance of one of 
> these multi-widget
> > prototypes which add their widget ids to the current namespace.
> > 
> > This way there is never a question about when id clashes 
> are possible,
> > following the pattern of only h

Cookie wrapper for continuation handling

2004-01-19 Thread Hunsberger, Peter

To follow up with an old post about handling continuation ids as request
parameters and how that could cause caching problems:

I wrote a quick set of changes to add the continuation id as a cookie in
the setup method of one of my generators as follows:

WebContinuation m_kont = FlowHelper.getWebContinuation(
objectModel );
if ( m_kont != null )
{
String id = m_kont.getContinuation(0).getId();
if ( id != null )
{
Response response = (Response)objectModel.get(
ObjectModelHelper.RESPONSE_OBJECT );
Cookie cookie = response.createCookie(
CONTINUATION_ID, id );
cookie.setMaxAge( -1 ); // Save in
memory only
cookie.setPath( "/" );
cookie.setVersion( 0 );
response.addCookie( cookie );
response.addHeader( "expires", "0" );
objectModel.put(
ObjectModelHelper.RESPONSE_OBJECT, response );
}
}

I then wrote a CookieValueModule as an input module to get the value of
a cookie:

public class CookieValueModule extends AbstractInputModule implements
ThreadSafe {

public Object getAttribute( String name, Configuration modeConf, Map
objectModel ) throws ConfigurationException {

String pname = (String) this.settings.get("parameter", name);
if ( modeConf != null ) {
pname = modeConf.getAttribute( "parameter", pname );
// preferred
pname = modeConf.getChild("parameter").getValue(pname);
}
Map cookies =
ObjectModelHelper.getRequest(objectModel).getCookieMap();
Cookie cookie = (Cookie)cookies.get( pname );
if ( cookie != null )
{
return cookie.getValue( );
}
return null;
}

public Iterator getAttributeNames( Configuration modeConf, Map
objectModel ) throws ConfigurationException {
Map cookies =
ObjectModelHelper.getRequest(objectModel).getCookieMap();
if ( cookies != null )
return cookies.keySet().iterator();
return null;
}

public Object[] getAttributeValues( String name, Configuration
modeConf, Map objectModel )
throws ConfigurationException {

Map cookies =
ObjectModelHelper.getRequest(objectModel).getCookieMap();
String pname = (String) this.settings.get("parameter", name);
Cookie cookie = (Cookie)cookies.get( pname );
if ( cookie != null )
{
Vector ret = new Vector();
ret.add( cookie.getValue( ) );
return ret.toArray();
}
return null;
}
}

I added this module to my Cocoon.xconf (with the name "cookie-value")
and then in the sitemap I can do:

   






  
  




 
This removes the need to manage continuation ids completely from any of
the XSLTs.

I think that it might make sense for Cocoon to do this automatically in
the setup method of the AbstractGenerator?  (I think a cookie can only
be added once? If not, we'd need a way to only add it once...)
Certainly a generic CookieValue Module might help.  In any case, if
anyone needs this and can't figure it out from the above let me know.

Peter Hunsberger

RE: Please help - NullPointerException in flowscript that worked in 2 .1.3

Hi,


> I were also on the search for a NPE today. The reason was a missing 
> widget in the definition for the id in combination with a 
> repeater. What 
> does the stacktrace say?

org.apache.avalon.framework.CascadingRuntimeException:
"resource://org/apache/cocoon/woody/flow/javascript/woody2.js", line 193:
uncaught JavaScript exception: 
at protect
(file:/D:/jakarta-tomcat-4.1.29/webapps/ROOT/properweb/system/scripts/login.
js, Line 20)
at success
(file:/D:/jakarta-tomcat-4.1.29/webapps/ROOT/properweb/system/scripts/login.
js, Line 53):
org.apache.avalon.framework.CascadingRuntimeException:
"resource://org/apache/cocoon/woody/flow/javascript/woody2.js", line 193:
uncaught JavaScript exception: 
at woody (resource://org/apache/cocoon/woody/flow/javascript/woody2.js, Line
213)
at prot_editPatient
(file:/D:/jakarta-tomcat-4.1.29/webapps/ROOT/properweb/system/scripts/flowsc
ripts.js, Line 70)
at  (resource://org/apache/cocoon/woody/flow/javascript/woody2.js, Line
193):
java.lang.NullPointerException 
at
org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.c
allFunction(FOM_JavaScriptInterpreter.java:706) 
at
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(C
allFunctionNode.java:160) 
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:84) 
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:165) 
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:108) 
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:162) 


I must say I don't have anything fancy like repeaters and such. Merely a
list of string fields, a date field and a radiobutton field.

Line 70 in flowscripts.js = form.load(document)

Login.js is copied/modified from the "authentication with flow" example

Line 20 in login.js = success()
Line 53 in login.js = cocoon.sendPage(internal);


Thanks for helping.

Bye, Helma

Re: Flow or actions?

On 19.01.2004 22:16, Reinhard Poetz wrote:

PS: It's Monday and we still don't know what's up!


http://www.betaversion.org/~stefano/linotype/news/36/
Wow, [EMAIL PROTECTED] Congratulations.

Joerg

Re: Please help - NullPointerException in flowscript that worked in 2 .1.3

On 19.01.2004 23:30, [EMAIL PROTECTED] wrote:

Hi,

I need some Woody features that are only available in 2.1.4 so I'm migrating
from 2.1.3 to 2.1.4. Under 2.1.3 my flowscript.js (a modified copy of the
form2_xml_bind example) worked, but failed due to a missing element in my
data.xml file (for which I need "lenient").
The same script generates a NPE under 2.1.4 when trying to load the same
data.xml file. More specifically: line 193 in woody2.js.
I've compared the 2.1.4 form2 example with my version, but I cannot find
anything different (other than different tags). The example runs, my stuff
doesn't. :-(
Any ideas as where I need look?
I were also on the search for a NPE today. The reason was a missing 
widget in the definition for the id in combination with a repeater. What 
does the stacktrace say?

Joerg

Please help - NullPointerException in flowscript that worked in 2 .1.3

Hi,

I need some Woody features that are only available in 2.1.4 so I'm migrating
from 2.1.3 to 2.1.4. Under 2.1.3 my flowscript.js (a modified copy of the
form2_xml_bind example) worked, but failed due to a missing element in my
data.xml file (for which I need "lenient").
The same script generates a NPE under 2.1.4 when trying to load the same
data.xml file. More specifically: line 193 in woody2.js.
I've compared the 2.1.4 form2 example with my version, but I cannot find
anything different (other than different tags). The example runs, my stuff
doesn't. :-(

Any ideas as where I need look?

Thanks and bye, Helma

RE: Flow or actions?

2004-01-19 Thread Reinhard Poetz


From: Joerg Heinicke

> 
> PS: It's Monday and we still don't know what's up!

http://www.betaversion.org/~stefano/linotype/news/36/

Congratulations and all the best Stefano!

Cheers,
Reinhard

Re: [Woody] observations, issues, questions, best practices

Joerg Heinicke wrote:

Hello,

at work I may convert a Struts application into a Woody one. I played 
around with the Woody samples and created a form handling prototype 
for my application. But I came across some problems and made some 
observations I want to point out here. On the other hand the 
architecture is not "fixed", especially the communication with the 
backend, so the handling of the business logic is not that perfect.

1. When the template contains a reference to a not defined widget, I 
get an exception: "EffectWoodyTemplateTransformer: Widget with id 
"addcontact" does not exist in the container."
What would be helpful in this error message is the mentioning of the 
file and the line number.

2. When a flow script function is not available (called via woody2.js, 
line 213) I only get a "CascadingRuntimeException: The undefined value 
has no properties." Isn't it possible to give a more exact explanation 
or at least to point to the expression that returns undefined?
You could change the code to this:

function woody(form_function, form_definition) {
   var form = new Form(cocoon.parameters["form-definition"]);
  
   var args = [form];

   // set the binding on the form if there's any
   var bindingURI = cocoon.parameters["bindingURI"];
   if (bindingURI != null)
   form.createBinding(bindingURI);
   var funName = cocoon.parameters["function"];
   var fun = this[funName];
   if (!fun) {
 throw "Function \""+funName +"\" is not defined";
   } else if (!(fun instanceof Function)) {
 throw "\""+funName +"\" is not a function";
   }
   fun.apply(this, args);
}

Re: JX and nodes with appostrophes

On 19.01.2004 21:36, Christopher Oliver wrote:

It appears that your DOM object contains multiple text nodes under 
the title element. How was it created? Can't you just use #{./title} 
or #{string(./title)}?
But even with mixed content text() should return all text nodes. And 
how is it related to the postrophes? Sounds weird and more like a bug.

I guess it is a bit weird. But with JXPath, the caller has to decide 
whether you want to treat the result of the evaluation as a single node 
(getPointer(), getNode()) or as a node set (iteratePointers(), 
iterate()). JXTemplate uses the former except in . However, by 
explicitly utilizing the string() function you can convert a node set to 
a string value within the expression itself to overcome the single node 
behavior.
Ah, I see, thanks for the info.

Joerg

Re: JX and nodes with appostrophes

Joerg Heinicke wrote:

On 16.01.2004 17:28, Christopher Oliver wrote:

It appears that your DOM object contains multiple text nodes under 
the title element. How was it created? Can't you just use #{./title} 
or #{string(./title)}?


But even with mixed content text() should return all text nodes. And 
how is it related to the postrophes? Sounds weird and more like a bug.

Joerg

I guess it is a bit weird. But with JXPath, the caller has to decide 
whether you want to treat the result of the evaluation as a single node 
(getPointer(), getNode()) or as a node set (iteratePointers(), 
iterate()). JXTemplate uses the former except in . However, by 
explicitly utilizing the string() function you can convert a node set to 
a string value within the expression itself to overcome the single node 
behavior.

Chris

Re: Flow or actions?

On 16.01.2004 11:07, Stefano Mazzocchi wrote:

BTW, what about my suggested FlowScriptSelector?
http://marc.theaimsgroup.com/?t=10686444852&r=1&w=2
The man on the whiteboard got stuck in the middle of a big thing that he 
will announce on monday, hopefully.

The answer of the men on the whiteboard was "no answer, so go right ahead".

Joerg, if you want to resort the discussion, I think it would be a good 
thing... I won't have time to deeply participate in the next few weeks, 
as you will understand on monday.
Yes, it would be interesting. I only do not see how these two different 
approaches can fit together - or as Peter said "this seems completely 
upside down". At that time I wanted to see the flow as simple 
replacement for the actions - with a return value and the selector 
instead of the actions.

Now I see the better separation with the flow and though I have my 
problems with the JavaScript (error messages etc.) I see the advantages 
of having the controller separated and the sitemap for pure pipeline 
selection.

Joerg

PS: It's Monday and we still don't know what's up!

Re: JX and nodes with appostrophes

On 16.01.2004 17:28, Christopher Oliver wrote:

It appears that your DOM object contains multiple text nodes under the 
title element. How was it created? 
Can't you just use #{./title} or #{string(./title)}?
But even with mixed content text() should return all text nodes. And how 
is it related to the postrophes? Sounds weird and more like a bug.

Joerg

Upayavira wrote:

I'm using jxtemplate with an entry like #{./title/text()}. When the 
text of the node includes an apostrophe, I need to use 
#{./title/text()}#{./title/text()[2]}#{./title/text()[3]} to get the 
full text.

Is this correct behaviour?

Regards, Upayavira

Re: [Woody] observations, issues, questions, best practices

On 19.01.2004 18:14, Marc Portier wrote:

I ended up switching easily by not passing the 
DOM directly into the binding, but rather the root-node.
I tried ownerDocument() and get following exception:

"uncaught JavaScript exception: TypeError: [#document: null] is not a 
function."
isn't the full name getOwnerDocument()?
*ouch* Ok, it was a bad day after a bad sleep last night - my 
concentration was not that good today. My information source is 
http://xulplanet.com/references/elemref/ref_Node.html as it's a good 
overview of the DOM - unfortunately they mix properties and methods. I 
have to use either ownerDocument or your getOwnerDocument(), but not my 
mixture of both.

After understanding my problem even the error message makes sense to a 
certain extent: it interprets ownerDocument as property and adds the 
function call after it => #document is not a function.

Can you understand that this is why I hate JavaScript? Tooo much 
automagic. If a function ownerDocument() does not exist, it should tell 
me it and not try something else.

This has nothing to do with the immediate steps of loading and saving 
the model
as also a document.getDocumentElement().ownerDocument() in 
loadDocument() (where
I expect document again) results in the exception above. How did you 
save the
document back, Marc? Or do you or anybody else know why 
ownerDocument() fails?
euh, as you can see in the binding samples I didn't :-)
I thought you have some secret code on your disk :)

Joerg

Re: Pipleline Execution Stack Trace (was Cocoon Stack Traces)

Vadim Gritsenko wrote:

Christopher Oliver wrote:

So I would propose something like the following:

1) Have the TreeProcessor pass the sitemap source location in 
setGenerator(), addTransformer(), and setSerializer() to the 
ProcessingPipeline.
2) In "Debug" mode instrument the PipelineProcessor to write the 
output of each stage to a temporary file and regenerate SAX events 
from the temporary file (with location information). The 
PipelineProcessor would catch any exception thrown by a pipeline 
component and generate a "Cocoon" stack trace that includes the 
source location of the temp file. The Cocoon error reporter could 
even display the source code (maybe in tab-panes or whatever) of the 
pipeline intermediate results together with the stack trace. 
Hypothetically the label or tooltip on the tab-pane would be 
something like:

C:\TEMP\Pipeline_1060734815693.xml (output of 
C:\cocoon\build\webapp\samples\sitemap.xmap::66:16)

where the sitemap location refers to a  or 
 instruction.

WDYT?


IIRC, profiler pipeline already does some of this, like it saves 
output of every stage. Me thinks this "debug" mode should be part of 
profiling pipeline.
I am aware of that from: 
http://marc.theaimsgroup.com/?t=10677658321&r=1&w=2

But profiling seems like a separate concern.

PS I don't like writing to a temp file part

Vadim


Why not (curious as to exact reason)?

The idea is that this is analagous to running a C compiler (which is 
also a pipeline, BTW) with "cc -i -s" to save the preprocessor and 
assembler output.

Chris

Re: [Woody] observations, issues, questions, best practices

2004-01-19 Thread Marc Portier



Joerg Heinicke wrote:
Joerg Heinicke  gmx.de> writes:


4. The switching of binding to XML or beans costs to much effort. 
Binding file, JXTemplate (for the result), flow script. Maybe I did 
something the wrong way, but the XML needs at least a root element, 
why this would be annoying for the bean. Some ideas for that?
hm, both are supported, but that doesn't necesarrily mean that 
swapping between both is that easy.

I encountered the same when doing the first of my binding-samples... 
I ended up switching easily by not passing the DOM directly into the 
binding, but rather the root-node.   Note: when binding to XML you 
need to pass in a DOM Node, not a DOM Document!
Sometimes it's soo simple. But could it be that it is a one-way ticket? 
nope works both ways for me, of course I write back to the same document 
I read fromm


Saving the "document" back does not work, because document is null.
howcome?
Good question. I simply used the woody2.js and the loadDocument() and 
saveDocument() from binding.js. Hmm, I will look again.


I investigated the problem a bit more and my first observations were wrong. Not
the document is null, but it's value. I guess that's ok, as toString() probably
returns the text nodes. So it look like "[data: null]" when  is the
document element.
The real problem now is to save this thing back to file. If I pass the document
element only to saveDocument() I get an empty file. If I pass the root node (the
one above document element - how is it correctly called in DOM?) I get the file
as expected. But it seems not to be possible to get from document element to
root node. I tried ownerDocument() and get following exception:
"uncaught JavaScript exception: TypeError: [#document: null] is not a function."

isn't the full name getOwnerDocument()?

This has nothing to do with the immediate steps of loading and saving the model
as also a document.getDocumentElement().ownerDocument() in loadDocument() (where
I expect document again) results in the exception above. How did you save the
document back, Marc? Or do you or anybody else know why ownerDocument() fails?
euh, as you can see in the binding samples I didn't :-)

Joerg

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Pipleline Execution Stack Trace (was Cocoon Stack Traces)

2004-01-19 Thread Vadim Gritsenko

Christopher Oliver wrote:

So I would propose something like the following:

1) Have the TreeProcessor pass the sitemap source location in 
setGenerator(), addTransformer(), and setSerializer() to the 
ProcessingPipeline.
2) In "Debug" mode instrument the PipelineProcessor to write the 
output of each stage to a temporary file and regenerate SAX events 
from the temporary file (with location information). The 
PipelineProcessor would catch any exception thrown by a pipeline 
component and generate a "Cocoon" stack trace that includes the source 
location of the temp file. The Cocoon error reporter could even 
display the source code (maybe in tab-panes or whatever) of the 
pipeline intermediate results together with the stack trace. 
Hypothetically the label or tooltip on the tab-pane would be something 
like:

C:\TEMP\Pipeline_1060734815693.xml (output of 
C:\cocoon\build\webapp\samples\sitemap.xmap::66:16)

where the sitemap location refers to a  or 
 instruction.

WDYT?


IIRC, profiler pipeline already does some of this, like it saves output 
of every stage. Me thinks this "debug" mode should be part of profiling 
pipeline.

PS I don't like writing to a temp file part

Vadim

Re: [CVS] - Flow broken?

OK, thanks.

Sylvain Wallez wrote:

Christopher Oliver wrote:

If you don't mind, can you explain how it fixes the problems reported 
by Unico and Antonio? What was happening before your fix and what 
will happen now when you have


Sorry, I'm quite busy and didn't took the time for the minimal 
explanations.

The important difference between internal and external requests is that:
- for external requests, Processor.process() is called, and the result 
is output to the environment's OutputStream as soon as we reach a 
 or 
- for internal requests (i.e. SitemapSource) Processor.buildPipeline() 
is called, and the Processor does nothing more than assemble the 
pipeline.

When a foward occurs (i.e. redirect to "cocoon:") within an internal 
request, we must build a pipeline for the new URI, and have the 
resulting pipeline be the result of the original call to 
Processor.buildPipeline().

To solve this problem, the redirector was setting a flag indicating a 
forward which was later checked at the end of the tree evaluation in 
TreeProcessor.process(). The bad side effect of this was that the new 
request was not processed as part of the call to redirector.redirect().

The change I made yesterday corrects this: the redirector now uses the 
same InvokeContext than the original call to 
Processor.processInternal, and this allows to return the correct 
Pipeline instance, since it is created and held by the invoke context.

The "attempt to process and incomplete pipeline" message occurs when a 
different pipeline instance is created when the forward is processed, 
which is what occurs if Interpreter.forwardTo() is implemented 
similarily to processTo().

Hope it was clear :-/

In short: never manually call Processor.process() to process a request 
if you want it to function properly when the request is internal. Use 
Redirector.redirect().

Sylvain

Re: [CVS] - Flow broken?

Sorry, my bad. Thanks for fixing. The System.err message occurs because 
FOM_Cocoon was not designed to be reentrant. I didn't consider the case 
of recursive calls to sendPage(), e.g. aggregation. I'll look into 
fixing this.

Unico Hommes wrote:

Christopher Oliver wrote:
 

I've reverted the change to the flow to support Sylvain's 
fix. Can you test this?

   

It's not working. I think sendpage is not resolving to the correct uri:

Doing a request to /samples/slide/content/ where the context prefix is
/samples/slide/ sendpage('screens/login.html') does resolve to
/samples/slide/screens/login.html but to
/samples/slide/content/screens/login.html
If I revert AbstractInterpreter to version 1.11 (the one before the
forwarTo change) it works OK. The only thing I am now still getting is a
"Request is null. Might be trying to invalidate an already invalidated
FOM_Cocoon instance." System.err message.
Unico

RE: help - error when starting Tomcat with Cocoon 2.1.4-dev

Aaarghh. Sorry for the noise.

Bye, Helma

> -Original Message-
> From: Upayavira [mailto:[EMAIL PROTECTED] 
> Sent: Monday, 19 January 2004 16:59
> To: [EMAIL PROTECTED]
> Subject: Re: help - error when starting Tomcat with Cocoon 2.1.4-dev
> 
> 
> It is trying to bind to a port that is already bound. If you look, 
> you'll see reference to HSQLDB. So, you've got two copies of Cocoon 
> running, the second can't bind HSQLDB to the port it wants to, as the 
> other has already claimed that port.
> 
> Only matters if you actually use HSQLDB.
> 
> Hope that helps.
> 
> Regards, Upayavira
> 
> [EMAIL PROTECTED] wrote:
> 
> >Hi,
> >
> >I've simply copied a freshly built Cocoon 2.1.4-dev webapp 
> into the Tomcat
> >webapps dir and every time I (re)start Tomcat I see the 
> following error:
> >
> >Jan 19, 2004 4:38:56 PM org.apache.jk.server.JkMain start
> >INFO: Jk running ID=0 time=0/16
> >config=D:\jakarta-tomcat-4.1.29\bin\..\conf\jk2.properties
> >
> >Server.run/init: java.net.BindException: Address already in 
> use: JVM_Bind
> >java.net.BindException: Address already in use: JVM_Bind
> >at java.net.PlainSocketImpl.socketBind(Native Method)
> >at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
> >at java.net.ServerSocket.bind(ServerSocket.java:318)
> >at java.net.ServerSocket.(ServerSocket.java:185)
> >at java.net.ServerSocket.(ServerSocket.java:97)
> >at org.hsqldb.Server.run(Unknown Source)
> >at org.hsqldb.Server.main(Unknown Source)
> >at
> >org.apache.cocoon.components.hsqldb.ServerImpl.run(ServerImpl
> .java:199)
> >at java.lang.Thread.run(Thread.java:536)
> >
> >
> >I haven't seen this before in 2.1.3 and both (2.1.3 and 
> 2.1.4-dev) use the
> >same Tomcat configuration.
> >
> >Any ideas?
> >
> >Bye,
> >
> >Helma van der Linden
> >Medical Informatics
> >University Maastricht
> >POBOX 616
> >6200 MD Maastricht
> >The Netherlands
> >[EMAIL PROTECTED] 
> >
> >  
> >
> 
>

Re: help - error when starting Tomcat with Cocoon 2.1.4-dev

It is trying to bind to a port that is already bound. If you look, 
you'll see reference to HSQLDB. So, you've got two copies of Cocoon 
running, the second can't bind HSQLDB to the port it wants to, as the 
other has already claimed that port.

Only matters if you actually use HSQLDB.

Hope that helps.

Regards, Upayavira

[EMAIL PROTECTED] wrote:

Hi,

I've simply copied a freshly built Cocoon 2.1.4-dev webapp into the Tomcat
webapps dir and every time I (re)start Tomcat I see the following error:
Jan 19, 2004 4:38:56 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/16
config=D:\jakarta-tomcat-4.1.29\bin\..\conf\jk2.properties
Server.run/init: java.net.BindException: Address already in use: JVM_Bind
java.net.BindException: Address already in use: JVM_Bind
   at java.net.PlainSocketImpl.socketBind(Native Method)
   at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
   at java.net.ServerSocket.bind(ServerSocket.java:318)
   at java.net.ServerSocket.(ServerSocket.java:185)
   at java.net.ServerSocket.(ServerSocket.java:97)
   at org.hsqldb.Server.run(Unknown Source)
   at org.hsqldb.Server.main(Unknown Source)
   at
org.apache.cocoon.components.hsqldb.ServerImpl.run(ServerImpl.java:199)
   at java.lang.Thread.run(Thread.java:536)
I haven't seen this before in 2.1.3 and both (2.1.3 and 2.1.4-dev) use the
same Tomcat configuration.
Any ideas?

Bye,

Helma van der Linden
Medical Informatics
University Maastricht
POBOX 616
6200 MD Maastricht
The Netherlands
[EMAIL PROTECTED]

Re: help - error when starting Tomcat with Cocoon 2.1.4-dev

[EMAIL PROTECTED] wrote:

Hi,

I've simply copied a freshly built Cocoon 2.1.4-dev webapp into the Tomcat
webapps dir and every time I (re)start Tomcat I see the following error:
Jan 19, 2004 4:38:56 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/16
config=D:\jakarta-tomcat-4.1.29\bin\..\conf\jk2.properties
Server.run/init: java.net.BindException: Address already in use: JVM_Bind
java.net.BindException: Address already in use: JVM_Bind
   at java.net.PlainSocketImpl.socketBind(Native Method)
   at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
   at java.net.ServerSocket.bind(ServerSocket.java:318)
   at java.net.ServerSocket.(ServerSocket.java:185)
   at java.net.ServerSocket.(ServerSocket.java:97)
   at org.hsqldb.Server.run(Unknown Source)
   at org.hsqldb.Server.main(Unknown Source)
   at
org.apache.cocoon.components.hsqldb.ServerImpl.run(ServerImpl.java:199)
   at java.lang.Thread.run(Thread.java:536)
I haven't seen this before in 2.1.3 and both (2.1.3 and 2.1.4-dev) use the
same Tomcat configuration.
Any ideas?
 

You have several contexts running Cocoon in the same Tomcat. This error 
is because several hsqldb servers (used for Cocoon samples) try to use 
the same TCP port.

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

help - error when starting Tomcat with Cocoon 2.1.4-dev

Hi,

I've simply copied a freshly built Cocoon 2.1.4-dev webapp into the Tomcat
webapps dir and every time I (re)start Tomcat I see the following error:

Jan 19, 2004 4:38:56 PM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/16
config=D:\jakarta-tomcat-4.1.29\bin\..\conf\jk2.properties

Server.run/init: java.net.BindException: Address already in use: JVM_Bind
java.net.BindException: Address already in use: JVM_Bind
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:331)
at java.net.ServerSocket.bind(ServerSocket.java:318)
at java.net.ServerSocket.(ServerSocket.java:185)
at java.net.ServerSocket.(ServerSocket.java:97)
at org.hsqldb.Server.run(Unknown Source)
at org.hsqldb.Server.main(Unknown Source)
at
org.apache.cocoon.components.hsqldb.ServerImpl.run(ServerImpl.java:199)
at java.lang.Thread.run(Thread.java:536)


I haven't seen this before in 2.1.3 and both (2.1.3 and 2.1.4-dev) use the
same Tomcat configuration.

Any ideas?

Bye,

Helma van der Linden
Medical Informatics
University Maastricht
POBOX 616
6200 MD Maastricht
The Netherlands
[EMAIL PROTECTED]

Re: CLI-style publishing from webapp

Hmmph. Oh well. Means I have to engage with the real issue.

In CocoonComponentManager.java, we have:

   public static void checkEnvironment(Logger logger)
   throws Exception {
   // TODO (CZ): This is only for testing - remove it later on
   final EnvironmentStack stack = 
(EnvironmentStack)environmentStack.get();
   if (stack != null && !stack.isEmpty() ) {
   logger.error("ENVIRONMENT STACK HAS NOT BEEN CLEANED 
PROPERLY");  
   throw new ProcessingException("Environment stack has not 
been cleaned up properly. "
 +"Please report this (if 
possible together with a test case) "
 +"to the Cocoon 
developers.");
   }
   }

This is where your error is happening. Now, I don't really know what 
this method is supposed to do, nor how to interpret the 'TODO'. Is the 
test needed? Presumably the environment stack actually should be empty. 
Anyone else able to help here? Carsten?

Regards, Upayavira

Patrick Hess wrote:

Upayavira wrote:

Scheduler = Quarz?? Already tried on friday to remove it from 
cocoon.xconf - without any luck.

I compiled another web application this morning excluding all 
samples, doc and all optional blocks. Still the same stuff::-(


All blocks are optional. Exclude all except the ones you actually use 
(which may be none).


With "optional" block I meant all blocks that I could exclude. So I 
created only a minimal webapp because this experiment does not require 
anything special yet.

You should exclude the 'cron' block, and 'build clean webapp' rather 
than editing cocoon.xconf. It'll be much cleaner.


I started from scratch and compiled with following .properties:

$ cat local.blocks.properties
exclude.block.authentication-fw=true
exclude.block.batik=true
exclude.block.bsf=true
exclude.block.chaperon=true
exclude.block.databases=true
exclude.block.fop=true
exclude.block.hsqldb=true
exclude.block.html=true
exclude.block.itext=true
exclude.block.jfor=true
exclude.block.jsp=true
exclude.block.jxforms=true
exclude.block.linkrewriter=true
exclude.block.lucene=true
exclude.block.naming=true
exclude.block.php=true
exclude.block.poi=true
exclude.block.portal-fw=true
exclude.block.profiler=true
exclude.block.python=true
exclude.block.session-fw=true
exclude.block.swf=true
exclude.block.velocity=true
exclude.block.web3=true
exclude.block.xmldb=true
exclude.block.apples=true
exclude.block.asciiart=true
exclude.block.axis=true
exclude.block.cron=true
exclude.block.deli=true
exclude.block.eventcache=true
exclude.block.jms=true
exclude.block.linotype=true
exclude.block.mail=true
exclude.block.midi=true
exclude.block.ojb=true
exclude.block.petstore=true
exclude.block.portal=true
exclude.block.precept=true
exclude.block.proxy=true
exclude.block.qdox=true
exclude.block.repository=true
exclude.block.scratchpad=true
exclude.block.slide=true
exclude.block.slop=true
exclude.block.stx=true
exclude.block.taglib=true
exclude.block.webdav=true
exclude.block.woody=true
exclude.block.xmlform=tru
$ cat local.build.properties

exclude.webapp.documentation=true
exclude.webapp.javadocs=true
exclude.webapp.idldocs=true
exclude.webapp.samples=true
#exclude.deprecated=true
exclude.javadocs=true
exclude.idldocs=true
#include.driver.oracle=true
#include.driver.postgre=true
#include.driver.odbc=true
#config.allow-reloads=true
#config.enable-uploads=true
compiler=modern
compiler.debug=on
compiler.optimize=on
compiler.deprecation=off
compiler.nowarn=on
Gruss,
  Patrick

Re: CLI-style publishing from webapp

2004-01-19 Thread Patrick Hess

Upayavira wrote:

Scheduler = Quarz?? Already tried on friday to remove it from 
cocoon.xconf - without any luck.

I compiled another web application this morning excluding all samples, 
doc and all optional blocks. Still the same stuff::-(
All blocks are optional. Exclude all except the ones you actually use 
(which may be none).
With "optional" block I meant all blocks that I could exclude. So I 
created only a minimal webapp because this experiment does not require 
anything special yet.

You should exclude the 'cron' block, and 'build clean webapp' rather 
than editing cocoon.xconf. It'll be much cleaner.
I started from scratch and compiled with following .properties:

$ cat local.blocks.properties
exclude.block.authentication-fw=true
exclude.block.batik=true
exclude.block.bsf=true
exclude.block.chaperon=true
exclude.block.databases=true
exclude.block.fop=true
exclude.block.hsqldb=true
exclude.block.html=true
exclude.block.itext=true
exclude.block.jfor=true
exclude.block.jsp=true
exclude.block.jxforms=true
exclude.block.linkrewriter=true
exclude.block.lucene=true
exclude.block.naming=true
exclude.block.php=true
exclude.block.poi=true
exclude.block.portal-fw=true
exclude.block.profiler=true
exclude.block.python=true
exclude.block.session-fw=true
exclude.block.swf=true
exclude.block.velocity=true
exclude.block.web3=true
exclude.block.xmldb=true
exclude.block.apples=true
exclude.block.asciiart=true
exclude.block.axis=true
exclude.block.cron=true
exclude.block.deli=true
exclude.block.eventcache=true
exclude.block.jms=true
exclude.block.linotype=true
exclude.block.mail=true
exclude.block.midi=true
exclude.block.ojb=true
exclude.block.petstore=true
exclude.block.portal=true
exclude.block.precept=true
exclude.block.proxy=true
exclude.block.qdox=true
exclude.block.repository=true
exclude.block.scratchpad=true
exclude.block.slide=true
exclude.block.slop=true
exclude.block.stx=true
exclude.block.taglib=true
exclude.block.webdav=true
exclude.block.woody=true
exclude.block.xmlform=tru
$ cat local.build.properties

exclude.webapp.documentation=true
exclude.webapp.javadocs=true
exclude.webapp.idldocs=true
exclude.webapp.samples=true
#exclude.deprecated=true
exclude.javadocs=true
exclude.idldocs=true
#include.driver.oracle=true
#include.driver.postgre=true
#include.driver.odbc=true
#config.allow-reloads=true
#config.enable-uploads=true
compiler=modern
compiler.debug=on
compiler.optimize=on
compiler.deprecation=off
compiler.nowarn=on
Gruss,
  Patrick

Re: CLI-style publishing from webapp

Patrick Hess wrote:

Upayavira wrote:

Looks to me like you've got a problem with the scheduler not being 
able to handle being run within in an outer and inner Cocoon. Try 
rebuilding your Cocoon without it.

If you need it, then maybe you should try having the inner cocoon use 
a different webapp that has been built without the scheduler.


Scheduler = Quarz?? Already tried on friday to remove it from 
cocoon.xconf - without any luck.

I compiled another web application this morning excluding all samples, 
doc and all optional blocks. Still the same stuff::-(
All blocks are optional. Exclude all except the ones you actually use 
(which may be none).

You should exclude the 'cron' block, and 'build clean webapp' rather 
than editing cocoon.xconf. It'll be much cleaner.

Try that and report back.

Regards, Upayavira


cocoon 2.1.3
Copyright (c) 1999-2003 Apache Software Foundation. All rights reserved.

Cannot find CatalogManager.properties
X [0] test/data2.htmlBROKEN: 
Environment stack has not been cleaned up properly. Please report this 
(if possible together with a test case) to the Cocoon developers.
X [0] test/data1.htmlBROKEN: 
Environment stack has not been cleaned up properly. Please report this 
(if possible together with a test case) to the Cocoon developers.
Total time: 0 minutes 2 seconds,  Site size: 0 Site pages: 0

So any new hints what I should try? :-)

RE: HELP - 2.1.4-dev cannot access internal pipelines!!!

Confirmed, works here too. Thanks.

Bye, Helma

> -Original Message-
> From: Antonio Gallardo [mailto:[EMAIL PROTECTED] 
> Sent: Monday, 19 January 2004 14:11
> To: [EMAIL PROTECTED]
> Subject: RE: HELP - 2.1.4-dev cannot access internal pipelines!!!
> 
> 
> Unico Hommes dijo:
> > I just checked in a fix that works for me. Can you try 
> updating and test
> > it?
> 
> Yep. It works now. Thanks! :-D
> 
> Best Regards,
> 
> Antonio Gallardo
>

Re: No memory leak because of Recyclable!

Carsten Ziegeler wrote:

Sylvain Wallez wrote:
 

I haven't followed all the discussion, but why is toString() used to
identify components?
   

I have asked the same question :) And didn't get any answer :(

 

Wouldn't it be better to use a Map keyed by the
identy of the object like java.util.IdentityHashMap()? That way, we
ensure there's no possible collision between two instances of the same
component, and also avoid any problem related to classes redefining
their own hashcode() and equals() methods.
   

Yupp. As we learn from Lars, using toString() is not secure!

So, we should change the use of the StaticBucketMap to a safer implementation and remove these toString() calls in Excalibur component.
 

Yep. What about a "IdentityStaticBucketMap" that would keep the reduced 
lock contention features of StaticBiucketMap?

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: HELP - 2.1.4-dev cannot access internal pipelines!!!

Antonio Gallardo wrote:

Unico Hommes dijo:
 

I just checked in a fix that works for me. Can you try updating and test it?
   

Yep. It works now. Thanks! :-D
 

Collaborative debugging at work. Thanks to all!

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: CLI-style publishing from webapp

2004-01-19 Thread Patrick Hess

Upayavira wrote:

Looks to me like you've got a problem with the scheduler not being able 
to handle being run within in an outer and inner Cocoon. Try rebuilding 
your Cocoon without it.

If you need it, then maybe you should try having the inner cocoon use a 
different webapp that has been built without the scheduler.
Scheduler = Quarz?? Already tried on friday to remove it from 
cocoon.xconf - without any luck.

I compiled another web application this morning excluding all samples, 
doc and all optional blocks. Still the same stuff:	:-(


cocoon 2.1.3
Copyright (c) 1999-2003 Apache Software Foundation. All rights reserved.

Cannot find CatalogManager.properties
X [0] test/data2.html	BROKEN: 
Environment stack has not been cleaned up properly. Please report this 
(if possible together with a test case) to the Cocoon developers.
X [0] test/data1.html	BROKEN: 
Environment stack has not been cleaned up properly. Please report this 
(if possible together with a test case) to the Cocoon developers.
Total time: 0 minutes 2 seconds,  Site size: 0 Site pages: 0

So any new hints what I should try? :-)
--
Patrick Hess

RE: No memory leak because of Recyclable!

2004-01-19 Thread Carsten Ziegeler

Sylvain Wallez wrote:
>
> I haven't followed all the discussion, but why is toString() used to
> identify components?
I have asked the same question :) And didn't get any answer :(

> Wouldn't it be better to use a Map keyed by the
> identy of the object like java.util.IdentityHashMap()? That way, we
> ensure there's no possible collision between two instances of the same
> component, and also avoid any problem related to classes redefining
> their own hashcode() and equals() methods.
>
Yupp. As we learn from Lars, using toString() is not secure!

So, we should change the use of the StaticBucketMap to a safer
implementation
and remove these toString() calls in Excalibur component.

Carsten

Re: No memory leak because of Recyclable!

Carsten Ziegeler wrote:

Volker Schmitt wrote:

Carsten Ziegeler wrote:

Lars Rottmann wrote:

Lars Rottmann wrote:
Replacing the BucketMap with another Map implementation solves the
problem of Cocoon failing at high load (where the ECM fails to look

a Selector, not the Selector looking up a handler). It does not cure
the warning message above.

Where do you replace the BucketMap with a Map? In the ECM?
Did you try to do this replacement in the

ExcaliburComponentSelector as

well?

I did replace every occurence of StaticBucketMap in the
Excalibur-Component
package with a Hashtable.

Ah, ok - so, it seems that the BucketMap has threading problems.

Replacing

it with a HashMap solved the problem in the ECM.
But replacing the BucketMap in the ECMSelector doesn't solve the other
problem, as you still get the message. So, there must be another problem

I know this is obvious, but I just wanted to restate it. I think we can
assume that the HashMap has no threading problems.
So, has anyone a clue? Can it be the toString() method on your operating
system? Hmm, I don't know.

Hm we don't have this effect on our machine and we have a lot of traffic.
The only difference in our ECM Implementation is, that I have changed
ExcaliburComponentSelector to use the component as the key and not
component.toString(). I changed this to use the same implementation the
ExcaliburComponentManager use. Yes ECM uses the component as key and ECS
use component.toString(). I wanted in our Implememtation to make sure that
ECS work if somebody implements the toString method.
I don't believe that this can be the problem, because then it can be no
difference between HashTable and StaticBucketMap.

But there is no difference between HashTable and StaticBucketMap in the ECS and as you replaced component.toString() with component and don't have problems, perhaps it is the problem.

Lars, can you try this and also replace every occurence of component.toString() with simply component in the ECS?

I haven't followed all the discussion, but why is toString() used to
identify components? Wouldn't it be better to use a Map keyed by the
identy of the object like java.util.IdentityHashMap()? That way, we
ensure there's no possible collision between two instances of the same
component, and also avoid any problem related to classes redefining
their own hashcode() and equals() methods.

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: REMINDER: javadocs errors in portlet and woody

2004-01-19 Thread Jorg Heymans

Now don't be shy here to provide a patch :-)

[EMAIL PROTECTED] wrote:
Hi,

just want to remind you of the fact that commandline building of 2.1.4-dev
generates a  lot of errors in the portlet and woody files. I know it's not
vital, but it would be helpful if they were solved one time or other.
Bye,

Helma van der Linden
Medical Informatics
University Maastricht
POBOX 616
6200 MD Maastricht
The Netherlands
[EMAIL PROTECTED]

REMINDER: javadocs errors in portlet and woody

Hi,

just want to remind you of the fact that commandline building of 2.1.4-dev
generates a  lot of errors in the portlet and woody files. I know it's not
vital, but it would be helpful if they were solved one time or other.

Bye,

Helma van der Linden
Medical Informatics
University Maastricht
POBOX 616
6200 MD Maastricht
The Netherlands
[EMAIL PROTECTED]

RE: HELP - 2.1.4-dev cannot access internal pipelines!!!

2004-01-19 Thread Antonio Gallardo

Unico Hommes dijo:
> I just checked in a fix that works for me. Can you try updating and test
> it?

Yep. It works now. Thanks! :-D

Best Regards,

Antonio Gallardo

AW: No memory leak because of Recyclable!

2004-01-19 Thread Rottmann, Lars

> Carsten Ziegeler wrote:
>>Volker Schmitt wrote:
>> Hm we don't have this effect on our machine and we have a lot of 
>> traffic. The only difference in our ECM Implementation is, that I have 
>> changed ExcaliburComponentSelector to use the component as the key and 
>> not component.toString(). I changed this to use the same 
>> implementation the ExcaliburComponentManager use. Yes ECM uses the 
>> component as key and ECS use component.toString(). I wanted in our 
>> Implememtation to make sure that ECS work if somebody implements the 
>> toString method. I don't believe that this can be the problem, because 
>> then it can be no difference between HashTable and StaticBucketMap.
>
>But there is no difference between HashTable and StaticBucketMap
>in the ECS and as you replaced component.toString() with component 
>and don't have problems, perhaps it is the problem.
>
>Lars, can you try this and also replace every occurence of
>component.toString() with simply component in the ECS?
>
>Carsten

Hi Carsten,

I tried your fix and apparently the warnings no longer show up in the log
file (at least not after 2M requests), even without increasing the number of
pooled CachingProcessingPipeline objects.

Lars

Vodafone Global Content Services Limited 
Registered Office:  Vodafone House, The Connection, Newbury, Berkshire  RG14 2FN

Registered in England No. 4064873 

This e-mail is for the addressee(s) only.  If you are not an addressee, you
must not distribute, disclose, copy, use or rely on this e-mail or its
contents, and you must immediately notify the sender and delete this e-mail
and all copies from your system.  Any unauthorised use may be unlawful.  The
information contained in this e-mail is confidential and may also be legally
privileged.

RE: HELP - 2.1.4-dev cannot access internal pipelines!!!

2004-01-19 Thread Unico Hommes

 

[EMAIL PROTECTED] wrote:
> 
> Hi,
> 
> I just did a checkout of cocoon 2.1.4-dev and did a full 
> build on the command line. After that I copied my webapp 
> (works on 2.1.3) into the build/webapp dir. After starting it 
> I got an error stating pipeline internal/login could not be found.
> Assuming I did something wrong I copied the entire 2.1.4-dev 
> into the Tomcat webapp dir, mimicking my 2.1.3 setup. Again 
> the above error. Just for testing I changed internal-only to 
> false and the page works. :-(
> 
> What did I do wrong or has something been broken in 2.1.4?
> 

I just checked in a fix that works for me. Can you try updating and test
it?

Unico

Re: HELP - 2.1.4-dev cannot access internal pipelines!!!

2004-01-19 Thread Antonio Gallardo

[EMAIL PROTECTED] dijo:
> Hi,
>
> I just did a checkout of cocoon 2.1.4-dev and did a full build on the
> command line. After that I copied my webapp (works on 2.1.3) into the
> build/webapp dir. After starting it I got an error stating pipeline
> internal/login could not be found.
> Assuming I did something wrong I copied the entire 2.1.4-dev into the
> Tomcat
> webapp dir, mimicking my 2.1.3 setup. Again the above error. Just for
> testing I changed internal-only to false and the page works. :-(
>
> What did I do wrong or has something been broken in 2.1.4?

Yep. the current CVS HEAD is broken. Don't try to fix your work!
As you stated internals pipelines does not work :(

The problem looks to be started at:

http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=107406238701588&w=2

Now it is a little better but still there is a bug we need to solve. I
asked Sylvain to see inside and try to solve the problem in the
treeprocessor.

Best Regards,

Antonio Gallardo

HELP - 2.1.4-dev cannot access internal pipelines!!!

Hi,

I just did a checkout of cocoon 2.1.4-dev and did a full build on the
command line. After that I copied my webapp (works on 2.1.3) into the
build/webapp dir. After starting it I got an error stating pipeline
internal/login could not be found.
Assuming I did something wrong I copied the entire 2.1.4-dev into the Tomcat
webapp dir, mimicking my 2.1.3 setup. Again the above error. Just for
testing I changed internal-only to false and the page works. :-(

What did I do wrong or has something been broken in 2.1.4?

Bye,

Helma van der Linden
Medical Informatics
University Maastricht
POBOX 616
6200 MD Maastricht
The Netherlands
[EMAIL PROTECTED]

Re: [CVS] - Flow broken?

2004-01-19 Thread Antonio Gallardo

Hi:

I updated from the CVS 5 minuts ago and the problem is still there.:-(

The authentication-fw using flow worked fine before the changes that Unico
pointed out, now it fails:

org.apache.cocoon.ResourceNotFoundException: No pipeline matched request:
entrada-form
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:167)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:139)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:373)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:314)
at org.apache.cocoon.Cocoon.process(Cocoon.java:656)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1112)

Best Regards,

Antonio Gallardo

Re: [Woody] observations, issues, questions, best practices

Joerg Heinicke  gmx.de> writes:

>  4. The switching of binding to XML or beans costs to much effort. 
>  Binding file, JXTemplate (for the result), flow script. Maybe I did 
>  something the wrong way, but the XML needs at least a root element, 
>  why this would be annoying for the bean. Some ideas for that?
> >>>
> >>> hm, both are supported, but that doesn't necesarrily mean that 
> >>> swapping between both is that easy.
> >>>
> >>> I encountered the same when doing the first of my binding-samples... 
> >>> I ended up switching easily by not passing the DOM directly into the 
> >>> binding, but rather the root-node.   Note: when binding to XML you 
> >>> need to pass in a DOM Node, not a DOM Document!
> >>
> >> Sometimes it's soo simple. But could it be that it is a one-way ticket? 
> > 
> > nope works both ways for me, of course I write back to the same document 
> > I read fromm
> > 
> >> Saving the "document" back does not work, because document is null.
> > 
> > howcome?
> 
> Good question. I simply used the woody2.js and the loadDocument() and 
> saveDocument() from binding.js. Hmm, I will look again.

I investigated the problem a bit more and my first observations were wrong. Not
the document is null, but it's value. I guess that's ok, as toString() probably
returns the text nodes. So it look like "[data: null]" when  is the
document element.

The real problem now is to save this thing back to file. If I pass the document
element only to saveDocument() I get an empty file. If I pass the root node (the
one above document element - how is it correctly called in DOM?) I get the file
as expected. But it seems not to be possible to get from document element to
root node. I tried ownerDocument() and get following exception:

"uncaught JavaScript exception: TypeError: [#document: null] is not a function."

This has nothing to do with the immediate steps of loading and saving the model
as also a document.getDocumentElement().ownerDocument() in loadDocument() (where
I expect document again) results in the exception above. How did you save the
document back, Marc? Or do you or anybody else know why ownerDocument() fails?

Joerg

RE: [CVS] - Flow broken?

2004-01-19 Thread Unico Hommes

Christopher Oliver wrote:
> 
> I've reverted the change to the flow to support Sylvain's 
> fix. Can you test this?
> 

It's not working. I think sendpage is not resolving to the correct uri:

Doing a request to /samples/slide/content/ where the context prefix is
/samples/slide/ sendpage('screens/login.html') does resolve to
/samples/slide/screens/login.html but to
/samples/slide/content/screens/login.html

If I revert AbstractInterpreter to version 1.11 (the one before the
forwarTo change) it works OK. The only thing I am now still getting is a
"Request is null. Might be trying to invalidate an already invalidated
FOM_Cocoon instance." System.err message.

Unico

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/environment ForwardRedirector.java

Christopher Oliver wrote:

This seems to have broken the build:

compile-core:
Copying 40 files to C:\cocoon5\build\cocoon-2.1.4-dev\classes
Copied 70 empty directories to 38 empty directories under 
C:\cocoon5\build\cocoo
n-2.1.4-dev\classes
Created dir: C:\cocoon5\build\cocoon-2.1.4-dev\mocks
Compiling 1 source file to C:\cocoon5\build\cocoon-2.1.4-dev\mocks
Compiling 559 source files to C:\cocoon5\build\cocoon-2.1.4-dev\classes
C:\cocoon5\src\java\org\apache\cocoon\environment\ForwardRedirector.java:138: 
ca
nnot resolve symbol
symbol  : variable COCOON_REDIRECT_ATTR
location: class org.apache.cocoon.components.treeprocessor.TreeProcessor
this.env.setAttribute(TreeProcessor.COCOON_REDIRECT_ATTR, uri);
   ^

Oops, fixed. Sorry.

Also wouldn't it make more sense to have ForwardRedirector define this 
constant rather than TreeProcessor so that ForwardRedirector need not 
have a dependency on TreeProcessor?


Actually, this constant is now totally useless. I removed it and changed 
ForwardRedirector to an abstract class, and TreeProcessor provides a 
concrete implementation.

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: [CVS] - Flow broken?

Christopher Oliver wrote:

If you don't mind, can you explain how it fixes the problems reported 
by Unico and Antonio? What was happening before your fix and what will 
happen now when you have


Sorry, I'm quite busy and didn't took the time for the minimal explanations.

The important difference between internal and external requests is that:
- for external requests, Processor.process() is called, and the result 
is output to the environment's OutputStream as soon as we reach a 
 or 
- for internal requests (i.e. SitemapSource) Processor.buildPipeline() 
is called, and the Processor does nothing more than assemble the pipeline.

When a foward occurs (i.e. redirect to "cocoon:") within an internal 
request, we must build a pipeline for the new URI, and have the 
resulting pipeline be the result of the original call to 
Processor.buildPipeline().

To solve this problem, the redirector was setting a flag indicating a 
forward which was later checked at the end of the tree evaluation in 
TreeProcessor.process(). The bad side effect of this was that the new 
request was not processed as part of the call to redirector.redirect().

The change I made yesterday corrects this: the redirector now uses the 
same InvokeContext than the original call to Processor.processInternal, 
and this allows to return the correct Pipeline instance, since it is 
created and held by the invoke context.

The "attempt to process and incomplete pipeline" message occurs when a 
different pipeline instance is created when the forward is processed, 
which is what occurs if Interpreter.forwardTo() is implemented 
similarily to processTo().

Hope it was clear :-/

In short: never manually call Processor.process() to process a request 
if you want it to function properly when the request is internal. Use 
Redirector.redirect().

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: Submitting form in onchange event

Found this one in unsent messages too...

Sylvain Wallez wrote:

Upayavira wrote:

Joerg Heinicke wrote:

On 15.01.2004 23:34, Upayavira wrote:

I'd like to have an on-change event actually submit the form, 
rather than just execute the  javascript code.

How can I do this?

Otherwise, the on-value-changed javascript doesn't have access to 
the local variables of the main flowscript, which I need to 
repopulate my form for redisplay. (I know I can get hold of the 
bizObject from the request attribute, but it all seems rather hard 
work to use it there. There's an elegance I'm missing).


You changed the woody stylesheet for the radio buttons, so you 
already came across @submit-on-change. Why not using the same for a 
field?


Because it goes back to the server, yes, but doesn't actually leave 
the showForm function, which is what I'm after.


Currently, the only widgets that can potentially automatically exit 
showForm are  widgets. "Potentially" since of course the 
form is redisplayed if validation is asked and fails.

The Form object has a endProcessing(boolean redisplayForm) method that 
could be use in the  to achieve this.

Sylvain (currently swamped)
event.source.parent.endProcessing(false) did the trick. And your email
came in literally seconds before I went to get on the Tube, when I'd be
wanting to use this. So your timing was absolutely perfect! Thanks!
Upayavira, also swamped, with a site to have live by Wednesday

Re: JX and nodes with appostrophes