Johan was right in his concerns about how the classloading would work. I can't see a non-hackish way to what I proposed. And registering class loaders (instead of the current scope class) is even uglier and I'm not sure what kind of problems we might run in to when we start keeping references to classloaders.
Luckily, Johan fixed the issue I stumbled upon, so package resources work again, and package resources are improved at least to some extend in that you can now register using a regexp, for instance, all .js, .css, and .gif files in a directory. It might be something to investigate further in 1.3/ 2.0, and then we should take OSGi's classloading into account specifically. By the time we get there, it might be nice to have some OSGi wizards working with us on it. Eelco On 3/10/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Hi guys, > > This is basically a copy of an email I sent to the admin list earlier > today. It seems that my latests 'improvements' freaks out Tomcat and > other servers. > > WARNING: So for those that are working directly on HEAD: please roll > back to the first beta Martijn put out a couple of days ago. > > Here is the mail that tells what I am plan to do now: > > ' > I've really had it with package resources. I improved them some last > week; generally made it easier to register a bunch of them, but it's > still a lot of work every time you make a custom component, and > moreover, the pre-registering that I built in has severe problems with > some application servers (seems like classloading problems, and I > found similar issues in a Spring bug report). > > What I am suggesting now is this: > > The idea would be to be able to access package resources just by url. > Same as we can do now, but without the need the pre-register them and > for security, layer filters a la FileNameFilter, with a default > implementation based on extensions and/ or regexp > > The default configuration would allow images (.gif .jpg .png) and > javascript (.js) and stylesheets (.css) to be pulled from the > packages. The configuration should be doable with one statement > application wide but overridable up to the scope of a single resource. > > Igor agrees with this, and I think Jonathan too, as he came up with > this two days ago. And if I remember correctly, Johan, didn't we > discuss something like this last year too? > > Anyway, if there are no big objections to this, I'd like to go forward > with this change. It wouldn't break the API and current HEAD is > dangerously broken anyway. > ' > > Eelco > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
