Its a good idea, one of the reasons we didn't do this was that you can create jar which contains more than one JBI component and therefore you can reference different jbi.xml's for different componets, this was to allow a situation where you might want to bundle a set of small/similar components in a single JAR bundle, in this case each of your component tags can refer to the location of the file that you wish to be the switched to the jbi.xmlwhen deployed.
ie. <components> <component descriptor="component1-jbi.xml"> .... </component> <component descriptor="component2-jbi.xml"> </component> </component> in this case you would have two components in the palette and during the deploy you would switch the component1-jbi.xml to be the jbi.xml. P On 1/17/06, Hossam Karim <[EMAIL PROTECTED]> wrote: > > Philip, > > Why not use the provided JBI schema to describe your design time > properties, > something like: > > > > <?xml version="1.0" encoding="UTF-8"?> > > <jbi xmlns="http://java.sun.com/xml/ns/jbi"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xmlns:ext="http://www.example.org/jbi/extension"; > > xsi:schemaLocation="http://java.sun.com/xml/ns/jbi ./jbi.xsd" > version="1"> > > <component type="binding-component"> > > <identification> > > <name>GroovyScript</name> > > <description>A component that can be deployed with an embedded > Groovy > Script</description> > > </identification> > > > <component-class-name>org.example.jbi.GroovyScriptBinding > </component-class-n > ame> > > <component-class-path> > > <path-element>.</path-element> > > </component-class-path> > > > <bootstrap-class-name>org.example.jbi.GroovyScriptBootstrap > </bootstrap-class > -name> > > <bootstrap-class-path> > > <path-element>.</path-element> > > </bootstrap-class-path> > > <ext:component> > > <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid> > > <assets> > > <embeddedArtifact name="script.groovy" extension="groovy" > description="Your Groovy Script"/> > > <parameter name="exampleparameter" defaultValue="haha" > description="Example parameter"/> > > <connection default="true" name="defaultDestination" > description="Default destination" mep="robustInOnly"/> > > </assets> > > </ext:component> > > </component> > > </jbi> > > > > So the document would be reusable for both design time and deployment. > > > > My team is using a similar approach. We created a UML 2.0 profile for JBI; > used deployment diagrams to define components and related artifacts, > annotating them using the profile stereotypes. We then export the model > into > an XMI document, and at build time, we run an XQuery against the exported > document to generate the descriptors. > > > > Cheers, > > Hossam Karim > > > > _____ > > From: Philip Dodds [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 17, 2006 9:12 PM > To: [email protected] > Subject: JBI Deployer > > > > We've been working on a re-usable deployment plugin for eclipse to try and > simplify the process of create components and actually making them > re-usable. The basic idea is fairly simple, when you build you JBI > component, whether it be a binding component or a service engine you > include a components.xml in the META-INF directory, which holds > information > about your component, and example of which is below: > > <components> > <component type="binding-component"> > > <componentUuid>1e194e80-7ee0-11da-bb92-0002a5d5c51b</componentUuid> > <name>Groovy Script</name> > <description> > A component that can be deployed with an embedded Groovy Script > </description> > <assets> > <embeddedArtifact name="script.groovy" extension="groovy" > description="Your Groovy Script" /> > <parameter name="exampleparameter" defaultValue="haha" > > description="Example parameter"/> > <connection default="true" name="defaultDestination" > > description="Default destination" mep="robustInOnly" /> > </assets> > </component> > > In essence the idea of your components.xml is to describe your components, > which can be either binding-components or service-engine, you can also > define embedded artifacts which are files you expect to be bundles with > either your service engine or binding-component, there is also space for > parameters and also connections to other services. The idea behind this > is > to express your requirements for your component so that someone knows what > they need to provide to get your working, the idea here is to make your > component re-usable without needing the source code. > > Then basically we have two projects, one which is the descriptors for > this > components.xml and also a file called assets.xml and the second is an > eclipse plugin that you can install and then register your components > with, > once you have the eclipse plugin installed in your eclipse you basically > can > goto preferences in eclipse and add all the packaged JBI components, > basically those JBI components with a jbi.xml that are your usual stuff > but > also with a components.xml in there. Once you have registered them you > can > create a project and add a file with the extension .jbi, this will open > the > JBI deployer which is basically just a GEF diagramming component, however > you will see you components (as registered from your components.xml) in > the > pallette, if you drop one on the canvas you will be able to configure the > settings (those also defined in the components.xml) and therefore > configure > a re-usable JBI component. If you component is a service engine you will > see component and be able to press the + button to create service units > inside, note that in this case you can gather parameters at a service > unit > by added parameters etc at the service unit level ie: > > <component type="service-engine"> > <componentUuid>658c0460-7ee0-11da-ba83-0002a5d5c51c</componentUuid> > <name>Translator</name> > <description> > Unity's transformation service engine > </description> > <serviceUnit> > <assets> > <embeddedArtifact name="translator.xml" extension="trslr" > description="Translator Configuration" /> > <parameter name="exampleparameter" defaultValue="haha" > description="Example parameter"/> > <connection default="true" name="defaultDestination" > description="Default destination" > mep="robustInOnly" /> > </assets> > </serviceUnit> > </component> > </components> > > Once you have set up your digram as you want it you can right click on a > component or service assembly and choose deploy, this will create the > component zips by basically exploding the base jar (which the > components.xml) and creating a new component injecting both the > embeddedArtifacts and also the assets (which are the parameters gathered > from the deployment editor), therefore you would have > META-INF/stored-assets.xml in either your binding-component or your > service > unit ie. > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > <storedAssets> > <artifactReference><name>script.groovy</name><path>whizbang.groovy > </path></a > > rtifactReference><resourceReference><name>defaultDestination</name><resource > xmlns:ns3=" > http://openuri.org"; > >ns3:newService2</resource></resourceReference><serviceNa > me > xmlns:ns3="http://openuri.org";>ns3:newService</serviceName></storedAssets> > > In the descriptor package with then supply a simple StoredAssetFactory you > can give either your service unit deploy path to or your component context > to get your assets back. > > The basic idea here is to make the packaging of a JBI component or re-use > and also the deployment of complex patterns easier with a graphical > environment and a mechanism for exposing your code and requesting the > artifacts etc you want. > > We (Unity Systems) have been working on this for the past couple of months > and believe that the ServiceMix project would benefit from this style of > deployment as it would enable easier configuration and deployment. There > are a couple of downsides first is it was written for Java 5 and the > second > is a dependency on JAXB2. > > If the team think this is a good idea or have comments we can place a cut > of > the code somewhere for review or we can make it a tooling project and > examine maybe how we could document the lw-container to make it a good > basis > to writing a component and passing it parameters, also we might want to > see if some of the service-components could be modified to be able to use > the stored assets if available. > > All comments and thoughts are welcome :) > > Cheers > > P > > >
