After a user resets a password, I want to force the user to change the password before she gets access to secured content. This is usually done with a servlet filter. But with Spring MVC, you can also use a HandlerInterceptor . According to Spring JavaDoc: HandlerInterceptor is basically similar to a Servlet 2.3 Filter, but in contrast to the latter it just allows custom pre-processing with the option of prohibiting the execution of the handler itself, and custom post-processing. Filters are more powerful, for example they allow for exchanging the request and response objects that are handed down the chain. Note that a filter gets configured in web.xml, a HandlerInterceptor in the application context. As a basic guideline, fine-grained handler-related preprocessing tasks are candidates...

These bean types are essential for the Spring MVC framework. I copied them here from the Spring Documentation for quick reference. Bean type Explanation HandlerMapping Maps incoming requests to handlers and a list of pre- and post-processors (handler interceptors) based on some criteria the details of which vary by HandlerMapping implementation. The most popular implementation supports annotated controllers but other implementations exists as well. HandlerAdapter Helps the DispatcherServlet to invoke a handler mapped to a request regardless of the handler is actually invoked. For example, invoking an annotated controller requires resolving various annotations. Thus the main purpose of a HandlerAdapter is to shield the DispatcherServlet from such details. HandlerExceptionResolver Maps exceptions to views also allowing for more complex exception handling code. ViewResolver Resolves logical String-based...

This is a series of notes on building custom JSF 2.0 facelet taglibs, ordered from the simplest to the less simple. Hopefully it can help you to get started on how to build custom taglibs for JSF. A simple JSF facelets taglib example The simplest taglib I can think of. Using EL expression with a custom tag Make tag attributes dynamic. Mixing custom tag with facelet ui taglibs Discover things you might run into when you get into more details. Which EL context to use? Using the wrong EL context can lead to subtle bugs. JSF facelet taglib backed by a UI component A UIComponent can be a tag handler, without being TagHandler . Using tag handler, UI component and renderer with a JSF facelet...

Syntax highlighted XML schema for JSF 2.0 Application Configuration Resource File ( faces-config.xml ). Almost 3000 lines! <?xml version="1.0" encoding="UTF-8"?> <xsd:sch...

Usually network connectivity can be tested with ping and telnet . Android adb shell has ping but no telnet . But it has nc , which can be used in place of telnet . # nc -z -v www.google.com 80 DNS fwd/rev mismat...

The Android unit test framework is based on JUnit 3 , not JUnit 4. Test cases have to extend junit.framework.TestCase or a subclass (such as android.test.InstrumentationTestCase ). Tests are identified by public methods whose name starts with test , not methods annotated with @Test (as in JUnit 4). An Android test suite is packaged as an APK, just like the application being tested. To create a test package, first you need to identify the application package it is testing. Google suggests to put the test package source in a directory named tests/ alongside the src/ directory of the main application. At runtime, Android instrumentation loads both the test package and the application under test into the same process. Therefore, the tests can invoke methods on...

I just installed Ubuntu 11.04 desktop on my old Dell laptop, but the cdrom is not auto-mounting. Normally this simply works. I tried various things like adding cdrom to /etc/fstab and installing halevt (which failed), none worked. However, I found out that despite talks of using gnome-volume-manager etc, at least for this version of Ubuntu automount is managed by Nautilus (file manager): start gconf-editor and navigate to /apps/nautilus/preferences/ , media_automount should be checked (but it's checked by default, unless you changed it). In the end, I wasn't able to make cdrom automount, although USB drives automounted fine. Instead of wasting more time to diagnose the problem, I manually mounted the cdrom drive: $ sudo mount /dev/cdrom /cdrom

This is a list of built-in Android permission values: Permission Description Since API Level android.permission.ACCESS_CHECKIN_PROPERTIES Allows read/write access to the "properties" table in the checkin database, to change values that get uploaded. 1 android.permission.ACCESS_COARSE_LOCATION Allows an application to access coarse (e.g., Cell-ID, WiFi) location 1 android.permission.ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location 1 android.permission.ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location provider commands 1 android.permission.ACCESS_MOCK_LOCATION Allows an application to create mock location providers for testing 1 android.permission.ACCESS_NETWORK_STATE Allows applications to access information about networks 1 android.permission.ACCESS_SURFACE_FLINGER Allows an application to use SurfaceFlinger's low level features 1 android.permission.ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks 1 android.permission.ACCOUNT_MANAGER Allows applications to call into AccountAuthenticators. Only the system can get this permission. 5 android.permission.AUTHENTICATE_ACCOUNTS...

In Android.mk , you can define LOCAL_JARJAR_RULES like this: LOCAL_JARJAR_RULES := $(LOCAL_PATH)/jarjar-rules.t... and in jarjar-rules.txt define a rule like this: rule org.bouncycastle.** com.android.@0 The build will change all org.bouncycastle to com.android.org.bouncycastle . Therefore, in your classes which are dependent on the library produced, the import statements should look like: import com.android.org.bouncycastle... Help for the jarjar utility (in prebuilt/common/jarjar/ ): $ java -jar jarjar-1.0rc8.jar Jar Jar Links - ...

By Android documentation , odex files are "Optimized DEX" files, which can be created in at least three different ways: The VM does it "just in time". The output goes into a special dalvik-cache directory. This works on the desktop and engineering-only device builds where the permissions on the dalvik-cache directory are not restricted. On production devices, this is not allowed. The system installer does it when an application is first added. It has the privileges required to write to dalvik-cache . The build system does it ahead of time. The relevant jar / apk files are present, but the classes.dex is stripped out. The optimized DEX is stored next to the original zip archive, not in dalvik-cache , and is part of the system...