In short the issue is this. Trinidad uses a response wrapper during a
ppr to set the content type. The theory is that this wapper won't allow
the content type to be changed (ie. setContentType is effectively
disabled) and getContentType always returns the expected AJAX content
type. When JSF does a forward to the JSP, this content type can never
get changed so even though the forward allows the JSP to set the new
content type, the wrapper object prevents this. This works in every
container except WLS... I'm not sure what version, I just know it
doesn't work on 10.
WLS for some reason is doing something wonkey here. It ignores the
content type set on this wrapper. Not only that, even if we set the
content type to our expected value the first time setContentType is
called, it still doesn't work. The workaround we found was to, every
time setContentType was called, actually set the expected content type
rather then what was passed in.
It should be a pretty straight forward fix, it's just not as clean as I
would like.
Scott
Francisco Passos wrote:
Yes, I can tell you every version up to 1.0.6 or 1.0.7 would not allow
me to get proper PPR. I just kept trying until one version fixed that
and did not introduce any other bugs, since this was an application
already at a very advanced state, nearly in production.
Our Weblogic is 9.2.2 on a Unix machine, but I can run it successfully
locally on Windows with Weblogic 9.2.1. <http://9.2.1.>
I hope this information helps you. Good luck!
Francisco
On 6/12/08, *Sandor Nemeth* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
thanks for replay!
I did a lot of test with it and in the end i tried to deploy the
Trinidad's own demo app can be downloaded from Trinidad site. And
PPR doesn't work neither in the demo app. Exactly what I noticed,
that the tr:table component range navigation (next, previous
links) and detail facet (show detail, hide detail, Show all
details, Hide all details links) doesm't work. The logging shows
that the server side actions performed, but the screen is not
refreshed. Sometimes after an exact page refresh (F5) the desired
screen displayed (next or previous range, displayed detail, etc).
And i would emphasize again i can reproduce it with the Trinidad's
own demo app.
What do you think should be any diffrence in the weblogic
environment? Our weblogic is an absolutely unpatched 9.2 version
on a windows xp. Do you know whether your weblogic needed any
patch for sucessfully run Trinidad PPR? And does your project use
any of above mentioned features?
As i could see in your thread about a year ago, you also had
problems with Trinidad PPR on weblogic. Was that solved only with
replace Trinidad version 1.0.1. <http://1.0.1./> with 1.0.7?
Since my last mail i tried ADF Faces on weblogic and it worked.
Almost the same code, just replace tr: with af: ....
Francisco, if you have any suggestion, i would hihgly appreciate it!
Thanks!
On Thu, Jun 12, 2008 at 8:42 PM, Francisco Passos
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
I have a working project running on Weblogic 9.2 with Trinidad
1.0.7. <http://1.0.7./> PPR works fine and, dare I say, a
whole lot faster than 1.0.1 used to, since it now uses AJAX
and several improvements have been made regarding bandwidth.
On Wed, Jun 11, 2008 at 7:22 AM, Sandor Nemeth
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Hi,
I've found only one thread among archives about Trinidad
PPR doesn't work on Weblogic 9 or 10. Unfortunately that
thread doesn't contain real solution. The suggestion
changing content type from text/html to text/xml doesn't
work for me.
I tried it with the latest trinidad release 1.0.8.
<http://1.0.8./>
Is there any solution or workaround to this issue? Or
should i choose another faces implementation for a
weblogic project?
As far as i can see, ADF faces has no problem with PPR on
weblogic.
Thanks!
