Switching ubuntu boot from graphics to text mode.

This one has always puzzled me and make me go round and round few times now on all my new VM's, so I decided to note down what I did this time.

To Change the Graphic boot to Text mode on startup all you need to do is modify your /etc/init/.cfg file.

In my case I was trying to do this with gdm.cfg based on many google results however, I missed a crucial point that I had selected another Display Manager lightdm. After trying few things I finally realized the mistake. So here is the snippet from /etc/init/lightdm.cfg (This should be same for gdm as well in gdm.cfg):

start on ((filesystem
           and runlevel [!026]
           and started dbus
           and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                or stopped udev-fallback-graphics))
          or runlevel PREVLEVEL=S)

stop on runlevel [016]

You can change the runlevel in

stop on runlevel [016]

but I didn't find it necessary, just changing it in start on section did the job.

Locking down JMX naming now easier with Camel 2.10

A very useful Article by Claus on controlling JMX Naming for Camel artifacts (routes/processors etc.)

Claus Ibsen (@davsclaus) riding the Apache Camel: Locking down JMX naming now easier with Camel 2.10

Quick Note on How to remove/change /cxf from context path of CXF OSGi service.

By Default, when a CXF servlet endpoint is deployed in Servicemix OSGi container the context path for the endpoint address contains "/cxf".
This causes resulting endpoint URL being something like http://localhost:9090/cxf/myservice . This is not always a desirable URL and many times needed to change to more generic (technology neutral) URL for publishing the endpoint.

This default context can be changed in one of the two ways as follows:

1. It can be changed by adding org.apache.cxf.servlet.context=/myservice to etc/org.apache.cxf.osgi.cfg.

2. By running following commands to alter configuration in container using configuration management service in Servicemix container.

       config:edit org.apache.cxf.osgi

       config:propset org.apache.cxf.servlet.context /myservice

       config:update

ActiveMQ prefetch and Spring DMLC advice from Torsten

A piece of advice on ActiveMQ prefetch and Spring DMLC from my colleague Torsten.


I just remembered a lesson learned about prefetch and Spring DMLC:
If you configure DMLC to use CACHE_SESSION or below (i.e. CACHE_CONNECTION or CACHE_NONE) *and* when you don't use a CachingConnectionFactory (e.g SingleConnectionFactory), then you should set the prefetch for the Spring consumer to only 1 or 0.
That is because when not caching the consumer, a new JMS consumer is recreated for every msg that Spring will ask the broker for.
And if there are many msgs on the queue, the broker will prefetch e.g. 1000 msgs to the consumer although the consumer will only process one msg.
Spring DMLC then recycles the JMS consumer with 999 unprocessed msgs. This obviously causes to much and unnecessary load on the network.

So possible solutions in this case:
1) prefetch=0 or 1,
2) configure DMLC to use CACHE_CONSUMER, or
3) use Springs CachingConnectionFactory

Short Note on How to install Servicemix 4 as windows service.

To install Servicemix 4 as windows service need to start SMX from console and run features:install wrapper and wrapper:install and follow the instructions that are displayed by second karaf command.

Here is the output from a sample run :

karaf@root> features:install wrapper
karaf@root> wrapper:install
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-wrapper.exe
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\etc\karaf-wrapper.conf

Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-service.bat
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\lib\wrapper.dll
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\lib\karaf-wrapper.jar
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\lib\karaf-wrapper-main
.jar

Setup complete. You may want to tweak the JVM properties in the wrapper configu
ration file:
C:\work\apache-servicemix-4.4.1-fuse-01-06\etc\karaf-wrapper.conf
before installing and starting the service.


To install the service, run:
C:> C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-service.bat install

Once installed, to start the service run:
C:> net start "karaf"

Once running, to stop the service run:
C:> net stop "karaf"

Once stopped, to remove the installed the service run:
C:> C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-service.bat remove

Hope this helps and serves as note to myself for future.

Test post from Android phone.

Test post.

Enabling JMX monitoring in Servicemix for pax-web jetty instance.

In Servicemix 4.x OSGi HTTP service is provided using pax-web. By default, it doesn't expose MBean for underlying Jetty instance running inside pax-web.

To enable monitoring this jetty instance you need to use fragment bundle that would connect underlying jetty to Servicemix MBeanServer using additional jetty configuration.

Here are steps to do this:

1. Create a OSGi Fragment-Bundle which will attach to pax-web-jetty OSGi service. Bundle Fragment project pom.xml contains following:

<project xmlns="http://maven.apache.org/POM/4.0.0"
             xsi="http://www.w3.org/2001/XMLSchema-instance"
         schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
             <modelversion>4.0.0</modelversion>
             <groupid>org.ops4j.pax.web</groupid>
             <artifactid>config-jetty-jmx</artifactid>
             <version>1.0.0-SNAPSHOT</version>
             <packaging>bundle</packaging>
             <name>OPS4J Pax Web - Configuring Jetty JMX connection</name>
             <properties>
                  <bundle.symbolicname>org.ops4j.pax.web.config-jetty-jmx</bundle.symbolicname>
             </properties>
             <build>
                <plugins>  
                   <plugin>    
                         <groupid>org.apache.felix</groupid>   
                         <artifactid>maven-bundle-plugin</artifactid>    
                         <version>2.2.0</version>    
                         <extensions>true</extensions>   
                         <executions>        
                             <execution>         
                                <id>bundle-manifest</id>         
                                <phase>process-classes</phase>          
                                <goals>            
                                   <goal>manifest</goal>          
                                </goals>        
                             </execution>      
                         </executions>    
                     <configuration>        
                         <instructions>          
                             <bundle-symbolicname>${bundle.symbolicName}</bundle-symbolicname>
                             <bundle-version>${pom.version}</bundle-version>                      
                             <fragment-host>org.ops4j.pax.web.pax-web-jetty</fragment-host>        
                         </instructions>   
                     </configuration>  
                 </plugin>
             </plugins>
         </build>
</project>

2. This bundle (Fragment) would have additional Jetty configuration xml file jetty.xml which would (reside in src/main/resources folder) look like this:

<configure class="org.mortbay.jetty.Server">
<call id="jettyMBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer">

<!-- =========================================================== -->
<!-- Initialize the Jetty MBean container                        -->
<!-- =========================================================== -->
<get id="Container" name="container">
<call name="addEventListener">
<arg>
  <new class="org.mortbay.management.MBeanContainer">
    <arg><ref id="jettyMBeanServer"></ref>
    <call name="start">
    </call>
   </arg>
</new>
</arg>

</call>

3. Once the fragment bundle is built install it in Servicemix instance which is not currently running pax-web OSGi services. (I used Servicemix instance with minimal bundles only config feature was installed) I installed it using osgi:install file:///.... or something like osgi:install mvn:org.ops4j.pax.web/config-jetty-jmx where the groupId for my Fragment bundle project was org.ops4j.pax.web and artifactId config-jetty-jmx.

4. Once this is installed you can install pax-web. I deployed war feature which installs and starts pax-web feature.

5. At this stage your Fragment bundle would get attached to pax-web-jetty Host Bundle and enable JMX monitoring. To confirm this if you run osgi:list you should see something like (Note Fragment and Host entries):

[33] [Resolved ] [ ] [ 60] OPS4J Pax Web - Configuring Jetty JMX connection (1.0.0.SNAPSHOT)
Hosts: 39
[ 34] [Active ] [ ] [ 60] geronimo-servlet_2.5_spec (1.1.2)
[ 35] [Active ] [ ] [ 60] Apache ServiceMix :: Bundles :: jetty (6.1.26.1-fuse)
[ 36] [Active ] [ ] [ 60] OPS4J Pax Web - API (0.7.3)
[ 37] [Active ] [ ] [ 60] OPS4J Pax Web - Service SPI (0.7.3)
[ 38] [Active ] [ ] [ 60] OPS4J Pax Web - Runtime (0.7.3)
[ 39] [Active ] [ ] [ 60] OPS4J Pax Web - Jetty (0.7.3)
Fragments: 33
[ 40] [Active ] [ ] [ 60] OPS4J Pax Web - Jsp Support (0.7.3)
[ 41] [Active ] [ ] [ 60] OPS4J Pax Web - Extender - WAR (0.7.3)
[ 42] [Active ] [ ] [ 60] OPS4J Pax Web - Extender - Whiteboard (0.7.3)
[ 43] [Active ] [ ] [ 60] OPS4J Pax Url - war:, war-i: (1.1.3)
[ 44] [Active ] [Created ] [ 60] Apache Karaf :: WAR Deployer (2.0.0.fuse-02-00)

6. At this stage if you start JConsole and look connect to running Servicemix instance you should be able to see following MBeans appearing in MBeans tab:
a. org.mortbay.jetty.servlet
b. org.mortbay.thread
c. org.ops4j.pax.web.service.jetty.internal

I did see some InstanceAlreadyExists exceptions in Servicemix instance but wasn't able to resolve them quickly so just left there since in my opinion they are harmless.

I hope this helps anyone who wants to configure internal Jetty instance run by pax-web in Servicemix/Karaf.