Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
Leakage of owlsim-server guice configuration into owlsim-core #62
Comments
|
Before you PR consider if #63 will make this simpler. As for the OWLAPI, in all other applications I use the OWLAPI v4 successfully without DI. However, in owlsim my recollection is that the overall use of DI leaked and we ended up using it. I think I'm good with moving DI out of the core. I'll chat with @jnguyenx about this today. I would also like to refactor OWLLoader (which is in core), see #57. I'm not sure if this is related. Given that OWLLoader essentially handles configuration (loading a collection of files given a YAML spec) I would have thought this a candidate for DI-ification, but happy to keep DI out here. |
jnguyenx
added a commit
that referenced
this issue
Mar 4, 2017
|
|
jnguyenx |
a9041df
|
|
I went ahead and extracted the modules from the core package, so you can use any DI framework in your service layer. @julesjacobsen can you try to pull from the branch and use your spring stack? If it works for you then we can merge. I still lack of some sleep hours, so I want to be careful :-) |
|
Yep, that works better. Although there are still some issues I've not got to the bottom of yet. I think these are more likely data-related. Using
but when I try to run a query which calls this code:
it throws a
So I swapped the test data for the full-on all.owl:
This gave couple of warnings and some errors:
Then it all falls over as it can't create the |
|
@julesjacobsen I'm not 100% sure how this factory method should be used to be honest. Here's how I've bound the
And to get the ontology objects:
Hope it makes sense. For more insight @cmungall should be able to shed some lights. |
|
I found the issue - it was to do with a lack of curies. Unfortunately the I've implemented a new return OwlKnowledgeBase.loader()
.loadCuries(curies())
.loadOntology("src/main/resources/ontologies/hp.obo")
.loadData("src/main/resources/data/human-pheno.assocs.gz")
.createKnowledgeBase();Where |
cmungall
referenced this issue
Mar 7, 2017
Open
Provide better documentation for how to use owlsim-v3 as a java library #65
|
I agree that it's still kinda messy, the So is it good for merging @julesjacobsen ? We can review the loader in a separate issue. |
|
@jnguyenx from my perspective, yes, this is good to merge. I've got a fully working Spring-powered REST wrapper running the core code. I'll migrate my previous comment to where it really ought to reside... |
julesjacobsen
closed this
Mar 7, 2017
jnguyenx
added a commit
that referenced
this issue
Mar 8, 2017
|
|
jnguyenx |
5bba20a
|
jnguyenx
added a commit
that referenced
this issue
Mar 9, 2017
|
|
jnguyenx |
56a4aa2
|
julesjacobsen commentedMar 3, 2017
I can't quite see the requirement for Guice to be used inside of owlsim-core. By following best practices hopefully anything Guice specific can be removed from the core. I think this will be pretty simple, with one possible major headache... The OWL API has a bunch of classes which are called in the OwlSimServiceApplication:
These OWLAPI* classes are all Guice Modules, but it's not apparent where these are used in the server or core or for what reason. If they are critical then I guess I'll just have to copy these into a Spring configuration and pray they limited the amount of Guice specific stuff to just these classes.
Apart from the OWL API stuff, there are four Guice configuration classes (those extending AbstractModule) classes in the core:
Of these
EnrichmentMapModule,MatcherMapModuleandMatcherModule(unused, duplicated by MatcherMapModule) are actually only used by the owlsim-services in order to find out which classes are available from the package using reflection and the creating a map of short name to actual instance which is taken from the Guice Injector by calling
injector.getInstance(clazz).The
ProfileMatcherandEnrichmentEngineimplementation constructors are annotated with@Injectwhich is as it should be and is part of the JSR-330 spec so can be used by any decent standards compliant Java DI framework. All concrete instances of these interfaces require a concrete instance ofBMKnowledgeBaseto be passed in by constructor injection.This is where it gets a bit more complicated.
KnowledgeBaseModuleis used to wire-up an instance ofBMKnowledgeBaseOWLAPIImpl, it's more or less a copy ofOWLLoaderwhich also takes a bunch of input terms to produce aBMKnowledgeBasewhencreateKnowledgeBaseInterface()is called. If theOWLLoaderprovided a Builder it would make constructing aBMKnowledgeBasea lot simpler as it would guide people along - this could the be used by any application to provide aBMKnowledgeBaseand wrapped into a DI framework more easily.So to summarise it looks like
EnrichmentMapModuleandMatcherMapModuleshould really move to the owlsim-services sub-project module andMatcherMapModuleshould be removed. TheKnowledgeBaseModuleshould utilise the OWLLoader to create a singleton instance ofBMKnowledgeBaseand use that for injection into Guice.I'm happy to do a PR for this.