Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <56516E62.3070404@die-schneider.net>
References: <564F2B7F.8060000@die-schneider.net>
	<CAA66TpozhSGTKPpc787hfSF1tpCOspeyJszCBfUhbC2-1fv+kA@mail.gmail.com>
	<56516E62.3070404@die-schneider.net>
Date: Tue, 24 Nov 2015 15:29:07 -0500
Message-ID: 
 <CAKF+bsriVUHLQ8WZUToZs+j5JZXicF5GHoPY39JKuG7zLZLb8g@mail.gmail.com>
Subject: Re: Artemis OSGi: Prototype available
From: Clebert Suconic <clebert.suconic@gmail.com>
To: "dev@activemq.apache.org" <dev@activemq.apache.org>,
 chris@die-schneider.net
Content-Type: text/plain; charset=UTF-8

I ran a few tests with this and it seems fine (hence I merged it).

just one thing on this.. I think it we could add more tests.. (and
maybe one example, since that has double purpose.. docs and indirectly
gives us nice smoke tests)

I think we could improve this further by bumping the release into 2.0
next year and fix these packages. We should have a release soon with
the current master, and if we bump the release as 2.0 we can make
small changes to the API. (I don't think we should do any drastic
changes).


On Sun, Nov 22, 2015 at 2:27 AM, Christian Schneider
<chris@die-schneider.net> wrote:
>
>
> Am 21.11.2015 um 11:28 schrieb Guillaume Nodet:
>>
>> Good work !
>>
>> A few remarks:
>>    * the native bundle needs some specific headers for loading the native
>> libraries I think
>
> I have not looked into the native module in detail but most probably yes.
>>
>>    * the protocol tracking needs to be done with a real service tracker,
>> shutting down the server if the protocol service is unregistered, and
>> waiting for the protocols needed in the configuration (and printing a log
>> message to know  what the configuration is waiting for)
>
> Yes. That part needs to be improved. Currently it is too brittle and also
> does not cope with changes once artemis is up.
>
> This is what have in mind for it:
> 1. Read the config and find the needed protocols. I hope we can use the
> existing FileConfiguration for this and extract the information
> 2. Create a service tracker that tracks all ProtocolManagerFactory services
> and for each service added / removed checks the difference between
> the wanted and present protocols. While not all needed protocols are present
> it can print that the server can not yet start as a list of protocols is
> missing.
> 3. Once the last missing protocol comes up the Artemis server is started
> 4. When one of the necessary protocols goes down the Artemis server is
> stopped again
>
> So this should then be able to adapt to changes.
>
> At a later point we can think of changing the Artemis design so it can adapt
> to protocol availability without restarting Artemis. So the server could
> start without the protocols and
> add and remove them online. I do not think we strictily need this to get
> started with OSGi though.
>
>>    * the protocol factory services need to have a list of protocols on the
>> properties (those obtained from ProtocolManagerFactory#getProtocols() so
>> that they can be tracked correctly I think
>
> I think we can do without the properties on the service level. We can simply
> track all services and
> ask each service for the protocols it supports.
>>
>>     * i think we should provide a ready-to-use feature with default
>> configuration, such as ActiveMQ provides (installing the default config in
>> etc/artemis.xml and needed configadmin config for the broker factory)
>
> +1
>
>
> Christian
>


-- 
Clebert Suconic