Developer Cloud Service with JDeveloper 12.2.1 available

I almost missed that Developer Cloud Service has been updated to 12.2.1. Great news as we now can use JDeveloper 12.2.1 to access the agile capabilities like

  • Interact with Tasks/Issues in JDeveloper
  • Leverage the Team view in JDeveloper (tasks, builds, and code repositories)
  • Connect to DevCS and its projects from inside JDeveloper
  • Create Agile boards and manage sprints in Developer Cloud Service
  • Associate code commits with specific tasks
  • Monitor team activity in the Team Dashboard
  • Handle Git transactions

For more information about how JDeveloper and the DCS are integrated watch this video ‘Agile development with Oracle JDeveloper and Oracle Developer Cloud Service’.

This was possible since last year. So, what’s new?

New is that the JCS is also available in 12.2.1 and that we can use the whole continuous integration scenario. For this we have to configure a 12.2.1 JCS instance which then can be used for deployment. When we select to create a new instance of a JCS we see the new wizard which allows us to select a WebLogic Server 12c in version 12.2.1

On the ‘Edition’ page we don’t find anything new so we skip it and go to the Details page where we specify the needed information for the service, database configuration, backup and the WebLogic user

After getting the confirmation page we create the new service and finally after a short time we see the new service

A look at the Enterprise Manager of the new service shows the new login page

and after logging in the new 12.2.1 Enterprise Manager

It look modern and fresh. However, this is not what this blog is about. I installed my ADF Version Web Service BlogAdfVersionWS to check which ADF version is running in this instance. Selection the modules we find the test point on the right side of the Web Service

After selecting the test point we select to run the ‘GetVersion’ service

and get

That’s right what we expect when running ADF 12.2.1!

Next time we see how to change the build and deployment part of the DCS to work with the JCS 12.2.1.

Advertisements

Change Application Configuration at Run Time through a Properties File (Part 1)

Often users ask how to change some configuration properties, e.g. a reprot definition file or endpoint of a web service, art runtime of the application. This is not an easy task as such configuration normally is deployed together with the application as part of the ear file. This however can’t be changed easily.

There are different possible solutions, like providing a Mbean which then can be used in the weblogic servers admin console to change values. A sample for this approach can be found e.g. here Creating Mbeans(JMX) in ADF Application and accessing them from jrockit mission control.

In this blog I show a different approach which uses a configuration file which can be changed externally. The values read from the file are properties (key value pairs). If we make changes to the file they are reflected during run time without the need to restart the application. Keep in mind that this approach does not work will on a clustered system as there are multiple servers with multiple file locations which have to change. One way to overcome this is to set the location on e shared file system which can be accessed from all servers.

To implement this use case we first have to think about how we get the path to the configuration file and it’s name to load it during run time.

To get the path the the configuration file we use a context parameter which we define in the web.xml file. The reason for this is that we need to change this parameter depending on the system we deploy the application too. In addition you can’t make predictions like where an administrator likes to put the configuration file.

Context Parameter in web.xml

Context Parameter in web.xml

To load the properties we can use java default Properties class which loads properties from a stream. The bit and bytes can be found in the source of the work space which is available GitHub (see link at the end of the post).

One thing to notice is that this post uses Apache Commons-IO version 2.4. This update make one other change necessary in the weblogic-application.xml file.

  <prefer-application-packages>
    <package-name>org.apache.commons.io</package-name>
  </prefer-application-packages>

This entry allows the application to use the included commons-io jar to be loaded before the already available commons-io jar, of an older version, in WebLogic server 12.1.3.

After setting the parameter let’s write a sample page where we show some of the properties on the page, then change the configuration reset the properties and see the changes on the page.
For the implementation we use an application scope bean. The reason is that the configuration parameter should be available application wide. There is no need to keep this info per session. If you read the configuration file for every parameter you can use a request scope bean.

In a live system I would not recommend using this approach (reading the configuration file every time) because it produces a bottleneck reading the file over and over again. Instead I would call a method periodically or as the result of a user action like button click.

OK, let’s create a configuration file in the WEB-INF folder or if you like in any other folder. Once the file is created we copy it into a temporary folder on the system (/tmp on mine) and read it from there.


Now we need an application scope bean

The bean has a getProperties method which checks if the proprieties are already read or if not read the context parameter from web.xml to read the file from the given position.

    /**
     * This method savely get the properties from a file if the file can be read, otherwise it return an empty properties object
     * @return Properties object read from file of empty properties object if hte file was empty or could not be found
     */
    public Properties getProperties() {
        if (properties == null) {
            FileInputStream fileInputStream = null;
            try {
                // read context parameter
                String initParameter = FacesContext.getCurrentInstance().getExternalContext().getInitParameter(PROPERTYFILE_PARAMETER);
                logger.info("Read properties from " + initParameter);
                // try to read the file
                File file = FileUtils.getFile(initParameter);
                fileInputStream = FileUtils.openInputStream(file);
                properties = new Properties();
                properties.load(fileInputStream);
                logger.info(properties.size() + " properties successfully read.");
            } catch (IOException ioe) {
                logger.warning("Error: Property file could not be read!", ioe);
                properties = new Properties();
            } finally {
                if (fileInputStream != null)
                    try {
                        fileInputStream.close();
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
            }
        }
        return properties;
    }

    /**
     * Reset the read properties so that the next try to read a property ready the file again
     */
    public void readPropertiesAgain() {
        logger.info("Reset properties!");
        properties = null;
    }

    /**
     * Method to return the version information of the configuration file.
     * this information is compiled from the keys PROPERY_NAME and PROPERTY_VERSION
     * @return version information read from the file
     */
    public String getPropertyVersionInfo() {
        String property = getProperty(PROPERTY_NAME);
        String property_2 = getProperty(PROPERTY_VERSION);
        String res = "Unkown";
        if (property != null && property_2 != null) {
            res = property + " " + property_2;
        }
        logger.info("Properyinfo: " + res);

        return res;
    }

The second method is used to reset the local storage of the properties, so that the next time a property is read the whole file will be read again. The third method is used to get the version information of the configuration file which is build as the concatenation of two properties.

On a page we add a button to reset the properties in the application scoped bean. After this the configuration file will be read again.

<af:button text="Read Configuration again" id="b1"
 actionListener="#{ReadPropertyFileBean.rereadActionListener}"
 partialSubmit="true"/>

Finally we add an outputText component to the page which uses an EL to read the PropertyVersionInfo from the application scoped bean ‘ReadPropertyFileBean’

<af:outputText id="ot6" inlineStyle="font-size:small;" 
 value="#{ReadPropertyFileBean.propertyVersionInfo}"
 partialTriggers="b1"/>

When we run the application we see the inital screen like

Initial index.jsf

Initial index.jsf


we change the configuration file
Changed Configuration File

Changed Configuration File


and reset the properties via a click on the button
Changed index.jsf

Changed index.jsf

This concludes part 1. In the final 2nd part we see how to change the fixed path set as context parameter in web.xml during deployment. This allows us to deliver a properties file together with the application but let the administrator decide where to put it on the server.

The work space for this sample can be downloaded from GitHub BlogReadConfigFile Release 1.0 or get the zipped workspace of this release 1.0
The sample is build using JDeveloper 12.1.3 and uses the HR DB schema.

JDeveloper 12.1.3: Using File Templates

Since JDeveloper 12.1.2 Oracle added a feature called ‘File Templates’. Only there was absolutely no documentation for this. We only had the ‘File Templates’ node in the preferences. I filed a bug (ADFEMG-150) for this.
In the current JDeveloper 12.1.3 release the ‘inital’ documentation for the ‘File Templated’ has been added.
To get to the ‘File Templates’ via the Tools->Preferences->’File Tempalates’ and see the below image.

File Templates in Preferences

File Templates in Preferences


Loading the extension you get
FileT emplates Inital Dialog

File Templates Inital Dialog


The only help I found can be reached by clicking the Help button in the dialog which will get you
File Templates Help

File Templates Help


This is not much to work with. I you find more help on using this feature, drop me a note, please. All I present in this blog was found out using try and error. There seams to be a difference if you use a Windows or Unix based machine. Later in the blog I’ll give more info on this.

Let’s start with my findings. Clicking through the tree shown in the image above you quickly get the intention of the file templates. This feature allows us to define template for files (e.g. java classes) which can be used to define repeating code and generate the files from it. The sample which is provided by Oracle builds a template for a java class containing copyright and licence information.


However, there is no button or menu to create your own template from scratch. The pencil icon in the top right corner is disabled for each of the files. The only way to create a new template file is to copy an existing one by using the ‘Copy’ button. The first time you click the copy button for one of the files in the you get a note that you can’t change the files in place:
Confirm Modify Template

Confirm Modify Template


confirming the dialog with yes, a copy the content of the sample template from the jar will be created into a file you can edit. All custom template files are written to system12.1.3.0.41.140521.1008\o.jdeveloper.filetemplate\ folder by default. While copying the files you can change the ID, description, the Name and the file name of the template.

Please not the properties in the dialog which allows to define where you later find the template in the gallery.
Once we have copied all files from the tree we can start to modify them. The file suffix of the templates is ‘ftl’. The copied files are automatically opened in the JDev editor. Here comes the first glitch in the extension. If you change *.ftl files in the JDev editor and hit the ‘Save All’ button, the files are not saved. The caption of the tabs remains italic, meaning that the content of the tab has changed and is not saved. You need to hit the ‘Save’ button to save each file by itself.
Once the templates are copied into an accessible path, you can use the ‘Pencil’ button to open them again in the JDev editor, or you can make small changes directly in the editor window in the dialog.
Looking at the content of the files you see that ‘copyright-hahn-java.ftl’ inludes ‘license-hahn-txt.ftl’ which then includes ‘copyright-hahn-content.ftl’. This is the first file we change to change the copyright notice
Changed Copyright Text

Changed Copyright Text


To make the licence ‘license-hahn-txt.ftl’ pick up the changes copyright text we have to change the include statement in the licence template
Change Include  of Copyright in Licence Template

Change Include of Copyright in Licence Template


and finally we have to change the ‘copyright-hahn-java.ftl’ to pickup the changes licence template
Change Include of Licence in Template

Change Include of Licence in Template


After saving all changes (remember to save each file separately) we can test the template. For this we select a package in a project, right click the package we want the file created in and select ‘New’->’From Gallery…’
Select 'New'->'From Gallery...'

Select ‘New’->’From Gallery…’


When we save the java call template we saved the information where the template shows up via the ‘Category’, ‘Folder’ and ‘Feature’ properties of the template dialog (these properties define where the template shown up in the gallery). Select ‘Java’ and you should see
Select the Template from the Gallery

Select the Template from the Gallery


Please notice the name which is the ID we chose for the template and the description which comes from the save dialog too. Select the template and you get the file save dialog
File Save Dialog

File Save Dialog


In the JDev editor you get the generated java class
Generated Class from Template

Generated Class from Template


Please note the error in line 26 of the generated java class

package de/hahn/blog/test1213/.model/adfbc/;

should be

package de.hahn.blog.test1213.model.adfbc;

This only happens on Windows machines, Unix machines generate the right package statement. You have to correct this yourself. I’ll file an bug this.

Now that we have seen this sample, let’s ask what’s missing.

    1) Documentation: if you look at the templates you seethe usage of variables in the templates like ‘${name}’ or ‘${package}’, however, I could not find if there any other valuables as the once you see in the sample. Same is true for the language behind the template mechanism. The sample show some kind of ternary operator, question is what other options do we have. The file suffix ‘.ftl’ and some other information I gathered for this blog post, suggests that the templates are using a tool named ‘FreeMarker’.
    2) Use cases: I would like to use templates at other points like java classes generated for ViewObjectImpl, EntityObjecImpl or ApplicationModuleImpl. This is not possible right now. It would be handy e.g. to generate files with ADFLogger directly implemented. You can insert the ADFLogger into the class using the template, but as this is only done for classes you create via the template most of the other generated classed need to be changed by hand.
    3) applying the template to an existing class is not possible. If you like a copyright statement in each class you can’t attach it from a template.

Problem Installing MAF on WIN 7 64bit System

Aside

The documentation states that installing JDeveloper 12.1.3 on a Windows 7 system (32 or 64) requires administrators rights (Select an Installation User). This is a known fact.
A side effect on my Windows box was, that installing ‘Mobile Application Framework’ (MAF) failed. When I tried installing MAF on my Win 7 laptop via ‘Check for updates’ and confirming the dialog which ask for a restart of JDeveloper, it never came back on. Using the task manager, it turned out that JDeveloper started but that there are other processes waiting for something.
Using some System Internal’s tools I found out that Jdev started opatch to install a needed patch before applying the MAF extension. As the processes are started from Jdev internally, it’s kind of hard to find out the real problem. Readings the doc and searching the file system found a log file, opatch writes into the opatch log folder. The information from this log is that opatch can’t lock or create a folder needed for internal use.

[04.07.2014 19:49:58]        OUI-67064:OPatchSession kann den Bestand für das angegebene Oracle-Standardverzeichnis nicht laden R:\JAVA\12130~1.0\ORACLE\MIDDLE~1. Mögliche Ursachen sind:
                                Keine Lese- oder Schreibberechtigung für ORACLE_HOME/.patch_storage
                                Zentrales Bestandsverzeichnis ist von einer anderen OUI Instance gesperrt
                                Keine Leseberechtigung für zentrales Bestandsverzeichnis
                                Die Lock-Datei ist in ORACLE_HOME/.patch_storage vorhanden
                                Das Oracle-Standardverzeichnis ist in dem zentralen Bestandsverzeichnis nicht vorhanden
[04.07.2014 19:49:58]        OPatch will clean up 'scratch,backup' directories.

Here is the english message

[04.07.2014 19:57:34]       OUI-67064:OPatchSession cannot load inventory for the given Oracle Home R:\JAVA\12130~1.0\ORACLE\MIDDLE~1. Possible causes are:
                                No read or write permission to ORACLE_HOME/.patch_storage
                                Central Inventory is locked by another OUI instance
                                No read permission to Central Inventory
                                The lock file exists in ORACLE_HOME/.patch_storage
                                The Oracle Home does not exist in Central Inventory

The problem is that installing Jdev as administrator put rights onto the file system (Understanding User Permissions) which prevents creating and locking the folder for the normal use running Jdev. This fact can be found in the doc too

When managing a product installation (for example, applying patches, or starting Managed Servers), you must use the same user ID as was used to perform the initial product installation.

To fix the problem start Jdev as administrator and the installation of the MAF extension should work.

JDeveloper 12.1.3 is out!

Oracle JDeveloper 12cR1 aka JDeveloper 12.1.3 finally arrived. We had to wait almost a year for this version.
From my first day working with it I can say that it was time well spent. Some nasty bugs from version 12.1.2 are fixed, others still need checking. This will take me a couple of days.
I spare you listing all new features which you can find at ‘What’s new’.

You can download the version from the JDev home page.

Interestingly there are only three install packages, one for Windows, one for Linux and the generic installer. The platform specific install packages are only for 64 bit systems. A look into the certification matrix shows that 32 bit systems are only listed under ‘Other Operating Systems’. I’m not sure if this means that you can’t run this version on 32 bit Windows, or if 32 bit Windows is just ‘others’. I don’t have a 32 bit OS available, do I can’t test this. However, to install on a 32 bit system you have to download the generic installer (size 1.8GB).

The installation went smooth, under 1 minute on my 64GB i7 server with a big SSD running Ubuntu 14.04!
Be advised that some things in the configuration have changed. Stuff you are used to change in Jdev.conf (like jdk) has been moved to a new file product.conf which is stored at your home/.JDeveloper folder. This makes it easier to change the configuration like setting the ide.user.dir and some memory options. More information on this can be found in the ‘Installation Guide’.

It’s going to be a busy weekend checking out all the new stuff. Have fun using Jdev 12.1.3!

Installing JDeveloper 11.1.1.7.0 from the Generic Installer Jar on 64bit Windows System

If you have installed JDev 11.1.1.7.0 lately, which I strongly recommend, you may have noticed, that the windows installer jdevstudio11117install.exe still ships with jdk160_24. Please don’t ask why Oracle don’t includes a JDk 1.7, I don’t know.
Well, it’s time to use JDK1.7 on my WIn7x64 system so I loaded hte jdevstudio11117install.jar which is a lot bigger (1.9GB) but comes without a bundeld JDK. As I have already installed JDK 1.7.0_17 on my system I pointed the installation to this jdk when I asked during the installation.
Everything went smooth and i took only a couple of minutes to install JDev and generate the embedded WLS 10.3.5 instance.

However, when I tried to start the embedded WLS instance I got the following error message

*** Using port 7101 ***
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\startWebLogic.cmd
[waiting for the server to complete its initialization...]
.
.
JAVA Memory arguments: -Xms256m -Xmx512m
.
WLS Start Mode=Development
.
CLASSPATH=...
.
PATH=...
.
***************************************************
*  To start WebLogic Server, use a username and   *
*  password assigned to an admin-level user.  For *
*  server administration, use the WebLogic Server *
*  console at http:\\hostname:port\console        *
***************************************************
starting weblogic with Java version:
<strong>Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized option: -jrockit</strong>
Starting WLS with line:
...
Process exited.

Hm, ‘Unrecognized option: -jrockit‘, how’s that? I’m running Sun JDK!
Right at the beginning of the server start we see the command used to start the server (the path may be different on your system)
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\startWebLogic.cmd
A look into this command shell reveals that another command shell script is called
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\setDomainEnv.cmd
In this script we find the problem

...
set BEA_JAVA_HOME=C:\Program Files\Java\jdk1.7.0_17

set SUN_JAVA_HOME=


if "%JAVA_VENDOR%"=="Oracle" (
	set JAVA_HOME=%BEA_JAVA_HOME%
) else (
	if "%JAVA_VENDOR%"=="Sun" (
		set JAVA_HOME=%SUN_JAVA_HOME%
	) else (
		set JAVA_VENDOR=Oracle
		set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_17
	)
)
...

As you see hte BEA_JAVA_HOME is set and if you put an
echo %JAVA_VENDOR%
before the if statement you see that the vendor is null. This sets the JAVA_HOME correct, but sets the JAVA_VENDOR to ‘Oracle’. This then adds the wrong option -jrockit to the command line later on in the startWebLogic.cmd script.

Now that we know that the solution is to make a small change to the
r:\jdeveloper\system\system11.1.1.7.40.64.93\DefaultDomain\bin\setDomainEnv.cmd
script. We only have to set the SUN_JAVA_HOME and set the JAVA_VENDOR to ‘Sun’

set BEA_JAVA_HOME=

set SUN_JAVA_HOME=C:\Program Files\Java\jdk1.7.0_17
set JAVA_VENDOR=Sun

After this change the embedded WLS server starts without a problem.

JDeveloper 11.1.2.2.0: First trap when installing a new JDeveloper version

One of my tasks is to evaluate new JDeveloper versions. I have to say that it’s one of the tasks I really do like as I get the chance to try out new things :). OK I have to check if current applications are still running first.

I started installing JDev 11.1.2.2.0 on my development machine, checked out the sources of the current applications and started compiling them and building adf libraries. At one point I got the below error message:

Error: An unreported error occurred in Appc. No errors were reported, but the tool returned a failure result code: 1.
Warning: <11.05.2012 16:40 Uhr MESZ> <Error> <J2EE> <BEA-160141> <Could not initialize the library C:\..\..\..\oracle_common\modules\oracle.jsf_2.0\jsf-ri-20.war. Please ensure the deployment unit is a valid library type (war, ejb, ear, plain jar). \..\..\..\oracle_common\modules\oracle.jsf_2.0\jsf-ri-20.war (Das System kann den angegebenen Pfad nicht finden) with : \..\..\..\oracle_common\modules\oracle.jsf_2.0\jsf-ri-20.war>
Warning: <11.05.2012 16:40 Uhr MESZ> <Error> <J2EE> <BEA-160187> <weblogic.appc failed to compile your application. Recompile with the -verbose option for more details. Please see the error message(s) below.> 
Warning: [J2EE:160147]One or more libraries could not be processed. See error above.

Interestingly the message complains about a war file ‘jsf-ri-20.war’ at a location which I never use for JDev. I never install JDev on drive C on a Windows system. All applications are installed on a different drive (P in my case). The reason for this is the the ‘system11.1.2.2.39.61.83.1’ folder was created in my personal ‘application data’ folder which resides on drive C. As this path has spaces on my Windows system I normally move the ‘system11.1.2.2.39.61.83.1’ on drive P. To archive this I set the environment variable JDEV_USER_DIR to ‘P:\jdeveloper\system’. When starting JDev the next time the ‘system11.1.2.2.39.61.83.1’ is generated in the folder ‘P:\jdeveloper\system’.

After this change I tried again and got the same error, only this time the path started with ‘P’. The path to the jar file C:\..\..\..\oracle_common\modules\ made me think again. This path is normally part of the ADF Runtime installation on a WLS server. In this case the integrated WLS which comes with JDev.

Well, at the time I tried to compile a project containing an ADF Task-Flow into an adf library. Interestingly the rebuild process somehow needs access to the ‘jsf-ri-20.war’. Problem is that I had not created the integrated WLS. This is done the first time you start the integrated WLS (debug or normal).

After starting the integrated WLS the first time the path gets created and my ADF Task-Flow compiles OK.

I installed JDev in various version hundreds (more or less) of times but never stumbled upon this.