I assume that the specific issue is when Trinidad is using the ExternalContext 
as an api to hide Servlet vs. Portlet differences BEFORE the FacesContext is 
created.  In these cases, Trinidad needs to create concrete ExternalContext 
implementations for Servlets and Portlets.  An example of this are the 
Configurators that abstract away ServletFilters.  Other frameworks may not have 
tis functionality, but regardless JSF 2.0 and JSF 2.1 have api 
incompatibilities that I believe are illegal for minor releases.

-- Blake Sullivan

On Oct 30, 2013, at 4:12 PM, Gerhard Petracek wrote:

> hi blake,
> 
> many other libs don't have an issue with using the std. wrapper approach (+ 
> ExternalContextWrapper).
> -> without concrete details we can't follow, since ExternalContextWrapper was 
> introduced for keeping libs as stable/compatible as possible (across spec. 
> revisions).
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 2013/10/30 Blake Sullivan <blake.sulli...@oracle.com>
> That's only if you are wrapping another ExternalContext.  If you need to 
> create an ExternalContext out of thin air, then any new abstract methods are 
> a problem.  Essentially, the JSF specification made an incompatible api 
> change between JSF 2.0 and 2.1.
> 
> -- Blake Sullivan
> 
> On Oct 30, 2013, at 3:49 PM, Gerhard Petracek wrote:
> 
>> @ExternalContext:
>> there shouldn't be an issue due to ExternalContextWrapper.
>> 
>> in any case +1 for the rest.
>> 
>> regards,
>> gerhard
>> 
>> http://www.irian.at
>> 
>> Your JSF/JavaEE powerhouse -
>> JavaEE Consulting, Development and
>> Courses in English and German
>> 
>> Professional Support for Apache MyFaces
>> 
>> 
>> 
>> 2013/10/30 Scott O'Bryan <darkar...@gmail.com>
>> Gerhard and Devs,
>> 
>> The problem is there was some 2.1 stuff added to the ExternalContext I 
>> believe.  At any rate, I agree with you and I've managed to free up some 
>> free time to get a release.  So here is what I suggest:
>> 
>> 1) I'm going to begin the release of the Trinidad plugins.  With voting this 
>> should give us a couple of days to get the main trinidad 2.1 release where 
>> we want it.
>> 
>> 2) I'm hearing concerns about some of the functionality, so while the 
>> Trinidad Plugin release is underway, let's try and figure out which 
>> uncomiited community patches are out there and should make this release.  
>> Getting help from you guys on which bugs are important would be a huge help 
>> because there is a lot in our bug queue and it would take me a long time to 
>> sort everything out.
>> 
>> 3) I've already fixed Gerhard's issue he raised below.  You're 100% right, 
>> this shouldn't have happened.  There is a slight build with the Jenkins 
>> sanity and I'm taking a look at that now, but the snapshots are building 
>> fine.
>> 
>> 4) Let's get through this release and then we'll talk about future steps 
>> once the release is complete.
>> 
>> Sounds like a plan?
>> -- 
>> Scott O'Bryan
>> 
>> On October 30, 2013 at 7:59:38 AM, Gerhard Petracek 
>> (gerhard.petra...@gmail.com) wrote:
>> 
>>> you
>> 
> 
> 

Reply via email to