OK, I think the key may be in your response to the code I offered, to find out from what jar your class was being loaded. You say it was in the itext.jar that comes with CF10.
So now, what about if you run that code on the other server where things were "working"? a) It could be that on that server, it was found in an older version of that built-in itext.jar (in which case you may be hitting an incompatibility in those versions with respect to what you're trying to hard-code via calls to their java objects). b) Or it may be that the called java object is found (on the old, working server) to be in some other jar that you guys had put on the server. In that case, it may be down to either getting that particular jar to be "found first" in CF10, or it may again be that that particular jar (one of those you refer to) is itself not compatible with the version of itext.jar (or other related pdf jars) that are provided with CF10. And you may be sensing that, since you ask at the end what version of "What iText.jar shipps with CF10?" I'm afraid I don't know the answer to that question. But I will say that it wouldn't surprise me if there are dependencies that your old code (and old jar) may have been relying on which could have changed in the move to 10. Adobe only strives to confirm that their own CFML tags/functions that use given java objects will work in a new release. Of course, they can't do anything to help confirm that such changes won't affect those who make direct calls to the embedded java objects. They also don't tend to document the versions of included java projects, like itext. But a little googling finds that someone has documented 2 ways to determine that: http://cfsearching.blogspot.com/2007/12/how-to-determine-version-of-itext.ht ml Let us know how you get on. /charlie From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, November 04, 2013 11:17 AM To: [email protected] Subject: Re: [houcfug] Object Instantiation Exception. - Red Hat 6 @mparks, you say you put the file in the opt\ColdFusion10\cfusion\lib. There are indeed jars there, but those are ones that come with CF. For you to add your own, you ought instead to put it in opt\ColdFusion10\cfusion\wwwroot\WEB-INF\lib. That's indeed the documented, at: http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172 e0811cbec14231-7fe5.html#WSc3ff6d0ea77859461172e0811cbec14231-7fd3 Now, I appreciate that you may be saying that you have always put it there, and you're saying that you see it in the Cf Admin display of the class path. But are you confirming that the specific "older company_pdf.jar" you refer to originally is shown in there at that specific location? MCP: Original is shown in this location on a Productivity server running Windows/CF10 Also, do you see any other pdf.jar files? MCP: There are other PDF.jar files in the \opt\ColdFusion10\cfusion\lib\ namely: pdfencryption.jar; pdflib.jar More specifically, you call it company_pdf.jar, but I wonder if it may be providing the same sort of stuff that some built-in CF jars/libraries may provide. Could it be that the conflict you're hitting is not due to the file you're playing with, but some others that CF/Java are finding? That's one more reason to put it in the web-inf\lib, in case CF may load it in precedence over its own, giving you the chance to upgrade something that's built-in. MCP: I moved the company_pdf.jar to the /cfusion/wwwroot/WEB-INF/lib/ as you have suggested. I removed it from \opt\ColdFusion10\cfusion\lib\ and I am still getting this error: org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [CfmServlet] in context with path [/] threw exception [Servlet execution threw an exception] with root cause java.lang.NoSuchMethodError: com.lowagie.text.Rectangle.width()F at com.co.itext.pdf_writer.GridBase.initSizes(GridBase.java:58) at com.co.itext.pdf_writer.pdfLibReplace.open_file(pdfLibReplace.java:56) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at coldfusion.runtime.StructBean.invoke(StructBean.java:508) at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:2465) at cfcspec_lib2ecfc963610666$funcPDF_INITIALIZE.runFunction(/var/www/html/prod/ cfcs/forms/co_lib.cfc:46) at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:472) at coldfusion.filter.SilentFilter.invoke(SilentFilter.java:47) at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:405) Finally, do look in the web-inf\lib, even if you have some reason to prefer to keep yours in the other lib. Maybe there's another jar there that is in fact conflicting with yours. Java doesn't care about file names, so if there are two that have a given class (and package name), it will load the first it finds among all jars/classes it's got access to. In that regard, you could dump the java object and find out the jar that CF/java found it in. You may be surprised to find that the object is not being found where you think it is. :-) <cfset x= createObject("java", "yourpackage.yourclassname")> <cfdump var="#X.getClass().getProtectionDomain().getCodeSource().tostring()#"> MCP: (file:/opt/coldfusion10/cfusion/lib/iText.jar <no signer certificates>) Let us know how you get on with this. /charlie PS If that helps, mparks, I'd like to make a trade: to you and some others, why are many people averse to putting their names in their from addresses and/or signatures? :-) It just would be nice for us to be able to refer to you by name when we're trying to help. MCP: RECAP : So My original post was with this error: Stack Trace at cfco_lib2ecfc963610666$funcPDF_INITIALIZE.runFunction(/var/www/html/prod/cfc s/forms/co_lib.cfc:40) at cfinq_app_pdf2ecfc740122486$funcRENDER_PDF.runFunction(/var/www/html/prod/cf cs/forms/inq_app_pdf.cfc:200) at cfinq_app_screen_finished22ecfm913491559._factor11(/var/www/html/prod/forms/ gen_cf/inq_app_screen_finished2.cfm:37) at cfinq_app_screen_finished22ecfm913491559.runPage(/var/www/html/prod/forms/ge n_cf/inq_app_screen_finished2.cfm:1) java.lang.ClassNotFoundException: com.co.itext.pdf_writer.pdfLibReplace This issue was resolved due to the Admin that installed it FTP process corrupted the JAR file. With a Clean JAR (co_pdf.jar) The jar was in cfusion\lib\ - by the by - a new error message came up which I am still facing at this point. I have moved the JAR to /cfusion/wwwroot/WEB-INF/lib/co_pdf.jar and i am still getting an error that seems to be pointing to the iText.jar. At this point. Looking at the Manifest file in the iText.jar yeilds: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.2 Created-By: 1.5.0_14-b03 (Sun Microsystems Inc.) Main-Class: com.lowagie.tools.Toolbox What iText.jar shipps with CF10? This what I need to figure out and hope that his will solve issue. I wanted to get this out so if there are holes in the theory someone may address for me. Thanks. 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.
