On Friday 22 September 2006 13:02, Eelco Hillenius wrote: > > Btw, is Wicket 2.0 still scheduled for native OSGi support in some form > > similar to what Pax Wicket offer?? > > The problem is that I'm merely a lurker here, in case anything Wicket > specific comes up etc. I wish I had more time to look at what Pax > Wicket does in detail, but so far I haven't found any. And that's the > same for the other Wicket committers.
The primary 'interesting' bit is that instead of programming the Wicket components, Pax Wicket programmer establishes a "Model" of how the Wicket components are to be assembled, and making it easy to modify that model in runtime. > However, we would greatly appreciate any help when it comes to > supporting OSGi in the best way we can. Are there any specific things > you are thinking about at this moment? Any pointers to areas than can > be improved? And how does the constructor change affect Pax Wicket? I am not sure. If we stick with Pax Wicket as it is, I don't think it changes anything significant to do add() or constructor injection. It happens in the same sequence for us anyway. What I was perhaps hoping for was a 'strategy' of how higher level dynamicity can be achieved in Wicket thru usage of OSGi. Pax Wicket is probably not the best way, just 'one way' possible using the Wicket 1.1/1.2 features unmodified. What Pax Wicket support today is that the client application can be broken up pieces and those parts are replaced on the fly without restarting the entire application. It is also easy to separate the business logic from the view, and hence get a better architecture in general. The main missing part is that if Wicket is upgraded, e.g. from 1.2.1 to 1.2.2 the Pax Wicket Service bundle will be reloaded and ALL client bundles will be stopped, reloaded and restarted isnce they all reference wicket classes directly. We have been sketching opn elaborate schemes on how to support upgrades of the Wicket classes without reload of the client bundles, but that quickly becomes a large unwieldly mess of Bridge pattern and slow routings. The obvious OSGi-centric choice would be a Wicket that has full separation of API from implementation, so that the implementation can be reloaded, but not the API, without reloading the client bundles. However, then the general approach would go from; Button b = new Button( parent, id, label ); to ButtonFactory factory = ... // get hold of it IButton b = factory.create( p, id, label ); which probably has little support in the general Wicket community, unless there is both... public class Button implements IButton And that the interface classes are placed in one bundle and the implementation classes in another. Finally, getting the factory in normal Wicket would probably then be with Spring, and the OSGi community would do it with Service lookup. Introduction of interfaces would mean a lot in OSGi terms, but I understand that it could be felt unnecessary in Wicket community at large. > We could open up a discussion either here or - probably better - on > the wicket-develop list to discuss this. You have so much traffic there :o) Hard to keep up, even though I try to look out for topics that interests me. > As a side note, we're nearing 2/3rd of Wicket In Action, and in the > last part, which will be written over the next three months, we're > still considering writing something about Wicket and OSGi. In that > respect, I would be very interested to learn about how people use OSGi > and web applications together. What are the pro's and con's, and in > what kind of scenarios did you use it? Not sure that it has been used that much in professional deployments yet. ScanCoin is however one deployment inside cash handling machines (ATMs and such), where the UI components are loaded and discovered via UI provider bundles. For instance; Each hardware component provides its own troubleshooting panel, which gets added onto an AjaxTabbedPanel. In machines where the hardware is not installed, the bundle that handles the hardware is not loaded and no panel in the UI. Due to the flexible Pax Wicket model, this is very easy to express, as one can 'wire' the Pax Wicket "Content" to "ContentContainers" in runtime and don't need to know where it is going to reside in the larger picture. "Content" is essentially a model of a Wicket component, and the "Content" will be asked to assemble the Wicket component in the hierarchy it sits at request time. Cheers Niclas _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
