Having an issue where I will be using a component, instantiated like this:
<cfset xmlLib = CreateObject("component", "myLIB.mycfc")>
and it will all of a sudden start throwing errors that it cannot find the component.
'Could not find the ColdFusion component or interface myLIB.mycfc'. I am really at a loss as to why it will suddenly lose these mappings.
Related
I'm attempting to connect to Java (JAR) libraries to communicate with the "QuickBooks Merchant Services API".
Each call to the API requires an OAuth2 access token. My first step is to use the Java SDK that QuickBooks provides to get the access token.
I downloaded the "jar-with-dependencies.jar" option from this page. According to Maven, 6.0.1 is the current version.
https://search.maven.org/search?q=a:oauth2-platform-api
I created a folder named "java" off of the root of the web site and stored this file in that folder.
oauth2-platform-api-6.0.1-jar-with-dependencies.jar
In Application.cfc, I added this line of code:
<!--- Application.cfc snippet --->
<cfset this['javaSettings'] = {
LoadPaths = ["#expandPath('/java')#"]
,loadColdFusionClassPath = true
,reloadOnChange = true
,watchInterval = 100
,watchExtensions = "jar,class,xml"
}>
In a test.cfm file I have the following lines of code in a function:
variables['oauth2Config'] = createObject("java", "com.intuit.oauth2.config.OAuth2Config").OAuth2ConfigBuilder(arguments.clientId, arguments.clientSecret).callDiscoveryAPI(Environment.SANDBOX).buildConfig();
In an example on the developer.intuit.com web site, the Java code looks like this:
OAuth2Config oauth2Config = new OAuth2Config.OAuth2ConfigBuilder("clientId", "clientSecret").callDiscoveryAPI(Environment.SANDBOX).buildConfig();
When I run the code, I get the following error message.
Class not found: com.intuit.oauth2.config.OAuth2Config
I have swapped out the "LoadPaths" key with several different variants but all result in the same error.
LoadPaths = ["/java"]
LoadPaths = ["./java"]
LoadPaths = ["./java/oauth2-platform-api-6.0.1-jar-with-dependencies.jar"]
I have tried modifying the initialization call:
local['oauth2Config'] = createObject("java", "OAuth2Config").OAuth2ConfigBuilder(arguments.clientId, arguments.clientSecret).callDiscoveryAPI(Environment.SANDBOX).buildConfig();
That resulted in basically the same kind of error:
Class not found: OAuth2Config
I'm pretty sure that I'm doing something wrong in the this.javaSettings struct in Application.cfc. I was hoping that the Java JAR approach would be easier, but I may end up using the REST API that Intuit has. I still have to use OAuth2 and I'm not sure if the cfoauth tag/function will work with this system.
Let me know if you see anything that will help me get past this problem.
CF can't find OAuth2ConfigBuilder because it's inner class, which requires a slightly different syntax:
createObject("java", "com.intuit.oauth2.config.OAuth2Config$OAuth2ConfigBuilder");
Environment is also a class within the jar. You must create a reference to it before using the constant Environment.SANDBOX
Even after fixing those issues, a brief test with CF2016 threw a LinkageError due to the inclusion of slf4j within the custom jar, while also loading the jars from CF/lib (which includes slf4j too). Switching to loadColdFusionClassPath = false seemed to get past that error.
java.lang.LinkageError: loader constraint violation: when resolving
method
"org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;"
the class loader (instance of
coldfusion/runtime/java/JavaDynamicClassLoader)
...
Application.cfc
this['javaSettings'] = {
LoadPaths = ["#expandPath('/java')#"]
,loadColdFusionClassPath = false
, ...
};
Code:
variables['environ'] = createObject("java", "com.intuit.oauth2.config.Environment");
variables['builder'] = createObject("java", "com.intuit.oauth2.config.OAuth2Config$OAuth2ConfigBuilder");
variables['oauth2Config'] = variables['builder'].init( arguments.clientId, arguments.clientSecret).
callDiscoveryAPI( variables['environ'].SANDBOX ).buildConfig();
I have a perplexing issue. I have Web Service A (henceforth WSA), a 3.5 .Net WCF, which I have added a call to Web Service B (henceforth WSB) which is a 3.5 .Net ASMX. When running WSA in the client (SOAPUI or WCFStorm), the WSB call times out per the client timeout setting.
In the VS event viewer I can see that the call to WSB immediately throws two error 400s:
Exception thrown: 'System.Net.WebException' in System.dll ("The remote
server returned an error: (400) Bad Request."). Exception thrown:
'System.Net.WebException' in System.dll ("The remote server returned
an error: (400) Bad Request.")
No reason is given. What is just as puzzling to me is the error doesn't go to my catch. When I debug and I hit the line of code that calls WSB, it's like a reset. No further code gets executed and no error is thrown by my WSA.
If I call WSB directly, it works. So nothing is wrong with WSB. At suggestion of a coworker, I took the code specific to my change and put it in a stand-alone service. I literally C&P the code and configs setting specific to me and adjust namespaces and class names. Lo and behold it works. My stand-alone web service called WSB just fine and get the data I expect.
A coworker and I checked the logs (IIS log for the service and the HTTPERR log) on the IIS server that WSB resides on to see if there was any mention of the 400 error. We found none.
So we are kind of perplexed at this point. The only thing we can think of is perhaps something in the web config might be interfering but have no idea what it could be.
If you have any suggestions of where else to look that would be helpful.
And it would be nice to know why it isn't falling into my error handler.
Thanks.
Update: It was requested I add config and code. I don't think it will help honestly and it is pretty straightforward. I can't put the real code due to company reasons but it is basically this:
In web config:
<configuration>
<appSettings>
<add key="endpointUrl" value = "someurl" />
</appSettings>
.
.
.
<applicationSettings>
<MyService.Properties.Settings>
<setting name="MyService_TheirService"
serializeAs="String">
<value>someurl</value>
</setting>
</MyService.Properties.Settings>
</applicationSettings>
Even though the data is super small I did try making large reader settings and such:
<binding name="CustomHtttpBinding" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" closeTimeout="01:50:00" openTimeout="01:50:00" sendTimeout="01:50:00" receiveTimeout="01:50:00" >
<readerQuotas maxDepth="128"
maxStringContentLength="8388608"
maxArrayLength="2147483646"
maxBytesPerRead="4096"
maxNameTableCharCount="16384" />
</binding>
Code:
using MyService.TheirService
.
.
.
var theirURL = ConfigurationManager.AppSettings["endpointUrl"];
var oSvc = new TheirServiceObject
{
Url = theirURL
};
int numberIneed = oSvc.SomeMethod();
That last line is where it throws the 400.
UPDATE 2:
A colleague show me how to use Fiddler. And I can now see that the request to WSB is absolute garbage.
xڭ s 6 mr!!u \ .3 5'3 G QOH>Iп kX M3 ~vY ) X e Z
w ~ :jv -ݴwڽHb Yqv A :(Q Z; >9W O0g 6 .ɖVlU Ţ 8Z
< ( t eSv U]r R $N \
Some odd encoding? At least it's another clue.
Wanted to let you know this problem was solved. Another Dev that had worked on this service before but no longer just happened to walk by and I said "Hey! Look at this!"
They saw the garbage request data and said "That looks like compression. Look up compression in the project."
Turn out there was a custom compression component that was compressing the outgoing data of the service and you needed to add 2 lines of code to decompress. After adding those lines to the top of my method everything immediately worked.
The lesson here is if your project is doing some weird stuff that defies reason, try and find as many people as you can that worked on it before even if they aren't working on it anymore.
We have a set of Coldfusion applications that all extended various parts of an application base. I'll provide a bit of code and then explain the issues we are having and see if anyone can shed light on the best way to trouble shoot this:
In our "OnRequestStart" in the app.cfc we have the following line to initiate a user:
if(!structKeyExists(SESSION, 'user'))
SESSION.user = CreateObject("component","cfcs.ds_user");
Then in the ds_user.cfc we call it like so:
component extends="cas.cas_user" displayname="basic_user"{
The application and all its parts run just like they should. However, in a seeming random manner after a while, the application will crash and I have to restart ColdFusion Service to get it running again. The error I get is:
Could not find the ColdFusion component or interface cas.cas_user.
So, for whatever reason after a while, my application decides it cannot find the path to the parent component. The mapping for that cfc is in the application.cfc at the top as so:
THIS.mappings["/cas"] = "#ReplaceNoCase(currpath,ListToArray(THIS.name,'_')[1],'cas30')#assets\cfcs\";
I want to be sure to say this, the application works perfectly as designed for a random amount of time and then it cannot find the parent component and will not find it again until I restart the ColdFusion Service on the server.
I figure this is somehow a memory leak or something, but I have no idea where to start looking to troubleshoot the issue. We have 6 or so other applications that are extended in the same way and work fine and never crash, but this one does.
EDIT: To be more clear on the mappings. Our applications are located:
root.com/app1
root.com/app2
We created mappings to grab cfcs from app2 while in app1 using the method above. The method, while I believe sort of strange, does work in all of our applications.
EDIT: The correct mappings that display for a while are:
/cfcs - D:\www\app1\assets\cfcs
/templates - D:\www\app1\assets\templates
/cas - D:\www\app2\assets\cfcs
/common - D:\www\app3\assets\common_elements
However once the Application goes in "crashed mode", the dump reveals the mappings are as follows:
/cfcs - D:\www\app1\assets\cfcs
/templates - D:\www\app1\assets\templates
/cas - D:\www\app1\assets\cfcs
/common - D:\www\app1\assets\common_elements
And here is how those mappings are defined at the start of the Application.cfc:
currpath = GetDirectoryFromPath(GetCurrentTemplatePath());
THIS.mappings["/templates"] = "#currpath#assets\templates";
THIS.mappings["/cfcs"] = "#currpath#assets\cfcs";
THIS.mappings["/common"] = "#ReplaceNoCase(currpath,ListToArray(THIS.name,'_')[1],'gum')#assets\common_elements\";
THIS.mappings["/cas"] = "#ReplaceNoCase(currpath,ListToArray(THIS.name,'_')[1],'cas30')#assets\cfcs\";
THIS.name = digisign_CAAAFACBFDFFE or
name_var = (arrayLen(meta_array) >= 2) ? meta_array[arrayLen(meta_array) - 1] & '_' : 'root_';
THIS.name = name_var & right(reReplace(hash(getCurrentTemplatePath()), "[^a-zA-Z]","","all"), 64 - len(name_var));
Where could it be failing. It seems the replace statement isn't working and therefore the appname in the path is not being changed from app1 to app2 when setting the mappings. is it possible this is related to this error we are currently working through: http://forums.adobe.com/message/4657868#4657868 We have yet to apply the Update 4 patch on production. However this problem we believe was happening before CF10. And while we have this issue, it only cropped up recently. This application in question has been crashing like this for a long time.
EDIT:
1. I guess when I say "crash" I mean the application gets into a state, where it will not declare the mappings correctly until I restart Coldfusion. I assume the error in our code causes the crash.
2.This is usually where the issue occurs, when doing this check of the SESSION.user var. I believe it has happened as well, it decides it cannot find our datasource. This is rare.
3. At first I thought yes, but actually no, not that many. Throughout our apps we have several names for common mappings. cas common cfcs templates etc. However D:\www\cas is where the application domain.com/cas30 is located. However a legacy version of that app is located at domain.com/cas. The mapping /cas should go to D:\www\cas30\assets\cfcs and works.
4.We have a dev setup and this never happens. (I assumed it was a load issue which is why it doesn't happen on dev). However, our dev environment is structred as so:
D:\www\deva\app1
D:\www\deva\app2
D:\www\devb\app1
D:\www\devb\app2
What we do (which I think is stupid) is we have a file located not in the same dir as the current app. This file is called application_base.cfc. All of the application.cfcs in the other applications extend from this application_base.cfc. They are not extended from other Application.cfc files. (hope that makes sense) In application_base is a init, onrequeststart, and an onerror. I'll post the App.cfc below. Also some setting are read from XML files both in the application base (to determine environment stuff) and at the application level. However we thought that might be causing the issue so the previous developer removed the xml file at the application level.
6.Yes. I'll post the app.cfc and the appbase.cfc so you can view both.
By reinitialize you mean call onapplicationstart or something. Not that I know of.
A few applications we have do:
currpath = GetDirectoryFromPath(GetCurrentTemplatePath());
app_path = ListToArray(currpath,'\');
THIS.name = app_path[ArrayLen(app_path)];
This one does:
meta_array = ListToArray(GetMetaData(this).name,'.');
name_var = (arrayLen(meta_array) >= 2) ? meta_array[arrayLen(meta_array) - 1] & '_' : 'root_';
THIS.name = name_var & right(reReplace(hash(getCurrentTemplatePath()), "[^a-zA-Z]","","all"), 64 - len(name_var));
A few others do this as well. Not sure if it was two different developers or something, but that is the way it is.
Once the app fails, it fails until I restart coldfusion. The app requires login from the domain.com/app page, so (not saying it cant change from request to request) but the request location is always the same where it's failing.
God I wish it wasn't this complex. I recently pulled our current CMS off of alot of this crazy stuff, but we have 7 or 8 applications that are so intertwined with each other and designed to work in dev/prod environments with different paths, its sometimes hard to tell what I can remove and what I can't.
I thought I tried dumping the applicationname from our error handler, but I thought it didn't work unless passed in. I passed through the mappings so I could see them which is how I know digisign is not changing to cas30 like it should in "crash" mode.
I think all the dynamic mappings were so the original developer could just use the same app.cfc template without changing anything. He liked to do stuff like var a = (b) ? (a-c) ? a-f+b : (a+b) ? d : d; : a; h; crap with no comments so it sometimes hard to just read the damn code let alone debug it.
EDIT
I feel like this issue and stackoverflow.com/q/14300915/1229594 issue may be related. I've posted some more details here as well: forums.adobe.com/message/5022377#5022377
First things first: why are you initialising session-oriented stuff in onREQUESTStart()? If you inited that in onSessionStart(), you'd not need to check for its existence every request, which - whilst trivial - is unnecessary overhead, and is simply the wrong code in the wrong place.
Secondly... you quote your error, but don't say where it's happening. Is it happening in that line in onRequestStart()?
If so, do me a favour: put a try/catch around it, and within that write the value of this.mappings to a log file, as well as the value of currPath. How is the value of that variable being derived, btw?
That said, I think if you just put that session.user init code in the right place, it'll solve your problem.
NB: frame this problem as almost certainly not a memory leak (ie: ColdFusion's fault), but your code doing something you did not anticipate (so... err... your fault ;-). This will help focus better on finding the problem. I'm not having a go at you, but "where is my code wrong" is a better approach than "it's probably something else". And more likely to be correct ;-)
Oh... and what version of CF are you on?
Take a look at this and see if it's relevant to your problem.
https://github.com/Mach-II/Mach-II-Framework/wiki/Application-Specific-Mapping-Workaround
If not, then it could have something to do with application specific mappings of the same name, on the same CF server, with those applications having different application names.
Some questions:
Are you assuming the crash is being caused by the code error, or that the code error is occurring because of the crash?
Is the instantiation of the session user the only line of code that you see these path errors?
Do you have any physical directories in your app that have the same name as the mapping names?
Does this occur in any other environments (dev/test)? Is this a clustered environment?
Are there multiple Application.cfc files extending this same Application.cfc?
Is there any code that is directly calling Application.cfc methods?
Are there any bits of code that cause the application to reinitialize itself?
What is determining the meta_array that is being used to derive the application name?
A few observations:
It seems to me that the application name is getting changed or that some other application is overwriting with the same name. This doesn't seem far-fetched as there's an awful lot of dynamic naming going on here. Starting with the application name, it's dependent on the current template's physical location, which could be different from request to request, depending on how the app routes requests. If the current template varies, the application name will vary, and cause the other app-specific mappings to change, which would cause a cascading effect to all the other mappings that use the app name to determine the physical location of those mappings.
Which begs the question: Why is all this dynamic evaluation of the application name and mapping locations even necessary? Can it be simplified or hard-coded? Can you instead use a server mapping? If it doesn't have to be this complex, simplifying it to its barest essentials will help troubleshooting and may clear up the issue entirely.
Finally, can you verify that the application name during normal operation is the same application name being referenced when the errors are occurring?
If they are different, then something is causing the application to execute within a different context (see my initial questions above for clues). A sudden change in the application name would invalidate any existing sessions and force the session user instantiation code to re-run. And because the user component paths are based in part on the application name, the paths may no longer be correct.
But if the application names are the same between normal operation and crash mode, then most likely the currpath variable is being affected by some part of the application being executed in a different physical path than expected. Since currpath is directly used in determining the rest of the mappings, that could certainly explain why an unexpected path could cause the component to go missing.
Because there are so many variables going into deriving these names, you would be well served to log those variables during normal operation and during crash mode. You'll want to see
GetCurrentTemplatePath()
GetDirectoryFromPath(GetCurrentTemplatePath())
THIS.name
meta_array
THIS.mappings
I suspect you'll find something significantly different in these variables when operating normally and when the crash/errors are occurring, and that difference should lead you closer to the answer.
My question seems to be related to this one:
Coldfusion memcached connections
however, i have been unable to solve it.
if i put this code in application.cfm:
<cfif not IsDefined("application.memcached")>
<cfset application.memcachedFactory = createObject("component","memcachedFactory").init("192.168.2.91:11211")>
<cfset application.memcached = application.memcachedFactory.getmemcached()>
</cfif>
the page will work for maybe 270 calls. then it will start to fail with an error "Object Instantiation Exception " The code is properly talking to memcached. I can send and receive data. it seems like java is running out of something .. threads, sockets, handles of some sort. I know little about java, and am stuck.
This seems wrong to me Don. Why would this code run again after the very first call? It should be running 1 time after which you have a reference to your object. What does the rest of your application.cfm look like? Have you added a cfapplication tag with a "name"?
If you fail to set an application "name" (via the cfapplication tag or "this.name" in application.cfc), the an "application.x" variable is treated just like a regular variable. After the page request ends it will "go away" and require the next request to reinstantiate the object over again.
The purpose of the "isDefined()" in this case is to insure it runs only once - providing you with a singleton (single reference) you can use again and again without reinstantiating it. It sounds like you are not "inside" an application.
I'm running CF 9.0.1 Developer and Coldbox 3.0.0 on my local machine (64-bit Windows Vista running 32-bit CF9 on Apache). I'm working on an application that I've checked out from SVN and deployed locally. Everything seems to be working correctly, but my application log is filling up with entries like this:
Apr 18, 2011 12:41 PM Error jrpp-7
exception.log has an extremely long stack trace for each exception, maybe 150 lines or so. It starts with this:
"Error","jrpp-4","04/18/11","11:07:30",,""
java.lang.NullPointerException
at coldfusion.util.Utils.getServletPath(Utils.java:86)
at coldfusion.util.Utils.getServletPath(Utils.java:76)
at coldfusion.util.Utils.getBaseTemplatePath(Utils.java:405)
at coldfusion.runtime.TemplateProxyFactory.getTemplateFileHelper
(TemplateProxyFactory.java:1522)
at coldfusion.runtime.MetadataUtils.getComponentMetadata
(MetadataUtils.java:112)
at coldfusion.runtime.CfJspPage.GetComponentMetaData(CfJspPage.java:2667)
at coldfusion.runtime.TemplateProxy.getRuntimeComponentMetadata
(TemplateProxy.java:1756)
at coldfusion.runtime.TemplateProxy.getRuntimeMetadata
(TemplateProxy.java:1617)
at coldfusion.runtime.MetadataUtils.getMetaData(MetadataUtils.java:54)
at coldfusion.runtime.CfJspPage.GetMetaData(CfJspPage.java:2640)
at cfEventHandler2ecfc862260423$funcPOSTLOAD.runFunction
(C:\ColdFusion9\wwwroot\ybocv5\coldbox\system\orm\hibernate
\EventHandler.cfc:30)
This is a version of an app that has been running in production, and what makes me think this is just on my local version is the appearance of this in the stack trace:
at cfdump2ecfm471394032$funcRENDEROUTPUT.runFunction
(E:\cf9_updates_rc\cfusion\wwwroot\WEB-INF\cftags\dump.cfm:704)
...
at cfCollectionPanel2ecfm961210602.runPage
(C:\ColdFusion9\wwwroot\ybocv5\coldbox\system\includes
\panels\CollectionPanel.cfm:40)
We don't use cfdump in production; this looks like ColdBox is trying to display a complex object in a debugger panel and failing.
The only thing I found online so far was this thread in Google's transfer-dev group ... someone who saw a bunch of similar errors and thought maybe it was a CF9 bug. The only reply with any sort of solution was this one, suggesting a fix that seems to be Transfer-specific.
Does anyone know what might be causing these errors? It's not as important to me to fix them as it would be on a production app, but if I'm spamming my logs with these errors, it's hard to find legitimate errors when they do occur.
Update: I've been working with the CollectionPanel.cfm template to identify the root cause, and the exception is consistently thrown here:
<cfelseif isObject(varVal)>
<!--- this cfdump is the guilty party ... --->
<cfdump var="#varVal#" expand="false" top="2">
<cfelse>
I've tried wrapping the cfdump in a try-catch, but the exception is thrown anyway, always from that same line of code. This makes sense, I guess, given that these errors don't have any visible effect on the pages on which they occur.
It appears to not be caused from a <cfdump> instead from a GetMetaData() call.
Specifically when you get the meta data of a cfc, which extends another cfc which has been modified after the current has been compiled (and where GetMetaData has been run) where it needs to update the extends struct in the GetMetaData() return. Cf only generates the meta data struct once, most likely for performance reasons.
I think it might be a bug in cf...
Inside the TemplateProxyFactory.getTemplateFileHelper() it's calling runtime.resolveTemplatePath(compName + ".cfc") where compName is name.replace('.', '/')
All good and well until you use a mapping. If you straight out replace dots with slashes, you'll need to add a leading slash, just like they do in TemplateProxy.getMetaData()
Without the leading slash, resolveTemplatePath() returns null, which triggers the VFSFileFactory.getFileObject() call which tries to get a File object from the parent cfc name.
Before it even gets to the VFSFileFactory, it calls Util.getBaseTemplatePath() with the pageContext. Inside it gets the ServletContext from the pageContext and tries to call getServletPath() so that it can get its real path. Utils.getServletPath() tries to get the attribute "javax.servlet.include.servlet_path" which on my machine (and probably yours) doesn't exist and returns null.
You can check by calling this: isNull(getPageContext().getRequest().getRequest().getAttribute("javax.servlet.include.servlet_path")); - yes, there is supposed to be two .getRequest() calls in there.
So it seems Cf is trying to refresh it's extends struct in a cfc getMetaData() call when the extended file is modified and does it a different way then when it first generated the struct.
In you cf admin, what are you settings under Server Settings > Caching?
Trusted cache? Cache template in request? Component cache? Save class files? Cache web server paths?