On Tue, Mar 15, 2011 at 10:26, Achim Nierbeck <bcanh...@googlemail.com> wrote: > Hi, > > did I get that right, you plan to use Karaf as a OBR Server? > Cause right now I think we are more used to use OBR from the client view, > right? > > Concerning the central Manager for other instances of a clustered > environment. Do we really want to > have a Managing instance like in the "good old days of JEE servers" or > do we want a more P2P approach? > > So I'm unsure if we need that or if we just need a way of > "synchronizing" all instances. For Provisioning inside the "cluster" > it might be a good Idea to use OBR.
OBR is not a provisioning system. It's just a resolver API. It only helps finding what actually need to be deployed. > Regards, Achim > > 2011/3/15 Jean-Baptiste Onofré <j...@nanthrax.net>: >> Hi Guillaume, >> >> my vision is: >> 1/ only add an optional feature to be able to use Karaf OBR as an Enterprise >> OBR (including RESTful, web administration) >> 2/ regarding the Karaf clustering, it could be interesting to have a central >> Karaf manager providing a central OBR >> >> The things that you described look good to me. Maybe just more documentation >> and more user-friendly tooling (in the WebConsole and with new obr: command >> in addition of list) could be enough :) >> >> Regards >> JB >> >> On 03/15/2011 08:56 AM, Guillaume Nodet wrote: >>> >>> On Fri, Mar 11, 2011 at 17:41,<j...@nanthrax.net> wrote: >>>> >>>> Hi guys, >>>> >>>> Correct me if I'm wrong but, currently, we have an OBR into Karaf. >>> >>>> I wonder if it could be interesting to extend this OBR in a more >>>> enterprise oriented way (as an optional feature) with: >>>> - RESTful service to administrate the repo and upload/download bundle >>> >>> The web console already offer a REST api afaik, but it could be made >>> more formal. >>> I also worked on something related a few months ago: >>> http://gnodet.blogspot.com/2010/09/remoteobr.html >>> More below. >>> >>>> - support of kar and features descriptor >>>> - JNDI lookup support >>> >>> JNDI is kinda legacy in OSGi, so not sure how it relates to OBR. If I >>> have to write new OSGi specific code, I wouldn't use JNDI at all, as >>> it can't really handle the dynamic nature of OSGi well. >>> >>>> - LDAP lookup support >>> >>> LDAP to do what ? >>> >>>> - management/extension of the existing obr page in the web console >>> >>> >>>> I don't know if we need to implement by ourself or embed an existing >>>> project (felix bundlerepository/ace, archiva, aries obr, others ?). >>> >>> Not sure which location would be best, but I would certainly not see >>> that in Karaf trunk, but eventually as a new subproject (if it ever >>> ends up in Karaf). >>> >>>> Anyway I think it could be interesting to turn Karaf into an EBR >>>> supporting remoting, management, etc. >>>> >>>> Wdyt ? >>> >>> OBR is really nice, but repositories could tend to be big and loading >>> the repository internally can consume quite a lot of resources. >>> That's why I've tried to split it in two parts: the client which can >>> connect to a server over a REST protocol. It's far from production >>> ready but that could give us a starting point. >>> At that time, I've also rewritten the OBR plugin for the webconsole so >>> that it can handle complex queries, displaying dependencies and all. >>> >>> I'm not quite sure to understand what your vision is. The webconsole >>> already offer a lot of features to manage the repositories and see the >>> dependencies. I'm sure it could be rewritten to be more user >>> friendly, but in terms of big features, what do you see added to it ? >>> >>> >>>> >>>> Regards >>>> JB >>>> >>> >>> >>> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
