Yes that was the idea.. That you have to delegate there through all your classloaders.I implemented your change by first using the objects classloader.. then fall back to what we did now.So that should help your case. When a page (by total) comes from one plugin/package
The only problem is when a
yeah i think that should do it. you think it will have a noticable
impact on the size of our cloned objects? maybe output null if the
object's classloader is the same as our default one to save on space.
-Igor
On 7/22/06, Johan Compagner [EMAIL PROTECTED] wrote:
Yes that was the idea.. That you
it won't impact the size of the cloned objects at allIt is just a list (or better set) of classloaders thats is registered and hold on to for only that cloneXXX methodnothing more. So the only thing that will be generated and discarded quickly is a List or Set holding the Classloaders.
johanOn
ah, i see. you are just registering them. i thought you were going to
include it into the cloed object itself. i think we still need to keep
the record of what the object's classloader was in case there are
objects with the same name in more then one classloader. so maybe as
you build up this list
hmm same name??So igor.i.am.the.one.MyGreatObjectdoes have 2 instances in somewhere in the cloned object hierachy but they are comming from different classloaders??That would really suck. I wouldn't know how to handle that currently.
Because at register time i just get a replaceObject(Object o){
I'm afraid I don't get the request. Could you please create a feature
request with a patch, clearly explaining what is wrong today and what
your patch fixes?
Thanks,
Eelco
On 7/17/06, Ittay Dror [EMAIL PROTECTED] wrote:
Hi,
We're using plugins similar to Eclipse's to decouple functionality.
done. the request id is 1524019.
i've added more description of the problem and the solution. i think this may
happen also with osgi integration, or any other case where an object is used
that is found through a classloader different than the one wicket / tomcat is
in.
Eelco Hillenius wrote:
we do have IClassResolver woudnt that help? it helped with osgi-IgorOn 7/17/06, Ittay Dror [EMAIL PROTECTED]
wrote:done. the request id is 1524019.i've added more description of the problem and the solution. i think this may happen also with osgi integration, or any other case where an object is
if the deserialization uses it, then maybe (i'm not sure how it is used). but
in our case, every Page subclass may be in its own class loader, separate from
others, so using a singleton IClassResolver instance will not help (unless it
delegates to all class loaders, which may cause havoc). i
