On 04/16/2012 12:30 PM, Mattias Jiderhamn wrote:

I'm sorry if http://bugs.caucho.com/view.php?id=5011 is misphrased. I'm still a bit of a newbie on the JEE 6+ stack.

I thought javaee-16.jar only contained repackaged standard API:s. Are you saying it contains Caucho specific implementations of these API:s, javax.el.BeanELResolver in particular...? (The fact that standard API interfaces such as javax.servlet.http.HttpServletRequest and javax.transaction.UserTransaction have a Caucho licensing header in the Resin source dist makes it harder to see what is standard and what isn't)

They're standard APIs with our implementation.

In most cases, those APIs are just interfaces. In some cases like the EL, the specification puts implementation in those jars. (Personally, I don't like those APIs, since I don't think spec jars should have much functionality.)

Anyway, when javaee-16.jar/javax/el is replaced with Maven dep javax.el/el-api/2.2 the problems were gone, so therefore I assumed the repackaging was based on a pre 2.2 version and Resin was not to blame for the bugs per se.

But what you are saying is, that our best bet is to report each separate bug against Resin, and hope to see them fixed in the next version?

Correct. Fixing those bugs are generally pretty simple, because they're fairly small in functionality.

-- Scott


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 mailing list

Reply via email to