Service registration and service consumption cannot be defined in the same blueprint bundle?

[Forrest Xia <fo...@gmail.com>]

Hi blueprint experts,

Can I make a blueprint definition like this?

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

    <bean id="serverbean1"

class="org.apache.aries.samples.blueprint.complex.server.ServerBean1"
        init-method="doSomething">
        <argument value="ServerBean1's Name"></argument>
    </bean>

    <service ref="serverbean1"

interface="org.apache.aries.samples.blueprint.complex.api.ServiceInterface1"/>

    <reference id="serviceref1"

interface="org.apache.aries.samples.blueprint.complex.api.ServiceInterface1"/>

    <bean id="callservicebean"
            class="org.apache.aries.samples.blueprint.complex.Bean6"
            init-method="startUp">
            <argument ref="serviceref1"/>
    </bean>
</blueprint>

ServerBean1 and Bean6 are in the same blueprint bundle. I find this bundle
cannot be started, the blueprint state shows failure.

Any comments?

Thanks!
Forrest

Re: Service registration and service consumption cannot be defined in the same blueprint bundle?

[Forrest Xia <fo...@gmail.com>]

Thank you, got it!

Forrest

Re: Service registration and service consumption cannot be defined in the same blueprint bundle?

[Valentin Mahrwald <vm...@googlemail.com>]

Blueprint supports two kinds of dependencies, implicit, which  
dependencies that come from injecting A into B (such as via a  
property, constructor arg or a ref on service definition etc), and  
explicit, which are defined by the "depends-on" attribute. Dependent  
beans are constructed after their dependencies. However, for beans  
that are not dependent on one another either way, blueprint gives no  
guarantee of any specific ordering.

So if you wanted a specific ordering you can most easily achieve that  
by specifying the "depends-on" attribute for each of your beans.  
Although of course that is not quite best practice ;)

For reference see 121.2.4 of the spec.

Regards,

Valentin


On 16 Dec 2009, at 00:52, Forrest Xia wrote:

> Hi Valentin,
>
> Thank you for quick response. Now I understood it.
>
> By default, the service reference resolution is mandatory, so this
> implicitly means service registration and consumption is better not  
> in the
> same bundle.
>
> I see callservicebean can use the serverbean1 directly, just I want to
> practice the service and service reference concepts :-)
>
> btw, another question comes out when I am doing practice. Is there any
> attribute or element to tell bluerprint extender the order of bean
> initialization? If there are many beans defined in the same bundle,  
> what
> order will they be initialized?
>
> Forrest

Re: Service registration and service consumption cannot be defined in the same blueprint bundle?

[Forrest Xia <fo...@gmail.com>]

Hi Valentin,

Thank you for quick response. Now I understood it.

By default, the service reference resolution is mandatory, so this
implicitly means service registration and consumption is better not in the
same bundle.

I see callservicebean can use the serverbean1 directly, just I want to
practice the service and service reference concepts :-)

btw, another question comes out when I am doing practice. Is there any
attribute or element to tell bluerprint extender the order of bean
initialization? If there are many beans defined in the same bundle, what
order will they be initialized?

Forrest

Re: Service registration and service consumption cannot be defined in the same blueprint bundle?

[Valentin Mahrwald <vm...@googlemail.com>]

Hi Forrest,

As far as I am aware (mandatory) service registrations cannot be used  
from inside the same blueprint. The reason for this is that the  
blueprint container waits for all (mandatory) service references to be  
satisfied before it starts creating components. See section 121.3.2.1  
for the details. So if serviceref1 is not satisfied by some other  
bundle it should never get satisfied since creating serverbean1 and  
exporting it as a service waits for serviceref1 to be satisfied.

If you really wanted to use a service, I suppose you could make the  
service reference availability=optional, but I can't see why you  
wouldn't just inject serverbean1 directly into callservicebean.

Regards,

Valentin

On 15 Dec 2009, at 14:16, Forrest Xia wrote:

> Hi blueprint experts,
>
> Can I make a blueprint definition like this?
>
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
>
>    <bean id="serverbean1"
>
> class="org.apache.aries.samples.blueprint.complex.server.ServerBean1"
>        init-method="doSomething">
>        <argument value="ServerBean1's Name"></argument>
>    </bean>
>
>    <service ref="serverbean1"
>
> interface 
> ="org.apache.aries.samples.blueprint.complex.api.ServiceInterface1"/>
>
>    <reference id="serviceref1"
>
> interface 
> ="org.apache.aries.samples.blueprint.complex.api.ServiceInterface1"/>
>
>    <bean id="callservicebean"
>            class="org.apache.aries.samples.blueprint.complex.Bean6"
>            init-method="startUp">
>            <argument ref="serviceref1"/>
>    </bean>
> </blueprint>
>
> ServerBean1 and Bean6 are in the same blueprint bundle. I find this  
> bundle
> cannot be started, the blueprint state shows failure.
>
> Any comments?
>
> Thanks!
> Forrest