| CRT home > SigPath: Frequently Asked Questions (FAQ) |
Installing Sigpath
- When I tried the command 'ant -f build\build.xml test' I received an error
message: "BUILD FAILDED C:\sigpath\build\build.xml:494: Could not create
task or type of type: fastobjects_enhancer_task."
- Fastobjects is a 15 day trial that at the moment cannot be downloaded. Do
you have alternate suggestions?
- Do user environment variables have to be set like this? Where does the code
for fastobjects configuration go?
- What does Client (poet.cfg) mean?
- Where do these commands for server have to be typed?
- Where does configuration code go?
- How do I compile the program? With Java?
XML Related Questions
- Why do I need to learn about XML? Why don't you support Excel for data submission?
- When I submit a new chemical, is it necessary to create a spid value?
- It is not clear what is supposed to be done in a TConfirmXX class.
- My group here is questioning again the need for this XML work.
- Why does the XML schema not have a 1-1 correspondence with the Java classes of the datamodel?
- Why are the names used in the XML schema for SigPath entities different from the Java class names in the datamodel?
- Why are spid, idref and ac all necessary for referencing an entity in an XML submission?
Database Related Questions
- Is there a helper class you have written that knows where to look for the property file that is used to create the PersistenceManagerFactory? Is there another similar program that loads information that I can look at? I'll need to make calls to a method somewhere to get the unique SigPath ID, etc.
- One of our other developers, who is doing the GUI work, is interested in knowing if there is a specific set of classes she can examine to see how she should interface to the database. Will she directly use JDO calls or do you have a layer between the SigPath application and the JDO interface?
- What is the strategy to write parts of the SigPath web application that submit new information to the database?
When I tried the command 'ant -f build\build.xml test' I received an error message: "BUILD FAILDED C:\sigpath\build\build.xml:494: Could not create task or type of type: fastobjects_enhancer_task."
You should copy FastObjects_t7_SDK.jar from the FastObjects distribution to the lib directory (this is the jar that contains *com.poet.tools.ptj.ant.PtjAntTask*, the task needed to configure fastobjects_enhancer_task).
Back to the top
Fastobjects is a 15 day trial that at the moment cannot be downloaded. Do you have alternate suggestions?
Yes, SigPath compiles and deploys with the Kodo product, from Solarmetric. Academic licenses are $100 per developer. We are now porting SigPath to JPOX, which is an open-source distribution of JDO. This
would be the ideal solution, but JPOX 1.0 was released last July, and there are still a few bugs or problems that prevent a successful SigPath deployment with JPOX.
Back to the top
Do user environment variables have to be set like this? Where does the code for fastobjects configuration go?
TOMCAT_DEPLOY is the only environment variable that SigPath uses. Most configuration is done in the file build/build_config.xml
You can make a backup of this file if you prefer, but you should change build/build_config.xml directly.You need to edit this file to describe your local configuration.
When you open the file, you will notice the <project> element, followed by many <property> elements, followed by many <target name=""> elements with different names. If you are not familiar with ant, each target describes some task that can be executed by running ant -f build/build_config.xml <target-name>
Each target element ends with the </target> closing tag. For instance, the first target has name "default" and looks like this:
<target name="*default*">
<echo level="*info*" message="*Use this file to configure SigPath settings for your configuration*" />
</target>
This one will just print a message if you run ant without a target name, i.e., ant -f build/build_config.xml
[Example]
Copy this target just after the default target (between the </target> tag and the next <target> tag).
When done, try running ant without a target name to check the format of the file. If ant complains at this stage, copy your backup over the file and try adding your configuration target again.
If ant displays the message, try ant -f build/build_config.xml config_tommy
This should configure SigPath for your local configuration and you can continue with the instructions (compiling, testing).
[Note: In SigPath, we do not use your classpath from your environment. Instead, we build one dynamically to include every jar that is needed and is in the lib project directory. Copy FastObjects_e7_JDO.jar and jdo.jar to the lib directory and the build will recognize them there.]
Back to the top
What does Client (poet.cfg) mean?
This is a FastObjects configuration file for FastObjects t7. If you use a FastObjects e7 evaluation, disregard this file.
Back to the top
Where do these commands for server have to be typed?
In a DOS console (Start->Programs->Accessories->Command Prompt)
Back to the top
Where does configuration code go?
Do you mean the config target? If so, it goes in build/build_config.xml (see detailed instructions above).
Back to the top
How do I compile the program? With Java?
Yes, you need the Java Development Kit.
Back to the top
It is not clear what is supposed to be done in a TConfirmXX class.
TConfirm classes are used indirectly by DisplaySPSubmission. This class converts an XML submission into a string that describes the content of the submission for the end-user.
We do not like how these classes are designed at the moment, but this is how they work:
- TConfirm tasks are called by XMLImport during the submission validation.
- Each TConfirm task builds a string to document an object and stores it into the Castor description field for the object. The problem here is that this overwrites whatever description was previously there, making the submission not reusable after the validate step. Some lookups occur at this stage to get information about objects referenced by spids and that were not in the XML file themselves (e.g., molecules refer to chemicals that need to be represented on the left and right side of reactions).
- The class DisplaySPSubmission iterates through each object in the submission and assembles the total report.
So, in summary, your TConfirm classes should fetch name and descriptions of compartments and membranes that are identified by spids (or use names and description of compartment and membranes in the XML file if idrefs are used), and build a string out of it.
Back to the top
My group here is questioning again the need for this XML work.
The XML work is necessary for three main reasons:
- For importing and exporting information into and from SigPath. We use it all the time to transfer the data from one release of SigPath to the next. If your project did not produce the XML tasks, data that users submitted in one release would be lost for the next. Therefore, keeping the data would be useful because changes to the ontology/database schema could be drastic.
- Long database transactions are totally avoided by using non-persistent XML classes from one screen of the wizard to the next, until the final submit.
- The validation constraints are enforced consistently in the user interface and in the XML import. This helps make sure that spurious data does not make it into the database.
Back to the top
Why does the XML schema not have a 1-1 correspondence with the Java classes of the datamodel?
In general, the XML submission is for human curators or end-users to use, the datamodel is for programs to work with. The two types of use often call for different representations.
Back to the top
Why are the names used in the XML schema for SigPath entities different from the Java class names in the datamodel?
Class names are too long for users to type and make the XML hard to read.
Back to the top
Why are spid, idref and ac all necessary for referencing an entity in an XML submission?
They are needed for different occasions.
- The spid is used when the molecule/object already exist in the SigPath database (was submitted at an earlier date, and
we preserve spids that start with sp from release to release).
- The idref is used when referencing an object within the current xml submission. This object has no representation in the database and does not have a spid yet (it will have one after the submission is successfully saved).
- The ac attribute is used to refer to objects that are imported directly from external databases, and for which we do not maintain spids in SigPath (these entitites have spid that start with "bid", which stands for background id).
In addition, for proteins, we need a fourth attribute "organism" that is used to resolve ambiguity of the accession code in the SwissProt and TrEMBL databases.)
Back to the top
When I submit a new chemical, is it necessary to create a spid value?
SigPath has the ability to allocate a unique spid for new entities. Unless it is a reference to an existing entity in the SigPath database, for new entities, the user should submit without a spid attribute in the XML file.
Back to the top
Why do I need to learn about XML? Why don't you support Excel for data submission?
XML offers significant advantages. For one thing, the format is text-based, and is not proprietary. XML supports computational use of the information, yet is easy for people to learn and get started with (see our XML Submission tutorial for a quick introduction). Another advantage is that many tools exist that can be used to check the structure and syntax of an XML file, or even to help you create the XML document.
For SigPath submisssions, using these tools and other validation tools that we are developing into SigPath, helps make sure that the data is well organised before it is submitted into SigPath.
We realize that the need to learn XML prevents some people to submit information. For this reason, we are actively developing web-based user interfaces that can be used instead of the XML submission. However, creating these user interfaces is a lengthy process, and features are always accessible through XML before they are implemented in the user interfaces (because SigPath user interfaces actually create an XML submission on your behalf).
Back to the top
Is there a helper class you have written that knows where to look for the property file that is used to create the PersistenceManagerFactory? Is there another similar program that loads information that I can look at? I'll need to make calls to a method somewhere to get the unique SigPath ID, etc.
The SigPath code provides support for most of this. Take a look at the classes SPDBManager (opens the connection to the database, and support transactions), and at DBTask, designed to free the developer from transactions as much as possible.
In the example below, TExportModelKK is a class that extends DBTask. The execute method of DBTask will begin/commit transactions as needed and delegate to the _execute method of its TExportModelKK subclass.
See the javadocs for details. The javadocs match the latest code release. (testkinetikit below is not in this release, compare to testsbml which is.)
Another example is the org.sigpath.test.datamodel.TestBoot class from the JUnit tests. [Click here to view code]
Back to the top
One of our other developers, who is doing the GUI work, is interested in knowing if there is a specific set of classes she can examine to see how she should interface to the database. Will she directly use JDO calls or do you have a layer between the SigPath application and the JDO interface?
She should look into the org.sigpath.database package. The main class again is SPDBManager and the other managers.
Back to the top
What is the strategy to write parts of the SigPath web application that submit new information to the database?
At the moment, a strong limitation of JDO is that it does not support long transactions. This is a major problem with web applications where business logic frequently spans multiple requests. Since we cannot keep transactions open for multi-second periods that typically occur between requests, we use the following strategy:
To submit new information through the web application and make persistent instances:
- Create a tapestry page that the user will reach upon starting the information submission wizard (the wizard could be just one page or multiple pages).
- Create an empty SigPath XML submission in the Visit object (org.sigpath.tapestry.Visit)
- Make sure that the tapestry code writes new information to the XML submission in the visit object.
- Write the display code in the way that it uses the XML information as the source of the data to display.
- Use the TValidate tasks to validate the XML submission when the user press the intermediate submit button. The tasks should report errors to the user through the tapestry mechanism.
- When the user has completed the wizard steps and clicks the final submit, which should write to the database. Perform a final TValidate on the submission, and if no error occurs, continue with a TSave. Upon successful completion, the TSave will create persistence instances from the information in the XML submission
For the strategy to work, you need XML import to recognize the type of information you will import. That means you will need an XML schema.
Back to the top
| 
