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
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;
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;
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
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?
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???On Monday, 23 January 2017 10:52:33 UTC, Matt Casey wrote:
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
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;
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;
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
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?
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.On Friday, 27 January 2017 08:50:04 UTC, Matt Casey wrote:
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.
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…
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.
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…
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
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
Hi,
Has anyone resolved this?
I’ve been experiencing this with Lucee 5.2 on linux using Farcry. Funny thing is it works with some and not for others. ie you can have two cfml files importing the same taglib, one will work and other will fail. I wonder if it’s a resource/timing issue during startup of the application. Restarting server can fix it but that’s not really aways an option.
I’ve only ever seen this on Lucee 5. I run the same setup on CF9,CF11, Railo and Lucee 4.5 without this issue.
Phil
Just thought I’d bump this.
This is still very much an ongoing issue for me. It only started with lucee 5.2 that I can see. This will happen randomly on my local linux (centos) development machine and on AWS linux during lucee startup.
Linux , mysql, Lucee 5.2.9.31,Apache Tomcat/7.0.56, Java 1.8.0_121
I thought that it might be a resource issue but doubling the size of the EC2 instance and adding a bit more JVM memory makes no difference.
Could it perhaps be a Java or Tomcat issue?
A reboot of lucee is the only was of resolving the issue (and sometimes it causes the issue to appear on a different cfimport). Once lucee decides it can’t see a library there there is no way of changing it without the reboot. You can change the address from root to relative and then it works eg /mystuff to …/…/mystuff. Not really a realistic workaround.
There have been others reporting this issue, see below and above. I’m interested if it’s still an issue for them or how they resolved it.
Cheers Phil
I see there was a rejected bug here…
https://luceeserver.atlassian.net/browse/LDEV-1197
Could you try upgrading java to the latest 1.8 release and tomcat 7.0.92?
Thanks for the suggestion Zac. I’ve updated Java (1.8.0_191 (Oracle Corporation) 64bit) and Tomcat (Apache Tomcat/7.0.92) and it’s still having this issue.
Any other suggestions?
invalid definition of the attribute taglib [/farcry/projects/XXXXXXXXX/tags/webskin].
I think I’ve seen this before in older versions of Lucee (not see it happen with 5.2.x myself) when there have been JVM issues, and some mappings just randomly disappear even when they are statically configured in the lucee-web.xml.cfm.
Unfortunately I don’t have many more details than that… Do you see any other issues with the app relating to the overall health of the JVM?
An alternative that is specific to FarCry Core might be to eliminate the need for mappings by restructuring your project to use a webroot install (the contents of your projects www folder gets moved into the webroot, and /farcry gets moved into the webroot), but that might only mask the underlying issue too.
Well I do have one thought. These servers have been upgraded from the original install of railo. So I wonder if something my still be hanging around because of that. It’s only turned up in 5.x. I have a similar server running 4.5 that’s never had this issue.
When I saw the issue it wasn’t on servers upgraded from Railo to Lucee, so I’m not sure about that. Even if you had an older config and were using it with Lucee 5.x I can’t think of a reason why it would affect mappings in this way.
You could try going with a fresh install just to rule it out, but of course that’s a little bit of work if you have to reconfigure everything manually.
I have the same issue.
“invalid definition of the attribute taglib [{sometagname}]”
I use <cfimport taglib="/sometagname" prefix="sometagname"> in lots of pages in several websites.
/sometagname is a folder in my webroot.
I now use Lucee 5.3.1.103 and experience this on both my Mac as well as on Ubuntu, but it started happening after upgrading from 4.5 to one of the first versions of 5.
After a restart of Lucee it mostly disappears, if not, I just have to to restart until it works. If one webapp in my lucee install suffers from this problem all fail that use this import. If it works for one webapp they all work. This makes restarting always a frustrating experience, because it seems so random.
Hi, just tested Lucee 5.3.3.43-SNAPSHOT on my Mac that had previously lucee-5.1.0.34.
This issue is not appearing anymore on my Mac. I restarted about 8 times and it seems ok now.
I see there is not a newer version that is production ready. So I will test that once it is available.
1 Like
Thanks for testing that and reporting back, great to hear that the problem has been resolved 
So, 5.3.2.74-RC also includes that fix and is due to drop as a stable release any time now (waves to @IamSigmund)
Hi all,
I’m sorry to say that this issue is back. I’m now using Lucee 5.3.5.92.
I even see it happening that the cfimport fails on one template and are fine on other templates within the same application. I have to do a full regression test on all applications (websites), to know for sure every page is loading as it should.
It is very random: sometimes all websites using the cfimport have this issue, sometimes all websites seem fine at first sight, but then some templates fail.
Restarting lucee has become a very tricky thing to do this way. I hope you can manage to solve this.
Update: I will first update my java version. It is pretty old I see…
If you can, try the 5.3.6 RC or even the latest 5.3.7 snapshot, they are a lot more robust
5.3.2 final release is live.