Maybe OSGi ist o much overhead for my needs. I just want to be able to load WicketPages from a jar during runtime. Lets say i have a wicket app with just the wicketapplication and a homepage (extendable through plugins (jar)). Then during runtime i dropin a jar containing some Pages and i want wicket to be able to reach them. My idea is to to just add the jars to the classloader searchpath and let wicket do the rest. Is this a naive idea or whats the wicket way?
Igor wrote (some time ago): "what we have in wicket is a IClassResolver which we use to allow for pluggable class resolution." How can this pluggable resolution be accomplished? Greetz and thanks -----Ursprüngliche Nachricht----- Von: Ernesto Reinaldo Barreiro [mailto:[email protected]] Gesendet: Sonntag, 1. November 2009 06:40 An: [email protected] Betreff: Re: OSGi Wicket I do agree Eclipse buddy system in not proper OSGi, but it makes a lot easier to develop applications because 1- Your application, components, etc, will be same as in any normal Wicket application (no changes to are needed) 2- If you find out OSGi is not suitable at the end, you can always build the same application dropping OSGi and using the same (component) factory services. You will loose hot pluggability and that's it. I never hit serialization limitation myself. On the other hand, I do know from experience that integrating with certain application servers (using bridge approach) can be challenging. This is also something to take into account before deciding to use osgi. I think Igor is totally right about the things you should weight in deciding whether to use OSGi or not for a project. OSGi is a way to achieve pluggability but not the only one. Best, Ernesto On Sun, Nov 1, 2009 at 2:27 AM, David Leangen <[email protected]> wrote: > > If you do go with OSGi, you will have problems with classloaders and > deserialization. > > To my knowledge, nobody has yet solved this (i.e. implemented a good > solution) in a decent way. The Eclipse buddy system is not "proper" OSGi, > IMO. > > pax-wicket does "solve" this problem (using "proper" OSGi), but I have > never used their approach much even though I use the framework. > > Here is a post about this by me with some interesting comments from Igor: > > http://bioscene.blogspot.com/2009/03/serialization-in-osgi.html > > > Good luck to you! > =David > > > > > On Nov 1, 2009, at 3:26 AM, Igor Vaynberg wrote: > > it is easy to create a pluggable application in wicket. all you need >> is a registry of component providers, whether it be something like >> spring [1], a custom registry like brix uses [2] or something more >> advanced like osgi. the choice should be based on the featureset you >> need. eg, if you need hot updating, classloader separation, etc, then >> osgi is good. if not, there are simpler ways to achieve modularity [1] >> [2]. the great news is that wicket lends itself easily to >> modularization. >> >> [1] >> http://wicketinaction.com/2008/10/creating-pluggable-applications-with-wicket-and-spring/ >> [2] http://code.google.com/p/brix-cms/source/browse/#svn/trunk/brix- >> core/src/main/java/brix/registry >> >> -igor >> >> 2009/10/29 Tomáš Mihok <[email protected]>: >> >>> Hello, >>> >>> I'm currently designing a new application. One of the requests is to make >>> it >>> modular. I found out that one of the possibilities to enable loading of >>> modules while application is running is OSGi. Is there a >>> tool/plugin/guide >>> to accomplish this or are there any other possibilities of accomplishing >>> same goal? >>> >>> Tom >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
