This is my workaround for JPA 2.1 on Resin. We've had to put that
upgrade aside for a while now so it hasn't been thoroughly tested and
there may be bumps down the road, but at least this allowed us to boot :-/
/** Remove Caucho's JPA implementation Amber - included in Resin -
from the list
Duh, should have read
http://www.caucho.com/resin-4.0/admin/security-authorization.xtp to the
end...
- Original Message -
Subject: [Resin-interest] Network based security behind Apache
(X-Forwarded-For)
Date: Fri, 30 Jan 2015 08:35:14 +0100
From: Mattias Jiderhamn mj-li
Hi list. What options do I have if I want to use IP based security
behind an Apache proxy?
I want to use ip-constraint or resin:IfNetwork, but
request.getRemoteAddr() will always be the IP of the proxy, and the real
IP is in X-Forwarded-For header.
It seems I cannot put a Servlet filter in
My request to update the bundled JPA API to 2.1, or at least extract the
JAR for easy replacement (http://bugs.caucho.com/view.php?id=5678) was
turned down with reference to the server-default / jvm-classpath
config option.
I have finally gotten around to trying this, with the Hibernate JPA
I have a couple of outstanding issues in Mantis (that I have not posted
about on the mailing list), that seems to have gotten no attention from
Caucho at all. The oldest one is almost 5 months.
Actually, I'm getting the impression that the development of Resin has
slowed down considerably in
Hi list. It seems that Resin will load and initiate Servlet 3.0
web-fragment.xml before it loads and initiates any .tld files -
including listeners therein - within the same .jar.
This results in the AutoProbe module of
http://messadmin.sourceforge.net/ causing exceptions, because it
Hi list. It seems that Resin will load and initiate Servlet 3.0
web-fragment.xml before it loads and initiates any .tld files -
including listeners therein - within the same .jar.
This results in the AutoProbe module of
http://messadmin.sourceforge.net/ causing exceptions, because it assumes
Has the Caucho Maven repo moved from http://caucho.com/m2 to somewhere else?
Or has it simply not been updated in a year and a half (latest version
is 4.0.30)? In the latter case - why...?
--
/Mattias
___
resin-interest mailing list
Since http://bugs.caucho.com/ is down currently, I'm posting this bug here.
When running Resin 4.0.37 under Windows, I am getting problem with the
same extension being loaded twice by
com.caucho.config.extension.ExtensionManager. The reason for this is
that in the EnumerationURL e on line 133
Resin ships with Hibernate Validator. I'm trying to figure out whose
responsibility is it to make the ValidatorFactory exposed in JNDI as
java:comp/ValidatorFactory.
What we are really trying to do is using JSF 2.2 with Resin, and then
Bean Validation is disabled since JSF is unable to find
On Thu, 18 Jul 2013 10:51:52 -0700 Scott wrote:
On 7/18/13 10:29 AM, Mattias Jiderhamn wrote:
On Thu, 18 Jul 2013 09:42:23 -0700 Scott wrote:
On 7/18/13 2:32 AM, Mattias Jiderhamn wrote:
It seems that a classloader leak in the JSF API as of
https://java.net/jira/browse/JAVASERVERFACES
On Thu, 18 Jul 2013 09:42:23 -0700 Scott wrote:
On 7/18/13 2:32 AM, Mattias Jiderhamn wrote:
It seems that a classloader leak in the JSF API as of
https://java.net/jira/browse/JAVASERVERFACES-2746 is triggered much
more
easily by the Caucho EL implementation than with the Sun/Glassfish
We use JAI in one of our web apps. Have you set system properties
java.awt.headless=true and java.awt.headlesslib=true ...?
(Btw, for full performance, you should install JNI binaries. Thought
that wouldn't be 100% Java either. And I haven't tried it.)
/Mattias
- Original Message -
Is it possible to completely disable deployment archiving as described
on http://www.caucho.com/resin-4.0/admin/deploy.xtp?
Or at least disable the undocumented(?) automatic rollback?
Background: We made some configuration changes that seemed to work fine,
but turned out to be invalid. Trying
I have noticed that System.getenv() behaves differently on our different
Linux servers.
When running stand-alone Java applications there is no issue, but on at
least one server the environment variables are inherited from the
watchdog process to the Resin process, and on others they are not.
I have reported a classloader / memory leak that I believe Scott tried
to fix for 4.0.33. Haven't had time to verify yet though.
Then add this library to your web app, to get rid of third party leaks:
Any news on the 4.0.33 release?
/Mattias
--- Original Message -
Subject: Re: [Resin-interest] 4.0.33 ETA?
Date: Thu, 22 Nov 2012 10:17:29 -0500
From: Paul Cowan co...@caucho.com
On Nov 22, 2012, at 2:46 AM, Mattias Jiderhamn wrote:
Hi. We are anticipating the upcoming 4.0.33 release
Hi. We are anticipating the upcoming 4.0.33 release that should resolve
a couple of our bugs. What is the ETA?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Without having had time to look into it further, I'm wondering if anyone
else has seen these exceptions moving from Resin 4.0.29 to 4.0.30 (same
problem with 4.0.31 for us)? Any workaround?
Caused by: java.io.NotSerializableException:
com.caucho.el.MethodExpr$MethodCall
at
What is the current recommended approach for remote deploying from
Hudson/Jenkins to recent Resin versions (4.0.29+)?
It looks like the resin-maven-plugin [1] (which may have been
preferable) has been abandoned? Latest version is 4.0.17 and does not
seem to be working.
Is command line deploy
We're in the process of setting up a new server and have installed Resin
4.0.29 from RPM. We have made minimal changes to the config to get up
and running, and are facing an issue we haven't seen on any other Resin
installation: When a .war is redeployed it seems the contents of the new
.war
- Original Message -
Subject: [Resin-interest] javax Validation provider change between
4.0.23 and 4.0.30?
Date: Tue, 28 Aug 2012 03:42:24 -0700
From: Rick Mann rm...@latencyzero.com
I just built a new webapp that uses javax Validation. It works on my
local machine with 4.0.30, but
- Original Message -
Subject: [Resin-interest] Resin 4 stability
Date: Thu, 19 Jul 2012 09:53:47 -0500
From: Aaron Freeman aaron.free...@layerz.com
I just want to query the user community for what seems to be the most
stable
version of resin 4.0 out there? We have been developing and
After a long debugging detour, I realized that response header of my JSF
pages is set to
Content-Type: text/html; charset=ISO-8859-1
while the content itself is UTF-8.
I don't quite understand what sets ISO-8859-1 and why (although
admittedly url-character-encoding is set to it).
What is
Don't bother - that turned out to be the detour...
/Mattias
- Original Message -
Subject: [Resin-interest] Set JSF response encoding
Date: Wed, 27 Jun 2012 20:26:54 +0200
From: Mattias Jiderhamn mj-li...@expertsystems.se
After a long debugging detour, I realized that response header
- Original Message -
Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
Date: Wed, 20 Jun 2012 13:30:26 -0700
From: Scott Ferguson f...@caucho.com
On 06/19/2012 02:18 PM, Scott Ferguson wrote:
On 06/19/2012 01:13 AM, Mattias Jiderhamn wrote:
- Original Message
- Original Message -
Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
Date: Fri, 15 Jun 2012 11:29:12 +0200
From: Mattias Jiderhamn mj-li...@expertsystems.se
- Original Message -
Subject: Re: [Resin-interest] JNI timeout on multipart forms in 4.0.28
I'm really glad Resin 4.0.28 is here since it resolves multiple issues
we've been having lately. However, it seems a new critical issue may
have been introduced since 4.0.25.
When running on 64-bit Linux, compiled with --enable-64bit and
--enable-ssl, and posting a multipart/form-data form
- Original Message -
Subject: Re: [Resin-interest] Out of PermGen space
Date: Fri, 27 Apr 2012 11:23:41 +0200
From: Mattias Jiderhamn mj-li...@expertsystems.se
I should also mention, that I have an open bug report on Resin 4.0.27
which seems to cause classloader leaks.
http
On 05/29/2012 12:27 PM, Mattias Jiderhamn wrote:
- Original Message -
Subject: Re: [Resin-interest] Out of PermGen space
Date: Fri, 27 Apr 2012 11:23:41 +0200
From: Mattias Jiderhamnmj-li...@expertsystems.se
I should also mention, that I have an open bug report on Resin 4.0.27
- Original Message -
Subject: Re: [Resin-interest] Override EL implementation (help us stay
with Resin)
Date: Mon, 23 Apr 2012 08:31:33 +0200
From: Mattias Jiderhamn mj-li...@expertsystems.se
...
I reported http://bugs.caucho.com/view.php?id=5034 (which has a very
easy workaround
Hi Rick.
After having had these issues for years, I started blogging about it and
how to find classloader leaks [1]. I also compiled a list of API calls
and third party libraries known to trigger these leaks [2], and as you
can see, it is quite common both to cause these problems yourself and
We have been using Resin for 10+ years, mostly very satisfied, but as we
are now working with JSF we've had numerous problems related to Resin.
Most of the problems are caused by Resins implementation of EL (not
resolving parameters, not being able to call a method defined in a super
class,
- Original Message -
Subject: Re: [Resin-interest] Override EL implementation (help us stay
with Resin)
Date: Mon, 16 Apr 2012 09:08:23 -0700
From: Scott Ferguson f...@caucho.com
On 04/16/2012 03:47 AM, Mattias Jiderhamn wrote:
We have been using Resin for 10+ years, mostly very
Hi. For multipart String parameters, Resin returns a UTF-8 encoded
stream from javax.servlet.http.Part.getInputStream() without regards to
request.getCharacterEncoding().
I cannot find whether the UTF-8 encoding is stipulated by the spec, or
if this is a Resin bug.
Anyone knows...? Reference?
Is there a way to change the priority / order of classloaders on
different levels? The class-loader config tag claims to do this, but it
seems to me it only affects the order within the current level (such as
WEB-INF/classes vs WEB-INF/lib), and not classes already loaded by a
higher level
to other issues...).
Is there any reason for this feature to be disable, or could the schema
be update in the next release?
/Mattias
- Original Message -
Subject: [Resin-interest] Change classloader precedence / priority / order
Date: Thu, 12 Jan 2012 15:40:49 +0100
From: Mattias Jiderhamn mj
There is a need for us to start few threads as soon as Resin starts up.
You can use load-on-startup for a servlet that starts these threads in
its init().
In web.xml:
servlet servlet-name='app-init-servlet'
servlet-class='servlet.that.starts.YourThreads'
load-on-startup/
/servlet
--
As I am anticipating an end to our class loader leaks, I'm trying out
remote deployments again, and they do seem to be working in 4.0.18 - yay!
However, once I have remote deployed to a server, Resin will no longer
pick up .war files dropped locally in the webapps directory on that
server. Or
To answer one part of your question:
Additionally the application is started as root and for the app tier we
use user and group to change the user. When we try to do the same
thing in the web-loadbalancer tier the application fails to start. Is
this normal/to be expected? Is it safe for the
message for this :-)
I'm happy to be back on Resin though.
Jeff
On Wed, Jun 8, 2011 at 12:26 AM, Mattias Jiderhamn
mj-li...@expertsystems.se wrote:
Jeff, is it possible that there is something strange about the WAR file
itself, like the compression...?
May I ask how the WAR is created
Jeff, is it possible that there is something strange about the WAR file
itself, like the compression...?
May I ask how the WAR is created?
Have you compared checksums between where it is created and where it is
deployed so it isn't messed up in some transfer?
/Mattias
Jeff Schnitzer wrote
We're still seeing this issue at random under 4.0.18 :-(
http://bugs.caucho.com/view.php?id=4290
/Mattias
Scott Ferguson wrote (2010-11-17 18:50):
Mattias Jiderhamn wrote:
Scott Ferguson wrote (2010-11-12 18:01):
Mattias Jiderhamn wrote:
Since upgrading to Resin 4.0.10 this error has turned
Sounds like a file permission issue, but you've checked that, haven't
you...?
/Mattias
- Original Message -
Subject: [Resin-interest] Resin no longer deploys my war
Date: Tue, 24 May 2011 01:52:04 -0700
From: Jeff Schnitzer j...@infohazard.org
I tried upgrading to 4.0.18 recently and
Schnitzer j...@infohazard.org
It does sound like that, but I'm running Resin as root.
Jeff
On Tue, May 24, 2011 at 1:56 AM, Mattias Jiderhamn
mj-li...@expertsystems.se wrote:
Sounds like a file permission issue, but you've checked that, haven't
you...?
/Mattias
- Original Message
Scott Ferguson wrote (2011-04-05 01:25):
On 04/04/2011 10:02 AM, Mattias Jiderhamn wrote:
Scott Ferguson wrote (2011-04-04 18:47):
On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote:
While evaluating Resin 4.0.16 we are seeing something that makes me
really concerned. It appears as if after
While evaluating Resin 4.0.16 we are seeing something that makes me
really concerned. It appears as if after a redeploy there can be two
instances of our main app running.
I was made aware of this by noticing that timed servlets (run-at ...
/) were having concurrency issues and logging the
Scott Ferguson wrote (2011-04-04 18:47):
On 04/04/2011 12:43 AM, Mattias Jiderhamn wrote:
While evaluating Resin 4.0.16 we are seeing something that makes me
really concerned. It appears as if after a redeploy there can be two
instances of our main app running.
I was made aware
By default Resin 4 uses Hessian for serialization of session data.
Hessian tries to traverse uninitialized Hibernate associations by
reflection, causing LazyInitializationException when serializing.
For that reason, we are using Java serialization instead of Hessian for
session data.
Here is
After upgrading to Resin 4.0.15/16, there is a new virutal host (or
whatever it is) in the WebApps section of the admin console, that I've
never noticed before.
The name is http://admin.resin; and it contains only a root webapp
(/) with an uptime as long as Resin has been running.
What is
I just noticed that installing Resin on Linux using
./configure ... --without-resin-init.d --prefix=/path-to-use; make;
make install
does not update the admin console pages in /path-to-use/admin
Could this be related to the problem with the docs dir reported by Bill
Au yesterday
Giving the resin-deploy Ant task another try in Resin 4.0.16, I get
resin-home is requried by resin-deploy
Adding a resin-home attribute to the resin-deploy tag as in
resin-deploy server=foo.com port=80
warfile=${war.file.path}
user=foo password=bar
Have you tried without versioning=true?
--
/Mattias
- Original Message -
Subject: [Resin-interest] ROOT.war not expanded when explicitly defined
in resin.xml
Date: Mon, 21 Mar 2011 17:03:31 -0700
From: Keith Fetterman kfetter...@go2marine.com
I am experiencing a problem in resin
Scott Ferguson wrote (2011-03-02 18:10):
On 03/02/2011 02:53 AM, Mattias Jiderhamn wrote:
We're looking forward to upgrading from 4.0.10 to 4.0.15, but during
testing we notice 4.0.15 takes way longer to boot our application.
Results on different machines range from twice the time to 4-5 times
We're looking forward to upgrading from 4.0.10 to 4.0.15, but during
testing we notice 4.0.15 takes way longer to boot our application.
Results on different machines range from twice the time to 4-5 times as
long. It seems that the Spring/Hibernate initialization is taking most
of the time
Never got an answer so I posted a bug at
http://bugs.caucho.com/view.php?id=4301
/Mattias
Mattias Jiderhamn wrote (2010-11-18 10:20):
Has anyone been able to run Hudson [1] on Resin 4.0.12...?
It's running just fine on 4.0.10, but when accessing the main page /
context root under 4.0.12
Has anyone been able to run Hudson [1] on Resin 4.0.12...?
It's running just fine on 4.0.10, but when accessing the main page /
context root under 4.0.12, a directory listing of the root of the WAR is
sent with Content-Type application/octet-stream
Accessing sub pages, such as /manage, seems to
Scott Ferguson wrote (2010-11-12 18:01):
Mattias Jiderhamn wrote:
Since upgrading to Resin 4.0.10 this error has turned up now and then in
our log files, however we have sofar been unable to reproduce it ourselves.
Could it be a Resin bug...?
java.lang.IllegalStateException: getWriter
Since upgrading to Resin 4.0.10 this error has turned up now and then in
our log files, however we have sofar been unable to reproduce it ourselves.
Could it be a Resin bug...?
java.lang.IllegalStateException: getWriter() can't be called after
getOutputStream().
at
)
at
com.caucho.hessian.io.Hessian2Output.writeObject(Hessian2Output.java:421)
at
com.caucho.hessian.io.UnsafeSerializer$ObjectFieldSerializer.serialize(UnsafeSerializer.java:293)
Am I still doing something wrong???
/Mattias
Scott Ferguson skrev:
Mattias Jiderhamn wrote:
After
Scott Ferguson wrote (2010-08-31 18:54):
Mattias Jiderhamn wrote:
Trying to launch Resin 4.0.10 on Windows with the -server-root /
-server_root / -root-directory / --root-directory but resin.exe seems to
ignore all of them. Is there an undocumented change, or is there a bug
in resin.exe
(I am not by far a *nix wizz, nor the admin of our production servers,
so please bear with me)
Historically we have edited the /etc/init.d/resin script to customize
the Resin startup, such as setting the server root directory or
assigning CPU cores with taskdef.
In the 4.0.x branch this file
Trying to launch Resin 4.0.10 on Windows with the -server-root /
-server_root / -root-directory / --root-directory but resin.exe seems to
ignore all of them. Is there an undocumented change, or is there a bug
in resin.exe in the 4.0.10 (pro) release?
--
/Mattias
):
Depends on the version of Unix you are on exactly. I customized the
init script quite a bit, so I don't use the one which ships with
Resin. Which version/distribution are you using? I can share the one
I use if you'd like.
-jk
On Tue, Aug 31, 2010 at 4:10 AM, Mattias Jiderhamn
mj-li
the
startup scripts with /sbin/sysconfig
-jk
On Tue, Aug 31, 2010 at 8:38 AM, Mattias Jiderhamn
mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote:
We are on RedHat Enterprise Linux 4/5.
Note that the question is not the configuration itself, but
*where
That's about what I had.
However geronimo-javamail_1.4_spec-1.6.jar seemed unnecessary, plus I
added spring.jar (3 MB) to config the services, but maybe Resin CanDI
works just as well?
/Mattias
Riccardo Cohen wrote (2010-07-22 11:14):
Ooops ... it actually works all right with lib/soap/
/Mattias
Mattias Jiderhamn wrote (2010-04-23 16:17):
Turned on finest logging. This could possibly be related.
[2010-04-23 16:13:34.097] com.caucho.hessian.io.HessianFieldException:
com.caucho.server.admin.DeployCommitListQuery._commitList: expected
string at end of file
...
Mattias
I thought I'd try out remote deployment but the documentation is a bit
inconsistent.
According to http://www.caucho.com/resin/admin/deploy.xtp there should
be a resin:RemoteDeploy/ tag in the configuration, however this tag is
not mentioned at http://blog.caucho.com/?p=134 and does not seem to
)
at
com.caucho.hessian.io.UnsafeDeserializer$ObjectFieldDeserializer.deserialize(UnsafeDeserializer.java:417)
... 14 more
Mattias Jiderhamn wrote (2010-04-23 16:05):
I thought I'd try out remote deployment but the documentation is a bit
inconsistent.
According to http://www.caucho.com/resin/admin/deploy.xtp there should
This part of the install document may also be helpful:
http://caucho.com/resin-4.0/admin/starting-resin-install.xtp#Creating%20a%20password%20for%20the%20Resin%20Administration%20Console
Best,
Emil
On Fri, Apr 16, 2010 at 09:46:33AM +0200, Mattias Jiderhamn wrote:
I feel like a newbie
Last week we saw a whole bunch of these exceptions. Removing
resin_data_default.db and resin_mnode_default.db and restarting Resin
removed the problem, but possibly there is something there that needs
attention.
java.lang.IllegalStateException
at
Scott Ferguson wrote (2010-01-13 18:07):
Mattias Jiderhamn wrote:
Scott, I notice that in com.caucho.hessian.server.HessianSkeleton
there are lots of out.close() but no out.flush(). Could unflushed
buffers be what is causing this?
At least then difference in output size could explain why
environment.
(There is a 200 status in the server log regardless of the result on the
client and the size of the response is about 200 kB)
/Mattias
Mattias Jiderhamn wrote (2010-01-08 21:24):
I was able to see the error myself today. It occurs within 3 seconds
from the Hessian call, so I doubt
-16 15:56):
Mattias Jiderhamn wrote:
Nope - standalone Resin.
It would be a different issue. This looks like a timeout issue, while
the previous one was a protocol problem.
On the server side, are you seeing any timeout of that connection? Or
does changing the socket-timeout avoid
We are seeing a lot of Connection reset with Hessian since the upgrade
of our production environment to 4.0.2 (both client and server). Would
this be related to the problems already reported against 4.0.2 and thus
fixed in the snapshot?
Caused by: com.caucho.hessian.io.HessianFieldException:
Nope - standalone Resin.
/Mattias
Wesley Wu wrote (2009-12-16 11:10):
If u'r using apache or other web server backended by resin instead of
running resin standalone, I think the 1202 snapshot should fix this
issue.
2009/12/16 Mattias Jiderhamn mj-li...@expertsystems.se:
We are seeing
One theory is that it is the last date you may purchase a renewal,
before you have to buy a new license?
/Mattias
Rob Lockstone wrote (2009-12-15 22:18):
I see in our resin license file a version-expire-date tag and an
expire-date tag.
The version-expire-date tag corresponds to the date
Scott, can you tell me whether you've been able to reproduce this scenario?
/Mattias
Mattias Jiderhamn wrote (2009-12-11 08:34):
Scott Ferguson wrote (2009-12-11 00:23):
Mattias Jiderhamn wrote:
So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our
Mattias Jiderhamn wrote (2009-12-11 08:34):
I should mention though, that there is still a minimum of two
EnvironmentClassLoaders for the given application after reloading at
least once. The former one seem to stick around somehow. We have
discussed this before, Scott; how references are kept
So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our application and/or Resin.
I made a new discovery which shouldn't be an issue, but could
potentially fix problems.
From my investigation it seems that whenever the application is
reloaded, a reference to the
Scott Ferguson wrote (2009-12-11 00:23):
Mattias Jiderhamn wrote:
So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our application and/or Resin.
I made a new discovery which shouldn't be an issue, but could
potentially fix problems.
From my investigation
Resin 4.0.2 can now be found on the download page, and for anyone else
wondering, the syntax to use Java session serialization seems to be like
this:
session-config
...
serialization-typejava/serialization-type
/session-config
Mattias
Mattias Jiderhamn wrote (2009-10-14 08:55
Alex wrote (2009-11-24 06:01):
Hello,
we try to do the following on our php/EJB3 application :
• find a given client from its lastname using a stateless bean ()
• load his orders using the getter
[code]
$clients = $client_eao-findBySample($sample_client,false,false);
I have been asking myself the same question...
Jeff Schnitzer wrote (2009-10-28 00:41):
This is really just a point of curiosity...
What editor are you guys using at Caucho? I've noticed all the code
is formatted using a bizarre combination of tabs and spaces, like
this:
1 indent = 4
Given your previous posts I assume you've just upgraded from 3.0 and in
that case, you need to make sure the WEB-INF/work directory is cleared
so JSPs can be compiled by the new Resin version.
/Mattias
- Original Message -
Subject: [Resin-interest] NoSuchMethodError
Date: Thu, 1 Oct
Is there any setting which would allow Resin to silently ignore
connections that cause the following error?
com.caucho.server.dispatch.BadRequestException: HTTP/1.1 requires host
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:261)
at
I think you need to make sure you are using an SSL connection
(request.isSecure()) before you create the Cookies in the first place.
The behaviour when changing a non-secure cookie to a secure one may be
browser dependant.//
//
/Mattias
//
//Abhinav Gupta wrote (2009-09-10 14:34):
Thanks Jeff,
After about a week with Resin 4.0.1 in production environment, we have
twice seen symptoms indicating that a value implementing
HttpSessionBindingListener has been removed from a session, without its
valueUnbound() method being called.
Has anyone else seen this?
Are there any circumstances where
http://docs.jboss.org/hibernate/stable/core/reference/en/html/transactions.html#transactions-basics-apptx
Jon Stevens wrote (2009-08-26 21:48):
You put Hibernate objects into the session?
jon
On Wed, Aug 26, 2009 at 8:37 AM, Mattias Jiderhamn
mj-li...@expertsystems.se mailto:mj-li
:05 AM, Mattias Jiderhamn
mj-li...@expertsystems.se mailto:mj-li...@expertsystems.se wrote:
http://docs.jboss.org/hibernate/stable/core/reference/en/html/transactions.html#transactions-basics-apptx
Jon Stevens wrote (2009-08-26 21:48):
You put Hibernate objects into the session
In Resin 4 persistent-store type=file seems to use Hessian for
serializing the session values.
This causes some trouble for us since Hessian in some cases tries to
access uninitialized Hibernate collections after the session/transaction
is closed.
Is there a way to revert Resin 4 to the old
What happened to the min-free-memory config tag in Resin 4? Still
available? Where to put it?
--
/Mattias
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Emil Ong wrote (2009-08-20 17:28):
On Thu, Aug 20, 2009 at 05:21:45PM +0200, Mattias Jiderhamn wrote:
What happened to the min-free-memory config tag in Resin 4? Still
available? Where to put it?
Hi Mattias,
It has changed to memory-free-min.
Which, for the record, is a child
Is there a way to make Resin not try interpreting EL expressions in JSP
pages (while still using fast jstl)?
We have custom tags with string attributes which are evaluated as EL
expressions using the Apache Taglibs implementation. After updating to
4.0, Resin refuses to treat these attributes as
Hessian was extracted to a separate hessian.jar in the Resin dist a
while back, which made it possible to upgrade Hessian without changing
Resin version.
For some reason hessian was moved back into resin.jar.
/Mattias
Scott Ferguson wrote (2009-06-18 00:16):
On Jun 17, 2009, at 2:10 PM, Rick
Scott Ferguson wrote (2009-06-05 18:11):
On Jun 3, 2009, at 10:59 PM, Mattias Jiderhamn wrote:
Done a bit more debugging and I have arrived at
com.caucho.server.distcache.FileCacheManager.put() which does nothing
but return null!?
Should persistent-store type=file work at all...?
Yikes
Scott Ferguson wrote (2009-06-03 23:52):
On Jun 3, 2009, at 1:08 PM, Mattias Jiderhamn wrote:
Scott Ferguson wrote (2009-06-03 21:17):
Can you check the permissions, particularly of the resin-data
directory? We had some trouble at the end of the release cycle with
permissions issues
My initial testing indicates that the leak indeed has been fixed in 4.0!
I'll have to get back on this once I have our real application up and
running in 4.0
/Mattias
Mattias Jiderhamn wrote (2009-04-02 11:23):
Scott Ferguson wrote (2009-03-30 18:20):
On Mar 30, 2009, at 3:54 AM, Mattias
Scott Ferguson wrote (2009-06-02 07:23):
On Jun 1, 2009, at 9:48 PM, Mattias Jiderhamn wrote:
Sitting here trying to upgrade the dev environment to Resin 4.0 with
minimal changes to configuration and startup scripts.
On Windows I'm up and running after a strange problem with a simple
I wrote on resin.conf = null when upgrading to Resin 4 (2009-06-02
06:48):
Sitting here trying to upgrade the dev environment to Resin 4.0 with
minimal changes to configuration and startup scripts.
On Windows I'm up and running ...
I apparently jumped the gun here. I am not up and running on
1 - 100 of 151 matches
Mail list logo
