Data Browser receives HTTP 500 error

Starrjos

Starrjos

Active Member
Recently we upgraded our tools from 8.96.1.5 to 8.98.0.2. We brought up DV and PY (mulitifoundation) without any major issues. Data Browser works fine for both environments and PD 8.96.1.5 worked fine as well. As soon as we pushed out the new tools via SM everything seemed ok until a few days ago when we attempted to use the data browser. We received the ole http 500 error!

Here is the message I found in the log.

09/03/24 16:44:44.441 webclient: 10.1.3.1.0 Started

09/03/24 16:45:52.34 webclient: JspServlet: unable to dispatch to requested page: Exception:eek:racle.jsp.parse.JspParseException: /databrowser
/ChooseTarget.jsp: Line # 18, <%@taglib prefix="webgui" uri="http://java.peoplesoft.com/e1/webgui"%>

Error: "http://java.peoplesoft.com/e1/webgui" is not a registered TLD namespace.

09/03/24 16:56:13.510 webclient: JspServlet: unable to dispatch to requested page: Exception:eek:racle.jsp.parse.JspParseException:
/databrowser/ChooseTarget.jsp: Line # 18, <%@taglib prefix="webgui" uri="http://java.peoplesoft.com/e1/webgui"%>

Error: "http://java.peoplesoft.com/e1/webgui" is not a registered TLD namespace.



Oracle wants me to upgrade to 8.98.0.5 tools but for some reason they are not comprehending that DV and PY data browsers work just fine. Only PD. There was a folder missing _databrowser within the persistence\pages folder. One fix recomended copying one of the working folders over from dv or py but that did not fix the problem.

Any recomendations would be greatly appreciated if you have run into this problem previoulsy.

Regards,

Joe Starr
Business Systems Analyst

E1 v8.10
Tools v8.98.0.2
SQL 2005
Windows Server 2003
Citrix
OAS
 
We saw this too.

we fix it by deleting and redeploying the JAS instance from scratch.

What we found was the DataBrowser java file has extra includes in it when compared to a working instance. However changing the files to match did not fix it.
 
Just had the same result by re-creating the OAS j2ee continer as well as the E1 HTML instance. The only difference was the JDBC driver was deployed to the j2ee container prior to the HTML instance deployment from server manager...

8.98.2 tools and ERP 9.0 apps...
 
Joel,

How did you finally end up fixing this issue, we now have it also.

Tom
 
Tom,

I ended up removing the jas and html. Everything had to be completely removed. You may need to make sure that the leftover folders are also removed. I suppose you can remove the drivers but I am not really sure why that would matter (see post below).

Just an FYI. I am at a new siteand our PD instance has the same issue. I am about to begin working on this today or tomorrow. Our DV/PY work fine!

I will update this post with the solution for this.

Joe
 
Have a look at the URL constructed by the databrowser, I bet the port number is incorrect. I have seen this error with some customers and its always an incorrect port number.

There is a knowledge garden article to fix this though I can't remember the solution id.

- Jeff
Technical Analyst
www.jdebase.com
 
I've ran into the same issue and had to unistall and reinstall the JAS instances that were having the issue as well. Sometimes I've had to uninstall and reinstall twice to get it working but it eventually did the trick.
 
Just what I need.....to let the hosting company have extra hours uninstalling and re-installing something that should have worked from the beginning really is unacceptable!
 
Hey y'all,

Check out Oracle Doc ID 1070574.1 (link). It talks about how Data Browser displays an Error 500 page after upgrading to Tools Release 8.98.

Basically, the web.xml file may have been corrupted in the process, which is why your reinstalling it may have worked. If not, follow the steps in the Oracle Doc, and see if it helps.
 
We also experienced the issue. I opened a call with Oracle and they suggested I install on a different port number. I suppose this works if you are you not in a clustered environment or if you do not use web cache. Seems like overkill just to upgrade the J2EE layer. As far as I know, reinstalling over a different port would mean the we would have to rebuild the cluster and web cache. I also agree Starrios - provide a product and method to install correctly the first time, especially with the outrageous maintenance fees.
 
Oracles Answer: Data Browser receives HTTP 500 error

They finally came back wiht a JDE ONLY document 881500.1 (just in case they ever release it).

Basically it says do a re-install (exactly what I wanted to do NOT)

I will be doing this this weekend, I'll let you know the results

Tom
 
Re: Oracles Answer: Data Browser receives HTTP 500 error

Tom,

To make the reinstall go a little quicker save off your JAS.INI, JDBJ.INI and necessary HTTPD.CONF files before the uninstall. That way after you install again you can just copy them back in without all the manual setup of those files afterwards.
 
Just change the tools release to ANYTHING other than 8.98.0.2 (like 8.98.2.4)

Then just change it back again to 8.98.0.2.

This is the easiet way to fix annoying issues without uninstalling and reinstalling the instance. The bonus factor is that all of your settings are maintained......including most of the OAS/WAS custom settings that you may have configured.

Colin
 
Hi guy, problems is related to layout customization (update color in jsp or change logo...). I solved this problem copying standard.jar to WEB-INF\lib directory. You can search this file under j2ee\home
good luck
gg
 
Just wanted to report Oracle Doc ID 1070574.1 works. Only thing it doesn't say is which web.xml file to edit. We've got webcache installed and load balancing configured, so there are a few. Browse to: <OAS_10.1.3.1_install_location>\j2ee\<JVM_name>\applications\<JVM_name>\webclient\web-inf

Also, after copying the file to another location and editing, had to put the original file back (restarting services between steps) and data browser began working just fine after using original file and second restart (this will make sense if you read the referenced doc ID). MUCH easier than recreating JVMs.

Cheers!
 
Back
Top