[windup-dev] Increasing depth of rules

[Robb Greathouse]

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 at redhat.com>
> > To: "Rebecca Searls" <rsearls at redhat.com>
> > Cc: windup-dev at 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 at redhat.com>
> > > > To: "Rebecca Searls" <rsearls at redhat.com>
> > > > Cc: windup-dev at 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
> > > > 
> > > > 
> > > 
> > 
>