Re: Wicket 1.5.8 + EJB 3.1 - strange problem
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 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
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 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: How to know the country of the user
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 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: wicket 6.1.0 default logging configuration
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 wrote:
> 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
> 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
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 wrote: > Hi, > > On Fri, Oct 19, 2012 at 11:04 AM, Wujek Srujek > 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 >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 > 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 > >
Re: js
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 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 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 > >
ModalDialog - control the location
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
