Re: [VOTE] uimaj sdk 3.0.0 beta rc2

[Peter Klügl]

I think the problem was caused by a bug in the old beta rc and the jar
was not replaced by the staged artifact.


Now, I face compile errors because I have two classes that extend the
old FSIteratorImplBase but do not implement the getter on the comparator
yet. Should we take care of some sort of backward-compatability on
compile level here? (I don't know)


I must admit that I lost the overview of all the changes in v3. A lot to
catch up on...


Best,

Peter

Am 07.09.2017 um 21:06 schrieb Marshall Schor:
> ok, let me know if I can help... -Marshall
>
>
> On 9/7/2017 11:29 AM, Peter Klügl wrote:
>> Ah wait, I still have some version problems. The staged-release build
>> did not work as expected.
>>
>>
>> Am 07.09.2017 um 17:19 schrieb Peter Klügl:
>>> Ok, this is really strange.
>>>
>>> There are two annotations of type "Struct" in the CAS (variables view
>>> say so). The first time I call cas.getAnnotationIndex(type) only one is
>>> returned (I am using the iterable). If I "drop to frame" and call the
>>> method again, two are returned. This behavior seems to be repeated for
>>> every other rule in this test.
>>>
>>>
>>> Could it be that I corrupted the index somehow and it recovers by itself
>>> for a second call?
>>>
>>>
>>> Some help would be really appreciated. I can provide specific steps how
>>> to reproduce it.
>>>
>>>
>>> Best,
>>>
>>> Peter
>>>
>>>
>>> Am 07.09.2017 um 17:03 schrieb Peter Klügl:
 Hi,


 I finally set up some ruta-v3 version (right now for testing the rc).
 One test is failing caused by some strange inconsistent matching behavior.


 ... investigating ...


 Best,


 Peter


 PS: I put it in the uv3 folder if that's ok.


 Am 06.09.2017 um 15:41 schrieb Marshall Schor:
> Here's RC2 for uimaj-sdk 3.0.0-beta.
>
> There are many fixes and improvements since the first rc on 27 April 
> 2017, due
> to much testing.
>
> List of changes:
> https://issues.apache.org/jira/browse/UIMA/fixforversion/12339590
> 36 new Jiras (out of 51) since rc1; to see, sort by key and looke at 
> UIMA-5407
> and newer.
>
> The v3 users guide has many updates and corrections.
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheuima-1154
>
> Source and binary zip/tar staged to:
> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/artifacts/
>
> Eclipse update site (no need to download, just use this as the link in 
> Eclipse's
> install):
> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/uimaj-v3-pre-production/
>
> SVN tag: 
> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags/uimaj-3.0.0-beta/
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> -Marshall
>

[jira] [Created] (UIMA-5552) uv3: Get JCas instance in JCas class

[Richard Eckart de Castilho (JIRA)]

Richard Eckart de Castilho created UIMA-5552:


 Summary: uv3: Get JCas instance in JCas class
 Key: UIMA-5552
 URL: https://issues.apache.org/jira/browse/UIMA-5552
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 3.0.0SDK-beta
Reporter: Richard Eckart de Castilho


In the new JCas FS classes, it is no longer possible to access the JCas 
instance conveniently. With UIMA v2, is was possible to get the JCas containing 
a feature structure via `jcasType.jcas`. Now, one has to do a 
`getCAS().getJCas()` but that requires catching a CASException. It would be 
nice to have a convenience method `getJCas()` in JCas FS classes that does not 
throw an exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] uimaj sdk 3.0.0 beta rc2

[Peter Klügl]

mvn clean install svn tag - OK

mvn clean install source-release - OK

spot checked sigs - OK

spot checked notes and friends - OK

tested plugins in Eclispe Oxygen - OK

problems with compile-level compatibility (see previous mails) - not a
blocker

tested ruta-v3 with staged artefacts - OK



[ X] +1 OK to release


Peter


Am 06.09.2017 um 15:41 schrieb Marshall Schor:
> Here's RC2 for uimaj-sdk 3.0.0-beta.
>
> There are many fixes and improvements since the first rc on 27 April 2017, due
> to much testing.
>
> List of changes:
> https://issues.apache.org/jira/browse/UIMA/fixforversion/12339590
> 36 new Jiras (out of 51) since rc1; to see, sort by key and looke at UIMA-5407
> and newer.
>
> The v3 users guide has many updates and corrections.
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheuima-1154
>
> Source and binary zip/tar staged to:
> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/artifacts/
>
> Eclipse update site (no need to download, just use this as the link in 
> Eclipse's
> install):
> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/uimaj-v3-pre-production/
>
> SVN tag: 
> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags/uimaj-3.0.0-beta/
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> -Marshall
>

[jira] [Reopened] (UIMA-5323) Adjust uimaFIT v3 branch to actually build against UIMA v3

[Richard Eckart de Castilho (JIRA)]

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

Richard Eckart de Castilho reopened UIMA-5323:
--

Further adjustments needed.

> Adjust uimaFIT v3 branch to actually build against UIMA v3
> --
>
> Key: UIMA-5323
> URL: https://issues.apache.org/jira/browse/UIMA-5323
> Project: UIMA
>  Issue Type: Task
>  Components: uimaFIT, uimaFIT-Maven-Plugin
>Reporter: Richard Eckart de Castilho
>Assignee: Richard Eckart de Castilho
> Fix For: 3.0.0uimaFIT
>
>
> Adjust uimaFIT v3 branch to actually build against UIMA v3. This might entail 
> code changes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath

[Richard Eckart de Castilho (JIRA)]

Richard Eckart de Castilho created UIMA-5553:


 Summary: uv3: Ability to set just a parent classloader, but not 
classpath
 Key: UIMA-5553
 URL: https://issues.apache.org/jira/browse/UIMA-5553
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 3.0.0SDK-beta
Reporter: Richard Eckart de Castilho


uimaFIT tries to set a custom classloader on a resource manager - but it does 
so without adding any additional classpath entries:

{noformat}
  ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
  resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(), "", 
true);
  return resMgr;
{noformat}

With UV3, this call now produces a warning:

{noformat}
org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping 
adding "" to URLs
{noformat}

It would be nice to have a `resMgr.setExtensionClassPath` method that just sets 
the parent loader but without trying to add URLs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jenkins build is unstable: UIMA-uimaFIT v3 » Apache UIMA uimaFIT - Legacy uimaFIT support #25

[Apache Jenkins Server]

See 

Jenkins build is unstable: UIMA-uimaFIT v3 » Apache UIMA uimaFIT - Core #25

[Apache Jenkins Server]

See 

Jenkins build is unstable: UIMA-uimaFIT v3 #25

[Apache Jenkins Server]

See 

[jira] [Created] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection

[Richard Eckart de Castilho (JIRA)]

Richard Eckart de Castilho created UIMA-5554:


 Summary: Strange exception when trying to get JCas FS class 
through reflection
 Key: UIMA-5554
 URL: https://issues.apache.org/jira/browse/UIMA-5554
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 3.0.0SDK-beta
Reporter: Richard Eckart de Castilho


I am trying to get a class object for a JCas FS type using reflection:

{noformat}
Class.forName(typeName);
{noformat}

However, it produces this strange error.

{noformat}
java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
...
Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field "sofa" 
is being initialized by non-framework (user) code before Type System Commit for 
a type system with a corresponding type. Either change the user load code to 
not do initialize, or to defer it until after the type system commit.
at 
org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2575)
at 
org.apache.uima.jcas.cas.AnnotationBase.(AnnotationBase.java:71)
... 27 more
{noformat}

Is it considered harmful to try getting a class object for a JCas FS class?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jenkins build is back to stable : UIMA-uimaFIT v3 » Apache UIMA uimaFIT - Legacy uimaFIT support #26

[Apache Jenkins Server]

See 

Jenkins build is back to stable : UIMA-uimaFIT v3 » Apache UIMA uimaFIT - Core #26

[Apache Jenkins Server]

See 

Build failed in Jenkins: UIMA-uimaFIT v3 #26

[Apache Jenkins Server]

See 


Changes:

[rec] [UIMA-5323] Adjust uimaFIT v3 branch to actually build against UIMA v3

- Update CAS dump files to changes in toString() method for feature structures

[rec] [UIMA-5553] uv3: Ability to set just a parent classloader, but not 
classpath

- Take into account logged warning for the time being

--
[...truncated 426.29 KB...]
[WARNING] 
:82:
 warning: no @throws for java.lang.Exception
[WARNING] public static void main(String[] args) throws Exception {
[WARNING] ^
[WARNING] 
:72:
 warning: no @param for args
[WARNING] public static void main(String[] args) throws Exception {
[WARNING] ^
[WARNING] 
:72:
 warning: no @throws for java.lang.Exception
[WARNING] public static void main(String[] args) throws Exception {
[WARNING] ^
[WARNING] 
:36:
 warning: no @param for 
[WARNING] public static  T initializeBean(AutowireCapableBeanFactory 
aBeanFactory, T aBean, String aName) {
[WARNING] ^
[WARNING] 
:36:
 warning: no @param for aBeanFactory
[WARNING] public static  T initializeBean(AutowireCapableBeanFactory 
aBeanFactory, T aBean, String aName) {
[WARNING] ^
[WARNING] 
:36:
 warning: no @param for aBean
[WARNING] public static  T initializeBean(AutowireCapableBeanFactory 
aBeanFactory, T aBean, String aName) {
[WARNING] ^
[WARNING] 
:36:
 warning: no @param for aName
[WARNING] public static  T initializeBean(AutowireCapableBeanFactory 
aBeanFactory, T aBean, String aName) {
[WARNING] ^
[WARNING] 
:36:
 warning: no @return
[WARNING] public static  T initializeBean(AutowireCapableBeanFactory 
aBeanFactory, T aBean, String aName) {
[WARNING] ^
[WARNING] 
:46:
 warning: no @param for aResource
[WARNING] public static Resource initResource(Resource aResource, 
ApplicationContext aApplicationContext) {
[WARNING] ^
[WARNING] 
:46:
 warning: no @param for aApplicationContext
[WARNING] public static Resource initResource(Resource aResource, 
ApplicationContext aApplicationContext) {
[WARNING] ^
[WARNING] 
:46:
 warning: no @return
[WARNING] public static Resource initResource(Resource aResource, 
ApplicationContext aApplicationContext) {
[WARNING] ^
[WARNING] 
:116:
 warning: no @param for aProject
[WARNING] public static String getClassName(MavenProject aProject, String 
aFile) {
[WARNING] ^
[WARNING] 
:116:
 warning: no @param for aFile
[WARNING] public static String getClassName(MavenProject aProject, String 
aFile) {
[WARNING] ^
[WARNING] 
:116:
 warning: no @return
[WARNING] public static String getClassName(MavenProject aProject, String 
aFile) {
[WARNING] ^
[WARNING] 
:126:
 warning: no @param for aProject
[WARNING] public static URLClassLoader getClassloader(MavenProject aProject, 
Log aLog)
[WARNING] 

[jira] [Created] (UIMA-5555) ExternalResourceFactoryTest hangs at some tests due to remote URL accesses

[Richard Eckart de Castilho (JIRA)]

Richard Eckart de Castilho created UIMA-:


 Summary: ExternalResourceFactoryTest hangs at some tests due to 
remote URL accesses
 Key: UIMA-
 URL: https://issues.apache.org/jira/browse/UIMA-
 Project: UIMA
  Issue Type: Bug
  Components: uimaFIT
Affects Versions: 3.0.0uimaFIT
Reporter: Richard Eckart de Castilho


ExternalResourceFactoryTest hangs for a while at some tests due to remote URL 
accesses.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Jenkins build is back to normal : UIMA-uimaFIT v3 #27

[Apache Jenkins Server]

See 

[jira] [Created] (UIMA-5556) uv3: Logging substitution does not work consistently

[Richard Eckart de Castilho (JIRA)]

Richard Eckart de Castilho created UIMA-5556:


 Summary: uv3: Logging substitution does not work consistently
 Key: UIMA-5556
 URL: https://issues.apache.org/jira/browse/UIMA-5556
 Project: UIMA
  Issue Type: Bug
  Components: Core Java Framework
Affects Versions: 3.0.0SDK-beta
Reporter: Richard Eckart de Castilho


The substitution of values in UIMA logging does not work consistently. E.g. for 
the following code

{noformat}
  UIMAFramework.getLogger().warn("Skipping adding \"{0}\" to URLs", p);
{noformat}

Depending on the configured logging backend, I get different messages. E.g. 
with SLF4J, I get the broken:

{noformat}
2017-09-08 14:45:42  WARN [main] (Misc) - Skipping adding "{0}" to URLs
{noformat}

while with what (I suppose) is the default UIMA logger used in the uimaFIT 
maven plugin, I get the correct

{noformat}
[WARNING] Skipping adding "" to URLs
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (UIMA-5557) uv3: FSArray accessors seem not to be correctly generated

[Richard Eckart de Castilho (JIRA)]

Richard Eckart de Castilho created UIMA-5557:


 Summary: uv3: FSArray accessors seem not to be correctly generated
 Key: UIMA-5557
 URL: https://issues.apache.org/jira/browse/UIMA-5557
 Project: UIMA
  Issue Type: Bug
  Components: jcasgen-maven-plugin
Affects Versions: 3.0.0SDK-beta
Reporter: Richard Eckart de Castilho


With the UIMAv3 jcasgen, at runtime, I am seeing messages such as

{noformat}
2017-09-08 15:00:29  WARN [main] (FSClassRegistry) - CAS type system type 
"de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Compound" defines field 
"splits" with range "class org.apache.uima.jcas.cas.FSArray", but JCas getter 
method is returning "interface java.util.List" which is not a subtype of the 
declared range.
{noformat}

A user on the users mailing list reported a similar message when trying out 
UIMAv3:

{noformat}
JCAS range type uima.cas.FSArray for feature ... does not match the CAS range 
type uima.cas.StringArray for the feature
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] uimaj sdk 3.0.0 beta rc2

[Richard Eckart de Castilho]

On 06.09.2017, at 16:41, Marshall Schor  wrote:
> 
> Here's RC2 for uimaj-sdk 3.0.0-beta.

So finally I have set up a DKPro Core branch to build against UIMAv3 and also 
updated
the uimaFIT v3 branch to build again.

Doing so, I found a couple of things and have opened issues for them.

We could vote through the beta despite known issues of course in an attempt to
get further exposure and feedback. Or would you prefer to address 
internally-detected
issues first?

Best,

-- Richard

[jira] [Commented] (UIMA-5557) uv3: FSArray accessors seem not to be correctly generated

[Richard Eckart de Castilho (JIRA)]

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

Richard Eckart de Castilho commented on UIMA-5557:
--

The two cases are probably different.

In my case (`Compound`), there is a customized JCas FS class. It contains the 
auto-generated methods:

{noformat}
  /** getter for splits - gets A word that can be decomposed into different 
parts.
   * @generated
   * @return value of the feature 
   */
  public FSArray getSplits() { return 
(FSArray)(_getFeatureValueNc(_FI_splits));}

  /** setter for splits - sets A word that can be decomposed into different 
parts. 
   * @generated
   * @param v value to set into the feature 
   */
  public void setSplits(FSArray v) {
_setFeatureValueNcWj(_FI_splits, v);
  } 
{noformat}

But it also contains a custom method:

{noformat}
  private List getSplits(final Split[] splits, final boolean 
includeMorpheme,
  CompoundSplitLevel splitLevel) ...
{noformat}

I assume that the warning comes because the custom method (which is obviously 
not a Java bean getter) returns a `List` instead of `FSArray`.

> uv3: FSArray accessors seem not to be correctly generated
> -
>
> Key: UIMA-5557
> URL: https://issues.apache.org/jira/browse/UIMA-5557
> Project: UIMA
>  Issue Type: Bug
>  Components: jcasgen-maven-plugin
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> With the UIMAv3 jcasgen, at runtime, I am seeing messages such as
> {noformat}
> 2017-09-08 15:00:29  WARN [main] (FSClassRegistry) - CAS type system type 
> "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Compound" defines field 
> "splits" with range "class org.apache.uima.jcas.cas.FSArray", but JCas getter 
> method is returning "interface java.util.List" which is not a subtype of the 
> declared range.
> {noformat}
> A user on the users mailing list reported a similar message when trying out 
> UIMAv3:
> {noformat}
> JCAS range type uima.cas.FSArray for feature ... does not match the CAS range 
> type uima.cas.StringArray for the feature
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (UIMA-5557) uv3: FSArray accessors seem not to be correctly generated

[Richard Eckart de Castilho (JIRA)]

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

Richard Eckart de Castilho edited comment on UIMA-5557 at 9/8/17 1:22 PM:
--

The two cases (mine and the one reported on the mailing list) are probably 
different.

In my case (`Compound`), there is a customized JCas FS class. It contains the 
auto-generated methods:

{noformat}
  /** getter for splits - gets A word that can be decomposed into different 
parts.
   * @generated
   * @return value of the feature 
   */
  public FSArray getSplits() { return 
(FSArray)(_getFeatureValueNc(_FI_splits));}

  /** setter for splits - sets A word that can be decomposed into different 
parts. 
   * @generated
   * @param v value to set into the feature 
   */
  public void setSplits(FSArray v) {
_setFeatureValueNcWj(_FI_splits, v);
  } 
{noformat}

But it also contains a custom method:

{noformat}
  private List getSplits(final Split[] splits, final boolean 
includeMorpheme,
  CompoundSplitLevel splitLevel) ...
{noformat}

I assume that the warning comes because the custom method (which is obviously 
not a Java bean getter) returns a `List` instead of `FSArray`.


was (Author: rec):
The two cases are probably different.

In my case (`Compound`), there is a customized JCas FS class. It contains the 
auto-generated methods:

{noformat}
  /** getter for splits - gets A word that can be decomposed into different 
parts.
   * @generated
   * @return value of the feature 
   */
  public FSArray getSplits() { return 
(FSArray)(_getFeatureValueNc(_FI_splits));}

  /** setter for splits - sets A word that can be decomposed into different 
parts. 
   * @generated
   * @param v value to set into the feature 
   */
  public void setSplits(FSArray v) {
_setFeatureValueNcWj(_FI_splits, v);
  } 
{noformat}

But it also contains a custom method:

{noformat}
  private List getSplits(final Split[] splits, final boolean 
includeMorpheme,
  CompoundSplitLevel splitLevel) ...
{noformat}

I assume that the warning comes because the custom method (which is obviously 
not a Java bean getter) returns a `List` instead of `FSArray`.

> uv3: FSArray accessors seem not to be correctly generated
> -
>
> Key: UIMA-5557
> URL: https://issues.apache.org/jira/browse/UIMA-5557
> Project: UIMA
>  Issue Type: Bug
>  Components: jcasgen-maven-plugin
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> With the UIMAv3 jcasgen, at runtime, I am seeing messages such as
> {noformat}
> 2017-09-08 15:00:29  WARN [main] (FSClassRegistry) - CAS type system type 
> "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Compound" defines field 
> "splits" with range "class org.apache.uima.jcas.cas.FSArray", but JCas getter 
> method is returning "interface java.util.List" which is not a subtype of the 
> declared range.
> {noformat}
> A user on the users mailing list reported a similar message when trying out 
> UIMAv3:
> {noformat}
> JCAS range type uima.cas.FSArray for feature ... does not match the CAS range 
> type uima.cas.StringArray for the feature
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] uimaj sdk 3.0.0 beta rc2

[Marshall Schor]

happy to address all issues you find in testing!  I don't see a benefit in
voting it through early.

Thanks for all the testing - that's just what it needs :-)

-Marshall


On 9/8/2017 9:15 AM, Richard Eckart de Castilho wrote:
> On 06.09.2017, at 16:41, Marshall Schor  wrote:
>> Here's RC2 for uimaj-sdk 3.0.0-beta.
> So finally I have set up a DKPro Core branch to build against UIMAv3 and also 
> updated
> the uimaFIT v3 branch to build again.
>
> Doing so, I found a couple of things and have opened issues for them.
>
> We could vote through the beta despite known issues of course in an attempt to
> get further exposure and feedback. Or would you prefer to address 
> internally-detected
> issues first?
>
> Best,
>
> -- Richard
>
>

Re: [VOTE] uimaj sdk 3.0.0 beta rc2

[Marshall Schor]

I'm curious whether the newer iterator things in v3 address the use case you
extended FSIteratorImplBase for.  Can you point to some code that is doing this
extension or some other info about it?

Thanks. -Marshall


On 9/8/2017 3:02 AM, Peter Klügl wrote:
> I think the problem was caused by a bug in the old beta rc and the jar
> was not replaced by the staged artifact.
>
>
> Now, I face compile errors because I have two classes that extend the
> old FSIteratorImplBase but do not implement the getter on the comparator
> yet. Should we take care of some sort of backward-compatability on
> compile level here? (I don't know)
>
>
> I must admit that I lost the overview of all the changes in v3. A lot to
> catch up on...
>
>
> Best,
>
> Peter
>
> Am 07.09.2017 um 21:06 schrieb Marshall Schor:
>> ok, let me know if I can help... -Marshall
>>
>>
>> On 9/7/2017 11:29 AM, Peter Klügl wrote:
>>> Ah wait, I still have some version problems. The staged-release build
>>> did not work as expected.
>>>
>>>
>>> Am 07.09.2017 um 17:19 schrieb Peter Klügl:
 Ok, this is really strange.

 There are two annotations of type "Struct" in the CAS (variables view
 say so). The first time I call cas.getAnnotationIndex(type) only one is
 returned (I am using the iterable). If I "drop to frame" and call the
 method again, two are returned. This behavior seems to be repeated for
 every other rule in this test.


 Could it be that I corrupted the index somehow and it recovers by itself
 for a second call?


 Some help would be really appreciated. I can provide specific steps how
 to reproduce it.


 Best,

 Peter


 Am 07.09.2017 um 17:03 schrieb Peter Klügl:
> Hi,
>
>
> I finally set up some ruta-v3 version (right now for testing the rc).
> One test is failing caused by some strange inconsistent matching behavior.
>
>
> ... investigating ...
>
>
> Best,
>
>
> Peter
>
>
> PS: I put it in the uv3 folder if that's ok.
>
>
> Am 06.09.2017 um 15:41 schrieb Marshall Schor:
>> Here's RC2 for uimaj-sdk 3.0.0-beta.
>>
>> There are many fixes and improvements since the first rc on 27 April 
>> 2017, due
>> to much testing.
>>
>> List of changes:
>> https://issues.apache.org/jira/browse/UIMA/fixforversion/12339590
>> 36 new Jiras (out of 51) since rc1; to see, sort by key and looke at 
>> UIMA-5407
>> and newer.
>>
>> The v3 users guide has many updates and corrections.
>>
>> Maven artifacts:
>> https://repository.apache.org/content/repositories/orgapacheuima-1154
>>
>> Source and binary zip/tar staged to:
>> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/artifacts/
>>
>> Eclipse update site (no need to download, just use this as the link in 
>> Eclipse's
>> install):
>> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/uimaj-v3-pre-production/
>>
>> SVN tag: 
>> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags/uimaj-3.0.0-beta/
>>
>> Please vote on release:
>>
>> [ ] +1 OK to release
>> [ ] 0 Don't care
>> [ ] -1 Not OK to release, because ...
>>
>> Thanks.
>>
>> -Marshall
>>
>

[jira] [Updated] (UIMA-5552) uv3: Get JCas instance in JCas class

[Marshall Schor (JIRA)]

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

Marshall Schor updated UIMA-5552:
-
Fix Version/s: 3.0.0SDK-beta

> uv3: Get JCas instance in JCas class
> 
>
> Key: UIMA-5552
> URL: https://issues.apache.org/jira/browse/UIMA-5552
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
> Fix For: 3.0.0SDK-beta
>
>
> In the new JCas FS classes, it is no longer possible to access the JCas 
> instance conveniently. With UIMA v2, is was possible to get the JCas 
> containing a feature structure via `jcasType.jcas`. Now, one has to do a 
> `getCAS().getJCas()` but that requires catching a CASException. It would be 
> nice to have a convenience method `getJCas()` in JCas FS classes that does 
> not throw an exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (UIMA-5552) uv3: Get JCas instance in JCas class

[Marshall Schor (JIRA)]

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

Marshall Schor resolved UIMA-5552.
--
Resolution: Fixed

excellent suggestion!  I added a getJCas() method with a default impl to the 
FeatureStructure interface; is efficient, no exception thrown, etc.

> uv3: Get JCas instance in JCas class
> 
>
> Key: UIMA-5552
> URL: https://issues.apache.org/jira/browse/UIMA-5552
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
> Fix For: 3.0.0SDK-beta
>
>
> In the new JCas FS classes, it is no longer possible to access the JCas 
> instance conveniently. With UIMA v2, is was possible to get the JCas 
> containing a feature structure via `jcasType.jcas`. Now, one has to do a 
> `getCAS().getJCas()` but that requires catching a CASException. It would be 
> nice to have a convenience method `getJCas()` in JCas FS classes that does 
> not throw an exception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath

[Marshall Schor (JIRA)]

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

Marshall Schor commented on UIMA-5553:
--

Are you asking for a method like resMgr.setExtensionClassPath(ClassLoader 
parent, boolean resolveResource) that acts just like the one with the 3 args, 
but doesn't give the warning message?

> uv3: Ability to set just a parent classloader, but not classpath
> 
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does 
> so without adding any additional classpath entries:
> {noformat}
>   ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
>   resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(), 
> "", true);
>   return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping 
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just 
> sets the parent loader but without trying to add URLs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath

[Marshall Schor (JIRA)]

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

Marshall Schor edited comment on UIMA-5553 at 9/8/17 9:11 PM:
--

Are you asking for a method like resMgr.setExtensionClassPath(ClassLoader 
parent, boolean resolveResource) that acts just like the one with the 3 args, 
but doesn't give the warning message?

These calls create a new instance of a subtype of the URLClassLoader (typically 
initialized with the classpath supplied).  


was (Author: schor):
Are you asking for a method like resMgr.setExtensionClassPath(ClassLoader 
parent, boolean resolveResource) that acts just like the one with the 3 args, 
but doesn't give the warning message?

> uv3: Ability to set just a parent classloader, but not classpath
> 
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does 
> so without adding any additional classpath entries:
> {noformat}
>   ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
>   resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(), 
> "", true);
>   return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping 
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just 
> sets the parent loader but without trying to add URLs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection

[Marshall Schor (JIRA)]

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

Marshall Schor commented on UIMA-5554:
--

It's not harmful, but there's an "ordering" issue, due to JCas static 
initializer code.  This can be solved in 2 ways.

Class.forName has 2 flavors.  The "plain" flavor loads the class *and 
initializes* it. That is, it runs the static initializers among other things.

In UIMA V3, these initializers reference information about the type system that 
defines the corresponding UIMA Type for this JCas classes.  Therefore, these 
types need to be "installed" - that is committed :-), before the class 
initialization happens.

So, you can do a Class.forName("myJCasClassName", false, 
this.getClass().getClassLoader()), which skips the initialization (the *false* 
argument says to not do the initialization.  The initialization will happen on 
first use, at which time the type system must be committed.

The other way to get Class.forname("myJCasClassName") (the plain variation) to 
work is to first commit a type system that defines the type this JCas class is 
covering.  

I hope that's clear; if not, please ask more questions.

> Strange exception when trying to get JCas FS class through reflection
> -
>
> Key: UIMA-5554
> URL: https://issues.apache.org/jira/browse/UIMA-5554
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> I am trying to get a class object for a JCas FS type using reflection:
> {noformat}
> Class.forName(typeName);
> {noformat}
> However, it produces this strange error.
> {noformat}
> java.lang.ExceptionInInitializerError
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:264)
> ...
> Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field "sofa" 
> is being initialized by non-framework (user) code before Type System Commit 
> for a type system with a corresponding type. Either change the user load code 
> to not do initialize, or to defer it until after the type system commit.
>   at 
> org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2575)
>   at 
> org.apache.uima.jcas.cas.AnnotationBase.(AnnotationBase.java:71)
>   ... 27 more
> {noformat}
> Is it considered harmful to try getting a class object for a JCas FS class?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Build failed in Jenkins: UIMA-v3-sdk #213

[Apache Jenkins Server]

See 


Changes:

[schor] [UIMA-5552] make a convenience method on all Feature Structures, 
getJCas() which returns the JCas view where the Feature Structure was created, 
no exception thrown; a default method

--
[...truncated 294.19 KB...]
A 
uimaj-json\src\test\resources\CasSerialization\expected\xmi\topExpandedNamesNoViews.xml
A 
uimaj-json\src\test\resources\CasSerialization\expected\xmi\topWithNamedViewOmits.xml
A 
uimaj-json\src\test\resources\CasSerialization\expected\xmi\nameSpaceNoCollsionFiltered.xml
A uimaj-json\src\test\java
A uimaj-json\src\test\java\org
A uimaj-json\src\test\java\org\apache
A uimaj-json\src\test\java\org\apache\uima
A uimaj-json\src\test\java\org\apache\uima\resource
A uimaj-json\src\test\java\org\apache\uima\resource\metadata
A uimaj-json\src\test\java\org\apache\uima\resource\metadata\impl
A 
uimaj-json\src\test\java\org\apache\uima\resource\metadata\impl\TestFruitObject.java
A 
uimaj-json\src\test\java\org\apache\uima\resource\metadata\impl\TestFruitBagObject.java
A uimaj-json\src\test\java\org\apache\uima\json
A 
uimaj-json\src\test\java\org\apache\uima\json\JsonMetaDataObjectTest.java
A 
uimaj-json\src\test\java\org\apache\uima\json\JsonXmiCasSerializerTest.java
A 
uimaj-json\src\test\java\org\apache\uima\json\JsonCasSerializerTest.java
A uimaj-json\src\test\java\org\apache\uima\test
A uimaj-json\src\test\java\org\apache\uima\test\AllTypes.java
A uimaj-json\src\test\java\org\apache\uima\test\RefTypes.java
A uimaj-json\src\main
A uimaj-json\src\main\java
A uimaj-json\src\main\java\org
A uimaj-json\src\main\java\org\apache
A uimaj-json\src\main\java\org\apache\uima
A uimaj-json\src\main\java\org\apache\uima\json
A uimaj-json\src\main\java\org\apache\uima\json\JsonCasSerializer.java
A uimaj-json\src\main\java\org\apache\uima\json\impl
A 
uimaj-json\src\main\java\org\apache\uima\json\impl\MetaDataObjectSerializer_json.java
A 
uimaj-json\src\main\java\org\apache\uima\json\impl\JsonContentHandlerJacksonWrapper.java
A 
uimaj-json\src\main\java\org\apache\uima\json\JsonMetaDataSerializer.java
A uimaj-json\pom.xml
A uimaj-eclipse-feature-tools
AUuimaj-eclipse-feature-tools\.project
AUuimaj-eclipse-feature-tools\feature.properties
A uimaj-eclipse-feature-tools\src
A uimaj-eclipse-feature-tools\src\main
A uimaj-eclipse-feature-tools\src\main\resources
A uimaj-eclipse-feature-tools\src\main\resources\feature.xml
AUuimaj-eclipse-feature-tools\build.properties
A uimaj-eclipse-feature-tools\pom.xml
A uimaj-eclipse-feature-tools\marker-file-identifying-eclipse-feature
AUuimaj-eclipse-feature-tools\uima-eclipse-user-agreement.html
A NOTICE
A LICENSE
A jVinci
AUjVinci\pom.xml
A jVinci\src
A jVinci\src\test
A jVinci\src\test\java
A jVinci\src\test\resources
A jVinci\src\main
A jVinci\src\main\resources
A jVinci\src\main\java
A jVinci\src\main\java\org
A jVinci\src\main\java\org\apache
A jVinci\src\main\java\org\apache\vinci
A jVinci\src\main\java\org\apache\vinci\debug
AUjVinci\src\main\java\org\apache\vinci\debug\Debug.java
AUjVinci\src\main\java\org\apache\vinci\debug\FatalException.java
AU
jVinci\src\main\java\org\apache\vinci\debug\AssertionFailedException.java
A jVinci\src\main\java\org\apache\vinci\transport
AUjVinci\src\main\java\org\apache\vinci\transport\VinciServable.java
AU
jVinci\src\main\java\org\apache\vinci\transport\VinciServableAdapter.java
A jVinci\src\main\java\org\apache\vinci\transport\util
AU
jVinci\src\main\java\org\apache\vinci\transport\util\StreamMaterializer.java
AUjVinci\src\main\java\org\apache\vinci\transport\util\UTFConverter.java
AU
jVinci\src\main\java\org\apache\vinci\transport\util\TransportableConverter.java
AUjVinci\src\main\java\org\apache\vinci\transport\util\XMLConverter.java
AU
jVinci\src\main\java\org\apache\vinci\transport\util\Base64Converter.java
AU
jVinci\src\main\java\org\apache\vinci\transport\util\Base64FormatException.java
AUjVinci\src\main\java\org\apache\vinci\transport\FrameTransporter.java
A jVinci\src\main\java\org\apache\vinci\transport\document
AU
jVinci\src\main\java\org\apache\vinci\transport\document\XTalkToSAX.java
AU
jVinci\src\main\java\org\apache\vinci\transport\document\AFrameLeaf.java
AU
jVinci\src\main\java\org\apache\vinci\transport\document\XMLToXTalk.java
AUjVinci\src\main\java\org\apache\vinci\transport\docum

[jira] [Commented] (UIMA-5557) uv3: FSArray accessors seem not to be correctly generated

[Marshall Schor (JIRA)]

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

Marshall Schor commented on UIMA-5557:
--

V3 has a "checker" that looks at the JCas class definition (using reflection) 
and tries to validate things.  In this case, it sees a method that starts with 
get and is followed by a capitalized feature name, and makes an (in this case, 
incorrect) assumption that this is a getter for a UIMA feature.  

This "error" doesn't cause a "throw" - it is merely noted, and things continue 
on...

I probably should improve this a bit, by (for gets) seeing if the argument list 
is either empty or a single item. (if the feature is an array),  and for sets, 
the same, but with the an extra argument being the value to set. 

> uv3: FSArray accessors seem not to be correctly generated
> -
>
> Key: UIMA-5557
> URL: https://issues.apache.org/jira/browse/UIMA-5557
> Project: UIMA
>  Issue Type: Bug
>  Components: jcasgen-maven-plugin
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> With the UIMAv3 jcasgen, at runtime, I am seeing messages such as
> {noformat}
> 2017-09-08 15:00:29  WARN [main] (FSClassRegistry) - CAS type system type 
> "de.tudarmstadt.ukp.dkpro.core.api.segmentation.type.Compound" defines field 
> "splits" with range "class org.apache.uima.jcas.cas.FSArray", but JCas getter 
> method is returning "interface java.util.List" which is not a subtype of the 
> declared range.
> {noformat}
> A user on the users mailing list reported a similar message when trying out 
> UIMAv3:
> {noformat}
> JCAS range type uima.cas.FSArray for feature ... does not match the CAS range 
> type uima.cas.StringArray for the feature
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] uimaj sdk 3.0.0 beta rc2

[Marshall Schor]

I will be cancelling the vote, but would encourage everyone to post about any
issues and/or difficulties they are finding in this candidate.

-Marshall


On 9/6/2017 9:41 AM, Marshall Schor wrote:
> Here's RC2 for uimaj-sdk 3.0.0-beta.
>
> There are many fixes and improvements since the first rc on 27 April 2017, due
> to much testing.
>
> List of changes:
> https://issues.apache.org/jira/browse/UIMA/fixforversion/12339590
> 36 new Jiras (out of 51) since rc1; to see, sort by key and looke at UIMA-5407
> and newer.
>
> The v3 users guide has many updates and corrections.
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapacheuima-1154
>
> Source and binary zip/tar staged to:
> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/artifacts/
>
> Eclipse update site (no need to download, just use this as the link in 
> Eclipse's
> install):
> https://dist.apache.org/repos/dist/dev/uima/uimaj/3.0.0-beta-rc2/uimaj-v3-pre-production/
>
> SVN tag: 
> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags/uimaj-3.0.0-beta/
>
> Please vote on release:
>
> [ ] +1 OK to release
> [ ] 0 Don't care
> [ ] -1 Not OK to release, because ...
>
> Thanks.
>
> -Marshall
>
>

Build failed in Jenkins: UIMA-v3-sdk #214

[Apache Jenkins Server]

See 


Changes:

[schor] no Jira rollback to 3.0.0-beta-SNAPSHOT for another rc

--
[...truncated 2.20 MB...]
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:registry: checking for updates from central
[INFO] artifact org.eclipse:osgi: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse:osgi: checking for updates from central
[INFO] artifact org.eclipse.core:runtime: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.core:runtime: checking for updates from central
[INFO] artifact org.eclipse:ui: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse:ui: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.swt:org.eclipse.swt.win32.win32.x86: checking for 
updates from eclipsePlugins
[INFO] artifact org.eclipse.swt:org.eclipse.swt.win32.win32.x86: checking for 
updates from central
[INFO] artifact org.eclipse.ui:ide: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse.ui:ide: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse:osgi: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse:osgi: checking for updates from central
[INFO] artifact org.eclipse.core:commands: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.core:commands: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.ui:views: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse.ui:views: checking for updates from central
[INFO] artifact org.eclipse.ui.workbench:texteditor: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.ui.workbench:texteditor: checking for updates from 
central
[INFO] artifact org.eclipse.jface:text: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse.jface:text: checking for updates from central
[INFO] artifact org.eclipse.core:commands: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.core:commands: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.jdt:launching: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.jdt:launching: checking for updates from central
[INFO] artifact org.eclipse.equinox:app: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:app: checking for updates from central
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:registry: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.core:runtime: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.core:runtime: checking for updates from central
[INFO] artifact org.eclipse:osgi: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse:osgi: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.core:jobs: checking for updates from eclipsePlugins
[INFO] artifact org.eclipse.core:jobs: checking for updates from central
[INFO] artifact org.eclipse.equinox:common: checking for updates from 
eclipsePlugins
[INFO] artifact org.eclipse.equinox:common: checking for updates from central
[INFO] artifact org.eclipse.equinox:registry: checking for updates from 
eclipsePlugins
[INFO] artifact 

[jira] [Commented] (UIMA-5553) uv3: Ability to set just a parent classloader, but not classpath

[Richard Eckart de Castilho (JIRA)]

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

Richard Eckart de Castilho commented on UIMA-5553:
--

{quote}Are you asking for a method like 
resMgr.setExtensionClassPath(ClassLoader parent, boolean resolveResource) that 
acts just like the one with the 3 args, but doesn't give the warning 
message?{quote}

Yes, exactly. 

> uv3: Ability to set just a parent classloader, but not classpath
> 
>
> Key: UIMA-5553
> URL: https://issues.apache.org/jira/browse/UIMA-5553
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> uimaFIT tries to set a custom classloader on a resource manager - but it does 
> so without adding any additional classpath entries:
> {noformat}
>   ResourceManager resMgr = UIMAFramework.newDefaultResourceManager();
>   resMgr.setExtensionClassPath(ClassUtils.getDefaultClassLoader(), 
> "", true);
>   return resMgr;
> {noformat}
> With UV3, this call now produces a warning:
> {noformat}
> org.apache.uima.internal.util.Misc addUrlsFromPath(257) WARNING: Skipping 
> adding "" to URLs
> {noformat}
> It would be nice to have a `resMgr.setExtensionClassPath` method that just 
> sets the parent loader but without trying to add URLs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (UIMA-5554) Strange exception when trying to get JCas FS class through reflection

[Richard Eckart de Castilho (JIRA)]

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

Richard Eckart de Castilho commented on UIMA-5554:
--

I am currently using this option

{noformat}
Class.forName("myJCasClassName", false, this.getClass().getClassLoader())
{noformat}

It just seems a bit strange that a normal `Class.forName()` call fails with 
such an error. I didn't even try to do anything with the sofa although the 
error message says "A JCas class field "sofa" is being initialized...". 
Shouldn't the sofa be only set when I actually create an instance of the class, 
i.e. in the constructor?

> Strange exception when trying to get JCas FS class through reflection
> -
>
> Key: UIMA-5554
> URL: https://issues.apache.org/jira/browse/UIMA-5554
> Project: UIMA
>  Issue Type: Bug
>  Components: Core Java Framework
>Affects Versions: 3.0.0SDK-beta
>Reporter: Richard Eckart de Castilho
>
> I am trying to get a class object for a JCas FS type using reflection:
> {noformat}
> Class.forName(typeName);
> {noformat}
> However, it produces this strange error.
> {noformat}
> java.lang.ExceptionInInitializerError
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:264)
> ...
> Caused by: org.apache.uima.cas.CASRuntimeException: A JCas class field "sofa" 
> is being initialized by non-framework (user) code before Type System Commit 
> for a type system with a corresponding type. Either change the user load code 
> to not do initialize, or to defer it until after the type system commit.
>   at 
> org.apache.uima.cas.impl.TypeSystemImpl.getAdjustedFeatureOffset(TypeSystemImpl.java:2575)
>   at 
> org.apache.uima.jcas.cas.AnnotationBase.(AnnotationBase.java:71)
>   ... 27 more
> {noformat}
> Is it considered harmful to try getting a class object for a JCas FS class?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)