Btw, do you have any idea how much work would be required to run the
console as a plain war without osgi?

2011/9/8 Łukasz Dywicki <[email protected]>

> 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
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to