Re: Wicket 1.5.8 + EJB 3.1 - strange problem

2012-11-19 Thread Wujek Srujek
If the container returns the correct bean, this means your login works
fine, is this correct? Why do you then care that the @Stateful-annotated
field is different? It probably is just a proxy generated by your
container's injection framework anyways.


On Mon, Nov 19, 2012 at 2:16 PM, Satrix satrix...@gmail.com wrote:

 Unfortunately even after changing the version of the
 wicketstuff-javaee-inject to newer version the problem still exists.

 What's more interesing is that when I navigate over the page (everything
 except back button) the @Stateful bean works. Only back button click
 recreates the @Stateful bean (but... after the bean has been recreated,
 when
 I click on a links etc, container returns me correct bean instance
 (previous
 bean - before recreation)).

 I wonder if you know someone from the wicketstuff-javaee-inject, so maybe
 they could provide me a workaround or smth ?

 Regards, Satrix



 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-8-EJB-3-1-strange-problem-tp4653977p4653991.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: How to know the country of the user

2012-10-28 Thread Wujek Srujek
Locale has more information than just the language. For example: en_US
is English in USA; en_UK is English in the UK, it_IT is Italian in Italy,
but it_CH is Italian in Switzerland. Your example would differentiate
between pt_PT (Portuguese in Portugal) and pt_BR (Portuguese in Brazil).
Check out Locale.getCountry().
This being said, it is still not the same as the physical location. Do you
really need the country of residence for some statistics / whatever, or the
language / regional settings for localization? In the former case, Locale
won't help; in the latter, the physical location is probably not the right
way to go, Locale is.
For example, I'm Polish but live in Germany, and I would like your
application display Polish strings (or English).

wujek

On Sun, Oct 28, 2012 at 5:52 PM, Paolo irresistible...@gmail.com wrote:

 Alle domenica 28 ottobre 2012, Andrea Del Bene ha scritto:
  You should try Session.get().getLocale(). By default Session returns the
  locale of the underlying HttpServletRequest.

 getLocale return the languange set in the browser, and it is not the same
 thing of country.

 You are right for example for me that I am italian, so my language (it) is
 the same of the country (it)

 But for example if your country may be Brazil (br), but language is
 portuguese.

 The same is for language espanol (es), that is speaking in many countries.




   How can I know the country of the user that is connected to my wicket
 page?
  
   I only suppose to check the IP address with:
  
   String ipAddress = ((ServletWebRequest)
 RequestCycle.get().getRequest()).getContainerRequest().getRemoteHost();
  
   And than with command line whois check the country
  
   whois 109.113.243.xx |grep -E 'country|Country'
  
   or use a free database:
  
   http://dev.maxmind.com/geoip/geolite.
  
   If you know some wicket library, or better way, please tell me.
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: How to know the country of the user

2012-10-28 Thread Wujek Srujek
Glad I could help. Please note, though, that Locale.getCountry() might be
null, or Locale.getLanguage() might be null, but both being null result in
an 'undefined' locale. You might want to take this into account.

wujek

On Sun, Oct 28, 2012 at 6:45 PM, Paolo irresistible...@gmail.com wrote:

 Alle domenica 28 ottobre 2012, Wujek Srujek ha scritto:
  Locale has more information than just the language. For example: en_US
  is English in USA; en_UK is English in the UK, it_IT is Italian in Italy,
  but it_CH is Italian in Switzerland. Your example would differentiate
  between pt_PT (Portuguese in Portugal) and pt_BR (Portuguese in Brazil).
  Check out Locale.getCountry().
  This being said, it is still not the same as the physical location. Do
 you
  really need the country of residence for some statistics / whatever, or
 the
  language / regional settings for localization? In the former case, Locale
  won't help; in the latter, the physical location is probably not the
 right
  way to go, Locale is.
  For example, I'm Polish but live in Germany, and I would like your
  application display Polish strings (or English).

 Thank you so much, for your reply.
 I don't need the physical location, so  Locale.getCountry() is enought for
 me,
 and so faster and easy than my idea.

 Thank you so much!

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: wicket 6.1.0 default logging configuration

2012-10-23 Thread Wujek Srujek
I am not using maven but gradle, but otherwise:
* there is only one logback jar on the classpath
* there are no configuration files anywhere - I had checked this before
posting
But there may be programmatic configuration somewhere, and as I am seeing a
lot of wicket DEBUG output, I thought it were wicket's doing.


wujek

On Tue, Oct 23, 2012 at 9:24 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 Wicket comes only with slf4j-api.jar. The application developer should
 provide the implementation.
 Check with 'mvn dependency:tree' that there is no other SLF4J impl
 than yours (logback).
 Additionally with ClassLoader#getResources(/logback.xml)
 (logback-test.xml, logback.groovy, log4j.properties) you may find
 whether there is one of those in the classpath and where exactly.

 On Tue, Oct 23, 2012 at 1:31 AM, Wujek Srujek wujek.sru...@gmail.com
 wrote:
  Hi. I am using wicket 6.1.0 and logback-classic as my logging backend.
  There is no configuration anywhere but wicket (and wicket only) logs
  everything at level DEBUG - where can this be coming come from?
 
  wujek



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: js

2012-10-19 Thread Wujek Srujek
This works more or less the following way in servlet containers: when the
first request comes to the server, it doesn't know if cookies are supported
or not on the client, so it sets both the cookie and appends the jsessionid
thingy that you see. Then, on another request, the container checks whether
a cookie is there, and now it can use the following logic:
1. the cookie is there: the client sent this cookie, so it supports cookies
- there is no need to append jsessionid every time, so the encodeUrl
methods don't do it any more
2. the cookie is not there, but the jsessionid part is - this must be the
second (or later) requrest, but cookies are not supported by the client -
encodeUrl will now encode each url you give it to add the jsessionid part
3. neither the cookie nor the jsessionid part is there - this is the first
request in this session, so maybe create one (depends whether the app needs
one): set the cookie, append jsessionid and send it - this basically starts
the whole process again, when the server got the initial request

Which means: if you disable cookies, your only option is to have jsessionid
encoded in the url. If you disabled cookies, and don't allow jsessionid to
be put (there are filters in SpringSecurity or custom solutions that strip
this) your application basically doesn't allow session tracking, which
makes it stateless and most of the time pretty much useless except for
simplest kinds.

As said before, this is all done by the container; Wicket (and all other
frameworks, for that matter) just use sessions.

wujek


On Fri, Oct 19, 2012 at 10:54 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 This is done by the web container (Tomcat, Jetty, ...), not by Wicket
 itself.
 See
 http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String)

 On Fri, Oct 19, 2012 at 10:51 AM, Jordi Deu-Pons jo...@jordeu.net wrote:
   Hi,
 
   when cookies are disable Wicket 6 attach the jsessionid in the URL like
 this:
 
   [app_path];jsessionid=1pwfo2de689mq100bkdc8i4jhy?[app_parameters]
 
   I'm having problems with an application that runs behind an apache
 proxy pass.
 
   So I wonder if somebody knows,
 
   why is not using a normal URL parameter after the question mark?
 
   and
 
   is it possible to change this behaviour and force wicket to use a
  normal URL parameter?
 
   Thanks.
 
  --
  a10! i fins aviat.
  J:-Deu
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: js

2012-10-19 Thread Wujek Srujek
Does the cookie come with the session id inside? I'm not sure this works
this way - the value of the session id will most likely be wrong for a
request one month after the last time the application was used even though
the cookie itself is still valid; the session will just not exist any more
on the server (unless you told tomcat / whatever to preserve sessions that
long ;d).
But you may be right - maybe the server can check if there is _any_ cookie
to know the client supports them. When cookies come with the first request,
it is the same as if it were the nth request in a series - the server can't
know that. That's what sessions are for ;d

wujek

On Fri, Oct 19, 2012 at 11:10 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 On Fri, Oct 19, 2012 at 11:04 AM, Wujek Srujek wujek.sru...@gmail.com
 wrote:
  This works more or less the following way in servlet containers: when the
  first request comes to the server, it doesn't know if cookies are
 supported
  or not on the client, so it sets both the cookie and appends the
 jsessionid

 I think there is a small optimization here.
 The first request may come with a cookie if it is not yet expired and
 then it will not encode jsessionid in the Url at all.

  thingy that you see. Then, on another request, the container checks
 whether
  a cookie is there, and now it can use the following logic:
  1. the cookie is there: the client sent this cookie, so it supports
 cookies
  - there is no need to append jsessionid every time, so the encodeUrl
  methods don't do it any more
  2. the cookie is not there, but the jsessionid part is - this must be the
  second (or later) requrest, but cookies are not supported by the client -
  encodeUrl will now encode each url you give it to add the jsessionid part
  3. neither the cookie nor the jsessionid part is there - this is the
 first
  request in this session, so maybe create one (depends whether the app
 needs
  one): set the cookie, append jsessionid and send it - this basically
 starts
  the whole process again, when the server got the initial request
 
  Which means: if you disable cookies, your only option is to have
 jsessionid
  encoded in the url. If you disabled cookies, and don't allow jsessionid
 to
  be put (there are filters in SpringSecurity or custom solutions that
 strip
  this) your application basically doesn't allow session tracking, which
  makes it stateless and most of the time pretty much useless except for
  simplest kinds.
 
  As said before, this is all done by the container; Wicket (and all other
  frameworks, for that matter) just use sessions.
 
  wujek
 
 
  On Fri, Oct 19, 2012 at 10:54 AM, Martin Grigorov mgrigo...@apache.org
 wrote:
 
  Hi,
 
  This is done by the web container (Tomcat, Jetty, ...), not by Wicket
  itself.
  See
 
 http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#encodeURL(java.lang.String)
 
  On Fri, Oct 19, 2012 at 10:51 AM, Jordi Deu-Pons jo...@jordeu.net
 wrote:
Hi,
  
when cookies are disable Wicket 6 attach the jsessionid in the URL
 like
  this:
  
[app_path];jsessionid=1pwfo2de689mq100bkdc8i4jhy?[app_parameters]
  
I'm having problems with an application that runs behind an apache
  proxy pass.
  
So I wonder if somebody knows,
  
why is not using a normal URL parameter after the question mark?
  
and
  
is it possible to change this behaviour and force wicket to use a
   normal URL parameter?
  
Thanks.
  
   --
   a10! i fins aviat.
   J:-Deu
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
 
 
 
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




ModalDialog - control the location

2012-10-12 Thread Wujek Srujek
Hi. We have the requirement that we need to show more than one popup at a
time - this means buttons / links in a popup trigger showing other popups
(whether it's good style or not is irrelevant, this is a requirement...).
We are using ModalWindow for that, and it is always shown in the center of
the screen. What we would like to have is to be able to 'stack' windows,
where the new one is shown +20 from the top and +20 to the right from the
top one:
 
| |_
| |  |
| |  |
| |  |
  |_|

My idea is to override the center method in a way that:
1. introduces a counter of the windows
2. calls the original method
3. retrieves the top and and left styles, parses them into an integer
4. top = top + counter * 20; left = left + counter * 20
5. sets the style to these new values

As I have very, very little knowledge of javascript, I'm failing to
implement that. Could I get some help from you? Namely, I have trouble
getting accessing the modal window, and its current styles.

Regards,
wujek