I've just provided a patch for this on FELIX-1766.
David
2009/10/16 David Bosschaert
> I've created FELIX-1766 for this.
>
>
> 2009/10/16 Guillaume Nodet
>
>> Sounds good!
>>
>> On Friday, October 16, 2009, David Bosschaert
>> wrote:
>> > The offer still stands :) I can try to get it refactor
I've created FELIX-1766 for this.
2009/10/16 Guillaume Nodet
> Sounds good!
>
> On Friday, October 16, 2009, David Bosschaert
> wrote:
> > The offer still stands :) I can try to get it refactored next week. If I
> > don't have it ready in time, we can always put it in a later release...
> >
> >
Sounds good!
On Friday, October 16, 2009, David Bosschaert
wrote:
> The offer still stands :) I can try to get it refactored next week. If I
> don't have it ready in time, we can always put it in a later release...
>
> David
>
> 2009/10/16 Eoghan Glynn
>
>> It would be quite useful to have the A
The offer still stands :) I can try to get it refactored next week. If I
don't have it ready in time, we can always put it in a later release...
David
2009/10/16 Eoghan Glynn
> It would be quite useful to have the AdminServiceMBean.getInstances()
> operation exposed, as it would allow for remot
It would be quite useful to have the AdminServiceMBean.getInstances()
operation exposed, as it would allow for remote probing that a particular
instance has been successfully started. I'm thinking of a scenario where
this probe is done programmatically via JMX/RMI as opposed to manually using
some
I'd like to have it released in the next two weeks if possible.
I think it's better to have more frequent releases than less ;-)
On Fri, Oct 16, 2009 at 11:49, David Bosschaert
wrote:
> When is 1.0.2 planned to be released?
>
> 2009/10/16 Guillaume Nodet
>
>> However, if we have time to refactor
When is 1.0.2 planned to be released?
2009/10/16 Guillaume Nodet
> However, if we have time to refactor it very soon, i would certainly
> have no problem to include it in 1.0.2.
> What I meant is that I'd rather avoid exposing an mbean which is bound
> to be refactored in the near future.
>
> On
However, if we have time to refactor it very soon, i would certainly
have no problem to include it in 1.0.2.
What I meant is that I'd rather avoid exposing an mbean which is bound
to be refactored in the near future.
On Fri, Oct 16, 2009 at 10:30, David Bosschaert
wrote:
> Okidoki, I'll leave tha
Okidoki, I'll leave that one for now.
Cheers,
David
2009/10/15 Guillaume Nodet
> Right, I think I've missed that one while refactoring the JMX layer
> for the features service.
> Unless there is a real need for that now, I would defer to 1.2.0 and
> refactor it in a more coarse grained service
Right, I think I've missed that one while refactoring the JMX layer
for the features service.
Unless there is a real need for that now, I would defer to 1.2.0 and
refactor it in a more coarse grained service, the same way we did for
the FeaturesServiceMBean, so that we'd have a getInstances() metho
Hi all,
While looking at FELIX-1655, I noticed that there is actually an
AdminServiceMBean in the code, but it doesn't seem to be registered with the
MBean Server. Is this done deliberately or is this an oversight or am I
missing it?
I think having this controllable through JMX would be useful -
11 matches
Mail list logo
