Monday, December 30, 2013

Detect AJAX Request or PPR Request in ADF Faces

I have a need to detect if the request generated is an AJAX request or Full request. In JSF 2.0 this is easy and you can find many blog posts and forum discussions which have dealt with it. But as I am using ADF 11.1.1.6.0 which uses JSF 1.2 so none of those methods of detecting an AJAX request wouldn't work for me.

So I tried to find a way to detect if the request generated is an AJAX or not and what I found I am sharing with you. You can use any one of the following methods from your Utility class:

public static boolean isPprRequest(FacesContext context) {
 return isPprRequest(context.getExternalContext());
}

public static boolean isPprRequest(ExternalContext ec) {
 return (("true".equals(ec.getRequestHeaderMap().get("Adf-Rich-Message"))) || ("true".equals(ec.getRequestParameterMap().get("Adf-Rich-Message"))));
}

public static boolean isPprRequest(HttpServletRequest req) {
 return (("true".equals(req.getHeader("Adf-Rich-Message"))) || ("true".equals(req.getParameter("Adf-Rich-Message"))));
}

Note this is applicable for ADF 11.1.1.6.0. I haven't tested with other ADF versions.

Happy coding :-)

Saturday, December 28, 2013

WildFly: EJB invocations from a remote client

Currently I am experimenting with Java EE7 and I have chosen WildFly as my application server. So far everything is working fine, the WebService, EJB 3.2 etc until today when I tried to access my EJB from a client application - jUnit Test.
To solve the issue initially I followed the instruction given in WildFly documentation EJB invocations from a remote client using JNDI, but it is not what I needed. After spending almost half a day at last I achieved what I wanted.

Prerequisite:

  • You need to have an Application User. Follow the instruction given in Add User Utility.
  • I am running my server with the parameter -b 0.0.0.0 --server-config standalone-full.xml
  • jboss-client.jar in your classpath, which can be found inside the /bin/client directory of the server.
Following is the piece of code which you need to access the EJB:

import java.util.Properties;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

import org.jboss.ejb.client.EJBClient;
import org.jboss.ejb.client.EJBClientContext;
import org.jboss.ejb.client.PropertiesBasedEJBClientConfiguration;
import org.jboss.ejb.client.StatelessEJBLocator;
import org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector;

/**
 * Class EJBLocator is the class to connect with EJB
 * 
 * @author Tapas Bose
 * @since 1.0
 */
public class EJBLocator {

 /**
  * Method locateEJB locates an EJB for the given jndi
  * 
  * @author Tapas Bose
  * @since 1.0
  * @param jndi
  *            - the jndi to lookup
  * @return an instance of EJB
  * @throws NamingException
  */
 @SuppressWarnings("unchecked")
 public static <T> T locateEJB(String jndi) throws NamingException {
  Properties clientProperties = new Properties();
  clientProperties.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
  clientProperties.put("remote.connections", "default");
  clientProperties.put("remote.connection.default.port", myPort);
  clientProperties.put("remote.connection.default.host", myHost);
  clientProperties.put("remote.connection.default.username", myUser);
  clientProperties.put("remote.connection.default.password", myPassword);
  clientProperties.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");

  EJBClientContext.setSelector(new ConfigBasedEJBClientContextSelector(new PropertiesBasedEJBClientConfiguration(clientProperties)));

  Properties properties = new Properties();
  properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
  Context context = new InitialContext(properties);
  return (T) context.lookup(jndi);
 }

 /**
  * Method locateEJBStateless locates an Stateless EJB for the given parameters
  * 
  * @author Tapas Bose
  * @since 1.0
  * @param viewType
  *            - the view type
  * @param appName
  *            - the application name
  * @param moduleName
  *            - the module name
  * @param beanName
  *            - the bean name
  * @param distinctName
  *            - the distinct name
  * @return an instance of EJB
  */
 public static <T> T locateEJBStateless(Class<T> viewType, String appName, String moduleName, String beanName, String distinctName) {
  Properties properties = new Properties();

  properties.put("endpoint.name", "client-endpoint");
  properties.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");
  properties.put("remote.connections", "default");
  properties.put("remote.connection.default.port", myPort);
  properties.put("remote.connection.default.host", myHost);
  properties.put("remote.connection.default.username", myUser);
  properties.put("remote.connection.default.password", myPassword);
  properties.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");

  EJBClientContext.setSelector(new ConfigBasedEJBClientContextSelector(new PropertiesBasedEJBClientConfiguration(properties)));
  StatelessEJBLocator<T> locator = new StatelessEJBLocator<T>(viewType, appName, moduleName, beanName, distinctName);
  T ejb = EJBClient.createProxy(locator);
  return ejb;
 }
}

Use this class as:
YourService service = EJBLocator.locateEJB(jndi);
//where the jndi is of the form ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>
Or by:
YourServic service = EJBLocator.locateEJBStateless(YourServic.class, "appName", "moduleName", "YourServicImpl", "distinctName");
Hope it will help.

Friday, May 10, 2013

Java EE 7: Specification, Services, Key features

Java EE Standard Services
The Java EE standard services include the following. Some of these standard services are actually provided by Java SE.
  1. HTTP
  2. HTTPS
  3. Java Transaction API (JTA)
  4. RMI-IIOP
  5. Java IDL
  6. JDBC API
  7. Java Persistence API (JPA)
  8. Java Message Service (JMS)
  9. Java Naming and Directory Interface (JNDI)
  10. JavaMail
  11. JavaBeans Activation Framework (JAF)
  12. XML Processing
  13. Java EE Connector Architecture
  14. Security Services
  15. Web Services
  16. Concurrency Utilities
  17. Batch
  18. Management
  19. Deployment
Interoperability 
Many of the APIs described above provide interoperability with components that are not a part of the Java EE platform, such as external web or CORBA services.
Following figure illustrates the interoperability facilities of the Java EE platform. (The directions of the arrows indicate the client/server relationships of the components.)
Java EE Interoperability
Key features:
Summary of the key features of different specifications in the Java EE 7 platform:
  1. Java EE 7 (JSR 342):
    • The main theme is to easily run applications on private or public clouds
    • The platform will define application metadata descriptor to describe PaaS execution environment such as multi-tenancy, resources sharing, quality-of-service, and dependencies between applications
    • Embrace latest standards like HTML5, WebSocket, JSON and have a standards-based API for each one of them
    • Remove inconsistencies between Managed Beans, EJB, Servlets, JSF, CDI, and JAX-RS
    • Possible inclusion of JAX-RS 2.0 in the Web Profile, revised JMS 2.0 API
    • Technology Refresh for several existing technologies (more on this below) and possible inclusion of Concurrency Utilities for Java EE (JSR 236) and JCache (JSR 107)
    • Status
  2. JPA 2.1 (JSR 338):
    • Support for multi-tenancy
    • Support for stored procedures and vendor function
    • Update and Delete Critieria queries
    • Support for schema generation
    • Persistence Context synchronization
    • CDI injection into listeners
    • Status
  3. JAX-RS 2.0 (JSR 339):
    • Client API - low level using builder pattern and possibly a higher level on top of that
    • Hypermedia - easily create and process links associated with resources
    • Form or Query parameter validation using Bean Validation
    • Closer integration with @Inject, etc
    • Server-side asynchronous request processing
    • Server-side content negotiation using "qs"
    • Status
  4. Servlets 3.1 (JSR 340):
    • Optimize the PaaS model for Web applications
    • Multi tenancy for security, session, resources, etc.
    • Asynchronous IO based on NIO2
    • Simplfiied asynchronous Servlets
    • Utilize Java EE concurrency utilities
    • Enable support for WebSockets
    • Status:
  5. Expression Language 3.0 (JSR 341):
    • Separate ELContext into parsing and evaluation contexts
    • Customizable EL coercion rules
    • Reference static methods and members directly in EL expressions
    • Adding operators like equality, string concatenation, and sizeof etc.
    • Integration with CDI such as generating events before/during/after the expressions are evaluated
    • Status
  6. Java Message Server 2.0 (JSR 343):
    • Ease of development - changes to the JMS programming model to make the application development simpler and easier
    • Remove/Clarify ambiguities in the existing specification
    • Integration with CDI
    • Clarification of the relationship between JMS and other Java EE specs
    • A new mandatory API to allow any JMS provider to be integrated with any Java EE container
    • Multi-tenancy and other cloud-related features from the platform
    • Status
  7. Java Server Faces 2.2 (JSR 344):
    • Ease of Development - making configuration options dynamic, make cc:interface in composite components optional, shorthand URLs for Facelet tag libraries, integration with CDI, OSGi support for JSF artifacts
    • Support implementation of Portlet Bridge 2.0 (JSR 329)
    • Support for HTML5 features like HTML5 Forms, Metadata, Heading and Section content model
    • Flow management, Listener for page navigation events, and new components like FileUpload and BackButton
    • Status
  8. EJB 3.2 (JSR 345):
    • Enhancements to the EJB architecture to enable PaaS, such as multi-tenancy
    • Factorization of container-managed transactions to use outside EJB
    • Further use of annotations
    • Alilgnment and integration with other specifications in the platform
    • Status
  9. CDI 1.1 (JSR 346, more details):
    • Global ordering of interceptors and decorators
    • API for managing built-in contexts
    • Embedded mode to allow startup outside Java EE container
    • Declarative control over which packages/beans are scanned in an archive
    • Injection for static members such as loggers
    • Send Servlet events as CDI event
    • Status
  10. Bean Validation 1.1 (JSR 349):
    • Integration with other Java EE specs
      • JAX-RS: Validate parameters and return values on HTTP calls
      • JAXB: Convert constraints into XML schema descriptor
    • Method level validation
    • Apply constraints on group collection
    • Extend the model to support AND and OR style composition
    • Status
  11. JCache (JSR 107)
    • API and semantics for temporary, in-memory caching of Java objects, including object creation, shared access, spooling, invalidation, and consistency across JVMs
    • Package: javax.cache
    • Status
      • Approved by the JCP
      • Spec lead: Yannis Cosmadopoulos, Cameron Purdy (Oracle) and Gregory Luck (Software AG)
      • Project page: jsr107spec
      • Mailing List Archive: jsr107@googlegroups.com
  12. State Management (JSR 350):
    • API that can be used by applications and Java EE containers to offload the responsibility of statement management into third party providers with different QoS characteristics
    • Java SE-based callers can access the state data by querying the state providers
    • Providers with different QoS can be added and API callers can query to meet their criteria
    • Package: javax.state and javax.state.provider
    • Status
  13. Batch Application for the Java Platform (JSR 352):
    • Programming model for batch applications and a runtime for scheduling and executing jobs
    • Defines Batch Job, Batch Job Step, Batch Application, Batch Executor, and Batch Job Manager for the standard programming model
    • Package: javax.batch
    • Status
  14. Concurrency Utilities for Java EE (JSR 236):
    • Provides a clean, simple, independent API by building on JSR 166, making it appropriate for use within any Java EE contianer.
    • Package: javax.util.concurrent
    • Status
      • Approved by the JCP
      • Spec lead: Anthony Lai, Naresh Revanuru (Oracle)
      • Project page:
      • Mailing List Archive:
  15. Java API for JSON Processing (JSR 353):
Reference:

Sunday, March 17, 2013

Upgrade JSF version in JBoss AS 7.1.1.Final

The JBoss AS 7.1.1 Final ships with Mojarra implementation of JSF versions 1.2 and 2.1.7. However sometimes developers need to change or upgrade the JSF version.
Prior to this JBoss version web applications could load their own JSF by placing the jar in WEB-INF/lib and adding the following context-param in web.xml.

   org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL
   true

But this doesn't work anymore for 7.1.1. Following is how you can do it.
At the time of this writing I have used version 2.1.19.
  • First you need to download the jsf-impl and jsf-api jars that you want. Here are the MVN Repository for jsf-impl and jsf-api.
  • Place the jsf-impl jar in the path modules/com/sun/jsf-impl/main.
  • Open the module.xml of that directory and change the value of path of resource-root as

  • Now place the jsf-api jar in the path modules/javax/faces/api/main.
  • Open the module.xml of that directory and change the value of path of resource-root as

  • Because jsf-api depends on jsf-impl you need to add the dependency in the module of jsf-api as

Now you are good to run you server. While running the server if you see the following line:
14:14:08,379 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-4) Initializing Mojarra 2.1.19 ( 20130213-1512 https://svn.java.net/svn/mojarra~svn/tags/2.1.19@11614) for context '/your-app'
Then everything is fine.
Good luck.

Sunday, February 17, 2013

Implementation of Singleton pattern with Inheritance and Generics

Some day ago while playing around with Singleton, I had a thought that if it is possible to implement a Singleton class with Generics and Inheritance.
The Singleton classes do mostly same tasks, so I thought maybe I can put the common methods in the parent class using Inheritance.
Usually I create the Singleton object by Lazy Singleton pattern. Here is my parent class AbstractXMLParser:
public abstract class AbstractXMLParser<T> { 
 private static final Map<Class<? extends AbstractXMLParser>, AbstractXMLParser> INSTANCES = new HashMap<>();
 
 public AbstractXMLParser() {
  
 }

 private static class SingletonHolder<T> {    
  private static <T> T getInstance(Class<T> clazz) throws InstantiationException, IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
   Constructor<T> constructor = (Constructor<T>) clazz.getDeclaredConstructors()[0];
   constructor.setAccessible(true);   
   return constructor.newInstance(null);
  }
 }
 
 protected static <T extends AbstractXMLParser<T>> T getInstance(Class<T> clazz) throws InstantiationException, IllegalAccessException, NoSuchMethodException, SecurityException, IllegalArgumentException, InvocationTargetException {
  if(INSTANCES.containsKey(clazz)) {
   return (T) INSTANCES.get(clazz);
  } else {
   T instance = SingletonHolder.getInstance(clazz);
   INSTANCES.put(clazz, instance);
   return instance;
  }
 }
 
 protected static <T extends AbstractXMLParser<T>> void putInstance(Class<T> clazz, T instance) {
  if(!INSTANCES.containsKey(clazz)) {
   INSTANCES.put(clazz, instance);
  }
 }
}
Here the SingletonHolder inner class is used for Lazy. Note that the instantiation of the new child object has been done through Reflection. And the getInstance method is protected so that it can be accessible from the child classes only. As the Generic types are not visible in runtime so, I had to pass the class name explicitly from the child class's getInstance method to it.
Here is one of the child class ActivityTypeXMLParser:
public class ActivityTypeXMLParser extends AbstractXMLParser<ActivityTypeXMLParser> {

 private ActivityTypeXMLParser() {

 }

 public static ActivityTypeXMLParser getInstance() {
  ActivityTypeXMLParser activityTypeXMLParser = null;

  try {
   activityTypeXMLParser = getInstance(ActivityTypeXMLParser.class);
  } catch (Exception exception) {
  }

  if (activityTypeXMLParser == null) {
   activityTypeXMLParser = new ActivityTypeXMLParser();
   putInstance(ActivityTypeXMLParser.class, activityTypeXMLParser);
  }

  return activityTypeXMLParser;
 }
}
The Map of the parent class is used to store the class name as key the value object to get reference of the object in future call.
I hope you can get an idea how to use Inheritance with Singleton object in Java.