Apache Tomcat 7.0, CentOS 5.8 i386
A web application needs a specific environment variable XY to be present in its context.
This variable is set in /etc/profile as a result of a computation (i.e. not a static value) and it is also used by other native applications running on the same system (hence it has to be the environment variable approach).
Tomcat is started with a general script using a dedicated tomcat user and sudo.
The first problem of passing XY through sudo is solved (thanks to stackoverflow) with the explicit definition within /etc/sudoers:
Defaults env_keep ="XY"
It means that the environment variable XY is preserved by sudo which is not the default case.
Now the environment variable XY is visible in the tomcat process. This can be verified with ps and /proc/tomcat-PID/environ or an explicit echo $XY in */your_tomcat/bin/startup.sh* (which is called by the init.d script using sudo). But seeing XY in the tomcat process does not mean the web app can see it. The web app dumps its environment to the log file with help of
LOGGER.debug("Environment: " + System.getenv());
the astonishing result for me was: no XY at all, although tomcat had it!
After reading the context documentation of tomcat 7.0 (be careful to distinguish between 7.0 and older versions of tomcat) I added the following entry to */your_tomcat/conf/context.xml*:
<Context>
...
<Environment name="XY" value="INIT_VALUE" type="java.lang.String"/>
...
</Context>
Now the output of System.getenv() really contains my XY environment variable BUT it has the correct value from /etc/profile not the value INIT_VALUE I specified in context.xml. With other words my /etc/profile does overwrite the INIT_VALUE, which is what I needed but not what I expected as there is no word about this in the documentation.
Did I find un-docmented behaviour that might be removed in later versions of tomcat or is this the way to go?
So in the end I am happy having a working solution but I am not very confident that this is a recommended and proper way of passing-through environment variables.
Any comments would be highly appreciated.
Tomcat Environment entries are different from system environment variables. Environment Entries specified by <Environment> markup are JNDI, accessible using InitialContext.lookup under java:/comp/env, while System.getEnv() is about system environment variables (of the tomcat process itself).
Related
I am trying to diagnose a few issues with ssl connectivity with Leingen. I am trying to find what SSL Key Store and Trust Store is being Used by Leingen,
I am behind a corporate firewall and we have self signed certificates deployed on all our desktops . I am running lein.bat on a windows 10.
Hence I have to start Leingen with java -Djavax.net.debug=true option.
The :jvm-opts in the project.clj wont work -- I need to make sure the Liengen's JVM is started with this option
You can set leiningen JVM options by setting LEIN_JVM_OPTS environment variable before running lein in the same terminal session.
The lein command is just a shell script which eventually invokes java with various options. You can edit this script to see what options are used and/or to modify them.
As Piotrek mentioned, the LEIN_JVM_OPTS environment variable is the canonical way of passing options to the jvm in which lein runs. You can see it used on line 372 of the source code.
For your case:
> export LEIN_JVM_OPTS='-Djavax.net.debug=true'
> lein clean
> lein run
Since you're running windows, you'll want to actually look at the lein.bat file. You'll still need to update LEIN_JVM_OPTS, but how you go about it will be a bit different. If you're using windows command terminal (cmd.exe) you will want to use the set command.
set LEIN_JVM_OPTS="-Djavax.net.debug=true"
The command is likely different if you're using powershell, and you can likely find out how to set that on this page on environment variables.
I’m currently running window 7, ACF 11, and IIS 7 and would like to install Lucee express to try.
I’m having the hardest time getting Lucee to work on my local desktop. I followed this article http://www.gpickin.com/index.cfm/blog/setting-up-lucee-in-my-dev-environment-changing-ports I can’t get the Lucee welcome page to work.
I download the Lucee Express from here http://lucee.org/downloads.html
I extract the file to C:\lucee
Ran the C:\lucee\bin\startup.bat
Navigated to 127.0.0.1:8888
I get the follow message: Firefox can't establish a connection to the server at 127.0.0.1:8888
Can someone tell me what am I doing wrong? Thank you in advance for your insights.
As identified in the comments on the question: you are missing the environment variable pointing to your Java runtime (you need one of JAVA_HOME or JRE_HOME.
This can be achieved in one of a coupla ways.
Set it globally:
Control Panel > System > Advanced system settings > Environment Variables > System Variables > New...
Or set it for just that environment by editing the startup.bat file you've already been using:
SET JAVA_HOME=[path]
In both situations you need a path to either a JRE or a JDK. You say you have CF11 already installed, so you can simply point to its one, which will be a subdirectory of your CF install, as Leigh points out above. So something like:
SET JRE_HOME=D:\apps\Adobe\ColdFusion\11\express\jre
If you have a Java JDK installed instead and want to use that, use JAVA_HOME instead of JRE_HOME, eg:
SET JAVA_HOME=D:\apps\Oracle\Java\jdk\1.8.0_60
As these things can be installed anywhere, you'll just need to locate 'em and use the path accordingly. You want to point it to the top level directory of your JRE or JDK, which contains the bin subdirectory.
I am currently setting up a web service powered by apache and running on CENTOS 6.4.
This service uses perl scripts (cgi-bin) launching in particular external homemade fortran compiled binaries.
Here is the issue: when I boot my server, everything goes well except that one of my binary crashes systematically (with a kernel segfault) when called by my perl scripts.
If I restart manually the httpd service (at the command line: service httpd restart), the issue is totally fixed.
I examined apache/system logs and nothing suspicious can be found.
It appears that the problem occurs only when httpd is launched by /etc/rc[0-6].d startup directives. I tried to change the launch order of http (S85httpd by default) to any other position without success.
To summarize, my web service is only functional (with no external binary crash) when httpd is launched at the command line once the server has fully booted up!
[EDIT] This issue is now resolved:
My fortran binary handles very large arrays and complex functions requiring an unlimited stack size.
Despite that the stack size limit was defined on a system-wide basis (in /etc/security/limits.conf), for any reason it appears that the "apache/perl/fortran binary" ensemble was not aware of that (causing my binary to crash each time it was called).
At the contrary, when I manually restarted apache at the shell prompt, the stacksize limit was correctly passed (.bashrc with 'ulimit -S -s unlimited').
As a workaround, I used BSD::Resource module (http://metacpan.org/pod/BSD::Resource) to define stacksize directly in my perl script by using e.g. setrlimit(RLIMIT_STACK, $softlimit, $hardlimit);
Thus, this new stack size limit is now directly passed from my perl script to my binary.
I've run into similar problems before. Maybe one way to solve this is to put the binary on a 'delayed start', so that it starts after everything else on your system is running. One way to do this is to put an at job in your /etc/rc.local script, to start the binary in X minutes.
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)
I have access to a remote Solaris terminal which crashes occasionally, and I have to ask someone with physical access to boot the machine up, which it does successfully. I would like to know which tools/files should I look at to find out the cause of the crash so that I can make the necessary configuration changes and avoid it in the future.
What tools you can use will depend on what version of solaris you have running and what the actual problem
is. The first thing to do is check the system console (which it sounds like you don't have access to) and the /var/adm/messages file. This file is updated with system messages and the newest will appear at the end.
Next, you can look for a system core file. If a core file is created, it would be in /var/crash/hostname where "hostname" is the name of the machine.
If you have an actual core file in the /var/crash/hostname directory, this set of commands will give you a good
string to search google with:
# cd /var/crash/hostname
Replace "hostname" with the hostname of your machine.
# mdb -k unix.0 vmcore.0
If you have multiple core files, select the most recent version.
> ::status
This should give you a panic message, cut and paste that into google and see what you can find.
For more core file analysis read this:
http://cuddletech.com/blog/pivot/entry.php?id=965