*“Don't cross the streams.”*
—
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, Doctor Faustus (v. 111-13)
On Mon, Apr 14, 2025 at 17:23 Chuck Caldarale wrote:
>
> > On 2025 Apr 14, at 15:57
> On 2025 Apr 14, at 15:57, Thad Humphries wrote:
>
> Thank you, Mark. Copying both jai-imageio jars into $CATALINA_BASE/lib
> works.
Hopefully, you moved the jars (as Mark suggested) rather than just copying
them. Putting the same jar in multiple places in a branch of the class loader
tree
Thank you, Mark. Copying both jai-imageio jars into $CATALINA_BASE/lib
works.
On Mon, Apr 14, 2025 at 6:13 AM Mark Thomas wrote:
> Thad,
>
> A quick read of https://github.com/jai-imageio/jai-imageio-core suggests
> a possible cause.
>
> The library is using the SPI plugin mechanism of ImageIO.
Thad,
A quick read of https://github.com/jai-imageio/jai-imageio-core suggests
a possible cause.
The library is using the SPI plugin mechanism of ImageIO.
I haven't confirmed this with a code inspection but what I assume is
happening is that the web application is registering an extension at
There are no native binaries in either the jai-image core or jpeg2000 jars.
These same web apps run on Linux, Windows, Intel macOS, and at least one
old Solaris machine. I just prefer macOS as my development platform. (Sun's
original JAI did have native libraries, but that was decades ago.)
On Sat
Wild guess. Does this library use tmp to extract binaries to run native
code?
If so, it might be a version collision of those tmp binaries?
On Sat, Apr 12, 2025 at 4:23 PM Thad Humphries
wrote:
> I have a problem that appears to be one webapp in Tomcat 9 having a portion
> of its classpath ma
