-
1. Re: JBoss integration redesign
starksm64 Jun 26, 2006 9:37 PM (in response to jason.greene)This is a mc/jmx kernel bridge issue that we should have better support for or else the beans deployer really does not integrate into the jboss-4.0.x release. What you need is an ability to import the foreign jmx kernel service into the mc as a bean for dependency purposes.
With what your proposing, aren't you going to be duplicating a kernel and therefore breaking another mc bean deployment from interacting with the jbossws beans? -
2. Re: JBoss integration redesign
jason.greene Jun 27, 2006 10:46 AM (in response to jason.greene)"scott.stark@jboss.org" wrote:
This is a mc/jmx kernel bridge issue that we should have better support for or else the beans deployer really does not integrate into the jboss-4.0.x release. What you need is an ability to import the foreign jmx kernel service into the mc as a bean for dependency purposes.
Yes, that would definately solve the problem.
With what your proposing, aren't you going to be duplicating a kernel and therefore breaking another mc bean deployment from interacting with the jbossws beans?
Yes, although this is what the current mc deployer does. It creates a new kernel per deployment.
-Jason -
3. Re: JBoss integration redesign
starksm64 Jun 27, 2006 1:07 PM (in response to jason.greene)"jason.greene@jboss.com" wrote:
Yes, although this is what the current mc deployer does. It creates a new kernel per deployment.
Ok, I did not realize that. Then I guess its just a question of is it worth the extra time to add support for integration of dependencies on jmx kernel beans to the deployer vs essentially creating a custom bean deployer for the jbossws usecase. The former is what I would prefer. I'll post in the mc forum on what it would take to get this done. Lack of followup would a green light to do what you want. -
-
5. Re: JBoss integration redesign
jason.greene Jun 27, 2006 1:36 PM (in response to jason.greene)"scott.stark@jboss.org" wrote:
Ok, I did not realize that. Then I guess its just a question of is it worth the extra time to add support for integration of dependencies on jmx kernel beans to the deployer vs essentially creating a custom bean deployer for the jbossws usecase. The former is what I would prefer. I'll post in the mc forum on what it would take to get this done. Lack of followup would a green light to do what you want.
I agree, the former is ideal because this is a problem that will affect other projects as they migrate to the mc. I will monitor the thread.
-Jason -
6. Re: JBoss integration redesign
thomas.diesler Jun 28, 2006 6:14 AM (in response to jason.greene)Jason,
I suggest we stay away from a fix in the jbossws codebase. As we all agree, this should be solved in a general way for all MC beans with dependencies on jboss services.
For the next release, we disable the eventing subsription manager by default and document that it can only be enabled when the JNDI service is part of conf/jboss-service.xml -
7. Re: JBoss integration redesign
heiko.braun Jun 29, 2006 3:46 AM (in response to jason.greene)I agree with thomas. Especially since our deployment problem doesn't exists anymore. I managed to tweak the eventing parts to lazily access the naming service. That means we can take our time and start looking at the mc2jmx bridge scott suggested.
-
8. Re: JBoss integration redesign
jason.greene Jun 30, 2006 12:29 AM (in response to jason.greene)An MC task was just created by scott to do this, so I have added a corresponding task on our side to make use of it.
http://jira.jboss.com/jira/browse/JBWS-1030
-Jason