[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
15 years, 10 months
[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
15 years, 10 months
[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
15 years, 10 months