Glad you may have finally resolved things. You conclude wondering how "you
should be able to include LIBRARY files that exist today without worrying
about someone else using your method name in the future."
Well, the problem here is that your code is calling a library that someone
else wrote (iowagie, makers of the itext.jar), and you are calling something
in there. Your first mail showed the failure at:
this.oPDF = createObject("java",
"com.co.itext.pdf_writer.pdfLibReplace").init();
So when you refer to "someone else using your method name in the future",
what are you referring to? By "your method name", are you speaking as
iowagie? Or as you calling their class? Because the "someone else using your
method name" in the case of the method you were calling was that of the
itext jar, called pdfLibReplace in the pdf_writer class. And the way that
Java knows that it's THAT specific class and not any other on the system is
that it references it as being in the packagename, com.co.itext.
But if you (or anyone) puts another jar into the classpath that has classes
with the same packagename, then you will have such conflicts, and again
that's where having a dir that can force a given jar to be searched first
(like the [cf]\wwwroot\web-inf\lib, which overrides the [cf]\lib), or the
use of custom classloaders, as the new CF10 feature provides, or Mark
Mandel's Javaloader project provided in earlier releases.
Make sense?
/charlie
From: [email protected] [mailto:[email protected]] On Behalf
Of [email protected]
Sent: Thursday, November 07, 2013 5:12 PM
To: [email protected]
Subject: Re: [houcfug] Object Instantiation Exception. - Red Hat 6
Charlie and anyone else that might be interested.
It took me three times or more of reading your note to have it sink into my
thick skull, but I got what you were saying and came up with a Hack of a
solution.
CF10 is installed stand alone. Our application is the only thing running on
the server and iText.jar is not used by any part of the application today
that we are aware of soo........
I removed iText.jar from the class path (I have it around so I can correct
root cause later, but is there ever a later?) and then the co_pdf.jar
started to work...Well kind of
the Font business was still an issue so I placed the *.afm files into the
co_pdf.jar file that it needed so that then resolved that issue.
The true resolution will be to rewrite the co_pdf.jar to use the newer
iText.jar libraries.
So here is another observation that I would like to share here as well. The
code:
<cfset x=createObject("java","com.lowagie.text.Rectangle")>
<cfdump
var="#X.getClass().getProtectionDomain().getCodeSource().tostring()#">
Helped to solve this issue.
On Windows servers, this yields my co_pdf.jar file as the owner or more to
the exact code out of:
(file:/C:/ColdFusion10/cfusion/lib/co_pdf.jar <no signer certificates>)
On Red Hat 6, this yields:
(file:/opt/coldfusion10/cfusion/lib/iText.jar <no signer certificates>)
So another possible long term solution would be to figure out on Red Hat 6
why the iText took prescience over the libraries that are referenced within
the JAR file that is using it in the first place.
but it is like you had told me before "any of the hundreds of jars that may
exist in the various directories on its classpath" that I was not grasping.
Just wondering how to avoid this.
I mean I hope that code that I write today can stand the test of time like
this code has.....It was written in 2006 and is still working on our Windows
servers....you should be able to include LIBRARY files that exist today
without worrying about someone else using your method name in the future.
And I know I know the whole CF10 javaSettings deal is out there, but you may
still need to load the loadColdFusionClassPath = true which will help cause
the same issue I was facing, unknowingly.
Anyway just wanted to post the conclusion to the situation.
Again, thank you everyone for you input it really helps.
Matthew C. Parks
--
--
You received this message because you are subscribed to the "Houston ColdFusion
Users' Group" discussion list.
To unsubscribe, send email to [email protected]
For more options, visit http://groups.google.com/group/houcfug?hl=en
---
You received this message because you are subscribed to the Google Groups
"Houston ColdFusion Users' Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
