You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by Chris <ch...@hmgcc.gsi.gov.uk> on 2007/11/28 10:43:13 UTC
StackOverflowError when validating long patterns in Windows Java
1.6.0_03
I have come across a repeatable error and enclose the test case.
When the following xml is validated with a ValidatingStreamReader it
causes an SOE.
If the sample string is shorter, this does not happen. With more complex
schemas, the string does not have to be as long to still cause an SOE.
I have not yet determined whether the complexity of the pattern is a factor.
Increasing the size of the stack using "java -Xss64M" does prevent this
issue.
This only happens in Windows, Linux does not have this behaviour. This
does not happen on any platform in java 5.
Note there were changes in java6 to the way stack sizes are implemented.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316197
I'm not sure if this is really a bug in xmlbeans since it does work on
other platforms... is there any reason why it would use more stack space
on windows? Is the default stack size different on windows and linux?
Thanks for your help
See stack trace below:
org.apache.xmlbeans.impl.regex.RangeToken.match(line 481)
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1673)
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
...
--
Chris
HMGCC
The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.
This information may be exempt from disclosure under Freedom Of Information
Act 2000 and may be subject to exemption under other UK information
legislation. Refer disclosure requests to the Information Officer.
The original of this email was scanned for viruses by the Government Secure Intranet Anti-Virus service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
RE: StackOverflowError when validating long patterns in Windows Java
1.6.0_03
Posted by Schalk Neethling <Sc...@momentum.co.za>.
Hi there Chris and Jacob,
I have run into a similar problem while using XMLBeans along side the
BIRT engine. I am using Java 5 on a Windows machine.
I discovered that it was a find and replace String task inside the BIRT
engine that was trying to determine whether a specific line in a
document was a comment or not.
I am therefore also certain that it is not and XMLBeans problem but more
then likely a JVM/Java problem.
Regards,
Schalk
-----Original Message-----
From: Chris [mailto:chrishe@hmgcc.gsi.gov.uk]
Sent: 29 November 2007 01:44 PM
To: dev@xmlbeans.apache.org
Cc: xmlbeans-dev@xml.apache.org
Subject: Re: StackOverflowError when validating long patterns in Windows
Java 1.6.0_03
I can, although I'm now pretty convinced it's not an XML Beans issue.
The fact is the default stack size must be smaller for 32bit jse6, and
long, complex patterns require a lot of stack.
Jacob Danner wrote:
> Hi Chris,
> Thanks for finding an investigating an issue like this.
> Can I get you to file a jira issue to track this?
> Thanks,
> -jacobd
>
> On Nov 28, 2007 2:20 AM, Chris < chrishe@hmgcc.gsi.gov.uk
> <ma...@hmgcc.gsi.gov.uk>> wrote:
>
> After looking further into this issue, in java6 the default stack
size
> is not different between Linux and Windows but between 32bit and
64bit
> implementations. This explains a lot as we're using 64bit linux.
> I can't find what the default stack sizes were in java5 though. I
> guess
> I'll just have to add a -Xss parameter to my application although
this
> doesn't fill me with confidence,
> "Options that begin with -X are non-standard (not guaranteed to be
> supported on all VM implementations), and are subject to change
without
> notice in subsequent releases of the JDK." -
> http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
>
> Chris wrote:
> > I have come across a repeatable error and enclose the test
case.
> > When the following xml is validated with a
ValidatingStreamReader it
> > causes an SOE.
> > If the sample string is shorter, this does not happen. With
more
> complex
> > schemas, the string does not have to be as long to still cause
an
> SOE.
> > I have not yet determined whether the complexity of the pattern
is a
> > factor.
> > Increasing the size of the stack using "java -Xss64M" does
> prevent this
> > issue.
> >
> > This only happens in Windows, Linux does not have this
behaviour.
> This
> > does not happen on any platform in java 5.
> >
> > Note there were changes in java6 to the way stack sizes are
> implemented.
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316197
> >
> > I'm not sure if this is really a bug in xmlbeans since it does
> work on
> > other platforms... is there any reason why it would use more
> stack space
> > on windows? Is the default stack size different on windows and
linux?
> >
> > Thanks for your help
> >
> > See stack trace below:
> > org.apache.xmlbeans.impl.regex.RangeToken.match(line 481)
> >
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1673)
> >
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1872)
> >
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1872)
> >
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString
> (line 1872)
> > ...
> >
> >
> >
>
------------------------------------------------------------------------
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
> > For additional commands, e-mail: dev-help@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
>
> --
> Chris
> HMGCC
>
> The information contained in this message (and any attachments)
may
> be confidential and is intended for the sole use of the named
addressee.
> Access, copying, alteration or re-use of the e-mail by anyone
other
> than the intended recipient is unauthorised. If you are not the
intended
> recipient please advise the sender immediately by returning the
e-mail
> and deleting it from your system.
>
> This information may be exempt from disclosure under Freedom Of
> Information
> Act 2000 and may be subject to exemption under other UK
information
> legislation. Refer disclosure requests to the Information Officer.
>
>
> The original of this email was scanned for viruses by the
Government
> Secure Intranet Anti-Virus service supplied by Cable&Wireless in
> partnership with MessageLabs. (CCTM Certificate Number
> 2006/04/0007.) On leaving the GSi this email was certified virus
free.
> Communications via the GSi may be automatically logged, monitored
> and/or recorded for legal purposes.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
>
>
>
> This email was received from the INTERNET and scanned by the
Government
> Secure Intranet Anti-Virus service supplied by Cable&Wireless in
> partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.)
In
> case of problems, please call your organisation's IT Helpdesk.
> Communications via the GSi may be automatically logged, monitored
and/or
> recorded for legal purposes.
--
Chris
HMGCC
The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.
This information may be exempt from disclosure under Freedom Of
Information
Act 2000 and may be subject to exemption under other UK information
legislation. Refer disclosure requests to the Information Officer.
The original of this email was scanned for viruses by the Government
Secure Intranet Anti-Virus service supplied by Cable&Wireless in
partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) On
leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or
recorded for legal purposes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
This email and all content are subject to the following disclaimer:
http://content.momentum.co.za/content/legal/disclaimer_email.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
Re: StackOverflowError when validating long patterns in Windows Java
1.6.0_03
Posted by Chris <ch...@hmgcc.gsi.gov.uk>.
I can, although I'm now pretty convinced it's not an XML Beans issue.
The fact is the default stack size must be smaller for 32bit jse6, and
long, complex patterns require a lot of stack.
Jacob Danner wrote:
> Hi Chris,
> Thanks for finding an investigating an issue like this.
> Can I get you to file a jira issue to track this?
> Thanks,
> -jacobd
>
> On Nov 28, 2007 2:20 AM, Chris < chrishe@hmgcc.gsi.gov.uk
> <ma...@hmgcc.gsi.gov.uk>> wrote:
>
> After looking further into this issue, in java6 the default stack size
> is not different between Linux and Windows but between 32bit and 64bit
> implementations. This explains a lot as we're using 64bit linux.
> I can't find what the default stack sizes were in java5 though. I
> guess
> I'll just have to add a -Xss parameter to my application although this
> doesn't fill me with confidence,
> "Options that begin with -X are non-standard (not guaranteed to be
> supported on all VM implementations), and are subject to change without
> notice in subsequent releases of the JDK." -
> http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
>
> Chris wrote:
> > I have come across a repeatable error and enclose the test case.
> > When the following xml is validated with a ValidatingStreamReader it
> > causes an SOE.
> > If the sample string is shorter, this does not happen. With more
> complex
> > schemas, the string does not have to be as long to still cause an
> SOE.
> > I have not yet determined whether the complexity of the pattern is a
> > factor.
> > Increasing the size of the stack using "java -Xss64M" does
> prevent this
> > issue.
> >
> > This only happens in Windows, Linux does not have this behaviour.
> This
> > does not happen on any platform in java 5.
> >
> > Note there were changes in java6 to the way stack sizes are
> implemented.
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316197
> >
> > I'm not sure if this is really a bug in xmlbeans since it does
> work on
> > other platforms... is there any reason why it would use more
> stack space
> > on windows? Is the default stack size different on windows and linux?
> >
> > Thanks for your help
> >
> > See stack trace below:
> > org.apache.xmlbeans.impl.regex.RangeToken.match(line 481)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1673)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line
> 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString
> (line 1872)
> > ...
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
> > For additional commands, e-mail: dev-help@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
>
> --
> Chris
> HMGCC
>
> The information contained in this message (and any attachments) may
> be confidential and is intended for the sole use of the named addressee.
> Access, copying, alteration or re-use of the e-mail by anyone other
> than the intended recipient is unauthorised. If you are not the intended
> recipient please advise the sender immediately by returning the e-mail
> and deleting it from your system.
>
> This information may be exempt from disclosure under Freedom Of
> Information
> Act 2000 and may be subject to exemption under other UK information
> legislation. Refer disclosure requests to the Information Officer.
>
>
> The original of this email was scanned for viruses by the Government
> Secure Intranet Anti-Virus service supplied by Cable&Wireless in
> partnership with MessageLabs. (CCTM Certificate Number
> 2006/04/0007.) On leaving the GSi this email was certified virus free.
> Communications via the GSi may be automatically logged, monitored
> and/or recorded for legal purposes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
> <ma...@xmlbeans.apache.org>
>
>
>
> This email was received from the INTERNET and scanned by the Government
> Secure Intranet Anti-Virus service supplied by Cable&Wireless in
> partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) In
> case of problems, please call your organisation’s IT Helpdesk.
> Communications via the GSi may be automatically logged, monitored and/or
> recorded for legal purposes.
--
Chris
HMGCC
The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.
This information may be exempt from disclosure under Freedom Of Information
Act 2000 and may be subject to exemption under other UK information
legislation. Refer disclosure requests to the Information Officer.
The original of this email was scanned for viruses by the Government Secure Intranet Anti-Virus service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org
RE: StackOverflowError when validating long patterns in Windows Java 1.6.0_03
Posted by Radu Preotiuc-Pietro <ra...@bea.com>.
Chris,
>From my experience, any Java project once it gets complex starts having
to use some -X option (and all JVMs support them), so I wouldn't be too
worried about that.
Radu
________________________________
From: Jacob Danner [mailto:jacob.danner@gmail.com]
Sent: Wednesday, November 28, 2007 7:58 AM
To: dev@xmlbeans.apache.org
Cc: xmlbeans-dev@xml.apache.org
Subject: Re: StackOverflowError when validating long patterns in
Windows Java 1.6.0_03
Hi Chris,
Thanks for finding an investigating an issue like this.
Can I get you to file a jira issue to track this?
Thanks,
-jacobd
On Nov 28, 2007 2:20 AM, Chris < chrishe@hmgcc.gsi.gov.uk
<ma...@hmgcc.gsi.gov.uk> > wrote:
After looking further into this issue, in java6 the
default stack size
is not different between Linux and Windows but between
32bit and 64bit
implementations. This explains a lot as we're using
64bit linux.
I can't find what the default stack sizes were in java5
though. I guess
I'll just have to add a -Xss parameter to my application
although this
doesn't fill me with confidence,
"Options that begin with -X are non-standard (not
guaranteed to be
supported on all VM implementations), and are subject to
change without
notice in subsequent releases of the JDK." -
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
Chris wrote:
> I have come across a repeatable error and enclose the
test case.
> When the following xml is validated with a
ValidatingStreamReader it
> causes an SOE.
> If the sample string is shorter, this does not happen.
With more complex
> schemas, the string does not have to be as long to
still cause an SOE.
> I have not yet determined whether the complexity of
the pattern is a
> factor.
> Increasing the size of the stack using "java -Xss64M"
does prevent this
> issue.
>
> This only happens in Windows, Linux does not have this
behaviour. This
> does not happen on any platform in java 5.
>
> Note there were changes in java6 to the way stack
sizes are implemented.
>
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316197
>
> I'm not sure if this is really a bug in xmlbeans since
it does work on
> other platforms... is there any reason why it would
use more stack space
> on windows? Is the default stack size different on
windows and linux?
>
> Thanks for your help
>
> See stack trace below:
> org.apache.xmlbeans.impl.regex.RangeToken.match(line
481)
>
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1673)
>
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
>
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
>
org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
>
org.apache.xmlbeans.impl.regex.RegularExpression.matchString (line 1872)
> ...
>
>
>
------------------------------------------------------------------------
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail:
dev-help@xmlbeans.apache.org
--
Chris
HMGCC
The information contained in this message (and any
attachments) may
be confidential and is intended for the sole use of the
named addressee.
Access, copying, alteration or re-use of the e-mail by
anyone other
than the intended recipient is unauthorised. If you are
not the intended
recipient please advise the sender immediately by
returning the e-mail
and deleting it from your system.
This information may be exempt from disclosure under
Freedom Of Information
Act 2000 and may be subject to exemption under other UK
information
legislation. Refer disclosure requests to the
Information Officer.
The original of this email was scanned for viruses by
the Government Secure Intranet Anti-Virus service supplied by
Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number
2006/04/0007.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged,
monitored and/or recorded for legal purposes.
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail:
dev-help@xmlbeans.apache.org
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: StackOverflowError when validating long patterns in Windows Java 1.6.0_03
Posted by Jacob Danner <ja...@gmail.com>.
Hi Chris,
Thanks for finding an investigating an issue like this.
Can I get you to file a jira issue to track this?
Thanks,
-jacobd
On Nov 28, 2007 2:20 AM, Chris <ch...@hmgcc.gsi.gov.uk> wrote:
> After looking further into this issue, in java6 the default stack size
> is not different between Linux and Windows but between 32bit and 64bit
> implementations. This explains a lot as we're using 64bit linux.
> I can't find what the default stack sizes were in java5 though. I guess
> I'll just have to add a -Xss parameter to my application although this
> doesn't fill me with confidence,
> "Options that begin with -X are non-standard (not guaranteed to be
> supported on all VM implementations), and are subject to change without
> notice in subsequent releases of the JDK." -
> http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
>
> Chris wrote:
> > I have come across a repeatable error and enclose the test case.
> > When the following xml is validated with a ValidatingStreamReader it
> > causes an SOE.
> > If the sample string is shorter, this does not happen. With more complex
> > schemas, the string does not have to be as long to still cause an SOE.
> > I have not yet determined whether the complexity of the pattern is a
> > factor.
> > Increasing the size of the stack using "java -Xss64M" does prevent this
> > issue.
> >
> > This only happens in Windows, Linux does not have this behaviour. This
> > does not happen on any platform in java 5.
> >
> > Note there were changes in java6 to the way stack sizes are implemented.
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316197
> >
> > I'm not sure if this is really a bug in xmlbeans since it does work on
> > other platforms... is there any reason why it would use more stack space
> > on windows? Is the default stack size different on windows and linux?
> >
> > Thanks for your help
> >
> > See stack trace below:
> > org.apache.xmlbeans.impl.regex.RangeToken.match(line 481)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1673)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> > org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> > ...
> >
> >
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> > For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
> --
> Chris
> HMGCC
>
> The information contained in this message (and any attachments) may
> be confidential and is intended for the sole use of the named addressee.
> Access, copying, alteration or re-use of the e-mail by anyone other
> than the intended recipient is unauthorised. If you are not the intended
> recipient please advise the sender immediately by returning the e-mail
> and deleting it from your system.
>
> This information may be exempt from disclosure under Freedom Of
> Information
> Act 2000 and may be subject to exemption under other UK information
> legislation. Refer disclosure requests to the Information Officer.
>
>
> The original of this email was scanned for viruses by the Government
> Secure Intranet Anti-Virus service supplied by Cable&Wireless in partnership
> with MessageLabs. (CCTM Certificate Number 2006/04/0007.) On leaving the GSi
> this email was certified virus free.
> Communications via the GSi may be automatically logged, monitored and/or
> recorded for legal purposes.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
>
>
Re: StackOverflowError when validating long patterns in Windows Java
1.6.0_03
Posted by Chris <ch...@hmgcc.gsi.gov.uk>.
After looking further into this issue, in java6 the default stack size
is not different between Linux and Windows but between 32bit and 64bit
implementations. This explains a lot as we're using 64bit linux.
I can't find what the default stack sizes were in java5 though. I guess
I'll just have to add a -Xss parameter to my application although this
doesn't fill me with confidence,
"Options that begin with -X are non-standard (not guaranteed to be
supported on all VM implementations), and are subject to change without
notice in subsequent releases of the JDK." -
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
Chris wrote:
> I have come across a repeatable error and enclose the test case.
> When the following xml is validated with a ValidatingStreamReader it
> causes an SOE.
> If the sample string is shorter, this does not happen. With more complex
> schemas, the string does not have to be as long to still cause an SOE.
> I have not yet determined whether the complexity of the pattern is a
> factor.
> Increasing the size of the stack using "java -Xss64M" does prevent this
> issue.
>
> This only happens in Windows, Linux does not have this behaviour. This
> does not happen on any platform in java 5.
>
> Note there were changes in java6 to the way stack sizes are implemented.
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6316197
>
> I'm not sure if this is really a bug in xmlbeans since it does work on
> other platforms... is there any reason why it would use more stack space
> on windows? Is the default stack size different on windows and linux?
>
> Thanks for your help
>
> See stack trace below:
> org.apache.xmlbeans.impl.regex.RangeToken.match(line 481)
> org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1673)
> org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> org.apache.xmlbeans.impl.regex.RegularExpression.matchString(line 1872)
> ...
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
> For additional commands, e-mail: dev-help@xmlbeans.apache.org
--
Chris
HMGCC
The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.
This information may be exempt from disclosure under Freedom Of Information
Act 2000 and may be subject to exemption under other UK information
legislation. Refer disclosure requests to the Information Officer.
The original of this email was scanned for viruses by the Government Secure Intranet Anti-Virus service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org