RADalcove

This article is a follow-up to 2 previous postings:
Understanding available WebLogic Server downloads for ADF Applications
and
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.

1. From your development machine, open JDeveloper and choose Help > Cue Cards and select the Build a Fusion Web Application cue card:



2. 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.

3. 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:

   

4. 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:

   

5. Specify a name for the connection, such as SharedDevServer, and leave the default WebLogic 10.3 specified as the connection type:

   
   Click Next

6. 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.

7. 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:

   

8. Finally, test the connection. A crucial step. Ensure that all tests complete successfully:

   

9. 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:

   

10. Change the connection details to point to your remotely-accessible database:

    

11. 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.

12. 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:

    

13. 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:

    
    The deployment log will appear in JDeveloper, and you should see a successful deployment like the following:

    

    If you see errors instead, check that you’ve followed the post for extending your domain.

14. 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:

    http://sharedserver.mycompany.com:7001/BrowseEditApp/faces/adf.task-flow?adf.tfId=orders-flow&adf.tfDoc=/WEB-INF/orders-flow.xml

15. 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:

    

Voila!

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: 11.1.1.1.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 – 11.1.1.0 [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 FMW_HOME/user_projects/domains/yourdomain/bin/setDomainEnv.sh file (or setDomainEnv.cmd if you are on Windows), and restart the server using FMW_HOME/user_projects/domains/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.
at oracle.jbo.server.ConnectionPool.createConnection(ConnectionPool.java:253)
at oracle.jbo.server.ConnectionPool.instantiateResource(ConnectionPool.java:168)
at oracle.jbo.pool.ResourcePool.createResource(ResourcePool.java:546)
at oracle.jbo.pool.ResourcePool.useResource(ResourcePool.java:327)
at oracle.jbo.server.ConnectionPool.getConnectionInternal(ConnectionPool.java:104)
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.