Re: [Dev] Web app class loading issue

[Charitha Goonetilleke]

Hi all,

Thanks for the suggestions, I removed *json_3.0.0.wso2v1* from
org.wso2.carbon.device.mgt.iot.common and modified code to comply with
*json_2.0.0.wso2v1*. Since org.wso2.carbon.event.simulator.core not used
any specific classes only provided by *json_3.0.0.wso2v1*, I was able to
solve the issue with only above modification.

Thanks,
/charithag

On Mon, Oct 5, 2015 at 5:56 PM, Madusanka Premaratne 
wrote:

> Hi Charitha,
> As per our findings, multiple versions from same bundle does not cause
> this issue. Usually this happens due to multiple jars which exports same
> package / incorrectly designed orbit bundles. Please find out those and
> exclude those.
>
> In APIM we have removed some jars to resolve the issue. Please refer [1]
>
> [1] -
> https://github.com/wso2/product-apim/blob/1.10.x/modules/distribution/product/src/main/assembly/bin.xml#L66
>
> Thanks,
> Madusanka
>
> On Mon, Oct 5, 2015 at 2:17 PM, Charitha Goonetilleke 
> wrote:
>
>> Hi Manoj,
>>
>> Thanks for the response. Actually, we can't eliminate one bundle version
>> from above since, both of them have their own dependencies. Actually we
>> tried to do that by removing *json_3.0.0.wso2v1.* But without that
>> bundle, org.wso2.carbon.event.simulator.core and
>> org.wso2.carbon.device.mgt.iot.common bundles throwing class not founds.
>> BTW, I can change json version dependency for 
>> org.wso2.carbon.device.mgt.iot.common
>> bundle. But still we need to change version for  
>> org.wso2.carbon.event.simulator.core
>> in that scenario.
>>
>> Anyway I think it would be better if we cloud upgrade
>> v2.0.0 dependent bundles to v3.0.0. WDYT?
>>
>> On Mon, Oct 5, 2015 at 1:34 PM, Manoj Kumara  wrote:
>>
>>> Hi Charitha,
>>>
>>> The reason here is that you have packed two versions of the same bundle.
>>> Please check the features they get added and remove unnecessary one.
>>>
>>> Regards,
>>> Manoj
>>>
>>> *Manoj Kumara*
>>> WSO2 Inc. *| **lean. enterprise. middleware.*
>>> *Mobile:* +94 713 448188
>>>
>>> On Mon, Oct 5, 2015 at 12:46 PM, Charitha Goonetilleke <
>>> charit...@wso2.com> wrote:
>>>
 Hi All,

 In IoT server we have the same issue, which occurred to Geeth
 initially. Thanks to RuwanA's tool, I figured out the conflicting bundles.

 Packages
 org.json
   Exported By
 json_2.0.0.wso2v1.jar at the location
 /repository/components/plugins/json_2.0.0.wso2v1.jar
 json_3.0.0.wso2v1.jar at the location
 /repository/components/plugins/json_3.0.0.wso2v1.jar

 When issue is occurred, tomcat imports org.json from
 json_3.0.0.wso2v1.jar as follows:

 osgi> p org.json
 org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
   oltu_1.0.0.wso2v2 [123] imports
   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
   org.wso2.carbon.registry.core_4.4.1 [534] imports
   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
 org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
   *tomcat_7.0.59.wso2v3* [692] imports

 If issue doesn't appear, tomcat imports org.json from json_2.0.0.wso2v1
 as follows:

 osgi> p org.json
 org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
   oltu_1.0.0.wso2v2 [123] imports
   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
   org.wso2.carbon.registry.core_4.4.1 [534] imports
   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
   *tomcat_7.0.59.wso2v3* [692] imports
 org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports

 Is there any known workaround to fix this issue?


 On Wed, Aug 5, 2015 at 8:10 PM, Ruwan Abeykoon  wrote:

> Hi Madushanka,
> You can exclude the duplicate (unwanted) jar being bundled by your
> assembly bin.xml (or relevant file) in "maven-assembly-plugin"
>
> 

Re: [Dev] Web app class loading issue

[Charitha Goonetilleke]

Hi All,

In IoT server we have the same issue, which occurred to Geeth initially.
Thanks to RuwanA's tool, I figured out the conflicting bundles.

Packages
org.json
  Exported By
json_2.0.0.wso2v1.jar at the location
/repository/components/plugins/json_2.0.0.wso2v1.jar
json_3.0.0.wso2v1.jar at the location
/repository/components/plugins/json_3.0.0.wso2v1.jar

When issue is occurred, tomcat imports org.json from json_3.0.0.wso2v1.jar
as follows:

osgi> p org.json
org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
  oltu_1.0.0.wso2v2 [123] imports
  org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
  org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
  org.wso2.carbon.databridge.commons_4.4.7 [299] imports
  org.wso2.carbon.databridge.commons_5.0.2 [300] imports
  org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
  org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
  org.wso2.carbon.registry.core_4.4.1 [534] imports
  org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
  org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
  org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
  org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
  *tomcat_7.0.59.wso2v3* [692] imports

If issue doesn't appear, tomcat imports org.json from json_2.0.0.wso2v1 as
follows:

osgi> p org.json
org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
  oltu_1.0.0.wso2v2 [123] imports
  org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
  org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
  org.wso2.carbon.databridge.commons_4.4.7 [299] imports
  org.wso2.carbon.databridge.commons_5.0.2 [300] imports
  org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
  org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
  org.wso2.carbon.registry.core_4.4.1 [534] imports
  org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
  org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
  *tomcat_7.0.59.wso2v3* [692] imports
org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
  org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
  org.wso2.carbon.event.simulator.core_2.0.5 [383] imports

Is there any known workaround to fix this issue?


On Wed, Aug 5, 2015 at 8:10 PM, Ruwan Abeykoon  wrote:

> Hi Madushanka,
> You can exclude the duplicate (unwanted) jar being bundled by your
> assembly bin.xml (or relevant file) in "maven-assembly-plugin"
>
> You can add whatever the bundle to be excluded in the list,
> XPATH : /assembly/fileSets/fileSet/excludes/exclude[]
>
> This is a quick fix until each carbon based feature agree on using same
> bundle versions for a given base carbon kernel version.
>
> Cheers,
> Ruwan
>
> On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne 
> wrote:
>
>> Hi all,
>> As in the conversation I understood that the issue happens due to
>> multiple exports of same package. I face the same scenario in APIM 1.10.0
>> (1.9.0 upgration to carbon 4.4.0).
>> I checked the APIM related ones and could not find any wrong export.
>>
>> I can see some of the packages like *net.minidev.json, *
>> *com.nimbusds.jwt*
>>  are duplicated with multiple versions.
>>
>> And
>> *com.jayway.jsonpath *exported as follows.
>>
>> osgi> p com.jayway.jsonpath
>> com.jayway.jsonpath; version="0.8.1"> [22]>
>>   synapse-core_2.1.3.wso2v5 [488] imports
>>   tomcat_7.0.59.wso2v1 [494] imports
>>
>> Can someone guide me to remove the unwanted ones?
>> Thanks in advance for your responses.
>>
>> Madusanka
>>
>> On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma 
>> wrote:
>>
>>> Hello Geeth,
>>>
>>> We've encountered many similar issues in the past. The main cause of
>>> these issues is the existence of multiple versions of some packages. OSGi
>>> is designed to support this scenario. But in some cases, OSGi resolution
>>> algorithm fails wire dynamical imported packages due multiple versions of
>>> some packages. This is indeed a wired observation.
>>>
>>> We've removed some duplicated bundles in CDM pack (e.g. httpclient,
>>> httpmime, httpcore). But we could still reproduce the issue, then we found
>>> out that one of the fixes introduced in Carbon 4.4.0 was not available in
>>> MDM distribution. I believe MDM or other components pack a custom
>>> launch.ini file. Let me explain.
>>>
>>> Carbon kernel used to export *"javax.xml.soap"* package from the JDK,
>>> hence this package was specified in the *launch.ini* file.
>>> Geronimo-saaj bundle exports this package as well. Now there are two
>>> versions of "javax.xml.soap" package available in the OSGi runtime. The
>>> strange thing is, tomcat bundle dynamically wire to both of the soap
>>> package versions time to time. This behavior is not predictable. When the
>>> tomcat bundle get wired to javax.xml.soap 0.0.0, above mentioned issue
>>> occurs. But when the tomcat is wired 

Re: [Dev] Web app class loading issue

[Manoj Kumara]

Hi Charitha,

The reason here is that you have packed two versions of the same bundle.
Please check the features they get added and remove unnecessary one.

Regards,
Manoj

*Manoj Kumara*
WSO2 Inc. *| **lean. enterprise. middleware.*
*Mobile:* +94 713 448188

On Mon, Oct 5, 2015 at 12:46 PM, Charitha Goonetilleke 
wrote:

> Hi All,
>
> In IoT server we have the same issue, which occurred to Geeth initially.
> Thanks to RuwanA's tool, I figured out the conflicting bundles.
>
> Packages
> org.json
>   Exported By
> json_2.0.0.wso2v1.jar at the location
> /repository/components/plugins/json_2.0.0.wso2v1.jar
> json_3.0.0.wso2v1.jar at the location
> /repository/components/plugins/json_3.0.0.wso2v1.jar
>
> When issue is occurred, tomcat imports org.json from json_3.0.0.wso2v1.jar
> as follows:
>
> osgi> p org.json
> org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
>   oltu_1.0.0.wso2v2 [123] imports
>   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
>   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
>   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
>   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
>   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
>   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
>   org.wso2.carbon.registry.core_4.4.1 [534] imports
>   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
>   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
> org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
>   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
>   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
>   *tomcat_7.0.59.wso2v3* [692] imports
>
> If issue doesn't appear, tomcat imports org.json from json_2.0.0.wso2v1 as
> follows:
>
> osgi> p org.json
> org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
>   oltu_1.0.0.wso2v2 [123] imports
>   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
>   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
>   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
>   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
>   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
>   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
>   org.wso2.carbon.registry.core_4.4.1 [534] imports
>   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
>   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
>   *tomcat_7.0.59.wso2v3* [692] imports
> org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
>   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
>   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
>
> Is there any known workaround to fix this issue?
>
>
> On Wed, Aug 5, 2015 at 8:10 PM, Ruwan Abeykoon  wrote:
>
>> Hi Madushanka,
>> You can exclude the duplicate (unwanted) jar being bundled by your
>> assembly bin.xml (or relevant file) in "maven-assembly-plugin"
>>
>> You can add whatever the bundle to be excluded in the list,
>> XPATH : /assembly/fileSets/fileSet/excludes/exclude[]
>>
>> This is a quick fix until each carbon based feature agree on using same
>> bundle versions for a given base carbon kernel version.
>>
>> Cheers,
>> Ruwan
>>
>> On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne > > wrote:
>>
>>> Hi all,
>>> As in the conversation I understood that the issue happens due to
>>> multiple exports of same package. I face the same scenario in APIM 1.10.0
>>> (1.9.0 upgration to carbon 4.4.0).
>>> I checked the APIM related ones and could not find any wrong export.
>>>
>>> I can see some of the packages like *net.minidev.json, *
>>> *com.nimbusds.jwt*
>>>  are duplicated with multiple versions.
>>>
>>> And
>>> *com.jayway.jsonpath *exported as follows.
>>>
>>> osgi> p com.jayway.jsonpath
>>> com.jayway.jsonpath; version="0.8.1">> [22]>
>>>   synapse-core_2.1.3.wso2v5 [488] imports
>>>   tomcat_7.0.59.wso2v1 [494] imports
>>>
>>> Can someone guide me to remove the unwanted ones?
>>> Thanks in advance for your responses.
>>>
>>> Madusanka
>>>
>>> On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma 
>>> wrote:
>>>
 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export 

Re: [Dev] Web app class loading issue

[Charitha Goonetilleke]

Hi Manoj,

Thanks for the response. Actually, we can't eliminate one bundle version
from above since, both of them have their own dependencies. Actually we
tried to do that by removing *json_3.0.0.wso2v1.* But without that bundle,
org.wso2.carbon.event.simulator.core and org.wso2.carbon.device.mgt.iot.common
bundles throwing class not founds. BTW, I can change json
version dependency for org.wso2.carbon.device.mgt.iot.common bundle. But
still we need to change version for  org.wso2.carbon.event.simulator.core
in that scenario.

Anyway I think it would be better if we cloud upgrade
v2.0.0 dependent bundles to v3.0.0. WDYT?

On Mon, Oct 5, 2015 at 1:34 PM, Manoj Kumara  wrote:

> Hi Charitha,
>
> The reason here is that you have packed two versions of the same bundle.
> Please check the features they get added and remove unnecessary one.
>
> Regards,
> Manoj
>
> *Manoj Kumara*
> WSO2 Inc. *| **lean. enterprise. middleware.*
> *Mobile:* +94 713 448188
>
> On Mon, Oct 5, 2015 at 12:46 PM, Charitha Goonetilleke  > wrote:
>
>> Hi All,
>>
>> In IoT server we have the same issue, which occurred to Geeth initially.
>> Thanks to RuwanA's tool, I figured out the conflicting bundles.
>>
>> Packages
>> org.json
>>   Exported By
>> json_2.0.0.wso2v1.jar at the location
>> /repository/components/plugins/json_2.0.0.wso2v1.jar
>> json_3.0.0.wso2v1.jar at the location
>> /repository/components/plugins/json_3.0.0.wso2v1.jar
>>
>> When issue is occurred, tomcat imports org.json from
>> json_3.0.0.wso2v1.jar as follows:
>>
>> osgi> p org.json
>> org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
>>   oltu_1.0.0.wso2v2 [123] imports
>>   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
>>   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
>>   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
>>   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
>>   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
>>   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
>>   org.wso2.carbon.registry.core_4.4.1 [534] imports
>>   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
>>   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
>> org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
>>   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
>>   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
>>   *tomcat_7.0.59.wso2v3* [692] imports
>>
>> If issue doesn't appear, tomcat imports org.json from json_2.0.0.wso2v1
>> as follows:
>>
>> osgi> p org.json
>> org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
>>   oltu_1.0.0.wso2v2 [123] imports
>>   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
>>   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
>>   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
>>   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
>>   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
>>   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
>>   org.wso2.carbon.registry.core_4.4.1 [534] imports
>>   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
>>   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
>>   *tomcat_7.0.59.wso2v3* [692] imports
>> org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
>>   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
>>   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
>>
>> Is there any known workaround to fix this issue?
>>
>>
>> On Wed, Aug 5, 2015 at 8:10 PM, Ruwan Abeykoon  wrote:
>>
>>> Hi Madushanka,
>>> You can exclude the duplicate (unwanted) jar being bundled by your
>>> assembly bin.xml (or relevant file) in "maven-assembly-plugin"
>>>
>>> You can add whatever the bundle to be excluded in the list,
>>> XPATH : /assembly/fileSets/fileSet/excludes/exclude[]
>>>
>>> This is a quick fix until each carbon based feature agree on using same
>>> bundle versions for a given base carbon kernel version.
>>>
>>> Cheers,
>>> Ruwan
>>>
>>> On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne <
>>> madusan...@wso2.com> wrote:
>>>
 Hi all,
 As in the conversation I understood that the issue happens due to
 multiple exports of same package. I face the same scenario in APIM 1.10.0
 (1.9.0 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, *
 *com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi> p com.jayway.jsonpath
 com.jayway.jsonpath; version="0.8.1">>> [22]>
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.

 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera 

Re: [Dev] Web app class loading issue

[Madusanka Premaratne]

Hi Charitha,
As per our findings, multiple versions from same bundle does not cause this
issue. Usually this happens due to multiple jars which exports same package
/ incorrectly designed orbit bundles. Please find out those and exclude
those.

In APIM we have removed some jars to resolve the issue. Please refer [1]

[1] -
https://github.com/wso2/product-apim/blob/1.10.x/modules/distribution/product/src/main/assembly/bin.xml#L66

Thanks,
Madusanka

On Mon, Oct 5, 2015 at 2:17 PM, Charitha Goonetilleke 
wrote:

> Hi Manoj,
>
> Thanks for the response. Actually, we can't eliminate one bundle version
> from above since, both of them have their own dependencies. Actually we
> tried to do that by removing *json_3.0.0.wso2v1.* But without that
> bundle, org.wso2.carbon.event.simulator.core and
> org.wso2.carbon.device.mgt.iot.common bundles throwing class not founds.
> BTW, I can change json version dependency for 
> org.wso2.carbon.device.mgt.iot.common
> bundle. But still we need to change version for  
> org.wso2.carbon.event.simulator.core
> in that scenario.
>
> Anyway I think it would be better if we cloud upgrade
> v2.0.0 dependent bundles to v3.0.0. WDYT?
>
> On Mon, Oct 5, 2015 at 1:34 PM, Manoj Kumara  wrote:
>
>> Hi Charitha,
>>
>> The reason here is that you have packed two versions of the same bundle.
>> Please check the features they get added and remove unnecessary one.
>>
>> Regards,
>> Manoj
>>
>> *Manoj Kumara*
>> WSO2 Inc. *| **lean. enterprise. middleware.*
>> *Mobile:* +94 713 448188
>>
>> On Mon, Oct 5, 2015 at 12:46 PM, Charitha Goonetilleke <
>> charit...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> In IoT server we have the same issue, which occurred to Geeth initially.
>>> Thanks to RuwanA's tool, I figured out the conflicting bundles.
>>>
>>> Packages
>>> org.json
>>>   Exported By
>>> json_2.0.0.wso2v1.jar at the location
>>> /repository/components/plugins/json_2.0.0.wso2v1.jar
>>> json_3.0.0.wso2v1.jar at the location
>>> /repository/components/plugins/json_3.0.0.wso2v1.jar
>>>
>>> When issue is occurred, tomcat imports org.json from
>>> json_3.0.0.wso2v1.jar as follows:
>>>
>>> osgi> p org.json
>>> org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
>>>   oltu_1.0.0.wso2v2 [123] imports
>>>   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
>>>   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
>>>   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
>>>   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
>>>   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
>>>   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
>>>   org.wso2.carbon.registry.core_4.4.1 [534] imports
>>>   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
>>>   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
>>> org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
>>>   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
>>>   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
>>>   *tomcat_7.0.59.wso2v3* [692] imports
>>>
>>> If issue doesn't appear, tomcat imports org.json from json_2.0.0.wso2v1
>>> as follows:
>>>
>>> osgi> p org.json
>>> org.json; version="2.0.0.wso2v1"<*json_2.0.0.wso2v1* [102]>
>>>   oltu_1.0.0.wso2v2 [123] imports
>>>   org.wso2.carbon.apimgt.impl_4.3.0.SNAPSHOT [264] imports
>>>   org.wso2.carbon.apimgt.keymgt_4.3.0.SNAPSHOT [265] imports
>>>   org.wso2.carbon.databridge.commons_4.4.7 [299] imports
>>>   org.wso2.carbon.databridge.commons_5.0.2 [300] imports
>>>   org.wso2.carbon.event.receiver.core_5.0.2 [379] imports
>>>   org.wso2.carbon.event.simulator.admin_2.0.5 [382] imports
>>>   org.wso2.carbon.registry.core_4.4.1 [534] imports
>>>   org.wso2.carbon.social.core_2.3.9.SNAPSHOT [584] imports
>>>   org.wso2.carbon.tenant.mgt.ui_4.5.0.m1 [603] imports
>>>   *tomcat_7.0.59.wso2v3* [692] imports
>>> org.json; version="3.0.0.wso2v1"<*json_3.0.0.wso2v1* [103]>
>>>   org.wso2.carbon.device.mgt.iot.common_1.0.0.SNAPSHOT [315] imports
>>>   org.wso2.carbon.event.simulator.core_2.0.5 [383] imports
>>>
>>> Is there any known workaround to fix this issue?
>>>
>>>
>>> On Wed, Aug 5, 2015 at 8:10 PM, Ruwan Abeykoon  wrote:
>>>
 Hi Madushanka,
 You can exclude the duplicate (unwanted) jar being bundled by your
 assembly bin.xml (or relevant file) in "maven-assembly-plugin"

 You can add whatever the bundle to be excluded in the list,
 XPATH : /assembly/fileSets/fileSet/excludes/exclude[]

 This is a quick fix until each carbon based feature agree on using same
 bundle versions for a given base carbon kernel version.

 Cheers,
 Ruwan

 On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne <
 madusan...@wso2.com> wrote:

> Hi all,
> As in the conversation I understood that the issue happens due to
> multiple exports of same package. I face the same scenario in APIM 1.10.0
> 

Re: [Dev] Web app class loading issue

[Ruwan Abeykoon]

Hi Madushanka,
You can exclude the duplicate (unwanted) jar being bundled by your assembly
bin.xml (or relevant file) in maven-assembly-plugin

You can add whatever the bundle to be excluded in the list,
XPATH : /assembly/fileSets/fileSet/excludes/exclude[]

This is a quick fix until each carbon based feature agree on using same
bundle versions for a given base carbon kernel version.

Cheers,
Ruwan

On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne madusan...@wso2.com
wrote:

 Hi all,
 As in the conversation I understood that the issue happens due to multiple
 exports of same package. I face the same scenario in APIM 1.10.0 (1.9.0
 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, **com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi p com.jayway.jsonpath
 com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1 [22]
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.

 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com
 wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the JDK,
 hence this package was specified in the *launch.ini* file. Geronimo-saaj
 bundle exports this package as well. Now there are two versions of
 javax.xml.soap package available in the OSGi runtime. The strange thing
 is, tomcat bundle dynamically wire to both of the soap package versions
 time to time. This behavior is not predictable. When the tomcat bundle get
 wired to javax.xml.soap 0.0.0, above mentioned issue occurs. But when the
 tomcat is wired to 1.0.0 version of the package this issue does not occur.
 We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3
 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386]
 imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
 export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and try to
 use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from 

Re: [Dev] Web app class loading issue

[Aruna Karunarathna]

See thread [1]

[1]. [Dev] Duplicate OSGI class inspector for Carbon based products

On Tue, Aug 4, 2015 at 4:20 PM, Madusanka Premaratne madusan...@wso2.com
wrote:

 Hi Aruna,
 No I did not try with that. Where can I find the tool?

 On Tue, Aug 4, 2015 at 3:42 PM, Aruna Karunarathna ar...@wso2.com wrote:



 On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne madusan...@wso2.com
  wrote:

 Hi all,
 As in the conversation I understood that the issue happens due to
 multiple exports of same package. I face the same scenario in APIM 1.10.0
 (1.9.0 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, *
 *com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi p com.jayway.jsonpath
 com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1
 [22]
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.


 Have you tried the tool written by RuwanA?.


 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com
 wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the JDK,
 hence this package was specified in the *launch.ini* file.
 Geronimo-saaj bundle exports this package as well. Now there are two
 versions of javax.xml.soap package available in the OSGi runtime. The
 strange thing is, tomcat bundle dynamically wire to both of the soap
 package versions time to time. This behavior is not predictable. When the
 tomcat bundle get wired to javax.xml.soap 0.0.0, above mentioned issue
 occurs. But when the tomcat is wired to 1.0.0 version of the package this
 issue does not occur. We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*;
 version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3
 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386]
 imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*;
 version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
 export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and try
 to use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com
 wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by
 a tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 

Re: [Dev] Web app class loading issue

[Madusanka Premaratne]

Hi Aruna,
No I did not try with that. Where can I find the tool?

On Tue, Aug 4, 2015 at 3:42 PM, Aruna Karunarathna ar...@wso2.com wrote:



 On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne madusan...@wso2.com
 wrote:

 Hi all,
 As in the conversation I understood that the issue happens due to
 multiple exports of same package. I face the same scenario in APIM 1.10.0
 (1.9.0 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, *
 *com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi p com.jayway.jsonpath
 com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1
 [22]
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.


 Have you tried the tool written by RuwanA?.


 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com
 wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the JDK,
 hence this package was specified in the *launch.ini* file.
 Geronimo-saaj bundle exports this package as well. Now there are two
 versions of javax.xml.soap package available in the OSGi runtime. The
 strange thing is, tomcat bundle dynamically wire to both of the soap
 package versions time to time. This behavior is not predictable. When the
 tomcat bundle get wired to javax.xml.soap 0.0.0, above mentioned issue
 occurs. But when the tomcat is wired to 1.0.0 version of the package this
 issue does not occur. We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3
 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386]
 imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
 export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and try
 to use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com
 wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by
 a tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 

Re: [Dev] Web app class loading issue

[Madusanka Premaratne]

Thanks Aruna for the response. I will try with that.

On Tue, Aug 4, 2015 at 4:22 PM, Aruna Karunarathna ar...@wso2.com wrote:

 See thread [1]

 [1]. [Dev] Duplicate OSGI class inspector for Carbon based products

 On Tue, Aug 4, 2015 at 4:20 PM, Madusanka Premaratne madusan...@wso2.com
 wrote:

 Hi Aruna,
 No I did not try with that. Where can I find the tool?

 On Tue, Aug 4, 2015 at 3:42 PM, Aruna Karunarathna ar...@wso2.com
 wrote:



 On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne 
 madusan...@wso2.com wrote:

 Hi all,
 As in the conversation I understood that the issue happens due to
 multiple exports of same package. I face the same scenario in APIM 1.10.0
 (1.9.0 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, *
 *com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi p com.jayway.jsonpath
 com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1
 [22]
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.


 Have you tried the tool written by RuwanA?.


 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com
 wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the JDK,
 hence this package was specified in the *launch.ini* file.
 Geronimo-saaj bundle exports this package as well. Now there are two
 versions of javax.xml.soap package available in the OSGi runtime. The
 strange thing is, tomcat bundle dynamically wire to both of the soap
 package versions time to time. This behavior is not predictable. When the
 tomcat bundle get wired to javax.xml.soap 0.0.0, above mentioned issue
 occurs. But when the tomcat is wired to 1.0.0 version of the package this
 issue does not occur. We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*;
 version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3
 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386]
 imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*;
 version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
 export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and try
 to use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com
 wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed
 by a tomcat patch. Seems the same CNF error is happening on kernel 4.4.0
 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  
 Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 

Re: [Dev] Web app class loading issue

[Aruna Karunarathna]

On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne madusan...@wso2.com
wrote:

 Hi all,
 As in the conversation I understood that the issue happens due to multiple
 exports of same package. I face the same scenario in APIM 1.10.0 (1.9.0
 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, **com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi p com.jayway.jsonpath
 com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1 [22]
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.


Have you tried the tool written by RuwanA?.


 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com
 wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the JDK,
 hence this package was specified in the *launch.ini* file. Geronimo-saaj
 bundle exports this package as well. Now there are two versions of
 javax.xml.soap package available in the OSGi runtime. The strange thing
 is, tomcat bundle dynamically wire to both of the soap package versions
 time to time. This behavior is not predictable. When the tomcat bundle get
 wired to javax.xml.soap 0.0.0, above mentioned issue occurs. But when the
 tomcat is wired to 1.0.0 version of the package this issue does not occur.
 We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3
 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386]
 imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
 export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and try to
 use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 

Re: [Dev] Web app class loading issue

[Madusanka Premaratne]

Hi all,
As in the conversation I understood that the issue happens due to multiple
exports of same package. I face the same scenario in APIM 1.10.0 (1.9.0
upgration to carbon 4.4.0).
I checked the APIM related ones and could not find any wrong export.

I can see some of the packages like *net.minidev.json, **com.nimbusds.jwt*
 are duplicated with multiple versions.

And
*com.jayway.jsonpath *exported as follows.

osgi p com.jayway.jsonpath
com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1 [22]
  synapse-core_2.1.3.wso2v5 [488] imports
  tomcat_7.0.59.wso2v1 [494] imports

Can someone guide me to remove the unwanted ones?
Thanks in advance for your responses.

Madusanka

On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of these
 issues is the existence of multiple versions of some packages. OSGi is
 designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the JDK,
 hence this package was specified in the *launch.ini* file. Geronimo-saaj
 bundle exports this package as well. Now there are two versions of
 javax.xml.soap package available in the OSGi runtime. The strange thing
 is, tomcat bundle dynamically wire to both of the soap package versions
 time to time. This behavior is not predictable. When the tomcat bundle get
 wired to javax.xml.soap 0.0.0, above mentioned issue occurs. But when the
 tomcat is wired to 1.0.0 version of the package this issue does not occur.
 We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3
 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242
 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
 export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and try to
 use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 

Re: [Dev] Web app class loading issue

[Harsha Kumara]

Hi Madusanka,

I have went through the pack seems, there a quite bit of same bundles with
different versions. There are
two org.wso2.carbon.apimgt.handlers.security.stub jars with different
versions 4.2.1 and 4.3.0 I have removed it and checked, seems the issue is
disappeared. Anyhow I deleted some more jars just for testing purposes.
Please went through jars to check whether why it's getting there.

Thanks
Harsha

On Tue, Aug 4, 2015 at 4:26 PM, Madusanka Premaratne madusan...@wso2.com
wrote:

 Thanks Aruna for the response. I will try with that.

 On Tue, Aug 4, 2015 at 4:22 PM, Aruna Karunarathna ar...@wso2.com wrote:

 See thread [1]

 [1]. [Dev] Duplicate OSGI class inspector for Carbon based products

 On Tue, Aug 4, 2015 at 4:20 PM, Madusanka Premaratne madusan...@wso2.com
  wrote:

 Hi Aruna,
 No I did not try with that. Where can I find the tool?

 On Tue, Aug 4, 2015 at 3:42 PM, Aruna Karunarathna ar...@wso2.com
 wrote:



 On Tue, Aug 4, 2015 at 3:14 PM, Madusanka Premaratne 
 madusan...@wso2.com wrote:

 Hi all,
 As in the conversation I understood that the issue happens due to
 multiple exports of same package. I face the same scenario in APIM 1.10.0
 (1.9.0 upgration to carbon 4.4.0).
 I checked the APIM related ones and could not find any wrong export.

 I can see some of the packages like *net.minidev.json, *
 *com.nimbusds.jwt*
  are duplicated with multiple versions.

 And
 *com.jayway.jsonpath *exported as follows.

 osgi p com.jayway.jsonpath
 com.jayway.jsonpath; version=0.8.1com.jayway.jsonpath_0.8.1.wso2v1
 [22]
   synapse-core_2.1.3.wso2v5 [488] imports
   tomcat_7.0.59.wso2v1 [494] imports

 Can someone guide me to remove the unwanted ones?
 Thanks in advance for your responses.


 Have you tried the tool written by RuwanA?.


 Madusanka

 On Thu, May 21, 2015 at 11:59 AM, Sameera Jayasoma same...@wso2.com
 wrote:

 Hello Geeth,

 We've encountered many similar issues in the past. The main cause of
 these issues is the existence of multiple versions of some packages. OSGi
 is designed to support this scenario. But in some cases, OSGi resolution
 algorithm fails wire dynamical imported packages due multiple versions of
 some packages. This is indeed a wired observation.

 We've removed some duplicated bundles in CDM pack (e.g. httpclient,
 httpmime, httpcore). But we could still reproduce the issue, then we 
 found
 out that one of the fixes introduced in Carbon 4.4.0 was not available in
 MDM distribution. I believe MDM or other components pack a custom
 launch.ini file. Let me explain.

 Carbon kernel used to export *javax.xml.soap* package from the
 JDK, hence this package was specified in the *launch.ini* file.
 Geronimo-saaj bundle exports this package as well. Now there are two
 versions of javax.xml.soap package available in the OSGi runtime. The
 strange thing is, tomcat bundle dynamically wire to both of the soap
 package versions time to time. This behavior is not predictable. When the
 tomcat bundle get wired to javax.xml.soap 0.0.0, above mentioned issue
 occurs. But when the tomcat is wired to 1.0.0 version of the package this
 issue does not occur. We still don't know why this happens.

 Working
 osgi p javax.xml.soap
 *javax.xml.soap*;
 version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
 *javax.xml.soap*;
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports

 *  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386]
 imports
   wss4j_1.5.11.wso2v9 [387] imports


 Not Working
 osgi p javax.xml.soap
 *javax.xml.soap*;
 version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
   org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
   org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
   org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

 *  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
 version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
   axis2_1.6.1.wso2v12 [14] imports
   org.wso2.carbon.apimgt.core_1.4.0 [154] imports
   spring.framework_3.2.9.wso2v1 [372] imports
   wss4j_1.5.11.wso2v10 [386] imports
   wss4j_1.5.11.wso2v9 [387] imports

 Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing
 the export of 0.0.0 version of this package.

 MDM team, please remove the custom launch.ini file if possible and
 try to use the one packed with the Kernel.

 Thanks,
 Sameera.

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com
 wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed
 by a tomcat patch. Seems the same CNF error is happening on kernel 4.4.0
 too.



 

Re: [Dev] Web app class loading issue

[Sameera Jayasoma]

Hello Geeth,

We've encountered many similar issues in the past. The main cause of these
issues is the existence of multiple versions of some packages. OSGi is
designed to support this scenario. But in some cases, OSGi resolution
algorithm fails wire dynamical imported packages due multiple versions of
some packages. This is indeed a wired observation.

We've removed some duplicated bundles in CDM pack (e.g. httpclient,
httpmime, httpcore). But we could still reproduce the issue, then we found
out that one of the fixes introduced in Carbon 4.4.0 was not available in
MDM distribution. I believe MDM or other components pack a custom
launch.ini file. Let me explain.

Carbon kernel used to export *javax.xml.soap* package from the JDK, hence
this package was specified in the *launch.ini* file. Geronimo-saaj bundle
exports this package as well. Now there are two versions of
javax.xml.soap package available in the OSGi runtime. The strange thing
is, tomcat bundle dynamically wire to both of the soap package versions
time to time. This behavior is not predictable. When the tomcat bundle get
wired to javax.xml.soap 0.0.0, above mentioned issue occurs. But when the
tomcat is wired to 1.0.0 version of the package this issue does not occur.
We still don't know why this happens.

Working
osgi p javax.xml.soap
*javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
  org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
  org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
  org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports
*javax.xml.soap*; version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
  axis2_1.6.1.wso2v12 [14] imports
  org.wso2.carbon.apimgt.core_1.4.0 [154] imports
  spring.framework_3.2.9.wso2v1 [372] imports

*  tomcat_7.0.59.wso2v1 [375] imports*  wss4j_1.5.11.wso2v10 [386] imports
  wss4j_1.5.11.wso2v9 [387] imports


Not Working
osgi p javax.xml.soap
*javax.xml.soap*; version=0.0.0org.eclipse.osgi_3.9.1.v20130814-1242 [0]
  org.eclipse.core.expressions_3.4.500.v20130515-1343 [78] imports
  org.eclipse.core.runtime_3.9.0.v20130326-1255 [80] imports
  org.wso2.carbon.p2.touchpoint_4.4.0 [277] imports

*  tomcat_7.0.59.wso2v1 [375] importsjavax.xml.soap;*
version=1.0.0geronimo-saaj_1.3_spec_1.0.0.wso2v3 [38]
  axis2_1.6.1.wso2v12 [14] imports
  org.wso2.carbon.apimgt.core_1.4.0 [154] imports
  spring.framework_3.2.9.wso2v1 [372] imports
  wss4j_1.5.11.wso2v10 [386] imports
  wss4j_1.5.11.wso2v9 [387] imports

Anyway his issue has been fixed in Carbon Kernel 4.4.0 by removing the
export of 0.0.0 version of this package.

MDM team, please remove the custom launch.ini file if possible and try to
use the one packed with the Kernel.

Thanks,
Sameera.

On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,899]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Destroying singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,901] ERROR
 {org.apache.catalina.core.ApplicationContext} -  StandardWrapper.Throwable

 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'tokEP': Cannot resolve reference to bean
 

Re: [Dev] Web app class loading issue

[Geeth Munasinghe]

Hi Kernel Team,

This is critical issue for us to continue development. Please consider this
as a urgent matter.

Thanks
Geeth


*G. K. S. Munasinghe*
*Senior Software Engineer,*
*WSO2, Inc. http://wso2.com http://wso2.com/ *
*lean.enterprise.middleware.*

email: ge...@wso2.com
phone:(+94) 777911226

On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,899]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Destroying singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,901] ERROR
 {org.apache.catalina.core.ApplicationContext} -  StandardWrapper.Throwable

 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'tokEP': Cannot resolve reference to bean
 'authzEndpointBean' while setting bean property 'serviceBeans' with key
 [0]; nested exception is
 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'authzEndpointBean' defined in URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]: Instantiation of bean
 failed; nested exception is java.lang.NoClassDefFoundError:
 org/wso2/carbon/identity/oauth/cache/CacheKey

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1327)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1085)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:516)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)

 at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)

 at
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)

 at
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)

 at
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)

 at
 

[Dev] Web app class loading issue

[Geeth Munasinghe]

Hi all,

I am getting the following CNF error intermittently. MDM is built on kernel
4.4.0.

 As I remember we got this issue for kernel 4.3.0, but it was fixed by a
tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.


/wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

[2015-05-19 15:29:17,619]  INFO
{org.springframework.web.context.support.XmlWebApplicationContext} -
Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
IST 2015]; root of context hierarchy

[2015-05-19 15:29:17,651]  INFO
{org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

[2015-05-19 15:29:17,676]  INFO
{org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
XML bean definitions from URL
[jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

[2015-05-19 15:29:17,745]  INFO
{org.springframework.beans.factory.support.DefaultListableBeanFactory} -
Pre-instantiating singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
defining beans
[cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
root of factory hierarchy

[2015-05-19 15:29:17,899]  INFO
{org.springframework.beans.factory.support.DefaultListableBeanFactory} -
Destroying singletons in
org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
defining beans
[cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
root of factory hierarchy

[2015-05-19 15:29:17,901] ERROR
{org.apache.catalina.core.ApplicationContext} -  StandardWrapper.Throwable

org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'tokEP': Cannot resolve reference to bean
'authzEndpointBean' while setting bean property 'serviceBeans' with key
[0]; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'authzEndpointBean' defined in URL
[jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]: Instantiation of bean
failed; nested exception is java.lang.NoClassDefFoundError:
org/wso2/carbon/identity/oauth/cache/CacheKey

at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)

at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)

at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)

at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1327)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1085)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:516)

at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)

at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)

at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)

at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)

at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)

at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)

at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)

at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:425)

at
org.apache.cxf.transport.servlet.CXFServlet.createSpringContext(CXFServlet.java:160)

at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:74)

at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.init(CXFNonSpringServlet.java:71)

at
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)

at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)

at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)

at

Re: [Dev] Web app class loading issue

[Supun Malinga]

Hi Geeth,

There is a workaround suggested in [Dev] [Urgent] [Greg] - Error when
server start up thread. So you may try that until this is properly fixed..

thanks,

On Tue, May 19, 2015 at 4:35 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi Kernel Team,

 This is critical issue for us to continue development. Please consider
 this as a urgent matter.

 Thanks
 Geeth


 *G. K. S. Munasinghe*
 *Senior Software Engineer,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ge...@wso2.com
 phone:(+94) 777911226

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,899]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Destroying singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,901] ERROR
 {org.apache.catalina.core.ApplicationContext} -  StandardWrapper.Throwable

 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'tokEP': Cannot resolve reference to bean
 'authzEndpointBean' while setting bean property 'serviceBeans' with key
 [0]; nested exception is
 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'authzEndpointBean' defined in URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]: Instantiation of bean
 failed; nested exception is java.lang.NoClassDefFoundError:
 org/wso2/carbon/identity/oauth/cache/CacheKey

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1327)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1085)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:516)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)

 at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)

 at
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)

 at
 

Re: [Dev] Web app class loading issue

[Sameera Jayasoma]

Hi Geeth,

Why do you held the kernel team responsible for this issue?

Thanks,
Sameera.

On Tue, May 19, 2015 at 4:35 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi Kernel Team,

 This is critical issue for us to continue development. Please consider
 this as a urgent matter.

 Thanks
 Geeth


 *G. K. S. Munasinghe*
 *Senior Software Engineer,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ge...@wso2.com
 phone:(+94) 777911226

 On Tue, May 19, 2015 at 3:50 PM, Geeth Munasinghe ge...@wso2.com wrote:

 Hi all,

 I am getting the following CNF error intermittently. MDM is built on
 kernel 4.4.0.

  As I remember we got this issue for kernel 4.3.0, but it was fixed by a
 tomcat patch. Seems the same CNF error is happening on kernel 4.4.0 too.



 /wso2mdm-2.0.0-SNAPSHOT/repository/deployment/server/webapps/mdm-windows-agent.war]

 [2015-05-19 15:29:17,619]  INFO
 {org.springframework.web.context.support.XmlWebApplicationContext} -
 Refreshing Root WebApplicationContext: startup date [Tue May 19 15:29:17
 IST 2015]; root of context hierarchy

 [2015-05-19 15:29:17,651]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from class path resource [META-INF/cxf/cxf.xml]

 [2015-05-19 15:29:17,676]  INFO
 {org.springframework.beans.factory.xml.XmlBeanDefinitionReader} -  Loading
 XML bean definitions from URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]

 [2015-05-19 15:29:17,745]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Pre-instantiating singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,899]  INFO
 {org.springframework.beans.factory.support.DefaultListableBeanFactory} -
 Destroying singletons in
 org.springframework.beans.factory.support.DefaultListableBeanFactory@787dc93c:
 defining beans
 [cxf,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,tokEP,authzEndpointBean,tokenEndpointBean,revokeEndpointBean,userinfoEndpointBean];
 root of factory hierarchy

 [2015-05-19 15:29:17,901] ERROR
 {org.apache.catalina.core.ApplicationContext} -  StandardWrapper.Throwable

 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'tokEP': Cannot resolve reference to bean
 'authzEndpointBean' while setting bean property 'serviceBeans' with key
 [0]; nested exception is
 org.springframework.beans.factory.BeanCreationException: Error creating
 bean with name 'authzEndpointBean' defined in URL
 [jndi:/localhost/oauth2/WEB-INF/cxf-servlet.xml]: Instantiation of bean
 failed; nested exception is java.lang.NoClassDefFoundError:
 org/wso2/carbon/identity/oauth/cache/CacheKey

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedList(BeanDefinitionValueResolver.java:353)

 at
 org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:153)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1327)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1085)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:516)

 at
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)

 at
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290)

 at
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:192)

 at
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:585)

 at
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)

 at