date:20190404

Re: web sockets messages + page identities

2019-04-04 Thread Martin Grigorov

Hi Ernesto,

Please file a ticket.
TextMessage and BinaryMessage can be improved.
I have to see whether IWebSocketConnection can be improved too.
But due to API changes this could be done only for Wicket 9.x.

On Wed, Apr 3, 2019 at 4:19 PM Ernesto Reinaldo Barreiro 
wrote:

> I meant my "question"
>
> On Wed, Apr 3, 2019 at 4:18 PM Ernesto Reinaldo Barreiro <
> reier...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Thanks for your answer. Yes my answer was more on the spirit if there is
> > something already available and ready to use Or if it makes sense to
> > have this by default at interface level.
> >
> > On Wed, Apr 3, 2019 at 3:37 PM Maxim Solodovnik 
> > wrote:
> >
> >> Hello Ernesto,
> >>
> >> We also have code to send websocket messages "to others"
> >> I do store active client list (each page/tab is client)
> >> Every client stores pageId and sessionId
> >>
> >> Then I do filtering on pageId+sessionId
> >>
> >> This seems to work as expected
> >>
> >> On Wed, 3 Apr 2019 at 18:18, Ernesto Reinaldo Barreiro
> >>  wrote:
> >> >
> >> > Hi,
> >> >
> >> > I have the following use case.
> >> >
> >> > 1- One browser tab sends a text message
> >> > 2- Other browser tabs should receive message (but emitting tab not).
> >> >
> >> > I have done
> >> >
> >> > add(*new *WebSocketBehavior() {
> >> > @Override
> >> > *protected void *onMessage(WebSocketRequestHandler handler,
> TextMessage
> >> > message) {
> >> > sendNotificationToSession()
> >> > }
> >> > });
> >> >
> >> >
> >> >
> >> > *public void *sendNotificationToSession(String sessionId) {
> >> > *if *(com.rometools.utils.Strings.*isEmpty*(sessionId)) {
> >> > *throw new *IllegalArgumentException(*"sessionId cannot be empty"*);
> >> > }
> >> > Application application = Application.*get*(KmsContext.*APP_NAME*);
> >> >
> >>
> privateSendNotificationTo(getRegistry(application).getConnections(application,
> >> > sessionId));
> >> > }
> >> >
> >> >
> >> > *private void
> >> *privateSendNotificationTo(Collection
> >> > webSocketConnections) {
> >> > String message = toJSON();
> >> > *for*(IWebSocketConnection connection : webSocketConnections) {
> >> > *if *(connection.isOpen()) {
> >> > *try *{
> >> > connection.sendMessage(message);
> >> > } *catch *(IOException e) {
> >> > *log*.error(*"Could not send notification"*, e);
> >> > *//$NON-NLS-1$ *}
> >> > }
> >> > }
> >> > }
> >> >
> >> >
> >> > I see some classes like
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > */**  * A base message for all messages with information about the
> >> client
> >> >  */ **public abstract class *AbstractClientMessage *implements *
> >> > IWebSocketMessage
> >> > {
> >> > *private final *String *applicationName*;
> >> > *private final *String *sessionId*;
> >> > *private final *IKey *key*;
> >> >
> >> > *public *AbstractClientMessage(Application application, String
> >> sessionId,
> >> > IKey key)
> >> > {
> >> > *this*.*applicationName *= Args.*notNull*(application, *"application"*
> >> > ).getName();
> >> > *this*.*sessionId *= Args.*notNull*(sessionId, *"sessionId"*);
> >> > *this*.*key *= Args.*notNull*(key, *"key"*);
> >> > }
> >> >
> >> > *public *Application getApplication()
> >> > {
> >> > *return *Application.*get*(*applicationName*);
> >> > }
> >> >
> >> > *public *String getSessionId()
> >> > {
> >> > *return **sessionId*;
> >> > }
> >> >
> >> > *public *IKey getKey()
> >> > {
> >> > *return **key*;
> >> > }
> >> >
> >> > }
> >> >
> >> >
> >> > provide IKey as "discriminator" of sending page. But this is neither
> >> part
> >> > of IWebSocketMessage nor it is part of IWebSocketConnection... So, I
> >> don't
> >> > really know to use to exclude the emitting page. This clearly would be
> >> > possible if both IWebSocketMessage and IWebSocketConnection have a
> IKey
> >> > getPageKey();
> >> >
> >> >
> >> > Is there a way to do this? Am I missing some essential part?
> >> >
> >> >
> >> > --
> >> > Regards - Ernesto Reinaldo Barreiro
> >>
> >>
> >>
> >> --
> >> WBR
> >> Maxim aka solomax
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
> > --
> > Regards - Ernesto Reinaldo Barreiro
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: Problem with ThreadContext.getSession when session dies

2019-04-04 Thread Patrick Schwarzer

Hi Sven,

thanks for the reply.

The problem is, that at the end of the request in onDetach wicket tries to 
write content of pages into the session (see storeTouchedPages in Stack-Trace), 
which is already dead. To identify if wicket needs to store content into 
session, it checked the Session.get() / ThreadContext.getSession() cached 
Session, which represents not the real last state of the session.

When wicket then writes content into session, it look in the real dead session 
(getSessionStore().getAttribute call).

So I don't know the right solution but I could not understand why checking 
state of session is done on a cached version while writing than is done on the 
real one. Does the process not to be consistent (check and write in the cached 
or check and write in the real one)?

Kind regards


PATRICK SCHWARZER
SOFTWARE ENGINEER

o +49 89 32175 655

TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen

[cid:image003.jpg@01D4EAC5.E4FEFCC0]




Hi Patrick,

Wicket uses a temporary session if there's no container session, e.g.
the latter has already expired.
It's not clear to me why that's a problem for you.

Best regards
Sven



Von: Patrick Schwarzer
Gesendet: Mittwoch, 3. April 2019 13:27
An: 'users@wicket.apache.org' 
Betreff: Problem with ThreadContext.getSession when session dies

Dear Sir or Madam,
we identified an issue during request handling in Wicket 7.12.0 when session 
dies during processing.
The problem is, that parts of the code accessing current session by calling 
Session.get() which then return a valid session cached in 
ThreadContext.getSession().
[cid:image004.png@01D4EAC5.E4FEFCC0]
But when accessing an attribute of the Session, the code accesses the real 
session, which is dead and leads to an Exception.
[cid:image005.png@01D4EAC5.E4FEFCC0]
So we were a little confused why Session.get() and Session.exists() return 
valid results when Session is already dead.
How we can avoid Session.get() and Session.exists() return valid results? 
Alternatively how we can ensure, that Request with cached Session is handled 
correctly?


The stack trace of our problem:
java.lang.IllegalStateException: 
org.apache.shiro.session.UnknownSessionException: There is no session with id 
[48cf6f39-9bf6-4b76-84cd-a106e707af63]
at 
org.apache.shiro.web.servlet.ShiroHttpSession.getAttribute(ShiroHttpSession.java:133)
 ~[shiro-web-1.3.2.jar:1.3.2]
getAttribute:286, HttpSessionStore (org.apache.wicket.session)
getAttribute:743, Session (org.apache.wicket) << Why this is not accessing 
cached Session?
getSessionAttribute:66, DefaultPageManagerContext (org.apache.wicket.page)
getSessionAttribute:101, RequestAdapter (org.apache.wicket.page)
getSessionEntry:414, PageStoreManager$PersistentRequestAdapter 
(org.apache.wicket.page)
storeTouchedPages:438, PageStoreManager$PersistentRequestAdapter 
(org.apache.wicket.page) <<  Should this happen, when Session is already dead?
commitRequest:193, RequestAdapter (org.apache.wicket.page)
commitRequest:76, AbstractPageManager (org.apache.wicket.page)
commitRequest:74, PageManagerDecorator (org.apache.wicket.page)
commitRequest:270, PageAccessSynchronizer$2 (org.apache.wicket.page)
onDetach:1798, Application$3 (org.apache.wicket)
notify:105, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle)
notify:101, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle)
notify:120, ListenerCollection$1 (org.apache.wicket.util.listener)
reversedNotify:144, ListenerCollection (org.apache.wicket.util.listener)
reversedNotifyIgnoringExceptions:113, ListenerCollection 
(org.apache.wicket.util.listener)
onDetach:100, RequestCycleListenerCollection (org.apache.wicket.request.cycle)
onDetach:649, RequestCycle (org.apache.wicket.request.cycle)
detach:594, RequestCycle (org.apache.wicket.request.cycle)
processRequestAndDetach:297, RequestCycle (org.apache.wicket.request.cycle)
processRequestCycle:261, WicketFilter (org.apache.wicket.protocol.http)
processRequest:203, WicketFilter (org.apache.wicket.protocol.http)
doFilter:284, WicketFilter (org.apache.wicket.protocol.http)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilterInternal:99, RequestContextFilter (org.springframework.web.filter)
doFilter:107, OncePerRequestFilter (org.springframework.web.filter)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilter:61, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:108, AdviceFilter

Re: Problem with ThreadContext.getSession when session dies

2019-04-04 Thread Martin Grigorov

Hi Patrick,

On Thu, Apr 4, 2019 at 10:16 AM Patrick Schwarzer <
patrick.schwar...@tomtec.de> wrote:

> Hi Sven,
>
>
>
> thanks for the reply.
>
>
>
> The problem is, that at the end of the request in onDetach wicket tries to
> write content of pages into the session (see storeTouchedPages in
> Stack-Trace), which is already dead. To identify if wicket needs to store
> content into session, it checked the Session.get() /
> ThreadContext.getSession() cached Session, which represents not the real
> last state of the session.
>
>
>
> When wicket then writes content into session, it look in the real dead
> session (getSessionStore().getAttribute call).
>

I have the feeling there is some problem with Shiro here.
What exactly is a "dead" session ?!
Wicket uses HttpServletRequest#getSession(boolean) to get the underlying
HttpSession.
Depending on the value of the boolean parameter the Servlet container
should:
- if the parameter is 'false' then:
-- if there is a session then it should return it
-- if there is a no session then it should return null
- if the value is 'true' then:
-- if there is a session then it should return it
-- if there is a no session then it should create a *new* HttpSession and
return it

So, I do not understand what Shiro considers as "dead" session.


>
> So I don’t know the right solution but I could not understand why checking
> state of session is done on a cached version while writing than is done on
> the real one. Does the process not to be consistent (check and write in the
> cached or check and write in the real one)?
>

Wicket stores the Wicket Session into a ThreadLocal, i.e. caches it. But
any access to the HttpSession is via HttpSessionStore which uses the
Servlet APIs.
The Wicket Session itself is stored as an attribute in the HttpSession.


>
>
> Kind regards
>
>
>
>
>
> *PATRICK SCHWARZER*
> SOFTWARE ENGINEER
>
> *o* +49 89 32175 655
>
> *TOMTEC Imaging Systems GmbH*
> Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
> Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
>
> 
>
>
>
>
>
>
>
> Hi Patrick,
>
>
>
> Wicket uses a temporary session if there's no container session, e.g.
>
> the latter has already expired.
>
> It's not clear to me why that's a problem for you.
>
>
>
> Best regards
>
> Sven
>
>
>
>
> *Von:* Patrick Schwarzer
> *Gesendet:* Mittwoch, 3. April 2019 13:27
> *An:* 'users@wicket.apache.org' 
> *Betreff:* Problem with ThreadContext.getSession when session dies
>
>
>
> Dear Sir or Madam,
>
> we identified an issue during request handling in Wicket 7.12.0 when
> session dies during processing.
>
> The problem is, that parts of the code accessing current session by
> calling Session.get() which then return a valid session cached in
> ThreadContext.getSession().
>
> But when accessing an attribute of the Session, the code accesses the real
> session, which is dead and leads to an Exception.
>
> So we were a little confused why Session.get() and Session.exists() return
> valid results when Session is already dead.
> How we can avoid Session.get() and Session.exists() return valid results?
> Alternatively how we can ensure, that Request with cached Session is
> handled correctly?
>
>
>
>
>
> The stack trace of our problem:
>
> java.lang.IllegalStateException:
> org.apache.shiro.session.UnknownSessionException: There is no session with
> id [48cf6f39-9bf6-4b76-84cd-a106e707af63]
>
> at
> org.apache.shiro.web.servlet.ShiroHttpSession.getAttribute(ShiroHttpSession.java:133)
> ~[shiro-web-1.3.2.jar:1.3.2]
>
> getAttribute:286, HttpSessionStore (org.apache.wicket.session)
>
> getAttribute:743, Session (org.apache.wicket) *<< Why this is not
> accessing cached Session?*
>
> getSessionAttribute:66, DefaultPageManagerContext (org.apache.wicket.page)
>
> getSessionAttribute:101, RequestAdapter (org.apache.wicket.page)
>
> getSessionEntry:414, PageStoreManager$PersistentRequestAdapter
> (org.apache.wicket.page)
>
> storeTouchedPages:438, PageStoreManager$PersistentRequestAdapter
> (org.apache.wicket.page) *<<  Should this happen, when Session is already
> dead?*
>
> commitRequest:193, RequestAdapter (org.apache.wicket.page)
>
> commitRequest:76, AbstractPageManager (org.apache.wicket.page)
>
> commitRequest:74, PageManagerDecorator (org.apache.wicket.page)
>
> commitRequest:270, PageAccessSynchronizer$2 (org.apache.wicket.page)
>
> onDetach:1798, Application$3 (org.apache.wicket)
>
> notify:105, RequestCycleListenerCollection$3
> (org.apache.wicket.request.cycle)
>
> notify:101, RequestCycleListenerCollection$3
> (org.apache.wicket.request.cycle)
>
> notify:120, ListenerCollection$1 (org.apache.wicket.util.listener)
>
> reversedNotify:144, ListenerCollection (org.apache.wicket.util.listener)
>
> reversedNotifyIgnoringExceptions:113, ListenerCollection
> (org.apache.wicket.util.listener)
>
> onDetach:100, RequestCycleListenerCollection
> (org.apache.wicket.request.cycle)
>
> onDetach:649, RequestCycle

Re: web sockets messages + page identities

2019-04-04 Thread Ernesto Reinaldo Barreiro

Hi Martin,

Many thanks for feedback. I will file a ticket.


> Please file a ticket.
> TextMessage and BinaryMessage can be improved.
> I have to see whether IWebSocketConnection can be improved too.
>

I see  AbstractWebSocketConnection contains AbstractWebSocketProcessor and
this one a pageId. Meanwhile I can try to roll my own implementation to
cover use case.

But due to API changes this could be done only for Wicket 9.x.
>

I understand. We are still on 7.x... One more argument to push for going
8.x and then 9.x.

Maybe one possibility to make this more configurable is allow to register
at "application level" some factory for IWebSocketConnections and/or
TextMessages? So, no need to break this on 7.x, 8.x? I don't know if this
makes sense at all? I see AbstractWebSocketProcessor contains both
Application and pageId.


>
> On Wed, Apr 3, 2019 at 4:19 PM Ernesto Reinaldo Barreiro <
> reier...@gmail.com>
> wrote:
>
> > I meant my "question"
> >
> > On Wed, Apr 3, 2019 at 4:18 PM Ernesto Reinaldo Barreiro <
> > reier...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Thanks for your answer. Yes my answer was more on the spirit if there
> is
> > > something already available and ready to use Or if it makes sense
> to
> > > have this by default at interface level.
> > >
> > > On Wed, Apr 3, 2019 at 3:37 PM Maxim Solodovnik 
> > > wrote:
> > >
> > >> Hello Ernesto,
> > >>
> > >> We also have code to send websocket messages "to others"
> > >> I do store active client list (each page/tab is client)
> > >> Every client stores pageId and sessionId
> > >>
> > >> Then I do filtering on pageId+sessionId
> > >>
> > >> This seems to work as expected
> > >>
> > >> On Wed, 3 Apr 2019 at 18:18, Ernesto Reinaldo Barreiro
> > >>  wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I have the following use case.
> > >> >
> > >> > 1- One browser tab sends a text message
> > >> > 2- Other browser tabs should receive message (but emitting tab not).
> > >> >
> > >> > I have done
> > >> >
> > >> > add(*new *WebSocketBehavior() {
> > >> > @Override
> > >> > *protected void *onMessage(WebSocketRequestHandler handler,
> > TextMessage
> > >> > message) {
> > >> > sendNotificationToSession()
> > >> > }
> > >> > });
> > >> >
> > >> >
> > >> >
> > >> > *public void *sendNotificationToSession(String sessionId) {
> > >> > *if *(com.rometools.utils.Strings.*isEmpty*(sessionId)) {
> > >> > *throw new *IllegalArgumentException(*"sessionId cannot be empty"*);
> > >> > }
> > >> > Application application = Application.*get*(KmsContext.*APP_NAME*);
> > >> >
> > >>
> >
> privateSendNotificationTo(getRegistry(application).getConnections(application,
> > >> > sessionId));
> > >> > }
> > >> >
> > >> >
> > >> > *private void
> > >> *privateSendNotificationTo(Collection
> > >> > webSocketConnections) {
> > >> > String message = toJSON();
> > >> > *for*(IWebSocketConnection connection : webSocketConnections) {
> > >> > *if *(connection.isOpen()) {
> > >> > *try *{
> > >> > connection.sendMessage(message);
> > >> > } *catch *(IOException e) {
> > >> > *log*.error(*"Could not send notification"*, e);
> > >> > *//$NON-NLS-1$ *}
> > >> > }
> > >> > }
> > >> > }
> > >> >
> > >> >
> > >> > I see some classes like
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > */**  * A base message for all messages with information about the
> > >> client
> > >> >  */ **public abstract class *AbstractClientMessage *implements *
> > >> > IWebSocketMessage
> > >> > {
> > >> > *private final *String *applicationName*;
> > >> > *private final *String *sessionId*;
> > >> > *private final *IKey *key*;
> > >> >
> > >> > *public *AbstractClientMessage(Application application, String
> > >> sessionId,
> > >> > IKey key)
> > >> > {
> > >> > *this*.*applicationName *= Args.*notNull*(application,
> *"application"*
> > >> > ).getName();
> > >> > *this*.*sessionId *= Args.*notNull*(sessionId, *"sessionId"*);
> > >> > *this*.*key *= Args.*notNull*(key, *"key"*);
> > >> > }
> > >> >
> > >> > *public *Application getApplication()
> > >> > {
> > >> > *return *Application.*get*(*applicationName*);
> > >> > }
> > >> >
> > >> > *public *String getSessionId()
> > >> > {
> > >> > *return **sessionId*;
> > >> > }
> > >> >
> > >> > *public *IKey getKey()
> > >> > {
> > >> > *return **key*;
> > >> > }
> > >> >
> > >> > }
> > >> >
> > >> >
> > >> > provide IKey as "discriminator" of sending page. But this is neither
> > >> part
> > >> > of IWebSocketMessage nor it is part of IWebSocketConnection... So, I
> > >> don't
> > >> > really know to use to exclude the emitting page. This clearly would
> be
> > >> > possible if both IWebSocketMessage and IWebSocketConnection have a
> > IKey
> > >> > getPageKey();
> > >> >
> > >> >
> > >> > Is there a way to do this? Am I missing some essential part?
> > >> >
> > >> >
> > >> > --
> > >> > Regards - Ernesto Reinaldo Barreiro
> > >>
> > >>
> > >>
> > >> --
> > >> WBR
> > >> Maxim aka solomax
> > >>
> > >>

AjaxDownloadBehavior with location=blob and greek filenames problems

2019-04-04 Thread mscoon

Hi all,

When using the AjaxDownloadBehavior with Location=Blob and a greek
filename, the filename is url encoded.

E.g. if the file is "αρχείο.txt" (as defined in
ResourceStreamResource.setFilename()), the downloaded file is
"%CE%B1%CF%81%CF%87%CE%B5%CE%AF%CE%BF.txt" which is the url encoded result
of the original filename.

This happens because ResourceStreamResource url encodes the filename -
something that works fine for Location=IFrame or Location=SameWindow.
However for Location=Blob it seems that the javascript code that constructs
the blob needs to url decode the filename...

Apparently this does not apply only to greek chars in filenames, but to all
non-ascii chars...

This has been tested in chrome and firefox.

Marios

Re: Problem with ThreadContext.getSession when session dies

2019-04-04 Thread Patrick Schwarzer

Hi Martin,

thanks for the explanation.

After some further research we identified the reason for the problem. Shiro 
1.3.2 has a bug, explained here: 
https://issues.apache.org/jira/browse/SHIRO-637.


In case, there is no session any more, Shiro calls to getSession(false) 
returned a cached Session instead of returning null. This problem is fixed with 
1.4.
We will update Shiro to fix this problem.

Thanks for your help.

Kind regards

PATRICK SCHWARZER
SOFTWARE ENGINEER

o +49 89 32175 655

TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen

[cid:image001.jpg@01D4EAF3.85ED4920]

Re: AjaxDownloadBehavior with location=blob and greek filenames problems

2019-04-04 Thread Martin Grigorov

Hi,

Please create a ticket in JIRA and we will take a look at it!

On Thu, Apr 4, 2019 at 3:52 PM mscoon  wrote:

> Hi all,
>
> When using the AjaxDownloadBehavior with Location=Blob and a greek
> filename, the filename is url encoded.
>
> E.g. if the file is "αρχείο.txt" (as defined in
> ResourceStreamResource.setFilename()), the downloaded file is
> "%CE%B1%CF%81%CF%87%CE%B5%CE%AF%CE%BF.txt" which is the url encoded result
> of the original filename.
>
> This happens because ResourceStreamResource url encodes the filename -
> something that works fine for Location=IFrame or Location=SameWindow.
> However for Location=Blob it seems that the javascript code that constructs
> the blob needs to url decode the filename...
>
> Apparently this does not apply only to greek chars in filenames, but to all
> non-ascii chars...
>
> This has been tested in chrome and firefox.
>
> Marios
>

Re: AjaxDownloadBehavior with location=blob and greek filenames problems

2019-04-04 Thread Sven Meier

  
  
Hi,
  

  
You're right, our JavaScript should decode the filename.
  

  
Please open a Jira issue.
  

  
Have fun
  
Sven
  

  
  

  
  
  
  
  
>   
> On 04.04.2019 at 14:52,wrote:
>   
>   
>  Hi all, When using the AjaxDownloadBehavior with Location=Blob and a greek 
> filename, the filename is url encoded. E.g. if the file is "αρχείο.txt" (as 
> defined in ResourceStreamResource.setFilename()), the downloaded file is 
> "%CE%B1%CF%81%CF%87%CE%B5%CE%AF%CE%BF.txt" which is the url encoded result of 
> the original filename. This happens because ResourceStreamResource url 
> encodes the filename - something that works fine for Location=IFrame or 
> Location=SameWindow. However for Location=Blob it seems that the javascript 
> code that constructs the blob needs to url decode the filename... Apparently 
> this does not apply only to greek chars in filenames, but to all non-ascii 
> chars... This has been tested in chrome and firefox. Marios  
>

Re: web sockets messages + page identities

Re: Problem with ThreadContext.getSession when session dies

Re: Problem with ThreadContext.getSession when session dies

Re: web sockets messages + page identities

AjaxDownloadBehavior with location=blob and greek filenames problems

Re: Problem with ThreadContext.getSession when session dies

Re: AjaxDownloadBehavior with location=blob and greek filenames problems

Re: AjaxDownloadBehavior with location=blob and greek filenames problems

8 matches

Site Navigation

Mail list logo

Footer information