UIMA
  1. UIMA
  2. UIMA-1793

jcasgen: load the descriptor from the classpath

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.2.2CE, 2.2.2AS, 2.2.2S, 2.1, 2.2, 2.2.1, 2.2.2
    • Fix Version/s: 2.3.1SDK
    • Component/s: Tools
    • Labels:
      None

      Description

      Hi,

      I would like to propose a small patch to the Jg class (org.apache.uima.tools.jcasgen.Jg). At the moment it is only possible to generate the source code for the typesystem when the corresponding descriptor file is located somewhere on your disk. I have the use case, where I want the typesystem descriptor to be contained inside a (company wide) jar. That means, I need to load the typesystem descriptor from the classpath.

      The attached patch adds a little bit of extra info to the "-jcasgeninput" parameter ind the "main1" method. If the value starts with "classpath:" the patch will try to look for everything after "classpath:" with its ClassLoader. If the ClassLoader can find the resource and the "outputDirectory" is not null, everything works. If the ClassLoader cannot find the resource, the corresponding error is generated.

      If the "-jcasgeninput" parameter does not start with "classpath:" everything works as before, only that the file is being converted to an URL instance that is given to the XMLInputSource object.

      What I am not sure about it the use of the "xmlSourceFileName" member variable and what it should contain if the descriptor is loaded from the classpath. Actually I don't even know what this variable does...

      I have not found any unittest for this class. So the code is tested with my maven mojo and works as expected. If anyone can provide me with more info about how to test the Eclipse plugin I could also test this, but I certainly need help there...

      Any comments? Best
      Daniel

      1. uima-tools-jg2.patch
        3 kB
        Daniel Truemper
      2. uimaj-tools-jg.patch
        3 kB
        Daniel Truemper

        Activity

        Hide
        Marshall Schor added a comment -

        looks like the error handling for file-not-found for the case of opening a file within a Jar is not right - findbugs reporting issues.

        Show
        Marshall Schor added a comment - looks like the error handling for file-not-found for the case of opening a file within a Jar is not right - findbugs reporting issues.
        Hide
        Marshall Schor added a comment -

        applied patch 2

        Show
        Marshall Schor added a comment - applied patch 2
        Hide
        Daniel Truemper added a comment -

        This is another version of the patch using the "jar:" URL handler. Works for me and the Jg unittests do not complain. But: I am unsure about the MalformedUrlException since it will be reported as "fileNotFound". I'd have to dig deeper into the error handling at that particular place in the code to add another custom error message. Any pointers to that?

        Best
        Daniel

        Show
        Daniel Truemper added a comment - This is another version of the patch using the "jar:" URL handler. Works for me and the Jg unittests do not complain. But: I am unsure about the MalformedUrlException since it will be reported as "fileNotFound". I'd have to dig deeper into the error handling at that particular place in the code to add another custom error message. Any pointers to that? Best Daniel
        Hide
        Daniel Truemper added a comment -

        Second version of the patch now using the "jar" protocol.

        Show
        Daniel Truemper added a comment - Second version of the patch now using the "jar" protocol.
        Hide
        Daniel Truemper added a comment -

        Hi Marshall,

        this maybe a better way to do so. My usecase is quite simple: I am wrinting a Maven Mojo, that should allow me to build the source files from my typesystem. So, at the moment I am doing things you should not do to add the Jar containing the typesystem to the Jg classpath. From there on I can then simply use the ClassLoader to get a stream.

        So with the jar protocol I should be able to provide a cleaner solution for the problem! Will try to do this right now and then submit another path for that!

        Thanks for the reply!
        Daniel

        Show
        Daniel Truemper added a comment - Hi Marshall, this maybe a better way to do so. My usecase is quite simple: I am wrinting a Maven Mojo, that should allow me to build the source files from my typesystem. So, at the moment I am doing things you should not do to add the Jar containing the typesystem to the Jg classpath. From there on I can then simply use the ClassLoader to get a stream. So with the jar protocol I should be able to provide a cleaner solution for the problem! Will try to do this right now and then submit another path for that! Thanks for the reply! Daniel
        Hide
        Marshall Schor added a comment -

        In looking at the patch and thinking about this, I have some questions.

        If the use case is to use run JcasGen on a typesystem which is contained inside a jar, another option would be to pass the a specification that follows the syntax for the standard way to write URLs for Jar contents:
        jar: [ some spec to the jar file ] ! [path to item in the Jar file].

        See http://java.sun.com/developer/onlineTraining/protocolhandlers/ and in that doc, the section on "The Standard URLStreamHandlers".

        Using this approach would avoid having to put the Jar into the classpath of the application running JcasGen. I think that would be good, because the class path for JCasGen in many cases would not normally need to include the target Jar.

        Does this fit your use case better?

        Show
        Marshall Schor added a comment - In looking at the patch and thinking about this, I have some questions. If the use case is to use run JcasGen on a typesystem which is contained inside a jar, another option would be to pass the a specification that follows the syntax for the standard way to write URLs for Jar contents: jar: [ some spec to the jar file ] ! [path to item in the Jar file] . See http://java.sun.com/developer/onlineTraining/protocolhandlers/ and in that doc, the section on "The Standard URLStreamHandlers". Using this approach would avoid having to put the Jar into the classpath of the application running JcasGen. I think that would be good, because the class path for JCasGen in many cases would not normally need to include the target Jar. Does this fit your use case better?
        Hide
        Daniel Truemper added a comment -

        The above mentioned patch

        Show
        Daniel Truemper added a comment - The above mentioned patch

          People

          • Assignee:
            Marshall Schor
            Reporter:
            Daniel Truemper
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development