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,
>
