Migration CF10 To Lucee

dev google-group-archive
1

First, I’m surprised I could not find an actual guide to migrating codes
from CF to Lucee. I did find a few “notes” from people having done it but
nothing I can go through to search and convert problematic areas of my
codes, systematically. So any help with something like this would be very
appreciated.

The problem I’m trying to fix right now has to do with XmlSearch.
This is the code as it has been working for me in CF10 as well as CF11

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Here is a sample of a response xml file (with only id numbers manually
changed):

<?xml version="1.0" encoding="UTF-8"?> 00012345670439632119 created

When I test my XMLsearch code
at XPath Expression Testbed, it
does not work, just as it does not work on Lucee.
But on that site this works (I mean it extracts the proper label
link): string(/descendant::link[@rel = ‘label’]/@href)

So I changed my cf code above to:
<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(/descendant::link[@rel
= ‘label’]/@href))”),“_”,“-”,“all”)>
But still no luck, it keeps returning an empty string.

What am I missing. Is this a Lucee problem?
Thank you

2

To answer Tom, In this case, I’m trying to extract only the *href *of the
label. (notice there are other href in the same xml doc).
As suggested by Lutz, I tried adding changing ‘label’ for ““label”” without
luck.

Further info: What i’m actually doing is converting an Carweaver based
online store, presently hosted on cf10 server and using a MSSQL database,
to a Lucee hosted server using MySQL database.
Cartweaver was already pretty much compatatible with Lucee. The database
conversion also was relatively easy. Now I’m left with ironing out problems
with my own customization codes. In this case, it is the shipping module.
It makes extensive use of xmlsearch! And it is a long code! (with various
API connections for both UPS and Canada Post) So I need to not just fix
this particular one, but I need to understand what is going on so I can
find and correct the rest of this module.

What puzzles me is that CF gets the proper link using (//*:link[@rel =
‘label’]/@href) while neither Lucee nor the web site (online xmlsearch test
site) returns a link with that. This could be the “cf being forgiving”
factor. But the online test web site does return the proper link with
…//:link… (Just removing the *) and Lucee still returns empty with
everything! //link, //link and even with /descendant::link could the
problem be with the prefix string in <cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),"normalize-space(string(//:link[@rel
= ‘label’]/@href))“),”_“,”-",“all”)>On Wednesday, September 23, 2015 at 10:49:26 AM UTC-4, lu...@lesener.de wrote:

On Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with
““label”” ?

rgds
Lutz

3

First, I’m surprised I could not find an actual guide to migrating codes
from CF to Lucee. I did find a few “notes” from people having done it but
nothing I can go through to search and convert problematic areas of my
codes, systematically.

Having worked through a few migrations, I’m not surprised. The
incompatibilities I ran across were all fairly obscure. There are simply a
vast number of possibilities to get from point a to point b in code if you
include everything possible to do.

4

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with ““label””
?

rgds
LutzOn Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

5

What part are you trying to extract ? Just the href’s ? Try a simpler XPATH
expression.

TomOn Tuesday, September 22, 2015 at 5:26:32 PM UTC+1, Dominique Dupuis wrote:

First, I’m surprised I could not find an actual guide to migrating codes
from CF to Lucee. I did find a few “notes” from people having done it but
nothing I can go through to search and convert problematic areas of my
codes, systematically. So any help with something like this would be very
appreciated.

The problem I’m trying to fix right now has to do with XmlSearch.
This is the code as it has been working for me in CF10 as well as CF11

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Here is a sample of a response xml file (with only id numbers manually
changed):

<?xml version="1.0" encoding="UTF-8"?> 00012345670439632119 created

When I test my XMLsearch code at
XPath Expression Testbed, it
does not work, just as it does not work on Lucee.
But on that site this works (I mean it extracts the proper label
link): string(/descendant::link[@rel = ‘label’]/@href)

So I changed my cf code above to:
<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(/descendant::link[@rel
= ‘label’]/@href))”),“_”,“-”,“all”)>
But still no luck, it keeps returning an empty string.

What am I missing. Is this a Lucee problem?
Thank you

6

Hi Dominique,

Glad it worked for you.

I would guess it may be down to whatever XML parser is being used within
the Whitebeam Xpath Testbed. It works OK using these ones:
http://www.xpathtester.com/xpath

All the best,

MartinOn Thursday, September 24, 2015 at 4:50:05 PM UTC+1, Dominique Dupuis wrote:

Hi Martin,
You’re my new best friend!!
It works like a charm, almost everywhere, CF10, CF11 and Lucee. But it
does not work on the XPath Expression testbed site?!? This is not a big
deal, except for the fact that I still don’t know why it works so
differently (or not) from one place to the other.

For now, I will use your solution since it works in both target
environments. Now I’m still missing some understanding as to why it works.
I need just enough so I can track and fix potential problems in the many
more lines of codes that use XPath in this shipping module.
You say you use it to avoid having to deal with the namespaces prefixes,
but my limited understanding of XPath was that this was what (this wild
card) *: was suppose to do.

Thank you for your help!
Dominique

On Thursday, September 24, 2015 at 6:26:56 AM UTC-4, mar...@cubicstate.com wrote:

Hi Dominique,

I have just tried the following XPath against your XML and it looks to
work OK in Lucee 4.5.1.022:

normalize-space(string(//*[local-name()=‘link’][@rel=‘label’]/@href))

I have used local-name() in the pas to avoid having to deal with the
namespaces prefixes.

All the best,

Martin

On Wednesday, September 23, 2015 at 9:02:26 PM UTC+1, Dominique Dupuis wrote:

To answer Tom, In this case, I’m trying to extract only the *href *of
the label. (notice there are other href in the same xml doc).
As suggested by Lutz, I tried adding changing ‘label’ for ““label””
without luck.

Further info: What i’m actually doing is converting an Carweaver based
online store, presently hosted on cf10 server and using a MSSQL database,
to a Lucee hosted server using MySQL database.
Cartweaver was already pretty much compatatible with Lucee. The database
conversion also was relatively easy. Now I’m left with ironing out problems
with my own customization codes. In this case, it is the shipping module.
It makes extensive use of xmlsearch! And it is a long code! (with
various API connections for both UPS and Canada Post) So I need to not
just fix this particular one, but I need to understand what is going on so
I can find and correct the rest of this module.

What puzzles me is that CF gets the proper link using (//*:link[@rel =
‘label’]/@href) while neither Lucee nor the web site (online xmlsearch test
site) returns a link with that. This could be the “cf being forgiving”
factor. But the online test web site does return the proper link with
…//:link… (Just removing the *) and Lucee still returns empty with
everything! //link, //link and even with /descendant::link could the
problem be with the prefix string in <cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),"normalize-space(string(//:link[@rel
= ‘label’]/@href))“),”_“,”-",“all”)>

On Wednesday, September 23, 2015 at 10:49:26 AM UTC-4, lu...@lesener.de wrote:

On Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with
““label”” ?

rgds
Lutz

7

Hi Martin,
You’re my new best friend!!
It works like a charm, almost everywhere, CF10, CF11 and Lucee. But it
does not work on the XPath Expression testbed site?!? This is not a big
deal, except for the fact that I still don’t know why it works so
differently (or not) from one place to the other.

For now, I will use your solution since it works in both target
environments. Now I’m still missing some understanding as to why it works.
I need just enough so I can track and fix potential problems in the many
more lines of codes that use XPath in this shipping module.
You say you use it to avoid having to deal with the namespaces prefixes,
but my limited understanding of XPath was that this was what (this wild
card) *: was suppose to do.

Thank you for your help!
DominiqueOn Thursday, September 24, 2015 at 6:26:56 AM UTC-4, mar...@cubicstate.com wrote:

Hi Dominique,

I have just tried the following XPath against your XML and it looks to
work OK in Lucee 4.5.1.022:

normalize-space(string(//*[local-name()=‘link’][@rel=‘label’]/@href))

I have used local-name() in the pas to avoid having to deal with the
namespaces prefixes.

All the best,

Martin

On Wednesday, September 23, 2015 at 9:02:26 PM UTC+1, Dominique Dupuis wrote:

To answer Tom, In this case, I’m trying to extract only the *href *of
the label. (notice there are other href in the same xml doc).
As suggested by Lutz, I tried adding changing ‘label’ for ““label””
without luck.

Further info: What i’m actually doing is converting an Carweaver based
online store, presently hosted on cf10 server and using a MSSQL database,
to a Lucee hosted server using MySQL database.
Cartweaver was already pretty much compatatible with Lucee. The database
conversion also was relatively easy. Now I’m left with ironing out problems
with my own customization codes. In this case, it is the shipping module.
It makes extensive use of xmlsearch! And it is a long code! (with various
API connections for both UPS and Canada Post) So I need to not just fix
this particular one, but I need to understand what is going on so I can
find and correct the rest of this module.

What puzzles me is that CF gets the proper link using (//*:link[@rel =
‘label’]/@href) while neither Lucee nor the web site (online xmlsearch test
site) returns a link with that. This could be the “cf being forgiving”
factor. But the online test web site does return the proper link with
…//:link… (Just removing the *) and Lucee still returns empty with
everything! //link, //link and even with /descendant::link could the
problem be with the prefix string in <cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),"normalize-space(string(//:link[@rel
= ‘label’]/@href))“),”_“,”-",“all”)>

On Wednesday, September 23, 2015 at 10:49:26 AM UTC-4, lu...@lesener.de wrote:

On Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with
““label”” ?

rgds
Lutz

8

Hi Dominique,

I have just tried the following XPath against your XML and it looks to work
OK in Lucee 4.5.1.022:

normalize-space(string(//*[local-name()=‘link’][@rel=‘label’]/@href))

I have used local-name() in the pas to avoid having to deal with the
namespaces prefixes.

All the best,

MartinOn Wednesday, September 23, 2015 at 9:02:26 PM UTC+1, Dominique Dupuis wrote:

To answer Tom, In this case, I’m trying to extract only the *href *of the
label. (notice there are other href in the same xml doc).
As suggested by Lutz, I tried adding changing ‘label’ for ““label””
without luck.

Further info: What i’m actually doing is converting an Carweaver based
online store, presently hosted on cf10 server and using a MSSQL database,
to a Lucee hosted server using MySQL database.
Cartweaver was already pretty much compatatible with Lucee. The database
conversion also was relatively easy. Now I’m left with ironing out problems
with my own customization codes. In this case, it is the shipping module.
It makes extensive use of xmlsearch! And it is a long code! (with various
API connections for both UPS and Canada Post) So I need to not just fix
this particular one, but I need to understand what is going on so I can
find and correct the rest of this module.

What puzzles me is that CF gets the proper link using (//*:link[@rel =
‘label’]/@href) while neither Lucee nor the web site (online xmlsearch test
site) returns a link with that. This could be the “cf being forgiving”
factor. But the online test web site does return the proper link with
…//:link… (Just removing the *) and Lucee still returns empty with
everything! //link, //link and even with /descendant::link could the
problem be with the prefix string in <cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),"normalize-space(string(//:link[@rel
= ‘label’]/@href))“),”_“,”-",“all”)>

On Wednesday, September 23, 2015 at 10:49:26 AM UTC-4, lu...@lesener.de wrote:

On Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with
““label”” ?

rgds
Lutz

9

Good, I can use these for further testing.

Moving on to next migration problem… I was testing this particular line
of code, that retreives the url of the actual label because I was told both
that Lucee handles PDF raw and that it did not handle it…
So I needed to fiind out if this was an issue:
A dump of the respond from Canada post API (cfhttp.FileContent) looks like
this (but shorten quite a lot):
Native Array (byte[])Raw[60,63,120,115,99,1(…lots more
numbers…)15,97,103,101,115,62]
Base64 EncodedPD94(…lots more
whatever…)wIiBl]

On CF10-11 I used this: to show my shipping label so I can print
it.

On Lucee, this results in the browser telling me that “This PDF doc might
not be displayed correctly”… and it does not display at all. The browser
offers to try opening it with different viewers but the result is the same
when I do. They don’t read it as being a pdf file. This tells me either
Lucee can’t use pdf as type for the tag cfcontent, or the conversion of raw
fails. The wed site: <cfcontent> :: Lucee Documentation
does not even specify any accepted type! So I’m left in the dark as to
what is wrong.
Thank you
DominiqueOn Thursday, September 24, 2015 at 12:08:37 PM UTC-4, mar...@cubicstate.com wrote:

Hi Dominique,

Glad it worked for you.

I would guess it may be down to whatever XML parser is being used within
the Whitebeam Xpath Testbed. It works OK using these ones:
http://www.xpathtester.com/xpath
XPath Tester and Evaluator online
http://www.utilities-online.info/xpath

All the best,

Martin

On Thursday, September 24, 2015 at 4:50:05 PM UTC+1, Dominique Dupuis wrote:

Hi Martin,
You’re my new best friend!!
It works like a charm, almost everywhere, CF10, CF11 and Lucee. But it
does not work on the XPath Expression testbed site?!? This is not a big
deal, except for the fact that I still don’t know why it works so
differently (or not) from one place to the other.

For now, I will use your solution since it works in both target
environments. Now I’m still missing some understanding as to why it works.
I need just enough so I can track and fix potential problems in the many
more lines of codes that use XPath in this shipping module.
You say you use it to avoid having to deal with the namespaces prefixes,
but my limited understanding of XPath was that this was what (this wild
card) *: was suppose to do.

Thank you for your help!
Dominique

On Thursday, September 24, 2015 at 6:26:56 AM UTC-4, mar...@cubicstate.com wrote:

Hi Dominique,

I have just tried the following XPath against your XML and it looks to
work OK in Lucee 4.5.1.022:

normalize-space(string(//*[local-name()=‘link’][@rel=‘label’]/@href))

I have used local-name() in the pas to avoid having to deal with the
namespaces prefixes.

All the best,

Martin

On Wednesday, September 23, 2015 at 9:02:26 PM UTC+1, Dominique Dupuis wrote:

To answer Tom, In this case, I’m trying to extract only the *href *of
the label. (notice there are other href in the same xml doc).
As suggested by Lutz, I tried adding changing ‘label’ for ““label””
without luck.

Further info: What i’m actually doing is converting an Carweaver based
online store, presently hosted on cf10 server and using a MSSQL database,
to a Lucee hosted server using MySQL database.
Cartweaver was already pretty much compatatible with Lucee. The
database conversion also was relatively easy. Now I’m left with ironing out
problems with my own customization codes. In this case, it is the shipping
module.
It makes extensive use of xmlsearch! And it is a long code! (with
various API connections for both UPS and Canada Post) So I need to not
just fix this particular one, but I need to understand what is going on so
I can find and correct the rest of this module.

What puzzles me is that CF gets the proper link using (//*:link[@rel =
‘label’]/@href) while neither Lucee nor the web site (online xmlsearch test
site) returns a link with that. This could be the “cf being forgiving”
factor. But the online test web site does return the proper link with
…//:link… (Just removing the *) and Lucee still returns empty with
everything! //link, //link and even with /descendant::link could the
problem be with the prefix string in <cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),"normalize-space(string(//:link[@rel
= ‘label’]/@href))“),”_“,”-",“all”)>

On Wednesday, September 23, 2015 at 10:49:26 AM UTC-4, lu...@lesener.de wrote:

On Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with
““label”” ?

rgds
Lutz

10

To keep things separate, I’ve mark a star on the posted solution
that worked, and created a new topic for the next problem I was facing.
(the Binary pdf problem). DominiqueOn Thursday, September 24, 2015 at 1:21:49 PM UTC-4, Dominique Dupuis wrote:

Good, I can use these for further testing.

Moving on to next migration problem… I was testing this particular line
of code, that retreives the url of the actual label because I was told both
that Lucee handles PDF raw and that it did not handle it…
So I needed to fiind out if this was an issue:
A dump of the respond from Canada post API (cfhttp.FileContent) looks like
this (but shorten quite a lot):
Native Array (byte[])Raw[60,63,120,115,99,1(…lots more
numbers…)15,97,103,101,115,62]
Base64 EncodedPD94(…lots more
whatever…)wIiBl]

On CF10-11 I used this: to show my shipping label so I can print
it.

On Lucee, this results in the browser telling me that “This PDF doc might
not be displayed correctly”… and it does not display at all. The browser
offers to try opening it with different viewers but the result is the same
when I do. They don’t read it as being a pdf file. This tells me either
Lucee can’t use pdf as type for the tag cfcontent, or the conversion of raw
fails. The wed site: <cfcontent> :: Lucee Documentation
does not even specify any accepted type! So I’m left in the dark as to
what is wrong.
Thank you
Dominique

On Thursday, September 24, 2015 at 12:08:37 PM UTC-4, mar...@cubicstate.com wrote:

Hi Dominique,

Glad it worked for you.

I would guess it may be down to whatever XML parser is being used within
the Whitebeam Xpath Testbed. It works OK using these ones:
http://www.xpathtester.com/xpath
XPath Tester and Evaluator online
http://www.utilities-online.info/xpath

All the best,

Martin

On Thursday, September 24, 2015 at 4:50:05 PM UTC+1, Dominique Dupuis wrote:

Hi Martin,
You’re my new best friend!!
It works like a charm, almost everywhere, CF10, CF11 and Lucee. But it
does not work on the XPath Expression testbed site?!? This is not a big
deal, except for the fact that I still don’t know why it works so
differently (or not) from one place to the other.

For now, I will use your solution since it works in both target
environments. Now I’m still missing some understanding as to why it works.
I need just enough so I can track and fix potential problems in the many
more lines of codes that use XPath in this shipping module.
You say you use it to avoid having to deal with the namespaces prefixes,
but my limited understanding of XPath was that this was what (this wild
card) *: was suppose to do.

Thank you for your help!
Dominique

On Thursday, September 24, 2015 at 6:26:56 AM UTC-4, mar...@cubicstate.com wrote:

Hi Dominique,

I have just tried the following XPath against your XML and it looks to
work OK in Lucee 4.5.1.022:

normalize-space(string(//*[local-name()=‘link’][@rel=‘label’]/@href))

I have used local-name() in the pas to avoid having to deal with the
namespaces prefixes.

All the best,

Martin

On Wednesday, September 23, 2015 at 9:02:26 PM UTC+1, Dominique Dupuis wrote:

To answer Tom, In this case, I’m trying to extract only the *href *of
the label. (notice there are other href in the same xml doc).
As suggested by Lutz, I tried adding changing ‘label’ for ““label””
without luck.

Further info: What i’m actually doing is converting an Carweaver based
online store, presently hosted on cf10 server and using a MSSQL database,
to a Lucee hosted server using MySQL database.
Cartweaver was already pretty much compatatible with Lucee. The
database conversion also was relatively easy. Now I’m left with ironing out
problems with my own customization codes. In this case, it is the shipping
module.
It makes extensive use of xmlsearch! And it is a long code! (with
various API connections for both UPS and Canada Post) So I need to not
just fix this particular one, but I need to understand what is going on so
I can find and correct the rest of this module.

What puzzles me is that CF gets the proper link using (//*:link[@rel =
‘label’]/@href) while neither Lucee nor the web site (online xmlsearch test
site) returns a link with that. This could be the “cf being forgiving”
factor. But the online test web site does return the proper link with
…//:link… (Just removing the *) and Lucee still returns empty with
everything! //link, //link and even with /descendant::link could the
problem be with the prefix string in <cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),"normalize-space(string(//:link[@rel
= ‘label’]/@href))“),”_“,”-",“all”)>

On Wednesday, September 23, 2015 at 10:49:26 AM UTC-4, lu...@lesener.de wrote:

On Tuesday, 22 September 2015 18:26:32 UTC+2, Dominique Dupuis wrote:

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Just a shot in the dark: What happens if you replace ‘label’ with
““label”” ?

rgds
Lutz

11

I have this regex code that used to work in CF10 but since moving to Lucee,
it no longer works. (The problem is not Lucee, it is the Regex, and Lucee
just seems to be less forgiving…)
The code is:
<cfset ThisNode =
#XMLSearch(xmlResponse,“//[local-name()=‘price_quotes’]/[local-name()=‘price_quote’]
[* = ‘#CanPost_ServiceRegion##xmldata.CanPost_service_code#’
]/count(preceding-sibling::) + 1")#>
The variable in the middle could be USA.SP.AIR for the purpuse of testing:
so
<cfset ThisNode =
#XMLSearch(xmlResponse,"//[local-name()=‘price_quotes’]/[local-name()=‘price_quote’]
[ = ‘USA.SP.AIR’ ]/count(preceding-sibling::*) + 1”)#>

The closes I get to something right is:
count(preceding-sibling:://[local-name()=‘price_quotes’]/[local-name()=‘price_quote’]
[* = ‘USA.SP.AIR’ ]) + 1
But it always returns 1, instead of the actual position +1…

Can someone point me in the right direction?

The test xml file could be:

<?xml version="1.0" encoding="UTF_8"?> http://www.canadapost.ca/ws/ship/rate_v2"><price_quote><service_code>USA.EP</service_code><service_link
rel=“service” href="
https://soa_gw.canadapost.ca:443/rs/ship/service/USA.EP?contract=
https://soa_gw.canadapost.ca/rs/ship/service/USA.EP?contract=0040024030&amp;country=US
004002000
https://soa_gw.canadapost.ca/rs/ship/service/USA.XP?contract=0040024030&amp;country=US&country=US"
media_type=“application/vnd.cpc.ship.rate_v2+xml”/><service_name>Expedited
Parcel
USA</service_name><price_details>19.400.000.000.0020.22<option_code>DC</option_code><option_name>Delivery
confirmation</option_name><option_price>0</option_price><adjustment_code>FUELSC</adjustment_code><adjustment_name>Fuel
surcharge</adjustment_name><adjustment_cost>0.82</adjustment_cost>4.25</price_details><weight_details/><service_standard><am_delivery>false</am_delivery><guaranteed_delivery>false</guaranteed_delivery><expected_transit_time>4</expected_transit_time><expected_delivery_date>2015_11_19</expected_delivery_date></service_standard></price_quote><price_quote><service_code>USA.PW.PAK</service_code><service_link
rel=“service” href="
https://soa_gw.canadapost.ca:443/rs/ship/service/USA.PW.PAK?contract=
https://soa_gw.canadapost.ca/rs/ship/service/USA.PW.PAK?contract=0040024030&amp;country=US
004002000
https://soa_gw.canadapost.ca/rs/ship/service/USA.XP?contract=0040024030&amp;country=US&country=US"
media_type=“application/vnd.cpc.ship.rate_v2+xml”/><service_name>Priority
Worldwide pak
USA</service_name><price_details>63.320.000.000.0065.06<option_code>DC</option_code><option_name>Delivery
confirmation</option_name><option_price>0</option_price><option_code>SO</option_code><option_name>Signature
option</option_name><option_price>0</option_price><adjustment_code>FUELSC</adjustment_code><adjustment_name>Fuel
surcharge</adjustment_name><adjustment_cost>1.74</adjustment_cost>2.75</price_details><weight_details/><service_standard><am_delivery>false</am_delivery><guaranteed_delivery>false</guaranteed_delivery></service_standard></price_quote><price_quote><service_code>USA.PW.PARCEL</service_code><service_link
rel=“service” href="
https://soa_gw.canadapost.ca:443/rs/ship/service/USA.PW.PARCEL?contract=
https://soa_gw.canadapost.ca/rs/ship/service/USA.PW.PARCEL?contract=0040024030&amp;country=US
004002000
https://soa_gw.canadapost.ca/rs/ship/service/USA.XP?contract=0040024030&amp;country=US&country=US"
media_type=“application/vnd.cpc.ship.rate_v2+xml”/><service_name>Priority
Worldwide parcel
USA</service_name><price_details>70.300.000.000.0072.23<option_code>DC</option_code><option_name>Delivery
confirmation</option_name><option_price>0</option_price><option_code>SO</option_code><option_name>Signature
option</option_name><option_price>0</option_price><adjustment_code>FUELSC</adjustment_code><adjustment_name>Fuel
surcharge</adjustment_name><adjustment_cost>1.93</adjustment_cost>2.75</price_details><weight_details/><service_standard><am_delivery>false</am_delivery><guaranteed_delivery>false</guaranteed_delivery></service_standard></price_quote><price_quote><service_code>USA.SP.AIR</service_code><service_link
rel=“service” href="
https://soa_gw.canadapost.ca:443/rs/ship/service/USA.SP.AIR?contract=
https://soa_gw.canadapost.ca/rs/ship/service/USA.SP.AIR?contract=0040024030&amp;country=US
004002000
https://soa_gw.canadapost.ca/rs/ship/service/USA.XP?contract=0040024030&amp;country=US
&country=US
https://soa_gw.canadapost.ca/rs/ship/service/USA.SP.AIR?contract=0040024030&amp;country=US"
media_type=“application/vnd.cpc.ship.rate_v2+xml”/><service_name>Small
Packet USA
Air</service_name><price_details>16.230.000.000.0016.23</price_details><weight_details/><service_standard><am_delivery>false</am_delivery><guaranteed_delivery>false</guaranteed_delivery></service_standard></price_quote><price_quote><service_code>
USA.TP http://usa.tp/</service_code><service_link rel=“service” href="
https://soa_gw.canadapost.ca:443/rs/ship/service/USA.TP?contract=
https://soa_gw.canadapost.ca/rs/ship/service/USA.TP?contract=0040024030&amp;country=US
004002000
https://soa_gw.canadapost.ca/rs/ship/service/USA.XP?contract=0040024030&amp;country=US
&country=US
https://soa_gw.canadapost.ca/rs/ship/service/USA.TP?contract=0040024030&amp;country=US"
media_type=“application/vnd.cpc.ship.rate_v2+xml”/><service_name>Tracked
Packet _
USA</service_name><price_details>18.190.000.000.0018.96<option_code>DC</option_code><option_name>Delivery
confirmation</option_name><option_price>0</option_price><adjustment_code>FUELSC</adjustment_code><adjustment_name>Fuel
surcharge</adjustment_name><adjustment_cost>0.77</adjustment_cost>4.25</price_details><weight_details/><service_standard><am_delivery>false</am_delivery><guaranteed_delivery>false</guaranteed_delivery><expected_transit_time>6</expected_transit_time><expected_delivery_date>2015_11_23</expected_delivery_date></service_standard></price_quote><price_quote><service_code>USA.XP</service_code><service_link
rel=“service” href="
https://soa_gw.canadapost.ca:443/rs/ship/service/USA.XP?contract=004002000&country=US
https://soa_gw.canadapost.ca/rs/ship/service/USA.XP?contract=0040024030&amp;country=US"
media_type=“application/vnd.cpc.ship.rate_v2+xml”/><service_name>Xpresspost
USA</service_name><price_details>30.600.000.000.0033.43<option_code>DC</option_code><option_name>Delivery
confirmation</option_name><option_price>0</option_price><option_code>SO</option_code><option_name>Signature
option</option_name><option_price>0</option_price><adjustment_code>FUELSC</adjustment_code><adjustment_name>Fuel
surcharge</adjustment_name><adjustment_cost>2.83</adjustment_cost>9.25</price_details><weight_details/><service_standard><am_delivery>false</am_delivery><guaranteed_delivery>true</guaranteed_delivery><expected_transit_time>3</expected_transit_time><expected_delivery_date>2015_11_18</expected_delivery_date></service_standard></price_quote></price_quotes>On Tuesday, September 22, 2015 at 12:26:32 PM UTC-4, Dominique Dupuis wrote:

First, I’m surprised I could not find an actual guide to migrating codes
from CF to Lucee. I did find a few “notes” from people having done it but
nothing I can go through to search and convert problematic areas of my
codes, systematically. So any help with something like this would be very
appreciated.

The problem I’m trying to fix right now has to do with XmlSearch.
This is the code as it has been working for me in CF10 as well as CF11

<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(//*:link[@rel =
‘label’]/@href))”),“_”,“-”,“all”)>

Here is a sample of a response xml file (with only id numbers manually
changed):

<?xml version="1.0" encoding="UTF-8"?> 00012345670439632119 created

When I test my XMLsearch code at
XPath Expression Testbed, it
does not work, just as it does not work on Lucee.
But on that site this works (I mean it extracts the proper label
link): string(/descendant::link[@rel = ‘label’]/@href)

So I changed my cf code above to:
<cfset GetArtifactURL =
Replace(XmlSearch(Trim(xmlResponse),“normalize-space(string(/descendant::link[@rel
= ‘label’]/@href))”),“_”,“-”,“all”)>
But still no luck, it keeps returning an empty string.

What am I missing. Is this a Lucee problem?
Thank you