Definitely not a big issue if it is not on the next release, at least there is a simple workaround if that causes a problem. (and it went unnoticed for quite some time obviously as it is a somewhat peculiar el usage in 2.2)
-- stephane On Tue, Mar 5, 2013 at 2:33 PM, Jesse McConnell <[email protected]>wrote: > ok, I quite doubt it can clear IP and all that by the next set of releases > but the next ones it should be definitely doable > > thanks for the feedback > > jesse > > -- > jesse mcconnell > [email protected] > > > On Tue, Mar 5, 2013 at 1:31 PM, Stephane Bailliez <[email protected]>wrote: > >> Just to confirm, we are all good with 2.2.4. So you can go ahead with the >> IP process. >> >> >> On Tue, Mar 5, 2013 at 9:41 AM, Stephane Bailliez <[email protected]>wrote: >> >>> Hi Jan, >>> >>> Tests so far have been ok on a limited scope, we're putting it through >>> its pace in the next couple few minutes and should have a canary in >>> production following that. I should have some more concrete news in the >>> next few hours and will let you know (and will update jira accordingly) >>> >>> -- stephane >>> >>> >>> On Tue, Mar 5, 2013 at 12:55 AM, Jan Bartel <[email protected]> wrote: >>> >>>> Stephane, >>>> >>>> Any luck with testing the newer jars?? We're coming up to a release >>>> and I'd like to get this sorted out as soon as possible ... >>>> >>>> thanks >>>> Jan >>>> >>>> On 28 February 2013 05:46, Stephane Bailliez <[email protected]> >>>> wrote: >>>> > Hi Jesse, >>>> > >>>> > Thanks for the reply. >>>> > >>>> > I went digging a little bit around, found that the javax.el-api 2.2.4 >>>> source >>>> > code seems to have that particular problem fixed in the sense they >>>> don't >>>> > cache the classes but rather they just lazily instantiate the factory >>>> > statically only once in BeanELResolver. So different fix than the one >>>> in >>>> > Tomcat land but that should fix our problem. We'll going to test that >>>> > version. Will let you know. >>>> > >>>> > Available at >>>> > >>>> http://search.maven.org/#artifactdetails%7Cjavax.el%7Cjavax.el-api%7C2.2.4%7Cjar >>>> > It's that same version that is shipped with Glassfish 3.1.2.2 as far >>>> as I >>>> > can see. >>>> > >>>> > -- stephane >>>> > >>>> > >>>> > On Wed, Feb 27, 2013 at 11:40 AM, Jesse McConnell >>>> > <[email protected]> wrote: >>>> >> >>>> >> we take the javax.el stuff from the jasper setup that glassfish uses, >>>> >> think there is a jsp project for it at java.net now a days for it >>>> (this one >>>> >> I think: http://jsp.java.net/) >>>> >> >>>> >> as for quick fix...we can look at updating the versions but between >>>> >> getting it into the CQ process and then orbitifying it is anywhere >>>> from a 1 >>>> >> week to 4 month process, which is why are are noticeably slow >>>> updating that >>>> >> :/ >>>> >> >>>> >> If updating to the tomcat one works for you then that is definitely >>>> the >>>> >> best short term solution. In the meantime the correct process here >>>> it to >>>> >> open a bug in bugzilla under RT/Jetty component with details so we >>>> can start >>>> >> the update process >>>> >> >>>> >> I'll note that you should be able to test updated jsp artifacts from >>>> the >>>> >> glassfish jsp setup by replacing them and seeing how they >>>> work...giving us >>>> >> an idea of what version resolves your problem will help >>>> >> >>>> >> cheers, >>>> >> jesse >>>> >> >>>> >> -- >>>> >> jesse mcconnell >>>> >> [email protected] >>>> >> >>>> >> >>>> >> On Wed, Feb 27, 2013 at 10:31 AM, Stephane Bailliez < >>>> [email protected]> >>>> >> wrote: >>>> >>> >>>> >>> I opened a few minutes ago: >>>> >>> >>>> >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=401916 >>>> >>> >>>> >>> This is obviously causing significant performance impact and affect >>>> >>> scaling, the only quick alternative I see would be to replace >>>> temporarily >>>> >>> the orbit javax.el version with the one from tomcat. >>>> >>> Short of that working would be to patch the orbit el code. >>>> >>> >>>> >>> This might seem a bit of a stretch as I'm not sure what is the >>>> >>> significant difference without doing a diff between the 2 source >>>> codes. I'll >>>> >>> have a look at that soonish, in the meantime I was wondering: >>>> >>> >>>> >>> Is there any significant difference in the codebase that you know >>>> of ? >>>> >>> From where is coming the repackaged orbit: javax.el >>>> 2.2.0.v201108011116 ? >>>> >>> >>>> >>> Do you see a possible release with updated version of it "soonish" ? >>>> >>> >>>> >>> Thanks ! >>>> >>> >>>> >>> -- stephane >>>> >>> >>>> >>> _______________________________________________ >>>> >>> jetty-users mailing list >>>> >>> [email protected] >>>> >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>> >>> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> jetty-users mailing list >>>> >> [email protected] >>>> >> https://dev.eclipse.org/mailman/listinfo/jetty-users >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > jetty-users mailing list >>>> > [email protected] >>>> > https://dev.eclipse.org/mailman/listinfo/jetty-users >>>> > >>>> >>>> >>>> >>>> -- >>>> Jan Bartel <[email protected]> >>>> www.webtide.com – Developer advice, services and support >>>> from the Jetty & CometD experts. >>>> >>> >>> >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
