Guillaume Nodet wrote:
Yeah, it should work. Even if not embedded in servicemix,
though I would prefer to avoid hard dependencies on internal
classes. The other solution is to do it with reflection, as done
in AsyncBaseLifeCycle#findExecutorFactory
If you can try to hide this hideous cast
Yeah, it should work. Even if not embedded in servicemix,
though I would prefer to avoid hard dependencies on internal
classes. The other solution is to do it with reflection, as done
in AsyncBaseLifeCycle#findExecutorFactory
If you can try to hide this hideous cast in a common parent class,
Guillaume,
can I do this?
if (isComponentContextImpl(getContext().getMBeanNames()))
{
ComponentContextImpl contextImpl
=(ComponentContextImpl)getContext().getMBeanNames();
}
or is it to dirty? I would have all information then. ;-)
Guillaume Nodet wrote:
Well, i think it will
Guillaume Nodet wrote:
Yeah, sounds good.
Make sure you use the facilities available on
the ComponentContext to create the mbean names ...
Do you have special vision there? What I thought is to have it under the
Type=Endpoint,SubType=Internal or External. But it seems not so easy.
If the mbean
Well, i think it will be difficult without accessing
ServiceMix internals.
Or maybe tweaking with the mbean names factory
available on the component context ? I don't recall what it gives ...
On 3/14/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Guillaume Nodet wrote:
Yeah, sounds good.
Make
Btw, I think i will add an MBean interface for the new
jms consumer endpoints, so that we can change the
number of concurrent consumers on a queue.
So i you come with something interesting ...
On 3/14/07, Guillaume Nodet [EMAIL PROTECTED] wrote:
Well, i think it will be difficult without
On 3/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Peter my colleague asked if you need a switch-filter as an EIP
component. It does nothing more then check a property for message flow.
If this property is true it sends the message to the destination and if
it is false the exchange will be
Guillaume Nodet wrote:
On 3/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Peter my colleague asked if you need a switch-filter as an EIP
component. It does nothing more then check a property for message flow.
If this property is true it sends the message to the destination and if
it is
Well, it sounds good.
What about the JMX stuff ?
On 3/13/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Guillaume Nodet wrote:
On 3/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Peter my colleague asked if you need a switch-filter as an EIP
component. It does nothing more then check a
Yes of course should also be changeable via JMX.
Guillaume Nodet wrote:
Well, it sounds good.
What about the JMX stuff ?
On 3/13/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Guillaume Nodet wrote:
On 3/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Peter my colleague asked if you need
I mean, did you already implement the JMX part ?
Which interface are you exposing to JMX ?
Anyway, you should raise a JIRA ...
On 3/13/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Yes of course should also be changeable via JMX.
Guillaume Nodet wrote:
Well, it sounds good.
What about the JMX
Guillaume Nodet wrote:
I mean, did you already implement the JMX part ?
Which interface are you exposing to JMX ?
Anyway, you should raise a JIRA ...
I didn't implemtet it up to now. But what I want to do is expose an
SwitchPredicateMBean interface where you can change some properties.
What do
Yeah, sounds good.
Make sure you use the facilities available on
the ComponentContext to create the mbean names ...
If the mbean name for this interface could be related
to the endpoint name, that would make it easier to find.
On 3/13/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Guillaume Nodet
---BeginMessage---
On 3/12/07, Thomas TERMIN [EMAIL PROTECTED] wrote:
Hello Guillaume,
did you see my small patch in JIRA?
Yeah, thx.
The next days I will provide the patch for ComponentSupport related to
the correlationID. I couln't make it up to now.
Cool :-)
Peter my colleague
14 matches
Mail list logo
