You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Soumadeep-Infravio <so...@infravio.com> on 2006/08/07 15:06:06 UTC

BAm Component - Data configuration

Hi Guillaume/All

We are almost there with the BAMComponent, as discussed in the earlier emails, we have used the maven archetype (which was uploaded by SM guys) for developing the JBI component.

The next step is to figure out a proper way of feeding configuration related data for the BAMComponent. As pointed out earlier the component in question would require data for KPI-Key performance indicator (currently xpath based), Actions and global configurations.

My idea was to use XMLBeans based on xsds for the same but am thinking otherwise as it would introduce some maintenance going forward. The other option is to use properties file but then again it would pose a challenge when the elements get nested, it will become too convoluted to handle. So the question is still open -> what to use or what could be an elegant solution for this.

Thanks
Soumadeep

 

 

Re: BAm Component - Data configuration

Posted by soumadeep sen <so...@gmail.com>.
Awesome idea... let me get this working.

Soumadeep


On 8/7/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I really think that XBean is the most flexible option, as it allow easy
> extension (using spring syntax), validation using the xml schemas and it
> would be more homegeneous with the remaining of ServiceMix.
>
> For actions, you could define these properties on the BAMEndpoint:
> private Action[] actions;
> private Resource actionsResource;
> with the appropriate getters / setters, where
>   Action is an interface defined by the BAM component, and Resource is a
> spring resource (org.springframework.core.io.Resouce).
>
> Let's you have an Action implementation with the MyAction class, if you
> annotate the javadoc with the @org.apache.xbean.XBean annotation, you
> would
> have:
>
> <bam:endpoint ...>
>    <bam:actions>
>      <bam:myAction .../>
>    </bam:actions>
> </bam:endpoint>
>
> The actionsResource would be used if you want to split the actions
> definition in another file.
>   <bam:endpoint actionsResource="classpath:actions.xml" ... />
> Where the file would contain something like:
> <beans xmlns:bam="xx">
>    <bam:myAction .../>
> </beans>
>
> This would allow to easily extend the set of actions, either by adding a
> predefined action in the
> component, but also by embedding the class in the SU and use standard
> spring
> syntax:
> <bam:endpoint ...>
>    <bam:actions>
>      <bean class="my.company.myAction" ... />
>    </bam:actions>
> </bam:endpoint>
>
>
> On 8/7/06, Soumadeep-Infravio <so...@infravio.com> wrote:
> >
> > Hi Guillaume/All
> >
> > We are almost there with the BAMComponent, as discussed in the earlier
> > emails, we have used the maven archetype (which was uploaded by SM guys)
> for
> > developing the JBI component.
> >
> > The next step is to figure out a proper way of feeding configuration
> > related data for the BAMComponent. As pointed out earlier the component
> in
> > question would require data for KPI-Key performance indicator (currently
> > xpath based), Actions and global configurations.
> >
> > My idea was to use XMLBeans based on xsds for the same but am thinking
> > otherwise as it would introduce some maintenance going forward. The
> other
> > option is to use properties file but then again it would pose a
> challenge
> > when the elements get nested, it will become too convoluted to handle.
> So
> > the question is still open -> what to use or what could be an elegant
> > solution for this.
> >
> > Thanks
> > Soumadeep
> >
> >
> >
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
>
>

Re: BAm Component - Data configuration

Posted by Guillaume Nodet <gn...@gmail.com>.
I really think that XBean is the most flexible option, as it allow easy
extension (using spring syntax), validation using the xml schemas and it
would be more homegeneous with the remaining of ServiceMix.

For actions, you could define these properties on the BAMEndpoint:
  private Action[] actions;
  private Resource actionsResource;
with the appropriate getters / setters, where
   Action is an interface defined by the BAM component, and Resource is a
spring resource (org.springframework.core.io.Resouce).

Let's you have an Action implementation with the MyAction class, if you
annotate the javadoc with the @org.apache.xbean.XBean annotation, you would
have:

  <bam:endpoint ...>
    <bam:actions>
      <bam:myAction .../>
    </bam:actions>
  </bam:endpoint>

The actionsResource would be used if you want to split the actions
definition in another file.
   <bam:endpoint actionsResource="classpath:actions.xml" ... />
Where the file would contain something like:
  <beans xmlns:bam="xx">
    <bam:myAction .../>
  </beans>

This would allow to easily extend the set of actions, either by adding a
predefined action in the
component, but also by embedding the class in the SU and use standard spring
syntax:
  <bam:endpoint ...>
    <bam:actions>
      <bean class="my.company.myAction" ... />
    </bam:actions>
  </bam:endpoint>


On 8/7/06, Soumadeep-Infravio <so...@infravio.com> wrote:
>
> Hi Guillaume/All
>
> We are almost there with the BAMComponent, as discussed in the earlier
> emails, we have used the maven archetype (which was uploaded by SM guys) for
> developing the JBI component.
>
> The next step is to figure out a proper way of feeding configuration
> related data for the BAMComponent. As pointed out earlier the component in
> question would require data for KPI-Key performance indicator (currently
> xpath based), Actions and global configurations.
>
> My idea was to use XMLBeans based on xsds for the same but am thinking
> otherwise as it would introduce some maintenance going forward. The other
> option is to use properties file but then again it would pose a challenge
> when the elements get nested, it will become too convoluted to handle. So
> the question is still open -> what to use or what could be an elegant
> solution for this.
>
> Thanks
> Soumadeep
>
>
>
>
>


-- 
Cheers,
Guillaume Nodet