Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: @Activation annotation not working when Bundle starts ?
Following snippets are a sample configuration interface and configuration reading class.
We read the above configuration in the Application class like below.
But in machine 2 the @Activate won't trigger when restarting the machine or even @Modified when the new value is added to the config. The following are the differences between machine 1 & 2
Machine 1 (working) : Liferay DXP fix pack 57, Tomcat 8.0.32, MySQL DB, Elasticsearch 2.2.2
Machine 2 (not working) : Liferay DXP fix pack 59, IBM Websphere, Oracle DB, Elasticsearch 2.2.4
In order to make machine 2 to read this osgi config after restart/modification we need to go to the App Manager and reactivate the bundle from there. Then it will trigger @Activate and the configuration value will pick up.
Why is @Activate method not triggering when the bundle (re)starts in Machine 2, or sometimes @Modified also not working when the configuration is changed ? Thanks in advance for your valuable answers. Please feel free to ask anymore info to better understand the scenario.
With Regards
[code]@Meta.OCD(id = "docs.exampleconfig.ExampleConfiguration")
public interface ExampleConfiguration {
@Meta.AD(
deflt = "0",
required =true
)
public Long authId();
}
We read the above configuration in the Application class like below.
[code]@Component(
configurationPid = "docs.exampleconfig.ExampleConfiguration",
configurationPolicy = ConfigurationPolicy.OPTIONAL,
immediate = true,
property = {
"javax.portlet.name=com_liferay_docs_exampleconfig_portlet_ExampleConfigPortlet"
},
service = ConfigurationAction.class
)
public class ExampleConfigurationAction extends DefaultConfigurationAction {
@Activate
@Modified
protected void activate(Map<object, object> properties) {
_exampleConfiguration = ConfigurableUtil.createConfigurable(
ExampleConfiguration.class, properties);
}
private volatile ExampleConfiguration _exampleConfiguration;
}
............</object,>
Everytime when we restart the liferay server in machine 1 the @Activate method triggers and the new configurations are picked up and works fine.But in machine 2 the @Activate won't trigger when restarting the machine or even @Modified when the new value is added to the config. The following are the differences between machine 1 & 2
Machine 1 (working) : Liferay DXP fix pack 57, Tomcat 8.0.32, MySQL DB, Elasticsearch 2.2.2
Machine 2 (not working) : Liferay DXP fix pack 59, IBM Websphere, Oracle DB, Elasticsearch 2.2.4
In order to make machine 2 to read this osgi config after restart/modification we need to go to the App Manager and reactivate the bundle from there. Then it will trigger @Activate and the configuration value will pick up.
Why is @Activate method not triggering when the bundle (re)starts in Machine 2, or sometimes @Modified also not working when the configuration is changed ? Thanks in advance for your valuable answers. Please feel free to ask anymore info to better understand the scenario.
With Regards
Why is @Activate method not triggering when the bundle (re)starts in Machine 2, or sometimes @Modified also not working when the configuration is changed?
The @Activate method is only called when a component activates, and a bundle can be started without the component starting. Chances are that your component has a dependency that isn't satisfied on Machine 2.
Minhchau DangWhy is @Activate method not triggering when the bundle (re)starts in Machine 2, or sometimes @Modified also not working when the configuration is changed?
The @Activate method is only called when a component activates, and a bundle can be started without the component starting. Chances are that your component has a dependency that isn't satisfied on Machine 2.
Thanks for the reply. I don't think it's any dependency issuse. It's not throwing any depedency error in the console as well as it works after re-actiavting the bundle from App Manager without adding any other dependencies. Both the enviroment have all same dependencies. I also tested it with the example shown in the liferay doc's and got the same issue in Machine 2
That doesn't mean much...
When you deploy, drop into gogo and list the bundles to find your bundle id.
Then do "scr:list NN" where NN is your bundle id, it lists all of the components. Verify that they are all active. For one(s) that are not, use "scr:info XXX" where XXX is the service id (will be shown when you use the scr:list command) and it will tell you why your component(s) are not started.
When you deploy, drop into gogo and list the bundles to find your bundle id.
Then do "scr:list NN" where NN is your bundle id, it lists all of the components. Verify that they are all active. For one(s) that are not, use "scr:info XXX" where XXX is the service id (will be shown when you use the scr:list command) and it will tell you why your component(s) are not started.
Thanks David, that was a very useful and new info. The component status says 'satisfied', but did'nt find any reason for not being active. The attached is the screenshot of the 'scr:info xxx' command.

Few more info regarding our scenario. We have 3 different configuration interfaces with unique Meta.OCD id. In order to read this configuration we have 3 differant reader classes, the @activate methods are there in each of them for the respective config interfaces. It came into my observation that only one of this configuration reader class component is 'active' in the gogo shell, other components says 'satisfied'. The 'satisfied' component becomes active only if we reactivae the project bundle from app manager (even redeploy doesn't make this components active). Two of our config interfaces and config reader classes are given below.
ex1; config interface and its reader class
ex 2: config interface and its reader class
Few more info regarding our scenario. We have 3 different configuration interfaces with unique Meta.OCD id. In order to read this configuration we have 3 differant reader classes, the @activate methods are there in each of them for the respective config interfaces. It came into my observation that only one of this configuration reader class component is 'active' in the gogo shell, other components says 'satisfied'. The 'satisfied' component becomes active only if we reactivae the project bundle from app manager (even redeploy doesn't make this components active). Two of our config interfaces and config reader classes are given below.
ex1; config interface and its reader class
@ExtendedObjectClassDefinition(category = "TH")
@Meta.OCD(name = "TH Search Config", id = "th.module.search.service.configs.SearchConfigs",
description = "Search Configurations", localization = "content/Language")
public interface SearchConfigs {
@Meta.AD(name = "Accordion Structure Id", required = true, deflt = "0")
public Long gid();
}
........
@Component(configurationPid = {"th.module.search.service.configs.SearchConfigs"},
immediate = true,
service = ReadSearchConfig.class)
public class ReadSearchConfig {
private volatile static SearchConfigs _configuration;
@Activate
@Modified
protected void activate(Map<string, object> properties) {
_configuration = ConfigurableUtil.createConfigurable(SearchConfigs.class, properties);
}
}</string,>
ex 2: config interface and its reader class
@ExtendedObjectClassDefinition(category = "TH")
@Meta.OCD(name = "TH Search Field Configs",
id = "th.module.search.service.configs.SearchFieldConfigs",
localization = "content/Language")
public interface SearchFieldConfigs {
@Meta.AD(name = "Description field name for accordion search results", required = false,
deflt = "ChildContent")
public String accordionDescriptionField();
}
........
@Component(configurationPid = {"th.module.search.service.configs.SearchFieldConfigs"},
immediate = true,
service = ReadSearchFieldConfig.class)
public class ReadSearchFieldConfig {
private volatile static SearchFieldConfigs _searchFieldConfiguration
@Activate
@Modified
protected void activate(Map<string, object> properties) {
_searchFieldConfiguration =
ConfigurableUtil.createConfigurable(SearchFieldConfigs.class, properties);
updatesearchmetadata();
}
}
</string,>
We have one more config and reader class like the above, one of them will be active and others will be 'satisfied' upon deployment. Always only one component gets active out of 'x' number of config interface reader components.
Are these all in the same bundle, or are they separate bundles using the same packages?
Are these all in the same bundle, or are they separate bundles using the same packages?
All these in the same bundle
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™