Re: [windup-dev] [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62)

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 > > > > > >