You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Peter Klotz <pe...@blue-elephant-systems.com> on 2006/04/03 17:06:37 UTC
servicemix.xml and servicemix-http vs. old SM http component
Hi,
I've derived from the
servicemix-3.0-SNAPSHOT/servicemix-http/src/test/resources/org/apache/servicemix/http/spring.xml
example this servicemix.xml and try to run it.
Through commenting parts out I could prove that something must be wrong with the
part <http:component>. The exception I get is attached below.
servicemix-http and servicemix-lwcontainer is deployed in servicemix
In some postings I saw <sm:serviceunit id="jbi">
when can/must one use this?
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:sm="http://servicemix.apache.org/config/1.0"
xmlns:http="http://servicemix.apache.org/http/1.0"
xmlns:test="http://test">
<!-- the JBI container -->
<sm:container id="jbi"
rootDir="./wdir"
MBeanServer="#mbeanServer"
installationDirPath="./install"
deploymentDirPath="./deploy"
dumpStats="true"
statsInterval="10"
flowName="seda">
<sm:activationSpecs>
<!-- output using a POJO -->
<sm:activationSpec service="test:httpConnector" endpoint="httpConnector">
<sm:component>
<http:component>
<http:endpoints>
<http:endpoint service="test:MyConsumerService" endpoint="myConsumer"
role="consumer"
locationURI="http://localhost:8192/Service/"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"/>
</http:endpoints>
</http:component>
</sm:component>
</sm:activationSpec>
<sm:activationSpec service="test:MyConsumerService" endpoint="myConsumer">
<sm:component>
<bean class="org.apache.servicemix.components.util.EchoComponent"/>
</sm:component>
</sm:activationSpec>
</sm:activationSpecs>
</sm:container>
...
INFO - JBIContainer.init(508) | ServiceMix JBI Container
(http://servicemix.org/) name: ServiceMix running version: 3.0-SNAPSHOT
Caught: org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'jbi' defined in file
[/home/pak/sandbox/servicemix-3.0-SNAPSHOT/examples/test/servicemix.xml]:
Initialization of bean failed; nested exception is
java.lang.IllegalArgumentException: Component name:
ID:sequoia-32971-1144075447193-0:0 is bound to an object which is not a JBI
component, it is of type: javax.xml.namespace.QName
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'jbi' defined in file
[/home/pak/sandbox/servicemix-3.0-SNAPSHOT/examples/test/servicemix.xml]:
Initialization of bean failed; nested exception is
java.lang.IllegalArgumentException: Component name:
ID:sequoia-32971-1144075447193-0:0 is bound to an object which is not a JBI
component, it is of type: javax.xml.namespace.QName
java.lang.IllegalArgumentException: Component name:
ID:sequoia-32971-1144075447193-0:0 is bound to an object which is not a JBI
component, it is of type: javax.xml.namespace.QName
at
org.apache.servicemix.jbi.container.JBIContainer.activateComponent(JBIContainer.java:885)
at
org.apache.servicemix.jbi.container.SpringJBIContainer.afterPropertiesSet(SpringJBIContainer.java:67)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:363)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:320)
at
org.apache.xbean.spring.context.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:149)
at
org.apache.xbean.spring.context.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:48)
at org.apache.servicemix.Main.main(Main.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchStandard(Launcher.java:410)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:344)
at org.codehaus.classworlds.Launcher.main(Launcher.java:461)
It works if I replace the http:component by the old SM component
<sm:activationSpec componentName="httpReceiver"
service="foo:httpBinding"
endpoint="httpReceiver"
destinationService="test:MyConsumerService">
<sm:component>
<bean class="org.apache.servicemix.components.http.HttpConnector">
<property name="host" value="localhost"/>
<property name="port" value="8912"/>
</bean>
</sm:component>
</sm:activationSpec>
Now the question is how do I use the new servicemix-http?
Peter
Re: servicemix.xml and servicemix-http vs. old SM http component
Posted by Guillaume Nodet <gn...@gmail.com>.
On 4/6/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
> Hi Guillaume,
>
> Thanks for your answer, the JBI-compliant mode is what I'm looking for but apart
> from the JBI spec it is hard to find docu. I need dynamic deploy/undeploy
> start/stop.
Yeah, given the state of the docs, i think a quick reading of the JBI
spec is a real need to understand the concepts.
>
> servicemix-jsr181 and servicemix-http would be configured with a xbean.xml and
> if one uses the SU servicemix-lwcontainer (as in the loan-broker example) one
> can specify a servicemix.xml configuration file.
Right
>
> As an example let's say I have an "adaptor" to a certain backend system that
> consists of multiple Spring-components/beans and one JBI-component that inherits
> from ComponentSupport and consumes a MessageExchange.
> This would be a service unit?
Yes. Note that -jsr181, -http or -lwcontainer components all use a
spring (xbean) configuration file, so that you put all the spring
beans you want in it.
> Because I have inherited from ComponentSupport I would need a lwcontainer?
> One could also inherit from BaseComponent then one would have a real JBI
> component but that would be more effort to implement.
Actually, a lightweight IS a jbi component. If you wish, you could
write a jbi deployment descriptor and deploy it as a standard jbi
component. The main difference is that the ComponentSupport class
helps writing simple components (without deployments, etc...) whereas
the BaseComponent and related classes are targeted for complex
components.
>
> A service assembly would then be a set of our own SUs (aka adaptors), some BU
> like servicemix-http and serviceix-soap and a SU that e.g. contains a router to
> distribute requests comming from the http endpoint to the adaptor SUs?
A service assembly can only contains one or more service units. What
do you mean by BU ? The main purpose of a service assembly is to
deploy and manage the lifecycle of several service units that are
deployed to different components in an atomic way. So usually, they
will contain service units that are related: for example a service and
the http binding.
> Is it a good idea to have multiple servicemix-lwcontainer running one in each SU?
Not sure what you mean... The servicemix-lwcontainer is a component
and thus should be installed in the JBI container. Then you can
deploy several service units onto it. There is no need for several
servicemix-lwcontainer components. This is usually true for all
components, unless you need different incompatible configurations.
Hope this helps,
Guillaume Nodet
>
>
> Peter
>
> Guillaume Nodet wrote:
> >
> > The other way is to use what the JBI spec explains: install a
> > component, then deploy a service unit / service assembly onto it.
> > The deployable artifact is the service assembly, which is a zip/jar
> > containing a jbi descriptor (META-INF/jbi.xml) describing the service
> > units to deploy, and the service unit artifacts. Each service unit
> > artifact is a zip/jar that will be exploded and given to the target
> > component. The contents of a service unit is specific to the target
> > component. servicemix-http supports a single xbean.xml file. It
> > means that you will have something like that:
> > sa.zip
> > |-> META-INF/jbi.xml
> > \-> su.zip
> > \-> xbean.xml
> > The main benefit is that:
> > * this is the specified way of using JBI
> > * some components may only handle JBI deployments
> > * such service assemblies can be deployed / undeployed at runtime
> >
> > You may choose the way you want. The servicemix.xml configuration
> > file is really usefull when developping / debugging or when you want
> > to embed servicemix in another application (a web app or anything
> > else).
>
>
Re: servicemix.xml and servicemix-http vs. old SM http component
Posted by Peter Klotz <pe...@blue-elephant-systems.com>.
Hi Guillaume,
Thanks for your answer, the JBI-compliant mode is what I'm looking for but apart
from the JBI spec it is hard to find docu. I need dynamic deploy/undeploy
start/stop.
servicemix-jsr181 and servicemix-http would be configured with a xbean.xml and
if one uses the SU servicemix-lwcontainer (as in the loan-broker example) one
can specify a servicemix.xml configuration file.
As an example let's say I have an "adaptor" to a certain backend system that
consists of multiple Spring-components/beans and one JBI-component that inherits
from ComponentSupport and consumes a MessageExchange.
This would be a service unit?
Because I have inherited from ComponentSupport I would need a lwcontainer?
One could also inherit from BaseComponent then one would have a real JBI
component but that would be more effort to implement.
A service assembly would then be a set of our own SUs (aka adaptors), some BU
like servicemix-http and serviceix-soap and a SU that e.g. contains a router to
distribute requests comming from the http endpoint to the adaptor SUs?
Is it a good idea to have multiple servicemix-lwcontainer running one in each SU?
Peter
Guillaume Nodet wrote:
>
> The other way is to use what the JBI spec explains: install a
> component, then deploy a service unit / service assembly onto it.
> The deployable artifact is the service assembly, which is a zip/jar
> containing a jbi descriptor (META-INF/jbi.xml) describing the service
> units to deploy, and the service unit artifacts. Each service unit
> artifact is a zip/jar that will be exploded and given to the target
> component. The contents of a service unit is specific to the target
> component. servicemix-http supports a single xbean.xml file. It
> means that you will have something like that:
> sa.zip
> |-> META-INF/jbi.xml
> \-> su.zip
> \-> xbean.xml
> The main benefit is that:
> * this is the specified way of using JBI
> * some components may only handle JBI deployments
> * such service assemblies can be deployed / undeployed at runtime
>
> You may choose the way you want. The servicemix.xml configuration
> file is really usefull when developping / debugging or when you want
> to embed servicemix in another application (a web app or anything
> else).
Re: servicemix.xml and servicemix-http vs. old SM http component
Posted by Guillaume Nodet <gn...@gmail.com>.
Peter,
You're right, we need to write some doc about that.
To understand how standard JBI deployment work, take a look at the
soap-binding demo which generate a service unit and a service assembly
to deploy a pojo and an http endpoint.
Also, you might want to read the jbi spec to undestand the mechanism
of installation and deployment (until we write the doc ;) )
Basically, you may choose to use the "lightweight" configuration,
which is suitable when you want to user ServiceMix in a static
configuration. The downside is that you can not change it at runtime
(you have to update your servicemix.xml configuration file and restart
the ServiceMix). In addition, external components (such as PXE) can
not be configured that way. Last point, this is a feature specific to
ServiceMix and not JBI compliant. When you use the servicemix.xml
configuration file, you do not have to "install" the components and/or
deploy service units/service assemblies.
The other way is to use what the JBI spec explains: install a
component, then deploy a service unit / service assembly onto it.
The deployable artifact is the service assembly, which is a zip/jar
containing a jbi descriptor (META-INF/jbi.xml) describing the service
units to deploy, and the service unit artifacts. Each service unit
artifact is a zip/jar that will be exploded and given to the target
component. The contents of a service unit is specific to the target
component. servicemix-http supports a single xbean.xml file. It
means that you will have something like that:
sa.zip
|-> META-INF/jbi.xml
\-> su.zip
\-> xbean.xml
The main benefit is that:
* this is the specified way of using JBI
* some components may only handle JBI deployments
* such service assemblies can be deployed / undeployed at runtime
You may choose the way you want. The servicemix.xml configuration
file is really usefull when developping / debugging or when you want
to embed servicemix in another application (a web app or anything
else).
Hope this helps,
Guillaume Nodet
On 4/3/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
> Hi Guillaume,
>
> well, I see the warning in the new page, although, why did I deploy
> servicemix-http then?
>
> > Classpath issues when embedding servicemix-http component
> >
> > When using the servicemix.xml configuration file to create http endpoints, you must include the servicemix-http-xxx.jar in your classpath.
> > You will find this file inside the component installer (./components/servicemix-http-xxx.zip).
> > Failing this, an IllegalArgumentException will be thrown with the following message:
> > Component name: xxxxxx is bound to an object which is not a JBI component, it is of type: javax.xml.namespace.QName
>
> I think my problem is more in the different ways to do the deployment and how to
> practically do this really. Normally I would have a servicemix.xml and call
> servicemix with this, this seems to be called "lightweight deployment"
>
> When I put servicemix-http.zip into the deploy directory it gets deployed but it
> is the mere component there is no component instantiated yet that waits on a
> port or does anything because there is no servicemix.xml, WSDL or xbean.xml
> specified yet, right?
>
> Let's start with the xbean.xml, what and HOW do I use it, how exactly do I
> deploy something with a xbean.xml, it is nowhere explained, sorry. xbean.xml is
> a Spring XML configuration file just like servicemix.xml, so what is the
> difference?
>
> I can use a servicemix.xml like
>
> # bin/servicemix examples/test/servicemix.xml
>
> but I cannot do the same with a xbean.xml.
>
> And most important what are the advantages or disadvantages of either method of
> deployment? What I want is the functionality to use the JBI Ant tasks (no idea
> how to use these yet as there are no examples) to dynamically deploy/undeploy
> start/stop components and using the SU/SA concepts. So my assumption is that the
> servicemix.xml method doesn't do this but instead I have to use xbean.xml or ???
>
> I think a overview page on deployment would help, now only me.
>
>
> Peter
>
> Guillaume Nodet wrote:
> > See the warning in the
> > http://servicemix.org/servicemix-http?refresh=1#servicemix-http-Lightweightmode
> > page that i have just created to answer this question.
>
>
Re: servicemix.xml and servicemix-http vs. old SM http component
Posted by Peter Klotz <pe...@blue-elephant-systems.com>.
Hi Guillaume,
well, I see the warning in the new page, although, why did I deploy
servicemix-http then?
> Classpath issues when embedding servicemix-http component
>
> When using the servicemix.xml configuration file to create http endpoints, you must include the servicemix-http-xxx.jar in your classpath.
> You will find this file inside the component installer (./components/servicemix-http-xxx.zip).
> Failing this, an IllegalArgumentException will be thrown with the following message:
> Component name: xxxxxx is bound to an object which is not a JBI component, it is of type: javax.xml.namespace.QName
I think my problem is more in the different ways to do the deployment and how to
practically do this really. Normally I would have a servicemix.xml and call
servicemix with this, this seems to be called "lightweight deployment"
When I put servicemix-http.zip into the deploy directory it gets deployed but it
is the mere component there is no component instantiated yet that waits on a
port or does anything because there is no servicemix.xml, WSDL or xbean.xml
specified yet, right?
Let's start with the xbean.xml, what and HOW do I use it, how exactly do I
deploy something with a xbean.xml, it is nowhere explained, sorry. xbean.xml is
a Spring XML configuration file just like servicemix.xml, so what is the
difference?
I can use a servicemix.xml like
# bin/servicemix examples/test/servicemix.xml
but I cannot do the same with a xbean.xml.
And most important what are the advantages or disadvantages of either method of
deployment? What I want is the functionality to use the JBI Ant tasks (no idea
how to use these yet as there are no examples) to dynamically deploy/undeploy
start/stop components and using the SU/SA concepts. So my assumption is that the
servicemix.xml method doesn't do this but instead I have to use xbean.xml or ???
I think a overview page on deployment would help, now only me.
Peter
Guillaume Nodet wrote:
> See the warning in the
> http://servicemix.org/servicemix-http?refresh=1#servicemix-http-Lightweightmode
> page that i have just created to answer this question.
Re: servicemix.xml and servicemix-http vs. old SM http component
Posted by Guillaume Nodet <gn...@gmail.com>.
See the warning in the
http://servicemix.org/servicemix-http?refresh=1#servicemix-http-Lightweightmode
page that i have just created to answer this question.
Cheers,
Guillaume Nodet
On 4/3/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
> Hi,
>
> I've derived from the
> servicemix-3.0-SNAPSHOT/servicemix-http/src/test/resources/org/apache/servicemix/http/spring.xml
> example this servicemix.xml and try to run it.
> Through commenting parts out I could prove that something must be wrong with the
> part <http:component>. The exception I get is attached below.
> servicemix-http and servicemix-lwcontainer is deployed in servicemix
>
> In some postings I saw <sm:serviceunit id="jbi">
> when can/must one use this?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns:sm="http://servicemix.apache.org/config/1.0"
> xmlns:http="http://servicemix.apache.org/http/1.0"
> xmlns:test="http://test">
>
> <!-- the JBI container -->
> <sm:container id="jbi"
> rootDir="./wdir"
> MBeanServer="#mbeanServer"
> installationDirPath="./install"
> deploymentDirPath="./deploy"
> dumpStats="true"
> statsInterval="10"
> flowName="seda">
>
> <sm:activationSpecs>
>
> <!-- output using a POJO -->
> <sm:activationSpec service="test:httpConnector" endpoint="httpConnector">
> <sm:component>
> <http:component>
> <http:endpoints>
> <http:endpoint service="test:MyConsumerService" endpoint="myConsumer"
> role="consumer"
> locationURI="http://localhost:8192/Service/"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"/>
> </http:endpoints>
> </http:component>
> </sm:component>
> </sm:activationSpec>
>
> <sm:activationSpec service="test:MyConsumerService" endpoint="myConsumer">
> <sm:component>
> <bean class="org.apache.servicemix.components.util.EchoComponent"/>
> </sm:component>
> </sm:activationSpec>
>
> </sm:activationSpecs>
> </sm:container>
>
> ...
>
>
> INFO - JBIContainer.init(508) | ServiceMix JBI Container
> (http://servicemix.org/) name: ServiceMix running version: 3.0-SNAPSHOT
> Caught: org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'jbi' defined in file
> [/home/pak/sandbox/servicemix-3.0-SNAPSHOT/examples/test/servicemix.xml]:
> Initialization of bean failed; nested exception is
> java.lang.IllegalArgumentException: Component name:
> ID:sequoia-32971-1144075447193-0:0 is bound to an object which is not a JBI
> component, it is of type: javax.xml.namespace.QName
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'jbi' defined in file
> [/home/pak/sandbox/servicemix-3.0-SNAPSHOT/examples/test/servicemix.xml]:
> Initialization of bean failed; nested exception is
> java.lang.IllegalArgumentException: Component name:
> ID:sequoia-32971-1144075447193-0:0 is bound to an object which is not a JBI
> component, it is of type: javax.xml.namespace.QName
> java.lang.IllegalArgumentException: Component name:
> ID:sequoia-32971-1144075447193-0:0 is bound to an object which is not a JBI
> component, it is of type: javax.xml.namespace.QName
> at
> org.apache.servicemix.jbi.container.JBIContainer.activateComponent(JBIContainer.java:885)
> at
> org.apache.servicemix.jbi.container.SpringJBIContainer.afterPropertiesSet(SpringJBIContainer.java:67)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:363)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
> at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
> at
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:320)
> at
> org.apache.xbean.spring.context.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:149)
> at
> org.apache.xbean.spring.context.FileSystemXmlApplicationContext.<init>(FileSystemXmlApplicationContext.java:48)
> at org.apache.servicemix.Main.main(Main.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchStandard(Launcher.java:410)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:344)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:461)
>
>
> It works if I replace the http:component by the old SM component
>
> <sm:activationSpec componentName="httpReceiver"
> service="foo:httpBinding"
> endpoint="httpReceiver"
> destinationService="test:MyConsumerService">
> <sm:component>
> <bean class="org.apache.servicemix.components.http.HttpConnector">
> <property name="host" value="localhost"/>
> <property name="port" value="8912"/>
> </bean>
> </sm:component>
> </sm:activationSpec>
>
> Now the question is how do I use the new servicemix-http?
>
> Peter
>
>