DO NOT REPLY [Bug 26186] - Memory Leak caused by cocoon:// protocol

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

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

Memory Leak caused by cocoon:// protocol





--- Additional Comments From [EMAIL PROTECTED]  2004-01-17 13:28 ---
ooh, moved too fast - been way too busy lately, neurons tend to collide when you
stir them too hard at my age ;-)


DO NOT REPLY [Bug 26219] New: - AbstractDOMTransformer dropping data

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

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

AbstractDOMTransformer dropping data

   Summary: AbstractDOMTransformer dropping data
   Product: Cocoon 2
   Version: 2.1.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The AbstractDOMTransformer (ADT) has a bug in the way it handles SAX events. If 
it receives multiple calls to characters() between calls to startElement() and 
endElement(), the DOM Node that it produces only has the data from the first 
call to characters(), and the data from the rest of the calls to characters() 
is lost.

One way to duplicate this problem is to set up an XSLT transform that outputs a 
single tag whose value is generated by multiple xsl:value-of tags. This causes 
the condition of multiple calls to characters(), and the problem ensues if you 
use the ADT downstream of the xslt transformer. The problem also occurs if you 
use the session transformer in a similar way, ie. output a single tag whose 
value is generated by multiple session:getxml tags.

This bug is being entered pursuant to the threads 'Losing XML data in the 
pipeline' and 'Bug in Transformer?' from the Cocoon Users List in January 2004.


RE: JXTemplateGenerator / JX macro bug

2004-01-17 Thread Oguz Kologlu
Chris,

thanks for the info. I need to do some presentation logic 
hence the JXTemplateGenerator.

eg: jx:if test=${..}etc../jx:if

I've put the wi:styling stuff on the backburner for the moment.
Were you planning on expanding on the macros any time soon?


Oz


-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Sent: Friday, 16 January 2004 5:58 PM
To: [EMAIL PROTECTED]
Subject: Re: JXTemplateGenerator / JX macro bug


Yes, you're right. There are some special hacks in 
WoodyTemplateTransformer to insert the styling element inside the 
expansion of the widget element. Although possible, it would be ugly to 
recreate these hacks in a macro. Probably what I would do if I were 
planning to fix this is to not use widget.generateSAXFragment() at all, 
and replace its behavior with equivalent jx macro code.

Why can't you use WoodyTemplateTransformer?

Regards,

Chris

Oguz Kologlu wrote:

Hi all,

I'm using the latest 2.1 JXTemplateGenerator (cvs tag 1.30) and the JX Macros 
Christopher Oliver orignally wrote.

There appears to be a problem with widgets that contains styling information
when the jxtemplategenerator processes them.

eg:
wt:widget id=notes
  wi:styling type=textarea rows=4 style=width:100%/
/wt:widget

Will be processed as:

wi:field id=notes required=false/
wi:styling type=textarea rows=4 style=width:100%/

(NOTE: two seperate elements..)

It would appear that:

  widget.generateSaxFragment(cocoon.consumer, locale)

in the macro is not outputing the wi:styling .. until
after it has finished processing wt:widget ... which then
results in the field being output as:

input name=notes

instead of the required:
texterea name=notes

Is there some workaround to this?

Thanks,
Oz


See full macro below:
jx:macro name=widget \
targetNamespace=http://apache.org/cocoon/woody/template/1.0;  jx:parameter \
name=id/  jx:set var=widget value=${woodyCurrent.getWidget(id)}/
  jx:choose
jx:when test=${widget.getSize() != null} !-- repeater --
   jx:set var=lastRow value=${widget.getSize() - 1}/
   jx:forEach varStatus=loop begin=0 end=${lastRow}
   jx:set var=woodyCurrent value=${widget.getRow(loop.index)}/
   ${row.generateSaxFragment(cocoon.consumer, locale)}
   jx:evalBody/
   /jx:forEach
 /jx:when
 jx:otherwise
   ${widget.generateSaxFragment(cocoon.consumer, locale)}
   jx:evalBody/
 /jx:otherwise
  /jx:choose
/jx:macro