JConsole in local mode and tomcat

After some debugging found that Jconsole will connect locally to a new MBeanServer created via ManagementFactory.getPlatformMBeanServer(). Tomcat will look for an existing MBeanServer and create one if needed - but this will be different than what jconsole uses.

The fix is 2 lines - benefit is that you can start tomcat normally, without any special flag, then connect with jconsole and inspect/modify settings. It looks like they use some signal or other form of communication on Linux, which opens a TCP port.

I'm not sure why someone would ever want to use MBeanServerFactory.findMBeanServer() and createMBeanServer. Sure, in the rarely used sandbox mode, if you want to strongly isolate apps it may be needed - assuming you want each untrusted app to have access to its own server, and grant it create mbean server rights.

Time to send a patch - long time since I haven't done that...

OFX download for vanguard

I've been using ofx.py to get my transactions from Vanguard, it stopped working sometimes this month. I have some code to parse and merge the sort-of-xml responses to an .xls file - which for me works much better than any alternative I tried. Moneydance is close, it provides an API that can be used to extract same data and it's a bit easier to setup, but it does some magic and seem to be less stable. Quicken, Money - never found a way to get my data back, and won't work on linux too well.

Made few changes to get it working again, first the setup is:

               "caps": [ "SIGNON", "INVSTMT" ],
               "fiorg": "vanguard.com", 
               "url": "https://vesnc.vanguard.com/us/OfxDirectConnectServlet"

The main change besides url is the code to get the transactions, urllib2 seems to default to HTTP/1.0, couldn't find a way to force it to 1.1 so I changed the code to use httplib directly:

            garbage, path = urllib2.splittype(self.config["url"])
            host, selector = urllib2.splithost(path)
            h = httplib.HTTPSConnection(host)
            h.request('POST', selector, query, 
                      { "Content-type": "application/x-ofx",
                        "Accept": "*/*, application/x-ofx"
                      })
            res = h.getresponse()
            response = res.read()
            res.close()

Old:

        request = urllib2.Request(self.config["url"],
                                                query,
                                               { "Content-type": "application/x-ofx",
                                                  "Accept": "*/*, application/x-ofx"
                                               })
        print "RES: ", res, " ", res.status, " ", res.reason
       f = urllib2.urlopen(request)
       response = f.read()
       f.close()

JAAS and tomcat

The JAAS ( authentication/authorization ) API has been around for many years now - the idea is to use a standard API for all authentication, and plugins to use NT, LDAP, PAM, SSO and any other realm. JAAS seems modeled after PAM - the auth API for linux ( and unix in general).

Tomcat supports JAAS auth and provides a sample LoginModule based on the simple clear-text xml file. Like most other apps using auth, tomcat also have direct modules to authenticate against DB, LDAP/JNDI, files - but it will never cover the same range of auth sources as PAM for example ( http://www.kernel.org/pub/linux/libs/pam/modules.html ).

JAAS has few big problems - it is quite complex, it lacks modules and it lacks users. A benefit of using a tomcat-specific module is that it can be better optimized for the target environment. The only reason to use it would be to use a PAM auth source, there is now a JAAS-PAM implementation http://jaas-pam.sourceforge.net/ - seems very good, LGPL, uses JNI to interface with PAM.

The default JAAS modules from Sun seem quite useless - they can authenticate the current user, not much more. The JDNI module is probably usable, but the tomcat JNDI source seems more customizable and simpler.

Another option that wraps PAM is SysAuth
(GPL2), it defines it's own simpler API, it could be wrapped in JAAS or
in a tomcat module. Due to license and the fact that jaas-pam exists -
probably not worth the effort. Another dead end is ShadowJAAS - it supports unix
user/password authentication, by parsing passwd/shadow files in a SUID
root file.

JMX names

Sun's advice http://java.sun.com/products/JavaManagement/best-practices.html

• Allways have type=
• if singleton ( or one instance per domain ) - no  other key
• otherwise: add name=
• for grouping, add group=
• j2eeType/jsr77 - they kind of agree it's a messs -  I think
• they do actually define a 'containment scheme', using type=Server.Application.WebModule,..  and  Server=, Application=, etc. Not quite JSR77 - but close enough., and it makes more sense.
• of course - an easier solution would be to just use  unix-like names name=//servername/appname/webname,

On mbeans, they advise:

• use standard MBeans - and use the interface with newProxyInstance. Not sure I agree with this one, if you want this kind of programmatic access use RMI/corba/etc if out of process, and the object directly if you are in process - you still have coupling and dependency, but no need for the JMX layer, which is not designed as RPC and is more inefficient than direct calls.
  
• advice against DynamicMBeans - instead extend StandardMBean.  I strongly disagree with this one.
• On model mbeans, the correctly mention that they are hard to use by themself. The fact that they can't have interfaces is false AFAIK, you can define the interfaces if you want and the proxy will be generated, you can construct a dynamic proxy for anything if you want to write the interface. There is a decoupling since the implementation doesn't have to implement the method, but this can happen in any case if one side changes attributes/methods. See the above point on why I think dynamic proxies for JMX are a convoluted and bad idea.
  
• recommend using OpenMbeans - good idea, and avoiding RMI-specific features like downloading classes.

As usual for any 'best practice' document - don't believe all they say, ask first what 'practice' they had and how many applications they developed or considered before finding the 'best', and how they relate to your use case.

Cleaning a firefox profile

http://robert.accettura.com/archives/2006/05/03/cleaning-a-firefox-profile/

JamVM -- A compact Java Virtual Machine

JamVM - impressive VM, runs tomcat without problems, even eclipse works. All in less than 1/2 M. Speed is decent for simple use. And it supports ARM - so I can play with java and tomcat on my toys.

Dashboard/konfabulator for Linux and firefox

Dashboard/konfabulator for Linux and firefox: "The 'killer feature' in Dashboard and konfabulator is (IMO) the ability to integrate a web-like interface with the OS. This opens the way for a lot of ideas in making Linux easier to use - for 'regular users' but also for advanced users who feel more comfortable using the browser than typing ( and remembering ) complex command lines.

The implementation for firefox of a 'system/exec' feature similar with dashboard and konfabulator is not trivial, but not that complex. As I mentioned in a previous post, the async execution is the tricky part, but it has a reasonably straight solution. I'll try to find a server and post the sources - I'm sure there are better implementations using the event queue, but it works well enough for me.
Now the remaining part is dealing with installing and running 'widgets' in firefox - and exactly emulating the interface. I'm not expecting Dashboard widgets to work unmodified, but with small changes.  Konfabulator has an simpler interface, but it's not HTML-like, I'll only see if I can implement a similar API for simpler transition.

This has been a very interesting mini-project for me - I found a lot about how firefox works, and I hope it'll serve it's purpose and I'll be able to reduce my use of CLI and have a nicer interface for the linux commands I use. Even if some already have"

A different implementation for commons-logging

Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.  It is also one of the not-so-good APIs or implementations.

The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.

An alternative - that will work better in most cases - is to write a specific commons-logging implementation for  each  backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.

The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic">A different implementation for commons-logging: "Commons logging is an API attempting to hide the differences between JDK1.4 logging, log4j and other logging implementations. The reasons it exist is simple - JDK1.4 logging failed to become a de-facto standard ( even if it is bundled and the 'official' JSR for logging ), and many people preffer log4j or other implementations for logging.  It is also one of the not-so-good APIs or implementations.

The current implementation of common-logging uses a discovery mechanism, similar with what is used by JAXP. This has caused a lot of problems to many people, in particular if multiple class loaders are used - yet it is a reasonable solution.

An alternative - that will work better in most cases - is to write a specific commons-logging implementation for  each  backend, without any discovery. That means the logging .jar file will no longer work with or discover any backend - but that's not really a problem. If someone choose a particular logging backend, all he has to do is also deploy the matching commons-logging.jar. This way all the guesses and discovery are no longer needed, and if he changes his mind and wants a different logging - all he needs is to switch both jars.

The ideal would be of course for log4j.jar to include a matching commons-logging implementation - but that won't happen for politic"

RSS for comments and ids

I got Sam's comment feed - and it imediately broke my agregator. The problem is quite simple - I use the link of the item as a key, and in the comment feed all
comments use the same key as the article. And the same title.

This changes the entire data model - for each link I'll have to store a list of MD5s, and treat it as a multi-value. The first time ( if no MD5 is found ) it'll be the "source" message, and all other occurances - including edits of the original - can be treated as "Re: " - to implement the threading in the mail reader.

Probably I'll just go for the simplest solution - and keep a .db keyed by MD5 (that should be unique enough ) - the whole idea is to avoid sending the same item multiple times.

Once again - the RSS proves to be almost completely useless.

Update: Sam changed the links. There are few problems. Some of his links are quite strange .../blog/('1247.html#c1047152121',), I suppose a small bug sneaked in.

Worse - I now lost the way to relate comments with postings. I'll have to parse the generated links and remove the ending to guess the original posting. Sam - please change back, I fixed my code to deal with the old problem and I think the workaround for the new problems is harder :-)

A better solution would be to just add a separate tag with the comment id. Of couse, that would be in the RSS-2003-03-08 "standard", and nobody else will use the same tag name. ( we should use the date of the "standard du jour")