[
https://issues.apache.org/jira/browse/KARAF-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147706#comment-13147706
]
Guillaume Nodet commented on KARAF-713:
---------------------------------------
The startup mechanism is that the start level is set to 1, initial bundles are
installed, then the lock thread starts. When the lock is grabbed, the start
level is moved to 100 (usually).
In your patch, the start up level was set to 100, then later to 1 and then
again to 100 for some reason, which casused the framework to kinda stop and
restart and leading to various problems (but those aren't alwasy reproductible
because it's a timing issue). Also your patch did break the startup when no
lock was specified.
That's the two main things I saw today, but I'm kinda reluctant to completely
refactor the class. Cleaning things by extracing utility methods would
certainly help though.
> Refactor karaf main
> -------------------
>
> Key: KARAF-713
> URL: https://issues.apache.org/jira/browse/KARAF-713
> Project: Karaf
> Issue Type: Improvement
> Components: karaf-core
> Affects Versions: 2.2.2, 3.0.0
> Reporter: Christian Schneider
> Assignee: Guillaume Nodet
> Fix For: 3.0.0
>
>
> The karaf main project is currently not so well structured.
> The class Main has too many responsibilities and is too big (almost 1500
> lines).
> The lock classes are in the main package. They should be moved to a separate
> package.
> Proposal:
> create package lock and put everything about locking there. The case without
> locking should be handled as another lock implementation
> Split the Main class into setup of the framework and LifeCycleManager that
> handles the lock / start and stopping
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
