web-admin mappings and cfimport issues.

[Matt Casey]

I've recently installed an application for a customer on a shared server (to save money) but am running into a mapping/cfimport problem that I've not seen before.

I have the mappings defined in the web-admin but whenever I try to <cfimport> a custom tag library I get the following error.

"invalid definition of the attribute taglib [{blahblah}]"
With {blahblah} being the name of the custom tag folder I want to import.

This is on a shared server where I only have access to the Lucee web-admin.
I do not have access to the Lucee server-admin.

The server is running;
Lucee: 5.1.0.34
OS: Linux (3.10.0-327.18.2.el7.centos.plus.x86_64) 64bit
Servlet Container: Apache Tomcat/8.5.6
Java: 1.8.0_112 (Oracle Corporation) 64bit

I've been working the the hosting provider support to try and resolve the issue but I'm not getting anywhere and feel like I have my hands tied.

I built a very simple test to highlight the issue.

The mapping is defined in the web-admin as;
<mapping inspect-template="once" physical="{web-root-directory}/test/tags/" primary="physical" readonly="false" toplevel="true" virtual="/newtestmapping"/>

There is a very basic custom tag in the webroot /test/tags/ folder.

Then in a test.cfm I try to import the library using;
<cfimport taglib="/newtestmapping/" prefix="test" />

It fails with the error;
"invalid definition of the attribute taglib [/newtestmapping/]""

Using expandpath() I can see that the mapping is resolving to the correct path.
{Redacted...}/httpdocs/test/tags/

I've been using this method succcessfully for years across CF, Railo and now Lucee without ever having to give it much thought. I have the exact same application running live in two other Lucee environments and have tested the code using various setups with commandbox https://www.ortussolutions.com/products/commandbox and it all works as expected.

I'm completely stumped.

Could it be a permissions issue?
Or is there a difference between mappings defined in the web-admin compared to those defined in the server-admin.
Has anyone else had similar experience?

[Richard Herbert]

Yep, I've just had the self same thing when my shared hosting provider moved my site to a Lucee 5.1 server over the weekend (not my decision/choice).

All works fine under macOS 10.12.2 and CommandBox 3.4 / Lucee 5.1.0.34 but I get the same error on their server which is using Linux (2.6.32-642.13.1.el6.x86_64) 64bit.

I don't have a mapping as my folder is located under the webroot so I think mappings is not the issue.

In a frantic attempt to debug the issue I removed the leading "/" and got a more predictable error of "could not find template [myTemplateName.[cfc|lucee|cfm|lucee]] in the following directories [myCustomTageFolder]".

So it seems like some issue supporting the "/" prefix????

[Matt Casey]

Hi Richard.

Glad to know that I'm not the only one having this issue.

Removing the leading "/" means that you are asking Lucee to import a tag library in a folder relative to the one the import is in.

Funny thing is that Lucee doesn't seem to care too much about the taglib path when using relative paths. You can put in any folder path, even a non existent one and It doesn't throw an error until you try and use a tag from that collection.

eg.

<cfimport taglib="notanexistingfolder/" prefix="rubbish" />

Compiles fine, the error is thrown when you try and use <rubbish:tag />.

But when using an absolute path such as when importing a library from a mapping it seems that Lucee evaluates the taglib parameter before executing the rest of the template and throws this "invalid definition of the attribute taglib" error if it can't find the path.

I can prove that my mapping exists and can use it with expandpath(), directorylist() etc.

Very frustrating...

[Richard Herbert]

I've never used cfimport with a relative path before. The doc's say start with "/".

I did also experience the same issue with the non-existent path. How strange.

I don't think your issue is with the mapping. As you say it's valid. If you move your tags into a folder located in your webroot and reference it as "/myTagFolder" it'll still fail.

Anyway, I've found a workaround for my situation which may work for you...

Rather that cfimport-ing your tags, add the path to your tags to the list of customtagpaths and then do a search and replace across your code base replacing "myTagPrefix:" with "cf_".

This has worked for me.

If you need more detail, let me know.

[Matt Casey]

> I've never used cfimport with a relative path before. The doc's say start with "/".

Me neither, just mentioning that it was odd that Lucee doesn't complain when you give it non-existent paths.

I hear what you're saying and you're quite right. I could change my application to put my tags in the customtags path and prefixing everything with "cf_"..

But I really don't want to do that. I feel quite strongly that it should work.

I know in fact that it does work on many other installs, just not this one.

I admit that it's maybe not the most pragmatic approach... but I really don't want to have to re-write my application to work around this issue.

Any way. Next week I'm supposed to be hearing from the hosting provider's Lucee expert.
Fingers crossed.

Cheers

[Patrick]

Have you received any advice that might resolve this issue? I am experiencing this in a very large application that simply cant be re-written (Slatwall) is there anything I can do to resolve this? Thanks,

[Jean Moniatte]

If you have access to the lucee admin, can you define the mapping there instead of in application.cfc?

It's far from ideal, but it fixed the issue for me (on debian).

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/4458ae3b-ceae-456c-aac9-4d019b5789dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Patrick]

Well my main issue is multiple mappings of the same resource name (aka running multiple /Slatwall mappings) on 1 Lucee instance. Thats what I thought the purpose of multiple web-admin's was, so you can create custom mappings for each site. I think this issue resides around an issue with CFIMPORT and how Lucee handles it.

On Tuesday, February 14, 2017 at 10:45:53 PM UTC-5, jmoniatte wrote:

If you have access to the lucee admin, can you define the mapping there instead of in application.cfc?

It's far from ideal, but it fixed the issue for me (on debian).

On Feb 14, 2017 5:22 PM, "Patrick" <pat...@flynn-media.com> wrote:

Have you received any advice that might resolve this issue? I am experiencing this in a very large application that simply cant be re-written (Slatwall) is there anything I can do to resolve this? Thanks,

On Friday, January 27, 2017 at 2:35:44 PM UTC-5, Matt Casey wrote:

> I've never used cfimport with a relative path before. The doc's say start with "/".

Me neither, just mentioning that it was odd that Lucee doesn't complain when you give it non-existent paths.

I hear what you're saying and you're quite right. I could change my application to put my tags in the customtags path and prefixing everything with "cf_"..

But I really don't want to do that. I feel quite strongly that it should work.

I know in fact that it does work on many other installs, just not this one.

I admit that it's maybe not the most pragmatic approach... but I really don't want to have to re-write my application to work around this issue.

Any way. Next week I'm supposed to be hearing from the hosting provider's Lucee expert.
Fingers crossed.

Cheers

--
You received this message because you are subscribed to the Google Groups "Lucee" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.

[Jean Moniatte]

I just tried and recreated the mapping in the Web administrator instead of the Server administrator, and it still works. Maybe try with one of the web admins to see if it fixes the issue.

But I agree, it is an issue with cfimport that should be fixed.

To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.

To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/761e034e-67ad-4c43-987e-2facec24b625%40googlegroups.com.

[Matt Casey]

Hi,

No I've had no luck at all and have tried almost everything I can think of.
I've not gotten much help from the provider and so have run the same tests with another shared hosting provider and am having the same issue there.

To recap;

This is my bare-bones test setup;

/test
  /code
    mapping.cfm
  /tags
    tag.cfm

The mapping is defined in the Lucee web-admin as I don't have access to the server-admin.
The line in the lucee-web.xml.cfm is;

<mapping inspect-template="once" physical="{web-root-directory}/test/tags/" primary="physical" readonly="false" toplevel="false" virtual="/test/"/>

There isn't an application.cfc so there are no application mappings defined.
Application.cfc level mappings are not relevant for <cfimport> as they are runtime whereas <cfimport> is compile time. This is discussed elsewhere on this board.

/test/tags/tag.cfm contains only;

<!--- tag.cfm --->
<cfif thisTag.executionMode == "end">
    <p>
        <strong>Customtag</strong>
        <br>This is in <cfoutput>#getCurrentTemplatePath()#</cfoutput>
    </p>
</cfif>

/test/code/mapping.cfm contains

<h3>Using mappings to access absolute paths</h3>
<cfdump var="#getCurrentContext()#" label="Current context"/>
<cftry>
    <p>Try to import an absolute path using <code>taglib="/test/"</code></p>
    <cfimport taglib="/test/tags" prefix="mytags" />    
    <mytags:tag />
    <cfcatch>
        <cfdump var="#cfcatch#">
    </cfcatch>
</cftry>

Always gives the same error

"invalid definition of the attribute taglib [/test/tags]"

In local testing and VPS based production environments it works perfectly. As you would expect, it's pretty basic code.

I've tested locally on my dev server (ubuntu/lucee 5.1.034 + ACF10) and have also tested using commandbox on my local Windows workstation with various versions of Lucee, Railo and ACF.  It all work fine...
I can define the mappings in either the server or the web admin and it works perfectly as expected.
In production I have applciations using the same code running in on a Windows ACF9, Windows ACF10, Ubuntu Railo 4, and CentOS Lucee 5.0 servers with no issues.

Is this some weird shared hosting lock-down issue?
No idea but I'm going crazy...

[Patrick]

Hey Matt-

I have been speaking with Gert Franz who is a LAS professional support person (Rasia) and contributor to the project. He said we could escalate the fix at an hourly rate of $165 x 4hr min. But we could also submit a bug with test cases at bugs.lucee.org and hope it gets fixed in a monthly sprint they do. Or we can submit a fix to the engine ourselves that might escalate it getting rolled out sooner. Just a heads up, it sounds like he acknowledges this is likely a bug but didnt directly say that.

Patrick

[Patrick]

Submitted bug:  https://luceeserver.atlassian.net/browse/LDEV-1197