XBean configuration in servicemix.xml

[Peter Klotz <pe...@blue-elephant-systems.com>]

Hi,

it looks like some non-endpoint XBean configuration is politely ignored in a
xbean.xml that is deployed as a SU to servicemix-http. That is probably ok so,
the question is can one use XBean-configuration such as this jetty 6 bean

<jetty port="8080" webAppContext="/" webAppDirectory="webapps"/>

in a servicemix.xml that is deployed to servicemix-lwcontainer?
It doesn't seem so to me, it seems to be ignored completely, no error but no
bean either.

is there a workaround?


Peter

Re: XBean configuration in servicemix.xml

[Guillaume Nodet <gn...@gmail.com>]

One problem, is that xbean does not really complains if it finds a tag
that it can not understand.  Are you sure that the necesarry
informations are available in the classpath ?
Mainly the jetty-xbean jar.

Cheers,
Guillaume Nodet

On 4/10/06, Peter Klotz <pe...@blue-elephant-systems.com> wrote:
>
> In the following servicemix.xml sample, the jetty-bean seems to be ignored
> completely, at least there is not logging that would show that it gets
> instantiated nor is the port 8080 available nor an error.
>
> The <sm:serviceunit/> is currently obviously required including this dummy
> service, because otherwise servicemix fails with the message not endpoint
> defined. Is this behaviour absolutely necessary?
>
> ---
> <?xml version="1.0"?>
> <beans xmlns:sm="http://servicemix.apache.org/config/1.0"
>   xmlns:http="http://servicemix.apache.org/http/1.0"
>   xmlns:jetty="http://mortbay.com/schemas/jetty/1.0"
>   xmlns:bes="http://blue-elephant-systems.com/midas/servicemix/1.0">
>
>   <sm:serviceunit id="jbi">
>     <sm:activationSpecs>
>
>       <sm:activationSpec service="bes:dummy" endpoint="dummy">
>         <sm:component>
>           <bean class="org.apache.servicemix.components.util.EchoComponent"/>
>         </sm:component>
>       </sm:activationSpec>
>
>     </sm:activationSpecs>
>   </sm:serviceunit>
>
>   <jetty:jetty>
>     <jetty:connectors>
>       <jetty:nioConnector port="8080" />
>     </jetty:connectors>
>
>     <jetty:handlers>
>       <jetty:webAppContext contextPath="/" resourceBase="/tmp/webapps"
> parentLoaderPriority="false" />
>     </jetty:handlers>
>   </jetty:jetty>
> </beans>
> ---
>
> In this case I would like to skip the <sm:serviceunit/> completely to have only
> the jetty component. Obviously I'm using servicemix as a normal component
> container here not in its role as ESB. But why not, better than having two
> containers and two deployment mechanisms etc.
>
> Peter
>
>

Re: XBean configuration in servicemix.xml

[Peter Klotz <pe...@blue-elephant-systems.com>]

In the following servicemix.xml sample, the jetty-bean seems to be ignored
completely, at least there is not logging that would show that it gets
instantiated nor is the port 8080 available nor an error.

The <sm:serviceunit/> is currently obviously required including this dummy
service, because otherwise servicemix fails with the message not endpoint
defined. Is this behaviour absolutely necessary?

---
<?xml version="1.0"?>
<beans xmlns:sm="http://servicemix.apache.org/config/1.0"
  xmlns:http="http://servicemix.apache.org/http/1.0"
  xmlns:jetty="http://mortbay.com/schemas/jetty/1.0"
  xmlns:bes="http://blue-elephant-systems.com/midas/servicemix/1.0">

  <sm:serviceunit id="jbi">
    <sm:activationSpecs>

      <sm:activationSpec service="bes:dummy" endpoint="dummy">
        <sm:component>
          <bean class="org.apache.servicemix.components.util.EchoComponent"/>
        </sm:component>
      </sm:activationSpec>

    </sm:activationSpecs>
  </sm:serviceunit>

  <jetty:jetty>
    <jetty:connectors>
      <jetty:nioConnector port="8080" />
    </jetty:connectors>

    <jetty:handlers>
      <jetty:webAppContext contextPath="/" resourceBase="/tmp/webapps"
parentLoaderPriority="false" />
    </jetty:handlers>
  </jetty:jetty>
</beans>
---

In this case I would like to skip the <sm:serviceunit/> completely to have only
the jetty component. Obviously I'm using servicemix as a normal component
container here not in its role as ESB. But why not, better than having two
containers and two deployment mechanisms etc.

Peter