Re: CForms slower with JXTemplateGenerator

[Leszek Gawron]

roy huang wrote:
> I can do it if current vote process is positive
There already is an ongoing vote.

-- 
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: CForms slower with JXTemplateGenerator

[roy huang]

I can do it if current vote process is positive

-- 
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65


Do we need a vote?

roy huang

Re: CForms slower with JXTemplateGenerator

[Leszek Gawron]

Jean-Baptiste Quenot wrote:

* Sylvain Wallez:



Leszek Gawron wrote:




roy huang wrote:




In  current 2.1.x  svn ,Forms  using JXTemplateGenerator  is
much slower than FormTransformer




For  2.1.x  it is  probably  true  because it  still  contains
unrefactored version of jxtg.




So what about adding the new Template block to 2.1?



Yes!  Please!  We need it.

I can do it if current vote process is positive

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: CForms slower with JXTemplateGenerator

[Jean-Baptiste Quenot]

* Sylvain Wallez:

> Leszek Gawron wrote:

> > roy huang wrote:

> > > In  current 2.1.x  svn ,Forms  using JXTemplateGenerator  is
> > > much slower than FormTransformer

> > For  2.1.x  it is  probably  true  because it  still  contains
> > unrefactored version of jxtg.

> So what about adding the new Template block to 2.1?

Yes!  Please!  We need it.
-- 
Jean-Baptiste Quenot
http://caraldi.com/jbq/

Re: CForms slower with JXTemplateGenerator

[Sylvain Wallez]

Leszek Gawron wrote:
> roy huang wrote:
>   
>> In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than 
>> FormTransformer
>> 
> For 2.1.x it is probably true because it still contains unrefactored
> version of jxtg.
>   

So what about adding the new Template block to 2.1?

Sylvain

-- 
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: CForms slower with JXTemplateGenerator

[Leszek Gawron]

roy huang wrote:
> In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than 
> FormTransformer
For 2.1.x it is probably true because it still contains unrefactored
version of jxtg.

-- 
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: CForms slower with JXTemplateGenerator

[roy huang]

In current 2.1.x svn ,Forms using JXTemplateGenerator is much slower than 
FormTransformer

Roy Huang

Re: CForms slower with JXTemplateGenerator

[Leszek Gawron]

Reinhard Poetz wrote:

--- Jean-Baptiste Quenot <[EMAIL PROTECTED]>
schrieb:



* Sascha-Matthias Kulawik:



Usual  stuff, but  Cocoon runs  very slow  in this


environment,


especially CForms  and the newer JXTransformer.


Tested  on Intel


Hardware or using Tomcat would solve the problem.


Do you mean using CForms's jx-macros.xml with
JXTemplateGenerator?
I   alsonoticed   thatit's   much   slower  
than   using
FormsTemplateTransformer.   But   Sylvain  told  me 
to   use  the

JXTemplateGenerator from  Cocoon 2.2  (trunk) in
Cocoon  2.1.  Has
anyone tried that combination?



I did some tests about half a year ago with the
generator (+ macros) from the JXTemplate-block (2.2).
After fixing some problems with the help of Daniel and
Leszek it was as fast as (or even a bit faster) than
the FormsTransformer.

If the performance is bad in recent tests, it might be
a problem introduced in the meantime as the macros and
jxtemplate have been refactored and extended .


I do not recall any serious changes being made that would affect 
performance.


About the combination of 2.1 with jxtg 2.2: The main problem I predict 
is a different object model provided for templates (in 2.2 Request, 
Response, Session and Context attributes have been extended in order to 
clarify things).


--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: CForms slower with JXTemplateGenerator

[Reinhard Poetz]

--- Jean-Baptiste Quenot <[EMAIL PROTECTED]>
schrieb:

> * Sascha-Matthias Kulawik:
> 
> > Usual  stuff, but  Cocoon runs  very slow  in this
>  environment,
> > especially CForms  and the newer JXTransformer.
> Tested  on Intel
> > Hardware or using Tomcat would solve the problem.
> 
> Do you mean using CForms's jx-macros.xml with
> JXTemplateGenerator?
> I   alsonoticed   thatit's   much   slower  
>  than   using
> FormsTemplateTransformer.   But   Sylvain  told  me 
> to   use  the
> JXTemplateGenerator from  Cocoon 2.2  (trunk) in
> Cocoon  2.1.  Has
> anyone tried that combination?

I did some tests about half a year ago with the
generator (+ macros) from the JXTemplate-block (2.2).
After fixing some problems with the help of Daniel and
Leszek it was as fast as (or even a bit faster) than
the FormsTransformer.

If the performance is bad in recent tests, it might be
a problem introduced in the meantime as the macros and
jxtemplate have been refactored and extended .

--
Reinhard







___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: CForms slower with JXTemplateGenerator

[Jean-Baptiste Quenot]

* Sascha-Matthias Kulawik:

> Usual  stuff, but  Cocoon runs  very slow  in this  environment,
> especially CForms  and the newer JXTransformer. Tested  on Intel
> Hardware or using Tomcat would solve the problem.

Do you mean using CForms's jx-macros.xml with JXTemplateGenerator?
I   alsonoticed   thatit's   much   slowerthan   using
FormsTemplateTransformer.   But   Sylvain  told  me  to   use  the
JXTemplateGenerator from  Cocoon 2.2  (trunk) in Cocoon  2.1.  Has
anyone tried that combination?
-- 
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845





--- Additional Comments From [EMAIL PROTECTED]  2005-09-04 05:44 ---
Thanks Leszek. I reviewed 2.2 and it is working there. Plase backport the 
changes. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845





--- Additional Comments From [EMAIL PROTECTED]  2005-09-02 10:28 ---
Fixed in trunk, please cross-check. I'll port the changes to 2.1.X then.
The fix also works for jx:formatDate as well as jx:formatNumber.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845





--- Additional Comments From [EMAIL PROTECTED]  2005-09-02 08:54 ---
This is a valid bug. The locale here does not work in this case:



a workaround is:




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845





--- Additional Comments From [EMAIL PROTECTED]  2005-07-25 13:09 ---
The suggested solution above is not that good in the following example:



where ${locale} is an actual Locale object. Since this probably is the "normal"
way of using the tag, it may be better to solve this bug in this way instead:

// First try to get the Locale as a Locale object
Object locVal = getValue(this.locale, jexl, jxp);
// If the locale wasn't a Locale object, try getting it as
// a String with getStringValue
if (locVal == null) {
locVal = getStringValue(this.locale, jexl, jxp);
}

or similar...

Best regards
Henric Müller

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35846] - locale attribute in is not used in JXTemplateGenerator

[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=35846


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-07-25 12:55 ---


*** This bug has been marked as a duplicate of 35845 ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845





--- Additional Comments From [EMAIL PROTECTED]  2005-07-25 12:55 ---
*** Bug 35846 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35846] New: - locale attribute in is not used in JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35846>.
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=35846

   Summary: locale attribute in  is not used in
    JXTemplateGenerator
   Product: Cocoon 2
   Version: 2.1.7
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,

I found that the locale attribute in the  tag is not used. I've also
seen that other people having trouble with this:
http://www.planetcocoon.com/node/2632
http://java2.5341.com/msg/108775.html

How to reproduce:
Make sure a variable named "date" is put in your jx-context.

In your jx-file:


Try some different locales and you will see that the date always is formatted
using the default locale in your JVM instead of the locale you specify in the
locale attribute.

How to fix it:
In the class StartFormatDate inner class (~ row 1700):
String format(JexlContext jexl, JXPathContext jxp)
throws Exception {
String var = getStringValue(this.var, jexl, jxp);
Object value = getValue(this.value, jexl, jxp);
Object locVal = getValue(this.locale, jexl, jxp);
 ...
Change the last row above so it uses getStringValue instead:
Object locVal = getValue(this.locale, jexl, jxp);

Best regards
Henric Müller

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] - locale attribute in is not used in JXTemplateGenerator

[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=35845





--- Additional Comments From [EMAIL PROTECTED]  2005-07-25 11:11 ---
I made a typo in the row that should fix everything, as you probably have
figured out already. It should be using getStringValue():

 Object locVal = getStringValue(this.locale, jexl, jxp);

Regards
Henric

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35845] New: - locale attribute in is not used in JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35845>.
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=35845

   Summary: locale attribute in  is not used in
    JXTemplateGenerator
   Product: Cocoon 2
   Version: 2.1.7
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi,

I found that the locale attribute in the  tag is not used. I've also
seen that other people having trouble with this:
http://www.planetcocoon.com/node/2632
http://java2.5341.com/msg/108775.html

How to reproduce:
Make sure a variable named "date" is put in your jx-context.

In your jx-file:


Try some different locales and you will see that the date always is formatted
using the default locale in your JVM instead of the locale you specify in the
locale attribute.

How to fix it:
In the class StartFormatDate inner class (~ row 1700):
String format(JexlContext jexl, JXPathContext jxp)
throws Exception {
String var = getStringValue(this.var, jexl, jxp);
Object value = getValue(this.value, jexl, jxp);
Object locVal = getValue(this.locale, jexl, jxp);
 ...
Change the last row above so it uses getStringValue instead:
Object locVal = getValue(this.locale, jexl, jxp);

Best regards
Henric Müller

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Sylvain Wallez]

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and 
some persistent filesystem swap, and therefore can only accept 
serializable objects.

Not true. Regular store must accept all objects. See also [1].
Vadim
[1] http://cocoon.apache.org/2.1/installing/updating.html#Store

Hmm... although the old implementation *may* have been able to accept 
non-serializable objects, it has AFAIK never formally be defined in 
the general store contract,

So now you will blame this bug on incomplete javadoc, huh? :-)

Well, do we have a better specification?
Here's what it says on the Store interface: "In some cases (like for 
example a cache) the data needs not to be persistent. Therefore with the 
two role TRANSIENT_STORE and PERSISTENT_STORE you get a store with 
exactly that behaviour."

We can consider that "the data needs not to be persisted" when it *can 
not* because it's not serializable.

and this is why we also have the transient store role.

No, that's not necessarily the right conclusion. I say we have 
transient store for objects which should not - or even must not! - be 
persisted across system restarts - even if they are serializable!

True, but (feeling like doing biblical interpertation) a 
non-serializable object must not be persisted across system restarts, 
and this for a good reason: it isn't possible to store it :-)

Considering the current issues with the newer cache systems we use 
(that integrate both memory front-end and persistent swap)

It does not mean that they are better, though. Even MRUMemoryStore is 
more efficient.


and can't handle non-serializable objects, I think it would be better 
to make it clear that non-serializable objects have to go in the 
transient store.

It is a serious backward incompatible change in contract. It might be 
better if general store simply passes non serializable objects to the 
transient store. Even better is fixing these new buggy stores. At the 
very least, this can be fixed in Cocoon itself - by wrapping objects 
into serializable holder.

Wow, a serializable holder? How can you do that when the wrapped objects 
are intrinsically not serializable? Or is it just for the serialization 
error to appear later, internally in the store, when the object is 
swapped to the filesystem?

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

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Vadim Gritsenko]

Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and 
some persistent filesystem swap, and therefore can only accept 
serializable objects.

Not true. Regular store must accept all objects. See also [1].
Vadim
[1] http://cocoon.apache.org/2.1/installing/updating.html#Store

Hmm... although the old implementation *may* have been able to accept 
non-serializable objects, it has AFAIK never formally be defined in the 
general store contract,
So now you will blame this bug on incomplete javadoc, huh? :-)

and this is why we also have the transient store role.
No, that's not necessarily the right conclusion. I say we have transient store 
for objects which should not - or even must not! - be persisted across system 
restarts - even if they are serializable!


Considering the current issues with the newer cache systems we use (that 
integrate both memory front-end and persistent swap)
It does not mean that they are better, though. Even MRUMemoryStore is more 
efficient.


and can't handle 
non-serializable objects, I think it would be better to make it clear 
that non-serializable objects have to go in the transient store.
It is a serious backward incompatible change in contract. It might be better if 
general store simply passes non serializable objects to the transient store. 
Even better is fixing these new buggy stores. At the very least, this can be 
fixed in Cocoon itself - by wrapping objects into serializable holder.

Vadim

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Sylvain Wallez]

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and 
some persistent filesystem swap, and therefore can only accept 
serializable objects.

Not true. Regular store must accept all objects. See also [1].
Vadim
[1] http://cocoon.apache.org/2.1/installing/updating.html#Store

Hmm... although the old implementation *may* have been able to accept 
non-serializable objects, it has AFAIK never formally be defined in the 
general store contract, and this is why we also have the transient store 
role.

Considering the current issues with the newer cache systems we use (that 
integrate both memory front-end and persistent swap) and can't handle 
non-serializable objects, I think it would be better to make it clear 
that non-serializable objects have to go in the transient store.

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

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Leszek Gawron]

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and 
some persistent filesystem swap, and therefore can only accept 
serializable objects.

Not true. Regular store must accept all objects. See also [1].
Vadim
[1] http://cocoon.apache.org/2.1/installing/updating.html#Store
Thanks for clarifying. Nice to know I'm not that crazy after all :)
--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Vadim Gritsenko]

Sylvain Wallez wrote:
The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and some 
persistent filesystem swap, and therefore can only accept serializable 
objects.
Not true. Regular store must accept all objects. See also [1].
Vadim
[1] http://cocoon.apache.org/2.1/installing/updating.html#Store

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Vadim Gritsenko]

Leszek Gawron wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
I think I have to switch to transient store because 
at least for now jxtg template is not serializable.

Is there a reason not to use transient store for jxtg?

none .. but I thought it is better to use a "store" instead of 
explicit "transient store". What I did not know was that when using 
Store one had to put only serializable objects in it.
Well it's better to use a store which is more appropriate. If it is faster to 
re-create something from original source than load it back from file system 
store, it is obvious that transient store is the best.


The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and 
some persistent filesystem swap, and therefore can only accept 
serializable objects.

got that now. I had a crazy idea that regular store can store all 
objects and is able to overflow to disk for those objects which support 
it - serializable.
It's not a crazy idea - that's how it should work. General store must accept any 
kind of objects. Default implementation still does work properly. Newer 
implementations are buggy. This is mentioned on the "known issues" page.

Vadim

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Leszek Gawron]

Sylvain Wallez wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java 




could this be the reason for the following exception?
java.lang.ClassCastException
at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61) 

at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102) 




Yes. I did not get it on my test case as I was using other store 
implementation. I think I have to switch to transient store because 
at least for now jxtg template is not serializable.

Is there a reason not to use transient store for jxtg?

none .. but I thought it is better to use a "store" instead of 
explicit "transient store". What I did not know was that when using 
Store one had to put only serializable objects in it.

The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and some 
persistent filesystem swap, and therefore can only accept serializable 
objects.

Sylvain
got that now. I had a crazy idea that regular store can store all 
objects and is able to overflow to disk for those objects which support 
it - serializable.

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Sylvain Wallez]

Leszek Gawron wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java 



could this be the reason for the following exception?
java.lang.ClassCastException
at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61) 

at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102) 



Yes. I did not get it on my test case as I was using other store 
implementation. I think I have to switch to transient store because 
at least for now jxtg template is not serializable.

Is there a reason not to use transient store for jxtg?
none .. but I thought it is better to use a "store" instead of 
explicit "transient store". What I did not know was that when using 
Store one had to put only serializable objects in it.

The transient store is meant as a cache for objects that aren't 
serializable, whereas the regular store has a memory front-end and some 
persistent filesystem swap, and therefore can only accept serializable 
objects.

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

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Leszek Gawron]

Vadim Gritsenko wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java 


could this be the reason for the following exception?
java.lang.ClassCastException
at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61) 

at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102) 


Yes. I did not get it on my test case as I was using other store 
implementation. I think I have to switch to transient store because at 
least for now jxtg template is not serializable.

Is there a reason not to use transient store for jxtg?
none .. but I thought it is better to use a "store" instead of explicit 
"transient store". What I did not know was that when using Store one had 
to put only serializable objects in it.

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Leszek Gawron]

Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java 


could this be the reason for the following exception?
java.lang.ClassCastException
at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61) 

at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102) 


fixed. thanks for reporting.
--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Vadim Gritsenko]

Leszek Gawron wrote:
Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java 

could this be the reason for the following exception?
java.lang.ClassCastException
at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61) 

at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102) 

Yes. I did not get it on my test case as I was using other store 
implementation. I think I have to switch to transient store because at 
least for now jxtg template is not serializable.
Is there a reason not to use transient store for jxtg?
Vadim

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Leszek Gawron]

Reinhard Poetz wrote:
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java 


could this be the reason for the following exception?
java.lang.ClassCastException
at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110) 

at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61) 

at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102) 
Yes. I did not get it on my test case as I was using other store 
implementation. I think I have to switch to transient store because at 
least for now jxtg template is not serializable.

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator

[Reinhard Poetz]

[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Sun May  8 14:23:28 2005
New Revision: 169169
URL: http://svn.apache.org/viewcvs?rev=169169&view=rev
Log:
JXTG uses cocoon store
Modified:

cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/template/jxtg/JXTemplateGenerator.java
could this be the reason for the following exception?
java.lang.ClassCastException
	at 
org.apache.cocoon.components.store.impl.EHDefaultStore.store(EHDefaultStore.java:268)
	at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:110)
	at 
org.apache.cocoon.template.jxtg.script.DefaultScriptManager.resolveTemplate(DefaultScriptManager.java:61)
	at 
org.apache.cocoon.template.jxtg.JXTemplateGenerator.setup(JXTemplateGenerator.java:102)

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

{Software Engineering, Open Source, Web Applications, Apache Cocoon}
   web(log): http://www.poetz.cc

DO NOT REPLY [Bug 33836] - JXTemplateGenerator cache thread safety problem

[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=33836


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 33836] New: - JXTemplateGenerator cache thread safety problem

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33836>.
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=33836

   Summary: JXTemplateGenerator cache thread safety problem
   Product: Cocoon 2
   Version: 2.1.6
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: sitemap components
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


I just upgraded to 2.1.6 and found a bug in JXTemplateGenerator.

The bug appears if one thread calls setup() and removes the cached template from
the cache. Before it has been able to reparse the template and put it back into
the cache another thread executes generate() and asks the cache for the same
template. The second thread will get a null startEvent.

Here's the relevant part of the setup()-method:

   synchronized (cache) {
   startEvent = (StartDocument)cache.get(uri);
   if (startEvent != null) {
   int valid = SourceValidity.UNKNOWN;
   if (startEvent.compileTime != null) {
   valid = startEvent.compileTime.isValid();
   }
   if (valid == SourceValidity.UNKNOWN && startEvent.compileTime
!= null) {
   SourceValidity validity = inputSource.getValidity();
   valid = startEvent.compileTime.isValid(validity);
   }
   if (valid != SourceValidity.VALID) {
   cache.remove(uri);
   regenerate = true;
   }
   } else {
   regenerate = true;
   }
   }
   if (regenerate) {
   Parser parser = new Parser();
   SourceUtil.parse(this.manager, this.inputSource, parser);
   startEvent = parser.getStartEvent();
   startEvent.compileTime = this.inputSource.getValidity();
   synchronized (cache) {
   cache.put(uri, startEvent);
   }
   }

To fix this either put the 'if (regenerate)' block inside the synchronized block
or remove the 'cache.remove(uri)' line.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: JXTemplateGenerator

[Sylvain Wallez]

Christopher Oliver wrote:

Let's face it: your code is dense as a neutron star and dense of 
comments and tests as the the outter space around one. 

For what it's worth I do like _your_ writing style above.

Me too, both because of the humorous tone and the message is conveys. 
Now you should remind that for most people here, english is a foreign 
language, and that not everybody is able to express jokes in a language 
they're not intimately familiar with. I for one am always afraid that 
funny expressions I know in french could be wrongly perceived when 
translated to english and read by non-english speakers. Cultural and 
language differences require the message to be more universal and 
therefore less original.

Your respect/care for the complexity of the social dynamics that 
originate around it is close to zero. 

Now, let me tell _you_ a story:
I play basketball 3-4 nights a week at the park by my house - 
"streetball", not organized basketball.  Now basketball is a fast 
paced game that requires split-second  decision making. As a result 
even the best players make mistakes in virtually every game. When an 
experienced player commits a turnover, misses an easy shot, misses a 
defensive assigment or whatever, there's no feeling of embarassment 
because it's known to be part of the game. However, inexperienced 
players tend to take their own mistakes as a personal reflection on 
their ability and tend to get embarassed or angry when one of their 
teamates points it out.

Now, since this is streetball and anyone can play, many different 
people of different skill levels show up.  However, in this case there 
is a harsh reality that if you don't know how to play the game well 
enough, you're likely to get embarassed by getting scored on, having 
the ball stolen from you, or your shots rejected. The only way not to 
get embarassed is to improve your game, to learn from your own 
mistakes - persevering through those embarassing moments - and to 
learn from other players. Anyone who has achieved any skill at 
basketball has gone through this process.

If you consider this story to be comparable to OSS development, then you 
are very far from the values of this community, and this explains a lot 
of things regarding how you behave and answer people. Developping Cocoon 
is not a competition. Developers don't try to bash each other, but work 
together to build something in common. Yes, there are some less 
experienced people. But if they are here and if they have been voted in 
as committers, it's because they have something to bring, and because 
they have the ability and the desire to learn. And more experienced 
people are happy to help them on this way.

The avalon project was taken over by peop le like you, that 
considered "consensus by friction" a better way to achieve progress 
and reduce the noisy babbage of social interaction with "inferior" 
talents. Result: social entropy expansion that lead to thermal death. 

I don't agree that I am anything like them and I don't think you would 
say that if your really knew me.

You're right: you went away rather than manipulating people like what 
happened in Avalon. Now people having met Stephen Mc Connell IRL said he 
is a pleasant person, and I heard the same about several people that are 
ususally rude in mailing-lists.

People can have very different behaviours in the virtualized world that 
is a mailing-list and the real world, when physical bodies are in front 
of each other. Unfortunately, we only know you through this list.

Technical problems are way more trivial to solve than social ones. 

Personally, I find both types of problems hard to solve.

Which explains the current situation: you're not happy to see people 
criticizing your work and wanting to refactor it so that it is more 
understandable and more easily adaptable to the evolution of its 
surrounding environment. Time goes on, and things have to evolve and 
adapt or die. That's what is happening currently with JXTG.

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

Re: JXTemplateGenerator

[Christopher Oliver]

Christopher Oliver wrote: > It's not personal, Bertrand. If someone 
does good work or makes a valid > point I will give them proper 
respect. If not, well, I'm not teaching > grade school and it's not my 
job to sugar coat it. 

Really? Wasn't that you that disliked the way Pierpaolo and myself 
avoided the sugar coating when we criticized the FOM design? 
To be honest, Pier's tone doesn't bother me, because he always has been 
able to back it up with valid points, real code, and humorous side comments.

Again, you fail to understand that what appears to be "pointless 
refactoring" for you might well be what turns a sandboxed one-man-show 
proposal into the official community-supported cocoon template system. 
Actually, I think I do (and did) understand that. And Daniel's and some 
others specific suggestions about how to improve the code seem very 
valid to me. So more power to them. However, mixed in that discussion 
were a number of silly ideas (which somehow need to be identified as 
such in order to make positive progress - and when that happens it can 
be painful or embarassing for somebody who feels personally responsible 
for them - but that's part of life).

William Strunk, Jr. and E.B. White, in their book "The Elements of 
Style" (New York, 1959) [page 70] write: "No one can write decently 
who is distrustful of the reader's intelligence, or whose attitude is 
patronizing". 

Let's face it: your code is dense as a neutron star and dense of 
comments and tests as the the outter space around one. 
For what it's worth I do like _your_ writing style above.
Your respect/care for the complexity of the social dynamics that 
originate around it is close to zero. 
Now, let me tell _you_ a story:
I play basketball 3-4 nights a week at the park by my house - 
"streetball", not organized basketball.  Now basketball is a fast paced 
game that requires split-second  decision making. As a result even the 
best players make mistakes in virtually every game. When an experienced 
player commits a turnover, misses an easy shot, misses a defensive 
assigment or whatever, there's no feeling of embarassment because it's 
known to be part of the game. However, inexperienced players tend to 
take their own mistakes as a personal reflection on their ability and 
tend to get embarassed or angry when one of their teamates points it out.

Now, since this is streetball and anyone can play, many different people 
of different skill levels show up.  However, in this case there is a 
harsh reality that if you don't know how to play the game well enough, 
you're likely to get embarassed by getting scored on, having the ball 
stolen from you, or your shots rejected. The only way not to get 
embarassed is to improve your game, to learn from your own mistakes - 
persevering through those embarassing moments - and to learn from other 
players. Anyone who has achieved any skill at basketball has gone 
through this process.

The avalon project was taken over by peop le like you, that considered 
"consensus by friction" a better way to achieve progress and reduce 
the noisy babbage of social interaction with "inferior" talents. 
Result: social entropy expansion that lead to thermal death. 
I don't agree that I am anything like them and I don't think you would 
say that if your really knew me.

Technical problems are way more trivial to solve than social ones. 
Personally, I find both types of problems hard to solve.
Everybody here welcomes contributions, not matter how silly, not 
matter how technologically savvy, now matter how outrageous and no 
matter how sinful and ranting. But respect for your peers is key. 
Unfortunately, true respect is earned, not given.  So it's not that simple.
-- Stefano.
As for Tony, I believe if you look back you might notice that I took the 
initiative in adding the excellent flowscript tutorial that he wrote to 
Cocoon. Hopefully, he does feel that was a compliment (which it was).

-- Chris

Re: JXTemplateGenerator

[Ralph Goers]

Stefano Mazzocchi wrote:.
Everybody here welcomes contributions, not matter how silly, not 
matter how technologically savvy, now matter how outrageous and no 
matter how sinful and ranting.

But respect for your peers is key.
Without that, any voice, no matter whose, becomes immediately silent, 
if not distracting and harmful.

And yes, I have committed this crime myself (and not only here) but it 
always brought me harm, cold and isolation.

A big price to pay for a little ego self-massaging.
Stefano,
First, I agree wholeheartedly with your response.  However, I have to 
temper that by saying that arrogance and egotism are often tempered with 
age (I should know, right?). In my younger days I was quite arrogant. I 
figured it was my right, since I was good at what I did.  With time you 
learn that there are lots of smart people, and lots of people with 
talents that are different then your own.  For example, while I am great 
with code my skills at designing a web page are lousy. You will 
accomplish very little in life if the people you need help and 
cooperation from don't like you.

In short, it is always OK to criticize an idea or design or even a piece 
of code, but.it is not OK to make that be personal or form our 
criticisms in such a way that they seem to be.

Ralph

Re: JXTemplateGenerator

[Stefano Mazzocchi]

Christopher Oliver wrote:
It's not personal, Bertrand. If someone does good work or makes a valid 
point I will give them proper respect. If not, well, I'm not teaching 
grade school and it's not my job to sugar coat it.
Really? Wasn't that you that disliked the way Pierpaolo and myself 
avoided the sugar coating when we criticized the FOM design?

Again, you fail to understand that what appears to be "pointless 
refactoring" for you might well be what turns a sandboxed one-man-show 
proposal into the official community-supported cocoon template system.

For this to happen, ego and code ownership must be set aside and all 
points of views respectfully debated, especially during brainstorming 
sessions as the one we are experiencing.

William Strunk, Jr. and E.B. White, in their book "The Elements of 
Style" (New York, 1959) [page 70] write:

"No one can write decently who is distrustful of the reader's 
intelligence, or whose attitude is patronizing".

Let's face it: your code is dense as a neutron star and dense of 
comments and tests as the the outter space around one. Your respect/care 
for the complexity of the social dynamics that originate around it is 
close to zero.

The avalon project was taken over by people like you, that considered 
"consensus by friction" a better way to achieve progress and reduce the 
noisy babbage of social interaction with "inferior" talents.

Result: social entropy expansion that lead to thermal death.
Technical problems are way more trivial to solve than social ones. I 
personally feel sad for the dry world of those who consider the first 
more important than the second.

Given that the template system is the contract between skilled 
programmers and unskilled ones, social problems will have to be taken 
into consideration way more than technical ones.

Everybody here welcomes contributions, not matter how silly, not matter 
how technologically savvy, now matter how outrageous and no matter how 
sinful and ranting.

But respect for your peers is key.
Without that, any voice, no matter whose, becomes immediately silent, if 
not distracting and harmful.

And yes, I have committed this crime myself (and not only here) but it 
always brought me harm, cold and isolation.

A big price to pay for a little ego self-massaging.
--
Stefano.

Re: JXTemplateGenerator

[Daniel Fagerstrom]

Bertrand Delacretaz wrote:
Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :

..."General consensus" has turned out to be incorrect on many 
occasions.
I guess many of us have seeked comfort in that idea, when not geting 
things our way. But while it might be a relevant idea for describing 
science development, the notion of being "correct" is not particulary 
usefull for discussing software development. In software devekopment it 
is much more important to create so much interest in ones ideas that 
people invest the energy in them, that makes them _become_ right. Is 
Unix and Widows NT the _correct_ operating systems?

Like it or not, striving for concensus is an important part of how the 
Cocoon community works. If it is efficient or not must be evaluated from 
the well being of the community and the quality of what we deliver.

What I see is that some people, such as Stefano, are 
looking to build a better templating system while others are 
contemplating what appears to be pointless refactoring...
If the only goal is for these people to become more comfortable with the 
code by refactoring, and especially if they're creating new tests along 
the way it I'm happy. But I understand the refactoring can seem 
pointless to you as you know this code much better.
For successfull code the time invested in writing the first version of 
it, is often a quite small fraction of all the developer time invested 
in the piexe of code during the life time of the project. And in the 
further development of a piece of code, reading and understanding the 
code often takes much longer time than adding the few lines of code that 
corrects the bug or add the new feature.

As a consequence, the efficiency of a piece of code cannot only be 
evaluated in terms of how well it does its work, but it must also be 
evaluated in how efficient it _communicates_ what it does to the ones 
that are reading it. And the communication style of JXTG is IMO entirely 
consistent with the email communication style of its author ;)

So if we succeed in making JXTG easier to digest for the Cocoon 
developer community and nothing more, it is still far from pointless, as 
it will going to save a lot of developer time in the future.

Now, my motivation for being involved in refactoring of JXTG, is to get 
it in such shape that I feel comfortable in using it as base for 
developing some new ideas on. Some of these new ideas has been discussed 
on the list and some are RTs that I don't have discussed yet.

...Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself 
included.
OK, but the size of the source file has no effect on the behavior of 
the classes it contains. If someone wants to convert inner to external 
classes it is a trivial and mindless exercise.  In fact, I would 
hardly call it refactoring...
Point taken, it's more like restructuring (damn, is there a function key 
in IDEA to do this? ;-)

The important thing for me is not really how the code looks though, but 
how the people who are taking charge of it perceive it.
What have been done this far is just a first step, don't worry less 
mechanical things will be done. And while the size of a file doesn't 
affect its behavior, it might effect how well it communucates its behaviour.

...  On the other hand the issues that Stefano raised bring up real 
problems that are not addressed by JXTG at all (nor any of the 
suggested alternatives)...
Ok - there's probably more to do, but in the meantime JXTG is an 
important component of Cocoon, so whatever big or small work people do 
to improve it must be encouraged.

...It's not personal, Bertrand. If someone does good work or makes a 
valid point I will give them proper respect. If not, well, I'm not 
teaching grade school and it's not my job to sugar coat it.
It might not be your job to sugar coat things, but you take the risk of 
focusing your audience energy and the response you get into other areas 
than the technical discussion, by not doing an effort in that direction.

/Daniel

Re: JXTemplateGenerator

[Reinhard Poetz]

Christopher Oliver wrote:
"General consensus" has turned out to be incorrect on many occasions.  
What I see is that some people, such as Stefano, are looking to build a 
better templating system while others are contemplating what appears to 
be pointless refactoring.
As I prepare a presentation on web controller I read the thread where Ovidiu 
presented his continuations idea. General consensus was something like Struts 
did (and still does ;-) and it took a while until people began to understand 
what the power is. And look where we are today ... :-)
Anyway, just a sidenote.

My question is: Chris, you talked to Stefano IRL and read at least some of the 
mails of the templating discussion. What is your understanding where "next 
generation templating" should head to?

--
Reinhard

Re: JXTemplateGenerator

[Bertrand Delacretaz]

Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :
..."General consensus" has turned out to be incorrect on many 
occasions.  What I see is that some people, such as Stefano, are 
looking to build a better templating system while others are 
contemplating what appears to be pointless refactoring...
If the only goal is for these people to become more comfortable with 
the code by refactoring, and especially if they're creating new tests 
along the way it I'm happy. But I understand the refactoring can seem 
pointless to you as you know this code much better.

...Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself 
included.
OK, but the size of the source file has no effect on the behavior of 
the classes it contains. If someone wants to convert inner to external 
classes it is a trivial and mindless exercise.  In fact, I would 
hardly call it refactoring...
Point taken, it's more like restructuring (damn, is there a function 
key in IDEA to do this? ;-)

The important thing for me is not really how the code looks though, but 
how the people who are taking charge of it perceive it.

...  On the other hand the issues that Stefano raised bring up real 
problems that are not addressed by JXTG at all (nor any of the 
suggested alternatives)...
Ok - there's probably more to do, but in the meantime JXTG is an 
important component of Cocoon, so whatever big or small work people do 
to improve it must be encouraged.

...It's not personal, Bertrand. If someone does good work or makes a 
valid point I will give them proper respect. If not, well, I'm not 
teaching grade school and it's not my job to sugar coat it.
I know, but we're all the grade school student of someone else here, 
depending on which area of expertise you consider. So we have to be 
careful not to break the (sometimes fragile) links which hold this 
great community together.

Thanks for your constructive reply (and for the initial comments about 
JXTG by the way, they will help a lot).

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: JXTemplateGenerator

[Daniel Fagerstrom]

Christopher Oliver wrote:
I recently took a look at this mailing list after I happened to talk to 
Stefano in person (he was in LA) and noticed a _few_ posts about 
refactoring JXTemplateGenerator.

Of course you can do what you like, but just so you know, here is my 
point of view:

Obviously it would have been easy to make the expression language 
pluggable. I intentionally did not do that but rather decided to 
specifically support Jexl and JXPath.

The reasons:
- Both Jexl and JXPath are IMO quality Apache projects that deserve to 
be reused - and I enjoy building on the work of others which, to me,  is 
one of the best aspects of open source software development.
The main reason for making expression languages (EL) plugable is that 
ELs are used in many places in Cocoon. If we define a common inteface 
for using an EL and for giving a context for an EL we could get rid of 
duplicated code and ensure that ELs are used in the same way everywhere.

Although other ELs has been mentioned at the list I would guess that our 
"oficial" recomondation would be that users stick to Jexl and JXPath.

- Two fundamentally different types of objects are typically passed to 
the template, namely Java Beans and XML documents. Jexl works well with 
the former but not the latter. The opposite is true for JXPath. However 
JXPath provides a bridge between the two for those cases where it is 
necessary to access both models in the same expression. It is naive in 
my opinion to assume that unifying to a single expression language is an 
actual achievement unless that language is suitable for accessing _all_ 
the object models you are using (maybe like this one: 
http://research.microsoft.com/~emeijer/Papers/XS.pdf). However, to my 
knowledge no usable implementation of such a language exists.  The 
combination of Jexl and JXPath is minimally viable for 
JXTemplateGenerator IMO and if I were to vote I would -1 eliminating 
either one of them.
I think there is an agreement on the list on supporting both, based on 
the reasons you mentioned above. Some people suggested earlier that it 
would better to stick to one EL (the suggesters favourite one normally 
;) ), but it soon become obvoius that it would be unrealistic.

I intentionally did not provide a Java language "taglib" interface like 
that in JSTL, but instead provided a macro language as in Velocity.
I sugested that we should use "externally defined Java tags" (I don't 
use the term taglib anymore as it evoked bad emotions from some people). 
One reason for this is that I want to gather the code that implements a 
tag to one class, instead of having it placed in a tag class, in the 
parser and in the execution method. This to make it easier to see whats 
going on in the code and simplify support.

Another reason is that it often has been sugested that we need a 
replacement for XSP. And I thought that it could be a good idea to 
implement the few things from XSP as external tags to JXTG. Also there 
are plenty of transformers that basically implement a set of tags and 
where their actual function is hidden in all the event handling and 
state machine code. Here I also though that it would be easier to 
implement such things in the future by providing a tag interface.

But a lot of people seemed to think that it would be very bad for Cocoon 
to allow such things. So I still think that I will gather the code for 
each tag to one class with a common tag inteface, but not providing any 
mechanisms for users to import their own Java tags. That should keep 
everybody (except some users maybe ;) ) happy.

The 
primary reason was that Java tags cannot be optimized the way macros 
can.
I had no intension whatsoever to remove macros. For most uses I think 
they are superior to Java tags.

Just look at the implementation of the Cocoon taglib block for a 
good example of how to get terrible performance in your template 
processor (it does componentmanager (or servicemanager or whatever it's 
called now) lookups at runtime just to determine if a given tag is 
really a Java "taglib").
Agree with that. We had some discussions about life cycle and contracts 
for tags and agreed about requiring them to be thread safe so that all 
setup work can be done at compile time. They would work in the same way 
the tags you have implemented. So I think they should get the same 
performance.

I also saw some comments about how you shouldn't put presentation markup 
in your templates but instead use XSLT, etc. The reason given was 
something to the  effect that you would have to go change all your 
templates if your site design changed.

Um, hello, you _can_ avoid this by using   and  macros 
(that's what they're there for - namely to factor out reusable parts of 
your templates so they can be managed in one place). It seems a little 
silly to me to suggest that you _must_ use pipelines and XSLT to get 
reusability and managability. 

Re: JXTemplateGenerator

[Christopher Oliver]

Le 10 déc. 04, à 17:29, Christopher Oliver a écrit : > ...The funniest 
post of all was this > 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2 
. 
> > I mean, give me break. That is just plain silly

Sorry for replying to you directly but I'm not subscribed to cocoon-dev.
Can't swallow this one without reacting, sorry - wrong tone, and there 
is a general consensus that JXTG needs refactoring, 

"General consensus" has turned out to be incorrect on many occasions.  
What I see is that some people, such as Stefano, are looking to build a 
better templating system while others are contemplating what appears to 
be pointless refactoring.

I did notice that Leszek identified a real problem with JXTG, namely not 
being able to pass parameters to macros called via jx:eval (and he seems 
motivated to fix it, so more power to him).

I find it very unfair of you to pick on Tony specifically.
From my experience (which is not restricted to Apache mailing lists) if 
you choose to post your opinions to a public mailing list, you need to 
be prepared to deal with the consequences.

Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself included. 
OK, but the size of the source file has no effect on the behavior of the 
classes it contains. If someone wants to convert inner to external 
classes it is a trivial and mindless exercise.  In fact, I would hardly 
call it refactoring.  On the other hand the issues that Stefano raised 
bring up real problems that are not addressed by JXTG at all (nor any of 
the suggested alternatives).

You've been quiet for a while, people are willing to take over to 
ensure JXTG's future (because it's a great tool, we *are* thankful to 
you for this), they're doing their best and we're starting to see good 
things coming out of this. So please respect their work - as much as 
we respect you and your work. 
It's not personal, Bertrand. If someone does good work or makes a valid 
point I will give them proper respect. If not, well, I'm not teaching 
grade school and it's not my job to sugar coat it.

-Bertrand

- Chris

Re: JXTemplateGenerator

[Glen Ezkovich]

On Dec 10, 2004, at 10:29 AM, Christopher Oliver wrote:
I also saw some comments about how you shouldn't put presentation 
markup in your templates but instead use XSLT, etc. The reason given 
was something to the  effect that you would have to go change all your 
templates if your site design changed.

Um, hello, you _can_ avoid this by using   and  macros 
(that's what they're there for - namely to factor out reusable parts 
of your templates so they can be managed in one place). It seems a 
little silly to me to suggest that you _must_ use pipelines and XSLT 
to get reusability and managability. I mean, any decent programming 
language provides subroutines and libraries.

I think this was me, and while we use  and macros it did not 
occur to me to use them to solve the problem of the ever evolving site 
design. Admittedly we could have done this. And I may have overstated 
my point. You are right it is a ridiculous notion that you MUST use 
pipelines and XSLT to get reusability.  What is not ridiculous is to 
suggest that you can get greater reusability by using pipelines and 
XSLT given that your site does not use JXTG exclusively.

The sites pages came from many types of sources. We used JXTG for only 
a portion of them. Many of the page elements they used were already 
defined in XSLT. We could have created macros but that would have been 
recreating the wheel. While stating that you have to modify all your 
templates when your site design changes was too strong, in our case it 
was a more flexible solution to just use an XML template XSLT. I like 
this approach and encourage others to try but they should do what works 
best for their problem.

Regardless of how i use it I think JXTG is a wonderful tool with a 
great deal of flexibility. I don't think the effort to refactor and 
extend it is being done with anything other then love and respect.

I never realized inner classes were so _scary_.  (The reason they are 
there is that JXTemplateGenerator predates blocks and also that the 
majority of those classes are unencapsulated "flyweight" objects that 
are managed by the enclosing template processor class.) If you insist 
on making them external classes please make sure they aren't public.
Makes good sense. Remember that refactoring is useful for 
understanding. The desire for refactoring derives from people looking 
at the code and not understanding its organization and what is going 
on.  Hopefully it is not fear of inner classes. ;-) Now anonymous 
classes those give me the shivers.

Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

Re: JXTemplateGenerator

[Bertrand Delacretaz]

Le 10 déc. 04, à 17:29, Christopher Oliver a écrit :
...The funniest post of all was this 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2.

I mean, give me break. That is just plain silly
Can't swallow this one without reacting, sorry - wrong tone, and there 
is a general consensus that JXTG needs refactoring, I find it very 
unfair of you to pick on Tony specifically.

Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself 
included.

You've been quiet for a while, people are willing to take over to 
ensure JXTG's future (because it's a great tool, we *are* thankful to 
you for this), they're doing their best and we're starting to see good 
things coming out of this.

So please respect their work - as much as we respect you and your work.
-Bertrand



smime.p7s
Description: S/MIME cryptographic signature

Re: JXTemplateGenerator

[Tony Collen]

(I had originally done the "write the nasty email, then delete it and 
write it again" trick.  Let's see if it works:)

Christopher Oliver wrote:
I recently took a look at this mailing list after I happened to talk to 
Stefano in person (he was in LA) and noticed a _few_ posts about 
refactoring JXTemplateGenerator.
You should show up a little more often... you know, be a little more 
sociable.

The funniest post of all was this 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2.

I mean, give me break. That is just plain silly.
I never realized inner classes were so _scary_.  (The reason they are 
there is that JXTemplateGenerator predates blocks and also that the 
majority of those classes are unencapsulated "flyweight" objects that 
are managed by the enclosing template processor class.) If you insist on 
making them external classes please make sure they aren't public.
(Background: It's my part of personality to become easily insulted, 
and for some reason I was initially insulted by this, but I'm not any 
mroe.  This is what caused me to have to rewrite this email a couple 
times.)

I'll admit:  I am scared by that metric shitton of code.  I'm not 
afraid to say it, either; I'm an amateur when it comes to programming. 
 But there was something else that bugged me about all that code:

I wanted to make sure the JXTG didn't suffer from the dreaded "one man 
show" syndrome.  The nice thing is that I think because of the JXTG 
discussion, we've been able to avoid it.

I wanted to make sure more than just one person knew what was going on 
with the code.  Again, because of the JXTG refactoring that's 
happening, this is no longer true as well.

I wanted to make sure that we didn't end up tossing JXT in favor or 
something new.  The JXTG plays an essential role in the "power triad," 
and dumping it would not be a good thing.  JTXG is here to stay.

I appreciate you showing up for some disussion on the issues, and I'm 
sure much of the list appreciates it too.  However, IMNSHO, before *I* 
take you seriously, you're going to have drop the sarcastic tone of 
your messages and be willing cooperate.  Please realize that not 
everyone is a super programmer.

If you're willing to hang out and chill, by all means, please stick 
around for a bit. I'm sure that people are more than willing to listen 
if you have some input to the JXTG refactoring that's happening.

I can't speak for anyone else on the list, but a helpful and 
cooperative message will get you further with your cause, at least 
with me.

Respectfully,
Tony

Re: JXTemplateGenerator

[Antonio Gallardo]

Hi Chris:

Thanks for sending this mail. It explains a lot about JXTG design
decisions and make things clear. Please do me a fabor, try to stay a
little bit more on the list while the topic is discussed. I (and others)
will be glad to hear your comments about this topic. :-D

Best Regards,

Antonio Gallardo

On Vie, 10 de Diciembre de 2004, 10:29, Christopher Oliver dijo:
> I recently took a look at this mailing list after I happened to talk to
> Stefano in person (he was in LA) and noticed a _few_ posts about
> refactoring JXTemplateGenerator.
>
> Of course you can do what you like, but just so you know, here is my
> point of view:
>
> Obviously it would have been easy to make the expression language
> pluggable. I intentionally did not do that but rather decided to
> specifically support Jexl and JXPath.
>
> The reasons:
>
> - Both Jexl and JXPath are IMO quality Apache projects that deserve to
> be reused - and I enjoy building on the work of others which, to me,  is
> one of the best aspects of open source software development.
> - Two fundamentally different types of objects are typically passed to
> the template, namely Java Beans and XML documents. Jexl works well with
> the former but not the latter. The opposite is true for JXPath. However
> JXPath provides a bridge between the two for those cases where it is
> necessary to access both models in the same expression. It is naive in
> my opinion to assume that unifying to a single expression language is an
> actual achievement unless that language is suitable for accessing _all_
> the object models you are using (maybe like this one:
> http://research.microsoft.com/~emeijer/Papers/XS.pdf). However, to my
> knowledge no usable implementation of such a language exists.  The
> combination of Jexl and JXPath is minimally viable for
> JXTemplateGenerator IMO and if I were to vote I would -1 eliminating
> either one of them.
>
> I intentionally did not provide a Java language "taglib" interface like
> that in JSTL, but instead provided a macro language as in Velocity. The
> primary reason was that Java tags cannot be optimized the way macros
> can. Just look at the implementation of the Cocoon taglib block for a
> good example of how to get terrible performance in your template
> processor (it does componentmanager (or servicemanager or whatever it's
> called now) lookups at runtime just to determine if a given tag is
> really a Java "taglib").
>
> I also saw some comments about how you shouldn't put presentation markup
> in your templates but instead use XSLT, etc. The reason given was
> something to the  effect that you would have to go change all your
> templates if your site design changed.
>
> Um, hello, you _can_ avoid this by using   and  macros
> (that's what they're there for - namely to factor out reusable parts of
> your templates so they can be managed in one place). It seems a little
> silly to me to suggest that you _must_ use pipelines and XSLT to get
> reusability and managability. I mean, any decent programming language
> provides subroutines and libraries.
>
> As regards the programming language like constructs, , ,
> etc (borrowed directly from JSTL), those are there simply as
> navigational tools for the object model (to navigate repeating data and
> alternative - choice, optional - data) and _not_ to write computations
> as in a real programming language.
>
> The funniest post of all was this
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2.
>
> I mean, give me break. That is just plain silly.
>
> I never realized inner classes were so _scary_.  (The reason they are
> there is that JXTemplateGenerator predates blocks and also that the
> majority of those classes are unencapsulated "flyweight" objects that
> are managed by the enclosing template processor class.) If you insist on
> making them external classes please make sure they aren't public.
>
> - Chris
>
>

JXTemplateGenerator

[Christopher Oliver]

I recently took a look at this mailing list after I happened to talk to 
Stefano in person (he was in LA) and noticed a _few_ posts about 
refactoring JXTemplateGenerator.

Of course you can do what you like, but just so you know, here is my 
point of view:

Obviously it would have been easy to make the expression language 
pluggable. I intentionally did not do that but rather decided to 
specifically support Jexl and JXPath.

The reasons:
- Both Jexl and JXPath are IMO quality Apache projects that deserve to 
be reused - and I enjoy building on the work of others which, to me,  is 
one of the best aspects of open source software development.
- Two fundamentally different types of objects are typically passed to 
the template, namely Java Beans and XML documents. Jexl works well with 
the former but not the latter. The opposite is true for JXPath. However 
JXPath provides a bridge between the two for those cases where it is 
necessary to access both models in the same expression. It is naive in 
my opinion to assume that unifying to a single expression language is an 
actual achievement unless that language is suitable for accessing _all_ 
the object models you are using (maybe like this one: 
http://research.microsoft.com/~emeijer/Papers/XS.pdf). However, to my 
knowledge no usable implementation of such a language exists.  The 
combination of Jexl and JXPath is minimally viable for 
JXTemplateGenerator IMO and if I were to vote I would -1 eliminating 
either one of them.

I intentionally did not provide a Java language "taglib" interface like 
that in JSTL, but instead provided a macro language as in Velocity. The 
primary reason was that Java tags cannot be optimized the way macros 
can. Just look at the implementation of the Cocoon taglib block for a 
good example of how to get terrible performance in your template 
processor (it does componentmanager (or servicemanager or whatever it's 
called now) lookups at runtime just to determine if a given tag is 
really a Java "taglib").

I also saw some comments about how you shouldn't put presentation markup 
in your templates but instead use XSLT, etc. The reason given was 
something to the  effect that you would have to go change all your 
templates if your site design changed.

Um, hello, you _can_ avoid this by using   and  macros 
(that's what they're there for - namely to factor out reusable parts of 
your templates so they can be managed in one place). It seems a little 
silly to me to suggest that you _must_ use pipelines and XSLT to get 
reusability and managability. I mean, any decent programming language 
provides subroutines and libraries.

As regards the programming language like constructs, , , 
etc (borrowed directly from JSTL), those are there simply as 
navigational tools for the object model (to navigate repeating data and 
alternative - choice, optional - data) and _not_ to write computations 
as in a real programming language.

The funniest post of all was this 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2.

I mean, give me break. That is just plain silly.
I never realized inner classes were so _scary_.  (The reason they are 
there is that JXTemplateGenerator predates blocks and also that the 
majority of those classes are unencapsulated "flyweight" objects that 
are managed by the enclosing template processor class.) If you insist on 
making them external classes please make sure they aren't public.

- Chris

ClassCastException in ScriptablePropertyHandler/JXTemplateGenerator

[Joerg Heinicke]

I'm getting a ClassCastException when using the JXTemplateGenerator and passing
bizdata to it:

java.lang.ClassCastException
at org.apache.cocoon.components.flow.javascript.ScriptablePropertyHandler
   .getPropertyNames(ScriptablePropertyHandler.java:77)
at org.apache.cocoon.generation.JXTemplateGenerator
   .fillContext(JXTemplateGenerator.java:2410)
at org.apache.cocoon.generation.JXTemplateGenerator
   .setContexts(JXTemplateGenerator.java:2457)
at org.apache.cocoon.generation.JXTemplateGenerator
   .setup(JXTemplateGenerator.java:2397)

It's an older version of Cocoon (2004-06-29):

http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/
   components/flow/javascript/ScriptablePropertyHandler.java?annotate=1.7
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/
   generation/JXTemplateGenerator.java?annotate=1.50

In this code some properties are casted to Strings:

69 :  Object[] ids;
70 :  if (obj instanceof ScriptableObject) {
71 :  ids = ((ScriptableObject)obj).getAllIds();
72 :  } else {
73 :  ids = ((Scriptable)obj).getIds();
74 :  }
75 :  String[] result = new String[ids.length];
76 :  for (int i = 0; i < result.length; i++) {
77 :  result[i] = (String)ids[i];
78 :  }

But obj is a NativeArray in my case and ids after running through line 71
contains an Integer 0 and a String "length".

The flowscript code looks like the following:

var legalcasesArray = new Array();
for (var i = 0; i < legalcases.size(); i++) {
var lc = legalcases.get(i);
var event = lc.getEvent();
legalcasesArray[i] = {"document": event.getDocument(lc), "variant":
  lc.getDocumentVariant(), "eventId": event.getId()};
}
cocoon.sendPage("internal-display-document-bulk", legalcasesArray);

Everything works like expected, I only get this exception stacktrace printed on
the console as the exception is ignored. Is there an error in using JXTemplate
or is it a bug?

Joerg

DO NOT REPLY [Bug 29381] - JXTemplateGenerator: ignore start/endDocument when streaming nodes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29381>.
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=29381

JXTemplateGenerator: ignore start/endDocument when streaming nodes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-11 12:48 ---
I have committed a small change to the JXTemplateGenerator, along with an
anteater test which demonstrates the new behavior. 

DOM objects are now dumped via an IncludeXMLConsumer filter, which removes
start/endDocument events.

Dumping DOM objects now works with both the #{domObject} and the #{domObject/*}
syntaxes. 

Please cross-check.

DO NOT REPLY [Bug 29381] - JXTemplateGenerator: ignore start/endDocument when streaming nodes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29381>.
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=29381

JXTemplateGenerator: ignore start/endDocument when streaming nodes

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|JXTemplate - Can't process  |JXTemplateGenerator: ignore
   |DOM document passed from|start/endDocument when
   |flowscript  |streaming nodes



--- Additional Comments From [EMAIL PROTECTED]  2004-10-11 10:31 ---
FYI I've seen the problem recently and added the relevant info to the FAQ at
http://wiki.apache.org/cocoon/FAQs (""The TransformerHandler is not serially
reusable".")

Re: Customizing the JxTemplateGenerator

[Sylvain Wallez]

Danny Bols wrote:
Repost...in the hope that the Jx/Jexl gurus are not on vacation.
 

Worse than that: the Jx/Jexl guru has left the project (it's Chris Oliver).
When customizing the JxTemplateGenerator we ran into a hardcoded
implementation of the Uberspect in Cocoon-2.1.4. The only way to get our own
implementation of the Uberspect up-and-running was to DIRTY hack the
JEXL-source.
Anyone ran into the same problems? Any better solutions?
 

Well, you seem to be more aware than us on this, so tell us the result 
of your investigation, so that we can improve our knowledge.

Maybe a little refactoring of JXTG allowing a subclass to redefine the 
Uberspect could help?

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

Customizing the JxTemplateGenerator

[Danny Bols]

Repost...in the hope that the Jx/Jexl gurus are not on vacation.

When customizing the JxTemplateGenerator we ran into a hardcoded
implementation of the Uberspect in Cocoon-2.1.4. The only way to get our own
implementation of the Uberspect up-and-running was to DIRTY hack the
JEXL-source.

Anyone ran into the same problems? Any better solutions?

Thanks
--
Danny

Small change to JXTemplateGenerator

[Peter Brant]

Hi all,

I think this is a bug, but just to make sure.  When copying an attribute
value containing no expressions, the original value shouldn't be used
because \ escapes will change the final value.  Patch is against
BRANCH_2_1_X.

Thanks,

Pete

--- JXTemplateGenerator.java.orig   2004-09-16 02:08:03.0 +0200
+++ JXTemplateGenerator.java2004-09-16 02:23:46.0 +0200
@@ -1194,7 +1194,7 @@
 }
 if (buf.length() > 0) {
 if (substEvents.size() == 0) {
-attributeEvents.add(new CopyAttribute(uri, local,
qname, type, value));
+attributeEvents.add(new CopyAttribute(uri, local,
qname, type, buf.toString()));
 } else {
 substEvents.add(new Literal(buf.toString()));
 attributeEvents.add(new SubstituteAttribute(uri,
local, qname, type, substEvents));

-- 
Supergünstige DSL-Tarife + WLAN-Router für 0,- EUR*
Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl--- JXTemplateGenerator.java.orig   2004-09-16 02:08:03.0 +0200
+++ JXTemplateGenerator.java2004-09-16 02:23:46.0 +0200
@@ -1194,7 +1194,7 @@
 }
 if (buf.length() > 0) {
 if (substEvents.size() == 0) {
-attributeEvents.add(new CopyAttribute(uri, local, qname, 
type, value));
+attributeEvents.add(new CopyAttribute(uri, local, qname, 
type, buf.toString()));
 } else {
 substEvents.add(new Literal(buf.toString()));
 attributeEvents.add(new SubstituteAttribute(uri, local, 
qname, type, substEvents));

Re: [was: RE: JXTemplateGenerator] setup() called twice when cocoon:// protocol used

[Michael Gerzabek]

blame on me! An image was missing. Sorry for the noise.
Regards,
Michael
At 13:12 03.09.2004, you wrote:
I debugged JXTG down and found out that seupt() is called twice when you 
use cocoon://.
There have been problems in the past with xsp pages that were loaded twice 
when using
cocoon:/(/) protocol
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107418715206665&w=2
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26186

Maybe there is a connection to
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109419334830100&w=2
WDYT? Are there any paths to follow?
Regards,
Michael

[was: RE: JXTemplateGenerator] setup() called twice when cocoon:// protocol used

[Michael Gerzabek]

I debugged JXTG down and found out that seupt() is called twice when you 
use cocoon://.
There have been problems in the past with xsp pages that were loaded twice 
when using
cocoon:/(/) protocol
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107418715206665&w=2
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26186

Maybe there is a connection to
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109419334830100&w=2
WDYT? Are there any paths to follow?
Regards,
Michael

Re: JXTemplateGenerator

[Michael Gerzabek]

At 11:23 03.09.2004, you wrote:
Michael Gerzabek wrote:
The best thing is - my session parameters are gone after I use
those statements. Before I call the page they are there and
afterwards they are gone.

works like a charm for me.
Could it be that the problem origins from using JXTG outside
the flow?
I've a flow scripts that handles login() and a bunch of stateless pages.
I use for these pages also the JXTG where I try to read some parameters
from session that the login() function had put there before.
Regards,
Michael

--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: JXTemplateGenerator

[Leszek Gawron]

Michael Gerzabek wrote:
The best thing is - my session parameters are gone after I use
those statements. Before I call the page they are there and
afterwards they are gone.

works like a charm for me.
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: JXTemplateGenerator

[Michael Gerzabek]

The best thing is - my session parameters are gone after I use
those statements. Before I call the page they are there and
afterwards they are gone.
Strange. Any idea?
Regards,
Michael
At 21:59 02.09.2004, you wrote:
Michael Gerzabek wrote:
Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) ${parameters.getParameter("store")}
2.) ${session.getAttribute("store")}
3.) 
4.) 
except of 4.) nothing is working for me.
What am I doing wrong?
Thanks in advance
Michael
should use $cocoon.session
--
Leszek Gawron  [EMAIL PROTECTED]

Re: JXTemplateGenerator

[Michael Gerzabek]

Doesn't work either. For the input
${cocoon.session.STORE_NAME}
${cocoon.session.getAttribute("STORE_NAME")}
${cocoon.session.getAttribute('STORE_NAME')}
${cocoon.session/STORE_NAME}
#{cocoon.session.STORE_NAME}
I get the results



0

I'm using C2.1.5.1.
Do I need input modules for that functionality?
Thanks,
Michael
At 21:59 02.09.2004, you wrote:
Michael Gerzabek wrote:
Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) ${parameters.getParameter("store")}
2.) ${session.getAttribute("store")}
3.) 
4.) 
except of 4.) nothing is working for me.
What am I doing wrong?
Thanks in advance
Michael
should use $cocoon.session
--
Leszek Gawron  [EMAIL PROTECTED]

Re: JXTemplateGenerator

[Leszek Gawron]

Michael Gerzabek wrote:
Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) ${parameters.getParameter("store")}
2.) ${session.getAttribute("store")}
3.) 
4.) 
except of 4.) nothing is working for me.
What am I doing wrong?
Thanks in advance
Michael
should use $cocoon.session
--
Leszek Gawron  [EMAIL PROTECTED]

JXTemplateGenerator

[Michael Gerzabek]

Hello,
I'm not sure if this is a bug or me doing wrong:
I'm trying to access session attributes from JXTemplateGenerator as well as
sitemap parameters. I use
1.) ${parameters.getParameter("store")}
2.) ${session.getAttribute("store")}
3.) 
4.) 
except of 4.) nothing is working for me.
What am I doing wrong?
Thanks in advance
Michael 

DO NOT REPLY [Bug 27133] - JxTemplateGenerator eats backslash-characters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27133>.
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=27133

JxTemplateGenerator eats backslash-characters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-28 02:44 ---
Fixed, please cross check.

DO NOT REPLY [Bug 27133] - JxTemplateGenerator eats backslash-characters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27133>.
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=27133

JxTemplateGenerator eats backslash-characters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

DO NOT REPLY [Bug 29752] - [PATCH] Caching JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29752>.
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=29752

[PATCH] Caching JXTemplateGenerator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-06-26 08:44 ---
Patch applied with minor changes, please cross check and close the bug.

DO NOT REPLY [Bug 29752] - [PATCH] Caching JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29752>.
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=29752

[PATCH] Caching JXTemplateGenerator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

DO NOT REPLY [Bug 29752] - [PATCH] Caching JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29752>.
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=29752

[PATCH] Caching JXTemplateGenerator





--- Additional Comments From [EMAIL PROTECTED]  2004-06-23 08:54 ---
Created an attachment (id=11914)
source

DO NOT REPLY [Bug 29752] New: - [PATCH] Caching JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29752>.
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=29752

[PATCH] Caching JXTemplateGenerator

   Summary: [PATCH] Caching JXTemplateGenerator
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have implemented a patch to JXTG that allows to specify cache-key and cache-
validity. Please look at this message for changes summary:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108627413529986&w=2

I attache the full JXTemplateGenerator as I have no tools right now to provide 
a cvs diff.

Customizing the JxTemplateGenerator

[Danny Bols]

Hello,

when customizing the JxTemplateGenerator we ran into a hardcoded
implementation of the Uberspect in Cocoon-2.1.4. The only way to get our own
implementation of the Uberspect up-and-running was to DIRTY hack the
JEXL-source.

Anyone ran into the same problems? Any better solutions?
I would apreciate any comments of the Jx/Jexl gurus out there.

Thanks
--
Danny

[PROPOSAL] extending JXTemplateGenerator

[Leszek Gawron]

Here are two new features I would like to try to implement if they were
accepted by cocoon developers:

1. implement jx:attribute (same functionality as xsl:attribute)
Try to implement a table with coloured rows and you'll know why it's needed -
as you cannot place a conditional attribute generation you will have to
duplicate the code for whole node.


2. implement a jx:outputxml helper which would provide functionality to
generate sax events directly from a string.
Example: http://marc.theaimsgroup.com/?t=10821296837&r=1&w=2&n=6
Chris has already provided me with a flow script but I think it would be good
to have it embedded directly in the JX language.

If there is a place for a built in number and date formatter there can be one
for xml output tag.

WDYT?
lg

-- 
__
 | /  \ |Leszek Gawron//  \\
\_\\  //_/   [EMAIL PROTECTED]   _\\()//_
 .'/()\'. Phone: +48(501)720812 / //  \\ \
  \\  //  recursive: adj; see recursive  | \__/ |

RE: Why does JXTemplateGenerator use FOM objects?

[Carsten Ziegeler]

Thanks!

Carsten 

> -Original Message-
> From: Christopher Oliver [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 01, 2004 5:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Why does JXTemplateGenerator use FOM objects?
> 
> 
> http://marc.theaimsgroup.com/?t=107083319900025&r=1&w=2
> 
> Carsten Ziegeler wrote:
> 
> >Just curious, I just noticed that the JXTemplateGenerator stores FOM 
> >objects in the context that can then be addressed by the 
> expressions, 
> >like this:
> >
> >cocoon.put("request",
> >   FOM_JavaScriptFlowHelper.getFOM_Request(objectModel));
> >
> >Why is this so?
> >
> >Carsten
> >
> >Carsten Ziegeler
> >Open Source Group, S&N AG
> >http://www.osoco.net/weblogs/rael/
> >
> >
> >  
> >
> 
> 

Re: Why does JXTemplateGenerator use FOM objects?

[Christopher Oliver]

http://marc.theaimsgroup.com/?t=107083319900025&r=1&w=2

Carsten Ziegeler wrote:

Just curious, I just noticed that the JXTemplateGenerator stores
FOM objects in the context that can then be addressed by the expressions,
like this:
cocoon.put("request",
  FOM_JavaScriptFlowHelper.getFOM_Request(objectModel));
Why is this so?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

 

Why does JXTemplateGenerator use FOM objects?

[Carsten Ziegeler]

Just curious, I just noticed that the JXTemplateGenerator stores
FOM objects in the context that can then be addressed by the expressions,
like this:

cocoon.put("request",
   FOM_JavaScriptFlowHelper.getFOM_Request(objectModel));

Why is this so?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

DO NOT REPLY [Bug 26086] - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26086>.
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=26086

[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-03-12 14:40 ---
It seems that this bug is invalid now as the code refered to has been 
removed/rewritten

DO NOT REPLY [Bug 26086] - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=26086>.
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=26086

[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator





--- Additional Comments From [EMAIL PROTECTED]  2004-03-08 19:58 ---
Chris, what about this bug and its very simple patch?

DO NOT REPLY [Bug 27133] New: - JxTemplateGenerator eats backslash-characters

[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=27133>.
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=27133

JxTemplateGenerator eats backslash-characters

   Summary: JxTemplateGenerator eats backslash-characters
   Product: Cocoon 2
   Version: 2.1.4
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When working with a combination of JxForms and JxTemplate (JxForm as the 
generator and JxTemplate as a transformer in the processing pipeline) I found 
out that values with backslash characters appears WITHOUT the backslash 
characters in the resulting XML Document. e.G: the original value 
d:\static\webs appears as d:staticwebs. 

I discoverd a problem in the code of parsing values in JxTemplateGenerator 
(Source from the latest 2.1.4 release):
Line 1270
Line 1502

My quick solution was to comment out the fragment which tests on backslash 
characters in the input stream. Now it works, but I'm not sure about side 
effects so far. Perhaps my hint is useful.

Re: JXTemplateGenerator and exceptions

[Christopher Oliver]

Can you provide an example stack trace? AFAIK JXTemplateGenerator wraps 
an  exception it catches in a SAXParseException. The original exception 
should still be available through SAXException.getException().

Upayavira wrote:

We've built a quite large set of Java objects that are handled by flow 
and then passed to JXTemplate for presentation. This all works fine, 
except when an exception occurs within our java objects. For some 
reason, the JXTemplate generator doesn't show or pass on the exception 
that occurred, showing instead its own exception.

If I have understood things right here, is it possible to change this 
behaviour to propogate Java exceptions out through the JXTemplate 
generator, so that debugging of the java objects can be made easier?

Regards, Upayavira

JXTemplateGenerator and exceptions

[Upayavira]

We've built a quite large set of Java objects that are handled by flow 
and then passed to JXTemplate for presentation. This all works fine, 
except when an exception occurs within our java objects. For some 
reason, the JXTemplate generator doesn't show or pass on the exception 
that occurred, showing instead its own exception.

If I have understood things right here, is it possible to change this 
behaviour to propogate Java exceptions out through the JXTemplate 
generator, so that debugging of the java objects can be made easier?

Regards, Upayavira

RE: JXTemplateGenerator / JX macro bug

[Oguz Kologlu]

Chris,

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

eg: 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:
>
>  
>
>
>Will be processed as:
>
>
>
>
>(NOTE: two seperate elements..)
>
>It would appear that:
>
>  widget.generateSaxFragment(cocoon.consumer, locale)
>
>in the macro is not outputing the  until
>after it has finished processing  which then
>results in the field being output as:
>
>
>
>instead of the required:
>
>
>Is there some workaround to this?
>
>Thanks,
>Oz
>
>
>See full macro below:
>targetNamespace="http://apache.org/cocoon/woody/template/1.0";>  name="id"/>  
>  
> 
>   
>   
>   
>   ${row.generateSaxFragment(cocoon.consumer, locale)}
>   
>   
> 
> 
>   ${widget.generateSaxFragment(cocoon.consumer, locale)}
>   
> 
>  
>
>
>
>  
>

Re: JXTemplateGenerator / JX macro bug

[Christopher Oliver]

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:

 

Will be processed as:



(NOTE: two seperate elements..)

It would appear that:

 widget.generateSaxFragment(cocoon.consumer, locale)

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


instead of the required:

Is there some workaround to this?

Thanks,
Oz
See full macro below:
http://apache.org/cocoon/woody/template/1.0";>
 

  
  
  
  ${row.generateSaxFragment(cocoon.consumer, locale)}
  
  


  ${widget.generateSaxFragment(cocoon.consumer, locale)}
  

 

 

RE: JXTemplateGenerator / JX macro bug

[Oguz Kologlu]

I've been doing some more testing.

I've created a macro for wt:stlying which outputs the 
styling information similar to the:
http://apache.org/cocoon/woody/template/1.0";>
macro.

I now have:

  


which _should_ output to the format:


  


but I still und up with:



It would appear that:
widget.generateSaxFragment(cocoon.consumer, locale)
(see below for full macro) is not actually processing the 
 macro...

Any ideas?
Oz


-Original Message-
From: Oguz Kologlu 
Sent: Friday, 16 January 2004 1:37 PM
To: [EMAIL PROTECTED]
Subject: JXTemplateGenerator / JX macro bug


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:

  


Will be processed as:




(NOTE: two seperate elements..)

It would appear that:

  widget.generateSaxFragment(cocoon.consumer, locale)

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



instead of the required:


Is there some workaround to this?

Thanks,
Oz


See full macro below:
http://apache.org/cocoon/woody/template/1.0";>
  
 
   
   
   
   ${row.generateSaxFragment(cocoon.consumer, locale)}
   
   
 
 
   ${widget.generateSaxFragment(cocoon.consumer, locale)}
   
 
  

JXTemplateGenerator / JX macro bug

[Oguz Kologlu]

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:

  


Will be processed as:




(NOTE: two seperate elements..)

It would appear that:

  widget.generateSaxFragment(cocoon.consumer, locale)

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



instead of the required:


Is there some workaround to this?

Thanks,
Oz


See full macro below:
http://apache.org/cocoon/woody/template/1.0";>
  
 
   
   
   
   ${row.generateSaxFragment(cocoon.consumer, locale)}
   
   
 
 
   ${widget.generateSaxFragment(cocoon.consumer, locale)}
   
 
  

DO NOT REPLY [Bug 26086] - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

[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=26086>.
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=26086

[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator





--- Additional Comments From [EMAIL PROTECTED]  2004-01-13 10:42 ---
The field I'm referring to in Description is "location"/"this.location" and not 
a "locator".

DO NOT REPLY [Bug 26086] - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

[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=26086>.
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=26086

[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator





--- Additional Comments From [EMAIL PROTECTED]  2004-01-13 10:19 ---
Created an attachment (id=9928)
Patch to JXTemplateGenerator.java

DO NOT REPLY [Bug 26086] New: - [PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

[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=26086>.
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=26086

[PATCH] Dereferencing null TextEvent() argument in JXTemplateGenerator

   Summary: [PATCH] Dereferencing null TextEvent() argument in
    JXTemplateGenerator
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Some pipelines containing jx transformer crash on NullPointerException:
org.apache.cocoon.ProcessingException: Failed to execute pipeline.: 
org.apache.cocoon.ProcessingException: Failed to execute pipeline.: 
java.lang.RuntimeException: java.lang.NullPointerException


There is a missing "this" in TextEvent constructor code, which results in 
dereferencing locator argument which may be null at that point (unlike 
this.locator field). The bug appears in certain piping combination (like piping 
some xsl transformations into jx transformer).

JxTemplateGenerator Problem

[Danny Bols]

Hello,

I am trying to integrate my own DynamicPropertyHandler into the
JxTemplateGenerator. It seems like JxPath doesn't activate the handler when
needed (I don't see any of my log messages added to the handler).

I registered the handler this way:
  JXPathIntrospector.registerDynamicClass(MyBean.class,
MyBeanPropertyHandler.class);

Checking the handler like this returns the expected handler:

JXPathIntrospector.getBeanInfo(MyBean.class).getDynamicPropertyHandlerClass(
)


What am I doing wrong???

--
Danny

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-07 11:54 ---
Please cross-check and set it to closed afterwards. Thanks!

Re: JXPath leniency in JXTemplateGenerator

[Sylvain Wallez]

Giacomo Pati wrote:

On Tue, 21 Oct 2003, Sylvain Wallez wrote:

 

Hi team,

I'd like to add the use of leniency to JXPath expressions in
JXTemplateGenerator: currently, if a path does not exist, a nice
exception is thrown. This may be good in some circumstances (avoids
endless hair pulling sessions to finally discover a small typo), but is
also required in some situations where the template writer _knows_ that
a path may not exist.
Here's what I want to do:
- add a global "lenient-xpath" sitemap parameter to the generator. This
allows to set a global leniency mode (default is false, meaning
exceptions are raised)
- set leniency always to true on test instructions ( and )
- add an optional "lenient" attribute to the  and 
statements (would default to the sitemap parameter value above).
What do you think?
   

+1

Done (still have to update the docs).

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: JXPath leniency in JXTemplateGenerator

[Reinhard Poetz]

From: Sylvain Wallez

> Hi team,
> 
> I'd like to add the use of leniency to JXPath expressions in 
> JXTemplateGenerator: currently, if a path does not exist, a nice 
> exception is thrown. This may be good in some circumstances (avoids 
> endless hair pulling sessions to finally discover a small 
> typo), but is 
> also required in some situations where the template writer 
> _knows_ that 
> a path may not exist.
> 
> Here's what I want to do:
> - add a global "lenient-xpath" sitemap parameter to the 
> generator. This 
> allows to set a global leniency mode (default is false, meaning 
> exceptions are raised)

+1

> - set leniency always to true on test instructions ( 
> and )

+1

> - add an optional "lenient" attribute to the  and 
> 
> statements (would default to the sitemap parameter value above).

+1

This avoids contructs like this, if "bla" can be null:


   
  
   


Reinhard

Re: JXPath leniency in JXTemplateGenerator

[Giacomo Pati]

On Tue, 21 Oct 2003, Sylvain Wallez wrote:

> Hi team,
>
> I'd like to add the use of leniency to JXPath expressions in
> JXTemplateGenerator: currently, if a path does not exist, a nice
> exception is thrown. This may be good in some circumstances (avoids
> endless hair pulling sessions to finally discover a small typo), but is
> also required in some situations where the template writer _knows_ that
> a path may not exist.
>
> Here's what I want to do:
> - add a global "lenient-xpath" sitemap parameter to the generator. This
> allows to set a global leniency mode (default is false, meaning
> exceptions are raised)
> - set leniency always to true on test instructions ( and )
> - add an optional "lenient" attribute to the  and 
> statements (would default to the sitemap parameter value above).
>
> What do you think?

+1

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

Re: JXPath leniency in JXTemplateGenerator

[Jeremy Quinn]

On Tuesday, October 21, 2003, at 03:33 PM, Sylvain Wallez wrote:

Hi team,

I'd like to add the use of leniency to JXPath expressions in 
JXTemplateGenerator: currently, if a path does not exist, a nice 
exception is thrown. This may be good in some circumstances (avoids 
endless hair pulling sessions to finally discover a small typo), but 
is also required in some situations where the template writer _knows_ 
that a path may not exist.

Here's what I want to do:
- add a global "lenient-xpath" sitemap parameter to the generator. 
This allows to set a global leniency mode (default is false, meaning 
exceptions are raised)
- set leniency always to true on test instructions ( and 
)
- add an optional "lenient" attribute to the  and  
statements (would default to the sitemap parameter value above).

What do you think?
+1

JXTemplate (which I like and use) always seems very touchy :)
Maybe it could log the times when it had to be lenient.
regards Jeremy

JXPath leniency in JXTemplateGenerator

[Sylvain Wallez]

Hi team,

I'd like to add the use of leniency to JXPath expressions in 
JXTemplateGenerator: currently, if a path does not exist, a nice 
exception is thrown. This may be good in some circumstances (avoids 
endless hair pulling sessions to finally discover a small typo), but is 
also required in some situations where the template writer _knows_ that 
a path may not exist.

Here's what I want to do:
- add a global "lenient-xpath" sitemap parameter to the generator. This 
allows to set a global leniency mode (default is false, meaning 
exceptions are raised)
- set leniency always to true on test instructions ( and )
- add an optional "lenient" attribute to the  and  
statements (would default to the sitemap parameter value above).

What do you think?

Sylvain

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

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively





--- Additional Comments From [EMAIL PROTECTED]  2003-10-07 02:35 ---
Created an attachment (id=8473)
tar.gz archive with individual patch files for JX(Template|Forms)Generator

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively





--- Additional Comments From [EMAIL PROTECTED]  2003-10-07 02:32 ---
Hmm, having a further look, I found that JXFormsGenerator uses the same pattern
and exhibits the same feature in the event loop.

Whilst my patch appeared to work for me, I also discovered the locator was
returning null values when I recorded the output with LogTransformer.

Will add another two patches for both JXFormsGenerator and JXTemplateGenerator
that initialize the LocatorFacade off the StartEvent's locator.

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively





--- Additional Comments From [EMAIL PROTECTED]  2003-10-06 00:34 ---
Thanks for your review Chris, I worked on a new patch, I hope it solves the
problem elegantly enough. I had an inkling that my original wasn't correct, just
didn't know better ;)

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively





--- Additional Comments From [EMAIL PROTECTED]  2003-10-06 00:23 ---
Created an attachment (id=8459)
[PATCH] Create facade for locator that is set once on the consumer before 
startDocument() as suggested

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively





--- Additional Comments From [EMAIL PROTECTED]  2003-10-04 05:23 ---
The attached patch is incorrect. Please don't apply it. A proper fix would be to
create a facade document locator that can be reset to point at the locator
associated with each event. This facade locator would be set once on the
XMLConsumer before startDocument().

DO NOT REPLY [Bug 23538] - [PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

[PATCH] JXTemplateGenerator calls setDocumentLocator() excessively

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|JXTemplateGenerator calls   |[PATCH] JXTemplateGenerator
   |setDocumentLocator()|calls setDocumentLocator()
   |excessively |excessively

DO NOT REPLY [Bug 23538] - JXTemplateGenerator calls setDocumentLocator() excessively

[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=23538>.
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=23538

JXTemplateGenerator calls setDocumentLocator() excessively





--- Additional Comments From [EMAIL PROTECTED]  2003-10-01 07:15 ---
Created an attachment (id=8417)
Proposed patch to invoke setDocumentLocator() once only per process