The only thing that the spec says it that the component should use the MBean
server given by the context and create the MBean name using the MBeanNames
attributes. The component is responsible for registering / unregistering
the mbean, so there is really no problems here.
Cheers,
Guillaume Nodet
On 5/19/06, William Blackburn <[EMAIL PROTECTED]> wrote:
Forgive me for intruding, but I just this morning figured this one
out, at least for servicemix 'pojo' components.
I created my component as usual, extending 'ComponentSupport' - we'll
call it 'TestComponent'.
I then created a new interface called 'TestCompoenntMBean'
I implemented the mbean interface in 'TestComponent'
I then added the following overrides to init and shutdown in
TestComponent:
public void init(ComponentContext cc) throws JBIException {
super.init(cc);
ObjectName name = getContext().getMBeanNames
().createCustomComponentMBeanName("MyExtensionName");
this.setExtensionMBeanName(name);
try {
getContext().getMBeanServer().registerMBean(this, name);
} catch (InstanceAlreadyExistsException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (MBeanRegistrationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (NotCompliantMBeanException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
public void shutDown() throws javax.jbi.JBIException {
super.shutDown();
try {
getContext().getMBeanServer().unregisterMBean
(this.getExtensionMBeanName());
} catch (InstanceNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (MBeanRegistrationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Now when I look at 'TestComponent' in JConsole, I see a third MBean
interface, on which I can access all my custom attributes and
operations.
This may not be a strictly spec compliant way of doing things, and
its an extra-credit exercise to add support for attributeinfos and
operationinfos, but its working well so far.
BJ
On May 19, 2006, at 9:51 AM, Doug Fischer wrote:
> Guillaume,
>
> I think that I am very confused now. Please bear with me while I
> try to
> understand.
>
> First, let me explain what the problem is that I am attempting to
> solve with
> ServiceMix. I know that I have described this before however a
> couple of
> other requirements have appeared so I want to make sure I explain
> it again.
>
> I need to create a number of binding components. These binding
> components
> will basically all connect in the same way, over a socket. This is
> why I am
> interested in creating a socket component. Each one of these binding
> components will be configured with a host, a port, and a number of
> other
> properties. These components need to pull data from the stream and
> post it
> to the bus. I would like to have the ability to manage these
> components
> through JMX, change the host, the port, or any other property that is
> exposed. In addition to that, I would also like to be able to
> create and
> remove these components through JMX dynamically. All properties
> will need
> to be persisted so that when the server is restarted, all of these
> components still exist.
>
>
> What I have implemented so far:
>
> I have created a class that extends the ComponentSupport class. I
> am using
> MINA ( http://directory.apache.org/subprojects/mina/index.html ) to
> connect
> and manage the socket connection. I have basically modeled this
> component
> after the other components in the org.apache.servicemix.components.*
> package. This seems to be working quite well right now. So I have
> the
> ability to deploy a component in ServiceMix that will connect to
> the socket
> and push data to the bus. In the jbi.xml file for the
> service-assembly/service-unit/target I have the following:
>
> <target>
> <artifacts-zip>myServiceUnit.zip</artifact-zip>
> <component-name>servicemix-lwcontainer</component-name>
> </target>
>
>
> What I am confused about:
>
> You said in the previous email that I could model my JMX
> configuration for
> my socket components the same way as the servicemix-http
> component. Does
> this mean that I should create something like a servicemix-socket
> module
> (set up basically the same way as the servicemix-http module) as a
> standard
> JBI compliant component, install this component in servicemix and then
> deploy a service assembly onto it? If this is the case, how can I
> configure
> the specific binding components through JMX?
>
> I really appreciate you help with this and I would like to thank
> you for any
> answers that you can provide.
>
> Thanks,
> Doug
>
>
> On 5/19/06 11:16 AM, "Guillaume Nodet" <[EMAIL PROTECTED]> wrote:
>
>> Well, this has not been done for lightweight components.
>> Take a look at the servicemix-* std jbi components (servicemix-
>> http for
>> example).
>> They have a persistent configuration exposed throught jmx.
>> You should be able to mimic the same for lightweight components if
>> you need.
>>
>> Cheers,
>> Guillaume Nodet
>>
>> On 5/19/06, Doug Fischer <[EMAIL PROTECTED]> wrote:
>>>
>>> I would like to be able to expose a number of configuration
>>> properties
>>> through JMX for my component. I saw the post "extending JMX
>>> attribute
>>> from
>>> pojosupport" but I was wondering if someone could get a little more
>>> specific
>>> about doing this. Does anyone have an example? I know that
>>> Spring has
>>> support for JMX now. Is there a way to do this through the
>>> context file?
>>> Also, after the properties are exposed through JMX, do you have the
>>> ability
>>> to change anything? Ex. I have written a TCP component that
>>> will connect
>>> to a host and port, would I, through JMX, have the ability to
>>> change the
>>> port and restart the component? Is this change persisted?
>>>
>>> That's probably enough questions for now I guess.
>>>
>>> Thank you very much,
>>> Doug
>>>
>>>
>>
>
>
--
Cheers,
Guillaume Nodet
