9:47 a.m.
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
10:01 a.m.
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
10:36 a.m.
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
>
>
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
> >
> >
>
11:37 a.m.
Hi,
I see your approach. I could be done in post processing. There is a SwitchYardController
in the reporting module.
I wrote something to go through the archive file to show its structure. It would be easy
to write something that would first find the file(s) of interest and then find the
actions. Then from there get the parameters.
Ok, will work on that.
Robb Greathouse
Partner Enablement
Middleware Business Unit
JBoss, a Division of Red Hat
cellphone 505-507-4906
----- Original Message -----
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
> > >
> > >
> >
>
4124
days inactive
4124
days old
4 comments
2 participants
participants (2)
-
Rebecca Searls -
Robb Greathouse