This content has been marked as final.
Show 26 replies
-
15. Re: bean/mbean integration issue
starksm64 Jan 14, 2007 6:59 PM (in response to starksm64)"alesj" wrote:
"scott.stark@jboss.org" wrote:
trunk is back to pulling in the mc snapshot so any working build of the mc could be pushed out as snapshot update.
How do you do that?
Is there an Ant task in MC which does this?
The jbossmc/build/build.xml has an install target that copies the mc jars to your jbossbuild repo in preparation for checkin:
[starksm@succubus build]$ ant -projecthelp
Buildfile: build.xml
Main targets:
clean Cleans up most generated files.
clobber Cleans up all generated files.
docs Builds all documentation.
help Show this help message.
install Install the jars to the jbossbuild repository.
main Executes the default target (most).
most Executes all modules and builds most everything.
It depends on the jbossbuild.repository.dir and jbossbuild.repository.version props which you can set in a local.properties file as shown here for a snapshot release:
jbossbuild.repository=file:/usr/Repository/repository.jboss.com
jbossbuild.repository.dir=/usr/Repository/repository.jboss.com
jbossbuild.repository.version=snapshot -
16. Re: bean/mbean integration issue
starksm64 Jan 14, 2007 9:06 PM (in response to starksm64)I did update the mc snapshot with deployer changes and I did pickup the kernel and dependency changes as well.
-
17. Re: bean/mbean integration issue
alesj Jan 15, 2007 8:05 AM (in response to starksm64)I've added DispatchContext support to ServiceControllerContext.
Scott, can you please test this again:<!-- Add a ProfileService handler to the remoting socket connector --> <bean name="ProfileServiceInvocationHandler" class="org.jboss.aspects.remoting.AOPRemotingInvocationHandler"> <install bean="jboss.remoting:service=Connector,transport=socket" method="addInvocationHandler"> <parameter>ProfileService</parameter> <parameter><this/></parameter> </install> <uninstall bean="jboss.remoting:service=Connector,transport=socket" method="removeInvocationHandler"> <parameter>ProfileService</parameter> </uninstall> </bean>
Maybe just adding additional class type info to parameters.
Let me know how it went. Or tell me where to look for the test case. -
18. Re: bean/mbean integration issue
starksm64 Jan 15, 2007 2:09 PM (in response to starksm64)I'll create a testcase for this in the jbossas/system-jmx module.
-
19. Re: bean/mbean integration issue
starksm64 Jan 15, 2007 5:18 PM (in response to starksm64)I added a org.jboss.test.system.controller.integration.test.InstallMCToJMXUnitTestCase and I'm still seeing a CCE in the test:
647 DEBUG [SimpleSARDeployer] Deployed file:/home/svn/JBossHead/jboss-head/system-jmx/src/resources/tests/org/jboss/test/system/controller/integration/test/InstallMCToJMXUnitTestCase.xml took 146ms 673 DEBUG [InstallMCToJMXUnitTestCase] Deploying file:/home/svn/JBossHead/jboss-head/system-jmx/src/resources/tests/org/jboss/test/system/controller/integration/test/InstallMCToJMXUnitTestCase-mc.xml 1134 ERROR [AbstractKernelController] Error installing to Installed: name=Test state=Start java.lang.ClassCastException: org.jboss.system.microcontainer.ServiceControllerContext at org.jboss.kernel.plugins.dependency.InstallAction.installActionInternal(InstallAction.java:59) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:187) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:126) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:430) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:540) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:474) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119) at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64) at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76) at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:146) at org.jboss.test.system.controller.integration.test.IntegrationTestDelegate.deployMC(IntegrationTestDelegate.java:219) at org.jboss.test.system.controller.integration.test.IntegrationTestDelegate.deployMC(IntegrationTestDelegate.java:291) at org.jboss.test.system.controller.integration.test.IntegrationTestDelegate.setUp(IntegrationTestDelegate.java:73) at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63) at org.jboss.test.AbstractTestCaseWithSetup.setUp(AbstractTestCaseWithSetup.java:97) at org.jboss.test.system.controller.AbstractControllerTest.setUp(AbstractControllerTest.java:77) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118)
Can you validate that the mc snapshot includes your changes. -
20. Re: bean/mbean integration issue
adrian.brock Jan 17, 2007 9:55 AM (in response to starksm64)"alesj" wrote:
"adrian@jboss.org" wrote:
This interface belongs in the dependency module that knows nothing about POJOs/services.
Where in the Context hierarchy should I put it?
It's upto each implementation whether it implements it.
Should KernelRegistryEntry extend it?
If so, how do we handle KernelRegistryPlugin entries?
You could make BasicKernelRegistryEntry implement it.
But you'd need a mechanism to get the BeanInfo for the target object of the entry.
I'm not sure it is worth the effort? -
21. Re: bean/mbean integration issue
alesj Jan 17, 2007 10:03 AM (in response to starksm64)"adrian@jboss.org" wrote:
"alesj" wrote:
"adrian@jboss.org" wrote:
This interface belongs in the dependency module that knows nothing about POJOs/services.
Where in the Context hierarchy should I put it?
It's upto each implementation whether it implements it.
I did make it to extend ControllerContext. I need the target and I thought I needed name. Should I make it plain 'standalone'?
I also added getClassLoader() method - to help me with getting the param TypeInfos. -
22. Re: bean/mbean integration issue
adrian.brock Jan 17, 2007 11:09 AM (in response to starksm64)"alesj" wrote:
I did make it to extend ControllerContext. I need the target and I thought I needed name. Should I make it plain 'standalone'?
It should be a seperate optional interface that a context can implement.
Not all contexts will have/need a notion of "dispatch".
I also added getClassLoader() method - to help me with getting the param TypeInfos.
To what? Again this should probably be a seperate interface that can be
optionally implemented.
That a context has an associated classloader is true for JMX
and sort of true for POJO (there is no first class support like the MBeanServer methods)
but is this really true of all contexts of a state machine?
Remember the dependency project is intended to be just a model
of state transitions governed by their dependencies.
The other part, i.e. what those transitions means and additional state/methods
is a property of the implementation projects.
But, that doesn't mean that the dependency project can't define optional
interfaces to allow contexts to provide add-on behaviour that
cross cuts the different implementations. -
23. Re: bean/mbean integration issue
adrian.brock Jan 17, 2007 11:11 AM (in response to starksm64)More concretely, for the case in hand - invoking a method on another context
during the install phase...
The code should be something like:if (context instanceof DispatchContext) { DispatchContext dc = (DispatchContext) context; dc.dispatch(...); } else { throw new IllegalArgumentException("Cannot install, context " + context + " does not implement DispatchContext"); }
-
24. Re: bean/mbean integration issue
adrian.brock Jan 17, 2007 11:24 AM (in response to starksm64)"adrian@jboss.org" wrote:
But, that doesn't mean that the dependency project can't define optional
interfaces to allow contexts to provide add-on behaviour that
cross cuts the different implementations.
I would also put these optional interfaces in different packages
to signify that they are not a part of the main api.
e.g. rather than org.jboss.dependency.spi.DispatchContext
something like org.jboss.depedendcy.spi.dispatch.DispatchContext
As you can probably tell, I'm a big fan of keeping packges small and to the point! ;-)
This sort of thing might look impression, but it makes it difficult to see the
wood for the trees. :-)
http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html
I'd have split the frames, widgets, layouts, etc. into different packages -
25. Re: bean/mbean integration issue
alesj Jan 17, 2007 11:37 AM (in response to starksm64)"adrian@jboss.org" wrote:
To what? Again this should probably be a seperate interface that can be
optionally implemented.
That a context has an associated classloader is true for JMX
and sort of true for POJO (there is no first class support like the MBeanServer methods)
But is this really true of all contexts of a state machine?
So we should split DispatchContext into simple get/set interface and 'advanced' interface with invoke, target, classloader.
Since how else would you get the parameters and signatures?protected Object invoke(KernelConfigurator configurator, DispatchContext context, String name, List<ParameterMetaData> params) throws Throwable { String[] signature; Object[] parameters; if (params == null || params.isEmpty()) { signature = new String[0]; parameters = new Object[0]; } else { int size = params.size(); signature = Configurator.getParameterTypes(log.isTraceEnabled(), params); Object target = context.getTarget(); // TODO - is this ok for non-POJO targets? if (target != null) { MethodInfo methodInfo = Configurator.findMethodInfo(configurator.getClassInfo(target.getClass()), name, signature); parameters = Configurator.getParameters(log.isTraceEnabled(), context.getClassLoader(), methodInfo.getParameterTypes(), params); // add some more info, if not yet set for(int j = 0; j < size; j++) { if (signature[j] == null) { signature[j] = methodInfo.getParameterTypes()[j].getName(); } } } else { parameters = new Object[size]; ClassLoader classLoader = context.getClassLoader(); for (int i = 0; i < size; i++) { ParameterMetaData pmd = params.get(i); TypeInfo typeInfo = null; if (signature[j] != null) { typeInfo = configurator.getClassInfo(signature[j], classLoader); } // typeInfo might be null, but we can still get value in some cases parameters[j] = pmd.getValue().getValue(typeInfo, classLoader); } } } return context.invoke(name, parameters, signature); }
-
26. Re: bean/mbean integration issue
alesj Jan 17, 2007 11:47 AM (in response to starksm64)I separated the DispatchContext into two interfaces = AttributeDispatchContext and InvokeDispatchContext:
public interface AttributeDispatchContext { /** * Getter property / attribute * * @param name * @return target's property / attribute instance * @throws Throwable */ Object get(String name) throws Throwable; /** * Setter property / attribute * * @param name * @param value set target's property / attribute instance * @throws Throwable */ void set(String name, Object value) throws Throwable; } public interface InvokeDispatchContext extends AttributeDispatchContext { /** * Invoke method / operation * * @param name * @param parameters * @param signature * @return inovocation's return object * @throws Throwable */ Object invoke(String name, Object parameters[], String[] signature) throws Throwable; /** * Get any target * * @return the target */ Object getTarget(); /** * Get context's classloader. * Used when determining type info for parameter and * getting the parameter actual value. * * @return context's classloader * @throws Throwable */ ClassLoader getClassLoader() throws Throwable; }