[Design of JBoss jBPM] - Re: jbpm 4 - Term
by tom.baeyens＠jboss.com
"camunda" wrote : Feedback about jbpm 4 and discussions will go on in this forum, right? Or PVM?
|
this forum is good. pvm separate forum should be deleted but i assume that it is impossible to (re)move forums.
"camunda" wrote : So I would like to see ProcessInstance and Token again
|
The motivation to unify process instance and token is the simple case without concurrency. When a process has no concurrency, the distinction between process instance and it's root token is artificial and confusing.
On a PVM level, we need to have this unification. The idea was that on the jPDL level, the distinction would be made to have a JpdlProcessInstance and a JpdlExecution. But so far, (ok we're only in alpha 1) there was no need for this separation.
Conceptually, the distinction needs to be there in case of querying.
"camunda" wrote : but I think that would cause a lot refactoring. What are your thoughts? Or is it decided already anyway?
|
I don't think that would cause a lot of refactoring. It's a matter of where and how this separation in the API should show up. This is a work in progress and all feedback is welcome.
For starters: the startExecutionXxx methods should be renamed to startProcessInstanceXxx. But in the services API, I have not yet had a need for a specific ProcessInstance method. So do we introduce a ProcessInstance that extends from Execution and not adds a method ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205507#4205507
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205507
17 years, 2 months
[Design of POJO Server] - Re: Using temp at undeploy
by alesj
"scott.stark(a)jboss.org" wrote : I'm looking through the changes, and it appears this automatically identifies contexts as temps if a specified metadata file exists. In the server we would presumably register all know deployment descriptors?
|
You register what you like. :-)
You can either change whole StructureProcessor impl,
or you can just add custom ModificationTypeMatcher(s).
My drive for this was Seam's request to have temp for all Seam apps,
hence I needed to recognize/match deployments that are possible Seam apps.
This is what we need to add in order to make it happen:
| <bean name="ModificationTypeStructureProcessor" class="org.jboss.deployers.vfs.plugins.structure.modify.ModificationTypeStructureProcessor">
| <incallback method="addMatcher"/>
| <uncallback method="removeMatcher"/>
| </bean>
|
| <!-- The holder for deployers that determine structure -->
| <bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl">
| <property name="structureBuilder">
| <!-- The consolidator of the structure information -->
| <bean name="StructureBuilder" class="org.jboss.deployers.vfs.plugins.structure.VFSStructureBuilder">
| <property name="structureProcessor"><inject bean="ModificationTypeStructureProcessor"/></property>
| </bean>
| </property>
|
| public class SeamModificationTypeMatcher extends TempTopModificationTypeMatcher
| {
| public SeamModificationTypeMatcher()
| {
| super(SeamConstants.SEAM_FILES);
| }
| }
|
| <!-- Seam modification type matcher -->
| <bean name="SeamMTMatcher" class="org.jboss.seam.integration.microcontainer.deployers.SeamModificationTypeMatcher"/>
|
|
"scott.stark(a)jboss.org" wrote :
| Its possible to have a nested deployment that has no descriptors. In that case you still will have to include a jboss-structure.xml I take it?
|
Yes.
Or you can write a different StructureProcessor or
a ModificationTypeMatcher that doesn't 'work' on descriptors;
e.g. might work on classpath or predetermined attachments
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205499#4205499
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205499
17 years, 2 months
[Design of POJO Server] - Finding RealClassLoader in ServiceDeployer
by alesj
There was this fix mentioned here:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4132644#4132644
I have a patch ready:
| Index: system-jmx/src/main/org/jboss/system/deployers/ServiceDeployer.java
| ===================================================================
| --- system-jmx/src/main/org/jboss/system/deployers/ServiceDeployer.java (revision 83578)
| +++ system-jmx/src/main/org/jboss/system/deployers/ServiceDeployer.java Thu Jan 29 10:12:22 CET 2009
| @@ -84,13 +84,7 @@
| {
| ObjectName loaderName = deployment.getClassLoaderName();
| if (loaderName == null)
| - {
| - ClassLoader cl = unit.getClassLoader();
| - if (cl != null && cl instanceof RealClassLoader)
| - loaderName = ((RealClassLoader) cl).getObjectName();
| - else
| - loaderName = defaultClassLoader;
| - }
| + loaderName = findLoaderName(unit.getClassLoader());
|
| controller.install(deployment, loaderName);
| ServiceContext context = controller.getServiceContext(name);
| @@ -124,6 +118,28 @@
| }
| }
|
| + /**
| + * Find first RealClassLoader instance
| + * and return its ObjectName.
| + * If none is found return defaultClassloader.
| + *
| + * @param cl the classloader
| + * @return classloader's ObjectName
| + */
| + protected ObjectName findLoaderName(ClassLoader cl)
| + {
| + if (cl == null)
| + return defaultClassLoader;
| +
| + if (cl instanceof RealClassLoader)
| + {
| + RealClassLoader rcl = RealClassLoader.class.cast(cl);
| + return rcl.getObjectName();
| + }
| +
| + return findLoaderName(cl.getParent());
| + }
| +
| public void undeploy(DeploymentUnit unit, ServiceMetaData deployment)
| {
| ObjectName name = deployment.getObjectName();
|
Should I apply it?
Or it might have some strange side affect? :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205478#4205478
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205478
17 years, 2 months