[jira] [Resolved] (UIMA-6385) Potential resource key clash in environments with multiple classloaders
[
https://issues.apache.org/jira/browse/UIMA-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho resolved UIMA-6385.
--
Resolution: Fixed
> Potential resource key clash in environments with multiple classloaders
> ---
>
> Key: UIMA-6385
> URL: https://issues.apache.org/jira/browse/UIMA-6385
> Project: UIMA
> Issue Type: Bug
> Components: uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.3.0uimaFIT, 3.2.1uimaFIT
>
>
> The {{ExternalResourceFactory}} internally generates a unique key for each
> resource using the method
> {{ExternalResourceFactory.uniqueResourceKey(String)}}. This method internally
> uses a static thread-safe counter which is increased for each resource.
> However, if we are in an environment where multiple instances of uimaFIT
> exists, e.g. within PEARs or OSGI environments, then it is possible that the
> same unique key is produced by two uimaFIT instances. It would also be
> possible that these keys both end up in the same resource manager and then
> the resources would override each other.
> A solution for this could be to also include some unique uimaFIT instance ID
> in the unique key, e.g. the {{System.identityHashCode(DISAMBIGUATOR)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (UIMA-6385) Potential resource key clash in environments with multiple classloaders
[
https://issues.apache.org/jira/browse/UIMA-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-6385:
-
Fix Version/s: 3.3.0uimaFIT
> Potential resource key clash in environments with multiple classloaders
> ---
>
> Key: UIMA-6385
> URL: https://issues.apache.org/jira/browse/UIMA-6385
> Project: UIMA
> Issue Type: Bug
> Components: uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.3.0uimaFIT, 3.2.1uimaFIT
>
>
> The {{ExternalResourceFactory}} internally generates a unique key for each
> resource using the method
> {{ExternalResourceFactory.uniqueResourceKey(String)}}. This method internally
> uses a static thread-safe counter which is increased for each resource.
> However, if we are in an environment where multiple instances of uimaFIT
> exists, e.g. within PEARs or OSGI environments, then it is possible that the
> same unique key is produced by two uimaFIT instances. It would also be
> possible that these keys both end up in the same resource manager and then
> the resources would override each other.
> A solution for this could be to also include some unique uimaFIT instance ID
> in the unique key, e.g. the {{System.identityHashCode(DISAMBIGUATOR)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [uima-uimafit] reckart merged pull request #162: [UIMA-6385] Potential resource key clash in environments with multiple classloaders
reckart merged pull request #162: URL: https://github.com/apache/uima-uimafit/pull/162 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [uima-uimafit] reckart opened a new pull request #162: [UIMA-6385] Potential resource key clash in environments with multiple classloaders
reckart opened a new pull request #162: URL: https://github.com/apache/uima-uimafit/pull/162 - Disambiguate the static disambiguator via its identity hash code (which should by unique for the entire JVM when there are multiple static disambiguators in different classloaders for some reason) JIRA Ticket: https://issues.apache.org/jira/browse/UIMA-6385 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [uima-uimafit] reckart merged pull request #161: [UIMA-6385] Potential resource key clash in environments with multiple classloaders
reckart merged pull request #161: URL: https://github.com/apache/uima-uimafit/pull/161 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (UIMA-5494) Ruta: problem with transitive type system import with strictImports on unix machines
[ https://issues.apache.org/jira/browse/UIMA-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Eckart de Castilho updated UIMA-5494: - Fix Version/s: 3.1.1ruta > Ruta: problem with transitive type system import with strictImports on unix > machines > > > Key: UIMA-5494 > URL: https://issues.apache.org/jira/browse/UIMA-5494 > Project: UIMA > Issue Type: Bug > Components: Ruta >Affects Versions: 2.6.0ruta >Reporter: Peter Klügl >Priority: Major > Fix For: 3.1.1ruta > > > Ruta: problem with transitive type system import with strictImports on unix > machines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (UIMA-5494) Ruta: problem with transitive type system import with strictImports on unix machines
[ https://issues.apache.org/jira/browse/UIMA-5494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435551#comment-17435551 ] Richard Eckart de Castilho commented on UIMA-5494: -- Do we have any theory about why this might happen and / or how this might be brought to a situation where it can be reproduced? > Ruta: problem with transitive type system import with strictImports on unix > machines > > > Key: UIMA-5494 > URL: https://issues.apache.org/jira/browse/UIMA-5494 > Project: UIMA > Issue Type: Bug > Components: Ruta >Affects Versions: 2.6.0ruta >Reporter: Peter Klügl >Priority: Major > > Ruta: problem with transitive type system import with strictImports on unix > machines -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (UIMA-3549) Enable strictImports by default for ruta scripts
[
https://issues.apache.org/jira/browse/UIMA-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-3549:
-
Fix Version/s: 4.0.0ruta
> Enable strictImports by default for ruta scripts
>
>
> Key: UIMA-3549
> URL: https://issues.apache.org/jira/browse/UIMA-3549
> Project: UIMA
> Issue Type: New Feature
> Components: Ruta
>Reporter: Alexandre Patry
>Priority: Major
> Fix For: 4.0.0ruta
>
>
> Strict imports should be enabled by defaults for RUTA script (see [this
> comment|https://issues.apache.org/jira/browse/UIMA-3303?focusedCommentId=13873363=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873363]
> of UIMA-3303) and disable for {{Ruta.apply}}.
> Because this change breaks backward compatiblity, it should be done when a
> new major version of RUTA is released.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (UIMA-6385) Potential resource key clash in environments with multiple classloaders
[
https://issues.apache.org/jira/browse/UIMA-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on UIMA-6385 started by Richard Eckart de Castilho.
> Potential resource key clash in environments with multiple classloaders
> ---
>
> Key: UIMA-6385
> URL: https://issues.apache.org/jira/browse/UIMA-6385
> Project: UIMA
> Issue Type: Bug
> Components: uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.2.1uimaFIT
>
>
> The {{ExternalResourceFactory}} internally generates a unique key for each
> resource using the method
> {{ExternalResourceFactory.uniqueResourceKey(String)}}. This method internally
> uses a static thread-safe counter which is increased for each resource.
> However, if we are in an environment where multiple instances of uimaFIT
> exists, e.g. within PEARs or OSGI environments, then it is possible that the
> same unique key is produced by two uimaFIT instances. It would also be
> possible that these keys both end up in the same resource manager and then
> the resources would override each other.
> A solution for this could be to also include some unique uimaFIT instance ID
> in the unique key, e.g. the {{System.identityHashCode(DISAMBIGUATOR)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [uima-uimafit] reckart opened a new pull request #161: [UIMA-6385] Potential resource key clash in environments with multiple classloaders
reckart opened a new pull request #161: URL: https://github.com/apache/uima-uimafit/pull/161 - Disambiguate the static disambiguator via its identity hash code (which should by unique for the entire JVM when there are multiple static disambiguators in different classloaders for some reason) **JIRA Ticket:** https://issues.apache.org/jira/browse/UIMA-6385 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [uima-uimafit] reckart merged pull request #160: Tie up loose branches
reckart merged pull request #160: URL: https://github.com/apache/uima-uimafit/pull/160 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [uima-uimafit] reckart opened a new pull request #160: Tie up loose branches
reckart opened a new pull request #160: URL: https://github.com/apache/uima-uimafit/pull/160 Just book-keeping by merging some branches into main which don't at this point actually introduce any changes anymore (all already was on main). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [uima-uimafit] reckart merged pull request #159: [UIMA-6392] Better delegate key generation
reckart merged pull request #159: URL: https://github.com/apache/uima-uimafit/pull/159 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work started] (UIMA-6392) Better delegate key generation
[
https://issues.apache.org/jira/browse/UIMA-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on UIMA-6392 started by Richard Eckart de Castilho.
> Better delegate key generation
> --
>
> Key: UIMA-6392
> URL: https://issues.apache.org/jira/browse/UIMA-6392
> Project: UIMA
> Issue Type: New Feature
> Components: uimaFIT
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
>Priority: Major
> Fix For: 3.3.0uimaFIT
>
>
> When building an aggregate using the uimaFIT {{AggregateBuilder}} or even the
> {{createEngine(AED, AED, ...)}} method, uimaFIT auto-generates the delegate
> keys. For example, if there is a name set in the metadata, then this is used
> and the index of the delegate is appended to it. But there are problems with
> the current approach.
> First problem is that for delegate aggregates, we simply get {{null-0}} if
> these aggregates do not have a name in their metadata. That could be improved
> at least to something like {{aggregate-0}}.
> Second problem is that the name set in the metadata is not sanitized in any
> way before being used as a delegate key. This means the name could contain
> e.g. slashes {{/}} which would then go into the qualified context name of the
> delegate and at that point it would mess up the context namespace hierarchy,
> placing delegates apparently at deeper levels than they actually are. So some
> sanitation would be called for here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [uima-uimafit] reckart opened a new pull request #159: [UIMA-6392] Better delegate key generation
reckart opened a new pull request #159: URL: https://github.com/apache/uima-uimafit/pull/159 - Improve generation of delegate keys based on the metadata name field or based on whether the delegate is a primitive or aggregate - Added unit tests for the delegate key generation - Avoid wrapping aggregates in another aggregate in the CpePipeline to avoid unnecessary deep contexts - except if there maybe CAS multipliers involved because then they wouldn't work anymore **JIRA Ticket:** https://issues.apache.org/jira/browse/UIMA-6392 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@uima.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (UIMA-5776) Calling a UIMACPP engine causes rules on prior annotations to fail
[
https://issues.apache.org/jira/browse/UIMA-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435339#comment-17435339
]
Richard Eckart de Castilho commented on UIMA-5776:
--
Could the re-index feature that was recently added to Ruta have fixed this now?
Even if it doesn't work automatically, I think it can be explicitly activated
on the Ruta engine.
[~pkluegl]?
> Calling a UIMACPP engine causes rules on prior annotations to fail
> --
>
> Key: UIMA-5776
> URL: https://issues.apache.org/jira/browse/UIMA-5776
> Project: UIMA
> Issue Type: Bug
> Components: C++ Framework, Ruta
>Reporter: Benjamin De Boe
>Assignee: Peter Klügl
>Priority: Major
> Attachments: Main.java
>
>
> We're having trouble leveraging a UIMACPP engine from Ruta. Whereas the
> ENGINE() call doesn't seem to throw any actual errors, some rules run
> afterwards don't seem to get triggered correctly, even if they involve plain
> Ruta annotations and none of the ones that (should) have been added by
> UIMACPP. It doesn't matter whether or not we supply the third argument to
> ENGINE()
>
> Here are a few tests that illustrate what we're seeing, leveraging the
> example AE provided with UIMACPP called "DaveDetector" (you'll need to make
> sure it's on your PATH to work). Each time, we should find at least one
> occurrence of the "Test" annotation in the output.
> The following scripts work:
> {{DECLARE Test;}}
> {{W\{->Test};}}
> and
> Document \{-> EXEC(DaveDetector)};
> {{DECLARE Test;}}
> {{David\{->Test};}}
> and
> {{DECLARE Test;}}
> {{W W\{->Test};}}
> And this trivial one still works as well
> {{Document \{-> EXEC(DaveDetector)}; }}
> {{DECLARE Test;}}
> {{W\{->Test};}}
> But this one doesn't:
> Document \{-> EXEC(DaveDetector)};
> {{DECLARE Test;}}
> {{W W\{->Test};}}
>
> Also attaching a test Java script that runs through these in succession
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (UIMA-6392) Better delegate key generation
Richard Eckart de Castilho created UIMA-6392:
Summary: Better delegate key generation
Key: UIMA-6392
URL: https://issues.apache.org/jira/browse/UIMA-6392
Project: UIMA
Issue Type: New Feature
Components: uimaFIT
Reporter: Richard Eckart de Castilho
Assignee: Richard Eckart de Castilho
Fix For: 3.3.0uimaFIT
When building an aggregate using the uimaFIT {{AggregateBuilder}} or even the
{{createEngine(AED, AED, ...)}} method, uimaFIT auto-generates the delegate
keys. For example, if there is a name set in the metadata, then this is used
and the index of the delegate is appended to it. But there are problems with
the current approach.
First problem is that for delegate aggregates, we simply get {{null-0}} if
these aggregates do not have a name in their metadata. That could be improved
at least to something like {{aggregate-0}}.
Second problem is that the name set in the metadata is not sanitized in any way
before being used as a delegate key. This means the name could contain e.g.
slashes {{/}} which would then go into the qualified context name of the
delegate and at that point it would mess up the context namespace hierarchy,
placing delegates apparently at deeper levels than they actually are. So some
sanitation would be called for here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
