Re: log4j w/apache
This is described here: http://www.mail-archive.com/log4j-u...@logging.apache.org/msg10697.html If you truly want them to go nowhere you can do this: log4j.logger.org.apache.commons.digester.Digester=WARN, nowhere log4j.logger.org.apache.commons.digester.Digester.sax=WARN, nowhere log4j.appender.nowhere=org.apache.log4j.varia.NullAppender log4j.additivity.nowhere=false The real trick is that you have to send those messages to a logger that won't pass them up (i.e. additivity=false). Using the documentation you should be able to take it from here. --Chris On Wed, Jun 24, 2009 at 4:29 PM, cpanoncpa...@yahoo.com wrote: Hello Newbie on ussing log4j and now that I have a simplistic log4j configuration file I am seeing ALL of the apache all from org.apache.commons.digester.Digester or org.apache.commons.digester.Digester.sax. How can I stop that but still keep a simple or reconfigure my log4j.properties? tia. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
UDP fails, but doesn't throw a SecurityException
I have a servlet that sends and listens to a local UDP service. To
allow this, I established the following policy:
grant codebase file:${catalina.base}/webapps/modbus/- {
permission java.net.SocketPermission localhost:502, connect;
};
This allowed packets out to the external service, but not responses.
I changed it as follows:
grant codebase file:${catalina.base}/webapps/modbus/- {
permission java.net.SocketPermission localhost:502,
connect,accept,listen;
};
and it started working.
The client library in question creates a DatagramSocket(), then calls
receive() on it with a timeout. Before adding accept,listen t
always timed out.
Version information:
Tomcat/6.0.18
JVM 1.6.0_13-b03Sun Microsystems Inc
O/S Linux 2.6.28-13-serveri386
Here's my question: if this was failing, why didn't it throw a
SecurityException? It would have been less challenging to figure out
what was going on had there been one.
--Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UDP fails, but doesn't throw a SecurityException
Here's my question: if this was failing, why didn't it throw a SecurityException? It would have been less challenging to figure out what was going on had there been one. Ask your Java vendor. :) There is no Tomcat code there. Really? I guess I didn't realize that. I figured the security was mainly implemented by the classloaders provided by tomcat. Actually, I guess I didn't really think about how it worked. Maybe I should figure that out. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrade to Tomcat 6 on Ubuntu
On Fri, Jun 12, 2009 at 4:32 PM, André Warniera...@ice-sa.com wrote: If yes, you are using the Ubuntu prepackaged version of tomcat 6.x (?), and it probably install it alongside tomcat 5.5, not on top of it. Yep, that's exactly what it does. The ubuntu packages put tomcat6 into directories whose paths include tomcat6. The ubuntu packages for tomcat really aren't too bad. My only complaint is that they recommend running with GCJ, so if you use a package tool like aptitude it may try to pull that in even if you don't need/want it. It's not that hard to make it not do that, and their packaged tomcat by default follows whatever jvm /etc/alternatives points to (see the man page for update-java-alternatives). --C - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput=true not working. Why?
Konstantin, Thanks for sharing your experience. It was helpful. I still have swallowOutput enabled but, with help from folks on this list, I kind of came to the same conclusion as you. I also realized that I was making a mistake by trying to have my webapp use the shared copy of log4j rather than just including its own log4j in the .war. The reason had to do with the classloader, and which log4j.properties gets loaded for my webapp versus for catalina itself. By sending another log4j with the webapp and following advice to go back to RollingFileAppender, I now have things working pretty sensibly. About the only real challenge now is dealing with things not yet smart enough to use log4j. One of those things is jamod (a Modbus protocol implementation in Java) -- and it's enough of a problem that I'm rewriting its logging :) --Chris On Fri, Jun 12, 2009 at 1:54 PM, Konstantin Kolinkoknst.koli...@gmail.com wrote: 2009/6/9 Christopher Piggott cpigg...@gmail.com: (...) This was not working, so I searched documentation and learned about: Context swallowOutput=true ... /Context However, this swallowOutput doesn't seem to work. I tried putting this in several places: (...) If you are still puzzled with swallowOutput mistery, here is my experience. I tried a similar thing once, not with log4j, but with JULI in TC 5.5, and also found that swallowOutput does not work with logging frameworks. The reason, as I see it, is the following: 1. to implement this functionality, Tomcat creates a custom PrintStream (SystemLogHandler) and replaces the default System.out and System.err 2. logging classes start up and are initialized before the above said happens, and at their initialization time they get reference to the original System.out and System.err PrintStreams, bypassing this replacement trick. After some thought my conclusion was that there is too much of a trick involved in that swallowOutput thing and I would better seek for a solution inside the logging framework itself. Though I do not have a clear recipe yet. I was not very interested. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
swallowOutput and service threads
Hi, I'm running tomcat 6 and am having the problem that swallowOutput doesn't work for my service threads (i.e. threads owned by the webapp, created in ServletContextListener.contextInitialized() and managed entirely by me). I noticed that swallowOutput=true doesn't seem to affect these child threads. Is there something that I have to do when I initialize my service thread to map its stdout/stderr to the rest of the webapp's, so that swallowOutput works on these children? --Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput and service threads
(By the way, did you solve your other problem of not getting *any*
stdout output swallowed when swallowOutput=true?)
Yep. I put it in what is essentially $CATALINA_HOME/conf/context.xml
which means it's server-wide and not host-specific ... and as you
pointed out, is a setting for all webapps. For now this is what I
want ... at least until I can go through all my servlets and make sure
they log properly. I'm carrying a lot of little apps I wrote a long
time ago that don't use a Logger. I've come to see the value of doing
it with log4j but it'll take me a little while to get everything
inline.
You may have to set the thread's context classloader like this:
public void contextInitialized(...)
{
Thread t = new Thread();
t.setContextClassLoader(Thread.currentThread()
.getContextClassLoader());
}
I will definitely try that. I also will consider using log4j's
rotating file appender instead of the ConsoleAppender. The reason I
didn't do this in the first place is permissions: I don't normally
have webapps that are able to write their own files. I will have to
think about this a little.
Thanks for all your help!
--Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: swallowOutput=true not working. Why?
Y On Tue, Jun 9, 2009 at 3:45 PM, Christopher Schultzch...@christopherschultz.net wrote: log4j.appender.R=org.apache.log4j.ConsoleAppender log4j.appender.R.target=System.out log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n I've never used the target property... is this actually a thing? ConsoleAppender should already send messages to stdout. Yeah, ConsoleAppender understands it ... but it's probably redundant as System.out must be the default. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
swallowOutput=true not working. Why?
Hi,
I just switched from Tomcat 5.5 to Tomcat 6 on an Ubuntu server. I'm
trying to use log4j with this configuration:
log4j.appender.R=org.apache.log4j.ConsoleAppender
log4j.appender.R.target=System.out
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
This was not working, so I searched documentation and learned about:
Context swallowOutput=true ... /Context
However, this swallowOutput doesn't seem to work. I tried putting
this in several places:
1) in the sever-wide context.xml, which already exists and has a
Context ... element. (On my system, this fil is in /etc/tomcat6).
2) There was no host-specific one, so I added the file
/etc/tomcat6/Catalina/localhost/context.xml with the contents:
Context swallowOutput=true/
Note that ${CATALINA_HOME}/conf is a symlink to /etc/tomcat6, so when
the documentation refers to the locations for these files, I am pretty
sure I know which ones they're talking about.
3) Just to exhaust all possibilities, in my webapp's META-INF, I
created a context.xml file with the same contents.
None of these three things had any effect. I tried it both with log4j
and, to rule out that log4j was the problem, tried some
System.out.println and System.err.println here and there. Near as I
can this output goes nowhere.
I would REALLY like my log4j output to go to localhost_datetime.log.
Otherwise, I think I have to do some screwing around with the
security manager in order to use something like the
RollingFileAppender.
I tried to follow http://tomcat.apache.org/tomcat-6.0-doc/logging.html
as best I could, including using tomcat-juli.jar from output/extras as
well as adding in tomcat-juli-adapters.jar. I'm not sure if that
really applies, but was wondering
BTW the logger itself more-or-less seems to work. I determined this
by doing something wrong just as a test: I called log4j's
BasicConfigurator.configure() to see what it would do. I got log4j
logging output, but I would get duplicate log entries the more times I
reloaded my app. I quickly figured out that I need to get the logger
as a static resource in whatever class wanted to log, e.g.
private static Logger logger = Logger.getLogger(servletEventListener.class);
Thanks,
--Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Classloading questions
As an experiment, I placed a file in the webapp dir of a servlet (not in WEB-INF but in the directory above it) and attempted to read it using getResource(). What I found was that I could not locate the resource unless I used getServletContext().getResource(). Reading through the Classloading How-To, I am confused why this works. The how-to says that from the perspective of the webapp, loading takes place in this order: * Bootstrap classes of your JVM * System class loader classses (described above) * /WEB-INF/classes of your web application * /WEB-INF/lib/*.jar of your web application * $CATALINA_HOME/common/classes * $CATALINA_HOME/common/endorsed/*.jar * $CATALINA_HOME/common/lib/*.jar * $CATALINA_BASE/shared/classes * $CATALINA_BASE/shared/lib/*.jar But, what is the order for getServletContext() ? To try to figure this out, I ran another experiment: ClassLoader c1 = this.getClass().getClassLoader(); log( this's classloader is + c1.getClass().getName()); ClassLoader c2 = getServletContext().getClass().getClassLoader(); log( servlet context's classloader is + c2.getClass().getName()); Results: this's classloader is org.apache.catalina.loader.WebappClassLoader servlet context's classloader is org.apache.catalina.loader.StandardClassLoader The HowTo says the following classloaders exist: * Bootstrap * System * Common * Catalina * Shared * WebappX How is that some instance of StandarClassLoader able to access the webapp root? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Class loading from within a servlet: interface definition not found
I have something happening with class loading from within a server, and I don't understand it. My servlet defines some classes called: org.something.server -- the class that extends HttpServlet org.something.DatabaseRequestHandler -- an interface When you make a request to the server, it figures out what handler class to load. Then it attempts to load it: Class handlerClass = Class.forName(handlerClassNameString); QUESTION: looking at the little diagram in the Tomcat 5.5 Class Loader HOW-TO, when I do the above (Class.forName) I am using the Webapp class loader, correct? The handler classes are all in handlers.jar which is in $CATALINA_BASE/shared/lib. The actual exception that I get is: 2006-04-28 17:05:55 StandardWrapperValve[xdb]: Servlet.service() for servlet xdb threw exception java.lang.NoClassDefFoundError: org/something/DatabaseRequestHandler It took me a few minutes to realize that this was not a ClassNotFound exception, but something else. Reading docs I figured out that the most probably cause is that the servlet's classloader was able to find the handler class, but then it failed to load one of the things it depended on, specifically it was able to find handlerClass but not the interface class that it depends on. Trouble is: the interface .class file is right there in WEB-INF/classes/com/something/DatabaseRequestHandler.class just like it should be. So, I am stumped why the class loader would be able to find the handler class in $CATALINA_BASE/shared/lib but NOT the interface that it implements which is in WEB-INF/classes. At the suggestion of a nice gentleman on freenode, I tried turning on the -verbose:class option in the jvm, and watched it log some interesting stuff to catalina.out. Unfortunately it doesn't shed any light on what is happening, beyond the exception and stack trace in the error log. I don't want to post the whole stack trace (unless someone thinks it would help to see it) but I will say that it includes catalina.loader.WebappClassLoader as well as catalina.loader.StandardClassLoader --Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: using digester from within a servlet
Frank W. Zammetti [mailto:[EMAIL PROTECTED] writes ... It looks to me like your ObjectCreate rule is incorrect... I believe the class you reference must be the fully-qualified name. That set me on the right track - thank you. My ObjectCreate rule was actually OK because I specified the Class itself, not the name of the class as a String: digester.addObjectCreate(config/xdb-config, XdbConfig.class); The other problem is that I did not do this: digester.setUseContextClssLoader(true); to tell Digester to use the right class loader. Once Digester was able to find all of the objects it had to create, it continued to blow up on my SetNext rules. The reason here was exactly what you said. I was not specifying the fully-qualified name. the addSetNext() I am using looks like: digester.addSetNext(String, String, String) /* works only if class name is fully qualified */ I wouldn't have had this problem if there were one of these: digester.addSetNext(String, String, Class) /* does not exist */ so I might recommend adding that to Digester some time in the future. Cool :-) --Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using digester from within a servlet
Hi, My goal is to use digester within a servlet, to parse a configuration file. When running within the servlet context digester is unable to find the classes specified by my rules. For example, I have this set of rules to process an element xdb-config which occurs within a config element: digester.addObjectCreate(config/xdb-config, XdbConfig.class); digester.addSetProperties(config/xdb-config, database-name, databaseName); digester.addSetNext(config/xdb-config, addXdbConfig, XdbConfig); What I get is this: Apr 23, 2006 10:21:29 PM org.apache.commons.digester.CallMethodRule setDigester SEVERE: (CallMethodRule) Cannot load class XdbConfig java.lang.ClassNotFoundException: XdbConfig I get this other places as well. One of the things I find odd is that this error occurs after the above one in the error log: Apr 23, 2006 10:21:29 PM org.apache.commons.digester.CallMethodRule setDigester SEVERE: (CallMethodRule) Cannot load class Config java.lang.ClassNotFoundException: Config Basically, the class loader seems to be able to load my classes from within my own classes, but NOT from the digester. What I don't understand is how that's possible when the required classes are clearly within the classpath; I upload them to tomcat as a .war and they are all exploded into WEB-INF/classes. I can't see how this could not be in the classpath and therefore not found by the digester. --Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
