3:25 p.m.
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>
To: "Rebecca Searls" <rsearls(a)redhat.com>
Cc: "Lincoln Baxter" <lbaxter(a)redhat.com>, "Robb Greathouse"
<robb.greathouse(a)jboss.com>, "windup/windup"
<windup(a)noreply.github.com>, "Brad Davis" <bdavis(a)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(a)github.com>
> > To: "windup/windup" <windup(a)noreply.github.com>
> > Cc: "rsearls" <rsearls(a)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
> >
>