[Design the new POJO MicroContainer] - Support for @JMX on attributes
by alesj
Tim raised this question on MC user forum:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=137721
So I hacked something in this direction - adding annotation plugin for @JMX.
| public abstract class JMXAnnotationPlugin<T extends AnnotatedInfo> extends AbstractAnnotationPlugin<T, JMX>
| {
| protected JMXAnnotationPlugin()
| {
| super(JMX.class);
| }
|
| protected List<? extends MetaDataVisitorNode> internalApplyAnnotation(T info, MetaData metaData, JMX jmx, KernelControllerContext context) throws Throwable
| {
| Class<?> exposedInterface = jmx.exposedInterface();
| if (exposedInterface == null || void.class.equals(exposedInterface))
| exposedInterface = getExposedInterface(info);
| if (exposedInterface == null || exposedInterface.isInterface() == false)
| throw new IllegalArgumentException("Illegal exposed interface: " + exposedInterface);
|
| BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(createObjectName(context, info, jmx), exposedInterface.getName());
| // TODO - uncomment with new MC release; builder.addAnnotation(jmx);
| Object proxy = createProxy(context, info, exposedInterface);
| KernelController controller = (KernelController)context.getController();
| controller.install(builder.getBeanMetaData(), proxy);
|
| // no change directly on context
| return null;
| }
|
| /**
| * Create proxy for attribute.
| *
| * @param context the context
| * @param info the info
| * @param exposedInterface the exposed interface
| * @return attribute's proxy
| * @throws Throwable for any error
| */
| protected Object createProxy(KernelControllerContext context, T info, Class<?> exposedInterface) throws Throwable
| {
| return Proxy.newProxyInstance(
| context.getClassLoader(),
| new Class<?>[]{exposedInterface},
| new AttributeInvocationHandler(context, getName(info))
| );
| }
|
| protected void internalCleanAnnotation(T info, MetaData metaData, JMX jmx, KernelControllerContext context) throws Throwable
| {
| Controller controller = context.getController();
| controller.uninstall(createObjectName(context, info, jmx));
| }
|
| /**
| * Get exposed interface from info.
| *
| * @param info the info
| * @return exposed interface
| */
| protected abstract Class<?> getExposedInterface(T info);
|
| /**
| * Get name from info.
| *
| * @param info the info
| * @return info's name
| */
| protected abstract String getName(T info);
|
| /**
| * Create object name.
| *
| * @param context the context
| * @param info the info
| * @param jmx the annotation
| * @return obejct name
| * @throws Exception for any error
| */
| protected String createObjectName(ControllerContext context, T info, JMX jmx) throws Exception
| {
| if (jmx != null)
| {
| String jmxName = jmx.name();
| if (jmxName != null && jmxName.length() > 0)
| return jmxName;
| }
|
| // try to build one from the bean name and info param
| String name = context.getName().toString();
| String objectName = name;
| if (name.contains(":") == false)
| {
| objectName = "jboss.pojo:name='" + name + "'";
| }
| return objectName + ",property=" + getName(info);
| }
|
| /**
| * Attribute invocation handler.
| */
| protected class AttributeInvocationHandler implements InvocationHandler
| {
| private KernelControllerContext context;
| private String property;
|
| protected AttributeInvocationHandler(KernelControllerContext context, String property)
| {
| this.context = context;
| this.property = property;
| }
|
| public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
| {
| Object target = context.get(property);
| return method.invoke(target, args);
| }
| }
| }
|
I'm creating a proxy target around @JMX exposed attribute, installing it to MC, hence leaving all the rest of jmx work to MC.
Does this look legit?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159534#4159534
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159534
16 years
[Design of JBoss jBPM] - Re: jbpm-api first draft
by tom.baeyens＠jboss.com
i would like to see how in this proposal we're going to implement cross cutting concerns like authorization, transactions, retry upon optimistic locking failure and make it configurable for different environments like plain java, servlet, ee, seam, spring,...
not all the details are necessary, just the interception points.
as far as i got it, your proposal seems to reflect the pattern of a statefull session bean, while i can only see it work with a stateless session bean approach.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159529#4159529
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159529
16 years
[Design of JBoss jBPM] - jBPM3 API now based on microcontainer
by thomas.diesler＠jboss.com
Folks,
the API now gets its artifacts configured through the MC
| <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"
| xmlns="urn:jboss:bean-deployer:2.0">
|
| <!-- The process engine -->
| <bean name="jBPMProcessEngine" class="org.jbpm.integration.client.ProcessEngineImpl">
| <property name="processDefinitionManager"><inject bean="jBPMProcessDefinitionManager"/></property>
| <property name="processInstanceManager"><inject bean="jBPMProcessInstanceManager"/></property>
| <property name="executionManager"><inject bean="jBPMExecutionManager"/></property>
| </bean>
|
| <!-- The process definition manager -->
| <bean name="jBPMProcessDefinitionManager" class="org.jbpm.integration.client.ProcessDefinitionManagerImpl">
| <!--property name="processEngine"><inject bean="jBPMProcessEngine"/></property-->
| </bean>
|
| <!-- The process instance manager -->
| <bean name="jBPMProcessInstanceManager" class="org.jbpm.integration.client.ProcessInstanceManagerImpl">
| <!--property name="processEngine"><inject bean="jBPMProcessEngine"/></property-->
| </bean>
|
| <!-- The execution manager -->
| <bean name="jBPMExecutionManager" class="org.jbpm.integration.client.ExecutionManagerImpl">
| <!--property name="processEngine"><inject bean="jBPMProcessEngine"/></property-->
| </bean>
|
| </deployment>
|
With this abstraction in place it should be possible to implement the mapping for the JBPM4 code base
You can consume the API and the related tests from
cheers
http://snapshots.jboss.org/maven2/org/jboss/jbpm/
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159503#4159503
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159503
16 years
[Design of JBoss jBPM] - Re: jPDL 4 early feedback
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote : I am wondering why the schema contains element declarations for concrete activities like 'email'. IMO we shouldn't treat the stock activities anyhow different as the ones user supply. That means they wouldn't be represented by an element name on it's own.
jPDL is an executable process language. Each node is of a certain type. One node type will delegate to an activity implementation (== direct mapping to the PVM construct). Another node type will call a java method through running a script or evaluating an expression. Other node types do more functional behaviour like email.
Separating the structure from the activity behaviour would make the XML a lot more verbose and hence less readable.
"heiko.braun(a)jboss.com" wrote : On the other hand, if we move stock activities to a custom namespace, then they are separated from the core xsd constructs.
using separate namespaces for user defined node types is certainly something that i think should be possible.
but a whole process should be usable without namespaces as well, i think. just referencing the core jpdl xsd in the default namespace is simple. so that should never be a problem.
but combining namespaces is what always should be optional. meaning. the functionality should always be available with or without setting up the namespaces properly.
so when users want to add a new node type, i don't want them to be forced to write an xsd and configure the namespace in the process.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159466#4159466
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159466
16 years