-
1. Re: manual deployment of existing object instance
adrian.brock Dec 20, 2005 12:56 PM (in response to bill.burke)It depends (sic!) what you are trying to achieve.
If you are just trying to add a global singleton then you can just use the
old-fashioned static factory pattern.
I plan to use as an example in the next release.
i.e. How to use JBossMC to implement the "locator pattern" without using any JBossMC
classes, including the horrible "getBean()".
Or maybe someother factory pattern will work for you?
If you are looking for something like the ServiceController'screate(ObjectName, Collection dependencies)
There is no current mapping (direct support) in the controller api.
The plan is you would do it something like this:KernelControllerContext context = new AbstractKernelControllerContext(null, metaData, TARGET_OBJECT_HERE); kernelController.install(context);
But currently the "InstantiateAction" will overwrite the "target". -
2. Re: manual deployment of existing object instance
bill.burke Dec 20, 2005 1:34 PM (in response to bill.burke)I'm currently attempting this. I'm writing an EJB3 deployer for the embedded stuff. The deployer creates EJB containers and the containers also create one or two objects that need registering for lifecycle. Of course it is an iteration until the deployer architure is ready, but here it is:
I'll see if I can figure out something around your suggestion.public class MCKernelAbstraction implements KernelAbstraction { private static final Logger log = Logger.getLogger(MCKernelAbstraction.class); public static class AlreadyInstantiated extends AbstractConstructorMetaData { private Object bean; public Object create() { return bean; } public AlreadyInstantiated(Object bean) { this.bean = bean; this.setFactory(new AbstractValueMetaData(this)); this.setFactoryClass(AlreadyInstantiated.class.getName()); this.setFactoryMethod("create"); } } private Kernel kernel; private MBeanServer server; public MCKernelAbstraction(Kernel kernel, MBeanServer server) { this.kernel = kernel; this.server = server; } public void install(String name, DependencyPolicy dependencies, Object service) { AbstractBeanMetaData bean = new AbstractBeanMetaData(name, service.getClass().getName()); bean.setConstructor(new AlreadyInstantiated(service)); MCDependencyPolicy policy = (MCDependencyPolicy) dependencies; bean.setDemands(policy.getDependencies()); try { kernel.getController().install(bean); } catch (Throwable throwable) { throw new RuntimeException(throwable); } }
-
3. Re: manual deployment of existing object instance
adrian.brock Dec 20, 2005 1:46 PM (in response to bill.burke)Your solution should work as just well?
You just have the extra factory class to workaround the fact that you can't
currently pass the target object directly. -
4. Re: manual deployment of existing object instance
adrian.brock Dec 20, 2005 1:54 PM (in response to bill.burke)Another solution would be to "open up" the constructors such you can pass
an alternate KernelControllerContextActions.
i.e. one without an "InstantiateAction".
This is really want I plan to do when I write the ServiceControllerContextActions
behind the different ServiceController population methods. -
5. Re: manual deployment of existing object instance
adrian.brock Dec 20, 2005 1:55 PM (in response to bill.burke)"adrian@jboss.org" wrote:
Another solution would be to "open up" the constructors
Of the AbstractKernelControllerContext -
6. Re: manual deployment of existing object instance
adrian.brock Dec 20, 2005 2:17 PM (in response to bill.burke)While we are on the subject, can you stop doing this:
mbeanServer = (MBeanServer)kernel.getRegistry().getEntry("MBeanServer").getTarget();
I've already fixed a number of places where you added this and told people to do this:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71739
It is not clear to me that this hangover from the initial port of JMX features is staying
in its current format.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=72926
And the registery certainly doesn't understand the cross context dependency model,
i.e. is it POJO or JMX
The correct API if you must use the kernel as a locator is:kernel.getController().getInstalledContext(name).getTarget()
Or if you are not sure it is installedkernel.getController().getContext(name, null).getTarget()
where the "null" can also be the state you expect the context to be in. -
7. Re: manual deployment of existing object instance
bill.burke Dec 21, 2005 11:42 AM (in response to bill.burke)"adrian@jboss.org" wrote:
Another solution would be to "open up" the constructors such you can pass
an alternate KernelControllerContextActions.
i.e. one without an "InstantiateAction".
This is really want I plan to do when I write the ServiceControllerContextActions
behind the different ServiceController population methods.
IMO, you are going overboard in supporting and writing all the old APIs like service controller and our JMX implementation on top of the new kernel just to be backward compatible with the < 1% of users that use this stuff. IMO, services should be migrated and refactored and rewritten to the new model and users should be forced to use the new SPIs. In a perfect world, we could be backward compatable, but there's just too much work to do. -
8. Re: manual deployment of existing object instance
adrian.brock Dec 21, 2005 11:53 AM (in response to bill.burke)"bill.burke@jboss.com" wrote:
IMO, you are going overboard in supporting and writing all the old APIs like service controller and our JMX implementation on top of the new kernel just to be backward compatible with the < 1% of users that use this stuff. IMO, services should be migrated and refactored and rewritten to the new model and users should be forced to use the new SPIs. In a perfect world, we could be backward compatable, but there's just too much work to do.
???
I'm not going to rewrite everything that uses a JBoss MBean or -service.xml/sar. :-)
In particular, I don't see the point in POJOifying the EJB2.x container.
There are certainly more than 1% of users that have their own Service MBean.
The cross model dependency is essential for the JMX and POJO kernel models
to live together during the transitional period.
A sideaffect is that the old JMX model gains some of the new features of the POJO MC.