First wi try to do it through the context classloader:
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null)
{
loader = getClass().getClassLoader();
}
if that isn't there we try it through getClass().getClassLoader() of you
Application object.
Maybe we should it more resilient that it falls back on as much classloader
as we can find..
But sharing jars is not a good thing anyway. Because what happens if other
webapps are deployed
that don't use the exact wicket version as you have deployed in the shared
lib?
In development you can use tomcat with the tomcat launcher :
http://www.sysdeo.com/eclipse/tomcatplugin
or just use the build in jetty. See the quickstart of wicket how to use
that.
But in deployment make a war with all the jars yes. I wouldn't depend on
external libs.
As for that security thats very strange by default i don't have to change
any security settings in tomcat.
If you can't use reflection that i think most webapp frameworks won't work.
johan
On 2/12/07, Gabor Szokoli <[EMAIL PROTECTED]> wrote:
Hello Everyone,
I am new to web programming in general, and took it upon myself to
learn servlet programming with wicket.
I am using tomcat as my target environment, because it is much more
likely to resemble a production system than Jetty is. (I do however
have a running quickstart environment for reference, and think it's a
great learning aid, keep it up!)
The local java community helped me find out that I can't keep the
wicket jar files under $CATALINA_BASE/shared/lib as the tomcat
documentation suggests, because the ContextParamWebApplicationFactory
uses the default classloader instead of the context classloader set up
by tomcat. It has been discussed before near here:
http://www.mail-archive.com/wicket-develop@lists.sourceforge.net/msg07325.html
I was just wondering what came of it, and where do I chalk up a "me
too": an init-param to instruct WicketServlet which classloader to
use would be nice.
If there is such a thing as a wicket-on-tomcat-howto, it should
probably mention you have to keep a copy of the wicket jars under
WEB-INF/lib of each webapp for now.
And that you must enable reflection, or turn the security manager off
altogether in tomcat for wicket PropertyModels to work.
And that unit tests attempting to instantiate wicket classes outside a
servlet container need the commons-logging.jar on their classpath to
run.
And whatever I'm gonig to come across today :-)
Gabor Szokoli
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
