Re: JXTemplateGenerator: strange behaviour with jx:set
Oops, this is the email I should have said something about... this one
actually describes the problem better...
Can anyone actually give me a hand with this one? Even if it's just to
point me in the direction of a better list to post the request to...
Cheers,
Taryn
On Thu, 2004-10-07 at 16:45, Taryn East wrote:
Hi there.
While trawling through the web hoping to find a solution to a bug we've
found I discovered an email with the above subject line in the archives
of this list:
http://archives.real-time.com/mailman/listinfo/cocoon-users
relevant post:
http://archives.real-time.com/pipermail/cocoon-users/2004-May/051335.html
that list seems to still be active (judging by the ongoing additions to
the archive page) but I can't actually subscribe... however the content
of the emails looks identical to the content of this mailing list...
thus why I have joined here.
nyway, I was wondering if anyone here had a solution to the problem
given in the email above, as it seems to be occurring for me also.
Now, caveat here: I actually am not the person administering to our
version of cocoon - I am dealing only with the JXtemplates... so I get
to see the problem, but won't actually be the one implementing a fix...
also, I don't know many of the details about:
- the cocoon setup
- the flow and additional java stuff
as I'll be getting this info second=hand from the guy that does do this
stuff... and he's pretty buys etc...
The problem, as it appears to us, is that sometimes, when we pass a
JXPath node/text() through to some sort of attribute (eg action=x or
href= - note this is an attribute in the html of the template, and
even sometimes occurs in, say, jx:formatnumber num=x)
the JXtemplate just chucks a spak and doesn't give me a nice string, but
somehow treis to pass through an array of nodes...
which means that, when I have a close look at the source that has been
built) i get something along the lines of:
a href=javascript('[Lorg.w3c.dom.Node;@346762');click here/a
instead of something like:
a href=javascript('12345');click here/a
or, worse, I get an exception thrown such as:
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
file:/projects/appsroot/asic/screens/perextr.jx:820:54:java.lang.NumberFormatException:
For input string: [Lorg.w3c.dom.Node;@346762
cause: java.lang.NumberFormatException: For input string:
[Lorg.w3c.dom.Node;@346762
when I try to pass it through to something like formatnumber.
Now, stuff I've checked:
1. the XML that I'm parsing at this point only has one node on it, ie
it's something like: companyorgNum12345/orgNum.../company
there are no other orgNum tags at this level of the DOM
2. The JXPath expression uses the correct tag names etc and isn't at a
higher level (so it's not accidentally gathering a whole bunch of
orgNum's raethr than just the one it should).
3. The guy that does the java stuff is the person that said it was
getting a whole bunch of nodes instead of just one - not sure exactly
how he figured this out.
4. Said same guy hacked up a java function that will force this thing to
make a string, so if I apply the following hack to any given situation
it will always work fine:
jx:set var=onum value=#{./OrgNum/text()}/
acnconv acn=${domutils.string(onum)} /
note: acnconv just does a formatNumber on the given number...
5. It doesn't *always* break... we haven't yet figured out when/why it
does break because it happens so intermittently and there does not seem
ot be any distinguishing characteristic of the data that does break.
However, if a given set of XML breaks at some point, it always breaks.
ie, at least it's repeatable (if not deterministic).
I'm really at a loss here as I know so little about how all this works
so I can't even begin to go looking for a solution.
We're currently faced with the possibility of having to put the
aforementioned hack into *every* spot that JXPath is required to be used
in an attribute... which is not a pretty thought at all.
Any help would be *greatly* appreciated as I'd really like to actually
solve the problem, rather than have to perpetuate an ugly hack.
Cheers and thanks in advance,
Taryn
Role:
Junior Developer
Email:
[EMAIL PROTECTED]
Phone:
+61 2 9429 8901
Fax:
+61 2 9429 8999
Internet:
www.gxs.com.au
Confidential Communication:
This e-mail message and any attachments may contain copyright material
of GlobalX Information Services Pty Ltd (GIS) A.B.N. 00 073 436 414
and/or information that is confidential and subject to privilege. If you
are not the intended recipient of this e-mail, please contact GIS
immediately by return e-mail or by telephone on (612) 9429 8900. In this
case, you must not read, print, disseminate, copy, store or act in
reliance on this e-mail or any of the accompanying attachments; and
JXTemplateGenerator: strange behaviour with jx:set
Hi there.
While trawling through the web hoping to find a solution to a bug we've
found I discovered an email with the above subject line in the archives
of this list:
http://archives.real-time.com/mailman/listinfo/cocoon-users
relevant post:
http://archives.real-time.com/pipermail/cocoon-users/2004-May/051335.html
that list seems to still be active (judging by the ongoing additions to
the archive page) but I can't actually subscribe... however the content
of the emails looks identical to the content of this mailing list...
thus why I have joined here.
nyway, I was wondering if anyone here had a solution to the problem
given in the email above, as it seems to be occurring for me also.
Now, caveat here: I actually am not the person administering to our
version of cocoon - I am dealing only with the JXtemplates... so I get
to see the problem, but won't actually be the one implementing a fix...
also, I don't know many of the details about:
- the cocoon setup
- the flow and additional java stuff
as I'll be getting this info second=hand from the guy that does do this
stuff... and he's pretty buys etc...
The problem, as it appears to us, is that sometimes, when we pass a
JXPath node/text() through to some sort of attribute (eg action=x or
href= - note this is an attribute in the html of the template, and
even sometimes occurs in, say, jx:formatnumber num=x)
the JXtemplate just chucks a spak and doesn't give me a nice string, but
somehow treis to pass through an array of nodes...
which means that, when I have a close look at the source that has been
built) i get something along the lines of:
a href=javascript('[Lorg.w3c.dom.Node;@346762');click here/a
instead of something like:
a href=javascript('12345');click here/a
or, worse, I get an exception thrown such as:
org.apache.cocoon.ProcessingException: Failed to execute pipeline.:
file:/projects/appsroot/asic/screens/perextr.jx:820:54:java.lang.NumberFormatException:
For input string: [Lorg.w3c.dom.Node;@346762
cause: java.lang.NumberFormatException: For input string:
[Lorg.w3c.dom.Node;@346762
when I try to pass it through to something like formatnumber.
Now, stuff I've checked:
1. the XML that I'm parsing at this point only has one node on it, ie
it's something like: companyorgNum12345/orgNum.../company
there are no other orgNum tags at this level of the DOM
2. The JXPath expression uses the correct tag names etc and isn't at a
higher level (so it's not accidentally gathering a whole bunch of
orgNum's raethr than just the one it should).
3. The guy that does the java stuff is the person that said it was
getting a whole bunch of nodes instead of just one - not sure exactly
how he figured this out.
4. Said same guy hacked up a java function that will force this thing to
make a string, so if I apply the following hack to any given situation
it will always work fine:
jx:set var=onum value=#{./OrgNum/text()}/
acnconv acn=${domutils.string(onum)} /
note: acnconv just does a formatNumber on the given number...
5. It doesn't *always* break... we haven't yet figured out when/why it
does break because it happens so intermittently and there does not seem
ot be any distinguishing characteristic of the data that does break.
However, if a given set of XML breaks at some point, it always breaks.
ie, at least it's repeatable (if not deterministic).
I'm really at a loss here as I know so little about how all this works
so I can't even begin to go looking for a solution.
We're currently faced with the possibility of having to put the
aforementioned hack into *every* spot that JXPath is required to be used
in an attribute... which is not a pretty thought at all.
Any help would be *greatly* appreciated as I'd really like to actually
solve the problem, rather than have to perpetuate an ugly hack.
Cheers and thanks in advance,
Taryn
Role:
Junior Developer
Email:
[EMAIL PROTECTED]
Phone:
+61 2 9429 8901
Fax:
+61 2 9429 8999
Internet:
www.gxs.com.au
Confidential Communication:
This e-mail message and any attachments may contain copyright material
of GlobalX Information Services Pty Ltd (GIS) A.B.N. 00 073 436 414
and/or information that is confidential and subject to privilege. If you
are not the intended recipient of this e-mail, please contact GIS
immediately by return e-mail or by telephone on (612) 9429 8900. In this
case, you must not read, print, disseminate, copy, store or act in
reliance on this e-mail or any of the accompanying attachments; and you
must destroy all copies of this e-mail message. This notice should not
be removed.
Disclaimer:
GIS believes that the information contained in this document is accurate
when issued. However, e-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or contain viruses.
Therefore GIS does not warrant that such information is
JXTemplateGenerator: strange behaviour with jx:set
Hi,
I just found out that jx:set does not quite behave like I expected. Please consider
the following JXTemplate snippets:
!-- 1 --
element attr=${request.getAttribute('foo')}/
!-- 2 --
jx:set var=foo value=${request.getAttribute('foo')}/
element attr=${foo}/
1 and 2 should be equivalent, shouldn't they? Everything is fine as long as the
request attribute 'foo' is available. However, if this is not the case (i.e.
request.getAttribute('foo') evaluates to null) then the first snippet is transformed
into
element attr= /
while the latter is transformed into
element attr=[Lorg.w3c.dom.Node;@6e3dee /
Am I doing something wrong? Or is this a bug? I couldn't find anything about it in the
mail archives.
I could imagine that the JXTemplateGenerator uses an empty DOM-Node as some kind of
NullObject-Pattern. This would work inside xml element nodes (i.e.
element${foo}/element works fine in the second example), but would fail inside
attributes.
Any ideas?
Regards,
Jan Harms
P.S. I use cocoon 2.1.4.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
