11:31 a.m.
I think you are coming at this from too much of a programming mind set.
I don't think decorator nesting is needed from Windup. What is needed
is a way to order the post processing and action classes to extract the detailed
data and perform the plugin calls.
Lets look at a specific lab example. Lab1 reports a set of needed actions
for migrating jboss-esb.xml. Here is the list.
Action : service binding configuration in jms-bus:
busid="quickstartGwChannel"
Action : service binding configuration in jms-bus:
busid="quickstartEsbChannel"
Action : composite service required for service: name="SimpleListener"
Action : composite service binding required for listener:
name="JMS-Gateway"
Action : create component service for action processing pipeline
Action : convert action class:
class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
Action : convert SystemPrintln:
class="org.jboss.soa.esb.actions.SystemPrintln"
Action : remove TestMessageStore:
class="org.jboss.soa.esb.actions.TestMessageStore"
This is an unordered list. Most of these represent individual forge-switchyard
cmds however there is a loose order needed for these. If we define a priority attribute
it might look like this. (0 is the highest priority)
priority
1 Action : service binding configuration in jms-bus:
busid="quickstartGwChannel"
1 Action : service binding configuration in jms-bus:
busid="quickstartEsbChannel"
0 Action : composite service required for service: name="SimpleListener"
0 Action : composite service binding required for listener:
name="JMS-Gateway"
1 Action : create component service for action processing pipeline
0 Action : convert action class:
class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
1 Action : convert SystemPrintln:
class="org.jboss.soa.esb.actions.SystemPrintln"
2 Action : remove TestMessageStore:
class="org.jboss.soa.esb.actions.TestMessageStore"
Or if we were using the pipeline model in which each rule has an ID and the ID
would be identified in the list. the list order would be
ref ID
6 Action : convert action class:
class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
3 Action : composite service required for service: name="SimpleListener"
4 Action : composite service binding required for listener:
name="JMS-Gateway"
5 Action : create component service for action processing pipeline
1 Action : service binding configuration in jms-bus:
busid="quickstartGwChannel"
2 Action : service binding configuration in jms-bus:
busid="quickstartEsbChannel"
7 Action : convert SystemPrintln:
class="org.jboss.soa.esb.actions.SystemPrintln"
8 Action : remove TestMessageStore:
class="org.jboss.soa.esb.actions.TestMessageStore"
There could be an PostProcessAction class associated with each unique action,
ConvertAction, CompositeServiceAction, ServiceBindingAction, .. etc)
Look at the action in my forge-integration-phase2-ActionDecorator branch code.
The ServicePostProcessor class has access to the original xpath and can do
extraction of any (extra) data it needs from jboss-esb.xml to populate the plugin cmd.
With the use of a PostProcessAction interface and SwitchardController that processes
all these action classes it should be fairly easy to pass what little data is needed
to be shared.
Here is a more complex (imaginary) case. Lets assume this action requires
data from jboss-esb.xml and some other file.
Action : service binding configuration in jms-bus:
busid="quickstartGwChannel"
Assume we have a rule that flags that other file.
If a ref ID to that other rule is provided to the ServiceBindingAction then
the action class can provide code to extract the needed data from that other
class and provide it to the plugin.
In summary I don't see the need for nesting of decorators to extract complex
data from 1 or more files. Detailed information can be extracted by the action
class. (this is equivalent to 2nd pass processing)
Your thoughts?
----- Original Message -----
From: "Robb Greathouse" <robb.greathouse(a)redhat.com>
To: "Rebecca Searls" <rsearls(a)redhat.com>
Cc: windup-dev(a)lists.jboss.org
Sent: Wednesday, September 11, 2013 11:36:52 AM
Subject: Re: Increasing depth of rules
The use case is to extract the values to pass to a Forge plugin.
Use case breaks down to this:
1. Identify an Action that needs to be migration. Example, Action :
Create Composite Service
a. This is created by an xPath.
2. Having identified the Action we need to extract the parameters
necessary to put into the plugin and run it.
Following this the mapping module could would map the the action and
parameters to the plugin commands.
In order to accomplish this, nesting is required so that the Action and
parameters can be linked. Since there can be any number of similar actions
can be found, I can't think of a way to link them with single layer and no
lists.
If they are nested they can be extracted from the archive in post processing.
Robb Greathouse
Partner Enablement
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
----- Original Message -----
>
>
>
> The rules are really only 1 level deep.
>
> There are grouping rules such as pipeline and xpath-gate. These tags group
> a
> set of rules like,
> xpath-value. The rules that do the real work, such as xpath-value only
> support a list of "decorator"
> under the decorator tag. That is as deep as it goes. Windup's
> implementation does not support multi-level
> nesting.
>
> Please send me a use case of what you are trying to do that requires nested
> decorators, maybe we can find another
> solution.
>
>
>
>
> ----- Original Message -----
> > From: "Robb Greathouse" <robb.greathouse(a)redhat.com>
> > To: "Rebecca Searls" <rsearls(a)redhat.com>
> > Cc: windup-dev(a)lists.jboss.org
> > Sent: Wednesday, September 11, 2013 10:47:47 AM
> > Subject: Increasing depth of rules
> >
> > Hi,
> >
> > I was wondering if you could point me to the place you found that limits
> > the
> > search depth?
> >
> > Robb Greathouse
> > Partner Enablement
> > Middleware Business Unit
> > JBoss, a Division of Red Hat
> > cellphone 505-507-4906
> >
> >
>