I have yet one observation. I don't know whether this is normal behavior or not. While starting the fresh ServiceMix 5/6 the first time there is a progress bar waiting untill all bundles are installed
Please wait while Apache ServiceMix is starting... 100% [========================================================================] Karaf started in 7s. Bundle stats: 236 active, 236 total After next start we have the same result In the new ServiceMix 7 the progress bar waits (while the first start) only for the bundles defined as startup bundles Please wait while Apache ServiceMix is starting... 100% [========================================================================] Karaf started in 0s. Bundle stats: 11 active, 11 total Next waits until all other boot boot features are installed until the ServiceMix logo appears. After restart the progress bar waits for all bundles Please wait while Apache ServiceMix is starting... 100% [========================================================================] Karaf started in 3s. Bundle stats: 223 active, 223 total I have tested the same with Karaf 4.0.3 and I have observed the same behavior. Is it correct? Regards Krzysztof On 26.01.2016 23:18, Krzysztof Sobkowiak wrote: > Hi > > Like mentioned before I have created the ServiceMix assembly as a standard > assembly by defining the boot features in karaf-maven-plugin. My first try > with profiles was very unstable and I started the new try by transforming > step by step the existing ServiceMix 6 assembly. As one of the next steps I'm > going to define the profiles again and use them to define the assembly. > > Actually the assembly is built using only the 'assembly' goal of the > karaf-maven-plugin. Instead of the 'archive' goal I have used the custom > assembly definition and the assembly maven plugin. Reasons and potential > solutions to avoid usage of the assembly plugin: > > - The 'archive' goal produces 2 distributions - .zip and .tgz. We have > decided over a year ago to provide only one assembly. It's possible to > configure the karaf plugin to generate only one of the distribution - most > reasonable would be a zip file. But the unix scripts (e.g. karaf, client,...) > have not set the executable bit. *TODO*: We need a change in the 'archive' > goal to enable the executable bit for unix scripts in the generated zip file > (like in the tgz file). I'm going to raise an issue for this problem. > - We need the servicemix and servicemix.bat scripts as a copy of karaf and > karaf.bat scripts. It was easy to do with the assembly definition. *TODO*: we > need find another way to copy the renamed scripts into the assembly > - The custom assembly definition is used also to include in the assembly the > samples and Karaf demos. *TODO*: we should do this similar to the Karaf > assembly using the dependency plugin. > - The jar with the ServiceMix branding is copied into the lib directory using > the assembly definition as well. We can solve this using the dependency > plugin or by moving the branding properties from the branding jar into the > /etc directory. > > The current version seems to be almost stable. I have performed some manual > smoke tests which I usually do before releasing a new version and I have > found no problems with the new version. There are still some issues with > itests. > > - https://issues.apache.org/jira/browse/SM-2787 - is the most irritating. I > think, the problem is caused with a huge log output generated using the DEBUG > log mode. At the beginning the problem happened randomly in each CXF itest > and some other itests. I have extracted the CxfWsn itest in a separate class, > changed the log level to INFO for all other itests and DEBUG for CxfWsn and > it fixed the problem in all itests except the CxfWsn itests. The CxfWsn > itests need the DEBUG mode, otherwise the test cannot find the expected log > entry produced by Camel. The solution would be the change of the route to > produce the log entry with INFO log level or find the problem why the itests > have problems with the big log output. > - https://issues.apache.org/jira/browse/SM-2813 - it's a problem with xstream > data format. The sample feature examples-drools-camel-cxf-server depends on > camel-xstream feature, but when the both features are installed together the > sample feature has problem with accessing the xstraem data format. Adding > camel-xstream to boot features solves the problem > - You can also look at following issues > https://issues.apache.org/jira/browse/SM-2814, > https://issues.apache.org/jira/browse/SM-2823, > https://issues.apache.org/jira/browse/SM-2825 and check whether I have used a > correct solution and whether you have a better solution for the problems > > > There are still some tasks to do which I'm going to do in next days: > > - simplify the assembly creation by using the archive goal (like described > above, we need the change in Karaf plugin) > - use Karaf profiles to define the assembly > - upgrade to Camel 2.16.2 > - upgrade to ActiveMQ 5.13.0 > - test it with Java 8 (especially the ActiveMQ console) > - some other small issues > > I propose to release the M1 soon (even if some of the above tasks will not be > fixed) to let people test the distribution and find eventual new issues. > > Kindly regards > Krzysztof > > > > > On 26.01.2016 07:35, Jean-Baptiste Onofré wrote: >> Hi Krzysztof >> >> It sounds good to me. Please, push your changes, and we will review/update >> in a second step together. >> >> Thanks ! >> Regards >> JB >> >> On 01/25/2016 09:15 PM, Krzysztof Sobkowiak wrote: >>> Hi >>> >>> Sorry for my low activity last time but I had to make a small break in my >>> habitual contacts with computer and use my longer vacation to take a rest >>> ;) As a result I'd like to push today my changes for ServiceMix 7 >>> (especially the upgrade to Karaf 4). I think, it's not ideal yet and is not >>> implemented using profiles (as >>> discussed with JB), but my first try starting with profiles was very >>> unstable and I started with the standard assembly. I'm going to use >>> profiles as a next step. >>> >>> I'll write more about the current state and my observations later/tomorrow. >>> >>> Kindly regards >>> Krzysztof >>> >>> >>> -- Krzysztof Sobkowiak (@ksobkowiak) JEE & OSS Architect, Integration Architect Apache Software Foundation Member (http://apache.org/) Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/) Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
