[windup-dev] [windup] Forge integration (changes to have windup generating switchyard classes using plugin-switchyard api) (#62)
Rebecca Searls
rsearls at redhat.com
Fri Sep 6 06:59:21 EDT 2013
I'm available all day. Any time you want to have a hangout I'm available.
----- Original Message -----
> From: "Robb Greathouse" <robb.greathouse at redhat.com>
> To: "Rebecca Searls" <rsearls at redhat.com>
> Cc: windup-dev at lists.jboss.org, "Lincoln Baxter" <lbaxter at redhat.com>, "Robb Greathouse" <robb.greathouse at jboss.com>,
> "Brad Davis" <bdavis at redhat.com>
> 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 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