Friday, December 23, 2016

RCU:6107 DB Init Param error

RCU:6107 DB Init Param error


While Installing Repository Creation Utility (RCU) Installation the following error occurs:
RCU:6107 DB Init Param Error
This can be removed simply by the following:
1. Login on your database with system user.
2. Write > show parameters processes (which will show the current value of processes).
3. If its value is less than 500 then write the following command:
ALTER SYSTEM SET PROCESSES=500 SCOPE=SPFILE;
4. Write > show parameters open_cursors (which will show the current value of open_cursors).
5. If its value is less than 500 then write the following command:
ALTER SYSTEM SET OPEN_CURSORS=500 SCOPE=SPFILE;
6. Restart your DB or system.
7. Start the installation now….
There will be no error…..

source: https://mhabib.wordpress.com/2010/07/20/rcu6107-db-init-param-error/

Thursday, December 1, 2016

Javascript - JSP not able to find .js file.

I was trying to create a simple web project and was starting to learn JavaScript.
I was suggested to created all JS functions in a .js file and import in to the JSP file, so as the code will be clean and it would be best practise.

But I was facing some issues when I did the following.
<script type="text/javascript"  src="/js/index.js"></script>

This is what I tried. The issue I faced is that my script is not running, which means that the .js file is not being found at runtime.


After some googling, I came to know that I should use like below.
<script type="text/javascript"  src="${pageContext.request.contextPath}/js/index.js"></script>




Explanation given on the internet:

Put the JS file in a folder under web content (but not WEB-INF) like [WebContent]/js/jsgl.min.js, and use the following in the JSP:
<script type="text/javascript" src="${pageContext.request.contextPath}/js/jsgl.min.js"></script>

Explanation
JSP files are compiled by the server, then processed to send data (typically HTML) back to the web browser. A <script> tag is a HTML tag that gets interpreted by the browser, not by the servlet container. So the browser sees that in the HTML then makes a new request to the server for the JavaScript file in the src attribute.
The src attribute is relative to the URL that the browser asked for, not to the path of the JSP on the server.
So as an example, let's say:
  • The browser asks for a page at http://example.com/SomeWebApp/some-resource
  • The servlet container internally forwards the request to a JSP at /WEB-INF/jsp/somepage.jsp
  • The response sent to the browser contains the script tag <script type="text/javascript" src="./jsgl.min.js"></script> (as in your question)
  • The browser sees the URL ./jsgl.min.js and resolves it relative to the URL it has asked the server for (which in this case was http://example.com/SomeWebApp/some-resource - note there is no trailing '/') so the browser will request the JS file from http://example.com/SomeWebApp/jsgl.min.js*. This is because the relative URL in the script tag's src attribute starts with a '.'.
Another answer suggested putting the JS file in a 'js' folder and changing the script tag to <script type="text/javascript" src="/js/jsgl.min.js"></script>. Using the same original page URL as in the example above, the browser would translate this src URL to http://example.com/js/jsgl.min.js. Note that this is missing the "/SomeWebApp" context path.

The best solution therefore is indeed to put the JS file in a static folder like /js/jsgl.min.js, but to use the following in the JSP script tag:
<script type="text/javascript" src="${pageContext.request.contextPath}/js/jsgl.min.js"></script>

The JSP will translate the ${pageContext.request.contextPath} bit into the current context path, making the code portable (if you redeploy the webapp with a different context path, it will still work). So the HTML response received by the browser will be (again, sticking with our example above):
<script type="text/javascript" src="/SomeWebApp/js/jsgl.min.js"></script>
The browser will now resolve that relative URL to the correct targe