[Design of JBoss jBPM] - Re: Defining the API Mission
by estaub
In case it wasn't clear...
My note about the mismatch between BPMN and JPDL was in no way meant to discourage mapping from B to J. I'm going through the same process as Jeff. I was only saying that introducing use of BPMN terms into the execution domain, e.g., as the basis for names in an API, would be a really bad idea.
Re use of GPD... I'm pretty unhappy with GPD. The code base is not very extensible, and is highly dependent on the XML editor codebase.
I went to the talk by the Eclipse BPMN editor guys at EclipseCon, and was very sold on GMF. The BPMN editor is really slick, and easily extensible. People kept complimenting them on this or that feature, and they kept saying things like "well, it wasn't really a requirement, but all we had to do to implement it was write these 5 lines of code, so we just threw it in." High praise for the framework!
After spending some time with the code, I am even more sold. I would very strongly suggest that Koen look at GMF et al again - it's probably grown up a lot since he checked it out the first time.
-Ed
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166729#4166729
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166729
17 years, 8 months
[Design of JBoss jBPM] - Re: Defining the API Mission
by heiko.braun＠jboss.com
anonymous wrote :
| The mismatch in naming of workflow elements is nearly as bad as it can get...
|
I totally agree with this. This was the reason for looking at BPMN in the first place. We wanted to get to "proven concepts" with "established terminology".
And to be honest, following the discussions around BPMN and executable dialects, I still don't see arguments why it can't be done. Please show me examples of BPMN elements that conflict with execution.
IMO it's not necessary to have full BPMN support. We just need those parts that we actually can make executable. If I remember correctly BPMN even defines profiles with different scopes. But I think a 60% BPMN support is still better 100% jPDL, which is, by the way, something we cannot even easily compare at the moment, because jBPM doesn't use common BPM patterns and established terminology to express it's features/capabilities.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166725#4166725
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166725
17 years, 8 months
[Design of JBoss/Tomcat Integration] - MC bean integration into Tomcat startup
by bstansberry＠jboss.com
In my work on ModClusterService, I'm facing an issue integrating MC beans into Tomcat and would appreciate any comments on my solution. My requirements:
1) Make mc beans available to Tomcat components. Specifically add a LifecycleListener to the TC Server object. The listener has various other beans injected into it; i.e. it needs to be built by the MC.
2) TC component is created as part of server.xml processing, i.e. it's not something we add later via JBoss AS code.
3) MC beans need to be available to TC component before the component is started.
Problem is the TC's server.xml processing works, the components listed in server.xml are both instantiated and started in a single call -- by TomcatService to org.apache.catalina.startup.Catalina.start(). So, there's no opportunity to inject anything before the components are started.
Perhaps JBAS-5672 work will fundamentally change how this is all done. But for now I've gotten something clunky working that allows me to test ModClusterService. I'd appreciate comments on this general approach before I commit it.
Basically, in server.xml I configure the LifecycleListener class I want to use. It includes a config attribute where the name of the MC bean it needs is specified. The listener uses a service locator to find the object.
| package org.jboss.web.tomcat.service.deployers;
|
| import org.jboss.dependency.spi.ControllerContext;
| import org.jboss.kernel.spi.dependency.KernelController;
|
| public class JBossWebMicrocontainerBeanLocator
| {
| private static KernelController kernelController;
|
| /**
| * Returns the microcontainer bean installed under the given name.
| *
| * @param beanName the name of the bean
| * @return the bean, or <code>null</code> if no bean is installed under <code>name</code>
| *
| * @throws IllegalStateException if no KernelController is available to perform
| * the lookup
| */
| public static Object getInstalledBean(Object beanName)
| {
| if (kernelController == null)
| {
| throw new IllegalStateException("KernelController not installed");
| }
|
| ControllerContext context = kernelController.getInstalledContext(beanName);
| return context == null ? null : context.getTarget();
| }
|
| /** Package-protected accessible to TomcatService */
| static void setKernelController(KernelController controller)
| {
| kernelController = controller;
| }
|
| /** Prevent instantiation */
| private JBossWebMicrocontainerBeanLocator()
| {
| }
|
| }
The KernelController is provided to the locator by the TomcatService bean, which is KernelControllerContextAware. Ensures the correct KernelController is used.
The same general approach could be used by other TC components (e.g. specialized valves) that are deployed via server.xml but need access to MC beans.
If there's an equivalent general purpose equivalent service locator that will use the correct KernelController out there in the AS somewhere, I could use that instead of having TomcatService provide it. A downside of having TomcatService provide the KernelController is I've found that the KernelControllerContextAware callbacks only get invoked if the TomcatService is deployed via a -beans.xml. With the current deployment via jboss-service.xml the callbacks are not getting invoked. (The conversion to -beans.xml is no big deal, except it further breaks the already-broken ServiceBindingManager.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166715#4166715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166715
17 years, 8 months