From: Egon W. <eg...@sc...> - 2002-03-17 09:17:23
|
Bradley, is there still time for me to update the CML reading lib? I've got a patch available, so should not take much time... Unfortunately, I am on vacation next week... but will have time next weekend... Egon |
From: Bradley S. <br...@ba...> - 2002-03-17 20:26:01
|
Yes, there is still time. Please let us know when you have completed the work. Thanks, Bradley ----- Original Message ----- From: "Egon Willighagen" <eg...@sc...> To: <jmo...@li...> Sent: Sunday, March 17, 2002 1:17 AM Subject: [Jmol-developers] Latest CML reading lib in Jmol v2 > > Bradley, > > is there still time for me to update the CML reading lib? > I've got a patch available, so should not take much time... > Unfortunately, I am on vacation next week... but will have > time next weekend... > > Egon > > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > |
From: Egon W. <eg...@sc...> - 2002-03-24 08:15:10
|
On Sunday 17 March 2002 21:25, Bradley Smith wrote: > Yes, there is still time. Please let us know when you have completed the > work. CML reading should work fine now with the new CDK based CML reading library. Egon |
From: Egon W. <eg...@sc...> - 2002-03-24 09:29:14
|
I've commited the new libraries... the footprint went up, which is caused by newer XML and CML stuff... among which namespaces, etc... The cdk-cml lib is 31258 bytes. The XML parser (Aelfred2) is normally (including DOM e.g.) 231445 bytes. I can get this down to 119576 bytes, but probably not much smaller. With jmol-applet.jar this totals: 118070 + 119576 + 31258 = 268904 bytes = 263 kbytes. On a 56k6 modem this would take about a minute to download. Egon |
From: Egon W. <eg...@sc...> - 2002-04-03 09:14:38
|
On Sunday 24 March 2002 10:29, Egon Willighagen wrote: > I've commited the new libraries... the footprint went up, which is caused > by newer XML and CML stuff... among which namespaces, etc... > > The cdk-cml lib is 31258 bytes. The XML parser (Aelfred2) is normally > (including DOM e.g.) 231445 bytes. I can get this down to 119576 bytes, but > probably not much smaller. I got gnujaxp-saxonly down to 69620. With jmol-applet.jar this totals: 118070 + 69620 + 31258 = 223 kbytes. Smaller is hardly possibly... This would have to do. The CVS has been updated with these changes. regards, Egon |
From: Bradley S. <br...@ba...> - 2002-04-04 06:29:06
|
Now the jars directory is confusing. The directory contains both gnujaxp.jar and gnujaxp-saxonly.jar, and the aelfred.jar and sax.jar still exist. What jars are needed for reading CML? What jars are needed for distributing the application and what jars are needed for the applet? What jars can be removed? Thanks, Bradley ----- Original Message ----- From: "Egon Willighagen" <eg...@sc...> To: "Bradley Smith" <br...@ba...>; <jmo...@li...> Sent: Wednesday, April 03, 2002 3:13 AM Subject: Re: [Jmol-developers] Latest CML reading lib in Jmol v2 > On Sunday 24 March 2002 10:29, Egon Willighagen wrote: > > I've commited the new libraries... the footprint went up, which is caused > > by newer XML and CML stuff... among which namespaces, etc... > > > > The cdk-cml lib is 31258 bytes. The XML parser (Aelfred2) is normally > > (including DOM e.g.) 231445 bytes. I can get this down to 119576 bytes, but > > probably not much smaller. > > I got gnujaxp-saxonly down to 69620. With jmol-applet.jar this totals: > > 118070 + 69620 + 31258 = 223 kbytes. > > Smaller is hardly possibly... This would have to do. > The CVS has been updated with these changes. > > regards, > > Egon > > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > |
From: E.L. W. <eg...@sc...> - 2002-04-04 10:48:00
|
On Thursday 04 April 2002 08:29, Bradley Smith wrote: > Now the jars directory is confusing. The directory contains both > gnujaxp.jar and gnujaxp-saxonly.jar, and the aelfred.jar and sax.jar still > exist. What jars are needed for reading CML? What jars are needed for > distributing the application and what jars are needed for the applet? What > jars can be removed? I thought I had sax.jar and aelfred.jar removed. They should be. gnujaxp.jar is needed for Jmol, the Application, while gnujaxp-saxonly.jar (the smallar one) is used for the applet. I was working on a tutorial on how to use CML in applets... Shall I continue? Egon |
From: Bradley S. <br...@ba...> - 2002-04-04 15:08:01
|
> I thought I had sax.jar and aelfred.jar removed. They should be. > gnujaxp.jar is needed for Jmol, the Application, while gnujaxp-saxonly.jar > (the smallar one) is used for the applet. The sax.jar and aelfred.jar have not been removed. Thanks for clearing up which jars are for what. > I was working on a tutorial on how to use CML in applets... Shall I continue? Yes, please do. More documentation is always welcome. Thanks, Bradley |
From: Bradley S. <br...@ba...> - 2002-04-04 07:03:34
|
Is CML reading working for applets? I receive the following exception. java.net.MalformedURLException: no protocol: cml.dtd at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at java.net.URL.<init>(Unknown Source) at gnu.xml.aelfred2.SAXDriver.absolutize(SAXDriver.java:608) at gnu.xml.aelfred2.SAXDriver.resolveEntity(SAXDriver.java:585) at gnu.xml.aelfred2.XmlParser.pushURL(XmlParser.java:3336) at gnu.xml.aelfred2.XmlParser.parseDoctypedecl(XmlParser.java:845) at gnu.xml.aelfred2.XmlParser.parseProlog(XmlParser.java:522) at gnu.xml.aelfred2.XmlParser.parseDocument(XmlParser.java:414) at gnu.xml.aelfred2.XmlParser.doParse(XmlParser.java:167) at gnu.xml.aelfred2.SAXDriver.parse(SAXDriver.java:320) at org.openscience.jmol.CMLReader.read(CMLReader.java:132) at org.openscience.jmol.applet.JmolApplet.init(JmolApplet.java:178) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) I am using the Java Plugin version 1.3.1_02. Thanks, Bradley |
From: E.L. W. <eg...@sc...> - 2002-04-04 10:50:51
|
On Thursday 04 April 2002 09:03, Bradley Smith wrote: > Is CML reading working for applets? I receive the following exception. > > java.net.MalformedURLException: no protocol: cml.dtd > at java.net.URL.<init>(Unknown Source) > at java.net.URL.<init>(Unknown Source) > at java.net.URL.<init>(Unknown Source) > at gnu.xml.aelfred2.SAXDriver.absolutize(SAXDriver.java:608) > at gnu.xml.aelfred2.SAXDriver.resolveEntity(SAXDriver.java:585) > at gnu.xml.aelfred2.XmlParser.pushURL(XmlParser.java:3336) > at gnu.xml.aelfred2.XmlParser.parseDoctypedecl(XmlParser.java:845) > at gnu.xml.aelfred2.XmlParser.parseProlog(XmlParser.java:522) > at gnu.xml.aelfred2.XmlParser.parseDocument(XmlParser.java:414) > at gnu.xml.aelfred2.XmlParser.doParse(XmlParser.java:167) > at gnu.xml.aelfred2.SAXDriver.parse(SAXDriver.java:320) > at org.openscience.jmol.CMLReader.read(CMLReader.java:132) > at org.openscience.jmol.applet.JmolApplet.init(JmolApplet.java:178) > at sun.applet.AppletPanel.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) Did you update today? This should no longer happen with the applet version as of my patch yesterday. (For me it did not...) Egon |
From: Bradley S. <br...@ba...> - 2002-04-04 15:11:00
|
> Did you update today? This should no longer happen with the applet > version as of my patch yesterday. (For me it did not...) Yes, I have updated, but it still happens. The CML file I am using is the Jmol/samples/methanol1.cml. Thanks, Bradley |
From: Bradley S. <br...@ba...> - 2002-04-04 07:07:11
|
Why does reading a CML cause error and debug messages to display in the Jmol console? These are a few of the messages. Activated validation INFO: instantiated INFO: Start XML Doc DEBUG: CMLResolver: resolving null, file:/H:/programming/sourceforge/Jmol/samples/cml.dtd ERROR: ** warning: URI was not reported to parser for entity [dtd] ERROR: URI = file:/H:/programming/sourceforge/Jmol/samples/methanol1.cml ERROR: line = 2 ERROR: ** warning: missing system ID, using cml.dtd ERROR: URI = null ERROR: line = 2 DEBUG: startElement: molecule DEBUG: uri: Thanks, Bradley |
From: E.L. W. <eg...@sc...> - 2002-04-04 10:49:21
|
On Thursday 04 April 2002 09:07, Bradley Smith wrote: > Why does reading a CML cause error and debug messages to display in the > Jmol console? These are a few of the messages. > > Activated validation > INFO: instantiated > INFO: Start XML Doc > DEBUG: CMLResolver: resolving null, > file:/H:/programming/sourceforge/Jmol/samples/cml.dtd > ERROR: ** warning: URI was not reported to parser for entity [dtd] > ERROR: URI = > file:/H:/programming/sourceforge/Jmol/samples/methanol1.cml ERROR: line > = 2 > ERROR: ** warning: missing system ID, using cml.dtd > ERROR: URI = null > ERROR: line = 2 > DEBUG: startElement: molecule > DEBUG: uri: A few? There are quite a lot... I am about to write a patch to remove this... Standard, this information is put to System.out, but for Jmol this is redirected to the Jmol Console... Egon |
From: E.L. W. <eg...@sc...> - 2002-04-04 13:36:02
|
On Thursday 04 April 2002 12:49, E.L. Willighagen wrote: > On Thursday 04 April 2002 09:07, Bradley Smith wrote: > > Why does reading a CML cause error and debug messages to display in the > > Jmol console? These are a few of the messages. > > > > Activated validation > > INFO: instantiated > > INFO: Start XML Doc > > DEBUG: CMLResolver: resolving null, > > file:/H:/programming/sourceforge/Jmol/samples/cml.dtd > > ERROR: ** warning: URI was not reported to parser for entity [dtd] > > ERROR: URI = > > file:/H:/programming/sourceforge/Jmol/samples/methanol1.cml ERROR: > > line = 2 > > ERROR: ** warning: missing system ID, using cml.dtd > > ERROR: URI = null > > ERROR: line = 2 > > DEBUG: startElement: molecule > > DEBUG: uri: > > A few? There are quite a lot... I am about to write a patch to remove > this... Standard, this information is put to System.out, but for Jmol this > is redirected to the Jmol Console... I have commited a new cdk-cml.jar that does not give this much debug output. Egon |
From: Bradley S. <br...@ba...> - 2002-04-04 15:14:24
|
> I have commited a new cdk-cml.jar that does not give this much debug output. The Jmol application now gives a NullPointerException when I try to read samples/methanol1.cml. The new jar seems to have a problem. Thanks, Bradley |
From: Egon W. <eg...@sc...> - 2002-04-04 19:01:10
|
On Thursday 4 April 2002 17:14, Bradley Smith wrote: > > I have commited a new cdk-cml.jar that does not give this much debug > > output. > > The Jmol application now gives a NullPointerException when I try to read > samples/methanol1.cml. The new jar seems to have a problem. Indeed. That seems to be the case... I will look into that saturday and make sure to add all Jmol files to the test files in the CML io JUnit tests in CDK. Egon |
From: Egon W. <eg...@sc...> - 2002-04-04 19:38:53
|
On Thursday 4 April 2002 17:14, Bradley Smith wrote: > > I have commited a new cdk-cml.jar that does not give this much debug > > output. > > The Jmol application now gives a NullPointerException when I try to read > samples/methanol1.cml. The new jar seems to have a problem. The actual problem was in Jmol itself, i.e. the interface to Jmol's classes. It turned out that the JmolCDO did not handle the objects properly, which was up til now unnoticed, due to a bug in cdk-cml.jar which was fixed last week. Did not try the methanol files with Jmol. (To not make this mistake again, these two files are added to CDK regression tests for the CML reading library) Egon PS. I know it is not saturday yet, but the fix was rather easy... :) |
From: E.L. W. <eg...@sc...> - 2002-04-05 11:43:05
|
On Thursday 04 April 2002 09:03, Bradley Smith wrote: > Is CML reading working for applets? I did some final tuning today and the CML reading is working perfectly for applets now. I've finished the document on how to put CML on you webpage and it can be found at http://www-sigma.sci.kun.nl/Persoonlijk/egonw/cml/jmol/. Bradley, I assume you will adapt the layout and put it online at jmol.sf.net? > I receive the following exception. > java.net.MalformedURLException: no protocol: cml.dtd Yes, indeed. The problem originates from the GNU XML parser (gnujaxp.jar) which requires SYSTEM identifiers to have a proper URL, thus with protocol://. This can be said afterwards, which I do in the application, but with the applet this is not possible. Thus, the CML file should either include the protocol (see webpage above) or should not have a <!DOCTYPE> line. Egon |
From: Bradley S. <br...@ba...> - 2002-04-06 22:22:32
|
Using Netscape Communicator 4.77 on Linux, the applet produces the following exception when reading CML. java.lang.ClassNotFoundException: org.apache.log4j.Category at netscape.applet.AppletClassLoader.findClass(AppletClassLoader.java:821) at netscape.applet.AppletClassLoader.loadClass1(AppletClassLoader.java:688) at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java:652) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:338) at org.openscience.cdk.tools.LoggingTool.<init>(LoggingTool.java:40) at org.openscience.cdk.io.cml.CMLHandler.<init>(CMLHandler.java:40) at org.openscience.jmol.CMLReader.read(CMLReader.java:125) at org.openscience.jmol.applet.JmolApplet.init(JmolApplet.java:177) * at netscape.applet.DerivedAppletFrame$InitAppletEvent.dispatch(DerivedAppletFra me.java:553) at java.awt.EventDispatchThread$EventPump.dispatchEvents(EventDispatchThread.ja va:81) at java.awt.EventDispatchThread.run(EventDispatchThread.java:135) at netscape.applet.DerivedAppletFrame$AppletEventDispatchThread.run(DerivedAppl etFrame.java:911) Is log4j also required to use the cdk-cml.jar? Thanks, Bradley |
From: Egon W. <eg...@sc...> - 2002-04-07 05:23:25
|
On Sunday 7 April 2002 00:22, Bradley Smith wrote: > Using Netscape Communicator 4.77 on Linux, the applet produces the > following exception when reading CML. > > Is log4j also required to use the cdk-cml.jar? Nope, the LoggingTool catches these ClassNotFoundException now, but only since last friday... but since the jars were not added with "-kb" (see other emails), you might not have the correct cdk-cml.jar... Egon |
From: Bradley S. <br...@ba...> - 2002-04-07 06:35:06
|
> Nope, the LoggingTool catches these ClassNotFoundException now, but only > since last friday... but since the jars were not added with "-kb" (see other > emails), you might not have the correct cdk-cml.jar... That must have fixed it. After updating the jar, the problem has disappeared. Thanks, Bradley |
From: Bradley S. <br...@ba...> - 2002-04-05 18:37:04
|
> I did some final tuning today and the CML reading is working perfectly for > applets now. I've finished the document on how to put CML on you webpage > and it can be found at > http://www-sigma.sci.kun.nl/Persoonlijk/egonw/cml/jmol/. > > Bradley, I assume you will adapt the layout and put it online at jmol.sf.net? Yes, I will integrate it with the rest of the web site. Thanks. > Yes, indeed. The problem originates from the GNU XML parser (gnujaxp.jar) > which requires SYSTEM identifiers to have a proper URL, thus with > protocol://. This can be said afterwards, which I do in the application, but > with the applet this is not possible. > > Thus, the CML file should either include the protocol (see webpage above) or > should not have a <!DOCTYPE> line. I think it is improper to require the user to change a correct DOCTYPE to a local URL in order to read CML files with the applet. A nonvalidating parser should not care what the DOCTYPE declares, and should not try to resolve it. I would call this a bug in the gnujaxp parser. Luckily, I was able to find a workaround by creating a new entity resolver. For the details, please see src/org/openscience/jmol/CMLResolver.java. It should now read CML files with any correct DOCTYPE. Thanks, Bradley |
From: Peter Murray-R. <pm...@ca...> - 2002-04-07 13:50:45
|
At 10:37 05/04/2002 -0800, Bradley Smith wrote: > > I did some final tuning today and the CML reading is working perfectly for > > applets now. I've finished the document on how to put CML on you webpage > > and it can be found at > > http://www-sigma.sci.kun.nl/Persoonlijk/egonw/cml/jmol/. > > > > Bradley, I assume you will adapt the layout and put it online at >jmol.sf.net? > >Yes, I will integrate it with the rest of the web site. Thanks. > > > > Yes, indeed. The problem originates from the GNU XML parser (gnujaxp.jar) > > which requires SYSTEM identifiers to have a proper URL, thus with > > protocol://. This can be said afterwards, which I do in the application, >but > > with the applet this is not possible. > > > > Thus, the CML file should either include the protocol (see webpage above) >or > > should not have a <!DOCTYPE> line. > >I think it is improper to require the user to change a correct DOCTYPE to a >local URL in order to read CML files with the applet. A nonvalidating parser >should not care what the DOCTYPE declares, and should not try to resolve it. >I would call this a bug in the gnujaxp parser. Luckily, I was able to find a >workaround by creating a new entity resolver. For the details, please see >src/org/openscience/jmol/CMLResolver.java. It should now read CML files with >any correct DOCTYPE. I find the DOCTYPE very annoying. For example if I use the Saxon XSLT processor and there is a DOCTYPE with a web-based URL (e.g. http://www.some.where/my.dtd) it will hang while it looks for a web connection. It is probably a good idea always to put <?xml version="1.0" standalone="yes"?> which ought to make it clear that the application does not need to read the DTD. I do not know whether parsers honour this or not, but it can't hurt. Part of the problem is that there is no mechanism for validating a document from *outside* - the DTD has to be internal. In CML V2 which is Schema-based we shall require a namespace, but we shan't require a DTD. If people wish to validate it they can apply the schema from outside the document. Also, of course, documents with multiple namespaces are unlikely to validate against a a single DTD so it is IMO obsolete. P. P. >Thanks, > Bradley > > > >_______________________________________________ >Jmol-developers mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-developers -- Peter Murray-Rust, pm286 AT cam.ac.uk Unilever Centre for Molecular Informatics, Chemistry Department Lensfield Road, Cambridge, CB2 1EW, UK +44-1223-336-432 |
From: Egon W. <eg...@sc...> - 2002-04-06 09:41:21
|
On Friday 5 April 2002 20:37, Bradley Smith wrote: > > Yes, indeed. The problem originates from the GNU XML parser (gnujaxp.jar) > > which requires SYSTEM identifiers to have a proper URL, thus with > > protocol://. This can be said afterwards, which I do in the application, > > but > > > with the applet this is not possible. > > > > Thus, the CML file should either include the protocol (see webpage above) > > or > > > should not have a <!DOCTYPE> line. > > I think it is improper to require the user to change a correct DOCTYPE to a > local URL in order to read CML files with the applet. A nonvalidating > parser should not care what the DOCTYPE declares, and should not try to > resolve it. I would call this a bug in the gnujaxp parser. Agreed, that sounds logical, in practice it does however... > Luckily, I was > able to find a workaround by creating a new entity resolver. For the > details, please see src/org/openscience/jmol/CMLResolver.java. It should > now read CML files with any correct DOCTYPE. There is such one already in cdk-cml.jar... and it was actually used as well... And the DTDs are in that jar as well... Do you think it is necessary to have Jmol have it's own CML DTDs and resolver? Egon |
From: Bradley S. <br...@ba...> - 2002-04-06 17:43:30
|
> > I think it is improper to require the user to change a correct DOCTYPE to a > > local URL in order to read CML files with the applet. A nonvalidating > > parser should not care what the DOCTYPE declares, and should not try to > > resolve it. I would call this a bug in the gnujaxp parser. > > Agreed, that sounds logical, in practice it does however... However what? > > Luckily, I was > > able to find a workaround by creating a new entity resolver. For the > > details, please see src/org/openscience/jmol/CMLResolver.java. It should > > now read CML files with any correct DOCTYPE. > > There is such one already in cdk-cml.jar... and it was actually used as > well... And the DTDs are in that jar as well... Do you think it is necessary > to have Jmol have it's own CML DTDs and resolver? It is necessary. As documented in src/org/openscience/jmol/CMLResolver.java: /** * This class provides access to the CML DTDs by resolving the system id of a * DOCTYPE declaration to a local resource. Since an applet can only access the * its server, the DTD must be found within the applet resources. * * <p>This class implements the EntityResolver2 rather than the EntityResolver * because of problems in the gnujaxp XML library currently used * (gnujaxp-1.0beta1). If the EntityResolver interface is used, the parser will * try to "absolutize" the system id URI before trying to resolve it. For system * ids which are not full URIs, this causes an exception from which no recovery * is possible. * </p> */ Bradley |