Within Eclipse I did the following:
1) Went to New -- Dynamic Web Project
2) Selected Resin 4.0 as my Target runtime on the dialog that pops up
3) Left Default Configuration for Resin 4.0 selected under Configuration
4) Selected Generate web.xml deployment descriptor
5) On the Server tab, I
: resin-interest-boun...@caucho.com [mailto:resin-interest-
boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, September 30, 2013 3:28 PM
To: 'General Discussion for the Resin application server'
Subject: [Resin-interest] Resin 4.0.37 via Eclipse Plugin
Within Eclipse I did
In resin-4.0.35 I am spinning on a typical BufferedInputStream read loop to
read from a multipart stream. It works great, but for some reason a large
percent of the connections hang at some point on the blocked read call. I
thought that the default SocketTimeout setting in Resin would cause
and then we will
roll it out.
Thanks a bunch!
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Friday, January 18, 2013 10:09 AM
To: 'General Discussion for the Resin application server'
Subject: Re: [Resin-interest
We're getting scanned today. Any hope on this?
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, January 14, 2013 2:01 PM
To: 'General Discussion for the Resin application server'
Subject: Re
Attack
On Jan 18, 2013, at 10:18 AM, Aaron Freeman aaron.free...@layerz.com
wrote:
We're getting scanned today. Any hope on this?
I just tested that Resin snapshot - the honor-cipher-order is not in that
jar. I think there was a mistake in the SCM checkin or Scott may have built
wrote:
Hi Scott,
We need this too.
Can you try http://caucho.com/download/resin-pro-4_0-snap.tar.gz
The configuration is honor-cipher-ordertrue/honor-cipher-order in
openssl.
-- Scott
Thanks,
Keith
On 1/2/2013 1:36 PM, Scott Ferguson wrote:
On 1/2/13 11:58 AM, Aaron Freeman wrote:
We
Attack
On 1/2/13 11:58 AM, Aaron Freeman wrote:
We have now been scanned and been found to be non-compliant due to lack of
the ability to order ciphers. Is there any timeframe we might expect even
a snapshot to have this capability?
I'll see if I can get a snapshot this week.
-- Scott
/JsseSSLFactory.java
I suspect you could get it going again if you have the fortitude to play around
with Resin's source code and build your own.
Good luck,
Knut Forkalsrud
On Mon, Dec 3, 2012 at 7:53 AM, Aaron Freeman aaron.free...@layerz.com wrote:
SSL BEAST
For PCI compliance we are supposed to address the SSL BEAST attack by
prioritizing SSL cipher suites.
Any clue how to do that with JSSE? We are using JSSE because we run Resin
uncompiled. Am I correct in thinking that in order to run OpenSSL we HAVE
to compile Resin? Or is there a way to
We had that issue when using jsp:include (jsp:include content wouldn't get
UTF-8 encoded), but switching it out for c:import worked. Not sure if this
applies in your case, but if the copyright is jsp:include'd you might try to
c:import and see if you get different results. No matter what you did
We are using EclipseLink and cannot use the version that ships with
resin-4.0.x due to a bug in that version. So we are having to install resin
and then delete the jar file that's in the resin lib folder, which is less
than desirable. We really don't want to have to modify the resin install at
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 using Rein
4.0.23 and are pretty satisfied.
Has anybody been using a later version in production and development and
find it to be nice and stable?
Thanks,
Sent: Thursday, July 19, 2012 12:39 PM
To: resin-interest@caucho.com
Subject: Re: [Resin-interest] Resin 4 stability
- 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
Does Resin 4.0 have any notion of handling a situation where a large HTTP
MULTIPART POST request has come in (a large file transfer for example), and
then when one of the nodes of the cluster that is handling that MULTIPART
POST were to go offline, another node would take over with no interruption
/22/2012 11:08 AM, Aaron Freeman wrote:
Does Resin 4.0 have any notion of handling a situation where a large
HTTP MULTIPART POST request has come in (a large file transfer for
example), and then when one of the nodes of the cluster that is
handling that MULTIPART POST were to go offline
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Friday, December 09, 2011 12:19 AM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Single Signon Questions
Using Resin 4.0.23 we are trying to get single sign-on working per this
link
I hope so. Since it's new, this is a great time for feedback
For the first time, Resin 4.0.24 doesn't work out of the box when added to
Eclipse as a new server.
I go through this process pain free for each new release, but now
immediately see the message 'default' is an unknown server in
With the latest resin-pro-4.0.23 plugin we are now getting an error when
trying to start multiple instances of Resin within a single Eclipse
environment:
java.sql.SQLException: CREATE for path
'C:\opt\project\ext\resin-pro-4.0.23\resin-data\default\tmp\temp_file'
failed, because the file
-Original Message-
If you look at the new default resin.xml, it has a
resin:properties path=${__DIR__}/resin.properties
and several uses of rvar like http port=${rvar('http')}/. The
resin:properties is similar to the resin:import, but loads a properties
file
and saves the
The following password xmlns ... technique works great for database
definitions:
database
jndi-namejdbc/oracle/jndi-name
driver
typeoracle.jdbc.pool.OracleConnectionPoolDataSource/type
urljdbc:oracle:thin:@${com.database.server}:${com.database.port}:${com.dat
Of Aaron Freeman
Sent: Monday, October 17, 2011 5:09 PM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Possible Bug Fix?
In AbstractHttpRequest I am seeing that the global variable _contentLength
it appropriately a long. Love that. Been a thorn in our side
, Aaron Freeman wrote:
If there is agreement that this is a bug, and the fix can be rolled into a
snapshot, I can test further to find out where the next gotcha is with large
valued contentLengths.
Thanks. I've filed this as http://bugs.caucho.com/view.php?id=4819.
There's a little bit of a bug
Is anybody using resin:import successfully that could advise on this? I am
still struggling with it.
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, October 17, 2011 3:53 PM
To: General
4.0 Questions
On 10/19/2011 08:19 AM, Aaron Freeman wrote:
Is anybody using resin:import successfully that could advise on this? I am
still struggling with it.
You can use EL variables like
resin:import path=host-${ext}.xml/
where you've defined -Dext=foo.
Is that what you're looking
We are on the latest and greatest Resin 4.0, and would like to have a single
resin.xml file that:
1) imports host.xml, which defines:
- a keystore to use and the passwords for the keystore
2) on different servers we would like to overwrite the host.xml so we can
change:
In AbstractHttpRequest I am seeing that the global variable _contentLength
it appropriately a long. Love that. Been a thorn in our side for a long
time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
as a solution, or just to more clearly isolate the problem.
Regards
Alan
On 30/09/2011 19:49, Aaron Freeman wrote:
We are currently experiencing a problem when we restart where the
ConnectionPools to Oracle take a long time to be established and cause
a long delay for our
We are currently experiencing a problem when we restart where the
ConnectionPools to Oracle take a long time to be established and cause a
long delay for our production machine to start. It almost feels like the
old ConnectionPools have to timeout, even though we have shut the entire
Resin
I know this is obvious and I am just overlooking it, but what would be
the Resin 4.0 equivalent to the Resin 3.0
rewrite-dispatch
not-found regexp=^.*/\.svn/.*$//not-found
/rewrite-dispatch
syntax?
I don't see a resin:NotFound option. I don't want to resin:Deny because
I don't even want
On 8/9/2011 11:09 AM, Scott Ferguson wrote:
resin:SendError code=404/
Oh cool, I'll give that a go. I should have updated to teh Resin 4.0
equivalents long ago!
An interesting point ... if you still have
rewrite-dispatch.../rewrite-dispatch it can completely take
precedence over the
I could use some help on this, even if it's just a hint or some ideas
what else to try.
Thanks,
Aaron
I'd like to disabled the HTTP CONNECT method. I don't know the best
way to do that, but I tried this and it's not working:
resin:Forbidden regexp='.*'
resin:IfMethod value=CONNECT/
On 7/21/2011 12:27 PM, Scott Ferguson wrote:
On 07/20/2011 10:39 AM, Aaron Freeman wrote:
I'd like to disabled the HTTP CONNECT method. I don't know the best
way to do that, but I tried this and it's not working:
resin:Forbidden regexp='.*'
resin:IfMethod value=CONNECT/
/resin:Forbidden
On 7/21/2011 4:12 PM, Scott Ferguson wrote:
On 07/21/2011 02:01 PM, Aaron Freeman wrote:
On 7/21/2011 12:27 PM, Scott Ferguson wrote:
On 07/20/2011 10:39 AM, Aaron Freeman wrote:
I'd like to disabled the HTTP CONNECT method. I don't know the best
way to do that, but I tried this and it's
I'd like to disabled the HTTP CONNECT method. I don't know the best
way to do that, but I tried this and it's not working:
resin:Forbidden regexp='.*'
resin:IfMethod value=CONNECT/
/resin:Forbidden
The request is passed on and I receive a 200 OK response when I telnet
and test the CONNECT.
Trying this:
http://www.caucho.com/resin-4.0/reference.xtp#resinMovedPermanently
Use case: I need to do a 301 redirect for all links to http://blog.X/*
to http://www.X/blog/
I found this documentation which is very similar, but does a forward:
On 6/15/2011 3:30 PM, Scott Ferguson wrote:
On 06/15/2011 01:25 PM, Aaron Freeman wrote:
Trying this:
http://www.caucho.com/resin-4.0/reference.xtp#resinMovedPermanently
Use case: I need to do a 301 redirect for all links to http://blog.X/*
to http://www.X/blog/
I found this documentation
On 6/15/2011 4:04 PM, Scott Ferguson wrote:
On 06/15/2011 01:51 PM, Aaron Freeman wrote:
URL dispatching is owned by the virtual host. The cluster level doesn't
understand URLs, so it doesn't make sense to dispatch a URL in the
cluster level.
Does that mean the example,
http
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:
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
Is there any forum software out there that runs nicely/reliably under
Resin and/or Quercus?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
We have multiple webapps in our 4.0.16 configuration and would like to
be able make changes to our resin.xml file without causing all of the
webapps to restart.
Can we somehow disable the automatic restart after detecting a change to
the resin.xml? If we do that, we can stop/start the
conf
settings independently but at least I can test that now.
Thanks,
Aaron
On 4/7/2011 9:56 AM, Aaron Freeman wrote:
We have multiple webapps in our 4.0.16 configuration and would like to
be able make changes to our resin.xml file without causing all of the
webapps to restart.
Can we
-
http://caucho.com/resin-4.0/admin/http-rewrite.xtp#Servlet%20Filters
Header should say something like: Example: Servlet Filter
Just a copy/paste error from the example above it.
-
http://caucho.com/resin-4.0/reference.xtp#resin:SetHeader
The resin:SetHeader Attributes
So we were having all kinds of performance issues with the Resin Eclipse
plugin (which may or may not be supported, but we use it like crazy now).
The performance problem we were all having is that every time we would
change some JSP source, we would have to wait WAY too long for the JSP
to
Is there a simple way to set an applicationScope variable from within
the resin.xml?
I see how to set system properties, but I'd like something I can
reference from a JSP like:
${applicationScope.var}
Or can I reference the system properties similarly?
Thanks,
Aaron
-${applicationScope.baz}-/p
/html
Any other way to do this?
Thanks,
Aaron
On 10/20/2010 12:09 PM, Aaron Freeman wrote:
Is there a simple way to set an applicationScope variable from within
the resin.xml?
I see how to set system properties, but I'd like something I can
reference from a JSP
On 10/20/2010 12:39 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Bah I stumbled on this, but it doesn't appear to do what I was hoping:
context-param
param-namebaz/param-name
param-valuevalue/param-value
/context-param
When I tried to reference that in a test.jsp like
What version of Resin 4.0 are you using? I can reproduce this easily
on resin-pro-4.0.10 by doing this:
-- create test.jsp:
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=test2.jsp var=debug/
${debug}
--
-- create test2.jsp
%@ taglib
...at
least on OS X. It also happens for non JSPs. I have some pages that
import XSL and XML files so I can parse them with the x tag library
and those imports also fail. There is no chaining of imports that I
can see.
matt
On Oct 19, 2010, at 9:24 AM, Aaron Freeman wrote:
What version of Resin
Ah, this is excellent info.
Aaron
On 9/21/2010 12:07 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Out of curiosity, why does Resin distribute with javamail-141.jar? Is
there some built-in mailing functionality that Resin ships with? If so,
is there a URL pointing to some
This is unrelated, but worth mentioning to other people converting
over from Resin 3.0.x:
We had this problem when converting over from Resin 3.0.x.: The
problem is that Resin 4.0.x now outputs white space in each iteration of
c:forEach .../c:forEach loops, and other places where Resin
This is an error in your JSP/JSTL, not with Resin -- you are trying to
modify (add to) a HashMap that you are iterating over.
Here is a more detailed explanation:
http://forums.sun.com/thread.jspa?threadID=5335803
Aaron
On 8/19/2010 4:20 AM, Wesley Wu wrote:
Often happened at 30 seconds
Out of curiosity do you have multiple instances of Resin (separate JVMs)
running on that same virtual machine? If so do you use different ports
for the watchdog on both instances? We had a similar situation and it
was fixed by just running the watchdog on separate ports for each
instance of
I was thinking it's possible to do something like this in a php file:
?php
if((include '../www/_header.jsp') == 'OK') {
echo 'OK';
}
?
Where the www folder has a path-mapping entry in the resin.xml.
It includes the file, but the file isn't processed by the JSP
On 8/12/2010 1:36 AM, Aaron Freeman wrote:
I was thinking it's possible to do something like this in a php file:
?php
if((include '../www/_header.jsp') == 'OK') {
echo 'OK';
}
?
Where the www folder has a path-mapping entry in the resin.xml.
It includes
I saw a wiki for running WordPress under Quercus 3.1.x -- is anybody out
there successfully running WordPress under Resin 4.0.x?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
,
I am successfully running WordPress 3.0 in Resin 4.0.7. It is behind Apache
2.2 with permalinks which took a while to configure mod_rewrite but otherwise
it works great.
matt
On Aug 11, 2010, at 7:00 AM, Aaron Freeman wrote:
I saw a wiki for running WordPress under Quercus 3.1.x
Ah, I faintly remember your posts about that now. Good to know. We
will start with the latest and greatest and work our way backward
stopping at 4.0.6, if necessary. :)
Aaron
On 8/11/2010 2:03 PM, Rick Mann wrote:
On Aug 11, 2010, at 10:02:21, Matthew Serrano wrote:
Aaron,
I am
me know how it goes. I kinda wish you'd work back 'till you see the same
problem, just so we can be sure it reproduces everywhere ;-)
On Aug 11, 2010, at 13:29:04, Aaron Freeman wrote:
Ah, I faintly remember your posts about that now. Good to know. We
will start with the latest
Just wondering if anybody has ever worked through a scenario where you
could automatically firewall off an IP address that requested a
poisoned URL?
There is an attacker continuously scanning all of our servers for a
specific URL, but from several different IPs. It would be nice to be
able
Jon,
Right, so far that's been our tact. This one particular attack is a bit
annoying because it's inflating our logs.
I was just curious if this was a capability within Resin. We wouldn't
take the time to write a custom tag or anything like that to stop it.
Aaron
On 7/21/2010 10:27 AM,
-store-file/opt/. . ./keys.kdb/key-store-file
41: password xmlns:encryption=urn:java:com.encryption
42: encryption:Passwordabcdf/encryption:Password
43: /password
Thanks,
Aaron
On 3/22/2010 6:09 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
O
Man, I don't see how I am blowing it then. Does
Awesome -- also note that the exact same syntax DOES work in place of
the password in the
databasedriverpassword../password/driver/database nodes.
Aaron
On 5/28/2010 2:14 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Sorry to bump this question, but any idea if this will be fixed
: /password
Thanks,
Aaron
On 3/22/2010 6:09 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
O
Man, I don't see how I am blowing it then. Does this look right:
password xmlns:encryption=urn:java:[full package, not including the
class]
encryption:[class name]abcdefg/encryption:[class name
, Aaron Freeman wrote:
Scott,
Still struggling with the issue where we cannot encrypt passwords in
our resin.xml file. As you have indicated, there is now a better clue:
C:\opt\. . .\conf\admin.xml:41: unable to create attribute
SetterAttribute[public void
only put implementations of interfaces into the context.
Otherwise, I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
Bummer, what's the proper way to test
Yes, that's exactly right. In several instances we have many
controllers that are written in JSP (pure JSTL code), that c:import
our models (also in this case JSPs) and also c:import our views.
Works great!
The upside to it is: a) easier to code -- people with limited Java
expertise can
On 5/7/2010 5:39 PM, Jeff Schnitzer wrote:
I doublechecked the spec and the current Resin behavior is the proper
behavior. I don't think this behavior has changed in the spec, so the
old behavior was a bug. You can't use the empty operator to test for
the existence of fields (or methods).
Marco,
If you are repeating that pattern every time, it sounds more like your
_brower's_ cache being the culprit. Instead of calling:
http://my-server.com/newfolder/ with an empty folder, place the
index.html in there and _then_ call it so your browser doesn't cache up
the 404 not found
Oh, you will have to swap out the httputil with whatever you use to
URLEncode strings in order to test it.
Thanks,
Aaron
On 3/31/2010 2:46 PM, Aaron Freeman wrote:
We are experiencing a fundamental change in how data is being passed as
a jsp:param between 3.0.22 and 4.0.5. We need to know
When we try to stop the resin-4.0.5 processes using:
$JAVA_HOME/bin/java \
-server \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dhost=${SERVER} \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf
of updating the documentation this week to reflect the change.
Thanks,
Emil
On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
When we try to stop the resin-4.0.5 processes using:
$JAVA_HOME/bin/java \
-server \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl
We take some fairly lengthy queries (lengthy row based on row count),
and push the data into hashmaps in JSTL pages. After that sometimes we
evaluate the hashmap and sometimes have to redirect the request to
another page. In 3.0.23 it works with no problems. In 4.0.5 we get
:
This is why you don't put application logic into the view layer.
Before you 'push' your data into the view, figure out if you want to
do the redirect or not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We take some
to change
that dependency because you can (and should) be doing it differently.
jon
On Thu, Mar 25, 2010 at 8:18 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
It's not in the view layer. We segregate our controller JSPs from
our view JSPs. So you
Is there any documentation for using the cipher-suites tag? Instead of
explicitly listing ciphers we do want, is there a way to list
cipher-suites you want to exclude? Google isn't helping me find such an
animal, so I am guess that it's not possible?
Thanks,
Aaron
,
Emil
On Thu, Mar 25, 2010 at 02:34:33PM -0500, Aaron Freeman wrote:
Is there any documentation for using the cipher-suites tag? Instead of
explicitly listing ciphers we do want, is there a way to list
cipher-suites you want to exclude? Google isn't helping me find such an
animal, so I
Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought we would
take advantage of the resin-admin stuff. However the docs aren't clear
on how that's supposed to happen. This page says nothing about what to
install: http://caucho.com/resin-4.0/admin/resin-admin.xtp
And this page
On 3/24/2010 1:15 PM, Rick Mann wrote:
On Mar 24, 2010, at 09:07:07, Aaron Freeman wrote:
Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought we would
take advantage of the resin-admin stuff. However the docs aren't clear
on how that's supposed to happen. This page says
that we have had to add on top of resin is now part
of it.
Bill
On Wed, Mar 24, 2010 at 2:15 PM, Rick Mann rm...@latencyzero.com
mailto:rm...@latencyzero.com wrote:
On Mar 24, 2010, at 09:07:07, Aaron Freeman wrote:
Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought
we
Can you show your resin-web.xml?
The first thing that leaps out at me (and may be okay, but looks odd)
is: com.caucho.config.ConfigException:
*foo.HelloServlet.personService*:
javax.enterprise.inject.UnsatisfiedResolutionException: Can't find a
bean for 'interface *foo.PersonService*'.
Rick,
Out of curiosity did you trying running a vanilla version of 4.0.5
without compiling (using Java sockets instead of the native sockets)? I
am curious if you still have the issue with it uncompiled.
Aaron
On 3/23/2010 2:15 PM, Rick Mann wrote:
On Mar 23, 2010, at 12:10:35, Scott
On this link there is resin:IfFileExists tag, but I am thinking what
you want to do is more simple than that, if you want to elaborate:
http://caucho.com/resin-4.0/admin/http-rewrite.xtp
Aaron
On 3/21/2010 3:03 PM, Rick Mann wrote:
With my WordPress installation, I need to redirect some
19, 2010 at 5:53 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
It's working now. For completeness and to help others moving from
3.0.x
to 3.1.x or 4.0.x you should change your startup script from this
style
(which relies on a wrapper.pl
I just noticed that resin-pro-3.1.10 no longer says latest stable, or
whatever it used to say. Is 4.0.5 now considered stable and production
ready?
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
On 3/22/2010 1:11 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
This page says that I can obfuscate a password in the resin.xml file,
but doesn't appear to work. It works in 3.0.23, but stopped working in
3.1.x and 4.0.x. We use this feature, not to protect the password
doing something wrong, but it seems flaky, at best.
On Mar 22, 2010, at 11:59:33, Aaron Freeman wrote:
I just noticed that resin-pro-3.1.10 no longer says latest stable, or
whatever it used to say. Is 4.0.5 now considered stable and production
ready?
Aaron
On 3/22/2010 2:29 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Ok, so I thought what you were saying is that this:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
is a drop-in replacement for this:
password resin:type
On 3/22/2010 3:44 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Ok, here is the full http block I am using, in case its out of date for
some reason (I am using the block directly from our working 3.0.23
implementation verbatim, with your recommended tweak):
http address=* port=443
Resin version: resin-pro-3.1.9
I am trying to convert my resin-pro-3.0.23 startup scripts and
resin.conf file to work with resin-pro-3.1.9. It's close, but there is
a small error. I am trying to build a start script similar to:
$RESIN_HOME/bin/httpd.sh -verbose \
-J-server \
-J-Xmx$JAVA_MX \
It's working now. For completeness and to help others moving from 3.0.x
to 3.1.x or 4.0.x you should change your startup script from this style
(which relies on a wrapper.pl):
$RESIN_HOME/bin/httpd.sh -verbose \
-J-server \
-J-Xmx$JAVA_MX \
-J-Xms$JAVA_MS \
-J-verbose:gc \
format.
-Knut
On Tue, Dec 29, 2009 at 05:49, Aaron Freeman aaron.free...@layerz.com
mailto:aaron.free...@layerz.com wrote:
I am a bit baffled. For PCI compliance we must restrict weak ciphers,
but I see no mechanism to do that with JSSE, which we have been using
for years
Alex wrote:
I've got this, which is a slightly different but equivalent technique that
doesn't require the jvm-arg tag (applicable bits only, my startup script
does other things too):
Just for the benefit of understanding the use case: is this to support n
environments that are
I have a situation where different servers should have different
jvm-args, but I would like to have a single resin.xml.
I tried doing a resin:import on a jvm.xml file that has just jvm-args in
it, but I haven't found a combination that works. I have tried
surrounding the jvm-arg tags like
I have a situation where different servers should have different
jvm-args, but I would like to have a single resin.xml.
You should be able to achieve this by using jvm-arg inside the server
server id=a address=127.0.0.1 port=6800
jvm-arg-Dserver=A/jvm-arg
/server
server id=b
You should be able to achieve this by using jvm-arg inside the server
server id=a address=127.0.0.1 port=6800
jvm-arg-Dserver=A/jvm-arg
/server
server id=b address=127.0.0.1 port=6801
jvm-arg-Dserver=B/jvm-arg
/server
Regards,
Alex
Hmm, that's exactly what I tried first,
The excerpt below should work and it will allow you to have all the
configuration in one file.
server id=a address=127.0.0.1 port=6800
jvm-arg-Dserver=A/jvm-arg
/server
server id=b address=127.0.0.1 port=6801
jvm-arg-Dserver=B/jvm-arg
/server
Thanks Alex. My problem
Aaron,
Maybe I am missing something, but if you can pass in
-Dconfiguration=wherever to your individual machines (in your
/etc/init.d/resin script or wherever, I assume?), can't you pass in
your server specific JVM args there too?
Rachel
Probably. The configuration is passed in via
I am working with 3.1, was wondering if there is a trick to allowing
recursive resin:imports? In other words I would like to resin:import a
file from within another file that was already resin:imported.
Thanks,
Aaron
___
resin-interest mailing
1 - 100 of 134 matches
Mail list logo
