Skip to Main Content

SQLcl

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

sqlcl 18.4 unsupported major.minor number 52.0

daniel_haukeJan 28 2019 — edited Aug 30 2019

Hi everybody,

i downloaded tht sqlcl version 18.4. When i try to start the sql command i get the following error:

Exception in thread "main" java.lang.UnsupportedClassVersionError: oracle/dbtools/raptor/scriptrunner/cmdline/SqlCli : Unsupported major.minor version 52.0

I know that this error is due to different version of java in our os and ORACLE_HOME. For some reason this version prefers the java from our ORACLE_HOME and not the java which is set in our PATH Variable.

Even if i set the $JAVA_HOME/bin at the beginning of our PATH the error occurs. I didn't get this error with the sqlcl 18.2.

The only way i found out is to unset our ORACLE_HOME. Then the  JAVA_HOME Variable is taken by the tool and i am able to start the sqlcl.

But unseting our ORACLE_HOME is not really an alternative for me.

So can anyone perhaps provide me a different workaround? Is it possible to tell sqlcl which java the tool should use to start?

Any tipp is appreciated!

Greetings Daniel

Comments

843842
Hi,

First, you cannot access a JSF page without going through the JSF Servlet.

Your JSF tags will not be translated into html tag, this will generate an error page.

you can specify the matching url that you want to send through the Servlet.
here is a chunk of one of my web.xml file.
  <!-- Standard Action Servlet Mapping -->
  <servlet-mapping>
    <servlet-name>FacesServlet</servlet-name>
    <url-pattern>*.faces</url-pattern>  
  </servlet-mapping>
Furthermore,

you can also disallow access to some directories, but, i'm not using this technique now and i can't tell you if it's an usual technique.

Anyone correct me if i'm wrong.



Sebastien Degardin.
843842
Thanks for the reply.

I understand how servlets are mapped. What I'm trying to figure out is how the FaceServlet translates a faces url into a JSP page. (ie. where is looks, what names it looks for etc.)

For example, with the mapping example you showed (*.faces), If I made made a call to http://server/myapp/mypage.faces, what would FacesServlet serve up? A jsp file called mypage.jsp? If so, where does it look for such a jsp?

In the example I was talking about before the mapping was /faces/*, which seemed to have the effect of just serving up all /faces/* paths with matches relative to the root of the application. For example, if i had a jsp in /mypage.jsp I could just called /faces/mypage.jsp and it would work. However, this also allowed me to access /faces/WEB-INF/web.xml which I not good (security problem IMO). An that was with a Java BluePrints application!

My question still remains. How can i tell FacesServlet where to look for pages, and stop things like the secrutiy problem above?

Thanks in advance,
Robert.
843842
Well after reading lots more stuff on faces it seems that faces always just looks in the root of your application for a match, and if you dont like it to always look for jsp files (for example if you want it to look for jspx) you can do something like this for the RI:

<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.jspx</param-value>
</context-param>

Still not sure about that whole being able to access WEB-INF thing :S. Instead i'm just using a *.faces mapping rather than /faces/*.
843842
Hello,

That's how i'm doing too.

faces ---> FacesServlet ----> JSP View

source suffixe ans target are configurable in web.xml file.


Sebastien Degardin
1 - 4

Post Details

Added on Jan 28 2019
9 comments
3,477 views