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
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] 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] 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] 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
[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] 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
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