No TypeHolder generated in -srconly

• Key: XMLBEANS-120
• Type: Bug
• Status: Resolved
• Resolution: Won't Fix
• Priority: Minor
• Assignee: Unassigned
• Reporter: Don Stewart
• Component/s: Compiler
• Affects Version/s: Version 2 Beta 2
• Fix Version/s: Version 2.1

Description

If youcreate a -srconly output no TypeHolder class is generated. If you try to edit the source files in an IDE they all point to a missing class and as such the IDE's report errors in every generated Interface.

Comments

[Johannes Stamminger]

Without -srconly there is created a .jar but the sourcecode written to disk is cannot be the one having been compiled as the generated interfaces contain references to not existing classes like ...schema.system.s88336473178149A1091FEBD8E40E9E6C.TypeSystemHolder that do not exist - and therefore are not compilable (though the corresponding .class file is found within the generated .jar).

I'll attach the schema (XTCE OMG spec.) I observe the problems with (1.0.4 generates working sourcecode).

[Johannes Stamminger]

XTCE 1.0 OMG specification (http://www.omg.org/cgi-bin/apps/do_doc?dtc/03-09-02.pdf) 2.0.1-beta1 does not create valid sourcecode for

[Radu Preotiuc-Pietro]

Johannes, I have no problems building that Schema file.
I have become convinced that this is an Eclipse-only issue because it can't pick up dependencies from a different directory than the source. I am going to fix this by removing that compile-time dependency, but in order to do this I need some APIs that don't currently exist, so I was going to wait on it a bit.

[Robin Sander]

With the actual 2.0 release I get the same effect even without -srconly! No TypeSystemHolder.java is generated, which causes IDEs like
Eclipse to complain. You can reproduce it simply by compiling one of the sample schemas:
 cd xmlbeans-2.0.0/schemas
  ../bin/scomp -src src -d out easypo.xsd
  find src -name '*TypeSystemHolder*.java'

... and nothing is found!

[Charles Blaxland]

I've just tried upgrading to 2.0, and I'm getting the same problem. I'm compiling with -srconly, and I get a TypeSystemHolder.class generated, but no TypeSystemHolder.java! This is not just an Eclipse issue - the TypeSystemHolder.java files seems to be simply not generated.

[Johannes Stamminger]

I just retested with 2.0 final version: definitely the sourcecode being generated is not compilable as it misses the TypeSystemHolder.java _SOURCECODE_.
 
 Not with 2.0-beta1, nor with 2.0 final.
 Not with '-scronly=true' nor without!!
 
 This is definitely no IDE problem (btw: I'm using IntelliJ, not Eclipse).
 
 Note: the xmlbeans-generated .jar contains a TypeSystemHolder.class file.
 
 The annoying thing is: when creating the .jar with xmlbeans itself (only way working so far) I do not have full control about javac options used.
 
 And IMHO this is no minor bug when creating not compilable sourcecode, please re-consider this.

[Charles Blaxland]

If anyone's intersted, I managed to make Eclipse happy without the TypeSystemHolder source by adding the output directory (where the TypeSystemHolder.class files get generated) to the project "Libraries" in the Java Build Path for the project. I also made my maven build work by manually copying the TypeSystemHolder.class files up to the target directory in a java:compile pregoal:

<preGoal name="java:compile">
<attainGoal name="generate-xmlbeans"/>
<ant:copy todir="${maven.build.dest}">
<ant:fileset dir="${xmlbeans.output.dir}">
<include name="**/*.class"/>
</ant:fileset>
</ant:copy>
</preGoal>

[Lawrence Jones]

Fixed with checkin 220181. Now refer to TypeSystemHolder via a reflection API instead of directly.

[Johannes Stamminger]

I just tried this thing ... and it still does not work for me: I created src files with ant task:

        <xmlbean schema="${schema.corbaobject}"
                 srcgendir="${src.corbaobject.dir}"
                 fork="false"
                 srconly="true"
                 typesystemname="net.eads.space.systemaccess.corba.corbaobject"/>

And when compiling the sourcecode in another task this one still complains of TypeSystemHolder not existing:

    [javac] Compiling 28 source files to /home/jstammi/Perforce2/systemaccess/main/build/classes/corbaobject
    [javac] /home/jstammi/Perforce2/systemaccess/main/src/generated/corbaobject/net/eads/space/systemaccess/corba/corbaobject/Address.java:18: package schemaorg_apache_xmlbeans.system.net.eads.space.systemaccess.corba.corbaobject.TypeSystemHolder does not exist


Please re-open this issue (I cannot do so; or do you prefer a new one?)

[Johannes Stamminger]

BTW: it is another schema but the attached one. On interest I might add that one, too.

[Don Stewart]

Reopened at the request of

Johannes Stamminger commented on XMLBEANS-120:
----------------------------------------------

I just tried this thing ... and it still does not work for me: I created src files with ant task:

        <xmlbean schema="${schema.corbaobject}"
                 srcgendir="${src.corbaobject.dir}"
                 fork="false"
                 srconly="true"
                 typesystemname="net.eads.space.systemaccess.corba.corbaobject"/>

And when compiling the sourcecode in another task this one still complains of TypeSystemHolder not existing:

    [javac] Compiling 28 source files to /home/jstammi/Perforce2/systemaccess/main/build/classes/corbaobject
    [javac] /home/jstammi/Perforce2/systemaccess/main/src/generated/corbaobject/net/eads/space/systemaccess/corba/corbaobject/Address.java:18: package schemaorg_apache_xmlbeans.system.net.eads.space.systemaccess.corba.corbaobject.TypeSystemHolder does not exist


Please re-open this issue (I cannot do so; or do you prefer a new one?)

[Radu Preotiuc-Pietro]

Can you please give me more details, like maybe paste the generated file?
I have looked at the code one more time and we have changed the line that used to output the static reference to TypeSystemHolder, definitely. I just can't understrand how this can happen... have you checked that you run at least XmlBeans 2.1.0 and you don't have any "stale" source files in ant?

[Johannes Stamminger]

My fault: I cannot reproduce after holidays. I guess I missed to replace somewhere in our build system the 2.0.0 version. Sorry for that!

[Johannes Stamminger]

OK, generation and compilation of the generated sourcecode now seems to work. But usage fails:

Exception in thread "main" java.lang.ExceptionInInitializerError
        at net.eads.space.systemaccess.corba.corbaobject.CORBAObjectDocument$Factory.newInstance(CORBAObjectDocume
        at net.eads.space.systemaccess.corba.jacorb.XMLObjectInfo.createXML(XMLObjectInfo.java:73)
        at net.eads.space.systemaccess.app.IORParser.<init>(IORParser.java:39)
        at net.eads.space.systemaccess.app.IORParser.main(IORParser.java:52)
Caused by: java.lang.RuntimeException: Cannot load SchemaTypeSystem. Unable to load class with name schemaorg_apac.corbaobject.TypeSystemHolder. Make sure the generated binary files are on the classpath.
        at org.apache.xmlbeans.XmlBeans.typeSystemForClassLoader(XmlBeans.java:783)
        at net.eads.space.systemaccess.corba.corbaobject.CORBAObjectDocument.<clinit>(CORBAObjectDocument.java:19)
        ... 4 more
Caused by: java.lang.ClassNotFoundException: schemaorg_apache_xmlbeans.system.net.eads.space.systemaccess.corba.co
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at org.apache.xmlbeans.XmlBeans.typeSystemForClassLoader(XmlBeans.java:769)
        ... 5 more



Sourcecode created with 2.2.0 and ant task

        <xmlbean schema="${schema.corbaobject}"
                 srcgendir="${src.corbaobject.dir}"
                 source="1.5"
                 javasource="1.5"
                 fork="false"
                 srconly="true"
                 verbose="false"
                 typesystemname="net.eads.space.systemaccess.corba.corbaobject"/>

[Radu Preotiuc-Pietro]

Johannes,
The TypeSystemHolder class is still required at run-time. It contains information about the Schema<->Java relationship (name mappings etc) that is not available elsewhere. You need to make sure that you have the .jar containing this class and all the generated .xsb classes on the classpath at runtime (look for these classes in the directory that you specify as "classgendir" in ant.

This issue merely asked that this dependency be only a run-time one (rather than both compiletime and runtime) so that IDEs can show the generated classes without having to re-load their classpath every time the files get re-generated. And this seems to be fixed.

[Johannes Stamminger]

Would it be possible to get sourcecode for
a) TypeSystemHolder
b) .xsb "classes"?

[Radu Preotiuc-Pietro]

Actually, no, there is no source code for those.

[Johannes Stamminger]

OK, I ask a different way: is it worth it to request those sourcecodes generation. Or is it too complex or not possible?

[Wing Yew Poon]

Note: While TypeSystemHolder.class is a java class file, the .xsb files are not. They are simply binary files. There is no "source" for them.

[Radu Preotiuc-Pietro]

As Wing Yew said, the .xsb files are not compiled Java code, so we can't generate sources for them.