jlabbe-processia / mxupdate

Automatically exported from code.google.com/p/mxupdate
1 stars 1 forks source link

Special character BELL (hex 07) prevents program export. #173

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. export V6R2013x OOTB program jpo.materialscompliance.PartBase
   exec program MxUpdate --export --path "C:/tmp" --program jpo.materialscompliance.PartBase;

What is the expected output? What do you see instead?
   - program export done properly
   - getting 'An invalid XML character' error

What version of the product are you using? On what operating system?
   Enovia V6R2013x.GA
   MxUpdate Update Deployment Tool V0.10.0 (with latest revision 855 and some extra...)

Please provide any additional information below.
   - import functionality works as needed with the same special character

Original issue reported on code.google.com by yrtti...@gmail.com on 12 Feb 2013 at 7:00

Attachments:

GoogleCodeExporter commented 8 years ago
There are no challenges due to this after FP1332.
Can be closed.

Original comment by yrtti...@gmail.com on 17 Aug 2013 at 5:37

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
This is still an issue in R2013x.FP1337 and MxUpdate 0.90.0 from github, up to 
commit e74fdb7e2e.

export jpo program 'emxTaskBase'
org.xml.sax.SAXParseException; lineNumber: 13123; columnNumber: 67; An invalid 
XML character (Unicode: 0x7) was found in the CDATA section.
    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1236)
    at org.mxupdate.update.AbstractAdminObject_mxJPOffe0636e01000000de.parse(AbstractAdminObject_mxJPOffe0636e01000000de.java:307)
    at org.mxupdate.update.AbstractObject_mxJPOffe0e53901000000aa.export(AbstractObject_mxJPOffe0e53901000000aa.java:179)
    at MxUpdate_mxJPOdaf00d1b01000000c4.export(MxUpdate_mxJPOdaf00d1b01000000c4.java:591)
    at MxUpdate_mxJPOdaf00d1b01000000c4.mxMain(MxUpdate_mxJPOdaf00d1b01000000c4.java:446)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at matrix.db.JPOSupport.invokeObject(JPOSupport.java:161)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at com.dassault_systemes.platform.ipmodeling.jni.EnoviaKernelUtils._invoke(EnoviaKernelUtils.java:54)
    at com.dassault_systemes.platform.ipmodeling.jni.EnoviaKernelUtils.invoke(EnoviaKernelUtils.java:35)
    at com.dassault_systemes.platform.ipmodeling.jni.EnoviaKernelUtils.invokeObject(EnoviaKernelUtils.java:129)

There's a number of BELs around those lines

Original comment by lar...@gmail.com on 7 Nov 2013 at 3:13

GoogleCodeExporter commented 8 years ago
In R2013x.FP1340 it's also emxMBOMPartBase containing BELs and thus being 
broken. Now with 0.90.0 final release.

Original comment by lar...@gmail.com on 6 Dec 2013 at 7:40

GoogleCodeExporter commented 8 years ago

Original comment by tim.mox...@innobix.com on 7 Feb 2014 at 8:31