Trying to load latest POI with javaloader... getting strange initialization error

[Marc Esher]

All,

I'm trying to load the latest POI nightlies using javaloader. I've
inited javaloader with an array of all the POI binaries plus all its
dependencies (20 some jars or so).

When I try to create the top-level object:

workbook =
javaloader.create("org.apache.poi.xssf.streaming.SXSSFWorkbook");

I get this strange error, down in the stack trace:

org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory

Now, obviously this gives ya'll nothing to go on to help me with this
specific problem.

What I'm wondering is: have any of you ever seen this kind of error
before, which is seemingly nonsensical? I wouldn't think it's a
classloader problem with CF's classloader since I'm not telling JL to
use the parent classloader.

Any tips on debugging this?

Thanks!

[Leigh]

> I get this strange error, down in the stack trace:
>
> org.dom4j.DocumentFactory cannot be cast to
> org.dom4j.DocumentFactory
>

> What I'm wondering is: have any of you ever seen this kind
> of error
> before, which is seemingly nonsensical?

Disclaimer: This may be no help at all, but - yes I have seen it before. IIRC it is a class loader problem. If you do a search I am pretty sure Mark discussed the issue in a thread about xml parsing (maybe?).

-Leigh

[Marc Esher]

Great. Thanks Leigh. I'll try to hunt that bugger down.

[Marc Esher]

I think I Found the thread in question:

http://groups.google.com/group/javaloader-dev/browse_thread/thread/997676def933c5f7/e82cf5ca200cf837?lnk=gst&q=cannot+be+cast+to#e82cf5ca200cf837

I gave that a shot, using the code below:

paths = directoryList(expandPath("lib"), false, "array");
writeDump(paths);

_thread = createObject("java", "java.lang.Thread");
currentClassLoader = _thread.currentThread().getContextClassLoader();

try{
jl = createObject("component", "javaloader.Javaloader").init(paths);
_thread.currentThread().setContextClassLoader(jl.getURLClassLoader());

wb = jl.create("org.apache.poi.xssf.streaming.SXSSFWorkbook").init(100);
} catch( any exc ){
rethrow;
} finally{
_thread.currentThread().setContextClassLoader(currentClassLoader);
}

But when I do that, I get this weird one:

Object Instantiation Exception.
Class not found: coldfusion.runtime.java.JavaProxy

The error occurred in
C:\dev\projects\wwwroot\javaloader\javaloader\JavaLoader.cfc: line 329
Called from C:\dev\projects\wwwroot\javaloader\javaloader\JavaLoader.cfc:
line 87
Called from C:\dev\projects\wwwroot\sandbox\poi\poi_xsff_example.cfm: line 13
Called from C:\dev\projects\wwwroot\javaloader\javaloader\JavaLoader.cfc:
line 329
Called from C:\dev\projects\wwwroot\javaloader\javaloader\JavaLoader.cfc:
line 87
Called from C:\dev\projects\wwwroot\sandbox\poi\poi_xsff_example.cfm: line 13

327 : <cfargument name="class" hint="the java class to create the
proxy with" type="any" required="Yes">
328 : <cfscript>
329 : return createObject("java",
"coldfusion.runtime.java.JavaProxy").init(arguments.class);
330 : </cfscript>
331 : </cffunction>

IT's as if overwriting the current class loader causes CF to lose its mind.

Marc

[Mark Mandel]

Yeah, that's not shocking.

Not sure why I didn't put this in the original post, but try it this way:

javaloader = new JavaLoader(loadPaths=loadpaths, loadColdFusionClassPath=true);

Then your version of the classLoader path can find the CF classes as well, but under the JL's classloader.

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

cf.Objective(ANZ) + Flex - Nov 17, 18 - Melbourne Australia
http://www.cfobjective.com.au

[Marc Esher]

Mark, you beautiful friggin aussie.

To be clear: the suggested way of working with javaloader is to create
an instance of it in the server scope.

But with this approach, I'll be creating a new javaloader every time,
correct?

My question is: what are the memory leak implications here, and is
there anything else i should do to ensure i don't hit leaks, etc?

I took a heap dump, and sure enough, I see a lot of
"com.compoundtheory.classloader.NetworkClassLoader" instances..
Question is: how do I get rid of those guys?

I hooked up a jmeter test to run this process repeatedly, and the good
news is that garbage collection does appear to get rid of these
instances as it needs memory. Ideally they wouldn't hang around at
all, but hey, if the JVM can do its thing, I guess I'm satisfied.

Thanks!

Marc

On Jul 18, 8:14 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> Yeah, that's not shocking.
>
> Not sure why I didn't put this in the original post, but try it this way:
>

> javaloader = new JavaLoader(loadPaths=loadpaths, *
> loadColdFusionClassPath=true*);

>
> Then your version of the classLoader path can find the CF classes as well,
> but under the JL's classloader.
>
> Mark
>
>
>
>
>
>
>
>
>
> On Tue, Jul 19, 2011 at 3:24 AM, Marc Esher <marc.es...@gmail.com> wrote:
> > I think I Found the thread in question:
>

> >http://groups.google.com/group/javaloader-dev/browse_thread/thread/99...

> > On Mon, Jul 18, 2011 at 12:47 PM, Marc Esher <marc.es...@gmail.com> wrote:
> > > Great. Thanks Leigh. I'll try to hunt that bugger down.
>

> > > On Mon, Jul 18, 2011 at 12:13 PM, Leigh <cfsearch...@yahoo.com> wrote:
> > >>> I get this strange error, down in the stack trace:
>
> > >>> org.dom4j.DocumentFactory cannot be cast to
> > >>> org.dom4j.DocumentFactory
>
> > >>> What I'm wondering is: have any of you ever seen this kind
> > >>> of error
> > >>> before, which is seemingly nonsensical?
>
> > >> Disclaimer: This may be no help at all, but - yes I have seen it before.
> > IIRC it is a class loader problem. If you do a search I am pretty sure Mark
> > discussed the issue in a thread about xml parsing (maybe?).
>
> > >> -Leigh
>
> --

> E: mark.man...@gmail.com

[Marc Esher]

After banging on it more with jmeter and taking heap dumps along the
way, I'm convinced that this will not be a problem. The
NetworkClassLoader instances are kept in a soft reference, and they're
going away quickly. So... I consider this a non-problem.

Thanks again for the guidance, everyone. Ya'll rock.

[Mark Mandel]

Quick answer - you can still put it in the server scope, just be sure to use this approach when you first set it up, and I'm pretty sure you should be good from then on.

Mark

Sent from this mobile doohickey.

[Mark Mandel]

Longer answer - dom4j sets up it's singletons on first load (or as a static block, I forget), and once it's done, you don't need to worry about it anymore - so you can still 

One of these days I will submit a patch to dom4j to fix this issue.... really, I will.

Mark

--
E: mark....@gmail.com

[Mark Mandel]

That should have read -

Longer answer - dom4j sets up it's singletons on first load (or as a static block, I forget), and once it's done, you don't need to worry about it anymore - so you can use it after the fact.

Got excited and hit 'send'.

Mark

On Wed, Jul 20, 2011 at 9:57 AM, Mark Mandel <mark....@gmail.com> wrote:

Longer answer - dom4j sets up it's singletons on first load (or as a static block, I forget), and once it's done, you don't need to worry about it anymore - so you can still 

[Leigh]

>> One of these days I will submit a patch to dom4j to fix this issue.... really, I will.

If it helps, I am sure it would make a lot of people very happy ;-)

[Marc Esher]

As a final follow-up on this, I wanted to let you know that this
approach did in fact work fine. Coupled with Jamie Krug's
JavaLoaderFactory, I'm all set.

Thanks, dudes!

On Jul 19, 7:57 pm, Mark Mandel <mark.man...@gmail.com> wrote:
> That should have read -
>
> Longer answer - dom4j sets up it's singletons on first load (or as a static
> block, I forget), and once it's done, you don't need to worry about it
> anymore - so you can use it after the fact.
>
> Got excited and hit 'send'.
>
> Mark
>

> On Wed, Jul 20, 2011 at 9:57 AM, Mark Mandel <mark.man...@gmail.com> wrote:
> > Longer answer - dom4j sets up it's singletons on first load (or as a static
> > block, I forget), and once it's done, you don't need to worry about it
> > anymore - so you can still
>
> --

> E: mark.man...@gmail.com

[Mark Mandel]

Awesome, glad to hear it.

Mark

--
E: mark....@gmail.com