RE: [Wicket-develop] Wicket and OSGi / Eclipse

[Jens Schmidt]

Not sure if this helps since it’s not directly OSGi (however, built on top if it), but we have had success wrapping Jetty into an Eclipse plug-in that allows dynamic contribution of web apps:   One of these web apps is Wicket, and in order to deal with the class loader issues we had to introduce a custom class loader (using the PluginClassLoaderWrapper as a starting point, see http://www.koders.com/java/fidF1EC15E4B7935CCD8213200FF6A7E3B656BC87E2.aspx)) that we use as the Jetty HttpContext classloader (using setClassLoader()). This class loader follows the bundle/plugin dependencies to lookup classes.   Another related issue we had to solve is that we wanted to contribute Wicket Web Pages from various plug-ins using extensions. This was solved by setting the default class resolver in wicket.protocol.http.WebApplication to a custom class that internally again uses the PluginClassLoaderWrapper to locate classes. This allows us to build web applications just like Eclipse itself allows extending the IDE. If there is interest I can share code samples (would love for someone to review the approach).   We are planning to release part of our Eclipse plugin code base as open source (after it is cleaned up a bit more), but maybe the pure OSGi version is solid enough soon in which case I’ll be happy to convert our code base to use it… - Jens   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Compagner Sent: Sunday, May 21, 2006 12:20 AM To: wicket-develop@lists.sourceforge.net Subject: Re: [Wicket-develop] Wicket and OSGi   Hmmm... A "version" is probably a key word here, that I don't fully understand. The real question is; Does ALL page creation happen through the IPageFactory.newPage() methods? I suspect not, since everything is required to be Serializable, which means that deserialization is another way the page can be created. And if so, what is the "user result" if the deserialization fails? Also, the deserialization would require to load the classes that makes up that serialization stream, unless it is a MarshalledObject which keeps the codebases for each classloader involved in the serialization. Any pointer to the answer of these thoughts? I also guess that the developer can keep the page around indefinately, just by adding/removing content on the same page. Is that correct? First the pagefactory is only used by wicket to create bookmarkable pages. After that it is the developers choice what to do. Of course he can use it also but i guess 99% of the devs do just: new UserPage(user); second a page records changes to itself through its version manager. This works just as the Undo Support of Swing. So it has a list of Change objects and in that change object the previous value is kept. (like a previous panel that was replaced) and when we encounter a request to a previous value we say to that change undo yourself. Then that change will get its value and set that value back where it was. Then the page is again in the previous state, because all changes are rollbacked. Look at the VersionManager of the page and its related classes. About serialization: Are you using OSGI on top of the web app (so inside the webapp) or do you run the server itself in OSGI? Because if you do the first then you have a big problem. Serialization will work. But deserialization will not work. Because you introduce classloaders inside the webapp. This is fine as long as those classloaders don't supply classes that makes objects that are stored in the session. Because how can the servlet container then find those classes? As far as i know there is no solution for that except having full control over the servlet container itself.. > As i said before you can do as much as you like alter the structure of the > page as you like (replacing panels and so on) > that is no problem. Just know that if you want backbutton support you must > also let the page version itself when it is changed > (this is done by default) Cool. We have the notification mechanism for that thought out, just need to make it work, and some examples. So, that includes removing components outside the request cycles? Thread-safe? First if all it is not thread save by default. Second the version manager will not work correctly. But the latter is something you want to by pass anyway. So if you change pages do turn off the version managment for those changes and sync the page around its session object.  (that is pretty much what we do also when accessing the page) So then it should be thread safe. johan