[starksm64]

"alesj" 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

[starksm64]

I did update the mc snapshot with deployer changes and I did pickup the kernel and dependency changes as well.

[alesj]

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.

[starksm64]

I'll create a testcase for this in the jbossas/system-jmx module.

[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.

[adrian.brock]

"alesj" 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?

[alesj]

"alesj" 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.

[adrian.brock]

"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.

[adrian.brock]

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");
}

[adrian.brock]

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

[alesj]

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);
 }

[alesj]

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;
}