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.

Advertisements

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.

FATAL ERROR when upgrading to WLS 10.3.3

In one of my last posts (https://tompeez.wordpress.com/2010/05/01/upgrade-an-existing-wls-10-3-2-to-wls-10-3-3/) I talked about the process of upgrading an existing WLS 10.3.x server to version 10.3.3.
One minor bug or glitch came up when I tried the procedure on one of the customers WLS servers.
Right befor the upgrade process starts we got a ‘FATAL ERROR’ from the installer. No log where written, nothing unusual I could think of.
After trying it out a couple of times, the last try I used JRockit instead of the configured Sun JDK and bingo I got an error message too. The big difference this time it told me that the free space on one of the partitions was too small.
Removing some old stuff from the partition solved the problem.