ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hookway <shook...@cra.com>
Subject RE: managing ctakes resources on classpath
Date Tue, 10 Sep 2013 18:42:28 GMT
Ah ha - I've sorted it out!

I couldn't figure out what would be different from adding resources on the buildpath (working)
vs the classpath (not working). But, what was going on was that Eclipse was managing the order
of the classpath differently in each case. When I added the resource folder to my buildpath,
it moves it "up" the classpath so that these resources are used before things in my maven
dependencies. As a result, FileLocater.locateFile is able to find the file from the folder
on my system.

When I was adding the folder via the classpath - it was always falling to the "bottom" of
dependencies (I never thought to move it up until I actual stepped through the FileLocator...)
as a result, FileLocator (via the class loader) finds the path in one of the maven dependencies
first: ctakes-resources-umls2011ab-3.1.1.jar. The LocateOnClasspath does throw the hierarchical
UI exception, which is caught and ctakes tries to "locateExplicitly" which fails because the
path is in fact a classpath resource.

Hopefully that helps someone else out! Also I'm curious the right way to be managing resources
- I arrived at my mish-mash because I started with the standalone and then started picking
with the API.

Thanks again for the help!
-Steve






THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN
INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW.
If you are not the intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please delete the message and
notify the sender so that we may correct our records.

-----Original Message-----



From: Steve Hookway [mailto:shookway@cra.com]
Sent: Tuesday, September 10, 2013 12:43 PM
To: dev@ctakes.apache.org
Subject: RE: managing ctakes resources on classpath

Hello Again,

Ok - I think I've straightened out some version issues (and resolved the hierarchical URI
loading issue) but now I'm having a problem getting Lucene to behave nicely when resources
are on the classpath vs. the buildpath.

An update: I've checked out the latest code - and am pointing to the AggregatePlaintextUMLSProcessor.xml
in the clinical pipeline. Although (to complicate things a little), I'm NOT building using
the checked out code - but using mvn to add a dependency on clinical pipeline 3.1.0.

I have my old 3.0.1 resources folder which I've clobbered with the 3.1.0 dependencies. After
running a few times and picking up "not founds" I've added enough of the resources from the
various checked out 3.1.0 projects into the resources folder to get up and running. When I
run things with the resources directory on the buildpath everything works as expected. But,
when I run with the resources directory on the classpath instead, I get a FileNotFoundException:

org.apache.uima.resource.ResourceInitializationException
        at org.apache.ctakes.core.resource.LuceneIndexReaderResourceImpl.load(LuceneIndexReaderResourceImpl.java:80)
        at org.apache.uima.resource.impl.ResourceManager_impl.registerResource(ResourceManager_impl.java:603)
        at org.apache.uima.resource.impl.ResourceManager_impl.initializeExternalResources(ResourceManager_impl.java:442)
........
Caused by: java.io.FileNotFoundException: org/apache/ctakes/dictionary/lookup/rxnorm_index
        at org.apache.ctakes.core.resource.FileLocator.locateExplicitly(FileLocator.java:93)

If I look in my resource folder I do in fact have a matching directory that's populated with
a number of files.

Any insight would be much appreciated,
Steve






THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN
INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW.
If you are not the intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please delete the message and
notify the sender so that we may correct our records.

-----Original Message-----



From: Steve Hookway [mailto:shookway@cra.com]
Sent: Tuesday, September 10, 2013 9:52 AM
To: dev@ctakes.apache.org
Subject: RE: managing ctakes resources on classpath

Hi Pei,

Thanks for the help!

I'm using version 3.0.1 of the resources and am grabbing my dependencies (using maven central)
from ctakes-clinical-pipeline version 3.0.0-incubating. I wound up hosting versions of zoner,med-facts,
and jcarafe myself; I found a ticket that made it seem like this is fixed in the latest release,
but I couldn't get the stuff from maven central working without adding these dependencies
manually.

I'm using: analysisEngine = AnalysisEngineFactory.createAnalysisEngineFromPath(analysisEnginePath);

And the Path points to the ctakes-clinical-pipeline\\desc\\analysis_engine\\AggregatePlaintextUMLSProcessor.xml

It's interesting to me that when running from Eclipse adding the resources to the buildpath
vs. classpath makes a difference - I'm not sure what tricks Eclipse uses here to transfer
buildpath entries to the classpath during runtime (that threats the resources differently)....

Hopefully this is just a configuration problem!

Thanks again for the help,
Steve






THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. IT MAY CONTAIN
INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW.
If you are not the intended recipient, your use of this message for any purpose is strictly
prohibited. If you have received this communication in error, please delete the message and
notify the sender so that we may correct our records.

-----Original Message-----



From: Pei Chen [mailto:chenpei@apache.org]
Sent: Tuesday, September 10, 2013 9:34 AM
To: dev@ctakes.apache.org
Subject: Re: managing ctakes resources on classpath

Hi Steve,
The URI is not hierarchical is most likely caused by the code trying to use the resources/models,
but they are inside a jar instead of unpacked.

-Which version of cTAKES are you using?
-Do you happen to have the resource file name that caused the above?

--Pei


On Mon, Sep 9, 2013 at 9:48 PM, Steve Hookway <shookway@cra.com> wrote:

> Hi all,
>
> I'm trying to integrate ctakes into a webapp and am running into
> issues getting the resources to load correctly. In a standalone
> version of the app, if I add the resources folder to the buildpath (as
> described in the install directions) everything works as expected.
> However, if I add the folder to the project classpath instead, I get a
> URI is not hierarchical exception from FileResourceImpl.load:
>
> java.lang.IllegalArgumentException: URI is not hierarchical
>        at java.io.File.<init>(File.java:392)
>        at
> org.apache.ctakes.core.resource.FileResourceImpl.load(FileResourceImpl.java:44)
>        at
> org.apache.uima.resource.impl.ResourceManager_impl.registerResource(Re
> sourceManager_impl.java:603)
>
> Similarly if I try and run from a webapp - setting up tomcat's
> classpath to include the ctakes resource folder, I get the same URI is
> not hierarchical error. I found this bug report:
> https://issues.apache.org/jira/browse/CTAKES-89 but  it suggests
> adding the resource folder to my classpath, which isn't doing the trick.
>
> If you can steer me in the right direction, I'd really appreciate it.
>
> Thanks,
> Steve
>
>
>
>
> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS
> ADDRESSED. IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL
> AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If you are not the
> intended recipient, your use of this message for any purpose is strictly prohibited.
> If you have received this communication in error, please delete the
> message and notify the sender so that we may correct our records.
>
>
>
>




Mime
View raw message