Re: [Resin-interest] Override EL implementation (help us stay with Resin)
- Original Message - Subject: Re: [Resin-interest] Override EL implementation (help us stay with Resin) Date: Mon, 23 Apr 2012 08:31:33 +0200 From: Mattias Jiderhamn mj-li...@expertsystems.se ... I reported http://bugs.caucho.com/view.php?id=5034 (which has a very easy workaround) and http://bugs.caucho.com/view.php?id=5035 (which should be no problem in production, but make development much less effective; trivial to fix so I trust it to be in the next release) Thanks. Unfortunately I was able to reproduce this one too: http://bugs.caucho.com/view.php?id=5039 This one is a bit more annoying, since the workaround requires adding dummy setters everywhere the bug is hit. And here is another one: http://bugs.caucho.com/view.php?id=5061 Seems like an easy fix. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Override EL implementation (help us stay with Resin)
On 04/17/2012 12:40 PM, Mattias Jiderhamn wrote: - Original Message - Subject: Re: [Resin-interest] Override EL implementation (help us stay with Resin) Date: Mon, 16 Apr 2012 13:12:15 -0700 From: Scott Ferguson f...@caucho.com 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. Well, I feel like a n00b after having realized the most severe problems we're actually caused by the fact that a team member (who is running JBoss locally) had set com.sun.faces.expressionFactory parameter to com.sun.el.ExpressionFactoryImpl. So there was a mixture of two implementations. Sorry for blaming Resin! *blush* After changing the setting to com.caucho.el.ExpressionFactoryImpl (or rather a proxy using com.caucho.el.ExpressionFactoryImpl if present), the problems turning are much less severe. I reported http://bugs.caucho.com/view.php?id=5034 (which has a very easy workaround) and http://bugs.caucho.com/view.php?id=5035 (which should be no problem in production, but make development much less effective; trivial to fix so I trust it to be in the next release) Thanks. I do want to ask, why Resin is using a custom EL implementation rather than the Sun implementation? Performance? Licensing? Historically licensing and performance. -- Scott In case there is good reason to stick with custom implementation, and the above two bugs are fixed, I guess http://bugs.caucho.com/view.php?id=5011 can be closed. -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Override EL implementation (help us stay with Resin)
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-loaderpriority-packagejavax.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 resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Override EL implementation (help us stay with Resin)
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 thejvm-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-loaderpriority-packagejavax.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
Re: [Resin-interest] Override EL implementation (help us stay with Resin)
- Original Message - Subject: Re: [Resin-interest] Override EL implementation (help us stay with Resin) Date: Mon, 16 Apr 2012 09:08:23 -0700 From: Scott Ferguson f...@caucho.com 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. 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) 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? /Mattias 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 thejvm-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-loaderpriority-packagejavax.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
Re: [Resin-interest] Override EL implementation (help us stay with Resin)
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 /Mattias 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 thejvm-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-loaderpriority-packagejavax.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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
