Managed Beans configuration In JSF 2.0 | Techartifact

In JSF 2.0, Java bean that is accessed from JSF page is called a Managed Bean. The managed bean can be a normal Java bean, which contains the getter and setter methods, business logic or even a backing bean (a bean contains all the HTML form value).

There are two ways to configure the managed bean :

-> Configure Managed Bean with faces-config.xml

It is same as we used to do JSF 1.1 .We can defined managed bean in faces-config.xml .

<?xml version="1.0" encoding="UTF-8"?>
<faces-config
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
    http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
    version="2.0">
    <managed-bean>
	  <managed-bean-name>helloBean</managed-bean-name>
	  <managed-bean-class>com.vinay.common.HelloBean</managed-bean-class>
	  <managed-bean-scope>session</managed-bean-scope>
     </managed-bean>
</faces-config>

Using Dependency Injection

-> Configure Managed Bean with Annotation

You can annotated a Managed Bean with new @ManagedBean annotation in JSF 2.0 .JSF is a basic Dependency Injection (DI) container and we can use annotations to inject objects. JSF offers setter method injection – this means the object will be passed into the setter. It is also static injection – meaning, the injection will happen only during bean creation (as opposed to Seam, where static and dynamic injection is possible).

package com.vinay.common;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import java.io.Serializable;
 
@ManagedBean
@SessionScoped

public class HelloBean implements Serializable {
 
	private static final long serialVersionUID = 1L;
 
	private String name;
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		this.name = name;
	}
}


@ManagedBean – marks this bean to be a managed bean with the name specified in name attribute. If the name attribute in @ManagedBean is not specified, then the managed bean name will default to class name portion of the fully qualified class name.Try to set the scope (request) into which this bean will be placed. If scope is not specified then bean will default to request scope.

@ManagedBean also has eager attribute (new in JSF 2). If eager=”true” and scope is application, then this bean must be created when the application starts and not during the first reference to the bean. In other words, the creation and storing of the bean instance must happen before any requests are serviced.

@ManagedBean(name="vinayBean", eager=true)
@ApplicationScoped
public class Vinay{
 ...
}

If eager is true but scope is not application, then regular “lazy” initialization used. If eager is not defined or missing, then “lazy” initialization is used as well.

You can also pass the value of variable using annotation.

@ManagedProperty(value="vinay")
private String name;

When the bean is created, ‘vinay’ will be passed to setName(..) method.

Happy New year guys.This is first post of this year.
Happy coding with Techartifact.

Ldap configuration in Jetspeed 2.2.0

Ldap configuration in Jetspeed 2 (JS2) is very easy. Its only two required steps to configure Ldap in JS2.

1) Enable Ldap module
First you need to create “spring-filter-key.properties” under jetspeed/WEB-INF/conf and add the following lines

#Turn on LDAP Security
spring.filter.key = portal.ldap

Spring-filter-key. properties can be used to enable or disable different module of jetspeed.

2) Define Ldap Connection propetries

Jetspeed store all its Configuration settings in jetspeed.properties.

Following are default jetspeed ldap settings
jetspeedldap
First four points are self explanatory.

ldap.context.factory
Jetspeed uses ldap to communicate to ldap server. I think it would not be advisable to changes context factory until its rally required.

ldap.user.filter =

You can define you own object class for users

ldap.search.scope

Ldap search scope refer to searching objects in ldap sub tree. I would suggest not-to change this value

ldap.user.searchBase
ldap.role.searchBase
ldap.group.searchBase
You can define tree location where all you users reside. Once you define user search base of user, Jetspeed will only look for user and there relation under that node.
Search base can be  defined for groups and roles too.

ldap user entryPrefix

In ldap there are different user classes to create user and they have there own different respective schema, So you can choose you can define your own uid prefix