Monday, April 20, 2009

gdm vs xdm surprise on my Ubuntu 8.04.1 x86_64 machine.

While looking at some cleanup in Synaptic package manger for unused packages I thought of seeing what difference it would make to GNOME if I use xdm instead of gdm. Well
1. I saw not so nice startup text display (I am fine with it though)
2. I saw fine black and white mesh screen which is awfully painful for graphical login with thick text box for entering login/password. (I even managed to stand this one)
3. Login was much swift than previous into GNOME. (so it was worth the switch for now)/
4. I could see all the menus icons taskbar etc. so it's good sign.
5. Only thing I missed was shutdown option in GNOME System->Quit (or from the quit button).

The biggest surprise was without anything running I would normally see most of my 4 GB RAM was always in use with GDM which is now drop down to around 700-900Mb even now with Thunderbird, pidgin, firefox on it is at 1.1GB I think to me this is big improvement. (there may some others limitations but for now I thik I will see how it works for me). I past I always saw my system eating away into the 6 GB swap without running much of the applications.

I think I will also try another not so heavy window managers like Enlightenment etc.

The part of inspiration to think about it is DIY I am doing with my homemade Digital Picture Frame out of P-II for which I am trying various linux options after staring the project 2 years back and shelved it with initial success with Windows.

I wish to get more than a digital picture frame out of the DIY possibly low-end media player controllable via remote using lirc. (sounds too ambitious but will give it a go)

Friday, April 10, 2009

Quick and short post on jmxrmi exception in FUSE HQ.

If you even see following exception when using FUSE HQ or Hyperic HQ it is most likely an issue with what JDK/JRE you (or rather HQ) is using. The problem occurred while collecting statistics from FUSE ESB (Servicemix) and FUSE Message Broker (ActiveMQ).

Here is the exception:

org.hyperic.hq.product.PluginException: javax.naming.NameNotFoundException: jmxrmi
at org.hyperic.hq.product.jmx.MxServerDetector.discoverServices(
at org.hyperic.hq.product.ServerDetector.discoverResources(
at org.hyperic.hq.autoinventory.agent.server.RuntimeAutodiscoverer.doRuntimeScan_internal(
at org.hyperic.hq.autoinventory.agent.server.RuntimeAutodiscoverer.doRuntimeScan(
at org.hyperic.hq.autoinventory.ScanManager.mainRunLoop(
at org.hyperic.hq.autoinventory.ScanManager.access$000(
at org.hyperic.hq.autoinventory.ScanManager$
Caused by: javax.naming.NameNotFoundException: jmxrmi
at mx4j.remote.resolver.rmi.Resolver.lookupStubInJNDI(
at mx4j.remote.resolver.rmi.Resolver.lookupRMIServerStub(
at mx4j.remote.resolver.rmi.Resolver.lookupClient(
at org.hyperic.hq.product.jmx.MxUtil.getMBeanConnector(
at org.hyperic.hq.product.jmx.MxServerDetector.discoverServices(

The cause in my case:
FUSE HQ agent was using JRE 1.4 bundled with it which was causing the problem.
Why : There are some incompatibilities in JMX stuff when it comes to using the same code with JDK 1.4 and JDK 1.5 and apparently moving to JDK/JRE 1.5 got rid of this problem.
I don't know much about JMX so don't know what all incompatibilities are between tow of them. Anyone who reads (in first place) and knows the differences and could comment on this post it would help everyone.

Tuesday, April 7, 2009

Accessing archetype while using nexus repository manager as proxy

I was trying to use Eclipse with m2eclipse for creating some FUSE ESB project from the archetypes and was getting strange error :

"Unable to create project from archetype [org.apache.servicemix.tooling:servicemix-bean-service-unit: -> null]
> The desired archetype does not exist (org.apache.servicemix.tooling:servicemix-bean-service-unit:"

After drilling down more and looking into it I found the problem was :
1. I did configured the nexus index catalog correctly.
2. However, I later realized that I am using Nexus repository manager which doesn't automatically download the catalog itself and so it is not getting all the requited information to download the correct artifacts.

The way I fixed this for now is manually downloading the archetype-catalog.xml via my Nexus repository instance like this:

wget http://my-nexus-proxy:8081/nexus/content/repositories/open.iona.m2/archetype-catalog.xml

once the catalog was available locally at my nexus repository I then used the Eclipse m2eclipse plugin in usual manner and it went and download required archetype plugins from the remote repository into my nexus instance.

I really would like to see some option in Nexus which would allow synchronization of such artifacts which are not downloaded normally by maven dependency. Some way of scheduling such stuff (I know we can schedule the task but some smart scheduling for such category of artifacts).

For now manual downloading and sync is the way to get around the problem.

Wednesday, March 25, 2009

Nexus Revisited after long time.

After long time and not to say with after giving up my thought of setting up nexus/artifactory/archiva I came back to same stuff recently around month back.

I restarted my exercise with nexus 1.2.1 and to my surprise with very little efforts I manage to get it up and running for Apache projects I care about which are CXF, Servicemix.

I also upgraded our team nexus repository manager from older version to 1.3.1 and happily using it now. It is lot more improved than I thought it would have been. In past I was very much annoyed when my pom files got corrupt for the artifacts that were present in more than one repositories I had configured but it appears to have been fixed now and also the web interface for configuration is very helpful.

Having said all this I did spent some time today in figuring out why the artifact present in remote repository won't download even though I had it configured it correctly. After a lot of head scratching and looking at the configuration multiple times discovered that there is a parameter on each repository you configure called Not Found Cache TTL which by default was set to 1440 Minute once I changed it to smaller amount like 2 minutes my build went ahead happily.

I am overall very happy with the new Nexus Repository Manager (surely much better experience than I had with proximity and old nexus version).

SOAP RPC/Encoded and style related articles

I recently looking for more information on RPC/encoded style came across two old but very good and simple articles so thought of bookmarking here via my Blog.


I have referenced the second one many times. It is very simple and handy to understand different between different SOAP message types.