From: "Robb Greathouse" <robb.greathouse(a)redhat.com&gt; To: "Rebecca Searls" <rsearls(a)redhat.com&gt; Cc: "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "Robb Greathouse" <robb.greathouse(a)jboss.com&gt;, "windup/windup" <windup(a)noreply.github.com&gt;, "Brad Davis" <bdavis(a)redhat.com&gt; Sent: Thursday, September 5, 2013 12:26:38 PM Subject: Re: [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62) Hi, Ran into same issues. Agree with your analysis. As stop gap I am using the windup:xpath-value to test mappings. But as you point out this is not a good long term solution. We will need to create a migration-decorator that can handle command and parameter mappings. When Brad gets back we can discuss the best way to create these in accordance with his architecture. In the meantime, we should start collecting use case for mapping decorators. Robb Greathouse Partner Enablement Middleware Business Unit JBoss, a Division of Red Hat cellphone 505-507-4906 ----- Original Message ----- > > I will be interested to hear what you found out about ShrinkWrap. It seems > this project is just getting started up again. > > Changing the subject slightly. The implementation I currently have in > place > is not really what we want going forward. > My questions to Brad about how to handling the, "Action : convert action > class: class=org.jboss.thing.MySeviceAction" > and such was trying to ferret this out. Based upon information that came > out > in our conf call, the design that is wanted > is for each rule to have a "Post-Action-Decorator" which gets executed at > the > end of the analysis phase. For SOA we want > the current controller to execute each Post-Action-Decorator it finds. > Each > of these decorators performs a small (limited) > task. One will generate the Intf/Impl class. One will create a JMS-bus > service binding. One will create and bind a > Camel route. These are based upon the "Action : *" stmts currently > generated. > > As a short term workaround critical information has been appended in the > description message (e.g. class=org.jboss.thing.MySeviceAction, > busid=helloFTPChannel). This is not the desired way to this pass > information as we move > forward. Its fraught with all kinds of issues. > > I am thinking the issues and though ways to address them. I will be sharing > my thoughts and asking for feedback. > It would also be good to have this discussion in the community. I don't > think there are yet may subscribers to > windup-dev or followers of the forum. Should I start the discussion on the > email list anyway or should I look > to some other alias? > > > > > ----- Original Message ----- > > From: "Lincoln Baxter, III" <notifications(a)github.com&gt; > > To: "windup/windup" <windup(a)noreply.github.com&gt; > > Cc: "rsearls" <rsearls(a)redhat.com&gt; > > Sent: Wednesday, September 4, 2013 4:18:16 PM > > Subject: Re: [windup] Forge integration (changes to have windup > > generating > > switchyard classes using > > plugin-switchyard api) (#62) > > > > > + LOG.warn("No class attribute for > > > action > > > tag class=" > > > + + nName.getNodeValue()); > > > + } > > > + > > > + } else { > > > + String className = > > > StringUtils.substringAfterLast( > > > + nClass.getNodeValue(), "."); > > > + String packageName = > > > StringUtils.substringBeforeLast( > > > + nClass.getNodeValue(), "."); > > > + > > > + LOG.debug("Action tag's baseName: " + > > > className > > > + + " package: " + packageName); > > > + > > > + BeanFacet beanFacet = > > > facetFactory.create(project, BeanFacet.class); > > > + beanFacet.install(); > > > + BeanServiceConfigurator > > > beanServiceConfigurator = > > > > Excellent, this is exactly the kind of integration we want to drive :) > > Sucks > > you have to use XPath, though. In reality, it's possible that ShrinkWrap > > Descriptors could be leveraged to provide a DSL to inspect the jbossesb > > XML > > file. Let me see what Andrew Rubinger thinks about this. > > > > --- > > Reply to this email directly or view it on GitHub: > > https://github.com/windup/windup/pull/62/files#r6165297 > > >

Here is what I am thinking of in providing an ActionDecorator. <!-- An example of the addition of an "actions" tag to the existing rules structure ServiceCreationDecorator must implement an MetaActionDecorator interface. It would have access to a generated xpath to the specific node found and possible other information from the rule decorator. The SwitchyardController would call the process method of this class which would call the plugin-forge code to create the service. --> <windup:xpath-value description="Action : convert action class" xpath="//*[local-name()='action' and not(starts-with(@class, 'org.jboss.soa.esb.actions'))]/@class" effort="1" inline="true"> <windup:actions> <windup:action description="Create Switchyard Intf/Impl service classes" class="org.jboss.windup.switchyard.ServiceCreationDecorator" /> </windup:actions> </windup:xpath-value> -------------- -- Here is the schema <xs:complexType name="xpathType"> <xs:sequence> <xs:element name="namespace" type="xmlNamespace" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="hints" type="allBeans" minOccurs="0" maxOccurs="1"/> <xs:element name="decorators" type="allBeans" minOccurs="0" maxOccurs="1"/> <xs:element name="actions" type="actionsType" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="xpath" use="required" type="xs:string" /> <xs:attribute name="description" use="required" type="xs:string" /> <xs:attribute name="effort" type="xs:int" /> </xs:complexType> <xs:complexType name="actionType"> <xs:annotation> <xs:documentation> Attribute class must be the fully qualified name of the class that implements the ActionDecorator interface. The class must be available in a jar file in the classpath of this tool. The class will be executed in the post-analysis phase of Windup. Attribute condition indicates when the action is to be executed. The default value is true; (i.e. when the test condition yields true the action will be run.) A setting of false will run this action if the test condition yields false. </xs:documentation> </xs:annotation> <xs:attribute name="description" use="optional" type="xs:string" /> <xs:attribute name="class" use="required" type="xs:string" /> <xs:attribute name="condition" use="optional" type="xs:string" default="true"/> </xs:complexType> ----------------- Here is the Interface public interface MetaActionDecorator { public void setCondition(String inline); public boolean isCondition(); public void setDescription(String description); public String getDescription(); public void setActionClass(String fullyQualifiedName); public String getActionClass(); public abstract boolean process(); } ----------------- Here is a convenience class public abstract class ActionDecorator implements MetaActionDecorator { private static final Log LOG = LogFactory.getLog(ChainingDecorator.class); private boolean condition = true; private String description; private String fullyQualifiedName; public void setCondition(String condition){ this.condition = BooleanUtils.toBoolean(condition); } public boolean isCondition(){ return condition; } public void setDescription(String description){ this.description = description; } public String getDescription(){ return this.description; } public void setActionClass(String fullyQualifiedName){ this.fullyQualifiedName = fullyQualifiedName; } public String getActionClass(){ return this.fullyQualifiedName; } /** * Add rule specific processing here. * @return */ public abstract boolean process(); } ----- Original Message ----- > From: "Robb Greathouse" <robb.greathouse(a)redhat.com&gt; > To: "Rebecca Searls" <rsearls(a)redhat.com&gt; > Cc: "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "Robb Greathouse" > <robb.greathouse(a)jboss.com&gt;, "windup/windup" > <windup(a)noreply.github.com&gt;, "Brad Davis" <bdavis(a)redhat.com&gt; > Sent: Thursday, September 5, 2013 12:26:38 PM > Subject: Re: [windup] Forge integration (changes to have windup generating > switchyard classes using > plugin-switchyard api) (#62) > > Hi, > > Ran into same issues. Agree with your analysis. As stop gap I am using > the > windup:xpath-value to test mappings. But as you point out this is not a > good long term solution. > > We will need to create a migration-decorator that can handle command and > parameter mappings. > > When Brad gets back we can discuss the best way to create these in > accordance > with his architecture. In the meantime, we should start collecting use > case > for mapping decorators. > > > Robb Greathouse > Partner Enablement > Middleware Business Unit > JBoss, a Division of Red Hat > cellphone 505-507-4906 > > ----- Original Message ----- > > > > I will be interested to hear what you found out about ShrinkWrap. It > > seems > > this project is just getting started up again. > > > > Changing the subject slightly. The implementation I currently have in > > place > > is not really what we want going forward. > > My questions to Brad about how to handling the, "Action : convert action > > class: class=org.jboss.thing.MySeviceAction" > > and such was trying to ferret this out. Based upon information that came > > out > > in our conf call, the design that is wanted > > is for each rule to have a "Post-Action-Decorator" which gets executed at > > the > > end of the analysis phase. For SOA we want > > the current controller to execute each Post-Action-Decorator it finds. > > Each > > of these decorators performs a small (limited) > > task. One will generate the Intf/Impl class. One will create a JMS-bus > > service binding. One will create and bind a > > Camel route. These are based upon the "Action : *" stmts currently > > generated. > > > > As a short term workaround critical information has been appended in the > > description message (e.g. class=org.jboss.thing.MySeviceAction, > > busid=helloFTPChannel). This is not the desired way to this pass > > information as we move > > forward. Its fraught with all kinds of issues. > > > > I am thinking the issues and though ways to address them. I will be > > sharing > > my thoughts and asking for feedback. > > It would also be good to have this discussion in the community. I don't > > think there are yet may subscribers to > > windup-dev or followers of the forum. Should I start the discussion on > > the > > email list anyway or should I look > > to some other alias? > > > > > > > > > > ----- Original Message ----- > > > From: "Lincoln Baxter, III" <notifications(a)github.com&gt; > > > To: "windup/windup" <windup(a)noreply.github.com&gt; > > > Cc: "rsearls" <rsearls(a)redhat.com&gt; > > > Sent: Wednesday, September 4, 2013 4:18:16 PM > > > Subject: Re: [windup] Forge integration (changes to have windup > > > generating > > > switchyard classes using > > > plugin-switchyard api) (#62) > > > > > > > + LOG.warn("No class attribute for > > > > action > > > > tag class=" > > > > + + nName.getNodeValue()); > > > > + } > > > > + > > > > + } else { > > > > + String className = > > > > StringUtils.substringAfterLast( > > > > + nClass.getNodeValue(), "."); > > > > + String packageName = > > > > StringUtils.substringBeforeLast( > > > > + nClass.getNodeValue(), "."); > > > > + > > > > + LOG.debug("Action tag's baseName: " + > > > > className > > > > + + " package: " + packageName); > > > > + > > > > + BeanFacet beanFacet = > > > > facetFactory.create(project, BeanFacet.class); > > > > + beanFacet.install(); > > > > + BeanServiceConfigurator > > > > beanServiceConfigurator = > > > > > > Excellent, this is exactly the kind of integration we want to drive :) > > > Sucks > > > you have to use XPath, though. In reality, it's possible that > > > ShrinkWrap > > > Descriptors could be leveraged to provide a DSL to inspect the jbossesb > > > XML > > > file. Let me see what Andrew Rubinger thinks about this. > > > > > > --- > > > Reply to this email directly or view it on GitHub: > > > https://github.com/windup/windup/pull/62/files#r6165297 > > > > > >

From: "Robb Greathouse" <robb.greathouse(a)redhat.com&gt; To: "Rebecca Searls" <rsearls(a)redhat.com&gt; Cc: windup-dev(a)lists.jboss.org, "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "Robb Greathouse" <robb.greathouse(a)jboss.com&gt;, "Brad Davis" <bdavis(a)redhat.com&gt; Sent: Thursday, September 5, 2013 5:20:53 PM Subject: Re: [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62) Hi, Looks like you have put a lot of thought into this. Could we have a Google Hangout tomorrow morning so you could walk us through this? I would like to fully understand before commenting. Robb Greathouse Partner Enablement Middleware Business Unit JBoss, a Division of Red Hat cellphone 505-507-4906 ----- Original Message ----- > > Here is what I am thinking of in providing an ActionDecorator. > > <!-- > An example of the addition of an "actions" tag to the existing rules > structure > > ServiceCreationDecorator must implement an MetaActionDecorator interface. > It would have access to a generated xpath to the specific node found and > possible other information from the rule decorator. > The SwitchyardController would call the process method of this class > which would call the plugin-forge code to create the service. > --> > <windup:xpath-value description="Action : convert action class" > xpath="//*[local-name()='action' and not(starts-with(@class, > 'org.jboss.soa.esb.actions'))]/@class" > effort="1" inline="true"> > > <windup:actions> > <windup:action description="Create Switchyard Intf/Impl service > classes" > class="org.jboss.windup.switchyard.ServiceCreationDecorator" /> > </windup:actions> > > </windup:xpath-value> > > -------------- > -- Here is the schema > > <xs:complexType name="xpathType"> > <xs:sequence> > <xs:element name="namespace" type="xmlNamespace" minOccurs="0" > maxOccurs="unbounded"/> > <xs:element name="hints" type="allBeans" minOccurs="0" maxOccurs="1"/> > <xs:element name="decorators" type="allBeans" minOccurs="0" > maxOccurs="1"/> > <xs:element name="actions" type="actionsType" minOccurs="0" > maxOccurs="1"/> > </xs:sequence> > <xs:attribute name="xpath" use="required" type="xs:string" /> > <xs:attribute name="description" use="required" type="xs:string" /> > <xs:attribute name="effort" type="xs:int" /> > </xs:complexType> > > > <xs:complexType name="actionType"> > <xs:annotation> > <xs:documentation> > Attribute class must be the fully qualified name of the > class > that > implements the ActionDecorator interface. The class must > be > available > in a jar file in the classpath of this tool. The class > will > be executed > in the post-analysis phase of Windup. > > Attribute condition indicates when the action is to be > executed. > The default value is true; (i.e. when the test condition > yields true > the action will be run.) A setting of false will run this > action if > the test condition yields false. > > </xs:documentation> > </xs:annotation> > <xs:attribute name="description" use="optional" type="xs:string" /> > <xs:attribute name="class" use="required" type="xs:string" /> > <xs:attribute name="condition" use="optional" type="xs:string" > default="true"/> > </xs:complexType> > > > ----------------- > Here is the Interface > > public interface MetaActionDecorator { > public void setCondition(String inline); > public boolean isCondition(); > public void setDescription(String description); > public String getDescription(); > public void setActionClass(String fullyQualifiedName); > public String getActionClass(); > public abstract boolean process(); > } > > > ----------------- > Here is a convenience class > > public abstract class ActionDecorator implements MetaActionDecorator { > private static final Log LOG = > LogFactory.getLog(ChainingDecorator.class); > > private boolean condition = true; > private String description; > private String fullyQualifiedName; > > public void setCondition(String condition){ > this.condition = BooleanUtils.toBoolean(condition); > } > > public boolean isCondition(){ > return condition; > } > public void setDescription(String description){ > this.description = description; > } > > public String getDescription(){ > return this.description; > } > > public void setActionClass(String fullyQualifiedName){ > this.fullyQualifiedName = fullyQualifiedName; > } > > public String getActionClass(){ > return this.fullyQualifiedName; > } > > /** > * Add rule specific processing here. > * @return > */ > public abstract boolean process(); > } > > > > > > > > > > ----- Original Message ----- > > From: "Robb Greathouse" <robb.greathouse(a)redhat.com&gt; > > To: "Rebecca Searls" <rsearls(a)redhat.com&gt; > > Cc: "Lincoln Baxter" <lbaxter(a)redhat.com&gt;, "Robb Greathouse" > > <robb.greathouse(a)jboss.com&gt;, "windup/windup" > > <windup(a)noreply.github.com&gt;, "Brad Davis" <bdavis(a)redhat.com&gt; > > Sent: Thursday, September 5, 2013 12:26:38 PM > > Subject: Re: [windup] Forge integration (changes to have windup > > generating > > switchyard classes using > > plugin-switchyard api) (#62) > > > > Hi, > > > > Ran into same issues. Agree with your analysis. As stop gap I am using > > the > > windup:xpath-value to test mappings. But as you point out this is not a > > good long term solution. > > > > We will need to create a migration-decorator that can handle command and > > parameter mappings. > > > > When Brad gets back we can discuss the best way to create these in > > accordance > > with his architecture. In the meantime, we should start collecting use > > case > > for mapping decorators. > > > > > > Robb Greathouse > > Partner Enablement > > Middleware Business Unit > > JBoss, a Division of Red Hat > > cellphone 505-507-4906 > > > > ----- Original Message ----- > > > > > > I will be interested to hear what you found out about ShrinkWrap. It > > > seems > > > this project is just getting started up again. > > > > > > Changing the subject slightly. The implementation I currently have in > > > place > > > is not really what we want going forward. > > > My questions to Brad about how to handling the, "Action : convert > > > action > > > class: class=org.jboss.thing.MySeviceAction" > > > and such was trying to ferret this out. Based upon information that > > > came > > > out > > > in our conf call, the design that is wanted > > > is for each rule to have a "Post-Action-Decorator" which gets executed > > > at > > > the > > > end of the analysis phase. For SOA we want > > > the current controller to execute each Post-Action-Decorator it finds. > > > Each > > > of these decorators performs a small (limited) > > > task. One will generate the Intf/Impl class. One will create a > > > JMS-bus > > > service binding. One will create and bind a > > > Camel route. These are based upon the "Action : *" stmts currently > > > generated. > > > > > > As a short term workaround critical information has been appended in > > > the > > > description message (e.g. class=org.jboss.thing.MySeviceAction, > > > busid=helloFTPChannel). This is not the desired way to this pass > > > information as we move > > > forward. Its fraught with all kinds of issues. > > > > > > I am thinking the issues and though ways to address them. I will be > > > sharing > > > my thoughts and asking for feedback. > > > It would also be good to have this discussion in the community. I > > > don't > > > think there are yet may subscribers to > > > windup-dev or followers of the forum. Should I start the discussion on > > > the > > > email list anyway or should I look > > > to some other alias? > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Lincoln Baxter, III" <notifications(a)github.com&gt; > > > > To: "windup/windup" <windup(a)noreply.github.com&gt; > > > > Cc: "rsearls" <rsearls(a)redhat.com&gt; > > > > Sent: Wednesday, September 4, 2013 4:18:16 PM > > > > Subject: Re: [windup] Forge integration (changes to have windup > > > > generating > > > > switchyard classes using > > > > plugin-switchyard api) (#62) > > > > > > > > > + LOG.warn("No class attribute for > > > > > action > > > > > tag class=" > > > > > + + nName.getNodeValue()); > > > > > + } > > > > > + > > > > > + } else { > > > > > + String className = > > > > > StringUtils.substringAfterLast( > > > > > + nClass.getNodeValue(), "."); > > > > > + String packageName = > > > > > StringUtils.substringBeforeLast( > > > > > + nClass.getNodeValue(), "."); > > > > > + > > > > > + LOG.debug("Action tag's baseName: " > > > > > + > > > > > className > > > > > + + " package: " + packageName); > > > > > + > > > > > + BeanFacet beanFacet = > > > > > facetFactory.create(project, BeanFacet.class); > > > > > + beanFacet.install(); > > > > > + BeanServiceConfigurator > > > > > beanServiceConfigurator = > > > > > > > > Excellent, this is exactly the kind of integration we want to drive > > > > :) > > > > Sucks > > > > you have to use XPath, though. In reality, it's possible that > > > > ShrinkWrap > > > > Descriptors could be leveraged to provide a DSL to inspect the > > > > jbossesb > > > > XML > > > > file. Let me see what Andrew Rubinger thinks about this. > > > > > > > > --- > > > > Reply to this email directly or view it on GitHub: > > > > https://github.com/windup/windup/pull/62/files#r6165297 > > > > > > > > > >