dom4j not found in production

[david macphail]

Hi everyone,

Hoping that someone can point me in the right direction here. We have a couple of coldfusion pages, reading and writing excel files quite happily in our development environment. We're using coldfusion 10 and implementing Marks javaloader in those pages. We had some initial issues with the set up, but thank to some help from Mark, worked through and got it all going.

We've now moved the classes and CF pages to our production environment and cannot get it to work no matter what we do. The error is 

java.lang.ClassNotFoundException: org.dom4j.DocumentException 

and I've attached the full error log for clarity. 

If anyone in the group can shed any light on the problem with our set up I'd be forever grateful.

Feels like we're going round in circles at the moment.

Thanks in advance

Dave 

[Mark Mandel]

First question would be, what code is at:

at cfPartsLoadXLS2ecfm1290349705$funcIMPORTXLS.runFunction(E:\inetpub\wwwroot\agconetTplProd11\PartsLoadXLS.cfm:116)

My other thought is, that isn't not a dom4j issue. Looks like dom4j is trying to throw an exception. For some reason it can't load the class (no idea why), but it's erroring for some reason or another.

Could production have different file permission issues?

Mark

--
You received this message because you are subscribed to the Google Groups "javaloader-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaloader-de...@googlegroups.com.
To post to this group, send email to javaloa...@googlegroups.com.
Visit this group at http://groups.google.com/group/javaloader-dev.
For more options, visit https://groups.google.com/d/optout.

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

2 Devs from Down Under Podcast

http://www.2ddu.com/

[Jaime Metcher]

This error can be the symptom of a completely missing dom4j.  CF10 should ship with dom4j-1.6 (ish), so unless it has mysteriously gone missing (worth checking) I'd be wondering if javaloader isn't talking to the CF classloader.  Are you initializing javaloader in exactly the same way on production?

Jaime

[david macphail]

Hi again Mark,

Thanks for the quick reply. The code at that part of the page is

// a function has to be created to call the program

//this gives us named arguments

function importXLS(program, mvxDbCon, mvxdt, status, path) 

{

    return program.GitXLS(mvxDbCon, mvxdt, status, path);

}

session.arrParts = javaloader.switchThreadContextClassLoader(importXLS, {program = up, mvxDbCon = application.mvxdbcon, mvxdt = application.mvxdt, status=501, path=filePath});

</cfscript>

I too wonder if its an issue with ust the new files. Surely if there was a geniune issue with dom4j far more pages would be affected.

Dave

[david macphail]

Hi Jaime,

Thanks for replying, this is driving us nuts. Dom4j is definitely there. Its in the classpath of the application. As for the javaloader implemenation, it certainly looks to be exactly the same. This morning I went through the coldfusion administrator setups on both servers and they look identical.

Dave

[Mark Mandel]

What happens if you just try and read the file in via regular CFFile? Does it throw a permission issue?

Mark

[david macphail]

Good question, I'll give it a go and let you know

Dave

[david macphail]

Afraid not, I read it into CFFILE and dumped it and it just looks like excel data

On Thursday, April 17, 2014 9:49:41 AM UTC+10, Mark Mandel wrote:

[Mark Mandel]

Next fun trick - try:

(I think this will work, been a while since I've written CF)

createObject("java", "http://dom4j.sourceforge.net/dom4j-1.6.1/apidocs/org/dom4j/DocumentException.html").init()

On both servers.

See if it works on both.

Mark

[todd sharp]

How in the hell does that work??

[david macphail]

Hmmm 

Class not found: http://dom4j.sourceforge.net/dom4j-1.6.1/apidocs/org/dom4j/DocumentException.html 

On both servers.

[Mark Mandel]

Oops! I copied that badly, didn't I. Can't you all ready my mind ;)

createObject("java", "org.dom4j.DocumentException").init()

What does that do.

Mark

[david macphail]

 Same result on both servers.

Error occurred in DOM4J application. 

org.dom4j.DocumentException: Error occurred in DOM4J application. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at coldfusion.runtime.java.JavaProxy.CreateObject(JavaProxy.java:166) at coldfusion.runtime.java.JavaProxy.invoke(JavaProxy.java:80) at blah blah blah

Would the whole stack trace help in any way?

Dave

[Jaime Metcher]

Well, here's the source code for the no-arg constructor for DocumentException:

public DocumentException() {

super("Error occurred in DOM4J application.");

}

;)

You may not be this desperate yet, but starting the JVM with -verbose:class will tell you exactly where dom4j is being loaded from and what other classes are being loaded.  If you're lucky, you might find that your dev box isn't loading the dom4j you think it is.  Slightly less convenient but still useful would be to discover that the SAX parser discovery mechanism is pulling in stuff on dev that is different on production.

BTW, Mark, feel free to tell me to butt out if I'm just muddying the waters here :)

Jaime

[david macphail]

Thanks for the input, Jaime.

This got sidelined over Easter and we've had other issues since. I'll definitely give that a try as we're pretty much out of ideas.

Thanks

Dave