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...

Step 1: Repackage a web app as EAR A Java EE application is a multimodule Maven project. At the very least you'll need to package a WAR and an EAR. To get started, I'll simply re-package the simple webapp as an EAR. Create a directory named javaee-app Copy the webapp from here to javaee-app . Rename struts1app to webapp . Create pom.xml under javaee-app : <project> <modelVersion>4.0.0</modelVersion>... Create a directory named ear under javaee-app . Create pom.xml under ear : <project> <modelVersion>4.0.0</modelVersion>... Modify pom.xml in the webapp directory so that it looks like this: <project> <modelVersion>4.0.0</modelVersion> ... Build with " mvn package " in the javaee-app directory. You can see that ear-1.0.ear is successfully generated in javaee-app/ear/target . Maven successfully resolves dependencies between the sub-projects....

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...

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...

This is an example that uses dynamic proxies to trace method calls (in logging) and print out elapsed times for them. Because dynamic proxies can only be generated for interfaces, the service classes must be implemented with interface-implementation pairs. Create services A and B. A.java : public interface A { public void service1()... AImpl.java : import java.util.Random; public class AImpl... B.java : public interface B { public void service1()... BImpl.java : public class BImpl implements B { public vo... The call trace proxy: import java.lang.reflect.*; class TraceProx... The performance proxy: import java.lang.reflect.*; class Performan... The service factory: import java.lang.reflect.*; public class Se... The test class: public class Test { public static void main... The output: Entering AImpl.service1 Entering BImpl.service1... The above example has no information...

Thread local storage is typically used to associate state with a thread (e.g., a user ID or Transaction ID). This example, coming from Java API doc , assigns a unique id to each thread that calls getCurrentThreadId() . The actual usage is demonstrated with the Java concurrency package. import java.util.concurrent.Future; import java...

android:sharedUserId (from Android doc): The name of a Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID. However, if this attribute is set to the same value for two or more applications, they will all share the same ID — provided that they are also signed by the same certificate. Application with the same user ID can access each other's data and, if desired, run in the same process. Declare sharedUserId in AndroidManifest.xml : <manifest xmlns:android="http://schemas.android.co... Retrieve sharedUserId programmatically: import android.content.pm.PackageManager; impor...

This is a common problem with shell scripts running from cron. Everything works perfectly fine from the command prompt, but fails when running from cron. In the worst cases, the job fails silently, even giving a return code of 0! Usually, these are caused by differences between the execution environments: the interactive shell (command line) has more environment variables defined/exported (through .kshrc , .bashrc etc.) than the shell started by cron. A simple way to resolve the differences is to run set in the command prompt and compare the output with the output of set from cron (add a single line to the shell script). You can also make the shell script more verbose by adding the -x switch: #!/bin/sh -x

These are the steps to create a JBoss 5.1.0 configuration with Tomcat from the built-in minimal configuration. Change directory to $JBOSS_HOME/server . Make a copy of the minimal configuration. cp -R minimal tomcatonly Copy bindingservice.beans from the default configuration. cp -R default/conf/bindingservice.beans tomcatonly... Copy login-config.xml from the default configuration. cp default/conf/login-config.xml tomcatonly/conf/ Edit tomcatonly/conf/jboss-service.xml : Add jars from the common/lib directory: <!-- Load all jars from the JBOSS_DIST/serv... Add the JAAS security manager section (copy from the default profile, and yes, JBoss tomcat can't live without the JBoss JAAS manager). <!-- JAAS security manager and realm mappin... Copy the Tomcat (JBoss web) deployer from the default configuration. cp -R default/deployers/jbossweb.deployer tomcaton... Copy metadata-deployer-jboss-beans.xml and security-deployer-jboss-beans.xml from the default profile. cp default/deployers/metadata-deployer-jboss-b... Copy...

Start remote desktop client by clicking Start and Run, then enter mstsc. Click the "Options" button, select the "Local Resources" tab, check "Clipboard" More options are available when you click the "More..." button (share local drives etc.).