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 <[EMAIL PROTECTED]> 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
