reckart opened a new issue, #431:
URL: https://github.com/apache/uima-uimaj/issues/431
**Describe the bug**
When using a PEAR file, UIMA will typically first use classes from the PEAR
before loading classes through the default class loader. This allows PEARs to
keep private versions of libraries that may conflict with those embedded in
other PEARs.
However, a problem occurs if an SPI provider is defined outside a PEAR and
inside a PEAR at the same time. Specifically:
* Outside the PEAR, we already use UIMA 3.6.0 and the `TypeSystemProvider`
SPI. So we have some `/META-INF/services/...TypeSystemProvider` file that
points to `my.FooTypeSystemProvider`
* Inside the PEAR, we have an older version of that
`my.FooTypeSystemProvider` (e.g. built against UIMA 3.5.0) and this class does
not yet implement the `TypeSystemProvider` interface
* The Java `ServiceLoader` will find the
`/META-INF/services/...TypeSystemProvider` file outside the PEAR and then try
loading the class - but the class loaded will be found inside the PEAR and will
not implement the interface. This cause the `ServiceLoader` to fail, claiming
that the class does not implement the required interface (which indeed it does
not).
**Expected behavior**
No error. We should probably not consider SPIs in PEARs at all. UIMA should
probably not allow the discovery of SPIs declared or implemented within PEARs.
PEARs may come with their own type system definitions and JCas classes, but it
should not be necessary to discover those through SPIs. Discovery through SPIs
should only be necessary for the "global" context, i.e. outside PEAR files.
**Please complete the following information:**
- Version: 3.6.0
--
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.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
