Re: Re: Wicket libraries stack trace
Hello Gwyn, So after I put wicket-velocity jar in my build path, I`m getting following errors. (I`m using nothing from it and the prove is when I remove it it deploys OK.) ---6.9.2007 11:37:21 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/velocity/app/Velocity at org.apache.wicket.velocity.Initializer.init(Initializer.java:64) at org.apache.wicket.Application.callInitializers(Application.java:808) at org.apache.wicket.Application.initializeComponents(Application.java:638) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:423) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4340) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:566) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) 6.9.2007 11:37:25 org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter HelloWorldApplication java.lang.NoClassDefFoundError: org/apache/velocity/app/Velocity at org.apache.wicket.velocity.Initializer.init(Initializer.java:64) at org.apache.wicket.Application.callInitializers(Application.java:808) at org.apache.wicket.Application.initializeComponents(Application.java:638) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:423) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4340) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:511) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1220) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297) at
Re: Wicket libraries stack trace
On Thursday, September 6, 2007, 9:52:46 AM, Robo [EMAIL PROTECTED] wrote: So after I put wicket-velocity jar in my build path, I`m getting following errors. (I`m using nothing from it and the prove is when I remove it it deploys OK.) ... So please explain me why Tomcat is complaining at deployment time about velocity just including it in the build path? What's happening is that the Wicket Application instance has searched the classpath to read all the wicket.properties files provided. The one in the wicket-velocity jar says initializer=org.apache.wicket.velocity.Initializer, so it's trying to run that initializer instance, but you're missing the dependances. If using Maven, you'd have them, but if not, you can go to MvnRepository (http://mvnrepository.com/) and search which would take you to http://mvnrepository.com/artifact/velocity/velocity/1.4 where it shows that you need velocity-dep-1.4.jar too. That's a useful site to bookmark, whether using Maven or not (probably even more if not!) /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Wicket libraries stack trace
On 06 Sep 2007 11:44:56 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Ok Thnaks for explanation. And do not look for truth in jokes. Jokes are just jokes ;-) But you are not using Velocity panel right? Why do you include that jar in the first place? You can just include the core wicket jar. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries stack trace
And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:09 Predmet: Re: Re: Wicket libraries stack trace On 06 Sep 2007 11:44:56 +0200 (CEST), Robo wrote: Ok Thnaks for explanation. And do not look for truth in jokes. Jokes are just jokes ;-) But you are not using Velocity panel right? Why do you include that jar in the first place? You can just include the core wicket jar. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mozaika storočia denníka SME - http://mozaika.sme.sk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 17:23:13 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Because you seem to be running into trouble with your dependencies. If you include wicket-velocity, you need Velocity (which you could have guessed from the name of the project) and any dependencies Velocity has. If don't include wicket-velocity, you don't need Velocity. It's that simple. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Wicket libraries stack trace
After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \self living\ lib problem. So Eelco we could probably close this thread as my troubles with Hello World are solved, now begins the trouble with demo app. So thanks for help and good product. Demo app will be presented week after next week so we`ll see hov wicket compares to other frameworks. Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 18:17 Predmet: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 17:23:13 +0200 (CEST), Robo wrote: And why not? Besides that Wicket is doing some initialization of not used libraries is there any restriction of not including not neccesary libraries in classpath? Most time I develop someting I have many libraries in my classpath even if I do not use them ... Because you seem to be running into trouble with your dependencies. If you include wicket-velocity, you need Velocity (which you could have guessed from the name of the project) and any dependencies Velocity has. If don\'t include wicket-velocity, you don\'t need Velocity. It\'s that simple. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Sprievodca herným svetom - http://hry.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 18:11:09 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \self living\ lib problem. You can't really depend on libs following such rules. All sorts of frameworks do this, from Guice to Seam to logging libraries, and it can get you in trouble with XML handling as well. As a general rule, only include what you need. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Wicket libraries stack trace
Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Can we finish? As you can see I do not share view of major java programmers but accepting the situation ... :-)) Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 19:08 Predmet: Re: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 18:11:09 +0200 (CEST), Robo wrote: After small troubles I had with it I know it. But from my point of view it is not correct to initiatie not used libraries just by including it in App Server classpath. From my point of view lib is lib, and when nto called by developer it sould not be initiated by App server. I runned into troubles with dependecies SELF initialized itself. I saw this behaviur several times before but everytime I`m suprised. As I said from my point of view, lib is lib. But this guides me to troubles :-) But to be concrete I need to develop demo app using fove frameworks, not using Maven :-), so I put every lib in wicket into lib dir to not to solve missing lib troubles when building demo app. But it raised contrary, unnessesary \\\self living\\\ lib problem. You can\'t really depend on libs following such rules. All sorts of frameworks do this, from Guice to Seam to logging libraries, and it can get you in trouble with XML handling as well. As a general rule, only include what you need. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Mozaika storočia denníka SME - http://mozaika.sme.sk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Wicket libraries stack trace
On 06 Sep 2007 18:32:44 +0200 (CEST), Robo [EMAIL PROTECTED] wrote: Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Sure. You know, if you would just try to have a little bit more of a constructive tone... I'm sure we can patch wicket-velocity so that it avoids pulling in Velocity too early. And maybe the project tries to do too much upfront. Should be pretty easy to fix if you want to create a JIRA issue for it. About calling initializers (that's what triggers Velocity loading in this case), the feature is generally nice. We can use it to e.g. automatically register shared resources or like wicket-jmx does, register resources, so that to enable functionality in that lib is as easy as dropping in a jar. That's pretty cool functionality in my book. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Wicket libraries stack trace
Sorry Eelco but I did not start this small personal war. In my previus of topic marked post I said lot of good about wicket and made lot of PLEASE do this ... I know you have lot of work ... IMHO ... and so on ... Also thanked to Gwyn? ... :-))) Al getted touched about my troubles with Maven, you started to talking b.s. and mindless way of something and started to solve and the same time started to solve some morality questions and so on. Gwyn started to look for truth in Joke :-)) POint me in one of my post when I said about Maven, or your work, that it is b.s. or mindless something. ... YOu will not find it. And also any personal negative sentences towards to any of the developers. I`m not trying to be polite. I`m rying to be correct to people. At the same time you are too polite and agresive ... :-) So after more than 26 hours of programming and mailing I`ll go for a Little bit of sleep. :-)) Bye Robo - Originálna Správa - Od: \Eelco Hillenius\ Komu: Poslaná: 06.09.2007 19:54 Predmet: Re: Re: Re: Re: Re: Wicket libraries stack trace On 06 Sep 2007 18:32:44 +0200 (CEST), Robo wrote: Yes I know Eelco. That is why there are so much troubles in Java programming land. Misusing of basic concepts ... That is why one needs some sort of COC, because there is lot`s of b.s. around ... J2EE 1.4 countained so much of it that lots of developers refused to use it And it had to be rewriten ... Apache Struts ... JSF ... Why did you started Wicket? Did`nt you wrote that MVC is kind of missconceptin? And I ask you Who told that? Eelco Hilenius? Yes and you were probably right. And in that time you with the tapestry was alone against the JSF Struts community. So accpet pleace that someone else is seeing miisconceptions and b.s. in other aspetcs of java programming and habits. OK? :-) Sure. You know, if you would just try to have a little bit more of a constructive tone... I\'m sure we can patch wicket-velocity so that it avoids pulling in Velocity too early. And maybe the project tries to do too much upfront. Should be pretty easy to fix if you want to create a JIRA issue for it. About calling initializers (that\'s what triggers Velocity loading in this case), the feature is generally nice. We can use it to e.g. automatically register shared resources or like wicket-jmx does, register resources, so that to enable functionality in that lib is as easy as dropping in a jar. That\'s pretty cool functionality in my book. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Najpopulárnejší blog na Slovensku - http://blog.sme.sk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
