Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 64207 invoked from network); 1 Dec 2009 23:03:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Dec 2009 23:03:53 -0000 Received: (qmail 30480 invoked by uid 500); 1 Dec 2009 23:03:52 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 30396 invoked by uid 500); 1 Dec 2009 23:03:52 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 30388 invoked by uid 99); 1 Dec 2009 23:03:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 23:03:52 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sethfromaustria@gmail.com designates 209.85.220.228 as permitted sender) Received: from [209.85.220.228] (HELO mail-fx0-f228.google.com) (209.85.220.228) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Dec 2009 23:03:49 +0000 Received: by fxm28 with SMTP id 28so4517734fxm.25 for ; Tue, 01 Dec 2009 15:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=20JJGLqlcFkKYzHSCTB76yABkT3wU0kxmkQGyq2E3v0=; b=K5G7gowC5GaVVXaXY8XIOsEzuwAc6pn3gqMxTKVo4+0sv7bnKETiGZdRdmSad8Gs9r tEuf/DwPAFUPO9UNIYTcvHDhXY0JOjmTc7jf0g2eKWnxzhavQh+fvv9sx/D7giUOhBy8 xBe89SppsynCXiO55fauVPkU5TpzDqAA2FCiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=QtvF4IVTDARteR6D8k5T047qeQtruybu/+uIkNFdGgEfsM/BkQnhBY9cWlzkaUxq8p FR5NLRfAtULg5BMLPjVORr456Qn230wjZfrgf9E10b/pscbYS+wR9pH69rBKEoQX0fpo kHYPiMWSmPcX39c4lylMlzVflReYvD1vgRgyc= MIME-Version: 1.0 Sender: sethfromaustria@gmail.com Received: by 10.103.144.22 with SMTP id w22mr2238124mun.52.1259708608311; Tue, 01 Dec 2009 15:03:28 -0800 (PST) In-Reply-To: References: <4B158F43.1020909@nc.rr.com> <9E2F7B24-33AF-43F5-849C-B806C40B9DF4@gmail.com> Date: Wed, 2 Dec 2009 00:03:28 +0100 X-Google-Sender-Auth: d2d0d0971fa51d84 Message-ID: Subject: Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner) From: Jakob Korherr To: MyFaces Development Content-Type: multipart/alternative; boundary=0016e65b548c1e71540479b2c407 --0016e65b548c1e71540479b2c407 Content-Type: text/plain; charset=UTF-8 I'd also prefer 2) Regards, Jakob Korherr 2009/12/2 Leonardo Uribe > > > 2009/12/1 Matthias Wessendorf > > >> >> Sent from my iPod. >> >> >> On 01.12.2009, at 22:48, Michael Concini wrote: >> >> I need some help with the best way to handle updating the dummy >>> request/response objects that we use for system event listeners kicked off >>> when there isn't a request context. Currently, we're implementing >>> ServletRequest and ServletResponse directly. This is broken when using a >>> servlet 3.0 runtime though since we're not implementing the new methods >>> added by the servlet 3.0 spec. >>> I tried already updating the classes to extend the request/response >>> wrapper classes, but that turned out to be problematic since the constructor >>> requires a request/response object to be passed. Since we don't have access >>> to that as we're outside of a request I hit an NPE try to use FacesContext >>> that wasn't there. >>> I've come up with a couple of potential solutions on this and would like >>> some input as to the best way to go. >>> >>> 1) We could also extend the wrapper classes, but add a no-arg constructor >>> to the dummy classes that would just call super(null). This would be fine >>> in most cases, but if an application tried to call any of the new >>> ServletContext methods from Servlet 3.0 we'd get an NPE instead of a runtime >>> exception (not ideal) >>> >>> 2) We can simply add the new methods from the Servlet 3.0 API to our >>> dummy classes. I think as long as we don't include the @Override annotation >>> it should build and run in either a 2.5 or 3.0 environment. >>> >> >> I think I like that. We should test 2.5 env >> >> -Matthias >> >> > I like number 2 too, because it keeps things simple. > > Leonardo Uribe > > >> >> 3) We could implement a dynamic proxy to handle the calls. Would be a >>> little more complex to implement, but might be the most elegant solution. >>> Not fully sure if there are performance implications here though. >>> Personally, I'd lean towards (2), I'd like to here from Werner as well >>> since he was the one that initially implemented this. Any additional >>> feedback from others in the community is of course welcome. >>> >>> Thanks, >>> Mike >>> >> > --0016e65b548c1e71540479b2c407 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd also prefer 2)

Regards,

Jakob Korherr

2009/12/2 Leonardo Uribe <lu4242@gmail.com>


2009/12/1 Matthias Wessendorf <mwe= ssendorf@gmail.com>



Sent from my iPod.


On 01.12.2009, at 22:48, Michael Concini <mconcini@gmail.com> wrote:

I need some help with the best way to handle updating the dummy request/res= ponse objects that we use for system event listeners kicked off when there = isn't a request context. =C2=A0Currently, we're implementing Servle= tRequest and ServletResponse directly. =C2=A0This is broken when using a se= rvlet 3.0 runtime though since we're not implementing the new methods a= dded by the servlet 3.0 spec.
I tried already updating the classes to extend the request/response wrapper= classes, but that turned out to be problematic since the constructor requi= res a request/response object to be passed. =C2=A0Since we don't have a= ccess to that as we're outside of a request I hit an NPE try to use Fac= esContext that wasn't there.
I've come up with a couple of potential solutions on this and would lik= e some input as to the best way to go.

1) We could also extend the wrapper classes, but add a no-arg constructor t= o the dummy classes that would just call super(null). =C2=A0This would be f= ine in most cases, but if an application tried to call any of the new Servl= etContext methods from Servlet 3.0 we'd get an NPE instead of a runtime= exception (not ideal)

2) We can simply add the new methods from the Servlet 3.0 API to our dummy = classes. =C2=A0I think as long as we don't include the @Override annota= tion it should build and run in either a 2.5 or 3.0 environment.

I think I like that. We should test 2.5 env

-Matthias


I like number 2 too, because it keeps things simple.

Leonardo Uribe
=C2=A0

3) We could implement a dynamic proxy to handle the calls. =C2=A0Would be a= little more complex to implement, but might be the most elegant solution. = =C2=A0Not fully sure if there are performance implications here though.
Personally, I'd lean towards (2), I'd like to here from Werner as w= ell since he was the one that initially implemented this. =C2=A0Any additio= nal feedback from others in the community is of course welcome.

Thanks,
Mike


--0016e65b548c1e71540479b2c407--