Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
There is one weird thing I've noticed ... my project is running super well with equinox 3.10. When I trying to run it with Felix 4.4.1 which comes with Bndtools the RAM usage climbs up to 2GB and then I get an error stating that the heap stack is out of memory. This is not normal behaviour from an OSGi container. On 23.06.2015 12:32, chris.g...@kiffer.be wrote: But do you know why? It's working now! On 21.06.2015 20:09, chris.g...@kiffer.be wrote: If you are launching the giant jar in both cases then that does indeed reduce the differences to a minimum. Therefore I think you need to look at things outside of the jar: the Java version, the database (is it accessible on the ARM7 target, with the same credentials?), anything which is being read from the host filesystem (i.e. not from inside a bundle) and which could therefore be different or absent on the target ... have you tried running the giant jar on a virgin PC, one that has never been used to develop or run your software? If bundles are staying as ACTIVE that indicates that they are not getting RESOLVED. Chances are that something pretty basic is going wrong in one bundle and this is having a domino effect on all the rest - and this could be happening before logging is initialised, so you don't see the root cause. See if you can get Equinox to send some detailed logging to stdout. So the way Bndtools packages the whole project is by compressing all the required jars inside of one giant jar. When you run that jar with the following : java -jar MyBigProject.jar Bndtools start the initialization of the OSGi framework and then loads all the other jars within. I was not expecting to have any problem because java runs the same on all platform in theory. Again I'm confused why It's not working On 20.06.2015 21:43, chris.g...@kiffer.be wrote: So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: It’s a bit odd to see the “Package uses conflict� message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
This is normal behaviour for a Java application which is spiralling out of control. ;) As in infinite recursion, or stuck in a tight loop trying to create a component and always failing. You should take this up on the felix mailing list, and preferably post the stack trace instead of I get an error stating that the heap stack is out of memory.. There is one weird thing I've noticed ... my project is running super well with equinox 3.10. When I trying to run it with Felix 4.4.1 which comes with Bndtools the RAM usage climbs up to 2GB and then I get an error stating that the heap stack is out of memory. This is not normal behaviour from an OSGi container. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
Yes I've changed few bundles removed few and updated old ones and somehow it worked. I've compiled the latest github of Gemini Blueprint myself and used these jars. I had 195 bundles when I finished cleaning everything it went down to 169 bundles... Now it is working pretty neatly on ARM7 ubuntu On 23.06.2015 12:32, chris.g...@kiffer.be wrote: But do you know why? It's working now! On 21.06.2015 20:09, chris.g...@kiffer.be wrote: If you are launching the giant jar in both cases then that does indeed reduce the differences to a minimum. Therefore I think you need to look at things outside of the jar: the Java version, the database (is it accessible on the ARM7 target, with the same credentials?), anything which is being read from the host filesystem (i.e. not from inside a bundle) and which could therefore be different or absent on the target ... have you tried running the giant jar on a virgin PC, one that has never been used to develop or run your software? If bundles are staying as ACTIVE that indicates that they are not getting RESOLVED. Chances are that something pretty basic is going wrong in one bundle and this is having a domino effect on all the rest - and this could be happening before logging is initialised, so you don't see the root cause. See if you can get Equinox to send some detailed logging to stdout. So the way Bndtools packages the whole project is by compressing all the required jars inside of one giant jar. When you run that jar with the following : java -jar MyBigProject.jar Bndtools start the initialization of the OSGi framework and then loads all the other jars within. I was not expecting to have any problem because java runs the same on all platform in theory. Again I'm confused why It's not working On 20.06.2015 21:43, chris.g...@kiffer.be wrote: So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: It’s a bit odd to see the “Package uses conflict� message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
It's working now! On 21.06.2015 20:09, chris.g...@kiffer.be wrote: If you are launching the giant jar in both cases then that does indeed reduce the differences to a minimum. Therefore I think you need to look at things outside of the jar: the Java version, the database (is it accessible on the ARM7 target, with the same credentials?), anything which is being read from the host filesystem (i.e. not from inside a bundle) and which could therefore be different or absent on the target ... have you tried running the giant jar on a virgin PC, one that has never been used to develop or run your software? If bundles are staying as ACTIVE that indicates that they are not getting RESOLVED. Chances are that something pretty basic is going wrong in one bundle and this is having a domino effect on all the rest - and this could be happening before logging is initialised, so you don't see the root cause. See if you can get Equinox to send some detailed logging to stdout. So the way Bndtools packages the whole project is by compressing all the required jars inside of one giant jar. When you run that jar with the following : java -jar MyBigProject.jar Bndtools start the initialization of the OSGi framework and then loads all the other jars within. I was not expecting to have any problem because java runs the same on all platform in theory. Again I'm confused why It's not working On 20.06.2015 21:43, chris.g...@kiffer.be wrote: So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: It’s a bit odd to see the “Package uses conflict� message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
But do you know why? It's working now! On 21.06.2015 20:09, chris.g...@kiffer.be wrote: If you are launching the giant jar in both cases then that does indeed reduce the differences to a minimum. Therefore I think you need to look at things outside of the jar: the Java version, the database (is it accessible on the ARM7 target, with the same credentials?), anything which is being read from the host filesystem (i.e. not from inside a bundle) and which could therefore be different or absent on the target ... have you tried running the giant jar on a virgin PC, one that has never been used to develop or run your software? If bundles are staying as ACTIVE that indicates that they are not getting RESOLVED. Chances are that something pretty basic is going wrong in one bundle and this is having a domino effect on all the rest - and this could be happening before logging is initialised, so you don't see the root cause. See if you can get Equinox to send some detailed logging to stdout. So the way Bndtools packages the whole project is by compressing all the required jars inside of one giant jar. When you run that jar with the following : java -jar MyBigProject.jar Bndtools start the initialization of the OSGi framework and then loads all the other jars within. I was not expecting to have any problem because java runs the same on all platform in theory. Again I'm confused why It's not working On 20.06.2015 21:43, chris.g...@kiffer.be wrote: So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: Itâs a bit odd to see the âPackage uses conflictâ message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
So the way Bndtools packages the whole project is by compressing all the required jars inside of one giant jar. When you run that jar with the following : java -jar MyBigProject.jar Bndtools start the initialization of the OSGi framework and then loads all the other jars within. I was not expecting to have any problem because java runs the same on all platform in theory. Again I'm confused why It's not working On 20.06.2015 21:43, chris.g...@kiffer.be wrote: So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: It’s a bit odd to see the “Package uses conflict� message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
If you are launching the giant jar in both cases then that does indeed reduce the differences to a minimum. Therefore I think you need to look at things outside of the jar: the Java version, the database (is it accessible on the ARM7 target, with the same credentials?), anything which is being read from the host filesystem (i.e. not from inside a bundle) and which could therefore be different or absent on the target ... have you tried running the giant jar on a virgin PC, one that has never been used to develop or run your software? If bundles are staying as ACTIVE that indicates that they are not getting RESOLVED. Chances are that something pretty basic is going wrong in one bundle and this is having a domino effect on all the rest - and this could be happening before logging is initialised, so you don't see the root cause. See if you can get Equinox to send some detailed logging to stdout. So the way Bndtools packages the whole project is by compressing all the required jars inside of one giant jar. When you run that jar with the following : java -jar MyBigProject.jar Bndtools start the initialization of the OSGi framework and then loads all the other jars within. I was not expecting to have any problem because java runs the same on all platform in theory. Again I'm confused why It's not working On 20.06.2015 21:43, chris.g...@kiffer.be wrote: So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: Itâs a bit odd to see the âPackage uses conflictâ message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
So we have the same bundles running on the same framework ... what are the other variables? Maybe another JDBC driver or a different JVM for example? Neither should make a big difference, but you never know. Or the framework is being launched with different parameters - on DEV it is presumably launched by bndtools, how is it launched on ARM7? Like Neil I'm a bit surprised by the lack of detail in the error message, are you sure there is not more information available somewhere? It could be interesting to know which bundles stay in INSTALLED, maybe this will give a clue. Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: Itâs a bit odd to see the âPackage uses conflictâ message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
Sorry for the targetted email towards Peter... this question was copied and pasted from a skype session and I forgot to remove his name to render the question more generic. :) Yes Neil you are correct I'm running equinox 3.7. Which comes with Bndtools. Unfortunately I cannot migrate towards Equinox 3.10(OSGi R5) because of the incompatibility of Aries Transaction Manager which breaks the PlatformTransactionManager I depend on from Spring when I use it. Chris I verified the (lb command from gogo shell) from my dev IDE and the ARM7 server I setup and they are showing the sames bundle versions. I don't think that there is a real conflict since I'm only using Spring Transaction Manager 4.1.1. The other bundles which are using the SPM 4.1.1 don't show this error only few get ACTIVE and the rest stays as INSTALLED. I double checked with WebConsole and it's only on the ARM7 server it breaks. Sent from my iPod On 2015-06-19, at 21:05, Neil Bartlett njbartl...@gmail.com wrote: It’s a bit odd to see the “Package uses conflict” message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
It’s a bit odd to see the “Package uses conflict” message but without the diagnostics of the conflicting chains. Are you running on an older OSGi Framework implementation? How are you launching your framework? Regards Neil On 19 Jun 2015, at 19:36, chris.g...@kiffer.be wrote: Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Bndtools OSGi Project not running on ARM7 - But OK on DEV machine
Fortunately Peter is not the only one on this mailing list ;-) I'm no Blueprint wizard, but it does look very as much as if bambu is in a bit of a tizz about spring.framework.transaction.annotation. Probably the framework you are deploying into has different versions of some modules to what you have on your dev machine; your code was probably compiled against version 4.1, so you need to have version 4.x installed on the server and not 3.x or 5.x for example. Wherever possible you should try to have the same version of all the dependencies on the dev machine as are on the target, to avoid these surprises. In particular, having a more recent version on dev than is running on the target is inviting disappointment. greetings Peter do you have an idea why i get this error on ARM7 when I try to put my osgi project on production on the ARM7 I run the project within my eclipse environment I get no error with Bndtools by the way I use the EXPORT function from bndtools to generate the jar that I'm using on the headless ARM7 ubuntu server Best regards Ergü ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
