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 >> >> _______________________________________________ >> 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
