History of Java 2 (incl. code names)

JDK 1.1 (released on Feb 19,1997)
 Major additions included an extensive retooling of the AWT event model, inner classes added to the language, JavaBeans and JDBC.

J2SE 1.2 (Dec 8, 1998) — codename Playground.
  Major additions included reflection, a Collections framework, Java IDL (an IDL implementation for CORBA interoperability), and the integration of the Swing graphical API into the core classes. a Java Plug-in was released, and Sun's JVM was equipped with a JIT compiler for the first time.

[J2SE 1.2 and subsequent releases through J2SE 5.0 were rebranded Java 2 and the version name "J2SE" (Java 2 Platform, Standard Edition) replaced JDK to distinguish the base platform from J2EE (Java 2 Platform, Enterprise Edition) and J2ME (Java 2 Platform, Micro Edition)]

J2SE 1.3 (May 8, 2000) — codename Kestrel.
 Notable changes included the bundling of the HotSpot JVM (the HotSpot JVM was first released in April, 1999 for the J2SE 1.2 JVM), JavaSound, JNDI and JPDA.

J2SE 1.4 (Feb 6, 2002) — codename Merlin.
 This was the first release of the Java platform developed under the Java Community Process as JSR 59. Major changes included regular expressions modeled after Perl, exception chaining, an integrated XML parser and XSLT processor (JAXP), and Java Web Start.

J2SE 5.0 or 1.5 (Sep 30, 2004) — codename Tiger.
 Developed under JSR 176, Tiger added a number of significant new language features including the for-each loop, generics, autoboxing and var-args.

Java SE 6 (Dec 11, 2006) — codename Mustang --> current version
 is bundled with a database manager, facilitates the use of scripting languages (currently JavaScript using Mozilla's Rhino engine) with the JVM and has Visual Basic language support. As of this version, Sun replaced the name "J2SE" with Java SE and dropped the ".0" from the version number. Other major changes include support for pluggable annotations (JSR 269), lots of GUI improvements, including native UI enhancements to support the look and feel of Windows Vista, and improvements to the JPDA & JVM Tool Interface for better monitoring and troubleshooting

Java SE 7 — Codename Dolphin.
 The Dolphin Project started in August 2006, with release estimated in September 2010. New builds including enhancements and bug fixes are released approximately weekly.[13]

Glossary:
JNDI - Java Naming and Directory Interface
JPDA - Java Platform Debugger Architecture
JDBC - Java DataBase Connectivity
JAXP - Java XML Parsing
J2SE - Java 2 Standard Edition
J2EE - Java 2 Enterprise Edition
J2ME - Java 2 Mobile Edition
JVM - Java Virtual Machine
JCP - Java Community Process

Web project - folder structure

Web Deployment Descriptor

web.xml file

JavaSource (or src/java)

Contains the project's Java source code for classes, beans, and servlets. When these resources are added to a Web project, they are automatically compiled and the generated files are added to the WEB-INF/classes directory. The contents of the source directory are not packaged in WAR files unless an option is specified when a WAR file is created.

imported_classes folder

This folder may be created during a WAR import, and contains class files that do not have accompanying source. The imported_classes folder is a Java classes folder; Java classes folders can also be created using the Web project Java Build Path properties page.

WebContent (or web) folder

The mandatory location of all Web resources, including HTML, JSP, graphic files, and so on. If the files are not placed in this directory (or in a subdirectory structure under this directory), the files will not be available when the application is executed on a server. The Web content folder represents the contents of the WAR file that will be deployed to the server. Any files not under the Web content folder are considered development-time resources (for example, .java files, .sql files, and .mif files), and are not deployed when the project is unit tested or published.

META-INF

This directory contains the MANIFEST.MF file, which is used to map class paths for dependent JAR files that exist in other projects in the same Enterprise Application project. An entry in this file will update the run-time project class path and Java build settings to include the referenced JAR files.

theme

The suggested directory for cascading style sheets (css) and other style-related objects.

WEB-INF

Based on the Sun Microsystems Java Servlet 2.3 Specification, this directory contains the supporting Web resources for a Web application, including the web.xml file and the classes and lib directories.

/classes

This directory is for servlets, utility classes, and the Java compiler output directory. The classes in this directory are used by the application class loader to load the classes. Folders in this directory will map package and class names, as in: /WEB-INF/classes/com/mycorp/servlets/MyServlet.class.This is generated while a build happens. Do not place any .class files directly into this directory. The .class files are placed in this directory automatically when the Java compiler compiles Java source files that are in the Java Resources directory. Any files placed directly in this directory will be deleted by the Java compiler when it runs.

/lib

The supporting JAR files that your Web application references. Any classes in .jar files placed in this directory will be available for your Web application. In short, jar's file would be in classpath.

Libraries

The supporting JAR files that your Web application references. This folder mirrors the content of the lib folder. In addition, Web Library Projects, which are "virtual" JAR files that do not physically reside in the Web project, but are associated with Java projects elsewhere in your workspace, are included in this folder. They are packaged with your project when you export the application's WAR file.

 A library entry on the Java build path will remain there unless the actual JAR file is deleted from the WEB-INF/lib folder. If you remove a library path entry but not the JAR file, the library entry will be re-added to the path automatically.

[Ultimate Reference: http://java.sun.com/blueprints/code/projectconventions.html ]

Oracle Open Interface

What is Oracle open interfaces?

Open interfaces used to integrate Oracle Applications with the non-oracle systems.
such as
1. Import data from your custom applications or legacy systems.
2. Migrate the old custom application data to the Oracle applications.
3. Import data from the banks, partners, suppliers, customers etc.


What is conversion?

Conversion is a one time Interface to migrate data from legacy application to the Oracle


Inbound Interface
The Interface which transforms and loads the data into the Oracle Applications system is called inbound interface.


Outbound Interface
The Interface which extracts the data from the oracle Application system for the purpose of loading into the external system is called outbound interface.


Common approach to interface is

1. Data would be extracted from the source machine and loaded into the custom table (stagging table) in Oracle apps database. Depending upon the complexity of the data Stagging table can be avoided.
2. The extracted data is then transformed into a form which oracle can recognize and pushed into interface tables.
3. Final step is load the data from interface table to base table of Oracle applications.

This whole process is called extract load and transformation (ETL).


Oracle provides Interface tables for data intensive applications like Invoice, receipts, journals etc and PL/SQL APIs for master data interfaces like people, items, suppliers etc.


Traditional approach used sql Loader to load the data and pl/sql program to validate and extract data.
Modern approach uses BPEL, ESB for online data interfaces and Oracle Data Integrator for data intensive batch processing.


Common Interface technologies
1. XML Gateway
2. SQL*Loader
3. DB Link
4. Java Concurrent Program
5. BPEL or ESB
6. Oracle Data Integrator or ODI
7. PL/SQL package for reading file or XML data
8. Oracle Advanced Queuing


Some Useful Links

1. Oracle Integration Repository - List of Oracle open interfaces
2. Technical reference Manual - Column level details of Interface tables, base tables and APIs
3. Technical reference Manual for different versions.

Debug bc4j objects or ADF BC Objects

How to debug the VO, LOV, poplist queries?

You can see the executed queries and its bind values in the jdeveloper console or messages window.
By default, this option is not available in jdeveloper.

To enable the debug console option in 11g and 12c

I was just going through my previous posts and found the this option still works on Jdeveloper 11g and 12c. So you could use the debug option on the ADF BC - Model project and it will log all the queries on the jDeveloper console during execution.

Just follow same set of instructions as given for 10g jdeveloper.


To enable the debug console option in 10g

1. Right click on project and select project properties

2. Select Run/Debug

3. Ensure Default in selected in Run configurations

4. Select Edit button.

5. You can see the Launch Settings window.

6. Add the following parameter in the java options
-Djbo.debugoutput=console

7. Select OK

8. Rebuild the project and run again to see the debug information in jdeveloper log window







To enable the debug console option in Jdev 9i1. Right click on project and select project properties

2. Navigate Configurations -> Development -> runner

3. Add the following parameter in the java options
-Djbo.debugoutput=console

4. Select OK

5. Rebuild the project and run again to see the debug information in jdeveloper log window







This option would be very helpful in finding out what going on in the bc4j objects. Including LOV queries, poplist queries, VOs etc. Whenever the query is executed through the AM or procedure is called, the bind variable values and executed sql will be displayed in the jdeveloper message window.

How to Call PL/SQL from ADF?

You can use the following code to call a pl/sql block from the ADF bc Application module.


public void executePlsqlProcedure(){

CallableStatement updateStmt = null;
try {
// Put your PL/SQL block in a String variable.
String Stmt = "begin delete test_table where header_id = :1; "+
" :2 = xxx_pkg.yyy_function(); end;";
OADBTransaction txn = getDBTransaction();

// Pass the PL/SQL block to the callable Statement
updateStmt = txn.createCallableStatement(Stmt, 1);


// Set all the bind variables before calling the execute command
updateStmt.setInt(1, headerIdToDelete);

// And register the output parameter types
updateStmt.registerOutParameter(2, Types.DOUBLE);
updateStmt.executeUpdate();

// After execute you can get the value of pl/sql block output
Number amount = new Number(updateStmt.getDouble(2));
updateStmt.close();

// Commit the transaction in the database
txn.commit();


} catch(SQLException sqle) {
updateStmt.close();
}

}



And you can call the above Application Modules method from managed bean using following code.

FacesContext facesContext = FacesContext.getCurrentInstance();
ExpressionFactory exp = facesContext.getApplication().getExpressionFactory();
DCBindingContainer bindingContainer = (DCBindingContainer)exp.createValueExpression(facesContext.getELContext(),"#{bindings}",DCBindingContainer.class).getValue(facesContext.getELContext()); 
DCIteratorBinding itr = bindingContainer.findIteratorBinding("Dept1Iterator"); 
DemoAppAMImpl svc = (DemoAppAMImpl)itr.getDataControl().getApplicationModule();


Or you can call this method by exposing into client interface.

System.out.println

This is the most commonly asked question in web applications development in jdeveloper including OA Framework, ADF, ejb, web services etc.


Can I leave System.out.println or System.err.println in the production code?

System.out.println comes handy when debugging the application because you can see the messages pretty much easily in the jdeveloper console. And it takes relatively less time than the debugging option in Jdeveloper. So even experienced developers use it for debugging. You may think, "Anyway this doesnot any affect in the production system". But actually System.out.println statements will have serious performance issue in the production system if you fail to remove them in the final code.

The reason is that the application server will have only one output stream and one error stream in the JVM. Hence multiple threads calling the System.out.println() have to be synchronized.

Considering the production system with thousands of users, back end programs, webservices, scheduled process running parralley in the machine. Calling system.out.println() will potentially block the performance of whole system.

Also the application server doesn't redirect the std out to a file, and is lost.



Hence always remove the System.out.println() /System.err.println() from the production code.

Managed Bean

Managed beans are Java classes that you register with the. The managed beans are initialized when they are referenced in the application for the first time. It helps to handle UI events or write data manipulation code. TIP: Use managed beans to store only logic that is related to the UI rendering.

Managed beans can be registered in three files

1. adfc-config.xml
2. Task flow definition file
3. faces-config.xml

adfc-config.xml

Managed bean declared in this file can be of any scope.

Task Flow definition file

Managed bean scope can any scope. However, managed beans of request, pageFlow, or with scope set to none accessed within the task flow definition, must be defined within the task flow definition file. Managed bean definitions within task flow definition files will only be visible to activities executing within the same task flow.

faces-config.xml

Allows any managed bean scope other than pageFlow scope.

The order of searching a managed bean in the application is faces-config.xml, adfc-config.xml and Task flow definition file (if exists). Hence managed bean defined in the faces-config.xml takes the precedence.

As a general rule in fusion web applications, a bean that may be used in more than one page or task flow is defined in the adfc-config.xml and a bean that is used within the task flow is defined in the task flow definition XML file.

Add a managed bean

To add a managed bean

1. Click the adbc-config.xml file or task flow definition file.
2. Go to Property editor -> Managed bean tab
3. Choose the +(Add) Icon.

Difference between Managed Bean and Backing Bean

Backing bean and Managed bean are not different they are the same. Managed bean is about how the bean is created and initialized. Backing bean is about the role a particular managed bean plays.

In other way, Managed bean is a Java Bean registered in the adfc-config.xml file. These beans have properties that are bound to the values of UIComponents.

Backing bean is a special type of managed-bean consisting of properties that are UIComponents. Instead of the bean properties being bound to the UIComponent values, they are instead bound to the UIComponents themselves.