This is usually caused by the Example program trying to connect to a database that has been removed from the mysql server ensembldb.ensembl.org:3306. This bug only happens in old version of ensj and upgrading to the latest build of ensj.jar will fix this problem.
This means that the database is not available on the database server. Perhaps the database name is misspelt or the database has been removed. This sometimes happens if you are using an old configuration file that refers to an obsolete database. A list of current databases on ensembldb.ensembl.org is available in the file ensembldb.ensembl.org-databases.txt in the latest build.
fetchInternalIDs(Location) methods
but you might want to consider using the
fetchIterator(Location) methods instead. These provide a very
simple interface with a fast implementation that uses relatively
little memory even for whole genome queries. Examples:
long[] ids =
geneAdaptor.fetchInternalIDs(location);
Iterator iter = geneAdaptor.fetchIterator(location);
It is possible that your bug has been fixed or is due to an incompatiblity between the versions of ensj.jar, mysql.jar (MySQL JDBC driver) or the MySQL database you are using. The first thing to do therefore is to make sure you are using the right jars. You can download the latest ensj release and a compatible mysql driver from the download section. Note that some users have experienced problems with both older and, surprisingly, newer mysql.jars so ensuring you are using the version we distribute is an important step in the debugging process.
Secondly, several people have experienced problems using ensj that were caused by referencing old ensj-XX.Y or mysql-XXX jars in their CLASSPATH.
java -cp ensj-XX.Y.jar:mysql-XXX.jar:$CLASSPATH
some.package.YourClass.
System.out.println(SystemUtil.environmentDump())
to the beginning of your program to discover which jars the ensj and
mysql classes are being loaded from. If the program won't compile or
run after adding this line because of a "SystemUtil.environmentDump()
is missing" error then you are using an old ensj-XX.Y.jar. If the bug occurs when you use the latest ensj-XX.Y.jar and mysql-ZZZ.jar then you should submit a bug report.
To begin with, read the "I think I've found a bug in ensj" section. Once you are convinced it is a real bug in ensj you should include these items in a bug report:
System.out.println(SystemUtil.environmentDump()) as the
first line of main() which will generate additional debugging information. This is usually because the ensj driver is pointing at a different database to the website. Configuring the driver to point at the same database as the website (the latest) usually solves this problem.
It should be in the jar name but if not you can also run this command
to find out: prompt>java org.ensembl.Version.
The source code for the latest release is included in the latest
distribution. Other versions of the source code corresponding to other
builds are available from CVS
using the appropriatte tag. For example, after checking out ensj-core
,cvs up -r release-ensembl-25-0 would retrieve all the
files in the 25.0 build (release or snapshot).
Yes. Ensj is published under the LGPL so you can redistribute the jar although you should also include a copy of the LGPL. For instance copy LICENSE to LICENSE-ensj in the same directory as your own license.
This question should really be answered by reading the MySQL AB license. It took me a little time to read through this so I'll give my short interpretation of it here on the grounds that it might save you some time. This interpretation might be wrong and comes with no warranty so you should still read the original for yourself. Enough caveats, here's my take on the license situation:
Probably. Ensj has been partially tested against an MS SQL database loaded with ensembl data via the jDTS jdbc driver (http://jtds.sourceforge.net). Sample configuration properties to put in the ensembl driver config file:
connection_string=jdbc:jtds:sqlserver://HOST:PORT
jdbc_driver=net.sourceforge.jtds.jdbc.Driver
This happens because too many connection requests have been made from your IP address. Ensembl's MySQL server ensembldb.ensembl.org:3306 only allows 32 connections per IP address. Note that if several users connect to the database from behind a NAT firewall they all appear to have the same IP address.
Putative orthologues generated by recipricol BLAST hits are stored in
the compara database and can be retrieved via a ComparaDriver. This
example shows how to print all the orthologues for the human gene
ENSG00000118961 from
the latest ensembl databases.
Here is similar code in jython:
ComparaDriver compara = Registry.createDefaultUserRegistry().getGroup("compara").getComparaDriver();
List gdbs = compara.getGenomeDBAdaptor().fetch();
for (int i = 0; i < gds.size(); i++) {
GenomeDB gdb =(GenomeDB) gdbs.get(i);
String targetSpecies = (String) gdb.getName();
// if we were only interested in hits in chicken...
// List hits = compara.getMemberAdaptor().fetch("Homo sapiens", new String[]{"ENSG00000118961"}, "Gallus gallus");
List hits = compara.getMemberAdaptor().fetch("Homo sapiens", new String[]{"ENSG00000118961"}, targetSpecies);
System.out.print(targetSpecies);
for (int j = 0; j < hits.size(); j++) {
FeaturePair p = (FeaturePair) hits.get(j);
// hitDisplayName is the orthologue gene name; begins with
// "ENS" if ensembl predicted gene otherwise name is assigned
// by another group.
System.out.print("\t" +p.getHitDisplayName());
}
System.out.println();
}
genomes = ensembl.ensembl_compara.genomeDBAdaptor.fetch()
for speciesName in [g.name for g in genomes]:
orthologues = ensembl.ensembl_compara.memberAdaptor.fetch("Homo Sapiens", ["ENSG00000118961"], speciesName)
geneNames = [o.hitDisplayName for o in orthologues]
print geneNames