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 <class-loader><priority-package>javax.el</priority-package>. 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, -- </Mattias> _______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
