Any reason this is happening? We have a client that is behing a proxy/firewall that doesn’t allow outgoing connections and Lucee isn’t deploying because of this.
Please always mention which version of Lucee!
It seems only the EOL Lucee 4 references this url?
Sorry, latest 22.214.171.124. So it’s still in there somewhere
is it fresh install or an upgrade from 4? time to upgrade your loader?
Fresh deployment of a .war file into Tomcat.
the .war was created with 126.96.36.199?
yes, it has /WEB-INF/lib/lucee-188.8.131.52.jar in there. The application runs fine on all machines that allow outgoing connections
Any news on this?
well, either you need to provide a cut down, reproducible test case, or you could install fusion reactor to pin point which bit of Lucee code is calling that url…
I started lucee express and it doesn’t reference the site you’ve indicated. Which means it’s probably specific to your environment or code.
I’d install this as a javaagent or in the WEB-INF in the war
I ran it as a javaagent on lucee-express and poked around in the extensions area of the server admin and it dutifully found things:
Then try following this advice:
If you want to test the startup of your application with no connectivity, toggle the Keep the fault tolerance settings after server restart switch and restart your server.
And see where the exceptions fly from.
Also keep in mind Lucee will look for assets when you reference them…i.e. in createobject() in your CF code. If it can’t find a local jar that matches it’ll try to download it. So it could be something in your CF code, not just the jar.
Ah, ok, thanks!
We’re also deploying the .war with the cfspreadsheet extension in /WEB-INF/lucee/deploy/cfspreadsheet-lucee-5.lex
I’m guessing it’s looking for it right on startup, before the deploy folder gets processed? What would be the way to prevent that from happening? To put the cfspreadsheet.jar from the archive into the bundles folder beforehand?
I don’t see any references to that hostname in the cfspreadsheet extension either.
I would recommend you pinpoint where it’s coming from first before you get ahead of yourself trying to prevent it. My guess is you have an old Railio or Lucee jar in your classpath. Spin up a fresh new server and see if it happens there.You mentioned deploying a war. Do you have other wars in your servlet? Have you added jars to your servlet’s lib folder in the past to attempt a “common jar” installation? Any of these could be the culprit.
Since it’s a clients’ server, we don’t have full access and only see the logs. We’ll try to work something out to get to the bottom of this.
Thanks to everyone so far!