log4j + client-application
Hello I want to use log4j together with my application. I.e I want all my servlets, jsps, ejbs and clients toshare the same logfiles. I've implemented log4j according to the tip the atlassian guy gave (don't remember his name).Put the log4j.jar in orion/lib, add libary path="config" to the orion-application.xml and finally add thelog4j.properties (or .xml) in config and add "config" and add the config to your application. So far so good. All my servlets, jsps ejbs are able to invoke log statements. The trouble is that my client which runs as auto-startupis not able to find log4j.xml until orion isfully initialized.So if I make a log statement in the main method of my client log4j will propt an error msg.But ifI invoke a delay until orion is initialized and then make my logstatement everything works. I've tried to set the Class Path: attribute in the Manifest of my client ,which in my case looks like ../../config/log4j.xml.But as it turns out the classloader points at the orion directory and not on my clients jar file, in the mainfest specs it says that the Class Path: attribute is relative to the appplications jar file.Which in my case is not true. How do I use log4j with an application-client which is in autostart mode?` regards /Linus
Re: Shutdown causes Address in use: JVM_Bind
Stephen, Andrew, After I posted this issue, I noticed that the problem was application dependent, i.e. when my web appwas invoked from an applet, shutdown and startup work as advertised. However, when the web appwas invoked frommy client app, in which I use a URLConnection object to talk to the web-app, subsequent shutdown and startup exhibited the address-in-use problem. The fixwas to do a disconnect() on the client app's URLConnection (casting it to an HttpURLConnection). The implication is that the browser (IE 5.0) is already well-behaved in this regard, so applets did not exhibit the problem. As to why this client-side problem affected the webserver, Iassumeit is because the web-server and client share the same TCP stack (I'm developing in loopback mode at present). I'll check that assumption later on, when Ideploy tothe real server. Bill. - Original Message - From: Bill Winspur To: Orion-Interest Sent: Thursday, February 07, 2002 1:11 AM Subject: Shutdown causes Address in use: JVM_Bind I'm running Orion 1.5.3 on Nt4/SP6, and jdk1.3.1_01. The command I use to shut the server down is: C:\jdk1.3.1_01\bin\java.exe -jar admin.jar ormi://localhost admin pwd -shutdown After a shutdown, starting the server always produces the following on the orion console. Error starting HTTP-Server: Address in use: JVM_BindOrion/1.5.3 initialized My work-around is to boot windows, very tedious. The command I use to start the server is: C:\jdk1.3.1_01\bin\java.exe "-jar" "orion.jar" I had a look thru the archive but the search keys 'Shutdown', and various substrings of the serverconsolelog, above, did notreveal any solutions. Is there an alternative way of shutting down the server, that releases the tcp/ip binding ? TIA Bill.
Re: [announce] Log4J Appender for Orion's application.log
Hi Curt, I agree with you, and that's why long ago we developed our own logging library, which rolls log files, logs to DB and can be configured per web application. Now we are looking to migrating to Log4J, even though we still have to check if it will be worthwhile for us. I had a look at the new logging classes that are being included now in the JDK1.4, and it seems the tendence is to centralise everything, which I don't like. I understand though, that for maintenance reasons it might look very attractive. In our case, log configuration files are always located in the same place /WEB-INF and follow the same name pattern *.logger.conf. We then redirect all the log files to the same directory, which is outside the deployed application directory, and you can have all the log files in one place while you know where everything is configured. Easy to find information, easy to mantain and, as configuration changes are detected in runtime, pretty useful. D. PD: I would also add that IMHO, web app security in the J2EE spec is very poorly defined, as specifying mappings in static files and letting containers implement role-users mappings makes applications rigid and non-portable. But that's another story ;). Curt Smith wrote: Geoff Soutter wrote I've hacked up an Orion Appender to allow you to log to the application.log file, via the Logger instance that Orion installs at java:comp/Logger. Here it is in all it's glory, use it however you wish. Cheers Geoff PS, did anyone figure out if it's possible to get orion to roll it's log files when they get too big? ;-) How about Orion logs to a log4j output device instead of apps logging to Orion's log files? Or did I miss understand this functionality?? Personally I feel the new log4j 1.3 features that make it easier for each application to have it's xml config file in the .war / .ear so that apps can have their own (separate) log files from each other to be a very useful choice. My view of the problem of deploying and supporting a j2ee app is the few features j2ee put in the spec (a big zero) to allow debugging and logging of app, feature, bean operations. I feel we need to drill on the debugging problem until we have a facility that supports logging based on session ID, so that we can follow a particular user's actions and failures across a cluster and set of services. To me, moving to one log file for the universe is the wrong direction? Any opinions? curt
Re: App server debugging -- HELP
Hi Aaron. I've had some success on these kinds of issues with a product called OptimizeIt, from VMGear. Best link to hit would be www.opitmizeit.com. They have a free-trial, which you can use to figure out if it will find your issue or not. I just saw that they were recently purchased by Borland, so no idea if it will affect their currently excellent tech support. One of the things it does show is how much time is being spent in a given function, which may indicate if this is the cause of the contention, or where threads may be waiting for resources. -Steve Aaron Tavistock wrote: I've got a very large web application (about 300 objects and about 1000 pages) which uses mostly straight JSP. This gets a reasonable number of hits with approximately 200 concurrant sessions operating. [snip to save bandwidth] -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
