Janise, are you on Java 7 or Java 6? I found Java 6 made my issues far
less problematic but it still happens at least 50% of the time when I start
up my app. I just made some changes to this recently actually, here's what
I have right now:
<cffunction name="search" hint="Searches the xml via an xpath"
access="public" returntype="array" output="false">
<cfargument name="xpath" hint="The xpath to search under" type="string"
required="Yes">
<cfscript>
var results = ArrayNew(1);
var res = arrayNew(1);
var len = arrayLen(getXMLCollection());
var counter = 1;
var collection = getXMLCollection();
var path = "";
var p = "";
for(; counter lte len; counter = counter + 1)
{
try
{
results.addAll(xmlSearch(collection[counter],
arguments.xpath));
}
catch (any ex)
{
// ok, let's serialize the XML as it exists so we can
capture it
writeLog(type="Error", file="transfer-xml", text="Failed to
XMLSearch(#arguments.xpath#) in XMLFileReader.cfc due to: [#ex.type#]
#ex.message#, check transfer-xml.serialized for a string representation of
the XML file");
writeLog(type="Error", file="transfer-xml-serialized", text
= toString(collection[counter]));
// flush the XML and try again
path = listToArray(getPathList());
setXMLCollection(arrayNew(1));
setPathList("");
for (p in path)
{
writeLog(type="Error", file="transfer-xml",
text="Readding XML: #p#...");
addXML(p, true);
}
// get updated collection
collection = getXMLCollection();
// run search again, it SHOULD be there this time
res = (isArray(collection) AND arrayLen(collection) ?
xmlSearch(collection[1], arguments.xpath) : 0);
writeLog(type="Error", file="transfer-xml", text="Reloaded
#arrayLen(path)# files, tried again against #arrayLen(collection)# files,
found #arrayLen(res)# matches.");
// now re-search the XML
results.addAll(res);
}
}
return results;
</cfscript>
</cffunction>
Mostly logging, but critically, the addXML(p, true), the true overwrites
what was there before, which clears out the broken ones.
I've got a guy who has offered to build a facade for CF ORM that presents
the same interface as Transfer. It has been a back burner project for me
but if someone else wanted to split the cost, I could prioritize it. Goal
would be to provide a drop-in replacement that would use CF ORM under the
hood but not require any code changes. I presume some configuration change
may be required but the getIsPersisted(), the relationships, etc... could
all implement the same interface.
Brian
On Monday, March 31, 2014 12:13:10 PM UTC-7, Janise Daylin wrote:
>
> I am a year late - but running into a similar issue. Went from CF8 with
> Transfer to CF10 with Transfer until I can get time to redesign. Getting
> "requested object could not be found in the config file" (when it exists)
> or "unable to process the result of the XMLSearch". If I refresh the page
> 2-12 times the errors disappear. I tried the try/catch in XMLFileReader
> but that didn't resolve the errors. I have a ticket open with Adobe but
> would love insight from anyone else that's resolved the issue or might give
> me some hints on where to look to resolve it.
>
> Janise
>
> On Wednesday, April 3, 2013 7:05:27 PM UTC-6, Brian G wrote:
>>
>>
>> That is where I'm doing it - but I wanted to test in prod that reloading
>> the XML did indeed fix the problem, and it did.
>>
>> Here's what I wound up with in XMLFileReader.cfc:
>>
>> try
>> {
>> results.addAll(xmlSearch(collection[counter], arguments.xpath));
>> }
>> catch (any ex)
>> {
>> // flush the XML and try again
>> setXMLCollection(arrayNew(1));
>> path = listToArray(getPathList());
>>
>> for (p in path)
>> {
>> addXML(p);
>> }
>>
>> writeLog(type="Error", file="transfer-xml", text="Failed to
>> XmlSearch(#arguments.xpath#) in XMLFileReader.cfc, reloaded
>> #arrayLen(path)# XML Files, trying again against
>> #arrayLen(getXMLCollection())# loaded configurations... [#ex.type#]
>> #ex.message#");
>>
>> // now re-search the XML
>> results.addAll(xmlSearch(collection[counter], arguments.xpath));
>> }
>>
>> I think that will do the trick for this particular issue. I mean, it
>> will work around whatever is really going on, at least for now. Fingers
>> crossed.
>>
>>
>> On Wednesday, April 3, 2013 2:32:13 PM UTC-7, Mark Mandel wrote:
>>>
>>> Why not do the try catch in here:
>>>
>>> http://transfer.riaforge.org/index.cfm?event=page.svnview&path=%2Ftransfer%2Ftrunk%2Fcom%2Fio&file=XMLFileReader%2Ecfc
>>>
>>> LIne 42 of the search?
>>>
>>> Rather than outside?
>>>
>>> Mark
>>>
>>>
>>> On Thu, Apr 4, 2013 at 3:30 AM, Brian G <[email protected]> wrote:
>>>
>>>>
>>>> On Tuesday, April 2, 2013 8:47:51 PM UTC-7, Mark Mandel wrote:
>>>>>
>>>>> Try/catch inside the XMLFileReader - if it overflows, then load up the
>>>>> path again. It knows where the XML file is, so it can always try it again.
>>>>> <http://www.2ddu.com/>
>>>>>
>>>>
>>>> That did it... on my wedged future production server, first I ran the
>>>> code that generated the stack overflow - still failed. Then I ran this:
>>>>
>>>>
>>>> <cfset orm = application.cs.getBean("ormService") />
>>>> <cfset xmlFileReader =
>>>> orm.getTransfer().getObjectManager().getObjectDAO().getConfigReader() />
>>>> <cfdump var="#arrayLen(xmlFileReader.getXMLCollection())#"
>>>> label="pre-reload, num of xml files" />
>>>> <cfset
>>>> xmlFileReader.addXML('/var/www/pukka/main-prod/config/transfer/transfer.xml',
>>>>
>>>> true) />
>>>> <cfdump var="#arrayLen(xmlFileReader.getXMLCollection())#"
>>>> label="post-reload, num of xml files" />
>>>>
>>>> Then I re-ran the borked code and actually it still failed. The
>>>> overwrite flag true here doesn't overwrite it only prepends to the array
>>>> of
>>>> XML files so the search still failed when it hit the original, somehow
>>>> jacked up, XML file. I manually killed it with
>>>> arrayDeleteAt(getXMLCollection(), 2) and then re-ran my error-generating
>>>> code and it worked fine.
>>>>
>>>> I'm not sure how to report this... clearly something is fubar'd and it
>>>> looks like a bug in CF but it's not reproducible in the traditional sense.
>>>>
>>>> For now, I'm going to wrap the xmlsearch with a try/catch and see if that
>>>> works?
>>>>
>>>> Thanks for the help Mark.
>>>>
>>>>
>>>> --
>>>> --
>>>> Before posting questions to the group please read:
>>>>
>>>> http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
>>>>
>>>> Try out the new Transfer ORM Custom Google Search:
>>>> http://www.google.com/cse/home?cx=002375903941309441958:2s7wbd5ocb8
>>>>
>>>> You received this message because you are subscribed to the Google
>>>> Groups "transfer-dev" group.
>>>> To post to this group, send email to [email protected]
>>>> To unsubscribe from this group, send email to
>>>> [email protected]
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/transfer-dev?hl=en
>>>>
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "transfer-dev" 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.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> E: [email protected]
>>> T: http://www.twitter.com/neurotic
>>> W: www.compoundtheory.com
>>>
>>> 2 Devs from Down Under Podcast
>>> http://www.2ddu.com/
>>>
>>
--
--
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
Try out the new Transfer ORM Custom Google Search:
http://www.google.com/cse/home?cx=002375903941309441958:2s7wbd5ocb8
You received this message because you are subscribed to the Google Groups
"transfer-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/transfer-dev?hl=en
---
You received this message because you are subscribed to the Google Groups
"transfer-dev" 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/d/optout.
