Re: [Resin-interest] Resin 4.0 Questions
Moreover, if you are separating things per server, you already have the
server.id EL variable to play with.
For example, we use it to define different home directories per server
instante:
web-app id=/ root-directory=${resin.home}/webapps/${server.id}//
so...
resin:import path=host-${server.id}.xml/
or something like that should work fine.
S!
D.
El 19/10/2011 19:44, Aaron Freeman escribió:
Oh geez, that’s so obvious. * smack myself *
Thanks,
Aaron
*From:*resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] *On Behalf Of *Scott Ferguson
*Sent:* Wednesday, October 19, 2011 11:46 AM
*To:* resin-interest@caucho.com
*Subject:* Re: [Resin-interest] Resin 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 for?
-- Scott
Thanks,
Aaron
*From:*resin-interest-boun...@caucho.com
mailto: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 Discussion for the Resin application server
*Subject:* [Resin-interest] Resin 4.0 Questions
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:
- host aliases
- reference a different keystore
- add additional host sections
Is all of this possible with resin:import, or is it not possible to pull
this off?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible Bug Fix?
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,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf 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 for a long
time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
int contentLength = 0;
int ch;
int i = 0;
int length = value.length();
for (;
i length (ch = value.charAt(i)) = '0' ch = '9';
i++) {
contentLength = 10 * contentLength + ch - '0';
}
if (i 0)
_contentLength = contentLength;
}
The method is internally using an int, so the values get truncated or
wrapped to negative values. Internally I believe that method should use a
long for the local contentLength variable.
This should help prevent HttpRequest from incorrectly throwing this for
request larger than 2GB (which is what the user community would see in their
logs if they are dumping exceptions):
throw new com.caucho.server.dispatch.BadRequestException(POST
requires content-length);
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible Bug Fix?
On 10/20/2011 08:25 AM, 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 backlog, so it'll probably be another week
or two.
-- Scott
Thanks,
Aaron
*From:*resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] *On Behalf 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 for a long time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
int contentLength = 0;
int ch;
int i = 0;
int length = value.length();
for (;
i length (ch = value.charAt(i)) = '0' ch = '9';
i++) {
contentLength = 10 * contentLength + ch - '0';
}
if (i 0)
_contentLength = contentLength;
}
The method is internally using an int, so the values get truncated or
wrapped to negative values. Internally I believe that method should
use a long for the local contentLength variable.
This should help prevent HttpRequest from incorrectly throwing this
for request larger than 2GB (which is what the user community would
see in their logs if they are dumping exceptions):
throw new com.caucho.server.dispatch.BadRequestException(POST
requires content-length);
Thanks,
Aaron
___
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] Possible Bug Fix?
Okidoke, no problem.
- Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson
Sent: Thursday, October 20, 2011 11:58 AM
To: resin-interest@caucho.com
Subject: Re: [Resin-interest] Possible Bug Fix?
On 10/20/2011 08:25 AM, 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 backlog, so it'll probably be another week or
two.
-- Scott
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf 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 for a long
time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
int contentLength = 0;
int ch;
int i = 0;
int length = value.length();
for (;
i length (ch = value.charAt(i)) = '0' ch = '9';
i++) {
contentLength = 10 * contentLength + ch - '0';
}
if (i 0)
_contentLength = contentLength;
}
The method is internally using an int, so the values get truncated or
wrapped to negative values. Internally I believe that method should use a
long for the local contentLength variable.
This should help prevent HttpRequest from incorrectly throwing this for
request larger than 2GB (which is what the user community would see in their
logs if they are dumping exceptions):
throw new com.caucho.server.dispatch.BadRequestException(POST
requires content-length);
Thanks,
Aaron
___
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] It seems resin 4.0.x does not implement Unified EL 2.2 properly
Hi Scott,
I used to bundle JUEL 2.1.x in my webapp and it run fine with resin 4.0.x.
After I upgrade to JUEL 2.2.3, some of the el expressions in jsp file
threw exceptions.
The error method invocation expressions is like:
${myBean.myMethod()}
it will produce
javax.el.MethodNotFoundException: Cannot find method 'myMethod' in
'class mypackage.MyBean'
I replaced java.el package in RESIN_HOME/lib/javaee16.jar with the
same package content in juel-2.2.3.jar
then everything went fine.
So I guess the implementation of java.el in resin maybe is conformed
to the EL 2.1 spec but not the EL 2.2 one.
I looked at the source of resin el implementation and found
java.el.CompositeELResolver did not implemented the
public Object invoke(ELContext context, Object base, Object method,
Class?[] paramTypes, Object[] params);
method which was added since EL 2.2.
any thoughts?
--
Wesley Wu
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] It seems resin 4.0.x does not implement Unified EL 2.2 properly
On 10/20/2011 11:59 AM, Wesley Wu wrote:
Hi Scott,
I used to bundle JUEL 2.1.x in my webapp and it run fine with resin 4.0.x.
After I upgrade to JUEL 2.2.3, some of the el expressions in jsp file
threw exceptions.
The error method invocation expressions is like:
${myBean.myMethod()}
it will produce
javax.el.MethodNotFoundException: Cannot find method 'myMethod' in
'class mypackage.MyBean'
I replaced java.el package in RESIN_HOME/lib/javaee16.jar with the
same package content in juel-2.2.3.jar
then everything went fine.
So I guess the implementation of java.el in resin maybe is conformed
to the EL 2.1 spec but not the EL 2.2 one.
I looked at the source of resin el implementation and found
java.el.CompositeELResolver did not implemented the
public Object invoke(ELContext context, Object base, Object method,
Class?[] paramTypes, Object[] params);
Yep. It's bug with CompositeELResolver. I've filed it as
http://bugs.caucho.com/view.php?id=4820
-- Scott
method which was added since EL 2.2.
any thoughts?
--
Wesley Wu
___
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
