[windup-dev] [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62)
Robb Greathouse
robb.greathouse at redhat.com
Thu Sep 5 17:19:26 EDT 2013
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 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