headers
Adam Lally (JIRA | 1 May 15:23
Picon
Favicon

[jira] Created: (UIMA-387) XMI Serializer can write invalid control characters

XMI Serializer can write invalid control characters
---------------------------------------------------

                 Key: UIMA-387
                 URL: https://issues.apache.org/jira/browse/UIMA-387
             Project: UIMA
          Issue Type: Bug
          Components: Core Java Framework
    Affects Versions: 2.1
            Reporter: Adam Lally
             Fix For: 2.2

On 5/1/07, Leo Ferres <lferres@...> wrote:
> Hello,
>
> While trying to open an xmi file after processing in xml view, an
> error pops up telling me that there is an invalid &#26 xml character.
> the error comes from the sax parser. Below is the stack trace. Thanks
> very much for your help,
>

Most control characters are not allowed in XML 1.0, even if they are
escaped with &#xxx.  If your input document contains such characters,
the XMI CAS serializer is writing them to the output XMI document,
making it unreadable.

I checked that if you edit the XMI document and change the first line to:
<?xml version="1.1" encoding="UTF-8"?>

The problem goes away, because XML version 1.1 does allow escaped
(Continue reading)

Permalink | Reply | 25 comments |
headers
Adam Lally (JIRA | 1 May 15:57
Picon
Favicon

[jira] Created: (UIMA-388) When CollectionReader wrapped as CAS Multiplier, if a second process call comes in, call reconfigure

When CollectionReader wrapped as CAS Multiplier, if a second process call comes in, call reconfigure
----------------------------------------------------------------------------------------------------

                 Key: UIMA-388
                 URL: https://issues.apache.org/jira/browse/UIMA-388
             Project: UIMA
          Issue Type: Improvement
          Components: Core Java Framework
    Affects Versions: 2.1
            Reporter: Adam Lally
         Assigned To: Adam Lally
            Priority: Minor
             Fix For: 2.2

This is to support deploying a CollectionReader as a CAS Multiplier service and then hitting it multiple
times, without having to restart the service.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Permalink | Reply | 2 comments |
headers
Adam Lally (JIRA | 1 May 16:07
Picon
Favicon

[jira] Resolved: (UIMA-388) When CollectionReader wrapped as CAS Multiplier, if a second process call comes in, call reconfigure


     [
https://issues.apache.org/jira/browse/UIMA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Lally resolved UIMA-388.
-----------------------------

    Resolution: Fixed

> When CollectionReader wrapped as CAS Multiplier, if a second process call comes in, call reconfigure
> ----------------------------------------------------------------------------------------------------
>
>                 Key: UIMA-388
>                 URL: https://issues.apache.org/jira/browse/UIMA-388
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>    Affects Versions: 2.1
>            Reporter: Adam Lally
>         Assigned To: Adam Lally
>            Priority: Minor
>             Fix For: 2.2
>
>
> This is to support deploying a CollectionReader as a CAS Multiplier service and then hitting it multiple
times, without having to restart the service.

--

-- 
This message is automatically generated by JIRA.
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Lally (JIRA | 1 May 17:08
Picon
Favicon

[jira] Reopened: (UIMA-379) CAS views should not call initFsClassRegistry


     [
https://issues.apache.org/jira/browse/UIMA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Lally reopened UIMA-379:
-----------------------------

      Assignee: Adam Lally  (was: Eddie Epstein)

The fix for this broke some other things.  Working on a better fix.

> CAS views should not call initFsClassRegistry
> ---------------------------------------------
>
>                 Key: UIMA-379
>                 URL: https://issues.apache.org/jira/browse/UIMA-379
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>            Reporter: Eddie Epstein
>         Assigned To: Adam Lally
>
> The fsclassregistry should be shared with the base CAS, as is done by setCAS(). If not shared, class cast
exceptions occur when instantiating JCas on one CAS view and then trying to use JCas on another CAS view.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Lally (JIRA | 1 May 17:55
Picon
Favicon

[jira] Closed: (UIMA-379) CAS views should not call initFsClassRegistry


     [
https://issues.apache.org/jira/browse/UIMA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Lally closed UIMA-379.
---------------------------

    Resolution: Invalid

There was no need for any changes here.  There were in fact no ClassCastExceptions in Apache UIMA, and the
previous behavior was correct.

> CAS views should not call initFsClassRegistry
> ---------------------------------------------
>
>                 Key: UIMA-379
>                 URL: https://issues.apache.org/jira/browse/UIMA-379
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>            Reporter: Eddie Epstein
>         Assigned To: Adam Lally
>
> The fsclassregistry should be shared with the base CAS, as is done by setCAS(). If not shared, class cast
exceptions occur when instantiating JCas on one CAS view and then trying to use JCas on another CAS view.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lev Kozakov | 1 May 18:14
Picon

UIMA PEAR utilization issues

Recently, Michael proposed adding 'UIMA PEAR runtime' capabilities to
automatically install PEARs and run encapsulated analytics. In
connection with that discussion, I would like to share experiences
related to utilization of PEARs in UIMA and start a broader discussion
on this topic. The issues, I'm talking about, were actually identified
in the course of developing the 2nd generation of PEARs (in
2005-2006).

PEAR format was introduced as a convenient vehicle for packaging and
distributing UIMA analytics and other resources. PEAR package must
include installation descriptor file, containing the PEAR
identification, reference to the main UIMA descriptor, runtime
settings and other information.
PEAR package has 3 different states: (1) ready for packing/archiving,
(2) packed as a zip (*.pear) archive and (3) installed in a local file
system. In state 1, the package is not packed, but may be not usable
for UIMA deployment, because its installation descriptor, as well as
other descriptor/configuration files may contain $main_root
expressions. In state 3, the package is ready for UIMA deployment.
Transition from state 1 to state 2 (zipping) does not modify the
package contents, while transition from state 2 to state 3
(installation) may irreversibly modify the package contents by
localizing (replacing $main_root with absolute path) installation
descriptor and other descriptor/configuration files. The
installation/localization step is necessary for utilizing PEAR in
UIMA.

As you can see from the previous paragraph, current PEAR has the
following issues:
 1. Installation descriptor file contains several different kinds of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall Schor | 1 May 19:59

Re: svn commit: r534093 - /incubator/uima/uimaj/trunk/uimaj-core/src/main/java/org/apache/uima/analysis_engine/impl/compatibility/CollectionReaderAdapter.java

Not sure about this; the main documentation, in the section 1.5.1 in 
tutorials / user guides on the "contract" says

reconfigure

This method is never called by the framework, unless
an application calls it on the Engine object – in which
case it the framework propagates it to all
annotators contained in the Engine.

Its purpose is to signal that the configuration
parameters have changed. A default implementation
of this calls destroy, followed by initialize. This
is the only case where initialize would be called
more than once. Users should implement whatever
logic is needed to return the annotator to an initialized
state, including re-reading the configuration parameter
data.

So this change sounds like a change in the contract for reconfigure?

-Marshall

alally@... wrote:
> Author: alally
> Date: Tue May  1 06:56:40 2007
> New Revision: 534093
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=534093
> Log:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adam Lally (JIRA | 1 May 21:45
Picon
Favicon

[jira] Created: (UIMA-389) AnnotationBase.getSofa() throws ClassCastException

AnnotationBase.getSofa() throws ClassCastException
--------------------------------------------------

                 Key: UIMA-389
                 URL: https://issues.apache.org/jira/browse/UIMA-389
             Project: UIMA
          Issue Type: Bug
          Components: Core Java Framework
    Affects Versions: 2.1
            Reporter: Adam Lally
         Assigned To: Adam Lally
             Fix For: 2.2

In the JCAS cover class for AnnotationBase:

  public SofaFS getSofa() {
    if (AnnotationBase_Type.featOkTst && ((AnnotationBase_Type) jcasType).casFeat_sofa == null)
      this.jcasType.jcas.throwFeatMissing("sofa", "uima.tcas.Annotation");
    return (SofaFS) jcasType.ll_cas.ll_getFSForRef(addr);
  }

That last line isn't right... it should be calling getFSForRef on the value of the "sofa" feature, but
instead it is calling it on the addr field, which would be the address of the annotation.  

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marshall Schor (JIRA | 1 May 21:51
Picon
Favicon

[jira] Commented: (UIMA-387) XMI Serializer can write invalid control characters


    [
https://issues.apache.org/jira/browse/UIMA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492934
] 

Marshall Schor commented on UIMA-387:
-------------------------------------

I don't think we should (silently) change user data (i.e., replacing funny characters with spaces).  I
would prefer the XML 1.1 approach, unless someone has a reason 1.0 is needed.  

That still leaves the 0x00 character not being valid - Could we output something that was valid XML but when
read in by our deserializer would be able to be converted back to 00?  I suppose if we came up with such a
mechanism, it could be used in XML 1.0 for all the "bad" characters.  Maybe something like outputing a
special XML element we define which has a hex representation of the bad character(s)?  

How does EMF handle this?

-Marshall

> XMI Serializer can write invalid control characters
> ---------------------------------------------------
>
>                 Key: UIMA-387
>                 URL: https://issues.apache.org/jira/browse/UIMA-387
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.1
>            Reporter: Adam Lally
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Lally (JIRA | 1 May 21:57
Picon
Favicon

[jira] Closed: (UIMA-389) AnnotationBase.getSofa() throws ClassCastException


     [
https://issues.apache.org/jira/browse/UIMA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Lally closed UIMA-389.
---------------------------

    Resolution: Fixed

> AnnotationBase.getSofa() throws ClassCastException
> --------------------------------------------------
>
>                 Key: UIMA-389
>                 URL: https://issues.apache.org/jira/browse/UIMA-389
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.1
>            Reporter: Adam Lally
>         Assigned To: Adam Lally
>             Fix For: 2.2
>
>
> In the JCAS cover class for AnnotationBase:
>   public SofaFS getSofa() {
>     if (AnnotationBase_Type.featOkTst && ((AnnotationBase_Type) jcasType).casFeat_sofa == null)
>       this.jcasType.jcas.throwFeatMissing("sofa", "uima.tcas.Annotation");
>     return (SofaFS) jcasType.ll_cas.ll_getFSForRef(addr);
>   }
> That last line isn't right... it should be calling getFSForRef on the value of the "sofa" feature, but
(Continue reading)

Permalink | Reply | 0 comments |

Gmane