Currently i am using the custom creation strategy:
http://paste.eientei.org/show/67/
as in:
@Provides(strategy =
"org.eientei.jshbot.bundles.protocols.console.NewThreadStrategy")
for my org.eientei...protocols.console-threaded class.
If you know any better solutions for this problem, please let me know.
Thanks.
On 2013-03-09 22:07, Alexander Tumin wrote:
Hello, i have an OSGi system driven by iPOJO which has (for sake of
simplicity, let's assume that only) two bundles besides the Framework
Bundle id 0:
* org.eientei.jshbot.bundles.services.dispatcher --- which provides a
Dispatcher interface implementation
* org.eientei.jshbot.bundles.protocols.console --- which @Requires
Dispatcher implementation in order to send nifty messages over the
whole system.
The problem here that org.eientei...protocols.console is a Thread and
it's starting tied to @Valiadte and stopping to @Invalidate, so it
has
to be either re-created (the whole new object instance) after
@Invalidate/@PostUnregistration and before
@Validate/@PostRegistration
or managed somehow more cleverly then simply having
request-stop-termination method tied to @Invalidate/@Postregistration
callback.
Otherwise whenever dispatcher is re-staring -- console is simply
suspending to @Invalidate/@PostUnregistration, but not getting
re-created (unlike if console where re-started directly) and thus -
having Thread's IllegalStateException's due to start()ing a thread
after Thread's run() returned (because
@Invalidate/@PostUnregistration
callbacks already triggered that return).
Please, guide me: how to correctly fix this situation?
Is there a way to mark a class as re-new-able after @Invalidate?
Or is there any more suitable callback then
@Invalidate/@PostUnregistration to execute Thread's stopping at?
Or maybe some other way i just couldn't have thought of?
Thank you
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
