RE: Textfield length validator?
StringValidator -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2008 2:39 PM To: users@wicket.apache.org Subject: Textfield length validator? Is there a validator in wicket that constrains the input length? Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Resource keys for custom Validators?
I think you can put "MyValidator.minimum" in your app's properties file. That makes it the app-level default. Yuesong -Original Message- From: Michael Mehrle [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2008 1:53 PM To: users@wicket.apache.org Subject: Resource keys for custom Validators? If I write my own MyValidator for a field I can place my resourceKey for example 'minimum' in my panel's properties file under "myForm.weight.MyValidator.minimum". This however requires everyone using that validator to add this value to their panel/page. I assume there is a default way of providing resource keys? Do I put them in the same folder as the Validator? If so, our group has standardized on putting resources in the template folder (not the class folder), and there is no template folder for Validators. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BaseWicketTester.isVisible() doesn't check Component.isRenderAllowed()
BaseWicketTester.isVisible() only checks Component.isVisible(), not Component.isRenderAllowed(). So for a component whose RENDER action is disabled through role based authorization strategy, BaseWicketTester.isVisible() still returns true. BaseWicketTester.isInvisible() works correctly by using BaseWicketTester.getComponentFromLastRenderedPage() which checks both Component.isVisible() and isRenderAllowed(). Should I add this to JIRA? Yuesong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem on undeploy
It's not a wicket issue. When Tomcat has to access resources in a jar file of a web app, it may lock it. Another attribute your can try is antiJARLocking, which is a little "nicer" than autiResourceLocking. You really only need to set these attribute if you do hot redeployment, e.g. in a development environment. In a production environment where you will stop the server before undeployment, it doesn't really matter. Yuesong -Original Message- From: Sébastien Piller [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 3:29 AM To: users@wicket.apache.org Subject: Re: Problem on undeploy Hello, I just tried it, and it worked :) I don't know if I can use this directive on my deployment server... I'll have a look with my hoster. After some investigation, I'm now quite sure that it's a Wicket problem. I tried with a very simple project (Hello World) and it made the lock. Could anybody tell me if it's a known bug or if I have to write a jira? Thanks TahitianGabriel a écrit : > Have you also tried the antiResourceLocking=true parameter? > > That's the one I use and it works! > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is serialVersionUID really required?
Johan, Thanks for the reply. Just need some further comfirmation. Here is my scenario: 1) The app is packaged in a single war. 2) No distributed deployment - everything is on the app server (Tomcat 6.0). 3) Only user agent is web browser. No remote client (RMI, java web start etc.). 4) Same JVM across all servers in cluster. 5) When deploying a new release, all servers will be stopped/undeployed/deployed/started at the same time. Is that enough to avoid potential serialization issues that may be caused by not supplying serialVersionUID? Yuesong -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: Is serialVersionUID really required? not that importand it is just easier to cluster over different jvms (which doesnt happen a lot) but it is also easier to upgrade an existing code. Because the generated serialVersionUID does change for the most stupid ways (i guess they have to do that but most of the time i don;t care if i added a method) without the id serialization just breaks (can't deserialize) just way more often johan On Thu, Feb 14, 2008 at 4:09 PM, Wang, Yuesong <[EMAIL PROTECTED]> wrote: > Hi, > > In theory, all Serializable classes should have a serialVersionUID, > but to provide one to every annonymous inner class used everywhere in > a Wicket app is just too much. So I decided to turn off that warning > in Eclipse, and not to use serialVersionUID any more, but what is the > implication? For example, will I run into any problem during > deployment/undeployment? What about clustering? > > Thanks, > > Yuesong > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is serialVersionUID really required?
Hi, In theory, all Serializable classes should have a serialVersionUID, but to provide one to every annonymous inner class used everywhere in a Wicket app is just too much. So I decided to turn off that warning in Eclipse, and not to use serialVersionUID any more, but what is the implication? For example, will I run into any problem during deployment/undeployment? What about clustering? Thanks, Yuesong
RE: OutOfMemoryError on FilePageSerializingThread
It's sort of a known issue of Tomcat (or Sun JVM? Which one I can't remember exactly). It happens when one does repeated hot redeployment. Tomcat can't clear the permgen space, so the classes get accumulated and eventually permgen space runs out. Something like that :) There's a lot of dicussion about this on Hibernate and Spring forum. It's defintely got nothing to do with Wicket. Passing the JVM option as Igor said is the way to "fix" it. Yuesong -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 5:24 PM To: users@wicket.apache.org Subject: Re: OutOfMemoryError on FilePageSerializingThread as i said, what i have shown you is an oversimplification. certainly you can try to load the wicket app first, in reality classes are loaded lazily. so load the wicket app first, use it for a bit to make sure it loads whatever classes it needs, then deploy the first and second ears. that should most likely make it crap out when you start using the last ear's app... -igor On Feb 12, 2008 2:03 PM, Vincenzo Vitale <[EMAIL PROTECTED]> wrote: > It means that if I want to "porove" that Wicket is not the problem, we > can try to load Wicket as the first application and then the others. > Should the problem arise always on the last deployed application? > > > V. > > > On Feb 12, 2008 10:53 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > not, this has nothing to do with load. look, your jvm has a preset > > permgen limit where bytecode is stored. lets say that permgen is > > allocated 60 megs, and all these numbers are arbitrary. > > > > first jboss loads all its jars, which arbitrarily takes 30mb. so > > after jboss is loaded you have 30mb permgen left. > > > > then you deploy the first ear that loads all its jars that take up > > 15 megs, now you have 30 jboss+15 ear = 15 megs left in permgen > > > > then you load your second ear whose jars take up 10 megs, so now you > > only have 5 megs left in your permgen. > > > > then you try to load wicket whose jars need more then 5 megs, so you > > get an out of permgen error. > > > > this is a gross simplification, but basically what happens. > > > > permgen is called perm(anent) so it is not cleaned up, once > > something is loaded it sticks. > > > > so really it has nothing to do with load, it has to do with the > > number of classes you try to load into that jvm. the more libs you > > use the more different classes are loaded, the more space you need. > > > > -igor > > > > On Feb 12, 2008 1:17 PM, Vincenzo Vitale <[EMAIL PROTECTED]> > > wrote: > > > Hi Igor, > > > > > > thanks for your fast answer (as usual)!!! > > > > > > So this also means that it's the high load on the bigger > > > applications > > which > > > is causing that *only* the smallest (and less used) Wicket app has > > > at > > the > > > moment the problem. Do you agree? > > > > > > We will try to monitor the usage by all the application deployed. > > > I > > don't > > > know if Jboss has already something with this value available > > > (ideally > > an > > > Mbean). > > > > > > > > > Ciao, > > > V. > > > > > > > > > On Feb 12, 2008 7:18 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > > this memory space is shared by all libs in the vm. so maybe your > > > > ears are taking up a ton of space and only a small amount is > > > > left to the wicket app...its just not the right way to look at > > > > the problem. this is not heap space which is allocated for > > > > runtime stuff, this is the space used by VM to hold bytecode for > > > > classes...it doesnt matter how small the app is or what load it is under... > > > > > > > > -igor > > > > > > > > > > > > On Feb 12, 2008 3:27 AM, Vincenzo Vitale > > > > <[EMAIL PROTECTED]> > > > > wrote: > > > > > Hi Johan, > > > > > > > > > > we proposed the increased memory solution to our IT department > > > > > but > > the > > > > > answer was: > > > > > > > > > > " Why this problem is occurring only with the small > > > > > application > > using > > > > > Wicket?". > > > > > > > > > > We have three ears deployed on the same Jboss instance. One is > > > > > using > > > > Spring > > > > > MVC, one CXF and the admin module is using Wicket. > > > > > Actually the admin module is used by only one person when the > > > > > other > > ones > > > > > have a high load. > > > > > We are using wicket.1.3.0-beta2 and the wicketstuff-dojo > > > > > (1.3.0-dojo > > ). > > > > > > > > > > We actually cannot reproduce the problem in an easy way and IT > > > > > is > > not > > > > sure > > > > > if it's caused by how we are using Wicket. > > > > > > > > > > > > > > > Have you any glue or suggestions on that? > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Vincenzo. > > > > > > > > > > On Feb 4, 2008 12:34 PM, Johan Compagner > > > > > <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > > > > > > > > Its not a normal out of mem but a Perm generation out of mem.. > > > > > > increase your perm
RE: Override external .properties for localization
Maybe you can extend the page, or duplicate the external package in your own code base, and put your localized properties file there? WARNING: I'm a newbie to wicket, so my suggestions might not work at all ;) Yuesong -Original Message- From: Thomas Kappler [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 9:32 AM To: users@wicket.apache.org Subject: Override external .properties for localization Hi, my question seems trivial, but I just can't find anything: how to localize a page or panel that's not my own, but is in a referenced library (like Wicket itself)? For instance, I'd like to have a German version of UserAdminPage in databinder (which provides String resources), so I would write a UserAdminPage_de.properties, but where should I put it and what do I have to do so that it's picked up and used? Thanks, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reloading resource
Thanks. I got it to work by checking Tomcat setting "Serve modules without publishing" in Eclipse. Guess that tells Tomcat to use the files in place(?). Java changes no longer get auto deployed, but that is no a big deal when I have to do a lot of fine tuning of the html pages. Maybe it's time to check out that JavaRebel... -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 2:34 PM To: users@wicket.apache.org Subject: Re: Reloading resource you need to a) point tomcat to some exploded war dir b) make it not redeploy the app if it detects a change c) make sure your ide copies modified html/property files into that exploded war location -igor On Feb 7, 2008 5:13 AM, Wang, Yuesong <[EMAIL PROTECTED]> wrote: > Hi, > > My name is Yuesong Wang. I'm new to Wicket. > > I don't think slf4j has anything to do with it. I have version 1.4.2. > Still when I change an html file in Eclipse, tomcat redeploys the > whole app. In tomcat console I do see > > 08:08:15,536 INFO [main] WebApplication - [WebAdrWebApplication] > Started Wicket version 1.3.1 in development mode > > *** WARNING: Wicket is running in DEVELOPMENT mode. *** > *** ^^^*** > *** Do NOT deploy to your live server(s) without changing this. *** > *** See Application#getConfigurationType() for more information. *** > > > So wicket is running in dev mode. What else do I need to do? > > I am using Eclipse 3.3.0 for JEE + Tomcat6 + Wicket 1.3.1 on Windows XP. > > Thanks, > > Yuesong > > > -Original Message- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 06, 2008 8:19 PM > To: users@wicket.apache.org > Subject: Re: Reloading resource > > On Feb 6, 2008 4:20 PM, gantini <[EMAIL PROTECTED]> wrote: > > > > Resolved > > Incredible. the problem was caused by wrong version of > > slf4j-log4j12 library, version 1.0.1 instead of 1.4.2 > > > > The right libraries is slf4j-api-1.4.2 + slf4j-log4j12-1.4.2 !!! > > I don't understand how that would influence reloading though... > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reloading resource
Hi, My name is Yuesong Wang. I'm new to Wicket. I don't think slf4j has anything to do with it. I have version 1.4.2. Still when I change an html file in Eclipse, tomcat redeploys the whole app. In tomcat console I do see 08:08:15,536 INFO [main] WebApplication - [WebAdrWebApplication] Started Wicket version 1.3.1 in development mode *** WARNING: Wicket is running in DEVELOPMENT mode. *** *** ^^^*** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getConfigurationType() for more information. *** So wicket is running in dev mode. What else do I need to do? I am using Eclipse 3.3.0 for JEE + Tomcat6 + Wicket 1.3.1 on Windows XP. Thanks, Yuesong -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 8:19 PM To: users@wicket.apache.org Subject: Re: Reloading resource On Feb 6, 2008 4:20 PM, gantini <[EMAIL PROTECTED]> wrote: > > Resolved > Incredible. the problem was caused by wrong version of > slf4j-log4j12 library, version 1.0.1 instead of 1.4.2 > > The right libraries is slf4j-api-1.4.2 + slf4j-log4j12-1.4.2 !!! I don't understand how that would influence reloading though... Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
