Miscellan – Web Technologies

Q# How do you configure maven? What are the advantages of maven over ant build?

Maven is just a framework of plugins that uses Ant underneath. It stores jar files in a remote repository for easy sharing. Maven is easier to use; there is no need to write large build.xml files since most common tasks are available as plugins.
You have a settings.xml and one or several pom.xml.
The settings.xml is optional and is used to specify the repository location, security and deployment settings. If it is absent default values are used. It may also contain repository authentication informatio and username and passoword for the server on which the generated package is deployed.
Maven Repository
Maven will automatically download artifacts from the online maven repository if the dependencies are not locally available in the repository. The jars are placed in a local maven repository(relative path=.m2/repo).
It contains the following information:

  • the type of packaging,
  • information about the project dependencies(artifacts or dependencies of those artifacts),
  • artifact name
  • artifact version,
  • artifact scope(default scope means the generated package will include this artifact while “provided” means they will be provided by the deployment container),
  • maven plugins that are to be used during the build process(certain plugins such as mvn:clean, mvn:compile, mvn:package are included by default within the maven distribution),
  • dependencies on third party maven repositories

When executing a task or goal, Maven looks for the POM in the current directory. It reads the POM, gets the needed configuration information such as project dependencies, then executes the goal. The goal may be a custom goal or one that is available in a maven plugin or inbuilt into maven.
Maven commands
mvn compile
mvn package
mvn install
are common maven commands.
Maven has plugins for all “common” tasks so that all you have to do is add some information to configuration files. These are built over Ant tasks.

Q# Java Messaging Service – here we go again

Two useful links from cuppajava site that proves handy:

Q# For what functionality did you use JMX in any of your applications?

customizing JBoss JMX console to change the state of custom beans at runtime

Q# Have you performed any tomcat or jboss administration?

For the most part developers do very little with jboss and tomcat administration – mainly deployment, datasource configuration. I’m sure jboss and tomcat have a lot of proprietary features that are powerful but normally we don’t use them and instead we stick to standard J2EE techniques and third party frameworks etc. In a production environment the jboss/tomcat administrator may do some tuning like change the # of connections in jdbc pool, JVM args, etc. but normally a developer doesn’t care about this stuff. jboss has a UI for configuration:
see http://docs.jboss.org/jbossas/6/Admin_Console_Guide/en-US/pdf/Admin_Console_Guide.pdf
For tomcat

Q# How does inter-portlet communication take place in liferay?

Q# Describe the JSF life cycle
Request Processing Scenarios:
1. Faces request: A servlet request that was sent from a previously generated Faces response. i.e. from a jsf page. eg a JSF form submission
2. Non Faces request: A servlet request that was sent from a non JSF page such as a JSP page without JSF tags.
3. Faces response: A servlet response rendered by the RENDER RESPONSE PHASE
4. Non Faces response: A servlet response not rendered by the RENDER RESPONSE PHASE
eg. a jsp page which does not incorporate JSF tags is rendered.

Scenario 1: Non Faces Request generates Faces Response
eg. When a hyperlink is clicked which invokes a JSF page. The non Faces request is mapped to the FacesServlet which generates a Faces response by generating a view which is basically a tree of UI componenents. It then goes to the RENDER RESPONSE PHASE.
Scenario 2: Faces Request generates Non Faces Response
A JSF page rendered through the RENDER RESPONSE PHASE when submitted may render a non JSF page without JSF tags. The RENDER RESPONSE PHASE is skipped and so are all the intermediate steps in the life cycle.
Scenario 3: Faces Request generates Faces Response
This is the most common scenario in a JSF life cycle. A JSF page rendered by a RENDER RESPONSE PHASE generates a Faces request mapped ot the Faces Servlet. All convertors, validators and listeners are invoked as part of the JSF life cycle and a Faces Response is rendered. This process is described below:
The following shows the complete steps from Faces Request to Faces Response.
When a request is made from a JSF page i.e. Faces Request postback- such as submission of a JSF page, the JSF implementation restores the view(tree of JSF UI components) by using state information saved on the server or client.
If this is a fresh request for a JSF page, an empty view comprising of JSF UI components is created and moves to the RENDER RESPONSE PHASE bypassing intermediate steps.
After the view is restored, the component tree extracts the request values and stores it, after conversion. If the conversion fails, validation errors are generated. If any listeners are registered, the JSF implementation broadcasts events to these listeners. In short components are set new values, messages and events are queued.
The JSF implementation processes all validator registred with the UI components and applies these rules to the stored value in the JSF UI componenets. If values are invalid, error messages are generated, and the cycle moves to RENDER RESPONSE PHASE and displays all error message queue up. If events have been queued up at this stage, the JSF implementation broadcasts tehm tho these liseteners.
The JSF implementation updates the model (JSF backing beans) with values from the UI componenets. If the conversion from UI component data types to model data types fails, errors are generated and queued up and the cycle moves to the RENDER RESPONSE PHASE Where these error messages are displayed. If events are queued up at this stage the JSF implementation broadcasts them to interested listeners.
The JSF implementation consults the application configuration and processes the request by handlers after which the navigation rules are looked up to find which view is to be shown. The cycle then moves to the RENDER RESPONSE PHASE. If events are fired these broadcast to interested listeners.
The JSF implementation hands delegates the remaining steps to the JSP container to render the Faces view.
If the request is postback the errors that were encountered in the above steps will be displayed on the original page.
The state of the response is saved to make it available to the next RESTORE VIEW PHASE.
If this is a fresh request the components are already added to the tree creating an empty view, and this will be rendered by the JSP container.

About cuppajavamattiz
Matty Jacob - Avid technical blogger with interests in J2EE, Web Application Servers, Web frameworks, Open source libraries, Relational Databases, Web Services, Source control repositories, ETL, IDE Tools and related technologies.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: