This content has been marked as final. Show 17 replies
What is the version of Java Virtual Machine (JVM) installed on the client? Downgrade your client-side JVM, and see if that solves the issue. I'm using a way older version (version 6 update 27).
I am using Java JDK 1.6.0 update 33 on the Server and my local machine is running 1.6.0 update 32.
I will try to find an older version to install to my local machine.
By the way, my Server is running on Solaris.
No real concern on the server side. The client side JVM (whatever the user's browser is using) is the likely culprit.
I have tried downgrade my client-side JRE to version 6 update 27.
I got the same error message.
I have also tried to upgrade the client JRE to version 7 update 5.
I still got the same error message.
Any ideas, please?
By the way, in any JRE version, I have no issue using the Admin Applets in the other UCM 10g instances I have on the same server.
Edited by: user6502585 on Aug 3, 2012 10:48 AM
Have you tried to access the content server by IP address instead of a host name?
Also, is there anything funky being done to the idcplg path?
I have tried using https and http, with IP or host name, all combinations returned the same error message.
To the best of my knowledge, nothing funky is performed on the idcplg path or the Intradoc.cfg file.
I completed the in-place upgrade process outlined by the Oracle Document.
Then, I started testing the basic functionality one by one.
Search, Check-In, Update DocInfo, IBR were working fine until I tried to access the Admin Applet in the browser.
In the 11g instance, take a look in the "weblayout\common" directory, and see if the file "idcapplet.jar" file exists. if not, that's the issue.
If it DOES exist, check the permissions on the file. It's likely the file system permissions are wrong.
It's too bad that the file does exist in the directory.
It belongs to the same user I used to install the Oracle Software.
The user and group owner are the same as the rest of the 11g directory.
Try directly downloading the jar file - -see if that errors. You should get prompted for a download.
Yes, I could download the file with the URL you suggested.
The downloaded file has the same size as the one on the server, so I believe they are the same file.
Caused by: intradoc.common.ServiceException: !syFileUtilsFileNotFound,(null)at intradoc.client.UrlClient.doURLRequest(UrlClient.java:298)>
That bit of code logic looks for only either a 403 or a 404 response code (403 being "forbidden" and 404 being "page not found"). The system is explicitly getting a 404 error passed to it, but the download test you just did shows that the file exists, and can be downloaded.
I have to wonder if the jar is messed up. My file size is 3.16 MB (3,318,627 bytes) for 11g. Yours close to that?
Also, try dumping your Java temp cache on your local machine. This is not the same as your temporary internet files. You have to go into the Java console control in Windows Control Panel to do it.
Also.. I hope you are aware that having your content server deployed under anything but /cs/ is not a supported configuration for 11g at the moment.1 person found this helpful
The only supported configuration for HttpRelativeWebRoot is to be "/cs/"
I've never done the in-place upgrade, but it is never a good idea to begin with.
What is your HttpRelativeWebRoot at the moment?
I suspect you had your content server deployed under something like /idc ?..
Try using Fiddler to see where it tries to pull the jar file from when you try to load the applet.
Let us know.
Yes, the file is the same size as yours, 3318627 bytes.
I tried clear the Java Console cache and access the Admin Applet page.
I now only have 6 image files and the "idcapplet.jar?SHA-256%......" in the Java Cache Viewer.
Still, the same error.
Well, since I am upgrading from 10g, my URL is not "/cs/".
It is "/contrib/".
It seems to be running just fine when I tested the upgrade process on my Window 7 box with "/contrib/".
I would only see the URL changed to "/cs/" when I login through the WebLogic Server.
If "/cs/" is the only supported configuration, then wouldn't the whole in-place upgrade process with UA be a hoax?
I would think not many 10g instance would be named "/cs/".
I will try Fiddler to pull more details on the error.