RE: [equinox-dev] policy=dynamic in Declarative Services.
HI Sameera,
I think Equinox' behavior is correct here. If you have a mandatory
service reference that is not valid anymore, the referring component has
to be deactivated even if the policy is dynamic.
But my requirement is that the service should be registered before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of components.
This is the default unless you declare the component itself immediate.
The meaning is: Unless no one wants to use your service, the component
(the implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should be registered before the component is activated. in that case I
have to put cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute in
the reference element, the component is deactivated once the
bound service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true
name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated
*** );
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated
*** );
}
protected void setRegistryService(RegistryService
registryService) {
System.out.println(Set Registry
Service);
}
protected void unsetRegistryService(RegistryService
registryService) {
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService,
following out put
is generated.
*** Carbon Core bundle is deactivated ***
{org.wso2.carbon.core.internal.CarbonCoreDSComponent}
Unset Registry Service
This mean carbon.core bundle is deactivated right?
Expected behavior: When the RegisterService is unregisterd,
only the unbind
method should be called. But here first the bundle is
deactivated and then
the unbind method is called.
Any solution would be greatly appreciated.
Thanks
--
Sameera Jayasoma
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
=
| BlueDavy |
| OSGi China User Group Director|
| http://china.osgiusers.org |
| http://blog.bluedavy.cn |
=
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Sameera Jayasoma
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
Re: [equinox-dev] policy=dynamic in Declarative Services.
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated ***
);
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated
*** );
}
protected void setRegistryService(RegistryService
registryService) {
System.out.println(Set Registry
Service);
}
protected void unsetRegistryService(RegistryService
registryService)
{
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService,
following out
put
is generated.
*** Carbon Core bundle is deactivated ***
{org.wso2.carbon.core.internal.CarbonCoreDSComponent}
Unset Registry Service
This mean carbon.core bundle is deactivated right?
Expected behavior: When the RegisterService is unregisterd, only
the
unbind
method should be called. But here first the bundle is deactivated
and
then
the unbind method is called.
Any solution would be greatly appreciated.
Thanks
--
Sameera Jayasoma
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
=
| BlueDavy |
| OSGi China User Group Director|
| http://china.osgiusers.org
Re: [equinox-dev] policy=dynamic in Declarative Services.
You cannot directly do this, because mandatory reference is mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory service
reference that is not valid anymore, the referring component has to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory when the
component is activated. Once the component is activated, the service is a
optional one. That mean I don't want my component to be de-activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of components.
This is the default unless you declare the component itself “immediate”. The
meaning is: Unless no one wants to use your service, the component (the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service should
be registered before the component is activated. in that case I have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy attribute
in
the reference element, the component is deactivated once the bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated *** );
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated *** );
}
protected void setRegistryService(RegistryService registryService) {
System.out.println(Set Registry Service);
}
protected void unsetRegistryService(RegistryService registryService)
{
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService, following out
put
is generated.
*** Carbon Core bundle is deactivated ***
{org.wso2.carbon.core.internal.CarbonCoreDSComponent}
Unset Registry Service
This mean carbon.core bundle is deactivated right?
Expected behavior: When the RegisterService is unregisterd, only the
unbind
method should be called. But here first the bundle is deactivated and
then
the unbind method is called.
Any solution would be greatly appreciated.
Thanks
--
Sameera Jayasoma
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
=
| BlueDavy |
| OSGi China User Group Director |
| http://china.osgiusers.org |
| http://blog.bluedavy.cn |
=
RE: [equinox-dev] policy=dynamic in Declarative Services.
@Hal, but DM will always create the service component eagerly since it
does not support lazy instantiation, right?
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Hal Hildebrand
Sent: Montag, 4. Mai 2009 16:53
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Well, Spring/DM will still work. The issue will be when he tries to
actually send a message to the service, in which case it will throw a
runtime exception.
On May 4, 2009, at 7:31 AM, BJ Hargrave wrote:
This does not sound like a flicker problem. DS can handle that also
for a dynamic 1..1 reference. The new service would be passed to bind
before the old service is passed to unbind. So the component is never
without a dependent service.
I think the issue here is that there is no replacement service available
and, with a 1..1 cardinality, the component is deactivated.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance http://www.osgi.org/
hargr...@us.ibm.com mailto:hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Hal Hildebrand hal.hildebr...@oracle.com
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2009/05/04 10:24
Subject:
Re: [equinox-dev] policy=dynamic in Declarative Services.
Sent by:
equinox-dev-boun...@eclipse.org
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai
kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox' behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
immediate. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org
mailto:equinox-dev-boun...@eclipse.org ] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0
http://www.osgi.org/xmlns/scr/v1.0.0
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private
Re: [equinox-dev] policy=dynamic in Declarative Services.
Well, Spring/DM will still work. The issue will be when he tries to
actually send a message to the service, in which case it will throw a
runtime exception.
On May 4, 2009, at 7:31 AM, BJ Hargrave wrote:
This does not sound like a flicker problem. DS can handle that
also for a dynamic 1..1 reference. The new service would be passed
to bind before the old service is passed to unbind. So the component
is never without a dependent service.
I think the issue here is that there is no replacement service
available and, with a 1..1 cardinality, the component is deactivated.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Hal Hildebrand hal.hildebr...@oracle.com
To: Equinox development mailing list equinox-dev@eclipse.org
Date: 2009/05/04 10:24
Subject:Re: [equinox-dev] policy=dynamic in Declarative Services.
Sent by:equinox-dev-boun...@eclipse.org
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is
mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative
Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the
bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated ***
);
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated
*** );
}
protected void setRegistryService(RegistryService
registryService) {
System.out.println(Set Registry
Service);
}
protected void unsetRegistryService(RegistryService
registryService)
{
Re: [equinox-dev] policy=dynamic in Declarative Services.
Yes, I see the point. He wants the service to become available before
the dependency arrives.
Sry for the confusion.
On May 4, 2009, at 7:55 AM, Toedter, Kai wrote:
@Hal, but DM will always create the service component eagerly since
it does not support lazy instantiation, right?
Kai
From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org
] On Behalf Of Hal Hildebrand
Sent: Montag, 4. Mai 2009 16:53
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Well, Spring/DM will still work. The issue will be when he tries to
actually send a message to the service, in which case it will throw
a runtime exception.
On May 4, 2009, at 7:31 AM, BJ Hargrave wrote:
This does not sound like a flicker problem. DS can handle that
also for a dynamic 1..1 reference. The new service would be passed
to bind before the old service is passed to unbind. So the component
is never without a dependent service.
I think the issue here is that there is no replacement service
available and, with a 1..1 cardinality, the component is deactivated.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Hal Hildebrand hal.hildebr...@oracle.com
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2009/05/04 10:24
Subject:
Re: [equinox-dev] policy=dynamic in Declarative Services.
Sent by:
equinox-dev-boun...@eclipse.org
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is
mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative
Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the
bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected
Re: [equinox-dev] policy=dynamic in Declarative Services.
From equinox realization,I think no way to do this.
Because equinox use reference policy cardinality interface etc. to
decide the component satisfication condition,if component become
unsatisfied,then equinox ds will dispose the component instance,and if
component become satisfied,equinox ds will create the component
instance,so If you want to use service with cardinality=1..1,you
must accept when the bound service is go away,the component instance
be disposed.
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory service
reference that is not valid anymore, the referring component has to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory when the
component is activated. Once the component is activated, the service is a
optional one. That mean I don't want my component to be de-activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of components.
This is the default unless you declare the component itself “immediate”. The
meaning is: Unless no one wants to use your service, the component (the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service should
be registered before the component is activated. in that case I have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy attribute
in
the reference element, the component is deactivated once the bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated *** );
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated *** );
}
protected void setRegistryService(RegistryService registryService) {
System.out.println(Set Registry Service);
}
protected void unsetRegistryService(RegistryService registryService)
{
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService, following out
put
is generated.
*** Carbon Core bundle is deactivated ***
{org.wso2.carbon.core.internal.CarbonCoreDSComponent}
Unset Registry Service
This mean carbon.core bundle is deactivated right?
Expected behavior: When the RegisterService is unregisterd, only the
unbind
method should be called. But here first the bundle is deactivated and
then
the unbind method is called.
Any solution would be greatly appreciated.
Thanks
--
Sameera Jayasoma
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
=
| BlueDavy |
| OSGi China User Group Director |
| http://china.osgiusers.org |
| http://blog.bluedavy.cn |
Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.comwrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory service
reference that is not valid anymore, the referring component has to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory when the
component is activated. Once the component is activated, the service is a
optional one. That mean I don't want my component to be de-activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of components. This
is the default unless you declare the component itself “immediate”. The
meaning is: Unless no one wants to use your service, the component (the
implementing Java class) will not be instantiated.
Best regards,
Kai
*From:* equinox-dev-boun...@eclipse.org [mailto:
equinox-dev-boun...@eclipse.org] *On Behalf Of *Sameera Jayasoma
*Sent:* Montag, 4. Mai 2009 04:59
*To:* Equinox development mailing list
*Subject:* Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service should
be registered before the component is activated. in that case I have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy attribute in
the reference element, the component is deactivated once the bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated *** );
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated *** );
}
protected void setRegistryService(RegistryService registryService) {
System.out.println(Set Registry Service);
}
protected void unsetRegistryService(RegistryService registryService)
{
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService, following out
put
is generated.
*** Carbon Core bundle is deactivated ***
{org.wso2.carbon.core.internal.CarbonCoreDSComponent}
Unset Registry Service
This mean carbon.core bundle is deactivated right?
Expected behavior: When the RegisterService is unregisterd, only the
unbind
method should be called. But here first the bundle is deactivated and
then
the unbind method is called.
Any solution would be greatly appreciated.
Thanks
--
Sameera Jayasoma
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
=
| BlueDavy |
| OSGi China User Group Director|
| http://china.osgiusers.org |
| http://blog.bluedavy.cn |
=
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Sameera Jayasoma
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Sameera Jayasoma
Software Engineer
WSO2 Inc.
Re: [equinox-dev] policy=dynamic in Declarative Services.
This does not sound like a flicker problem. DS can handle that also for
a dynamic 1..1 reference. The new service would be passed to bind before
the old service is passed to unbind. So the component is never without a
dependent service.
I think the issue here is that there is no replacement service available
and, with a 1..1 cardinality, the component is deactivated.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Hal Hildebrand hal.hildebr...@oracle.com
To:
Equinox development mailing list equinox-dev@eclipse.org
Date:
2009/05/04 10:24
Subject:
Re: [equinox-dev] policy=dynamic in Declarative Services.
Sent by:
equinox-dev-boun...@eclipse.org
There's also Spring/DM, which does I think what you want - i.e. 1..1
cardinality, but not dropping the service is its dependencies
momentarily flicker.
On May 4, 2009, at 6:53 AM, Neil Bartlett wrote:
You cannot directly do this, because mandatory reference is mandatory
at all times. However, you could make the reference optional and
perform some kind of internal activation/deactivation in the
bind/unbind methods.
However, if that still doesn't work for you then you're trying to do
something outside the scope of use-cases supported by DS, so you
should drop down to the ServiceTracker API.
Regards,
Neil
On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma
sameera.madus...@gmail.com wrote:
Hi Kai,
On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com
wrote:
HI Sameera,
I think Equinox’ behavior is correct here. If you have a mandatory
service
reference that is not valid anymore, the referring component has
to be
deactivated even if the policy is dynamic.
I agree with your point. Now say that the service is mandatory
when the
component is activated. Once the component is activated, the
service is a
optional one. That mean I don't want my component to be de-
activated when
the service is unregistered. How can I handle this situation with
declarative services?
Thanks
Sameera
But my requirement is that the service should be registered
before the
component is activated.
in that case I have to put cardinality as 1..1 right?
I guess your question is related to the lazy activation of
components.
This is the default unless you declare the component itself
“immediate”. The
meaning is: Unless no one wants to use your service, the component
(the
implementing Java class) will not be instantiated.
Best regards,
Kai
From: equinox-dev-boun...@eclipse.org
[mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Sameera
Jayasoma
Sent: Montag, 4. Mai 2009 04:59
To: Equinox development mailing list
Subject: Re: [equinox-dev] policy=dynamic in Declarative Services.
Hi,
On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com
wrote:
if u want to the component isn't deactivated,u should set the bound
service cardinality to 0..1
Thanks for the quick reply. But my requirement is that the service
should
be registered before the component is activated. in that case I
have to put
cardinality as 1..1 right?
Thanks
Sameera
2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com:
Hi devs,
Even though I have used the value dynamic for the policy
attribute
in
the reference element, the component is deactivated once the
bound
service
is unregistered. Here is the component.xml I am using.
components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0;
scr:component enabled=true name=carbon.core.dscomponent
implementation
class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/
property name=service.pid
value=carbon.core.dscomponent/
reference name=registry.service
interface=org.wso2.carbon.registry.core.service.RegistryService
cardinality=1..1 policy=dynamic bind=setRegistryService
unbind=unsetRegistryService/
/scr:component
/components
Here is the component implementation class.
public class CarbonCoreDSComponent{
private static Log log =
LogFactory.getLog(CarbonCoreDSComponent.class);
private BundleContext bundleContext;
protected void activate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is activated ***
);
}
protected void deactivate(ComponentContext ctxt) {
log.info(*** Carbon Core bundle is deactivated
*** );
}
protected void setRegistryService(RegistryService
registryService) {
System.out.println(Set Registry
Service);
}
protected void unsetRegistryService(RegistryService
registryService)
{
System.out.println(Unset Registry
Service);
}
}
When I stop the bundle which registers the
org.wso2.carbon.registry.core.service.RegistryService,
following out
put
is generated.
*** Carbon Core bundle is
Re: [equinox-dev] policy=dynamic in Declarative Services.
Thanks guys for your feedback. I really understands the problem here now. Thanks Sameera On Mon, May 4, 2009 at 8:28 PM, Hal Hildebrand hal.hildebr...@oracle.comwrote: Yes, I see the point. He wants the service to become available before the dependency arrives. Sry for the confusion. On May 4, 2009, at 7:55 AM, Toedter, Kai wrote: @Hal, but DM will always create the service component eagerly since it does not support lazy instantiation, right? Kai *From:* equinox-dev-boun...@eclipse.org [ mailto:equinox-dev-boun...@eclipse.org equinox-dev-boun...@eclipse.org] *On Behalf Of *Hal Hildebrand *Sent:* Montag, 4. Mai 2009 16:53 *To:* Equinox development mailing list *Subject:* Re: [equinox-dev] policy=dynamic in Declarative Services. Well, Spring/DM will still work. The issue will be when he tries to actually send a message to the service, in which case it will throw a runtime exception. On May 4, 2009, at 7:31 AM, BJ Hargrave wrote: This does not sound like a flicker problem. DS can handle that also for a dynamic 1..1 reference. The new service would be passed to bind before the old service is passed to unbind. So the component is never without a dependent service. I think the issue here is that there is no replacement service available and, with a 1..1 cardinality, the component is deactivated. -- *BJ Hargrave* Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance http://www.osgi.org/* *hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: Hal Hildebrand hal.hildebr...@oracle.com To: Equinox development mailing list equinox-dev@eclipse.org Date: 2009/05/04 10:24 Subject: Re: [equinox-dev] policy=dynamic in Declarative Services. Sent by: equinox-dev-boun...@eclipse.org -- There's also Spring/DM, which does I think what you want - i.e. 1..1 cardinality, but not dropping the service is its dependencies momentarily flicker. On May 4, 2009, at 6:53 AM, Neil Bartlett wrote: You cannot directly do this, because mandatory reference is mandatory at all times. However, you could make the reference optional and perform some kind of internal activation/deactivation in the bind/unbind methods. However, if that still doesn't work for you then you're trying to do something outside the scope of use-cases supported by DS, so you should drop down to the ServiceTracker API. Regards, Neil On Mon, May 4, 2009 at 2:26 PM, Sameera Jayasoma sameera.madus...@gmail.com wrote: Hi Kai, On Mon, May 4, 2009 at 11:55 AM, Toedter, Kai kai.toed...@siemens.com wrote: HI Sameera, I think Equinox’ behavior is correct here. If you have a mandatory service reference that is not valid anymore, the referring component has to be deactivated even if the policy is dynamic. I agree with your point. Now say that the service is mandatory when the component is activated. Once the component is activated, the service is a optional one. That mean I don't want my component to be de- activated when the service is unregistered. How can I handle this situation with declarative services? Thanks Sameera But my requirement is that the service should be registered before the component is activated. in that case I have to put cardinality as 1..1 right? I guess your question is related to the lazy activation of components. This is the default unless you declare the component itself “immediate”. The meaning is: Unless no one wants to use your service, the component (the implementing Java class) will not be instantiated. Best regards, Kai From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.orgequinox-dev-boun...@eclipse.org] On Behalf Of Sameera Jayasoma Sent: Montag, 4. Mai 2009 04:59 To: Equinox development mailing list Subject: Re: [equinox-dev] policy=dynamic in Declarative Services. Hi, On Mon, May 4, 2009 at 8:23 AM, BlueDavy Lin blued...@gmail.com wrote: if u want to the component isn't deactivated,u should set the bound service cardinality to 0..1 Thanks for the quick reply. But my requirement is that the service should be registered before the component is activated. in that case I have to put cardinality as 1..1 right? Thanks Sameera 2009/5/4 Sameera Jayasoma sameera.madus...@gmail.com: Hi devs, Even though I have used the value dynamic for the policy attribute in the reference element, the component is deactivated once the bound service is unregistered. Here is the component.xml I am using. components xmlns:scr=http://www.osgi.org/xmlns/scr/v1.0.0; scr:component enabled=true name=carbon.core.dscomponent implementation class=org.wso2.carbon.core.internal.CarbonCoreDSComponent/ property name=service.pid value=carbon.core.dscomponent/ reference
[equinox-dev] Equinox tagged for Galileo integration build
The map file has been updated for the following Bug changes: + Bug 274156. Add x86_64 to osgi test bundles (FIXED) The following projects have changed: org.eclipse.osgi.tests Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
