Webservice returning CFC in a different directory

Morning all I've been tearing my hair out with this one: I have a complex application with lots of CFCs that we want to web-service. The CFCs are in a directory outside the webroot, with a mapping set up to it : call it /mycomponents/ I have a directory /ws/ under the webroot with it's own Application.cfm, where I've put the webservice interface CFCs If I put a "noddy" method into a webservice CFC, like: <cfcomponent displayname="myWebService">                          <cffunction name="sayHello" access="remote" returntype="string">                         <cfargument name="myName" type="string" required="true" />                         <cfreturn "Hello #arguments.myName#" />             </cffunction> </cfcomponent> Then I can view the wsdl and call the method, with no problems The trouble comes when I want to return one of the CFCs from the main application, under /mycomponents/ <cfcomponent displayname="myWebService">                          <cffunction name="getPersonByID" access="remote" returntype="mycomponents.person">                         <cfargument name="intPersonID" type="numeric" required="true" />                         <cfscript>                                     objPerson = CreateObject( "component", "mycomponents/person" );                                     objPerson.init();                                     objReturnPerson = objPerson.getPersonByID( arguments.intPersonID ); </cfscript> <cfreturn objReturnPerson />             </cffunction> </cfcomponent> I get an Axis fault : coldfusion.xml.rpc.SkeletonClassLoader$UnresolvedCFCDataTypeException : Could not resolve CFC datatype mycomponents.person I've tried many different ways of referring to mycomponents/person.cfc in the returntype, none of them work. There's a macromedia technote describing a similar fault to this, when instantiating components as local variables in webservice CFCs, the workaround is to put a mapping into jrun-web.xml I've tried that, and it doesn't work for me. If I copy the person.cfc into the same directory as the webservice CFC, it works OK, but I don't want to have to put the webservice CFCs in the same directory as the back-end CFCs, for various reasons that I won't bore you with. I've spent about two hours googling looking for a solution, and all I can find is people having the same problem. No-one seems to have found a fix. So has anyone got any ideas that they'd like to share? Thanks, Alistair Davidson Senior Technical Developer Headshift.com ------------------------------------------ HEADSHIFT >>  www.headshift.com <BLOCKED::http://www.headshift.com/>; T: 020 7357 7358   ------------------------------------------ smarter  >  simpler  >  social  >

Do you have a CF Mapping setup pointing to mycomponents/ ? Then you can access the component in the ws by calling something like var oFoo = CreateObject("Component", "mycompents.mycfc"); HTH Mike Morning all I've been tearing my hair out with this one: I have a complex application with lots of CFCs that we want to web-service. The CFCs are in a directory outside the webroot, with a mapping set up to it : call it /mycomponents/ I have a directory /ws/ under the webroot with it's own Application.cfm, where I've put the webservice interface CFCs

Hi Mike, Yes, I have a mapping set up to mycomponents. I can create an instance of the CFC in the web service method, no problem. If I do: <cfcomponent displayname="Person Web Service Component">                                      <cffunction name="viewPerson" returntype="string" access="remote">                         <cfargument name="intItemID" type="numeric" required="true" />                         <cfscript>                                     objPerson = CreateObject( "component", "mycomponents/person" );                                     objPerson.init();                                                                          objPerson = objPerson.viewPersonByID( arguments.intItemID );                                                                          //return objPerson;                         </cfscript>                         <cfreturn "personid #arguments.intItemID#" />             </cffunction> </cfcomponent> Then it works fine, no errors, and returns the string. But if I uncomment the return objPerson line and change the returntype to mycomponents.person, or mycomponents/person, or /mycomponents/person, or anything similar, I get the the "UnresolvedCFCDatatype" exception. --------------------------------- Do you have a CF Mapping setup pointing to mycomponents/ ? Then you can access the component in the ws by calling something like var oFoo = CreateObject("Component", "mycompents.mycfc"); HTH Mike

I *beleive* although I havnt tested this that the return type would be person and not myCompnents.Person HTH Mike But if I uncomment the return objPerson line and change the returntype to mycomponents.person, or mycomponents/person, or /mycomponents/person, or anything similar, I get the the "UnresolvedCFCDatatype" exception.

Have you tried moving the CFCs into the web root? I know you said you have a /ws directory with interface CFCs, but I *think* the other CFCs need to be in the web root as well. There have been numerous web services posts to this and the CFCDev list in the past, and I believe the solution has been that all CFCs for web services need to be under the web root. Regards, Dave. ----- Excess quoted text cut - see Original Post for more -----

I've tried it - it doesn't work :-) I've tried person, mycomponents.person, mycomponents/person, /mycomponents/person, none of them work   _____ Sent: 12 July 2004 12:35 To: CF-Talk Subject: Re: Webservice returning CFC in a different directory I *beleive* although I havnt tested this that the return type would be person and not myCompnents.Person HTH Mike But if I uncomment the return objPerson line and change the returntype to mycomponents.person, or mycomponents/person, or /mycomponents/person, or anything similar, I get the the "UnresolvedCFCDatatype" exception.   _____  

Yeah, it looks like the bottom line is that the webservice CFCs HAVE to be in the same directory as any other CFCs they call. Which effectively means that all your back-end CFCs have to be under the webroot. Is it just me, or does that make anyone else feel a little bit uneasy? Seems like a nasty kludge to me - fingers crossed for Blackstone....

I beleive thats only to do with CFCs that return CFC components... I dont have the code to hand at the moment but im sure one of my sites proxy's, but it just returns a structure to flash rather than an instance of a CFC HTH Yeah, it looks like the bottom line is that the webservice CFCs HAVE to be in the same directory as any other CFCs they call. Which effectively means that all your back-end CFCs have to be under the webroot. Is it just me, or does that make anyone else feel a little bit uneasy?

----- Excess quoted text cut - see Original Post for more ----- I've never been a huge fan of that myself. However, that being said, maybe you're not out of luck just yet. I did a quick search and found this archived thread on CFCDev that might help you get to where you want to be without having to move your CFCs around: http://www.mail-archive.com/cfcdev@cfczone.org/msg04805.html Hope this helps? Regards, Dave.

But that fix also exposes all of your CFCs to the outside world correct? Just because you don't have to move them into the physical webroot doesn't make me feel much more secure if all CFCs are in a virtual directory. John ----- Excess quoted text cut - see Original Post for more ----- I've never been a huge fan of that myself. However, that being said, maybe you're not out of luck just yet. I did a quick search and found this archived thread on CFCDev that might help you get to where you want to be without having to move your CFCs around: http://www.mail-archive.com/cfcdev@cfczone.org/msg04805.html Hope this helps? Regards, Dave.

> But that fix also exposes all of your CFCs to the outside world correct? > Just because you don't have to move them into the physical webroot > doesn't make me feel much more secure if all CFCs are in a virtual > directory. I was just noting that you don't have to change your directory structure and refactor code just to implement web services. Why should he have to move all of his CFCs from outside the web root to under the web root just to work with them? Regards, Dave.

Yes, it works if I set the returntype as "struct" rather than a specific CFC type. The trouble then is that the struct comes out in the WSDL as a "Map" type, and I've had all sorts of trouble getting the Map type parsed correctly from a client written in anything other than CF - which kind of goes against the whole point of webservices... (sigh) like I said, fingers crossed for blackstone... Thanks for your help anyway though   _____ Sent: 12 July 2004 15:59 To: CF-Talk Subject: Re: Webservice returning CFC in a different directory I beleive thats only to do with CFCs that return CFC components... I dont have the code to hand at the moment but im sure one of my sites proxy's, but it just returns a structure to flash rather than an instance of a CFC HTH Yeah, it looks like the bottom line is that the webservice CFCs HAVE to be in the same directory as any other CFCs they call. Which effectively means that all your back-end CFCs have to be under the webroot. Is it just me, or does that make anyone else feel a little bit uneasy?   _____  

>found >this archived thread on CFCDev that might help you get to where you >want to be without having to move your CFCs around: >http://www.mail-archive.com/cfcdev@cfczone.org/msg04805.html Thanks Dave, but I've already tried that, and I just can't get it to resolve the component. Maybe it's because I'm on MX 6.1 Professional, rather than Enterprise....? I dunno... I'm on the verge of giving up

Have you tried moving the CFCs into the web root? I know you said you have a /ws directory with interface CFCs, but I *think* the other CFCs need to be in the web root as well. There have been numerous web services posts to this and the CFCDev list in the past, and I believe the solution has been that all CFCs for web services need to be under the web root. Regards, Dave. ----- Excess quoted text cut - see Original Post for more -----

In desperation, I've now set up an IIS (...ick...) virtual directory pointing to the directory with all my cfcs in, and lumped the interface cfcs in with the back-end cfcs in the same directory, along with my web service Application.cfm. (ugh.....makes my skin feel creepy...). It now works.....more or less.....some of the time..... It seems to randomly fail, giving me errors like "cannot resolve CFC datatype" for components that have not been changed, the good old "cannot generate stub objects" error, and a whole host of other axis errors that I'm not even going to bother to list - NOTE: if I restart the server, it works at first, for about 10 minutes, then suddenly stops working for no apparent reason. Oh yes, and if I type in the wsdl address, sometimes I get valid wsdl, sometimes I get nothing but a blank browser screen, sometimes I get an axis error, sometimes I get what looks like valid wsdl but when I try my test client to actually invoke the webservice, it tells me that the wsdl cannot be parsed. Sometimes this happens after I add a totally innocuous line into my web service CFC (like a comment! Yes, adding a comment can break it!), sometimes it starts failing without me changing anything. If anyone can come out with a "I've done this and it worked first time, and I've never had any problems with it..." I'll be eternally grateful if they can walk me through it. Otherwise, I'm giving up - this is way too much of a headache. Thanks for your help guys. Alistair

----- Excess quoted text cut - see Original Post for more ----- Can't say that I have, honestly, but a thought does come to mind. Have you tried downing your instance and blowing away the contents of both your cfclasses and cfc-skeletons directories (cfc-skeletons only gets used if you're using CFCs with web services)? It sounds like there's some caching going on that is hanging you up a bit. Also, I would disable the option in the MX Administrator to save generated class files (in the Caching section). Several Macromedians have posted recently that this may actually boost performance for sites with large numbers of classes because MX doesn't have to traverse the cfclasses directory looking for an already-generated class file. Hope this helps? Regards, Dave.

*       Have you tried downing your instance and blowing away the contents of both your cfclasses and cfc-skeletons directories..... Yup - tried it many times, no luck...

I know this post is over 8 years old, but it is the only one that was "on point" to a problem I was having.  I now have a solution so am simply updating this in case others stumble upon the same situation. I'm on Coldfusion 9. My set up is exactly like the original poster's:  webservices in a directory under the webroot, components in a directory outside the webroot of the current app. I was getting the same as errors described above. What I discovered - after much hair pulling! - was that I had carefully (I thought) sculpted a extremely limited subset of the main application.cfc (being overly cautious perhaps) and placed it in the web services directory.  In CFAdmin, the order for reading application.cfcs was set to "default order".   Accordingly it was reading the application.cfc in the web services directory. I also put all my mappings in the application.cfc (vs. manage them in the CFAdminstrator). Well, in my vast wisdom, I discovered that I had excised the mapping to the components directory in the web services version of application.cfc.  Once I added that back in, I was in heaven.  The components lived outside the app and functioned beautifully with the CFCs in the web services directory. Hope this helps the next soul that stumbles upon this problem. >*       Have >you tried downing your instance and blowing away the contents of both >your cfclasses and cfc-skeletons directories..... > > > >Yup - tried it many times, no luck...