I'm working on a web application which is deployed on a glassfish server.
I wanted to implement the log4j framework. First, I tested everything on my local machine (local server) and it works perfect.
Now, i deployed it on a test environment and noticed two strange behaviours.
It creates two logfiles, one is named "server.log" and is created during the server restore function is executed. The other has the instace name, like "instance104.log" and is created while the server is starting.
But this is not the main problem. The main problem is that it doesn't write anything to any of those logfiles.
This is the logfile path from the log4j.properties:
log4j.appender.file1.File = /lfs/wwwmnt/appName/logs/project/${com.sun.aas.instanceName}.log
Does log4j need a initialization for writing logs to logfiles when it's on remote servers? Do I have to add the log4j jar to the remote sever?
Like I said, it works perfect on local evironment but on the test it just creates the logfile but doesn't write anything to it...
So I figured out it was a problem with the clusterDomain domain.xml file. The configuration tags were missing ( ), and I couldn't configure them - in our business envoronment only the DevOps can do that.
Busienss processes are a pain..
Related
I have two environment development(local) and other QA environment, In the last is a cluster with two nodes.
The problem came with the deploy in QA environment I can't see the log in the server, but locally print console logging without problem.
I'm sure that module structure is the same in both environments, and my configure is in the classpath with xml file.
Which aspect can influence in this difference?
Local print logging console server and QA enviroment dont do it.
I was able to solve this, I checked the server in the development environment, it's a domain configuration and for this reason it did not show the application log in the user wizard, due to application conditions only the applications write to the .log file, at start I was not allowed to check this domain log directory, but after I check this by command line my app log file is right there
I'll hope to help someone else
On a remote server I'm having a folder which contains serveral jars. Each of it will represent an application, which will open up a port, on which a web-application is served.
It might look like this:
jars
app1.jar
app2.jar
app3.jar
I'm trying to find a solution now to ensure that all of them are constantly running on separated jvm's. Whenever one jar is replaced by another uploaded jar, this should immediately be handled.
At the moment I can achieve parts of this manually by setting up a service for each of it. Something like:
my-servers-service-setup-tool app1 java -jar app1.jar 12345
(last parameter is the port)
In case app1.jar is now overridden by an upload: How could the service react on that? Either restart itself or if this is necessary setup a new service for the same port.
If a new jar enters the folder, I'd setup a new service for this as described above. Might there maybe be a more declarative approach to this? I mean, another automation that would detect the arrival of a new jar and that would setup a new service.
When we configure a web application to run in IIS Express there are certain things VS does, like:
Creating the application host configuration file in the IISExpress subfolder of the user documents folder.
Creating a dedicated site section for each web application in the solution, including ours.
Maybe more things are done, which I am unaware of.
I would like to replicate the same process from a script, so that running the web application from the script would be equivalent to running it from VS. Including for the very first time.
Right now I start IISExpress with the /port and /path flags, because this is how I used to run Cassini. However, Cassini supported an additional flag - /vpath. They removed it from IISExpress, meaning I have to use another set of flags - /config, /site, /siteid. But I suspect it must be done in conjunction with the Appcmd.exe utility.
This second approach is still something I haven't managed to master. So, my question is this - suppose I am given the port, path and vpath of a web application (i.e. no need to read them from the web application's csproj file, like VS does). What command sets up the right application host configuration file and how do I run IISExpress to take advantage of it?
There is a file within the .\jboss-4.2.2.GA\server\default\deploy folder, named "jmx-console.war". I am getting a security vulnerability dealing with this module. How can I tell if our application is using this module. I implemented an open source tool, but I'm not sure how to test whether it's being used.
Nessus vulnerability of High Severity:
JBoss JMX Console Unrestricted Access
http://www.tenable.com/plugins/index.php?view=single&id=23842
If you see that war file in the deploy folder, then most likely your application is using it. That is to say, it is most likely being loaded. It should be fairly easy to test for, assuming you know the HTTP port the JBoss instance is listening on. By default, it is 8080 so point your browser to http://[your jboss host]:8080/jmx-console and see if the console comes up, keeping in mind that it might be password protected, and your HTTP port might not be 8080.
You should also see something like this in the server.log or configured equivalent:
11:52:30,165 INFO main [TomcatDeployer] deploy, ctxPath=/jmx-console,
warUrl=.../deploy/jmx-console.war/
Having said that, there's a couple of ways I can think of that would indicate or cause the jmx-console to not be deployed:
The folder you referenced is in the default server directory. This is only one instance out of 3 (default, all, minimal) and you may be running one of the others, or even a custom configured server. That is to say, if you were running the minimal server instance, or one that did not contain the jmx-console.war, then the presence of that file in the default server's deploy directory would not cause it to be deployed in another server's instance. (that all sounds more complicated than it really is)
War files in the deploy directory depend on another directory called jboss-web.deployer which actually deploys war files. If that directory is not there, my guess is that war deployment has been disabled. Highly unlikely though, as there are easier ways of doing this, and if someone went to the trouble of removing this folder, they probably would have removed the wars too.
Bottom line is, the easiest way would be to find the http port, then hit the jmx-console URL and see if it responds, or check the log file. It is conceivable that someone could rename jmx-console.war to something else (in an ill-conceived attempt to hide it perhaps ?) in which case, you would need to execute a battery of http request scans and try and find a jmx-console signature, but that's out of my (otherwise quite large...) area of expertise.
I have a web-site that needs to be up all the time. I also, of course, need to do new releases. Each page tends to be very long-lived, with lots of JavaScript doing AJAX calls to the server.
What I do is build a new WAR file and put it in Tomcat's webapps directory, which ends up looking like this:
20110701-7f077d 20110711-aa8db4 20110715-6f4a12
20110701-7f077d.war 20110711-aa8db4.war 20110715-6f4a12.war live
The war file is named after the date of its release and the first few characters of its GIT commit-id, just so I can keep track of everything. Tomcat automatically unpacks the war file into a directory of the same name. The live directly just contains a file giving the name of the "live" version.
This way, each user can continue using the version of the back-end that works with the version of the front-end that he has loaded into his browser. And obviously, version upgrade and reversion is painless.
Now, I'm switching to node.js and I want to do the same thing. I am reliably informed that node.js doesn't support independent applications in one instance. So, what to do?
The only thing I can thing of is to designate n slots (where n is some small number like 10 or 100), and each slot corresponds to a port (i.e., slot 1 is 8001 and so on), put Apache in front of several node.js instances, each representing a slot, and Apache would use mod_proxy or mod_redirect to proxy requests like '/slot01' to port 8081. "live" would point to the current slot.
This would be clumsy and error prone and require an otherwise useless Apache instance and most of all I cannot believe that node.js doesn't have a good solution to what seems like a near-universal problem.
You can use node-http-proxy and write some code to monitor your 'deployment directory' for new versions and when such versions are found you can start the corresponding script and proxy it under the directory name (to make myself clear if you find a new directory 'version-11-today' your parent node-http-proxy script could start the new script assigning it a port passed as a parameter and then proxy to the new app under the path '/version-11-today').
A similar solution could be done with nginx only in this case you could write a script to monitory the deployment directory and generate some new nginx configuration when new apps are found.
If you are afraid you might run out of ports I believe both node.js and nginx can run on and proxy unix sockets besides inet sockets.
An advantage of the above is that each app runs in its own process protecting the other apps from crashes and enabling individual app restarts.
A third solution if you are not afraid some bug will crash your app is to have a parent script that loads all the app versions in the same process and maps them under different paths depending on the directory they were found in. You can still restart your server without downtime such as in this example http://codegremlins.com/28/Graceful-restart-without-downtime