Hey, I've created in September project called jsr330 [1] for pax-wicket which allows to run wicket applications with @Inject annotations without direct dependency to pax-wicket nor any other dependency injection framework. It's possible to run same code with different injection sources as WAR or OSGi bundle. It uses same concepts as pax-wicket and wicket - scaning for annotations and injecting possible services. Injection provider is set in application factory and might be used also in typical web applications [2]. There is still many things to do, but as you see it is possible to run same code and components in different environments.
Best regards, Lukasz [1] https://github.com/splatch/pax-wicket-jsr330 [2] https://github.com/splatch/pax-wicket-jsr330/blob/master/test/src/main/java/org/ops4j/pax/wicket/jsr330_test/WicketApplicationFactory.java > Hey Guillaume, > You're right we use PaxWicket as an glue to connect all pieces together, but > pax in fact is an wicket extension which manages classloaders and wraps some > elements (look for @PaxWicketMountPoint annotations, @PaxWicketBean). > > Best regards, > Lukasz > > >> If the console can be run without osgi, the problem becomes slightly >> different, I agree. >> If we can provide a basic infrastructure for running the same code in >> osgi and in a war, it becomes very interesting. >> But I thought it was based on pax-wicket which afaik is slightly >> different than pure wicket, but I haven't really looked at it, so not >> sure about that. >> >> Also, camel and activemq consoles are based on top of a rest api which >> is already provided by those frameworks. >> For ServiceMix 5, I was considering going the same direction too. >> >> 2011/9/8 Łukasz Dywicki <[email protected]>: >>> Hey Guillaume, >>> >>> Any tool listed below have own 'management' tool, and that's main problem. >>> We (generaly people involved in webconsole development) wish to propose >>> solution without forcing anybody to using or extending it. It will depend >>> on developers and users community if they will see benefits from webconsole >>> extensions or not. >>> From other hand camel svn repository contains code which is stricly related >>> to Karaf - the commands and some community members support it even if not >>> everyone uses it. In fact 50% of camel code is not widely used, but that is >>> not reason to remove it from source tree, isn't? >>> >>> I think also we will be able to provide *web* distribution of webconsole >>> without bigger problems. Code uses plain wicket structures and may be >>> embedded in any WAR so it may be easier to switch webconsole from osgi to >>> war than servicemix from osgi to tomcat. >>> >>> Best regards, >>> Lukasz >>> >>> >>>> 2011/9/2 Łukasz Dywicki <[email protected]>: >>>>> Hey guys, >>>>> Since we have bunch of features in current prototype I would like to >>>>> start talking about roadmap and other communities involvement. >>>>> >>>>> What we currently have: >>>>> - Security layer integrated with JAAS, also with support for roles (based >>>>> on Ioannis jaas-blog example). >>>>> Every subpage can have different set of principals allowed to watch >>>>> it - for example we can introduce karaf-manager and developer roles and >>>>> so on. >>>>> - Support for basic OSGi operations >>>>> Start, stop, refresh and uninstall operations on bundles >>>>> - Extensible bundles view which allows to add new columns >>>>> As an example you can check blueprint module >>>>> - Support for basic karaf operations >>>>> Viewing, installing features, listing repositories and adding new >>>>> ones >>>>> - Extensible dashboard with widgets possible to be added dynamically by >>>>> webconsole modules >>>>> - Example ServiceMix extension which lists endpoints, exchanges and >>>>> exchange details >>>>> - Support for translations throught wicket i18n mechanism >>>>> - Support for branding based on OSGi BrandProvider services, not only on >>>>> fragment resource overrides. >>>>> >>>>> Felix WebConsole contains much more features eg. viewing the logs, >>>>> editing the configurations (it's broken currently in our case) managing >>>>> Karaf instances and so on. I started thinking about announcing our work >>>>> to these user communities who may be interested in extensions. With them >>>>> we can discuss scope of webconsole (and their extensions). I think we are >>>>> close to stabilize core APIs and start working on first version which >>>>> should be released before end of this year. >>>>> >>>>> Communities which may be involved: >>>>> - servicemix (especially in context of smx5) >>>>> - camel >>>>> - felix >>>>> - sling >>>>> - geronimo (since it is OSGi based) >>>>> - activemq? >>>>> - cxf? >>>> >>>> Afaik, Geronimo has its own console. >>>> Camel and ActiveMQ are not OSGi based so I doubt they could benefit >>>> from this work. >>>> For ServiceMix, we were also discussing allowing ServiceMix added >>>> value to run on non OSGi based deployment such as tomcat, so that may >>>> be a bit problematic too. >>>> >>>>> WDYT, are we ready to ask them for help and cooperation? >>>>> >>>>> Best regards, >>>>> Lukasz >>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>> >>> >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >
