[x3d-public] X3DObjectUtil for X3DJSAIL

John Carlson yottzumm at gmail.com
Fri Jun 2 03:14:53 PDT 2017


As an example of the problem I’m having when compiling with Dragome, I include this exception.

Here is my main code:
                        ConfigurationProperties.setXsltEngine(ConfigurationProperties.XSLT_ENGINE_nativeJava);
                        X3DObject exampleObject = new abox().getX3dModel();
                        String validationResults = exampleObject.validationReport();
                        label.setValue(helloWorldService.getGreetingsFor(validationResults));

I will check in my changes for you to look into.  I think the problem may be with xmlvm’s XSLT stylesheet.  Hmm.

Dragome compiles bytecode to JavaScript and I am including saxon in the classpath.

Not quite sure what the issue is at this point.  Will investigate xmlvm.  I may not have the latest release.

John

Compiling classes: .............................................................................................................Exception in thread "Thread-15" java.lang.IncompatibleClassChangeError: Implementing class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:427)
        at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:389)
        at org.xmlvm.plugins.javascript.XsltRunner.runXSLT(XsltRunner.java:98)
        at org.xmlvm.plugins.javascript.XsltRunner.runXSLT(XsltRunner.java:69)
        at org.xmlvm.ClassToJs.transformFile(ClassToJs.java:57)
        at org.xmlvm.ClassToJs.transformClassFileToJs(ClassToJs.java:72)
        at com.dragome.compiler.type.TypeResolver.compile(TypeResolver.java:96)
        at com.dragome.compiler.type.TypeResolver.visit(TypeResolver.java:44)
        at com.dragome.compiler.Project.visitSuperTypes(Project.java:286)
        at com.dragome.compiler.Project.resolve(Project.java:464)
        at com.dragome.compiler.writer.Assembly.resolveNoTainting(Assembly.java:338)
        at com.dragome.compiler.DragomeJsCompiler.execute(DragomeJsCompiler.java:276)
        at com.dragome.compiler.DragomeJsCompiler.compile(DragomeJsCompiler.java:190)
        at com.dragome.helpers.serverside.DragomeCompilerLauncher.compileWithMainClass(DragomeCompilerLauncher.java:44)
        at com.dragome.serverside.compile.watchers.WatchDir.compile(WatchDir.java:261)
        at com.dragome.serverside.compile.watchers.WatchDir.main(WatchDir.java:247)
        at com.dragome.serverside.servlets.CompilerServlet$1.run(CompilerServlet.java:83)

Sent from Mail for Windows 10

From: Don Brutzman
Sent: Friday, June 2, 2017 2:11 AM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: X3DObjectUtil for X3DJSAIL

Am trying to think this through.

All of the subclass/superclass relationships in X3DJSAIL are related to the X3D Abstract Spec and SAI relationships.  Am reluctant to change something so fundamental into variable, it no longer seems clear.

Integration of a variety of other capabilities is expected in the future?

Why is it hard to include a .jar when you are doing development?  Because of compilation of the other codebases is trying to include them in the 'transpilation' ??

Possibly we could include a switch in the autogeneration XSLT that avoided (or commented out, or substituted) certain code in the output.

Thanks for further explanations to help understand what precise problem/goal we are dealing with.


On 6/1/2017 10:22 PM, John Carlson wrote:
> You could call the superclass X3DObjectBase.java perhaps.  A true service provider interface (SPI) to XSLT would be better though, I believe (not sure).
> 
> John
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Friday, June 2, 2017 12:21 AM
> *To: *Don Brutzman <mailto:brutzman at nps.edu>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
> *Subject: *RE: X3DObjectUtil for X3DJSAIL
> 
> Additionally, if I comment out the import and change the name of the exception, I get the attached errors.
> 
> It doesn’t work without XSLT/Saxon.  I would like to make the dependency optional, perhaps in a separate extension, or better SPI interface, so I can replace Saxon with something else if I want to.  For example, I may want to plug in my javaSerializer, JavaScriptSerializer or PythonSerializer once converted to JavaScript (replacing to the toFile* methods).
> 
> I think the least invasive change is to move everything but the stylesheet stuff to a superclass.
> 
> John
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
> *From: *Don Brutzman <mailto:brutzman at nps.edu>
> *Sent: *Thursday, June 1, 2017 11:39 PM
> *To: *John Carlson <mailto:yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
> *Subject: *Re: X3DObjectUtil for X3DJSAIL
> 
> The x3djsail.classes.jar only has X3DJSAIL classes and stylesheets, not Saxon... in fact, not finding Saxon in the full.jar either
> 
>                  http://www.web3d.org/specifications/java/X3DJSAIL.html#Downloads
> 
>                  X3DJSAIL.3.3.classes.jar (~8MB)
> 
>                  http://www.web3d.org/specifications/java/jars/X3DJSAIL.3.3.classes.jar
> 
>                  X3DJSAIL.3.3.full.jar source, documentation, etc. (~24MB)
> 
>                  http://www.web3d.org/specifications/java/jars/X3DJSAIL.3.3.full.jar
> 
> If you try to invoke Saxon without classpath, you get some sort of "class not found" exception.
> 
> We could make the code a bit smarter to give an informed exception "Saxon not available, cannot apply XSLT stylesheet transformation" instead, acting more gracefully.
> 
> Anyway that is fine tuning.  You should be good to go without saxon already.
> 
> p.s. G'day mate!  8)
> 
> On 5/31/2017 4:26 PM, John Carlson wrote:
> 
>  > What we could do is subclass X3DObject and put all XSLT/Saxon related stuff in there...probably too late now.   Sorry I didn't mention it sooner.   Or we could superclass X3DObject and move all non-XSLT/Saxon stuff up.   Basically, I'd like to create a distribution without Saxon.
> 
>  >
> 
>  > Thanks!
> 
>  >
> 
>  > John
> 
>  >
> 
>  > John
> 
>  >
> 
>  > On May 29, 2017 11:41 AM, "John Carlson" <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
> 
>  >
> 
>  >     I am just trying to think what to do before release, and Saxon is a big stumbling block for jsweet.
> 
>  >
> 
>  >     John
> 
>  >
> 
>  >     On May 29, 2017 1:39 AM, "Don Brutzman" <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
> 
>  >
> 
>  >         On 5/28/2017 8:02 PM, John Carlson wrote:
> 
>  >
> 
>  >             I wonder if It would be good to create an X3DObjectUtil.java and put the conversions in there.
> 
>  >
> 
>  >
> 
>  >         There is a utility class called org.web3d.x3d.jsail.ConfigurationProperties that collects a number of capabilities.
> 
>  >
> 
>  >         http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/ConfigurationProperties.html <http://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/jsail/ConfigurationProperties.html>
> 
>  >
> 
>  >                  "Concrete class that enables developers to set custom configuration properties when using X3D Java SAI Library (X3DJSAIL). Output serialization support is provided for indentation, X3D Canonicalization (C14N) and showing default attributes. TODO more to follow!"
> 
>  >
> 
>  >             That way we can deploy X3DObject.java with just the XML output and not the stylesheet(s).
> 
>  >
> 
>  >
> 
>  >         New methods handleArguments and validationReport were put in X3DObject because they would tend to be used there.
> 
>  >
> 
>  >         Will thinking about splitting off a separate utilities class if needed at some point.  So far am getting good traction by figuring out when/where functionality is needed and positioning it appropriately.
> 
>  >
> 
>  >             That would make it easier to deploy to a browser, and browsers can offer alternate implementations of X3DObjectUtil.
> 
>  >
> 
>  >
> 
>  >         Not sure there are any impediments or blockers at this point?
> 
>  >
> 
>  >         Not sure how many HTML browsers support Java, and existing X3D players with Java support tend to have their own concrete classes.  (Xj3D has three actually, can be pretty confusing.)
> 
>  >
> 
>  >         I've tried to keep X3DJSAIL as consistent as possible with X3D Java SAI, which is pretty old.  Suggested changes for future specification work are collected at
> 
>  >
> 
>  >         http://www.web3d.org/specifications/java/X3DJSAIL.html#SpecificationChanges <http://www.web3d.org/specifications/java/X3DJSAIL.html#SpecificationChanges>
> 
>  >
> 
>  >         http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt <http://www.web3d.org/specifications/java/X3dJavaSpecificationChangesAndIssues.txt>
> 
>  >
> 
>  >             Let me know what you think.   I think it’s a good idea to be able to not be totally reliant on the stylesheets.  Plus we can put other Utils there.
> 
>  >
> 
>  >
> 
>  >         Other implementation is always welcome.  I'll keep adjusting the stylesheets and checking results.
> 
>  >
> 
>  >         Before working on duplicative functionality, it would be good to work on things that are needed.  STL/PLY comes to mind, also X3D Projects Wish List.
> 
>  >
> 
>  >         http://www.web3d.org/projects/wish-list <http://www.web3d.org/projects/wish-list>
> 
>  >
> 
>  >         For your patches, I'd like to keep iterating on representative content problems and adapting/integrating those corrections directly into the X3DJSAIL code autogeneration.
> 
>  >
> 
>  >         Other utilities also welcome in this open-source asset.  X3DJSAIL wish list is found at
> 
>  >
> 
>  >         http://www.web3d.org/specifications/java/X3DJSAIL.html#TODO <http://www.web3d.org/specifications/java/X3DJSAIL.html#TODO>
> 
>  >
> 
>  >         Future libraries will include Efficient XML Interchange (EXI) compression (OpenEXI and EXIficient), XML encryption and signature, X3D Canonicalization (C14N), etc. etc.  It would be good to apply jgeom.jar for NURBS too.
> 
>  >
> 
>  >         all the best, Don
> 
>  >         --
> 
>  >         Don Brutzman  Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
> 
>  >         Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 <tel:%2B1.831.656.2149>
> 
>  >         X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman>
> 
>  >
> 
> all the best, Don
> 
> -- 
> 
> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
> 
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> 
> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
> 


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170602/9ce6772b/attachment-0001.html>


More information about the x3d-public mailing list