Re: [Resin-interest] Sending log4j logs to the web apps log folder
Consider this another vote for a possible switch to using SLF4j as the Resin
logging interface. It's a very thin API that is an extremely powerful
aggregator of log information.
(*Chris*)
On Fri, Apr 2, 2010 at 12:57 PM, Jeff Schnitzer j...@infohazard.org wrote:
I'm pretty sure that it's possible to configure any possible
combination of input loggers and output destinations by mixing and
matching the various components of SLF4J.
To get log4j output to java.util.logging, you could use the
log4j-slf4j bridge, then use the slf4j output module that dumps to
java.util.logging. There's no configuration, you just pick which jar
files you include in your project. In this case it would be:
slf4j-X.X.X.jar (the base jar)
log4j-over-slf4j-X.X.X.jar (the bridge)
slf4j-jdk14-X.X.X.jar (the output module)
Just add these jars to your project (leave out the log4j jar) and I'm
pretty sure that you'll find all log4j output sent to the resin
logger.
Jeff
On Fri, Apr 2, 2010 at 12:43 PM, Scott Ferguson f...@caucho.com wrote:
Jon Stevens wrote:
I use this class to do JDK- commons-logging (which could either be
modified to go directly to log4j or, just through CL and then to
log4j)...
I think he needs the other way around, from log4j to java.util.logging
(?)
By the way, in Resin 4.0.6 you'll be able to do the same thing with
resin xmlns=...
system
logger name= level=
mypkg:JDKLogHandler xmlns=urn:java:org.mycom.mypkg
levelall/level
/mypkg:JDKLogHandler
/logger
/system
I'm not sure setting the Logger level to all would be a good idea,
though, because Logger.isLoggable() would always return true, which
would harm performance somewhat.
(The system is just to ensure it's configured in the system
classloader context, since resin is a child of the system loader. And
at some point I need to look into providing an adapter to log4j handlers
so you can configure log4j handlers as a java.util.logging handler
directly in Resin.)
-- Scott
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.logging.Handler;
import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.LogRecord;
import java.util.logging.Logger;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* Writes JDK log messages to commons logging.
*
* @see http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging;
*/
public class JavaLoggingToCommonLoggingRedirector
{
static JDKLogHandler activeHandler;
/**
* Activates this feature.
*/
public static void activate()
{
try
{
Logger rootLogger = LogManager.getLogManager().getLogger();
// remove old handlers
for (Handler handler : rootLogger.getHandlers())
{
rootLogger.removeHandler(handler);
}
// add our own
activeHandler = new JDKLogHandler();
activeHandler.setLevel(Level.ALL);
rootLogger.addHandler(activeHandler);
rootLogger.setLevel(Level.ALL);
// done, let's check it right away!!!
Logger.getLogger(JavaLoggingToCommonLoggingRedirector.class.getName()).info(
activated: sending JDK log messages to Commons Logging);
}
catch (Exception exc)
{
LogFactory.getLog(JavaLoggingToCommonLoggingRedirector.class).error(activation
failed, exc);
}
}
public static void deactivate()
{
Logger rootLogger = LogManager.getLogManager().getLogger();
rootLogger.removeHandler(activeHandler);
Logger.getLogger(JavaLoggingToCommonLoggingRedirector.class.getName()).info(dactivated);
}
protected static class JDKLogHandler extends Handler
{
private MapString, Log cachedLogs = new ConcurrentHashMapString,
Log();
private Log getLog(String logName)
{
Log log = this.cachedLogs.get(logName);
if (log == null)
{
log = LogFactory.getLog(logName);
this.cachedLogs.put(logName, log);
}
return log;
}
@Override
public void publish(LogRecord record)
{
Log log = this.getLog(record.getLoggerName());
String message = record.getMessage();
Throwable exception = record.getThrown();
Level level = record.getLevel();
if (level == Level.SEVERE)
{
log.error(message, exception);
}
else if (level == Level.WARNING)
{
log.warn(message, exception);
}
else if (level == Level.INFO)
{
log.info http://log.info(message, exception);
}
else if (level == Level.CONFIG)
{
log.debug(message, exception);
}
else
{
log.trace(message, exception);
}
}
@Override
public void flush()
{
// nothing to do
}
@Override
public void close()
{
// nothing to do
}
}
}
On Fri, Apr 2, 2010 at 12:14 PM, Scott Ferguson f...@caucho.com
mailto:f...@caucho.com wrote:
Stargazer wrote:
If I have an entry in log4j.properties like this
log4j.rootCategory=DEBUG, Console, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
Re: [Resin-interest] Shutdown Issues
I definitely don't know for sure, but that strikes me as a duplicate jar
problem. You might look at what new jars were introduced in 4.0.14 and see
if you are duplicating any of them in your WEB-INF/lib directory.
(*Chris*)
On Thu, May 26, 2011 at 7:49 AM, Aaron Freeman aaron.free...@layerz.comwrote:
I have tried each version, starting with 4.0.18 and going back, and the
shutdown problem begins with resin-pro-4.0.14 and up. I noticed this on
the change log for version 4.0.14:
resin: CLI added deploy, undeploy, list, start-webapp, stop-webapp,
restar-webapp commands (#4316, rep by Patrick Brigger)
So I am guessing either the functionality changed in that version and I
don't know how to upgrade my resin.xml properly. Or there is some issue
in that version and up with just doing a simple shutdown from the
command line (on a Linux system)?
Thanks,
Aaron Freeman
On 5/26/2011 4:29 AM, Aaron Freeman wrote:
Starting with resin-4.0.16 and persisting with Resin-4.0.18 we can no
longer shutdown the Resin process properly. When I attempt to do so I
get this:
-
Resin/4.0.18 can't shutdown watchdog at 127.0.0.1:10080.
com.caucho.bam.RemoteConnectionFailedException:
BamError[type=cancel,group=remote-connection-failed,
text=Cannot connect to http://127.0.0.1:10080/hmtp
java.io.IOException: Unexpected response HTTP/1.1 500 Internal Server
Error
html
titleServer Error/title
body
h1Server Error/h1
pThe server is temporarily unavailable due to an
internal error. Please notify the system administrator
of this problem./p
precode
Date: 2011-05-26T09:04:56.897+00:00
/code/pre
p /hr /
small
Resin/4.0.18
Server: 'default'
/small
/body/html
---
The jvm log didn't output anything, but when I dump the
watchdog-manager.log I get the clue below. I Googled and found a
reference to adding the sec:AdminAuthenticator, which I tried to get
working, but I could never get the below error to go away.
I am really not thinking I should have to modify our current resin.xml
to simply shutdown the Resin process properly, and perhaps the below
message is misleading?
Currently to shut down resin we are issuing a kill on the non-watchdog
Resin process, which isn't a feel good.
Here is the watchdog-manager.log:
[2011/05/26 03:55:37.854] {http://127.0.0.1:10080-1}
HmtpServlet[WebApp[production/webapp/admin.resin/ROOT]] requires an
active com.caucho.security.Authenticator because HMTP messaging requires
authenticated login for security. In the resin.xml, add an
sec:AdminAuthenticator
[2011/05/26 03:55:37.857] {http://127.0.0.1:10080-1}
javax.enterprise.inject.AmbiguousResolutionException: Too many beans
match, because they all have equal precedence. See the @Stereotype and
enable tags to choose a precedence. Beans:
SingletonBean[Authenticator, {@Default(), @Any()}]
SingletonBean[Authenticator, {@Default()}]
for InjectManager[web-app:production/webapp/admin.resin/ROOT]
at
com.caucho.config.inject.InjectManager.ambiguousException(InjectManager.java:2593)
at
com.caucho.config.inject.InjectManager.resolve(InjectManager.java:1766)
at
com.caucho.config.inject.InjectManager.getReference(InjectManager.java:2101)
at
com.caucho.hemp.servlet.ServerAuthManager.init(ServerAuthManager.java:76)
at com.caucho.remote.HmtpServlet.init(HmtpServlet.java:132)
at javax.servlet.GenericServlet.init(GenericServlet.java:70)
at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:1351)
at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:1199)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:98)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:156)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:792)
at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
at
com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
at
com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
at
com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
at
com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81)
at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67)
at
[Resin-interest] Slow Alarm bug... It's baaaaack!
I just installed 4.0.19 and I'm seeing lots of slow alarm's just like are
mentioned in bug
http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=4291 is there a way
to work around this but, or should I back off and try 4.0.18? If there's
anything you need to help solve this problem, just let me know. Thanks.
(*Chris*)
[11-06-19 22:03:01.512] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[
WebAppExpandDeployGenerator[null]]] 239429ms
[11-06-19 22:03:01.513] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[WebAppExpandDeployGenerator[null]]] 238655ms
[11-06-19 22:03:01.514] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[WebAppExpandDeployGenerator[null]]] 238290ms
[11-06-19 22:03:01.514] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[com.caucho.network.listen.TcpSocketLinkListener$SuspendReaper@17991de
1]] 215443ms
[11-06-19 22:03:01.514] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[com.caucho.http.log.AccessLog@595780d9]] 215181ms
[11-06-19 22:03:01.514] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[SessionManager[]]] 215026ms
[11-06-19 22:03:01.963] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[DeployControllerAlarm[null]]] 215316ms
[11-06-19 22:03:01.963] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[DeployControllerAlarm[null]]] 215287ms
[11-06-19 22:03:01.963] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[SessionManager[/resin-admin]]] 215287ms
[11-06-19 22:03:01.963] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[ConnectionPool[jdbc/resin]]] 215210ms
[11-06-19 22:03:01.964] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[DeployControllerAlarm[null]]] 214899ms
[11-06-19 22:03:01.964] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[DeployControllerAlarm[null]]] 214899ms
[11-06-19 22:03:01.965] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[DeployControllerAlarm[null]]] 214900ms
[11-06-19 22:03:01.965] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
larm[alarm[DeployControllerAlarm[null]]] 214900ms
[11-06-19 22:03:01.965] {CoordinatorThread[]-2} CoordinatorThread[] slow
alarm A
and so on... for hours.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] non-serializable type errors in logs for Resin 4
Basically everything that is put into the session must be Serializable is you have the distributable/ element in web.xml. If you don't have that setting then it shouldn't be required. (*Chris*) On Sep 23, 2011 4:00 AM, Alan Wright alan.wri...@athenesystems.com wrote: Hi We are in the process of migrating from Resin 2 to Resin 4.0.22 We are seeing errors like the following in the logs: SessionImpl[aaauOtLVNFKQddEwiHvkt,] attribute 'cadb' value is non-serializable type 'com.athene.jaffa.beans.BusinessDocSettingsBean' What is the change in Resin 4 that causes this where it was not an issue under Resin 2? Do we need all our beans to implement the Serializable interface for Resin 4? Thanks Alan -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
Well, yes and no. As I understand the problem, it really got bad around the Java 5 timeframe because of the addition of Enumerations to the language. What Resin does (and all auto-reloading Java containers do) is to create a ClassLoader that contains all the code for your application. When it senses a change to your code, it loads that new code into a brand new ClassLoader and releases the old one to be garbage collected once it's done processing it's active requests. The problem is that, since Enumerations are guaranteed to work with the == operator, even when serialized/deserialized between different computers, Java treats them special, by keeping them in the Permanent Generation (so their internal ID's won't change). Unfortunately, each time the app is loaded a new set of Enumerations takes up more space in the precious PermGen until it finally blows its lid. So, theoretically, you could use less PermGen by limiting Enumeration use, but that's really not a realistic response. Before Java became property of Oracle, there was some talk about fixing this problem at the JVM level, but I haven't heard anything in quite a while. (*Chris*) On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann rm...@latencyzero.com wrote: When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.35 works great locally on OS X, slightly busted on Rackspace Ubuntu 12.04
Check your web.xml. You're probably sending /* or /service/* to your servlet, which means YOU have to handle serving the CSS files. If you'd rather let Resin handle those, try using /*.jsp or /service/*.jsp (or something more specific to your situation). (*Chris*) On Mon, Apr 8, 2013 at 8:08 PM, Rick Mann rm...@latencyzero.com wrote: On Apr 8, 2013, at 19:52 , Rick Mann rm...@latencyzero.com wrote: I see that in app-default.xml, it has: servlet-mapping url-pattern=/ servlet-name=resin-file default=true/ Can I change that to *.css and *.js, etc? So, the answer appears to be no. Not sure how it is that *.jsp is handled but *.css isn't. -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Rewriting hostnames across webapps?
Wouldn't adding (stage\.)? to each host-alias-regexp and changing the host-name to regexp allow it to work as you want it? For example: host regexp=(stage\.)?latencyzero.com root-directory=/lz/var/www/ com/latencyzero host-alias-regexp^tycho.(stage\.)?latencyzero.com[\.]?$/host- alias-regexp host-alias-regexp^(www\.)?(stage\.)?latencyzero.com[\.]?$/host- alias-regexp web-app id=/ document-directory=www/webapp /host On Fri, Jan 17, 2014 at 3:18 PM, Rick Mann rm...@latencyzero.com wrote: On Jan 17, 2014, at 06:05 , Paul Cowan co...@caucho.com wrote: On Jan 16, 2014, at 4:32 PM, Rick Mann rm...@latencyzero.com wrote: I'm trying to update a virtual server that runs a handful of webapps in Resin. The old machine was tycho.latencyzero.com and a bunch of DNS entries point to it. The web apps are configured to respond to those varying hostnames. The new machine temporarily has the name stage.latencyzero.com. I copied everything from the old machine to the new, including the resin config file. Obviously, I can't just go to stage.latencyzero.com, because resin has no idea which webapp I really want. Is there any way to configure resin to rewrite a request with a host like foo.bar.latencyzero.com.stage.latencyzero.com into a request for the webapp that responds to foo.bar.latencyzero.com, while keeping the actual hostname intact for the purposes of rendering links in the pages, etc.? Hi Rick, I'm not exactly understanding what you want to do, but it sounds like I a similar situation I had on one of my sites. This configuration below is what I used. The new real host is listed first in resin.xml, then the default host id= with host-alias * will catch all, and the redirect regex will redirect to the new site while appending the requested URI. host id=foo root-directory=hosts/foo host-alias-regexp.*foo.com/host-alias-regexp … /host host id= root-directory=hosts/default host-alias*/host-alias web-app id=/ root-directory=webapps/ROOT resin:Redirect regexp=(.*) target=http://www.foo.com$1/ resin:Redirect regexp=(.*) target=https://www.foo.com$1; resin:IfSecure value=true/ /resin:Redirect /web-app /host Hope this helps, Hmm, not sure. Basically, I have entries in resin.xml on machine tycho.latencyzero.com like this: host host-name=latencyzero.com root-directory=/lz/var/www/com/latencyzero host-alias-regexp^tycho.latencyzero.com [\.]?$/host-alias-regexp host-alias-regexp^(www\.)?latencyzero.com [\.]?$/host-alias-regexp web-app id=/ document-directory=www/webapp /host host id=comics\.roderickmann\.org\.? root-directory=/lz/var/www/org/roderickmann/comics host-namecomics.roderickmann.org/host-name web-app id=/ document-directory=./webapp /host host host-name=www.roderickmann.org root-directory=/lz/var/www/org/roderickmann/www host-alias-regexp^(www\.)?roderickmann.org [\.]?$/host-alias-regexp host-alias-regexp^(www\.)?rickmann.org[\.]?$/host-alias-regexp web-app id=/ document-directory=./webapp /host host host-name=mgfb.roderickmann.org root-directory=/lz/var/www/org/roderickmann/mgfb host-alias-regexp^mgfb\.roderickmann.org [\.]?$/host-alias-regexp host-alias-regexp^blog\.roderickmann.org [\.]?$/host-alias-regexp web-app id=/ document-directory=./webapp /host I have DNS entries for all of the above that are all CNAMEs to tycho.latencyzero.com. I want to move all of those apps to a new machine (upgrading hardware and OS), but I want to test it first. The machine is called stage.latencyzero.com, and I need to make new DNS entries for each webapp (perhaps adding stage to each name, or something). The most straightforward thing would be simply to modify each name to add stage to them, but then when I decide to make the new machine permanent, and change all the old DNS entries to point to the new IP address, I'd have to modify the entries. Or I could simply add host-aliases for all the new names. But I was hoping there'd be a trick so that I only have to modify one line, and each of the host entries would pick it up. I realize that might require me to modify all the entries once (as you did with your redirects). But once I do this once, it should work for similar changes in the future. One thing I need to preserve: if I'm hitting one of my webapps through the new name (e.g. stage.mgfb.roderickmann.org or whatever), when code in the webapp uses the host name to render URIs, it needs to use that same hostname, so that links point to the right place, and not back to the old instance. All this discussion, of course, has taken longer than it would have to simply modify the entries a couple times, but I was curious. Thanks, Rick
Re: [Resin-interest] [Resin] Resin 4 and Java 8
Nope just tried it out and it worked just fine. (*Chris*) On Tue, Mar 24, 2015 at 2:14 PM Maria Elena ringmeiste...@gmail.com wrote: On Tue, Mar 24, 2015 at 5:40 PM, Chris Pratt thechrispr...@gmail.com wrote: Yes, I have it working just fine on Java 8. But, I can't seem to get it working with the new JPA 2.1 (from Hibernate 4.3). (*Chris*) On Tue, Mar 24, 2015, 8:28 AM Maria Elena ringmeiste...@gmail.com wrote: Hello, has anyone tried using Resin 4 on Java 8? I only found documentation about Java 6 (Oracle site) and Java 7 (Caucho site). Thanks and regards Maria Elena -- PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x34977A00 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest Hi Chris, many thanks for your reply! Did you find any resource (e.g. link, wiki page) about Resin 4 experience with Java 8 or you installed just from scratch? Thanks and regards Maria Elena -- PGP Public key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x34977A00 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
