Mamallan,
here are my dummy test to see what is causing server log errors:
--------------------------------------------------------------------------------------
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
System.out.println("-------------1");
if (!_filters.isEmpty())
chain = new FilterListChain(_filters, chain);
System.out.println("-------------2");
request.setAttribute(_FILTER_EXECUTED_KEY, Boolean.TRUE);
System.out.println("-------------3");
ExternalContext externalContext = new
ServletExternalContext(_servletContext, request, response);
System.out.println("-------------4");
GlobalConfiguratorImpl config = GlobalConfiguratorImpl.getInstance();
System.out.println("-------------5");
config.beginRequest(externalContext);
System.out.println("-------------6");
String noJavaScript =
request.getParameter(XhtmlConstants.NON_JS_BROWSER);
System.out.println("-------------7");
if(noJavaScript != null &&
XhtmlConstants.NON_JS_BROWSER_TRUE.equals(noJavaScript))
{
request = new
BasicHTMLBrowserRequestWrapper((HttpServletRequest)request);
}
System.out.println("-------------8");
Map<String, String[]> addedParams =
FileUploadConfiguratorImpl.getAddedParameters(externalContext);
System.out.println("-------------9");
if(addedParams != null)
{
FileUploadConfiguratorImpl.apply(externalContext);
request = new UploadRequestWrapper((HttpServletRequest)request,
addedParams);
}
System.out.println("-------------10");
try
{
_doFilterImpl(request, response, chain);
System.out.println("-------------100");
}
--------------------------------------------------------------------------------------------------------------------------------------
private void _doFilterImpl(
ServletRequest request,
ServletResponse response,
FilterChain chain) throws IOException, ServletException
{
System.out.println("-------------11");
ExternalContext ec = new ServletExternalContext(_servletContext,
request, response);
System.out.println("-------------12");
boolean isHttpReq = ExternalContextUtils.isHttpServletRequest(ec);
System.out.println("-------------13");
if(isHttpReq)
{
System.out.println("-------------14");
response = _getResponse(ec);
System.out.println("-------------15");
ec.setResponse(response);
System.out.println("-------------16");
}
System.out.println("-------------17");
PseudoFacesContext pfc = new PseudoFacesContext(ec);
System.out.println("-------------18");
_PSEUDO_FACES_CONTEXT.set(pfc);
System.out.println("-------------19");
try
{
if(isHttpReq)
{
System.out.println("-------------20");
request = _getRequest(ec);
System.out.println("-------------21");
ec.setRequest(request);
System.out.println("-------------22");
}
System.out.println("-------------23");
chain.doFilter(request, response);
System.out.println("-------------24");
if(isHttpReq)
{
System.out.println("-------------25");
_handleDialogReturn(ec);
System.out.println("-------------26");
}
}
finally
{
System.out.println("-------------27");
_PSEUDO_FACES_CONTEXT.remove();
System.out.println("-------------28");
}
}
---------------------------------------------------------------------------------------------------------------------
and here is the server log for this
-------------1
-------------2
-------------3
-------------4
-------------5
-------------6
-------------7
-------------8
-------------9
-------------10
-------------11
PWC4011: Unable to set request character encoding to UTF-8 from context
/YP, because request parameters have already been read, or
ServletRequest.getReader() has already been called
-------------12
-------------13
-------------14
-------------15
-------------16
-------------17
-------------18
-------------19
-------------20
-------------21
PWC4011: Unable to set request character encoding to UTF-8 from context
/YP, because request parameters have already been read, or
ServletRequest.getReader() has already been called
-------------22
-------------23
PWC4011: Unable to set request character encoding to UTF-8 from context
/YP, because request parameters have already been read, or
ServletRequest.getReader() has already been called
TopLink, version: Oracle TopLink Essentials - 2.0.1 (Build b09d-fcs
(12/06/2007))
Server: unknown
file:/opt/glassfish/domains/domain1/applications/j2ee-apps/YachtPool/YachtPool-ejb_jar/-YachtPool-PU
login successful
-------------24
-------------25
-------------26
-------------27
-------------28
-------------100
Matthias,
there must be some other changes in filter chain because, before fix
1272 because server didn't display this errors. Maybe it is a Glassfish
bug, but how to track the root cause?
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Tadashi Enomori wrote:
Luka,
Thanks for bringing this issue to our attention and investigating the
issue to isolate the cause.
Our team will be working to deliver the solution as soon as possible.
Thanks,
Tadashi
Luka Surija wrote:
Thank you Matthias!
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
On Wed, Mar 18, 2009 at 2:52 PM, Luka Surija <[email protected]>
wrote:
Putting "ExternalContext externalContext = new
ServletExternalContext(_servletContext, request, response); " in a
first
line of the function just before
String noJavaScript =
request.getParameter(XhtmlConstants.NON_JS_BROWSER);
resolved the problem with character encoding, but errors in server log
remains.
I'm not sure what is the best solution because:
I pinged the guys that offered the patch. They are
from another team at Oracle. They are aware of the issue.
So, a correct patch should be available soon.
-Matthias
request = new
BasicHTMLBrowserRequestWrapper((HttpServletRequest)request);
is called (if noJavaScript==true) before ExternalContext creation,
and I
think it has a good reason because it changes the request befor any
other
initialization.
on the other hand putting fix 1272 after ExternalContext creation
looks
like has no meaning, but I can't test it.
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Luka Surija wrote:
I'll try your suggestion and post the results.
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
in here:
ExternalContext externalContext = new
ServletExternalContext(_servletContext, request, response);
we set the encoding (inside of the ServetExternalContext(...)),
so the
fix for 1272 should be done after that,
or we need to create the ServetExternalContext earlier...
-Matthias
On Wed, Mar 18, 2009 at 2:01 PM, Luka Surija <[email protected]>
wrote:
https://issues.apache.org/jira/browse/TRINIDAD-1430
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
Hi Luka,
thanks for following up here.
Do you mind to create an issue for the problem that you are
facing?
It would be good to link to 1272 as it is the source of the
problem.
Once done, I'll follow up on that issue(s).
-Matthias
On Wed, Mar 18, 2009 at 1:29 PM, Luka Surija
<[email protected]>
wrote:
Finally I've found the source of the problem in general. svn
revision
713294
(TRINIDAD-1272 - Support for WAP2.0 Browser without
JavaScript) is
introducing this problem.
The changes in TrinidadFilterImpl.java causes this issue.
this line looks like source of the problems
String noJavaScript =
request.getParameter(XhtmlConstants.NON_JS_BROWSER);
request is probably called too early, so the JSF (Majorra)
can't set
proper
CharacterEncoding, and that's why server reported the error
message
and
messed up non-US characters.
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
ah, good to know.
Did you test the recent trunk ?
-Matthias
On Tue, Mar 17, 2009 at 7:43 PM, Luka Surija
<[email protected]>
wrote:
I have to correct myself. Now this problem appears only with
1.2.11
version
of trinidad. All versions prior 1.2.11 in 1.2.x trunk are
working
fine.
Maybe this can narrow possible problems and incompatibility.
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Luka Surija wrote:
No luck with newest Majorra version 1.2_12-b01-FCS.
do you mind to test with the myfaces/jetty combo ? --> This
is a
full
EJB
3 application, so jetty web server is not enough. Also putting
myfaces
on
glassfish is real pain ....
Do you know what is so big difference in 1.0.x and 1.2.x.
versions
of
trinidad that handles in different order request parameters?
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
Or perhaps, can you go with a more recent version of this?
Majorra 1.2_04-b18-p03
-Matthias
On Tue, Mar 17, 2009 at 7:07 PM, Matthias Wessendorf
<[email protected]>
wrote:
do you mind to test with the myfaces/jetty combo ?
-Matthias
On Tue, Mar 17, 2009 at 7:04 PM, Luka Surija
<[email protected]>
wrote:
The strange thing is that this problem persist in all my
applications
built
with this combination of frameworks.
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
Hrm,
I was able to submit my name "Weßendorf" on the demo
(Trinidad 1.2. trunk + MyFaces 1.2.x + Jetty)
-Matthias
On Tue, Mar 17, 2009 at 6:48 PM, Luka Surija
<[email protected]>
wrote:
No, just JSF phase listener for authentication. Nothing
special.
If
you
referring to the error in server log, then it shows
only in
1.2.x
version
of trinidad.
Looking with Firefox live headers bellow mentioned
characters
are
submitted
as "%C5%A1%C4%91%C5%BE%C4%87%C4%8D" in both versions of
trinidad.
So
it's
not problem with browser encoding.
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
Matthias Wessendorf wrote:
Are you using some custom filter, that accesses the
request
map
?
-Matthias
On Tue, Mar 17, 2009 at 5:57 PM, Luka Surija
<[email protected]>
wrote:
Hi,
I'm stuck with trinidad version 1.0.x. and I can't
use any
1.2.x
version
because many non us characters are broken. The
problem is
not
in
character
displaying this characters, but in submitting.
For example "šđžćč" is correctly displayed in
tr:inputText,
but
after
submitting the same value, it is displayed as
"Å¡Ä‘Å¾Ä‡Ä ".
This
problem
is
not only with croatian characters, but also with German
umlauts
and
probably
other non us characters.
I've also noticed that with 1.2.x version of
trinidad this
error
in
server
log:
"PWC4011: Unable to set request character encoding
to UTF-8
from
context
/YP, because request parameters have already been
read, or
ServletRequest.getReader() has already been called"
Glassfish 9.1
Trinidad 1.2.11
Facelets 1.1.13
Majorra 1.2_04-b18-p03
--
Luka Surija
+385 1 61 99 140
+385 98 434 061
[email protected]
I.Y. tim d.o.o.
Vrbik 3, HR-10000 Zagreb
www.iytim.hr
[email protected]
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
