Thanks for all answers. I think OSGi is to much overhead for my needs. Joint fits more my needs, but includes unneeded overhead (for my project). I think I will implement my own mechanism with using a custom ClassResolver, cause I just need to search in new added jars (URLClassloader), Authorizationstrategy for security and a class the recursivly mounts a whole package on a given basepath which is extended with the package structur of the plugin (this structur includes a unique path so no collision will happen).
But thanks anyway for ideas! Chris -----Ursprüngliche Nachricht----- Von: Ben Tilford [mailto:bentilf...@gmail.com] Gesendet: Montag, 2. November 2009 16:45 An: users@wicket.apache.org Betreff: Re: OSGi Wicket You might want to check out http://kenai.com/projects/joint the wicket example builds a menu system based of pages / links that are on the classpath which implement a Navigatable interface and have the @Navigation annotation. Still very early in development but it still might do what you need. On Mon, Nov 2, 2009 at 2:29 AM, Giambalvo, Christian < christian.giamba...@excelsisnet.com> wrote: > 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:reier...@gmail.com] > Gesendet: Sonntag, 1. November 2009 06:40 > An: users@wicket.apache.org > 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 <wic...@leangen.net> 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 <tomas.mi...@cnl.tuke.sk>: > >> > >>> 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: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
