Note: reposted to ops4j to get their input. This thread is about the state of Wicket+OSGi, specifically regarding classloaders. I have stated my opinion, but thought it would be a good idea to include the core developers working on this project.
> even that solution is technically a "hack" correct? that and dynamic > imports and all that stuff that you need to do to make it work. Yes and no. The idea seems ok, but the developers haven't yet fully followed up on it, so the result is that the current state of the code is a hack (IMHO), but with a little work, it could be turned into a correct solution. Just as an example, currently proxied classes cannot be serialized. One can work around this, but it's a bit of a PITA. Another example is that if two bundles provide a class of the same name, there is currently (AFAIU) no way of determing which bundle should handle the serialization for that class. If enough people show their interest, maybe this could be moved up on the priority list. :-) They are committed to pax-wicket, but I think their team is very busy right now, so it's just question of priorities. > thats too bad. i havent been following osgi closely to be familar > with all > the problems. you would think there would be something like > OsgiObjectInput/OutputStream that is provided by the platform to > handle this sort of thing. Hopefully that will come soon. I tend to agree with you, so hopefully if ops4j doesn't fix this soon, maybe somebody else will. (I wish I had the time...) Like you point out, the ideal thing would be to have a generalized solution that would work with any Wicket+OSGi setup, IMO... Cheers, =dml _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
