When I start bundle ID it does not run the module.

[Freemon Johnson]

Hi Thomas,

When I start the bundle ID for my python module the State reads its active but I know for certain the module is not executing. When I invoke my module from command line using python2.7 module.py it runs fine.

I know you can automatically launch Pelix and run your module at the same time but I want to install and start it through the pelix.shell. 

I have the pelix main entry point in the module as well .e.g

if __name__ == '__main__:

    main()

Simple applications I had no issue but this module has threads in it and external dependencies or modules that it imports to run. Any ideas? I have multiple versions of python installed. so when I launch pelix.shell i issue

python2.7 -m pelix.shell 

When start() is invoked will Pelix use Python2.7 or does it use the default python in the default path? Is there a way to tell pelix to use python2.7? What I want to avoid is creating any symbolic links or changing the pythonpath because that will break everything else in the linux distro that depends on that version of python. I am just guessing this is the issue by the way.

Thank you for any help!

Cheers,

Freemon

 

[Thomas Calmant]

Hi Freemon,

Le mardi 14 juin 2016 23:33:37 UTC+2, Freemon Johnson a écrit :

Hi Thomas,

When I start the bundle ID for my python module the State reads its active but I know for certain the module is not executing. When I invoke my module from command line using python2.7 module.py it runs fine.

I know you can automatically launch Pelix and run your module at the same time but I want to install and start it through the pelix.shell. 

I have the pelix main entry point in the module as well .e.g

if __name__ == '__main__:

    main()

That's the Python entry point, for scripts ran from the command line.

In Pelix, you'll need an activator:

from pelix.constants import BundleActivator

# Pelix activator => ran when starting and stopping the bundle
@BundleActivator
class Activator:
  def start(self, context):
    print("Bundle started")
  def stop(self, context):
    print("Bundle stopped")

# Python activator => ran when executed as a script
if __name__ == '__main__':
  print("Started")
  main()
 
The Pelix shell console has a main method that creates the Pelix framework and installs its component factories.

Simple applications I had no issue but this module has threads in it and external dependencies or modules that it imports to run. Any ideas?

You should use the start() and stop() methods of the activator to start and stop/join the threads to follow the lifecycle of the bundle.
 

I have multiple versions of python installed. so when I launch pelix.shell i issue

python2.7 -m pelix.shell 

When start() is invoked will Pelix use Python2.7 or does it use the default python in the default path? Is there a way to tell pelix to use python2.7? What I want to avoid is creating any symbolic links or changing the pythonpath because that will break everything else in the linux distro that depends on that version of python. I am just guessing this is the issue by the way.

Pelix runs in a single interpreter, which is the one it is loaded with.
So if you run Pelix in Python 2.7, all its modules will be loaded in this interpreter.
 

Thank you for any help!

Cheeres,
Thomas
 

Cheers,

Freemon

 

[Freemon Johnson]

Thank you very much Thomas! I have been using the sample applications until now and I completely forgot about the decorator when I moved away from my unit testing.

Since my program runs in an infinite while loop e.g. server I never receive back the Pelix shell prompt. I noticed that one of your variables in your pseudo code passed in a "context" variable. Is this a variable that needs to be defined in order to give context back to the Pelix shell? Presently it remains in the context of my app only when started indefinitely. I was under the impression that Pelix spawned the bundles into a process thread it oversees.

Thanks,

Freemon

[Freemon Johnson]

Thomas I am assuming you were referring to this with regards to context for main_pelix_launcher.py:

https://ipopo.coderxpress.net/wiki/doku.php?id=ipopo:tutorials:ipopo_10min

The above allows you to run the Pelix framework and the python module at once. I was trying to install the module then start it upon launching pelix shell. Sorry for not including that prior. I may have to end up following this anyway depending on your response.

Regards,

Freemon

[Freemon Johnson]

My apologies Thomas  for not including this in my last post but does the Activator function start() has to exit before the pelix.shell changes the state from STARTING to ACTIVE? No exceptions were thrown in start() as well. My start function has an infinite loop and the upon using your post and following the main_pelix_launcher.py I do have access to the pelix.shell but the State never transitions to ACTIVE.

I still would like to know also how to install and start the module within pelix.shell as well if possible.

Regards,

Freemon

[Thomas Calmant]

Hi Freemon,

The start() must return as soon as possible, as the framework is locked waiting for the bundle to initialize.

This ensures that two bundles can't start in different threads, avoiding multiple concurrency risks.

If the start() tasks needs a long time to run, or even are blocking, they should be executed in a new thread, started in the start() method and possibly stopped/joined in the stop() method.

In fact, this is a standard behavior in OSGi applications.

If you require to run the code in the main thread (like a UI thread), you should take a look at the "loopers" in the Cohorte project ([1] and [2]).

It starts a loop [1] waiting for tasks to run in the main thread while starting the framework in a new thread [2].

Else, you simply have to create a thread in the start() method and return immediately.

[1] https://github.com/isandlaTech/cohorte-runtime/blob/master/python/cohorte/boot/looper/qt.py
[2] https://github.com/isandlaTech/cohorte-runtime/blob/master/python/cohorte/boot/boot.py#L155-L185

Cheers,

Thomas

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "ipopo-dev".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse ipopo-dev+...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.