charlie.
I don't mean to kick a dead hourse here, but based on my observations on
this issue, FOR Red Hat 6 install of CF10 your statement of
the [cf]\wwwroot\web-inf\lib, which overrides the [cf]\lib
Is not ture. That is the whole reason I had to do the iText.jar removal
from the [cf]\lib
I was expecting it to work in that manner, like it is on our Windows Server
installs but it is not. Thus my finial solution.
So what you said make perfect since to me it is just it was not working in
that manner for this OS install.
I did explore the new feature of CF to load the javaSettings at the
application scope variable but abandoned that in the chios. I am planning
on revisiting in the near term. I like dynamic loading idea.
How can you confirm the ClassPath information with the javaSettings? I was
not able to get that figured out.
Matthew C. Parks
On Thursday, November 7, 2013 11:18:12 PM UTC-5, charlie arehart wrote:
> 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] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *
> [email protected] <javascript:>
> *Sent:* Thursday, November 07, 2013 5:12 PM
> *To:* [email protected] <javascript:>
> *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.
