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, requiring setter to allow getter access).

We've managed some partial workarounds (such as a custom 
com.sun.faces.expressionFactory), but at this point it seems the only 
rational thing to do is to replace/override individual classes or the 
entire javax.el package (which Resin does not allow out of the box) - or 
look for another application server. I want your help to see what our 
workaround options are.

There are obviously benefits of being able to limit the workaround to 
the application, so that a WAR can include any EL updates and there is 
no special operation required per server / when upgrading Resin etc. The 
fact that the application is supposed to be hosted by a third party, 
also means we don't know if we are even allowed to make necessary 
changes to the Resin installation.

Here are the options I see so far:

A) Configure the server to include alternative EL implementation JAR 
(el-api-2.2.jar) in the classpath, preceeding Resins javaee-16.jar. This 
could be achieved by setting CLASSPATH environment variable and should 
also be possible with the <jvm-arg> tag in Resin configuration.
Drawbacks: EL cannot be updated with application, but needs separate 
update. Not sure hosting companies allow it. Probably not compatible 
with Resin IDE plugin (haven't got it working yet...), so there will be 
different configs in dev and production.

B) Patch Resins javaee-16.jar with the contents of the other EL 
implementation JAR (el-api-2.2.jar). This has been tested in dev 
environment and seems to work.
Drawbacks: EL cannot be updated with application, but needs separate 
update. Unlikely that hosting companies allow this. Needs to be done for 
every Resin upgrade (until Resin is fixed...). "Hacky".

C) Allow override of classes inside application (as of the Servlet 
spec...) by patching the Relax NG Schema of Resin configuration 
(env.rnc) and adding 
Drawbacks: Less likely that hosting companies allow this. Lead to other 
issues when testing.

D) I believe it may be possible replacing for example 
com.sun.faces.el.ELUtils.BEAN_RESOLVER constant with another 
implementation, using reflection and Apache BCEL. This way, everthing 
would be included in WAR and no special configuration needed per server.
Drawbacks: Unimplemented and untested (requires time, may not work), 
very hacky. There may be interdependencies between classes in the 
javax.el package that are broken if only single classes replaced.

Are there other options?
Flaws in the above reasoning?

Thanks in advance,



resin-interest mailing list

Reply via email to