July 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Need for database compatibility between jBPM versions

by thomas.diesler＠jboss.com

In http://www.jboss.com/index.html?module=bb&op=viewtopic&t=138168 I state anonymous wrote : | Database layout is considered implementation detail that might change between minor versions. | This is based on my understanding that a process definition is an immutable entity, which is defined in XML. The state of running processes is persisted in the database. For many a reason It cannot be expected that jBPM can be updated for running proccess. If this feature is required we need to see this reflected in the test suite. In other words, as long as there are no automated tests that verify that an update of jBPM from version X to version Y for a non trivial set of running processes - this feature is not there. The API will support | ProcessEngine.prepareForShutdown() | This will allow processes to terminate, while others cannot start. A user is expected to setup a new instance of jBPM version Y that can receive new process requests. >From that perspective, it is unnecessary and not even desired to provide backwards compatibility for database layout. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161691#4161691 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161691

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Installer supports optional pack

by thomas.diesler＠jboss.com

Hi Foks, you can now optionally install components like bam-console or a specific db support http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3BuildingTheInstaller Next is to integrate the installer in the Hudson QA. The installer should be the only supported way to install jBPM in a target container. Like every other supported functionality, this needs to be automatically verified. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161688#4161688 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161688

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by tom.baeyens＠jboss.com

perfect lecture for during the holidays. i'll surely find some time to read them during the next two weeks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161685#4161685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161685

17 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBMICROCONT-309; aliases and scoping

by alesj

With Kabir's issue: - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154037#4154037 I've re-factored scoped kernel/controller code a bit. The new addition makes aliases pretty useful now. :-) The detail is in the state they are added - past PRE_INSTALL (after scoping). It solves what we mostly want to do with an alias and scoped beans. But the problem we're inconsistent with how we do the aliases - scoping aliases to be exact. Focusing just on scoping + alias: In my new code, where I handle aliases on annotation, my controller is already scoped, so my alias is unique in that controller scope. This makes combination of global unique bean name + scoped alias a great asset for other scoped beans (Kabir's issue use case) - but see issue1. Issue#1: Controller should have option to do just local lookup - otherwise order of bean deployment is important; e.g. picking up bean from parent (already available), where you would actually want scoped one (not available at dependency item resolution) This can also lead to CCE issues; parent bean being of wrong type Currently scoping controllers are completely transparent, visible only to top level controller. And as such, install and uninstall only take place at the top, propagating the action to the right controller based on the (hopefully) unique name. Issue#2: If we do alias addition after scoping (post PreInstall), the alias (context) name is unique, since it's signed by controller id (new notion I needed to add). But currently we register context's aliases in Controller:install, which is way too early. :-) Hence we loose alias (context) name uniqueness - they are all signed by top controller. Alias addition should be done in Describe state, since I very much doubt anybody depends on the bean via alias before Describe state. This would solve the uniqueness problem. Aliases can also be deployed separately - see DeploymentAliasDeployer in deployers project. Issue#3: NamedAliasMetaData is missing a way to specify to which scope this alias should be installed. In order to do this, there are two ways that I see: 1) Controller::add/removeAlias take ScopeKey parameter, NamedAliasMetaData knows how to create that scope key 2) NamedAliasMetaData takes annotations, AliasControllerContext uses MetaData to keep that annotations, and we use the same lookup mechanism as we do in PreInstallAction With all this, once we abandon context name notion - making it automatically unique - defining aliases and coding against them would make scoping truly usable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161684#4161684 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161684

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by heiko.braun＠jboss.com

Another good one: * http://www.tbray.org/ongoing/When/200x/2006/01/09/On-XML-Language-Design View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161672#4161672 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161672

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by heiko.braun＠jboss.com

Some background information on schema design that may be useful for this thread: * http://www.xml.com/pub/a/2004/07/21/design.html * http://www.xml.com/pub/a/2003/12/03/versioning.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161670#4161670 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161670

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining a public API for jBPM

by tom.baeyens＠jboss.com

good point, ed. Also during the jBPM Community Day, the most important feedback from the core community session was migration support. It depends on the resources we can get for this. currently the plan is to make a jPDL3 parser available in jPDL4 and make sure that both jPDL3 and jPDL4 can run next to each other. When we enter beta stage with jPDL4, then we'll be thinking more concrete on this and we'll probably have to finetune the details at that time. Hopefully we can add some kind of database migration, but it is still too early to tell if we're going to be able to make it. In the future we'll also work towards XML serialization and XML parsing of runtime process execution information. That might also be a way to support DB migration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161664#4161664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161664

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by tom.baeyens＠jboss.com

<activity name="s" class="com.customer.OurSapIntegration"> | <field name="server"><string value="sap.intranet.customer.com"/></field> | <transition to="next" /> | </activity> can be given a shortcut like this <sap name="s" server="sap.intranet.customer.com"> | <transition to="next" /> | </sap> to improve readability. Additions (including introduction of shortcuts like these) can even be done in micro version updates as they don't break existing backwards compatibility. The esb node was a special case and such quick-fixes must be avoided in the future. The biggest problem with the esb node is that the action handler was located in the esb jar and not in the jbpm-jpdl jar. That way incompatibilities appeared between (jbpmruntime+designer) and (esbnode) Also, there can be dependencies of activity implemenetations on certain configurations on the node structure properties. For example, a sequence implementation might require that the isPreviousNeeded property is set on the node. Such things further complicate the reading and writing process XML by hand. The good part of the PVM is that the upper xml example snippet will become persistable in the generic PVM DB schema. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161663#4161663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161663

17 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: XPost - Remoting from unsigned applet - ClassLoader secu

by ron.sigal＠jboss.com

Hi James, Sounds great. Looking forward to it. -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161646#4161646 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161646

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by estaub

"kukeltje" wrote : 'the' xsd is not available yet... for the very reason this discussion is taking place.... it has to be defined based on input from us. Er... the javadoc was generated by a tool that converts an xsd to javadoc. To see the big picture, the original xsd would be useful. It can be stamped "first draft" in many ways, so that it is not confused with the final. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161636#4161636 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161636

17 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2008