[windup-dev] [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62)
Rebecca Searls
rsearls at redhat.com
Thu Sep 5 16:25:59 EDT 2013
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 at redhat.com>
> To: "Rebecca Searls" <rsearls at redhat.com>
> Cc: "Lincoln Baxter" <lbaxter at redhat.com>, "Robb Greathouse" <robb.greathouse at jboss.com>, "windup/windup"
> <windup at noreply.github.com>, "Brad Davis" <bdavis at redhat.com>
> 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 at github.com>
> > > To: "windup/windup" <windup at noreply.github.com>
> > > Cc: "rsearls" <rsearls at redhat.com>
> > > 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
> > >
> >
>
More information about the windup-dev
mailing list