Egon Willighagen wrote: >On Wednesday 09 May 2007 14:31:41 Bob Hanson wrote: > > >>Egon Willighagen wrote: >> >> >>>Just out of curiosity... how is the split up into 16 >>>jars done? I seem to have overlooked that howto on the list... >>> >>> First, all classes that needed isolation were placed in separate org.jmol.xxx packages. For example, I split off the readers into org.jmol.adapter.readers, and within that, the cif and pdb readers into org.jmol.adapter.readers.cifpdb. And I separated out the various types of shapes into separate packages org.jmol.shape, org.jmol.shapebio, and org.jmol.shapespecial. I also split off org.jmol.modelframe, but that was unrelated to this issue, I think.
Then all cross-jar references that would require an import command were removed. This was the hardest part, but it was critical. You can have no direct reference from one class in one jar file to another class in another jar file for this to work. This was mainly accomplished using interfaces. The interface itself is defined in org.jmol.api, and that is part of the main Jar file. So, for example, we have a JmolBioResolver interface that doesn't require any direct association between the bio-related shapes and structures (biopolymer, monomer, etc.) and Frame. The same worked for smiles, mo calculation, and mep calculation. In addition, any cross-jar instantiation of a class is carried out using Class.forName() instead of a direct invocation using new. The one thing that threw me off was a reference in org.jmol.viewer.JmolConstants.java to org.jmol.Jmol.property (where "Jmol.property" was a file in org.jmol). It turns out that if you reference an object in a parent package, then all siblings are loaded. So for a couple of days, I simply could not get the Jar files to load sequentially. Once Jmol.property was moved to org.jmol.viewer, everything worked as expected. Also, build.xml was modified to create a correct jar index in JmolApplet0.jar and JmolAppletSigned0.jar. I simplified the manifests by just creating a generic manifest for most jar files: Manifest-Version: 1.0 Sealed: true So this then could be used in all situations. One surprise I had was that I also experimented with adding extra external .class files on the fly from the server. For example, not including a jar file containing the GAMESS reader, and then loading a GAMESS file, and having that read from org.jmol.adapter.readers.GamessReader.class on my server. It turns out even without signing, if the manifest for a package's Jar file says "Sealed: true" then you cannot expand that java package with an additional class file on the server. Signed or not. Anyway, that idea of providing additional class files wasn't necessary and was dropped. To monitor the whole thing, I used a little personal server I wrote years ago and that I could easily monitor. I set up a page that used a (secret, sorry!) local port, and then used http://localhost:xxx/test.htm. I then watched my server log to see what the browser was requesting. This way I could see exactly when and in what order any particular jar file was being called. That's about it, I think. Bob ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
