You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Taryn East <ta...@globalx.com.au> on 2004/10/07 08:45:42 UTC
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.
aaaanyway, 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: <company><orgNum>12345</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:
taryn.east@globalx.com.au
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 accurate,
reliable, complete or up to date, and, to the fullest extent permitted
by law, disclaims all liability of GIS and its Associates for any loss
or damage suffered by any person by reason of the use by that person of,
or their reliance on, any information contained in this document or any
error or defect in this document, whether arising from the negligence of
GIS or its Associates or otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: No replies?
Posted by Ralph Goers <Ra...@dslextreme.com>.
I'm not sure if this addresses your exact problem, but it might.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29381
Since this patch was recently applied you would need to get the latest
from CVS to try it.
If it doesn't fix the problem, I would suggest you then post your
question on the developer's list. Finally, you should file a bug report.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
No replies?
Posted by Taryn East <ta...@globalx.com.au>.
Hi everyone, I'm a little saddened by the fact that my emails have gone
completely ignored by you all... is it possible to get some help... or
even a response?
I know my emails are getting through as I receive a copy of them from
the list... but it would be nice if someone at least replied...
Cheers,
Taryn
On Wed, 2004-10-13 at 11:06, Taryn East wrote:
> Hi all, I don't seem to have received a reply to this posting. Is my
> email coming through ok?
>
> Is anyone able to point me at a place to start looking for a solution?
>
> 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.
> >
> > aaaanyway, 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: <company><orgNum>12345</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:
> taryn.east@globalx.com.au
> 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 accurate,
> reliable, complete or up to date, and, to the fullest extent permitted
> by law, disclaims all liability of GIS and its Associates for any loss
> or damage suffered by any person by reason of the use by that person of,
> or their reliance on, any information contained in this document or any
> error or defect in this document, whether arising from the negligence of
> GIS or its Associates or otherwise.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
________________________
Role:
Junior Developer
Email:
taryn.east@globalx.com.au
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 accurate,
reliable, complete or up to date, and, to the fullest extent permitted
by law, disclaims all liability of GIS and its Associates for any loss
or damage suffered by any person by reason of the use by that person of,
or their reliance on, any information contained in this document or any
error or defect in this document, whether arising from the negligence of
GIS or its Associates or otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXTemplateGenerator: strange behaviour with jx:set
Posted by Taryn East <ta...@globalx.com.au>.
Hi all, I don't seem to have received a reply to this posting. Is my
email coming through ok?
Is anyone able to point me at a place to start looking for a solution?
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.
>
> aaaanyway, 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: <company><orgNum>12345</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:
taryn.east@globalx.com.au
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 accurate,
reliable, complete or up to date, and, to the fullest extent permitted
by law, disclaims all liability of GIS and its Associates for any loss
or damage suffered by any person by reason of the use by that person of,
or their reliance on, any information contained in this document or any
error or defect in this document, whether arising from the negligence of
GIS or its Associates or otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JXTemplateGenerator: strange behaviour with jx:set
Posted by Taryn East <ta...@globalx.com.au>.
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.
>
> aaaanyway, 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: <company><orgNum>12345</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:
> taryn.east@globalx.com.au
> 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 accurate,
> reliable, complete or up to date, and, to the fullest extent permitted
> by law, disclaims all liability of GIS and its Associates for any loss
> or damage suffered by any person by reason of the use by that person of,
> or their reliance on, any information contained in this document or any
> error or defect in this document, whether arising from the negligence of
> GIS or its Associates or otherwise.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
________________________
Role:
Junior Developer
Email:
taryn.east@globalx.com.au
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 accurate,
reliable, complete or up to date, and, to the fullest extent permitted
by law, disclaims all liability of GIS and its Associates for any loss
or damage suffered by any person by reason of the use by that person of,
or their reliance on, any information contained in this document or any
error or defect in this document, whether arising from the negligence of
GIS or its Associates or otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org