Congratulations to ECSTeam on their recent designation as a partner specialized in ADF! Some of you have seen Greg Opie co-present with me at Oracle Open World, demonstrating the various applications that his team have built using Oracle ADF. This latest feather in their cap means that the ECSTeam is recognized by Oracle as ADF experts. Congrats to Greg and the rest of your team!
Grant Ronald and I co-presented a session at Oracle Open World this year, providing a synopsis of our own Forms redevelopment project. With Grant explaining the concepts that map from the Forms world to ADF, and myself driving the demos, it is a session that includes a nice mix of both the WHAT and HOW of building applications with ADF.
If you missed us at OOW, or just need a recap, we’ve recorded the unabridged version and published it on OTN here:
If you’re thinking about reusability in your ADF application (and you should be!), you might have taken a look at using ADF Libraries. These are a special type of JAR file that allows ADF Business Components (EOs, VOs, AMs) or ADF Faces Components (page templates, task flows, declarative components) to be reused in other applications. When validating Dede’s new ADF Insider Essential on the topic, I found that it’s imperative that you use unique naming conventions for the project. More specifically, if you are prototyping this feature and create an Application that uses the default Model and ViewController project names (and the corresponding packages of the same names), you’ll be able to add ADF Library JARs containing components from those projects to projects in another application, but you won’t be able to reuse any of the components. So to set this up correctly, follow these steps:
- Create a base Application named anything you like. If you choose the Fusion Application Template, you’ll be prompted to add two projects, Model and ViewController, to the Application in a wizard.
- In Step 2 of 5 in the wizard, name the Model project BaseModel and in step 3 of 5, provide a package name of basemodel (or some unique name).
- Repeat this for Steps 4 and 5, providing a unique name for the ViewController project
- Create reusable components for your organization’s use. If you are just prototyping this, you might create a full set of ADF Business Components in the BaseModel project, and a page template and the traditional ADFUtils and JSFUtils helper classes in the BaseViewController project.
- Create a New ADF Library JAR deployment profile for each project and deploy the JAR files.
- Create a new application, using the default project and package names, and either use the Resource Palette to add the JARs to the projects or for Business Components, use Project Properties > Business Components > Imports to add the components to the new project.
The key to all this is that if you fail to change the name of the project, adding the JAR to the project using either method will be a no-op and you won’t see your BC or ADF Faces components reused in the ‘consuming’ application.
Note: In JDeveloper 184.108.40.206, when you change the name of the project in steps 2 and 4 of the wizard, the name of the package isn’t changed from the default in steps 3 and 5. This is a regression in behavior so I’ve filed a bug for that.
A new press release has just come out that highlights Collect America’s experience with JDeveloper and ADF. If you are a evaluating ADF for your next application development project, this is a must-read! Collect America is using the entire ADF stack – ADF Business Components, ADF Controller, and ADF Faces. They’ve even developed their own CSS skin. The application was built with JDeveloper 11g and is running on WLS 10.3 production.
Read the press release here:
This article is a follow-up to 2 previous postings:
Understanding available WebLogic Server downloads for ADF Applications
Extending WebLogic Server for ADF Applications
and assumes you have followed the steps in both.
This means that you have JDeveloper installed on your local machine, that you have a WebLogic Server installed on a remote machine, and you’ve extended the WLS server with the required JRF template for ADF applications, and that you’ve started the WLS server with -Djps.app.credential.overwrite.allowed=true so that database credentials will be uploaded to the server when an application is deployed. If you haven’t done these steps, go back through the previous two posts and follow those instructions.
If you’re still with me, now you’re ready to deploy a simple ADF application to the server to validate that it’s ready for real ADF applications.
The easiest way to develop a simple ADF application (if you don’t already have one on hand) is to follow the cue cards.
- From your development machine, open JDeveloper and choose Help > Cue Cards and select the Build a Fusion Web Application cue card:
The first step of the cue card is to install the schema. The example uses a hostname of localhost, meaning that the sample schema is installed on a local database. If you’re going to be deploying to a remote machine with WLS installed, then the schema will need to be installed somewhere where the remote machine can connect to, such as your team’s shared database. Keep that in mind through the first step and then follow through all the steps in Part 1 and Part 2 of the cue card to create the example. You’ll end up with an application with ADF business components, an ADF task flow, and two ADF Faces views:
If you want to cheat a bit, you can download the application completed through parts 1 and 2 of the cue card here.
- The last step of Part 2 of the cue card is to run the application locally. This is a step that you should always perform on any application before you deploy it, to ensure that it runs properly and does what you expect. This is the primary reason that WLS is embedded in JDeveloper; you can test incremental changes in an application without having to redeploy the application. Make sure that you perform this step. For the example application, you should see the following when running locally:
- Once the application runs successfully locally, create a connection in JDeveloper to your shared WLS server. Open the Resource Palette, right click Application Server, and choose New Application Server connection:
- Specify a name for the connection, such as SharedDevServer, and leave the default WebLogic 10.3 specified as the connection type:
- Specify the username and password you created when installing WebLogic Server, such as weblogic and welcome1:
The security people will be after me if I don’t mention here that you should not actually use the default password, but this is the password that the JDeveloper-embedded version of WebLogic Server uses, so there you go. Click Next.
- Enter the hostname where you have installed WebLogic Server, and the port you installed to (7001 by default). Additionally, enter the domain that you extended with JRF. If you did not create a new domain, this might be “AdminServer”, but that’s actually not recommended because the AdminServer domain has enough tasks to do without hosting your applications. If that’s the case for you, you might want to go back to step 11 of the appendix in Steve Muench’s article and create a new domain and then extend that domain with the JRF files. In my previous post, I extended the my_domain domain and so that’s the domain I specify here:
- Finally, test the connection. A crucial step. Ensure that all tests complete successfully:
- At this point, there’s a few things to do to make life easier for this test deployment. The first thing to ensure is that when deployed to a remote machine, that machine has access to the data source connection that the application uses. You could do this by creating a global data source in WLS and then configuring your domain to use that connection. However, we’re just testing here, so in the case that your application was built using a data source based on your local machine’s database (and presuming that the machine that you’re deploying to doesn’t also have a database running at localhost), change the database connection that the application uses to a remotely-accessible database where you have installed the FOD schema (see step two above). To do this, expand Application Resources beneath your Projects listing in the Application Navigator. Expand Connections, Database, and then right click FOD and choose Properties:
- Change the connection details to point to your remotely-accessible database:
- The next thing that makes life easier for this test deployment is to limit the amount of typing that you have to do to access the application remotely. Some history: JDeveloper uses the name of your application, the name of your project, and then “context-root” for the root url of your web application (BrowseEditApp-ViewController-context-root, for example). It does this because it can then ensure that the url to any application that you run in the embedded server in JDeveloper is unique. However, when you run a web application in JDeveloper, the browser is automatically launched for you and you don’t have to type a url. This is fine for testing locally, but you can make things easier for deployment by changing the default url to something more manageable. To do this, double click on your web application project (ViewController) to bring up the project properties. Click the Deployment node and select the Deployment Profile:
You might have noticed that you didn’t have to explicitly create deployment profiles for your application (.EAR), data model (.JAR) or web applications (.WAR) – JDeveloper creates them for you and you only need to modify them if you have specific deployment configurations to consider. Click Edit to edit the automatically generated WAR deployment profile.
- On the General page of the WAR deployment profile dialog, select Specify Java EE web context root and enter a more user-friendly name, such as BrowseEditApp:
- You’re now ready to deploy. You will be deploying the default EAR file profile, which is stored at the application level, and includes the WAR profile that you just modified as well as the JAR file that was automatically defined for the ADF Business Components Model project. Click the dropdown next to your application name, and choose Deploy. A series of context menus will appear as you select the name of your application’s EAR deployment profile (BrowseEditApp_application1 by default), to, and then the name of your shared server that you defined in step 5 above:
If you see errors instead, check that you’ve followed the post for extending your domain.
- Now you can access your application from a browser. The url will be the hostname of your server, the port (default 7001), followed by the context root of your web application, followed by the servlet url “faces” because this is a JSF application, followed by the name of your starting .jspx page. In this example application, you don’t have a starting .jspx page because your starting point is actually an ADF task flow and a slew of parameters are required to load the task flow properly (in most applications, you’d have a starting index.jspx that redirects to your initial task flow’s url for convenience). So in this test, copy the Target URL from the log that was created when you test-ran the application locally in step 3 above. The tab for this log is called Running: DefaultServer. Click that tab and then select the entire contents of the Target URL:
Right click and choose Copy, then paste that into a browser. Replace the local ip address with the hostname for your shared server, replace the 7101 embedded WLS Server port with the default standalone port of 7001, and finally replace the longer default context root with the one that you defined for this application. Leave all the remaining parameters as-is. The resulting url will be something like the following:
- Click enter to launch the application (you’ll see a spinning “O” first to let you know the application is loading). The result is your test application, deployed to a remote, standalone, JRF-extended WebLogic Server:
This post serves as a step by step guide to extending a generic WebLogic Server domain on Linux using the Application Development Runtime package available on OTN. The Application Development Runtime package includes the Java Required Files (JRF) which include the ADF runtime libraries necessary to deploy ADF applications on WLS. In case you’re wondering, these libraries are already included for the default domain that’s installed with JDeveloper, so that’s why no domain extension is necessary when you’re running an application directly from JDeveloper. However, if you’ve deployed an ADF application to your domain and are getting errors like “Unresolved application library references, defined in weblogic-application.xml: [Extension-Name: adf.oracle.domain, Implementation-Version: 220.127.116.11.0, exact-match: false], [Extension-Name: oracle.jsp.next, exact-match: false]“, then your domain doesn’t include the JRF extension and you’ll need to follow these steps.
1. From the Fusion Middleware Download page:
2. Scroll down to Application Development Runtime and click Disk1 to download.
3. Save the zip file to disk.
4. Open the zip once it has downloaded successfully and extract the files.
5. cd to the location of the files and run the installer:
6. If the installer prompts for a JDK, enter the one in the your Fusion Middleware home directory:
7. When the installer launches, select a directory for the inventory of the install:
8. If the installer was not run as root, the installer will prompt for the createCentralInventory.sh to be run before the install proceeds:
9. Run the script as directed:
The script should execute successfully.
10. Click OK in the installer dialog to continue the installation:
11. Click Next on the welcome page of the installer.
12. Click Next once the requirements are verified:
13. Specify the Oracle Fusion Middleware Home directory (where you have installed WLS 10.3) and click Next:
14. Click Install to start the installation:
15. Click Finish when the install is complete.
16. From the quick start dialog, launch the configuration wizard:
17. In the configuration wizard, select Extend an existing WebLogic domain and click Next:
18. Select the domain that you previously created and click Next:
19. Select Oracle JRF – 18.104.22.168 [Oracle_APPDEV1] as the extension source and click Next:
20. Click Next to skip the Optional configurations steps:
21. Click Extend to extend the domain:
22. Click Done to exit the configuration wizard once the extension is applied successfully.
23. Finally, to ensure that the credentials that you supply in the database connections for your ADF Application are deployed and include the password, add -Djps.app.credential.overwrite.allowed=true to the JAVA_PROPERTIES entry in the
yourdomain/bin/setDomainEnv.sh file (or setDomainEnv.cmd if you are on Windows), and restart the server using
yourdomain/bin/startWebLogic.sh. This is what you need to do if you have deployed an ADF application to your server but are seeing the following errors when the application is accessed:
oracle.jbo.DMLException: JBO-26061: Error while opening JDBC connection.
Truncated. see log file for complete stacktrace
java.sql.SQLException: ORA-01005: null password given; logon denied
Congratulations! Your WLS domain is now ready to host ADF applications.