Posted: Wed Dec 08, 2010 4:46 pmPost subject: applet.getMol in MarvinSketch 5.4
we're working on upgrading to MarvinSketch 5.4 and I've found a pretty severe problem in the applet that I wanted to report. We use MarvinSketch as part of an educational app, and we've always used the getMol function to pull out the students' responses. We also use this function when our question coders generate keys for these types of questions (we give them a page with a MarvinSketch applet and an 'export button', which calls applet.getMol('mrv'), then places the results in a text box for them to copy/paste). It has always worked well.
Now, for the problem. In MarvinSketch 5.4, getMol only returns a value up to a certain number of atoms (3). If you have any more than that, getMol no longer returns anything but an empty string.
1. Place three carbon atoms on the MarvinSketch canvas and call getMol('mrv'). This yields the normal xml one would expect.
2. Add one more carbon atom (increasing the count to 4) and call getMol('mrv'). This yields an empty string.
3. Delete the fourth carbon atom and call getMol('mrv'). The normal xml structure is returned again.
I can consistenly replicate this - any more than three atoms (not counting implicit hydrogens), and getMol returns nothing. Please let me know if you can replicate this issue and if/when a fix will be implemented. For now, we're probably going to have to hold off on upgrading until this issue can be addressed.
István ChemAxon personnel
Joined: 03 Dec 2007
I have tried that, and i cannot reproduce the issue, in this case this is maybe a configuration related issue, and then i will need more information, either the whole html page where you are embedding the applet, could be useful or at least the part where the applet is embedded. Is this issue browser or java specific on your side?
I tried on the example, and I can't replicate the problem there. The odd thing is, our implementation did not change - upgrading to 5.4 causes the problem, reverting back to 5.3.8 fixes it. So there must be something about the configuration that is not acceptable to Marvin 5.4? Here is the html source of the page with the problem ....
<input type="button" name="getKey" value="Get Key" onClick="getMarvinVal('mrv')" />
<!--<br /><strong>cxsmarts: </strong><input type="text" size="40" id="cxflags" />
<input type="button" name="getCX" value="Get CXSMARTS" onClick="getCxSmarts()" />-->
<td width="100%" valign="top"><p><b>Instructions for Mechanism Questions</b><br />
Grading of mechanism questions is sensitive due to the way that Marvin
generates its XML representation (known as MRV). When creating a template/key
combination for a mechanism question, it is important to follow these
<li>Draw the template FIRST. Export MRV, copy/paste and save somewhere. Use
that for your $MARVIN_START value.</li>
<li>Modify the template as necessary to make it the key, i.e. 'answer'
it as if you were a student. Export MRV, copy/paste and use for your answer
key. It is important that you not move any of the template's structures
while doing so.</li>
<p>If you need to edit these after the fact, be sure to copy in the MRV you
originally generated, or you may have to repeat both steps. You can paste
MRV directly into Marvin by copying it your clipboard, right-clicking anywhere
in Marvin and selecting 'paste'.<br />
<td valign="bottom"><textarea name="mol" id="mol" rows="13" cols="50"></textarea></td>
Also, the original bug reported occurs in Firefox 3.6.1/OSX 10.6
I started checking some othere browsers, and I get wildly varying results.
In Safari 5.0.3/OSX 10.6, attempting to call getMol at all yields the following Java errors:
Oddly enough, in Chrome 8.0.552.215 on OSX 10.6, it works just fine. I will go test this in various Windows browsers and report back to you.
I have set up a link for you to view where you can see these bugs in action and perhaps tell us what's going on. Let me reiterate that backing up to Marvin 5.3.8 eliminates all problems. I will post the results of Windows testing shortly.
May be onto a clue here. You'll note that in the test page I gave you, there is a dropdown at the bottom which allows you to select different chemical modes. Picking one of these causes the applet parameters to change appropriately (you can view source to see this, or if you like I can post all of the parameters here). So, in chrome, if one picks 'Lewis' mode, everything works fine - if one switched to 'condensed' mode, getMol doesn't work at all ... empty string returnedd no matter what is on the canvas.
So, it must be something about certain applet parameters in 5.4. Perhaps Windows testing will reveal more detail. Feel free to contact me at dholyfield _at_ webassign.net as this seems to be a complex bug.
IE8/Win7 has the same problems as Firefox 3.6.1/OSX 10.6 (3 or less atoms will yield mrv, adding any more causes empty string to return). Scratch that last bit about the mode mattering, I had neglected to change the form action on that dropdown and was being directed to the working 5.3.8 installation.
browser/os result summary:
Firefox/OSX - cannot export more than 3 atoms
Safari/OSX - cannot call getMol at all (see stack trace above)
IE8/Win7 - cannot export more than 3 atoms
Firefox/Win7 - cannot export more than 3 atoms
Safari/Win7 - cannot export more than 3 atoms
we don't support Chrome at WebAssign, so I omitted the results of Chrome testing (they turn out to be the same as Firefox incidentally). Please let us know if the test page reveals anything -as of now, we're stuck.
Sorry for the long silence from me, and the for the late reply, but i had the information that i needed to work on this issue, and i tried a lot of dead end while working on the reproduction in my environment.
And finally it turned out, it is a server configuration issue. I have missed an exception on the java console on the page that you gave me, and that was the key, after i found it yesterday evening i was able to reproduce the issue and find a cause.
If i discovered well you are using an Apache server. There is a mime module for apache, that is repsonsoble for the content headers mime type part. As i think, there is an "AddEncoding x-gzip .data" line in the apache config somewhere, and that will be the guilty line. As i discovered java saves the isotopes.data file into the cache, but if it has x-gzip as content encoding, then the file gets bigger then the original one on the server, and therefore when the applet loads it from the cache, an exception occurs because the file cannot be open by GZipInputStream. In this case a class initialization fails which cause the export to fail when that class is used by the export modules.
So at first i suggest to remove this encoding for .data extensions, and see what happens (please also clear the java cache on the client before testing). I hope it can solve the problem. I also suggest to introduce the codebase_lookup parameter for the applet with the value false to avoid the security warning dialog by the applet startup.
I hope the discovered issue is the problem, but not sure. Please test it, and inform me if it solves the problem or not.
Well, after talking to our sys admin about this, I don't think we can set up our servers in such a way. Apache's 'magic' file determines mime type by file contents, rather than extension. Regardless of what isotopes.data is named, it will be seen as a gzip file, because it is one - or at least 'magic' thinks so based on its contents. We cannot remove gzip from our mime types and allow isotopes.data to be served as 'unknown' (pardon me if I'm not describing that elegantly), because we have other areas in our application where gzip files do need to be served. 5.3.8 does not have this problem, so I'm assuming the change is new to 5.4.0. Is there any possibility this can be changed back for 5,4.1?
I'll be brainstorming with our sys admin for any kind of workaround on our end, our chemistry department are adamant about getting the other fixes (electron flow arrow cleanup in particualr) out into our production environment for the Spring semester. Let us know if you know of another way to get around this.
István ChemAxon personnel
Joined: 03 Dec 2007
i understand the situation. I will check whether the mime magic module is loaded in the used test environment where i could be able to reproduce the problem with explicitly set the encoding for .data extension and test it a bit more. In the mean time, could you just test whether turning off the mime magic, and let the .data extension to be unknown solves the problem on your side also?
I will google about the possible causes and see what i can find based on the relevant changes in the codebase.
We were poking around for a workaround, what mime type is isotopes.data expected to be? We can add a line for it, but we need to know the proper type. Otherwise, it will drop to magic, which says 'hey that's a gzip file' and serves it ups as such. Let us know ...
FWIW, we have a workaround. We added a line to magic and now serve up .data files as application/octet-stream. This fixes the loading of isotopes.data and subsequent exports work correctly. In the long run, this isn't the most ideal solution - should we ever need to serve up .data files as something besides octet-stream, we'll be stuck. So, I'm hoping a real fix for this on the applet end is still in the works - please keep us posted and thanks very much for the help with this issue so far.
- Danny Holyfield
István ChemAxon personnel
Joined: 03 Dec 2007
Sorry it has taken me so long to get back with you, we are just now doing a spot test on MarvinSketch 18.104.22.168. Unfortunately, the problems do not seem to have been fixed. When attemping to load the applet, a security warning appears, indicating an mix of signed and unsigned components. We do not know if the problem is still with isotopes.data or not, but at any rate, we are unable to use the applet at this time. Please let us know if a fix is planned for the future. Feel free to contact us for more details.
Tamas ChemAxon personnel
Joined: 21 May 2004
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum