Hi Paul, as Zac said, did you try creating a dynamic application name on behalf of your host names? Something like below? And that didn’t work? Really would like to know a test case for this, because I think it shouldn’t be a problem.
<cfcomponent displayname="Application" output="false" hint="Handle the applications">
<cfif cgi.http_host is "web1.com"
<cfset local.appID="web1" />
</cfif>
<cfif cgi.http_host is "web2.com"
<cfset local.appID="web2" />
</cfif>
<!--- Then set some application vars --->
<cfset this.name="appCF#local.appID#" />
<cfset this.sessionTimeout=CreateTimeSpan(0, 0, 30, 0) />
<cfset this.sessionManagement="yes" />
<cfset this.setclientcookies="false" />
<cfset this.sessionType="cfml">
...
<cffunction name="OnApplicationStart" ...
Paul, as you’ve said… this isn’t a good solution at all. I’m sure someone will get this working somehow! Please post a simple test case so we can figure something out.
Browse to test.cfm. It correctly output the app name and test1
Now, change application.cfc to replace application1 by application2 and test1 to test2.
Browse again to test.cfm using a different tab or browser. It correctly output applcation2 as name and test2.
Go back to the first browser which was running Application1 and refresh
Surprise! it is now Application2 and all the context of application1 is gone.
Do the same with Application.cfm: all work as it should. Application1 is not destroyed as it should not be. only a time out or call to delete it should destroy it.
Andreas,
Sorry, I did not get a notification for your answer an completely missed it.
I will try your solution, however even if it works it does not solve the problem I have with Application.cfc.
As I tried to describe it, I believe Application.cfc is a HUGE step backwards and your answer confirms my feelings, even if it works. In fact it confirms my feelings even more if your solution works!
Having to dig into the Java structure with something like you propose (…cfset local.appID=“web1” /> . . .) demonstrates my point: something which worked effortlessly with Application.cfm now needs you to dig into undocumented Java stuff to try to make your code work!!! What a progress!!!
This is obviously a big step backwards and destroys the original idea of ColdFusion being a higher level language. What’s the point to use ColdFusion if you need to dig into Java to make your application run? Why not then simply code everything in Java? (or in assembly language ah ah ah)
I STRONGLY believe that if you want to succeed with Lucee and have a good impact on the market in the future your best route is to remember the basic ideas of ColdFusion and forget the stupid “improvements” of Adobe making ColdFusion a sub Java language instead of being a higher level.
Whatever a solution might be, Application.cfm works and Application.cfc does not. The rest is noise.
Please do not take this as a negative comment against you: I appreciate beyond limits what you do. I am simply trying to add a little grain of salt in what you do, hoping to help you myself in your venture.
Thank you so much for taking the time to read me and helping.
Paul
Hi Paul, I can understand you very, very well. I know your feelings, because I’ve been exactly there at some time in the past. And I don’t take your posts as a negative comment, not at all. To be sincere, I think of myself back in the classic cfml programming days, and to be honest it wasn’t a long time ago. There are things I still LOOOOOVE to use, like the good old cf tags like cfquery. But sometimes when dealing with different problems we need different solutions, and components and all this oop concepts addresses some of these important issues. I can only recommend trying it and learn a little about it, and as soon as you feel more familiar with it, you’ll notice it is a great thing to know and then you can always decide what is best for your specific situation/solution.
Comming to your test case, I’m really asking myself how could it work with the classic cfml. I don’t think it can work like this, because you are overwriting the code base, thus you are overwriting and resetting the application variables. At every refresh the variables will be already overwritten and gone. Really curious how this could have worked before in your old setup.
However… I’ve created this little testcase for you as a demonstration on how it could work. Just drop the files of the attached zip file into an empty webapps/root of a Lucee Express Version and run it. You’ll see that you can load the application settings even on behalf of an URL variable named “app” by opening http://localhost:8888/test.cfm?app=1 or http://localhost:8888/test.cfm . You can do it also by binding it to cgi.http_host.
What you still would need to do is to adapt the varibale names of your apps pages, like changing application.someVarName to this.someVarName. But this is better than having lots of codebases.
I also can really recommend the following so highly valuable blogposts of @bennadel
Andreas, Zac,
A great thank you to both of you. Yes, I had made a stupid mistake and thanks to your help I can now run multiple applications with a single Application.cfc.
Andreas: thanks for your test code. Just a small remark: your test.cfm template calls variables like #this.name# and #this.test#. I believe that this is a mistake as this. does not seem to be defined outside application.cfc.
I have one more question: in my Lucee admin the entry “Performance/caching” does not work and send an error “java.lang.NullPointerException” The Error Occurred in /admin/server.cache.cfm: line 109 called from /admin/web.cfm: line 467
I have the same error on two different Lucee implementations. Is this a known problem?
Many thanks to both of you again
The variables for “this” are always set in the Application.cfc pseudo-constructor ( this is how we call the upper part of the body of the component ), and not outside of Application.cfc. This is because they usually shouldn’t be reset or overwriten for the application. These variables are like some kind of constants which you want to use very, very often throughout your application (so they always persist). I’ve used these variables in the test.cfm just to show you how you can call/access them in the cfm templates, just like we CF developers did with #application.variables# in classic CFML.
Regarding the error you’ve seen, I can’t really tell what would be causing it. But as you’re accessing the Web Administrator I would always recommend just to stick to only one domain then . That is because the WEB-INF is shared across all your multiple domains in your specific configuration. Thus I would try to avoid any possible conflicts. But may be there is another CF-Pro around here who might have more insights to share than I do.
I’m glad I could help a little and I hope very much that I could somehow, give you some sort of new positive perspective and feelings regarding CFML technology. Don’t give up!