coldfusion 10 classpath

[N0cT1v4Gus]

how does coldfusion 10 works with the classpaths?

ex. in cf9 it uses a very old version of jasper reports, when you try to overload it, it didn't work because of classpath problems and dependencies

would it be possible to create my own build of an implementation of jasper reports with it's dependencies which could have other versions of

.jar files which cf10 uses or would it again collide ?

calling my main class would work because the path is unique but when it will internally will use the dependencies from jasper with it's own depedencies

will it only look in the "classpath container" defined or will it collide again?

tx

[-__cfSearching__-]

I believe the basic mechanism is the same. CF's internal jars take precedence. However, ColdFusion 10 adds the ability to load custom jars on a per application basis using an Application.cfc setting. ( It is basically Mark Mandel's awesome JavaLoader bundled as built in feature of CF10 😉  So in theory, both versions of jasper reports can co-exist. 

There does not seem to be much official documentation on the setting for some weird reason. But this entry about closures gives a good description.

[N0cT1v4Gus]

so they can't, they will collide internally when the new version tries to lookup some own classes

it will take the first one found on the classpath and collide

[-__cfSearching__-]

Not quite.  How are you using jasper reports - with createObject("java")?  If so, did you see the link above about CF10's new custom class loader feature?

      http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSe61e35da8d318518-106e125d1353e804331-7ffe.html

[itisdesign_-_AH]

I did some playing around w/ THIS.javaSettings and just thought I'd mention a couple of things, in case any of it helps..

@N0cT1v4Gus, CF Admin's "Java and JVM" page writes the contents of the "ColdFusion Class Path" box to the end of the -Dcoldfusion.classPath list in C:\ColdFusion10\cfusion\bin\jvm.config.  You might try making a backup copy of the jvm.config file, and adding your path(s) to be beginning of the -Dcoldfusion.classPath list.  Be careful tho, b/c if you ever click the "Submit Changes" button on the Java and JVM page, then your entries will be automatically moved to the end of the list.  (so you'd need to manually move them again)  There will soon be an ER filed to also allow CF Admin to display the full -Dcoldfusion.classPath string, and I'll try to remember to follow-up here w/ the ticket#.

@Leigh, just wanted to note that THIS.javaSettings does work nicely in most cases.  But I currently have an open case regarding a situation where it doesn't (even w/ loadColdFusionClassPath=false).  In that same case, jvm.config works perfectly fine.  I also tried Mark's JavaLoader directly, but the issue exists there as well.  Basically, THIS.javaSettings has problems w/ HTMLUnit.  Depending upon what that underlying issue is, it's possible that THIS.javaSettings doesn't yet work for all cases.  Of course N0cT1v4Gus may never have an issue.  Just noting that I did is all.

Thanks,

-Aaron

[-__cfSearching__-]

@Aaron - Very true. I have found certain libraries (dom4j, etectera) are known to be problematic whenever multiple class loaders are involved in any application. So you are right that THIS.javaSettings may not work in all cases. Coincidentally, I just ran into a problem with the new setting as well. I have a few suspicions, but am still investigating. Out of curiosity, what is the bug number for your HTMLUnit issue (nothing came up in a brief search)? I am just curious if your issue is the same or related as mine.

Message was edited by: -==cfSearching==-

[-__cfSearching__-]

@Aaron - I think I found it.  Is this the HTMLUnit bug? 

         https://bugbase.adobe.com/index.cfm?event=bug&id=3121307

As an aside, wow .. that library is a good test case. Almost every single one of the dependencies is already built into CF. No wonder there were problems 😉

[itisdesign]

@Leigh, yes you found it!  #3121307.  It's been a fun one for sure.  Currently, I can:

1) Use jvm.config if I a) remove the nekohtml.jar from CF's lib directory, or b) manually place HTMLUnit's lib directory at the front of jvm.config's CF Class Path

2) Use THIS.javaSettings, w/ loadColdFusionClassPath=false, if I remove HTMLUnit's xml-apis-1.3.04.jar

#1 is the most dependable.  While #2 seems to work at-this-very-moment, I do recall an error still being thrown during one of my tests. (just can't remember atm what I was doing)

I wish Adobe would've added some notes to #3121307 before marking it Closed/Fixed, b/c I don't see how it's fixed yet =P

Thanks,

-Aaron

[-__cfSearching__-]

Well if they are anything like me, they just swallowed some asprin, closed their eyes, and hoped the class loader headaches went away 😉  On a more serious note, in the absence of comments/release notes/etcetera I am not sure how it is fixed either ...

(I have not tried your test case yet, but ...) If it were not for the error, option #2 would be my preference.  Any chance you have the error logs or stack traces lying around? If you do, attach them to the bug report. That might help identify which libraries tend to be problematic. So even if the issue is not (or cannot be) fixed, there is at least reference out there for others that run into similar problems.

[N0cT1v4Gus]

tx for your testings guys, at the end i've installed the jasper server version and used rest and soap services on it which is much cleaner

also with ireports you can directly work on the server so it was the cleanest option