Trying to use POI 3.11 jar crashing

dev google-group-archive
1

I’m getting the following error only on the server when using the POI 3.11
jar file(s). The code works fine locally using Jetty, but on the server
running Tomcat it crashes. The server is running Lucee 4.5.1.000.

java.lang.NoSuchMethodError

Stack trace:
org.apache.poi.util.IOUtils.readFully(Ljava/nio/channels/ReadableByteChannel
;Ljava/nio/ByteBuffer;)I at org.apache.poi.poifs.filesystem.NPOIFSFileSystem
.(NPOIFSFileSystem.java:195):195 at org.apache.poi.poifs.filesystem.
NPOIFSFileSystem.(NPOIFSFileSystem.java:163):163 at org.apache.poi.
poifs.filesystem.NPOIFSFileSystem.(NPOIFSFileSystem.java:145):145 at
org.apache.poi.ss.usermodel.WorkbookFactory.create(WorkbookFactory.java:87):
87 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method):-2 at sun.
reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57):57
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43):43 at java.lang.reflect.Method.invoke(
Method.java:606):606 at lucee.runtime.reflection.pairs.MethodInstance.invoke
(Unknown Source):-1 at lucee.runtime.java.JavaObject.call(Unknown Source):-1
at lucee.runtime.java.JavaObject.call(Unknown Source):-1 at lucee.runtime.
util.VariableUtilImpl.callFunctionWithoutNamedValues(Unknown Source):-1 at
lucee.runtime.PageContextImpl.getFunction(Unknown Source):-1 at cewit2015.
com.poi_cfc$cf.udfCall(C:\inetpub\wwwroot\r1.events-registration.com
cewit2015\com\POI.cfc:17):17 at lucee.runtime.type.UDFImpl.implementation(
Unknown Source):-1 at lucee.runtime.type.UDFImpl._call(Unknown Source):-1
at lucee.runtime.type.UDFImpl.call(Unknown Source):-1 at lucee.runtime.
ComponentImpl._call(Unknown Source):-1 at lucee.runtime.ComponentImpl._call(
Unknown Source):-1 at lucee.runtime.ComponentImpl.call(Unknown Source):-1
at lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(
Unknown Source):-1 at lucee.runtime.PageContextImpl.getFunction(Unknown
Source):-1 at cewit2015.test_cfm$cf.call(C:\inetpub\wwwroot\r1.events-
registration.com\cewit2015\test.cfm:9):9 at lucee.runtime.PageContextImpl.
doInclude(Unknown Source):-1 at lucee.runtime.PageContextImpl.doInclude(
Unknown Source):-1 at lucee.runtime.listener.ModernAppListener._onRequest(
Unknown Source):-1 at lucee.runtime.listener.MixedAppListener.onRequest(
Unknown Source):-1 at lucee.runtime.PageContextImpl.execute(Unknown Source
):-1 at lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at lucee.
runtime.engine.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at lucee.loader
.servlet.CFMLServlet.service(Unknown Source):-1 at javax.servlet.http.
HttpServlet.service(HttpServlet.java:727):727 at org.apache.catalina.core.
ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303):303
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208):208 at org.apache.tomcat.websocket.server.
WsFilter.doFilter(WsFilter.java:52):52 at org.apache.catalina.core.
ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241):241
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208):208 at org.apache.catalina.core.
StandardWrapperValve.invoke(StandardWrapperValve.java:220):220 at org.apache
.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122):
122 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:504):504 at org.apache.catalina.core.
StandardHostValve.invoke(StandardHostValve.java:170):170 at org.apache.
catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103):103 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:116):116 at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:421):421 at org.apache.coyote.ajp.AjpProcessor.process(
AjpProcessor.java:190):190 at org.apache.coyote.
AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611
):611 at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(
JIoEndpoint.java:314):314 at java.util.concurrent.ThreadPoolExecutor.
runWorker(ThreadPoolExecutor.java:1145):1145 at java.util.concurrent.
ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615):615 at org.apache
.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61):61
at java.lang.Thread.run(Thread.java:745):745

Since it works locally I’m guessing it is a Tomcat issue?

2

Lucee 4.5 is using version 3.8 of this library, if you add an other version
what version is loading happens by accident.
It is highly possible that Jetty loads one version and Tomcat an other.
The exception indicates that you simply run a incompatible version.

That is exactly the reason we have added support for OSGi to Lucee 5, with
Lucee 5 you can use whatever version you like, that Lucee uses an other
version does not matter.

MichaOn Fri, Apr 24, 2015 at 5:46 PM, Jonathan Brookins <@Jonathan_Brookins> wrote:

I’m getting the following error only on the server when using the POI 3.11
jar file(s). The code works fine locally using Jetty, but on the server
running Tomcat it crashes. The server is running Lucee 4.5.1.000.

java.lang.NoSuchMethodError

Stack trace:
org.apache.poi.util.IOUtils.readFully(Ljava/nio/channels/
ReadableByteChannel;Ljava/nio/ByteBuffer;)I at org.apache.poi.poifs.
filesystem.NPOIFSFileSystem.(NPOIFSFileSystem.java:195):195 at org.
apache.poi.poifs.filesystem.NPOIFSFileSystem.(NPOIFSFileSystem.java:
163):163 at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.(
NPOIFSFileSystem.java:145):145 at org.apache.poi.ss.usermodel.
WorkbookFactory.create(WorkbookFactory.java:87):87 at sun.reflect.
NativeMethodAccessorImpl.invoke0(Native Method):-2 at sun.reflect.
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57):57 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43):43 at java.lang.reflect.Method.
invoke(Method.java:606):606 at lucee.runtime.reflection.pairs.
MethodInstance.invoke(Unknown Source):-1 at lucee.runtime.java.JavaObject.
call(Unknown Source):-1 at lucee.runtime.java.JavaObject.call(Unknown
Source):-1 at lucee.runtime.util.VariableUtilImpl.
callFunctionWithoutNamedValues(Unknown Source):-1 at lucee.runtime.
PageContextImpl.getFunction(Unknown Source):-1 at cewit2015.com.poi_cfc$cf
.udfCall(C:\inetpub\wwwroot\r1.events-registration.com\cewit2015\com\POI.
cfc:17):17 at lucee.runtime.type.UDFImpl.implementation(Unknown Source):-1
at lucee.runtime.type.UDFImpl._call(Unknown Source):-1 at lucee.runtime.
type.UDFImpl.call(Unknown Source):-1 at lucee.runtime.ComponentImpl._call(
Unknown Source):-1 at lucee.runtime.ComponentImpl._call(Unknown Source):-1
at lucee.runtime.ComponentImpl.call(Unknown Source):-1 at lucee.runtime.
util.VariableUtilImpl.callFunctionWithoutNamedValues(Unknown Source):-1
at lucee.runtime.PageContextImpl.getFunction(Unknown Source):-1 at
cewit2015.test_cfm$cf.call(C:\inetpub\wwwroot\r1.events-registration.com
cewit2015\test.cfm:9):9 at lucee.runtime.PageContextImpl.doInclude(Unknown
Source):-1 at lucee.runtime.PageContextImpl.doInclude(Unknown Source):-1
at lucee.runtime.listener.ModernAppListener._onRequest(Unknown Source):-1
at lucee.runtime.listener.MixedAppListener.onRequest(Unknown Source):-1
at lucee.runtime.PageContextImpl.execute(Unknown Source):-1 at lucee.
runtime.PageContextImpl.execute(Unknown Source):-1 at lucee.runtime.engine
.CFMLEngineImpl.serviceCFML(Unknown Source):-1 at lucee.loader.servlet.
CFMLServlet.service(Unknown Source):-1 at javax.servlet.http.HttpServlet.
service(HttpServlet.java:727):727 at org.apache.catalina.core.
ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303):
303 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208):208 at org.apache.tomcat.websocket.server
.WsFilter.doFilter(WsFilter.java:52):52 at org.apache.catalina.core.
ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241):
241 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208):208 at org.apache.catalina.core.
StandardWrapperValve.invoke(StandardWrapperValve.java:220):220 at org.
apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java
:122):122 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:504):504 at org.apache.catalina.core.
StandardHostValve.invoke(StandardHostValve.java:170):170 at org.apache.
catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103):103 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:116):116 at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:421):421 at org.apache.coyote.ajp.AjpProcessor.process(
AjpProcessor.java:190):190 at org.apache.coyote.
AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:
611):611 at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(
JIoEndpoint.java:314):314 at java.util.concurrent.ThreadPoolExecutor.
runWorker(ThreadPoolExecutor.java:1145):1145 at java.util.concurrent.
ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615):615 at org.
apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java
:61):61 at java.lang.Thread.run(Thread.java:745):745

Since it works locally I’m guessing it is a Tomcat issue?

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1024c3a3-c081-43f5-8c6f-02b831037458%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1024c3a3-c081-43f5-8c6f-02b831037458%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

3

You cannot simple load 2 different version of the same class, you have to
trick Java to do so (you need to cripple tha parent
classloader). JavaLoader will not help with that.

MichaAm Freitag, 24. April 2015 schrieb Jonathan Brookins :

I’m using this to access the jar file:
wf = createObject(“java”, “org.apache.poi.ss.usermodel.WorkbookFactory”,
expandPath(“/jars/poi/poi-3.11-20141221.jar”));

Would I still need something like JavaLoader?

On Friday, April 24, 2015 at 12:30:08 PM UTC-4, Julian Halliwell wrote:

JavaLoader should help get round this issue.

GitHub - markmandel/JavaLoader: JavaLoader is a library that has been built to ease the use, development and integration of Java within ColdFusion applications.

On 24 April 2015 at 16:46, Jonathan Brookins jon.br...@gmail.com wrote:

I’m getting the following error only on the server when using the POI
3.11
jar file(s). The code works fine locally using Jetty, but on the
server
running Tomcat it crashes. The server is running Lucee 4.5.1.000.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/63236357-cb3d-4b8f-9e4f-301712997742%40googlegroups.com
https://groups.google.com/d/msgid/lucee/63236357-cb3d-4b8f-9e4f-301712997742%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

4

Again, I don’t pretend to understand the details, but somehow
JavaLoader does appear to solve the problem, since it is working both in
my Lucee Spreadsheet Library and the recently “hacked” version of the
Railo extension, both of which use POI 3.11 despite 3.8 being already
in the Lucee core lib.

https://github.com/cfsimplicity/lucee-spreadsheetOn 24 April 2015 at 20:41, Michael Offner <@Michael_Offner> wrote:

You cannot simple load 2 different version of the same class, you have to
trick Java to do so (you need to cripple tha parent classloader). JavaLoader
will not help with that.

5

So it should work if I just omit using the jars I downloaded in the
createObject()?On Friday, April 24, 2015 at 12:08:02 PM UTC-4, Micha wrote:

Lucee 4.5 is using version 3.8 of this library, if you add an other
version what version is loading happens by accident.
It is highly possible that Jetty loads one version and Tomcat an other.
The exception indicates that you simply run a incompatible version.

That is exactly the reason we have added support for OSGi to Lucee 5, with
Lucee 5 you can use whatever version you like, that Lucee uses an other
version does not matter.

Micha

On Fri, Apr 24, 2015 at 5:46 PM, Jonathan Brookins <jon.br...@gmail.com <javascript:>> wrote:

I’m getting the following error only on the server when using the POI
3.11 jar file(s). The code works fine locally using Jetty, but on the
server running Tomcat it crashes. The server is running Lucee 4.5.1.000.

java.lang.NoSuchMethodError

Stack trace:
org.apache.poi.util.IOUtils.readFully(Ljava/nio/channels/
ReadableByteChannel;Ljava/nio/ByteBuffer;)I at org.apache.poi.poifs.
filesystem.NPOIFSFileSystem.(NPOIFSFileSystem.java:195):195 at org.
apache.poi.poifs.filesystem.NPOIFSFileSystem.(NPOIFSFileSystem.java
:163):163 at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.(
NPOIFSFileSystem.java:145):145 at org.apache.poi.ss.usermodel.
WorkbookFactory.create(WorkbookFactory.java:87):87 at sun.reflect.
NativeMethodAccessorImpl.invoke0(Native Method):-2 at sun.reflect.
NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57):57 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43):43 at java.lang.reflect.Method.
invoke(Method.java:606):606 at lucee.runtime.reflection.pairs.
MethodInstance.invoke(Unknown Source):-1 at lucee.runtime.java.JavaObject
.call(Unknown Source):-1 at lucee.runtime.java.JavaObject.call(Unknown
Source):-1 at lucee.runtime.util.VariableUtilImpl.
callFunctionWithoutNamedValues(Unknown Source):-1 at lucee.runtime.
PageContextImpl.getFunction(Unknown Source):-1 at cewit2015.com.
poi_cfc$cf.udfCall(C:\inetpub\wwwroot\r1.events-registration.com
cewit2015\com\POI.cfc:17):17 at lucee.runtime.type.UDFImpl.implementation
(Unknown Source):-1 at lucee.runtime.type.UDFImpl._call(Unknown Source):-
1 at lucee.runtime.type.UDFImpl.call(Unknown Source):-1 at lucee.runtime.
ComponentImpl._call(Unknown Source):-1 at lucee.runtime.ComponentImpl.
_call(Unknown Source):-1 at lucee.runtime.ComponentImpl.call(Unknown
Source):-1 at lucee.runtime.util.VariableUtilImpl.
callFunctionWithoutNamedValues(Unknown Source):-1 at lucee.runtime.
PageContextImpl.getFunction(Unknown Source):-1 at cewit2015.test_cfm$cf.
call(C:\inetpub\wwwroot\r1.events-registration.com\cewit2015\test.cfm:9):
9 at lucee.runtime.PageContextImpl.doInclude(Unknown Source):-1 at lucee.
runtime.PageContextImpl.doInclude(Unknown Source):-1 at lucee.runtime.
listener.ModernAppListener._onRequest(Unknown Source):-1 at lucee.runtime
.listener.MixedAppListener.onRequest(Unknown Source):-1 at lucee.runtime.
PageContextImpl.execute(Unknown Source):-1 at lucee.runtime.
PageContextImpl.execute(Unknown Source):-1 at lucee.runtime.engine.
CFMLEngineImpl.serviceCFML(Unknown Source):-1 at lucee.loader.servlet.
CFMLServlet.service(Unknown Source):-1 at javax.servlet.http.HttpServlet.
service(HttpServlet.java:727):727 at org.apache.catalina.core.
ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303):
303 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208):208 at org.apache.tomcat.websocket.
server.WsFilter.doFilter(WsFilter.java:52):52 at org.apache.catalina.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241
):241 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208):208 at org.apache.catalina.core.
StandardWrapperValve.invoke(StandardWrapperValve.java:220):220 at org.
apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
java:122):122 at org.apache.catalina.authenticator.AuthenticatorBase.
invoke(AuthenticatorBase.java:504):504 at org.apache.catalina.core.
StandardHostValve.invoke(StandardHostValve.java:170):170 at org.apache.
catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103):103
at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:116):116 at org.apache.catalina.connector.
CoyoteAdapter.service(CoyoteAdapter.java:421):421 at org.apache.coyote.
ajp.AjpProcessor.process(AjpProcessor.java:190):190 at org.apache.coyote.
AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:
611):611 at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(
JIoEndpoint.java:314):314 at java.util.concurrent.ThreadPoolExecutor.
runWorker(ThreadPoolExecutor.java:1145):1145 at java.util.concurrent.
ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615):615 at org.
apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.
java:61):61 at java.lang.Thread.run(Thread.java:745):745

Since it works locally I’m guessing it is a Tomcat issue?

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/1024c3a3-c081-43f5-8c6f-02b831037458%40googlegroups.com
https://groups.google.com/d/msgid/lucee/1024c3a3-c081-43f5-8c6f-02b831037458%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

6

Locally my org.apache.poi.util.IOUtils has quite a few methods.
org.apache.poi.util.IOUtils on the server has two. The code that fails is
pretty basic:
wb = createObject(“java”, “org.apache.poi.ss.usermodel.WorkbookFactory”);
f = createObject(“java”, “java.io.File”).init(expandPath(“test.xls”));
wb.create(f);

I’ve tried using InputStream rather than the File, same result.

7

JavaLoader should help get round this issue.

https://github.com/markmandel/JavaLoaderOn 24 April 2015 at 16:46, Jonathan Brookins <@Jonathan_Brookins> wrote:

I’m getting the following error only on the server when using the POI 3.11
jar file(s). The code works fine locally using Jetty, but on the server
running Tomcat it crashes. The server is running Lucee 4.5.1.000.

8

I’m using this to access the jar file:
wf = createObject(“java”, “org.apache.poi.ss.usermodel.WorkbookFactory”,
expandPath(“/jars/poi/poi-3.11-20141221.jar”));

Would I still need something like JavaLoader?On Friday, April 24, 2015 at 12:30:08 PM UTC-4, Julian Halliwell wrote:

JavaLoader should help get round this issue.

GitHub - markmandel/JavaLoader: JavaLoader is a library that has been built to ease the use, development and integration of Java within ColdFusion applications.

On 24 April 2015 at 16:46, Jonathan Brookins <jon.br...@gmail.com <javascript:>> wrote:

I’m getting the following error only on the server when using the POI
3.11
jar file(s). The code works fine locally using Jetty, but on the server
running Tomcat it crashes. The server is running Lucee 4.5.1.000.

9

Yes, that’s my understanding and experience with Lucee 4.5. I’m not
sure what the mechanism is for picking which version to load, but
specifying the path in createObject() doesn’t guarantee it’ll be that
one.

As Micha says, this isn’t in issue in Lucee 5 because of OSGi. It
means you can control which version is loaded.On 24 April 2015 at 18:08, Jonathan Brookins <@Jonathan_Brookins> wrote:

I’m using this to access the jar file:
wf = createObject(“java”, “org.apache.poi.ss.usermodel.WorkbookFactory”,
expandPath(“/jars/poi/poi-3.11-20141221.jar”));

Would I still need something like JavaLoader?

10

The problem now isn’t a 3.11 vs 3.8 issue. I’m not using the 3.11 jar any
longer, but I’m still getting the same error.

11

The problems with class loading mostly revolve around lookups.

JavaLoader isn’t working by accident. There’s a choice of what you want
the parent loader to be when you instantiate it. If you choose the
“loadColdFusionClasspath” option it will behave one way, if you pass in
say “null” as the parent classloader, it will behave another.

There is an order to it all, it’s just tricky to control it-- few
classes generally “pollute” the whole JVM when loaded, but they’re the
hardest to work around (sometimes impossible-ish). You can do things
like renaming packages and whatnot, but a lot depends on your
requirements, and what depends on what.

A common problem is cross-loading, where an isolated classloader doesn’t
have access to all the classes it needs, and so goes out to some other
classloader to get the missing ones, and then the lookup chain is all
messed up, as some bits are coming from here, other bits from there.

Another problem is stuff that uses the thread context classloader-- then
you’ve got to switch classloaders out, be sure X is getting used with X
and Y with Y, and sometimes can’t return what you think you’d be able to
return, as it would end up crossing loaders.

Spengler: Don’t cross the streams.
Venkman: Why?
Spengler: It would be bad.
Venkman: I’m fuzzy on the whole good/bad thing. What do you mean, “bad”?

Basically messing with class loading can be a super huge pain in the
buttocks. It’s not exactly based on luck, but there can be a lot of
variables, and depending on what you need to do some of them can be out
of your control… so, yeah, it is kind based on luck, I guess. :slight_smile:

FWIW, I’ve successfully used JavaLoader for cfspreadsheet too-- I have a
fork somewhere, but I haven’t updated it recently.

-DenOn 4/26/15 7:48 AM, Julian Halliwell wrote:

Thanks for the explanations, Micha, but I’m still not persuaded that
JavaLoader is working by accident. It works consistently and in more
than one case (my library, the official Railo and Lucee spreadsheet
extensions and PDFBox).

But we may be at cross purposes here. The newer jars being loaded by
by JavaLoader are not in the Lucee core lib classpath, but in a
separate location. Does that make a difference?

On 26 April 2015 at 13:34, Michael Offner <@Michael_Offner> wrote:

If you have 2 versions of the same library in your classpath only one of
them is loaded, which one is loaded is not following a specific rule,
because there are no rules for this in Java.
That is simply happening by accident, so you are simply lucky the right one
is loaded. to control the versions jou need a framework like osgi.
In Lucee 5 you can load classes by version because Lucee 5 is osgi based.
But javaLoader for sure cannot do this …

12

Let me explain from ground.
Java was never made to update jars at runtime, there can be only one class
with a specific name, for example “java.lang…String” as soon this class is
loaded no other class can take this place. It is taken as long Java runs.
Java classloaders are organized in a tree where every request first get
delegated to the parent, before the classloader check if he can answer the
request itself.
This is made to make sure you only have one class instance of every
possible class. To load different versions you need a classloader that
ignores this rule and ignores the parent (simplified). If you do this you
have to handle that your class is not visible to classes outside your jar
(is a problem when jars are loaded by string definition with for example
the system classloader) and that you have possible doubles.
Lucee loads the core this way what makes it possible to update it on the
fly, in lucee 5 with help of osgi and in older version with a custom made
classloader.

As you can see, it is complicated and JavaLoader is for sure not helping
with that.

MichaAm Samstag, 25. April 2015 schrieb Jonathan Brookins :

The problem now isn’t a 3.11 vs 3.8 issue. I’m not using the 3.11 jar any
longer, but I’m still getting the same error.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

13

So how is it that my spreadsheet library works with POI 3.11, loaded
using JavaLoader?

I’ve also used JL successfully to load the latest PDFBox, an older
version of which is also in the core lib.

Let me explain from ground.
[…]On 26 April 2015 at 08:39, Michael Offner <@Michael_Offner> wrote:
As you can see, it is complicated and JavaLoader is for sure not helping
with that.

14

See my comments between the lines.

So how is it that my spreadsheet library works with POI 3.11, loaded
using JavaLoader?

If you have 2 versions of the same library in your classpath only one of
them is loaded, which one is loaded is not following a specific rule,
because there are no rules for this in Java.
That is simply happening by accident, so you are simply lucky the right one
is loaded. to control the versions jou need a framework like osgi.
In Lucee 5 you can load classes by version because Lucee 5 is osgi based.
But javaLoader for sure cannot do this …

I’ve also used JL successfully to load the latest PDFBox, an older
version of which is also in the core lib.

Then the core lib is not loaded and the functionality in Lucee will maybe
fail.
We have spend a lot of time on that topic with a bigger client of us, the
result was the support of osgi in Lucee 5.Am Sonntag, 26. April 2015 schrieb Julian Halliwell :

On 26 April 2015 at 08:39, Michael Offner <@Michael_Offner <javascript:;>> wrote:

Let me explain from ground.
[…]
As you can see, it is complicated and JavaLoader is for sure not helping
with that.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com <javascript:;>.
To post to this group, send email to lucee@googlegroups.com <javascript:;>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAC_5Vori%3DH_1wQQr0yNtK5VsdPP-oqgD0qeZoR3bzqUHKK3ktA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

15

Thanks for the explanations, Micha, but I’m still not persuaded that
JavaLoader is working by accident. It works consistently and in more
than one case (my library, the official Railo and Lucee spreadsheet
extensions and PDFBox).

But we may be at cross purposes here. The newer jars being loaded by
by JavaLoader are not in the Lucee core lib classpath, but in a
separate location. Does that make a difference?On 26 April 2015 at 13:34, Michael Offner <@Michael_Offner> wrote:

If you have 2 versions of the same library in your classpath only one of
them is loaded, which one is loaded is not following a specific rule,
because there are no rules for this in Java.
That is simply happening by accident, so you are simply lucky the right one
is loaded. to control the versions jou need a framework like osgi.
In Lucee 5 you can load classes by version because Lucee 5 is osgi based.
But javaLoader for sure cannot do this …

16

If you get that error you still have a version conflict for sure, I cannot
say why. Don’t forget rename the jar or move it to a sub folder will not
hide it from the servlet engine…

MichaAm Samstag, 25. April 2015 schrieb Jonathan Brookins :

The problem now isn’t a 3.11 vs 3.8 issue. I’m not using the 3.11 jar any
longer, but I’m still getting the same error.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

17

Micha,

I’m not using the jars anymore, just trying to use the POI 3.8 inside of
Lucee. Does this not instantiate the Workbook Factory, or is there a
specific Lucee-based namespace to access it?
wb = createObject(“java”, “org.apache.poi.ss.usermodel.WorkbookFactory”);On Sunday, April 26, 2015 at 3:41:27 AM UTC-4, Micha wrote:

If you get that error you still have a version conflict for sure, I cannot
say why. Don’t forget rename the jar or move it to a sub folder will not
hide it from the servlet engine…

Micha

Am Samstag, 25. April 2015 schrieb Jonathan Brookins :

The problem now isn’t a 3.11 vs 3.8 issue. I’m not using the 3.11 jar any
longer, but I’m still getting the same error.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

18

Great explanation! specially the Ghostbusters part :wink:

MichaOn Sun, Apr 26, 2015 at 8:01 PM, denstar <@denstar> wrote:

The problems with class loading mostly revolve around lookups.

JavaLoader isn’t working by accident. There’s a choice of what you want
the parent loader to be when you instantiate it. If you choose the
“loadColdFusionClasspath” option it will behave one way, if you pass in
say “null” as the parent classloader, it will behave another.

There is an order to it all, it’s just tricky to control it-- few
classes generally “pollute” the whole JVM when loaded, but they’re the
hardest to work around (sometimes impossible-ish). You can do things
like renaming packages and whatnot, but a lot depends on your
requirements, and what depends on what.

A common problem is cross-loading, where an isolated classloader doesn’t
have access to all the classes it needs, and so goes out to some other
classloader to get the missing ones, and then the lookup chain is all
messed up, as some bits are coming from here, other bits from there.

Another problem is stuff that uses the thread context classloader-- then
you’ve got to switch classloaders out, be sure X is getting used with X
and Y with Y, and sometimes can’t return what you think you’d be able to
return, as it would end up crossing loaders.

Spengler: Don’t cross the streams.
Venkman: Why?
Spengler: It would be bad.
Venkman: I’m fuzzy on the whole good/bad thing. What do you mean, “bad”?

Basically messing with class loading can be a super huge pain in the
buttocks. It’s not exactly based on luck, but there can be a lot of
variables, and depending on what you need to do some of them can be out
of your control… so, yeah, it is kind based on luck, I guess. :slight_smile:

FWIW, I’ve successfully used JavaLoader for cfspreadsheet too-- I have a
fork somewhere, but I haven’t updated it recently.

-Den

On 4/26/15 7:48 AM, Julian Halliwell wrote:

Thanks for the explanations, Micha, but I’m still not persuaded that
JavaLoader is working by accident. It works consistently and in more
than one case (my library, the official Railo and Lucee spreadsheet
extensions and PDFBox).

But we may be at cross purposes here. The newer jars being loaded by
by JavaLoader are not in the Lucee core lib classpath, but in a
separate location. Does that make a difference?

On 26 April 2015 at 13:34, Michael Offner <@Michael_Offner> wrote:

If you have 2 versions of the same library in your classpath only one of
them is loaded, which one is loaded is not following a specific rule,
because there are no rules for this in Java.
That is simply happening by accident, so you are simply lucky the right
one
is loaded. to control the versions jou need a framework like osgi.
In Lucee 5 you can load classes by version because Lucee 5 is osgi
based.
But javaLoader for sure cannot do this …

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/553D27E6.4030001%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

19

between the lines

Micha

Micha,

I’m not using the jars anymore, just trying to use the POI 3.8 inside of
Lucee. Does this not instantiate the Workbook Factory, or is there a
specific Lucee-based namespace to access it?

nope

wb = createObject(“java”, “org.apache.poi.ss.usermodel.WorkbookFactory”);

looks right to me, what happens?On Mon, Apr 27, 2015 at 8:02 AM, Jonathan Brookins <@Jonathan_Brookins> wrote:

On Sunday, April 26, 2015 at 3:41:27 AM UTC-4, Micha wrote:

If you get that error you still have a version conflict for sure, I
cannot say why. Don’t forget rename the jar or move it to a sub folder will
not hide it from the servlet engine…

Micha

Am Samstag, 25. April 2015 schrieb Jonathan Brookins :

The problem now isn’t a 3.11 vs 3.8 issue. I’m not using the 3.11 jar
any longer, but I’m still getting the same error.

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/59a64817-5db8-41f9-a7aa-6a65b95c194a%40googlegroups.com
https://groups.google.com/d/msgid/lucee/59a64817-5db8-41f9-a7aa-6a65b95c194a%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

20

LOL @ Ghostbusters reference. Who you gonna call?

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 4/27/2015 3:00 AM, Michael Offner wrote:

Great explanation! specially the Ghostbusters part :wink:

Micha

On Sun, Apr 26, 2015 at 8:01 PM, denstar <@denstar mailto:denstar> wrote:

The problems with class loading mostly revolve around lookups.

JavaLoader isn't working by accident.  There's a choice of what
you want
the parent loader to be when you instantiate it.  If you choose the
"loadColdFusionClasspath" option it will behave one way, if you
pass in
say "null" as the parent classloader, it will behave another.

There is an order to it all, it's just tricky to control it-- few
classes generally "pollute" the whole JVM when loaded, but they're the
hardest to work around (sometimes impossible-ish).  You can do things
like renaming packages and whatnot, but a lot depends on your
requirements, and what depends on what.

A common problem is cross-loading, where an isolated classloader
doesn't
have access to all the classes it needs, and so goes out to some other
classloader to get the missing ones, and then the lookup chain is all
messed up, as some bits are coming from here, other bits from there.

Another problem is stuff that uses the thread context
classloader-- then
you've got to switch classloaders out, be sure X is getting used
with X
and Y with Y, and sometimes can't return what you think you'd be
able to
return, as it would end up crossing loaders.

Spengler: Don't cross the streams.
Venkman: Why?
Spengler: It would be bad.
Venkman: I'm fuzzy on the whole good/bad thing. What do you mean,
"bad"?

Basically messing with class loading can be a super huge pain in the
buttocks.  It's not exactly based on luck, but there can be a lot of
variables, and depending on what you need to do some of them can
be out
of your control... so, yeah, it is kind based on luck, I guess. :)

FWIW, I've successfully used JavaLoader for cfspreadsheet too-- I
have a
fork somewhere, but I haven't updated it recently.

-Den

On 4/26/15 7:48 AM, Julian Halliwell wrote:
> Thanks for the explanations, Micha, but I'm still not persuaded that
> JavaLoader is working by accident. It works consistently and in more
> than one case (my library, the official Railo and Lucee spreadsheet
> extensions and PDFBox).
>
> But we may be at cross purposes here. The *newer* jars being
loaded by
> by JavaLoader are not in the Lucee core lib classpath, but in a
> separate location. Does that make a difference?
>
> On 26 April 2015 at 13:34, Michael Offner <@Michael_Offner <mailto:@Michael_Offner>> wrote:
>> If you have 2 versions of the same library in your classpath
only one of
>> them is loaded, which one is loaded is not following a specific
rule,
>> because there are no rules for this in Java.
>> That is simply happening by accident, so you are simply lucky
the right one
>> is loaded. to control the versions jou need a framework like osgi.
>> In Lucee 5 you can load classes by version because Lucee 5 is
osgi based.
>> But javaLoader for sure cannot do this ...
>

--
You received this message because you are subscribed to the Google
Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee%2Bunsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/553D27E6.4030001%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

–
You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG%2BEEBy8trjqRj1Z%3DGPKHOPwHVzbXHsaj82ZxPyM6x2BXq_fZQ%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG%2BEEBy8trjqRj1Z%3DGPKHOPwHVzbXHsaj82ZxPyM6x2BXq_fZQ%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.