This is just bad. Because now a webapplication can run fine in the developer or on WebServer X but suddenly completely stops working when deployed on WebServer Y.
We already had many packages problems suddenly nullpointers everywhere that didn't happen in other situations but did happen suddenly in that.
This is very unpredictable behaviour
So if we don't like mountPackage(String path, Class clazz) then maybe mountPackage(String path, String packageName)
Or is that the same then an other we have now?
Then we should warn people that instead of mountPackage with the Package param can be the one that doesn't work with other/specific classloaders.
johan
On 12/11/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
i think mountPackage(String path, Class clazz) looks funny. where is the package you are trying to mount? i think it is up to the user to provide a package with a valid name, if the package has an empty string for the name it will be mounted as / . we can also pirnt out a warning in the log. i will factor in mount path into the encoder so that we do not have to keep it in two places.
-Igor
On 12/11/05, Johan Compagner <[EMAIL PROTECTED] > wrote:This method has to be rewritten:
public final void mountPackage(String path, Package packageToMount)
{
if (!path.startsWith("/"))
{
path = "/" + path;
}
mountPath(path, new PackagePathMountEncoder(path, packageToMount));
}
to not use the Package object (so that users don't have to do MyClass.class.getPackage())
Because getPackage() doesn't have to return the package it can also return null (and we know that because we already had these problems in wicket!!)
So my fix would be to also give the class object in that method:
public final void mountPackage(String path, Class classForThePackage)
{
if (!path.startsWith("/"))
{
path = "/" + path;
}
mountPath(path, new PackagePathMountEncoder(path, classForThePackage));
}
and then we can look inside our code if the Package object is there or else extract it as a string from the classname.
johan
