[jBPM Development] - foreach activity
by Alejandro Guizar
Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] created the discussion
"foreach activity"
To view the discussion, visit: http://community.jboss.org/message/546597#546597
--------------------------------------------------------------
Stemming from a http://community.jboss.org/message/544154#544154 previous discussion I want to discuss https://jira.jboss.org/browse/JBPM-2414 JBPM-2414 separately. The original proposal in the jira issue showed a foreach activity separate from fork. At some point the collection iteration behavior got merged into fork for no reason other than "making it visible in the designer, now". In my view, the +foreach+ and the +fork+ behaviors respond to different needs and should not be merged.
As precedents, I can think of BPEL 2 and its +flow+ and +forEach+ activities. The former provides static parallelism of multiple activities. The latter provides dynamic parallelism of a single activity; nothing prevents this single activity from being a flow. Giving each activity a single responsibility makes its behavior concise and simple to describe.
I suggest we introduce a separate +foreach+ activity instead of adding iteration semantics to +fork+. The binding and activity code that Maciej wrote is kept intact. Only one outgoing transition is allowed. The transition condition MAY refer to the variable specified in the var attribute. If the transition condition evaluates to false, the corresponding child execution does not leave the activity. If no child execution leaves the activity, an exception is thrown.
<foreach name="multiplier" var="item" in="#{items}">
<transition to="task" name="to_task" expr="#{item.value > 10}"/>
</foreach>
I am going to prepare a patch with this proposal and attach it to JBPM-2414 for your review.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546597#546597]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/546593#546593
--------------------------------------------------------------
> Alexey Loubyansky wrote:
>
> > Scott Stark wrote:
> > I still think the best comprimise would be to have profile definitions in the domain in terms of the required capabilities potentially simplified by having implied capabilities associated with each application type that could be overriden by the admin.
>
> Ok, this makes sense. Taking it further... The profiles in the domain schema (as they are now) are kind of redefined, i.e. it's not the same profile definition/configuration as the actual profile configuration like here http://community.jboss.org/wiki/AS6ServerSideConfiguration http://community.jboss.org/wiki/AS6ServerSideConfiguration
Definitely.
> Alexey Loubyansky wrote:
>
> So, I want to clarify the purpose and meaning of this redefinition in the domain config. Perhaps, it also makes sense to choose a different name not to confuse with the actual profiles.
> I think if we can make domain.xml contain only the concepts/notions that are defined in its schema, it would be the best. I.e. if it contained (was expressed in) only the terms defined for it and learning additional concepts/notions for the user wouldn't be a requirement to understand the configuration.
>
> Can we think about the profiles here as a set of capabilities that might be activated once there is an application requiring them? I.e. not to think about them as defining capabailities that must be activated after the start-up?
> Perhaps, something like "environment" would describe it?
Yeah, that's exactly what I was getting at. Though like I said, Scott indicated that we still need the ability to let administrators restrict the set of subsystems that are allowed to be active for a given server group. But this is definitely not the same as specifying the subsystems that *will* be started up, so yes, I agree. Though using "environment" might be too general a term?
> Alexey Loubyansky wrote:
>
> So, what I think we can do:
> - define a set of implied capabilities associated with each application type (or define the "environment" for each application type);
> - if an application is mentioned in the domain.xml w/o specified by the admin "environment" it requires, we assume our defaults;
> - if the admin wants to be precise, it could look like
> <application name="" path="">
> <environment name=""/>
> <environment-ref name=""/>
> </application>
I'd rather localize the configuration overrides to an explicit deployment declaration. This gets back to a previous post I made where I gave this example of a possible way to explicitly declare a deployment in XML:
<!-- An application deployment which is assigned to two server groups -->
<!-- Note the sha1 hash, so we know which version of my-app.ear to deploy -->
<deployment name="my-app.ear" sha1="12b4...2b42" server-groups="group1 group2">
<!--
~ Now inside here, we can put all the overrides which apply to a specific deployment,
~ using a format that is perhaps specific to each deployment type
-->
</deployment>
Or perhaps "deployment-unit" is a better name.
I see what you're getting at with "environments" - to add a level of indirection between deployment types and their capabilities - but I'm not sure that deployment type is the right association to make. Wouldn't it make more sense to declare the capability restrictions on either a domain-wide or per-server-group basis? It seems to me that forbidding the use of certain subsystems at a deployment level would be considerably more complex, and I'm not sure that there's a requirement driving that idea.
For example something like this mockup:
<!-- Domain-wide whitelist -->
<subsystems>
<allow name="ejb"/>
<allow name="http"/>
<allow name="ws"/>
<!-- Everything else is denied -->
</subsystems>
<!-- The back-end servers do not have HTTP, so blacklist them -->
<subsystems server-groups="group1">
<deny name="http"/>
</subsystems>
Then any deployment going to the server group which implies a requirement on a subsystem which is forbidden would receive a deployment error. (Assuming I understand the use case correctly, that is.)
One thing is certain though: we need to identify the subsystems in question so we know what set of capabilities we're talking about in the first place.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546593#546593]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - default values in domain management
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] replied to the discussion
"default values in domain management"
To view the discussion, visit: http://community.jboss.org/message/546559#546559
--------------------------------------------------------------
> David Lloyd wrote:
> > Alexey Loubyansky wrote:
> > By property/value duplication I didn't mean it as a requirement for all the properties. But it will be the case for those that are overriden in domain.xml. It's not so much a value duplication but the property config duplication which won't be in sync (between the domain.xml and the deployment descriptors) which is a bit confusing.
> What do you mean by "in sync" in this case? One would only override a configuration property if there was a deployment to override. I imagine that any overriding properties in the domain.xml file that pertain to a specific deployment will be children of an element which defines that deployment, so if there's no such element, there's no such deployment, and such an element can't exist without the deployment being present.
I simply mean that there will be two values for the property: one in the deployment descriptor (i.e. the default one) and one in the domain.xml (the actual one).
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546559#546559]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - default values in domain management
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] replied to the discussion
"default values in domain management"
To view the discussion, visit: http://community.jboss.org/message/546508#546508
--------------------------------------------------------------
> David Lloyd wrote:
>
> > Alexey Loubyansky wrote:
> >
> > At the same time, there will still be the usual run.sh/run.bat that will start server instances as usually (passing by the domain.xml), they won't join the domain, i.e. will be running stand-alone and deployment operations and config changes will be performed traditionally manually.
> Yes and no. We can still have a deploy directory. But *if* we do, the scanner for that directory would take deployments and feed them through the DC, so the domain model info would be automatically updated at the same time.
>
> We can still have run.sh; it just starts the server manager which starts all the server instances according to domain.xml.
>
> I don't forsee any mode of operation that does not involve domain.xml. Even an embedded server should have something performing the role of DC and SM even if it's all in the same process space. This way there's only one API for deployment and configuration.
Agreed. Going through https://community.jboss.org/docs/DOC-15303 the lifecycle use cases what seems to be falling out is a two step process where step 1) is registering with a domain and getting the local environment consistent with the domain, then step 2) starting a Server based on the domain.xml. A "stand-alone server" use case or an embedded one would mostly differ from the more complete one in skipping step 1). (Embedded would presumably also at least partly use an API to establish the domain model rather than getting everything from a domain.xml.)
Interesting question on how to do deployment operations and make config changes on a "stand-alone" server. If the stand-alone server is running the DomainControllerSubprofile, then it exposes the full management capability of a larger domain and can be managed the same way. If it doesn't run the DomainControllerSubprofile, then we need to establish what post-startup management capability it will expose.
First, my opinion on a requirement: the "standalone server" and embedded use cases are meant for developers, not for production systems. Setting up a production system consisting of a bunch of stand-alone servers, each running the DomainControllerSubprofile could work but is not the recommended architecture. Setting up a production system consisting of a bunch of stand-alone servers that don't run the DomainControllerSubprofile is not a supported architecture.
Put another way, the full stable supported management API we are developing is exposed by a DomainController, so if you want the full capabilities you need the DomainControllerSubprofile. But what does API does the non-DC stand-alone server expose?
I think the answer to this will largely fall out of working through the embedded use cases, plus working out the interaction between a separate-process DC and a Server. For sure a stand-alone server needs an deployment API, otherwise it's useless in an IDE.
One thing I think there is consensus on: hot deployment is limited to a deploy/ dir that only contains end user deployments, no core services. So reconfiguring a core service by changing some -beans.xml file and having HDScanner pick it up is not a supported configuration mechanism.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546508#546508]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - default values in domain management
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"default values in domain management"
To view the discussion, visit: http://community.jboss.org/message/546496#546496
--------------------------------------------------------------
> Alexey Loubyansky wrote:
>
> Ok, so far we agree that defaults come from the deployment descriptors. At least it would be the next (perhaps not the last) source for initialization values if they are missing from the domain.xml.
Yeah, I think it's hard to say anything more specific without use case examples. Some things might not appear in a deployment descriptor at all though, like the JBossWeb server configuration for example, because they apply to the server as a whole, not a specific deployment.
> Alexey Loubyansky wrote:
> By property/value duplication I didn't mean it as a requirement for all the properties. But it will be the case for those that are overriden in domain.xml. It's not so much a value duplication but the property config duplication which won't be in sync (between the domain.xml and the deployment descriptors) which is a bit confusing.
What do you mean by "in sync" in this case? One would only override a configuration property if there was a deployment to override. I imagine that any overriding properties in the domain.xml file that pertain to a specific deployment will be children of an element which defines that deployment, so if there's no such element, there's no such deployment, and such an element can't exist without the deployment being present.
> Alexey Loubyansky wrote:
>
> Ok, so I think I understand it better now. Again, correct me if I am wrong:- to start a domain (member of a domain), I'll use a separate tool/script (not the usual run.sh/ran.bat) that will start things according to the domain.xml (that will happen in collaboration with the domain controller or actually the tool/script will just delegate the tasks to the domain controller);
> - further dynamic (hot) deployment operations will also be performed using a tool/script and through the domain controller;
> - config changes of any kind (including managed components) will be performed also using a tool/script and through the domain controller.
>
> So, actually, in the domain-running mode all the operations including start-up/shutdown and any config changes will be performed using a tool/script, not manually, i.e. not by manually changing deployment descriptors at runtime, manually copying/removing deployments from the deploy dir, etc.
>
> At the same time, there will still be the usual run.sh/run.bat that will start server instances as usually (passing by the domain.xml), they won't join the domain, i.e. will be running stand-alone and deployment operations and config changes will be performed traditionally manually.
Yes and no. We can still have a deploy directory. But *if* we do, the scanner for that directory would take deployments and feed them through the DC, so the domain model info would be automatically updated at the same time.
We can still have run.sh; it just starts the server manager which starts all the server instances according to domain.xml.
I don't forsee any mode of operation that does not involve domain.xml. Even an embedded server should have something performing the role of DC and SM even if it's all in the same process space. This way there's only one API for deployment and configuration.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546496#546496]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by Alexey Loubyansky
Alexey Loubyansky [http://community.jboss.org/people/alex.loubyansky%40jboss.com] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/546490#546490
--------------------------------------------------------------
> Scott Stark wrote:
> I still think the best comprimise would be to have profile definitions in the domain in terms of the required capabilities potentially simplified by having implied capabilities associated with each application type that could be overriden by the admin.
Ok, this makes sense. Taking it further... The profiles in the domain schema (as they are now) are kind of redefined, i.e. it's not the same profile definition/configuration as the actual profile configuration like here http://community.jboss.org/wiki/AS6ServerSideConfiguration http://community.jboss.org/wiki/AS6ServerSideConfiguration
So, I want to clarify the purpose and meaning of this redefinition in the domain config. Perhaps, it also makes sense to choose a different name not to confuse with the actual profiles.
I think if we can make domain.xml contain only the concepts/notions that are defined in its schema, it would be the best. I.e. if it contained (was expressed in) only the terms defined for it and learning additional concepts/notions for the user wouldn't be a requirement to understand the configuration.
Can we think about the profiles here as a set of capabilities that might be activated once there is an application requiring them? I.e. not to think about them as defining capabailities that must be activated after the start-up?
Perhaps, something like "environment" would describe it?
So, what I think we can do:
- define a set of implied capabilities associated with each application type (or define the "environment" for each application type);
- if an application is mentioned in the domain.xml w/o specified by the admin "environment" it requires, we assume our defaults;
- if the admin wants to be precise, it could look like
<application name="" path="">
<environment name=""/>
<environment-ref name=""/>
</application>
- there could be a section in the domain config where the admin can define his own named environments and reference them later for applications.
Then actually the set of applications mentioned in the domain.xml will dictate (through their "environments") which profiles/subprofiles to activate and run.
Does it make sense?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546490#546490]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - default values in domain management
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"default values in domain management"
To view the discussion, visit: http://community.jboss.org/message/546296#546296
--------------------------------------------------------------
> Alexey Loubyansky wrote:
>
> I thought it's worth a separate thread.
>
> There are of course very different kinds of properties. I.e. the ones that are set in deployment descriptors and those that can't be, e.g. jvm args, environment variables, etc.
You can break it down like this:
1. Properties that are part of a deployment
2. Properties that are global to the domain
3. Properties that are specific to a server group
4. Properties that are specific to a host
Items 1-3 are definitely part of the domain model either explicitly or implicitly. If I deploy an application into a server group or server groups, then that deployment becomes part of the domain.
> Alexey Loubyansky wrote:
> At least in the beginning, domain.xml could be optional from the server instance start-up point of view. I.e. it would be possible to start a stand-alone server instance without domain.xml. Then all the services/containers would be initialized from their deployment descriptors (and possibly other config files) as it's happening now. But if domain.xml is present then the values it contains will override the corresponding values from the deployment descriptors.
My feeling on this is that deployments have to be part of the domain model if we are to retain a consistent view of configuration and deployment (i.e. to allow "undo" operations and allow servers to go offline and download changes in order when they come back online). Since deployments are part of the domain model, you can't deploy without the domain controller. If you get deployments, you get a domain.xml, so it's not possible to start up a server with deployments but without domain.xml.
I don't think this is incompatible with the desire that people have to (a) keep a deploy/ drop-in directory like we have to day (for development purposes) or (b) have an embeddible mode. These could simply be a specialized, minimal implementation of the domain controller/server manager interaction.
> Alexey Loubyansky wrote:
>
> As Brian said in the other thread this approach implies that to have correct values of a manged component in an admin tool the managed service must be initialized at a minimum.
>
> In addition, the values for managed properties are duplicated, i.e. in the deployment descriptors and domain.xml, which is confusing. Admin tool will apply changes to domain.xml but not the deployment descriptor. domain.xml is synchronized between the server instances in the domain but deployment descriptors probably won't. Which means if the value is removed from the domain.xml the default value for the property on every server instance coming from the deployment descriptors maybe different.
I don't see any reason, given what I've said above, to *require* duplication of what's in the deployment descriptors into the domain.xml file. It would only happen in the case where something specific needs to be overridden.
Maybe Brian's idea of having the defaults in the schema isn't such a bad one after all: as long as we have separate namespaces for each successive version of each component, the version can be used to imply the defaults in play. We have to make sure that the implementation of the parsing layer makes it easy to support multiple namespaces (and know which is in play) in this case though.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546296#546296]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years