It would be a good solution. In addition to addressing current concerns, it will address all future class-loader related issues by establishing a pattern.

Alexei

On 3/31/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
why dont we switch those 3 pointed out places to use the IClassResolver?

-Igor



On 3/30/06, Gwyn Evans < [EMAIL PROTECTED]> wrote:
It certainly sounds as if it's something we should take another look
at (post 1.2/1.3, anyway).

I've got some memories of (Eelco?) having looked into a few months
ago, and some issues (but not what issues) having been seen then, so
maybe we'll need some form of strategy-based solution, rather than
just a straight-forward switch?

If no one's yet done so though, please raise an RFE, as that keeps it 'visible'.

/Gwyn

On 30/03/06, Niclas Hedhman < [EMAIL PROTECTED] > wrote:
> On Thursday 30 March 2006 07:10, Alexei Sokolov wrote:
> > I'm working on integrating Wicket into OSGi container.
> > Classloader schema in the container is more complex
> > than the one used by j2se app servers, so simple
> > Class.forName does not always work.
>
> We are also working on this (Wicket in OSGi) and our solution involves
> replacing the Wicket ClassResovler with our implementation that deals with
> the underlying framework (in our case OSGi). So, it should be fairly easy you
> to use the Thread.contextclassloader there if you like.
>
>
> Cheers
> Niclas


-------------------------------------------------------
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?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop


Reply via email to