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
On Tuesday, November 5, 2013 4:41:50 PM UTC-5, charlie arehart wrote:
>
> I think you would find that if you moved the itext.jar from cf8 to the
> web-inf/lib in cf10, it would cause it to override that in CF10’s own
> internal lib directory. Again, I think that’s the point of that alternative
> lib where you are to put your own.
>
> Now, while that may allow your own code you’re calling to work, I’ll note
> that it could break other functionality within CF10 (if you, or others on
> your server use it) when it tries to call the classes that IT expects to
> find in the CF10 version of that itext.jar.
>
> Finally, I’ll repeat a point I made initially: no, you CANNOT just rename
> the new file and hope that will prevent such difficulties. Java does NOT
> pay attention to jar file names, at all. It pays attention only to class
> names and package names (as used when the object is referred to in code),
> and then it searches through its classpath to find that package/class in
> any of the hundreds of jars that may exist in the various directories on
> its classpath—and that’s why the order in which those directories is
> searched.
>
> I was about to say that you may just be down to a conflict that you can’t
> resolve, because you can’t have the two versions of the jar serving the two
> purposes at once. But then I realized something: if you are yourself
> prepared to forego (in some one app) the use of any CF10 features that
> would rely on that CF10 jar, then you CAN in fact solve this problem with a
> new feature that CF10 specifically does provide.
>
> CF10 now allows for a custom classloader, meaning that you can load a jar
> for use with only one application. That would prevent your use of the jar
> clashing with other users. Instead of putting it in the public classpath,
> you put it in a private one that you point to within your app, alone. That
> would keep it from hurting others, but again beware that in that app you
> would likely hit conflicts if you used features in CF10 that relied on the
> new jar it’s expecting.
>
> How does that sound? You can learn more about this in the CF10 docs at:
>
>
> http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSe61e35da8d318518-106e125d1353e804331-7fff.html
>
> Or if you got the CF10 WACK book, I did the chapter there on changes
> related to Java integration (this dynamic classloading and more, and more
> than is in the docs). I’m afraid it’s not online anywhere that I know of. I
> can also help, of course, via my consulting at the consulting page of
> carehart.org (if this is getting too deep in the weeds for the mailing
> list.)
>
> Hope that helps.
>
> /charlie
>
>
>
> *From:* [email protected] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *
> [email protected] <javascript:>
> *Sent:* Tuesday, November 05, 2013 9:07 AM
> *To:* [email protected] <javascript:>
> *Subject:* Re: [houcfug] Object Instantiation Exception. - Red Hat 6
>
>
>
> OK, Back to the drawing board.
>
>
>
> The iText.jar file was pulled from CF8 and placed on server to get me to
> these new errors.
>
>
>
> When the iText.jar was restored to the CF10 version that is should have
> been I am back to the same issue as when I began this post.
>
>
>
> So my question here is now, with the co_pdf.jar in
> the /opt/coldfusion10/cfusion/wwwroot/WEB-INF/lib/ location.
>
>
>
> Can I move an iText.jar from CF8 to that same location for my co_pdf.jar
> to reference? I believe that will cause conflicts with the same JAR files
> in JAVA Path.
>
>
>
> So can I rename it to iText_CF8.jar or something like that and move on to
> getting the Fonts loaded on server?
>
>
>
> Just wondering
>
>
>
--
--
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.
