Saturday, May 24, 2008

» Embedded Jetty + WicketFilter - web.xml

I searched quite a bit on lazyweb but couldn't find anything conclusive so.. for posterity, here is how to start an embedded Jetty (a lightweight Java Servlet container/webserver) without any XML, add <init-param/> values without XML (Wicket's WicketFilter requires a applicationClassName init-param that contains the fully qualified class name of your WebApplication) and with Wicket:
import org.apache.wicket.protocol.http.ContextParamWebApplicationFactory;
import org.apache.wicket.protocol.http.WicketFilter;
import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.nio.SelectChannelConnector;
import org.mortbay.jetty.servlet.Context;
import org.mortbay.jetty.servlet.DefaultServlet;
import org.mortbay.jetty.servlet.FilterHolder;

public class EmbeddedJettyWithWicket {
   // change these accordingly:
   private static final String LISTEN_HOST = "localhost";
   private static final int LISTEN_PORT = 8888;
   private static final String WICKET_WEBAPP_CLASS_NAME =
      MyWebApp.class.getName();

   public static final void main(String[] argsthrows Exception {
      Server server = new Server();
      SelectChannelConnector connector = new SelectChannelConnector();
      connector.setHost(LISTEN_HOST);
      connector.setPort(LISTEN_PORT);
      server.setConnectors(new Connector[] { connector });
      Context root = new Context(server, "/", Context.SESSIONS);
      root.addServlet(DefaultServlet.class, "/*");
      FilterHolder filterHolder = new FilterHolder(WicketFilter.class);
      filterHolder.setInitParameter(ContextParamWebApplicationFactory.APP_CLASS_PARAM,
                                    WICKET_WEBAPP_CLASS_NAME);
      root.addFilter(filterHolder, "/*"1);
      server.start();
      server.join();
   }
}
Java2html
UPDATE: replaced with code that actually works

Labels: , ,

Friday, May 16, 2008

» smplayer

smplayer 0.6.0 has been released. If you haven't used it yet, it is a very nice and comprehensive graphical frontend for the almighty mplayer that (now) uses the Qt4 toolkit. It just got out of a pretty long development branch plus several betas and now seems to be ready for mass consumption (at least, that version works nicely on my desktops (10.2+10.3), haven't noticed any issues yet). The package of the old major release has been renamed to smplayer-old and the new 0.6.0 branch from smplayer-beta to smplayer. Note that kmplayer is another nice mplayer frontend that perfectly integrates into konqueror. Screenshots: smplayer | kmplayer

Labels:

» Re: Ubuntu's Pipe Dream: True Free Software Syncronicity

As Sean Michael Kerner puts it on his blog, Mark Shuttleworth's "The Art of Release".. erm... "vision"/wish/dream/strategy is nether a good nor a realistic thing. Shuttleworth's "vision" just won't work. You can't force 10-20 big upstream projects (KDE, GNOME, kernel, OpenOffice.org, Firefox, GCC, etc...) to sync their release schedule. And you wouldn't want to do that either. One of the reasons why FOSS is usually better in terms of quality is that releases, focus and features are typically driven by quality, by developers, not by marketing and competitors. Things are released when they're ready, when the maintainer thinks it's good enough. Having a synched release plan for many large and complex projects means a huge burden on upstream. I can't imagine Mark Shuttleworth could be that clueless about the reality of software development and how the whole ecosystem around a distribution actually works. He isn't. Can't be. So what agenda is he having/endorsing when he pushes that idea so loudly (arguably, even when he whispers, it does make a lot of noise ;)) ? I don't know. Except, maybe, because Canonical doesn't have much developers working directly on upstream projects that aren't 100% Ubuntu specific (at least compared to Fedora and openSUSE) and hence they're not really in a position to push for certain things to be fixed before others. Well, just thinking out loud, maybe there's no hidden motivation behind it at all. Sean wrote that he rather wished "common packaging across distributions", but:
  • PackageKit is definitely a good initiative and project, but it doesn't solve anything with regards to that as it's "merely" a frontend to different package management stacks, so it can give users of several distros the same frontends and user experience, but not access to the same packages;
  • it isn't about the package format (RPM vs deb vs whatnot), RPM and dpkg are pretty much equal in terms of features, performance, stability anyway; even if everyone was using RPM, it wouldn't help because the real problem is what dependencies packages are built against, especially their respective versions
To explain the latter: take openSUSE, Fedora and Mandriva, they're all using compatible versions of RPM. So, from a packaging format point of view, you can install an RPM package that has been built on one of those three on any of those three (say, a libfoo.rpm built on openSUSE can be installed on Fedora). Problem is, every single package (except a very, very few) has dependencies against other ones. If you take Firefox as an example, it depends on the GCC C++ runtime libs (libstdc++), gtk2, cairo, freetype, etc... Point is, distros usually don't have compatible (major) versions of those libraries so you won't be able to install openSUSE's 11.0 Firefox package on Fedora 9 because it uses much more recent versions of gtk2/cairo/freetype/GCC/... (just an example). And then you have different package naming conventions (though softened a bit by relying on file dependencies instead of package names for shared libraries). And different init scripts. And different file/directory locations. Distro A uses sysvinit, distro B uses upstart. To summarize, what Sean would like to see is even more restrictive and difficult to implement then what Mark is dreaming of -- it would pretty much boil down to having a single, unique distribution ;) Whatever your distribution of choice is, and regardless about how religious you are about it, I think we all agree that would be a terrible thing, whatever that distribution would be (including openSUSE). In order to accomplish that partially (which should be feasible in theory, certain dependencies are very stable and have a strong record on backward/forward compatibility, e.g. KDE 3), we'd first need to have everyone or at least the "big players" work together on LSB and actually implement it (Debian/Ubuntu don't, or only partly, even without considering RPM), and have LSB evolve at a much faster pace to encompass more standards. If package naming differences and init scripts incompatibilities were addressed and implemented by many distributors, it could be done for a certain amount of packages. Having major upstream projects follow strong guidelines on SONAMEs and ABI compatibility would be a lot more interesting than synching release cycles. But, again, it has a high cost on upstream development, is very complex to accomplish, and clearly takes a lot of fun, drive and "innovation" out of FOSS development. Not sure we'd want that either. I certainly don't. I'd already be really happy if all upstream projects written in C or C++ would know how to properly handle SONAME, bumping the major version number when ABI incompatibilities arise, in order to package and install several major versions of libraries side-by-side (a train openSUSE arguably catched quite late but works for most library packages nowadays). As said, it isn't trivial though, assessing and verifying ABI compatibility through regression tests isn't always that easy -- at least not as easy as with Clirr and/or JDiff when using Java.

Labels: ,