Calling EJB's from MBeans

[ashields]

I have an MBean that needs to call an EJB, If I deploy my MBean when the server is up and running it's fine, however if I restart the server my MBean gets started before the EJB is deployed so I get a not bound exception.

Whats the best solution to this? I've considered just putting a 30 second sleep in my MBean but I don't really like this idea.

I know I can make a service dependent on other services, can I make a service depend on an EJB?

Thanks
Alan Shields

[adrian.brock]

http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=forums/

[juha]

hey,

how come the deployment system doesn't send a notification when it sets up an EJB or other units? or does it?

and would that make a difference... is it just easier to write dependencies in the deployment descriptors rather than rely on runtime notifications?

just a thought..

-- Juha

[petertje]

The message
> http://www.jboss.org/forums/thread.jsp?forum=63&thread14550&message=3725964&q=depends+ejb#3725964

shows the example service=EjbModule,url=file%/jboss/server/default/deploy/ejb-management.jar

However, in my case it only works after prefixing the dependency with "jboss.j2ee":

jboss.j2ee:service=EjbModule,url=file%/jboss/server/default/deploy/ejb-management.jar

Regards,
Peter.

[petertje]

And by the way, it would be great if we wouldn't have to put absolute file paths in the dependency (file%/jboss/server/etc), would make deployment a bit easier...

Regards,
Peter

[davidjencks]

Ummm.. how would notifications help? You still need to specify somehow that component x depends on component y. The functionality could be moved from the ServiceController to an mbean lifecycle interceptor (containing the ServiceContext info), but I think the needed info would be the same. If we rewrote this to be based on an interceptor, I think notifications might make more sense. With the current system in ServiceController, I don't see the point.

I do think there are many unexploited possibilities for automatically determining dependencies (such as from jndi enviroment entries).

[juha]

> Ummm.. how would notifications help?

Meaning, for example, I can register to the MBeanServerDelegate in any JMX MBean server to be notified of registration/unregistration events in the server. Therefore it becomes trivial for me to code up an MBean that waits for another MBean to appear before I execute the lines of code that depend on the other MBean.

I guess this still works if JSR-77 standardizes the naming of components (I havençt looked, assuming they do).

-- Juha

[marc.fleury]

> I guess this still works if JSR-77 standardizes the
> naming of components (I havençt looked, assuming they
> do).

Clearly we should build the delegation model based on MBeanName internally to the system, the jsr77 will just be a way to specify the name in the standard and we will map to the JMX name behind the scenes. Working at the MBeanName level will enable us to build the dependency mechanism in the generic way you mention.

Please add this idea to the TODO list of the forums this will enable to track the idea.

PS: you free on Tuesday? wanna come east of the mallorca island?

>
> -- Juha
>

[marc.fleury]

> Ummm.. how would notifications help? You still need
> to specify somehow that component x depends on
> component y. The functionality could be moved from

You are correct, however it assumes that all lifecycle events go through the ServiceController, which today they do for the most part but we can also directly talk to the MBean through the MBeanServer. You might imagine some of the updates to the configuration that really are managed by the service controller.

I guess what I am saying is that forcing the dependency management to be done through the ServiceController, while equivalent to halting invocations at the MBean System level is less standard based (read JMX only).

> I think the needed info would be the same. If we
> rewrote this to be based on an interceptor, I think
> notifications might make more sense. With the

It won't be an interceptor (in our sense) but something very akin to it, the MBeanServerDelegate which is really the equivalent of the ClientContainer on the client side, i.e. the first point of entry to the invocation on a container. You are correct in pointing out that since the ServiceController is always aware of the state of the MBean it could be the one "notifying". In fact in light of this I would tend to say you are correct even on the first point meaning that all state altering operation should at some point branch through the ServiceController. I don't have a clear example that would make either solution break.

(I was thinking about 2 mbeans and one need to be started first but the system juha is describing is one where you have the "mbean" present it just revives the threads. So even if 1 is resuming threads 2 is waiting them until he is ok and if 2 is resuming threads before one, who cares, when 1 revives he will recieve them. One case I do see where the SC should be in charge is in case the Service goes down and the Service is removed so the delegate is removed as well).

Hmmmm, I think the bottom line is that the SC should be the one listening for notifications, meaning that he is the one centralizing the MBeanNotification listeners. I would also have the SC delegate to the MBean in the standard case but the case above will require some indirection in the SC (for him to shut down the proper MBeans).

If the target MBean defines MBeanNotificationListeners, should we let the SC intercept all these and just delegate? It would make the JMX layer dependent on the ServiceController.

This being said. I believe the SC and the deployers are JBossMX level constructs.

> I do think there are many unexploited possibilities
> for automatically determining dependencies (such as
> from jndi enviroment entries).

Yes and no ( I do like the idea though). I think we need to have the generic dependency mechanisms at the SC/MX level and then different "inputs" into it. IN the case you track JNDI entries -> modules (i.e. those declared in the XML files, you will miss the registration) and in the case you intercept the JNDI call (which we will do) then you can establish an incomplete map of the dependencies (what do you do with static classes).

Bottom line.

Let's keep it simple. We have been pushing for the MBeanName everywhere in our system and we are really getting there today, let's finish this first push and have the lifecycle management in the SC notifying the MBeanDelegate for thread holding/starting.

[marc.fleury]

> And by the way, it would be great if we wouldn't have
> to put absolute file paths in the dependency
> (file%/jboss/server/etc), would make deployment a bit
> easier...

Clearly, also in most cases we can complete the domain. This is a great idea, why don't you patch or at least put a post in the TODO list, we need to simplify the way we specify this.