On 04/16/2012 03:47 AM, Mattias Jiderhamn wrote: > 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).
Hmm. I'd assumed you were talking about the draft for JavaEE 7, because the bug report says "update EL to 2.2" (and not remembering the exact bug report number.) Instead of reporting specific bugs against Resin's implementation (which we can fix), you're asking for it to be replaced? That's backwards. Am I understanding this right? I'd put it on a low priority, because I thought you were asking for early draft implementation of JavaEE 7, not bugs against JavaEE 6 (because your requests weren't described as JavaEE 6 bugs.) -- Scott > > 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, > _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
