Trying to use POI 3.11 jar crashing

[Jonathan Brookins]

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.<init>(NPOIFSFileSystem.java:195):195 at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.<init>(NPOIFSFileSystem.java:163):163 at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.<init>(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?

[Michael Offner]

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

--
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.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1024c3a3-c081-43f5-8c6f-02b831037458%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julian Halliwell]

JavaLoader should help get round this issue.

https://github.com/markmandel/JavaLoader

[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?

[Jonathan Brookins]

So it should work if I just omit using the jars I downloaded in the createObject()?

[Julian Halliwell]

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.

[Jonathan Brookins]

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.

[Michael Offner]

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.

Micha 

--

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.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/63236357-cb3d-4b8f-9e4f-301712997742%40googlegroups.com.

[Julian Halliwell]

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-spreadsheet

[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.

[Michael Offner]

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.

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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com.

[Michael Offner]

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.

--

[Julian Halliwell]

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.

On 26 April 2015 at 08:39, Michael Offner <mic...@lucee.org> wrote:
> Let me explain from ground.

[...]

[Michael Offner]

See my comments between the lines.

Am Sonntag, 26. April 2015 schrieb Julian Halliwell :

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.

On 26 April 2015 at 08:39, Michael Offner <mic...@lucee.org> 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+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAC_5Vori%3DH_1wQQr0yNtK5VsdPP-oqgD0qeZoR3bzqUHKK3ktA%40mail.gmail.com.

[Julian Halliwell]

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?

[denstar]

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

[Jonathan Brookins]

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.

[Michael Offner]

Great explanation! specially the Ghostbusters part ;-)

Micha

--
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.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/553D27E6.4030001%40gmail.com.

[Michael Offner]

between the lines

Micha

On Mon, Apr 27, 2015 at 8:02 AM, Jonathan Brookins <jon.br...@gmail.com> wrote:

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 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+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.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+un...@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/59a64817-5db8-41f9-a7aa-6a65b95c194a%40googlegroups.com.

[Jonathan Brookins]

the createObject() works fine.  It crashes when  you try to do a wb.create().  I tried using an InputStream as well as a File, same result.  The problem seems to be in in org.apache.poi.util.IOUtils.  My laptop has the same Lucee version as the server, but if I dump() org.apache.poi.util.IOUtils on my laptop there are quite a few methods shown.  The same dump() on the server shows only two readFully() methods.  Something in there is why create() is failing.  Here is the error that occurs:

org.apache.poi.util.IOUtils.readFully(Ljava/nio/channels/ReadableByteChannel;Ljava/nio/ByteBuffer;)I at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.<init>(NPOIFSFileSystem.java:195):195 at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.<init>(NPOIFSFileSystem.java:163):163 at org.apache.poi.poifs.filesystem.NPOIFSFileSystem.<init>(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(MethodInstance.java:55):55 at lucee.runtime.java.JavaObject.call(JavaObject.java:234):234 at lucee.runtime.java.JavaObject.call(JavaObject.java:256):256 at lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(VariableUtilImpl.java:742):742 at lucee.runtime.PageContextImpl.getFunction(PageContextImpl.java:1586):1586 at cewit2015.test_cfm$cf.call(C:\inetpub\wwwroot\r1.events-registration.com\cewit2015\test.cfm:14):14 at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:948):948 at lucee.runtime.PageContextImpl.doInclude(PageContextImpl.java:900):900 at lucee.runtime.listener.ModernAppListener._onRequest(ModernAppListener.java:223):223 at lucee.runtime.listener.MixedAppListener.onRequest(MixedAppListener.java:35):35 at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2254):2254 at lucee.runtime.PageContextImpl.execute(PageContextImpl.java:2221):2221 at lucee.runtime.engine.CFMLEngineImpl.serviceCFML(CFMLEngineImpl.java:456):456 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

On Monday, April 27, 2015 at 6:04:36 AM UTC-4, Micha wrote:

between the lines

Micha

On Mon, Apr 27, 2015 at 8:02 AM, Jonathan Brookins <jon.br...@gmail.com> wrote:

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 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 lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3bb8e9c3-7763-4d67-9756-fe493cee8045%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Igal @ Lucee.org]

LOL @ Ghostbusters reference.  Who you gonna call?

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBy8trjqRj1Z%3DGPKHOPwHVzbXHsaj82ZxPyM6x2BXq_fZQ%40mail.gmail.com.

[Julian Halliwell]

I ran into similar problems when attempting to use the included POI
jars directly via CreateObject(). I went back to JavaLoader which
worked well and allowed me to use the latest POI, despite what Micha
says. Have you tried that?

Alternatively have you tried my library? It will save you the bother
of setting up JavaLoader/POI 3.11 and give you a wide range of
functions in CFML

https://github.com/cfsimplicity/lucee-spreadsheet

If you've got a specific need which it doesn't cover I'd welcome
suggestions/feedback.

Julian

[Jonathan Brookins]

Micha, 

Since the Lucee POI libs aren't working, at least on the server, should I file a bug report?

[Jonathan Brookins]

One thing I just realized about this.  My local Lucee copy is a Railo upgrade, while the server is a clean install.  Perhaps that is why it works locally and not on the server.

[Jedihomer Townend]

Hi,

My instance has the same issue, installed from scratch.

To rectify I:

moved apache-poi* out of the lucee/lib/ directory.
Downloaded and extracted the latest POI from the apache site.
Copied/movied poi-3.11/poi-* to the lucee/lib/ directory.
Stopped then started lucee

Re-running the code then worked, no 'no method' error.


HTH

Jedi

> --
> 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.
> To post to this group, send email to lu...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/lucee/702a971c-0eb5-43c1-b632-58c2710d515b%40googlegroups.com.

[Jonathan Brookins]

Thanks, Jedi!  I'll give it a shot and let you know how it goes.

[Jonathan Brookins]

That seems to work for me.  Thanks again, Jedi.