JDeveloper 12c error javax.naming.NameNotFoundException: While trying to lookup 'jdbc.LocalSvcTblDataSource'

Today I noticed mysterious error when I run any web application in my JDeveloper 12.2.1. This is the stack trace:

[ecid: badadddc-e435-47c7-9b26-b7a8c0331704-00000048,0] [partition-name: DOMAIN] [tenant-name: GLOBAL] CCW auto-republish services error [[
com.oracle.cie.servicetable.external.ServiceTableException: javax.naming.NameNotFoundException: While trying to lookup 'jdbc.LocalSvcTblDataSource' didn't find subcontext 'jdbc'. Resolved ''; remaining name 'jdbc/LocalSvcTblDataSource'
 at com.oracle.cie.servicetable.impl.ServiceTableImpl.getOnlineLocalServiceTableConnection(ServiceTableImpl.java:99)
 at com.oracle.cie.servicetable.impl.ServiceTableImpl.getLocalConnection(ServiceTableImpl.java:223)
 at com.oracle.cie.servicetable.impl.ServiceTableImpl.query(ServiceTableImpl.java:405)
 at com.oracle.cie.servicetable.impl.ServiceTableImpl.query(ServiceTableImpl.java:379)
 at oracle.as.ccw.jmx.CCWCache.autoRePublish(CCWCache.java:320)
 at oracle.as.jmx.framework.wls.spi.WLSInternalEventsListener.processEditSessionChanges(WLSInternalEventsListener.java:376)
 at oracle.as.jmx.framework.wls.spi.WLSInternalEventsListener.handleEvent(WLSInternalEventsListener.java:198)
 at weblogic.management.eventbus.spi.InternalEventBusImpl.send(InternalEventBusImpl.java:75)
 at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.doCommit(RuntimeAccessDeploymentReceiverService.java:574)
 at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.commit(RuntimeAccessDeploymentReceiverService.java:435)
 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.commit(DeploymentReceiverCallbackDeliverer.java:64)
 at weblogic.deploy.service.internal.statemachines.targetserver.AwaitingCommit.callDeploymentReceivers(AwaitingCommit.java:266)
 at weblogic.deploy.service.internal.statemachines.targetserver.AwaitingCommit.handleCommit(AwaitingCommit.java:121)
 at weblogic.deploy.service.internal.statemachines.targetserver.AwaitingCommit.receivedCommit(AwaitingCommit.java:44)
 at weblogic.deploy.service.internal.transport.CommonMessageReceiver.receiveRequestCommitMsg(CommonMessageReceiver.java:597)
 at weblogic.deploy.service.internal.transport.CommonMessageReceiver$3.run(CommonMessageReceiver.java:883)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:643)
 at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
 at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
 at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
 at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
 at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:617)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
Caused by: javax.naming.NameNotFoundException: While trying to lookup 'jdbc.LocalSvcTblDataSource' didn't find subcontext 'jdbc'. Resolved ''; remaining name 'jdbc/LocalSvcTblDataSource'
 at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1224)
 at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:268)
 at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:217)
 at weblogic.jndi.internal.BasicNamingNode.lookupIgnorePartition(BasicNamingNode.java:1503)
 at weblogic.jndi.internal.PartitionHandler.lookupSharable(PartitionHandler.java:88)
 at weblogic.jndi.internal.ServerNamingNode.lookup(ServerNamingNode.java:584)
 at weblogic.jndi.internal.RootNamingNode.lookup(RootNamingNode.java:81)
 at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:307)
 at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:430)
 at javax.naming.InitialContext.lookup(InitialContext.java:417)
 at com.oracle.cie.servicetable.util.JdbcUtil.getOnlineLocalSvcTblConnection(JdbcUtil.java:383)
 at com.oracle.cie.servicetable.impl.ServiceTableImpl.getOnlineLocalServiceTableConnection(ServiceTableImpl.java:92)
 ... 24 more

]]

After long investigation ... Eureka ... The missing datasource isn't associated with concrete web application. This is built-in "feature":) caused by the fact that the default Derby Server supplied with JDeveloper 12c is not running.

But what is the reason the Derby is not starting?

It turned out that the cause of error is upgrade of JDK. In JDK 7U51 (and above) the default socket permissions assigned to all code including untrusted code have been changed. This was described here: http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html.

But how to resolve this issue?

The simplest way is modyfying Derby start scripts. In my case I need find startNetworkServer.bat which is located in:

%WL_HOME%\common\derby\bin\startNetworkServer.bat

In this script you should modify line:

"%_JAVACMD%" %DERBY_OPTS% -classpath "%CLASSPATH%;%LOCALCLASSPATH%" org.apache.derby.drda.NetworkServerControl start %DERBY_CMD_LINE_ARGS%

replacing it by:

"%_JAVACMD%" %DERBY_OPTS% -classpath "%CLASSPATH%;%LOCALCLASSPATH%" org.apache.derby.drda.NetworkServerControl start -noSecurityManager %DERBY_CMD_LINE_ARGS%

In Linux/Unix systems you need find script startNetworkServer, and modified line should looks like:

derby_exec_command="exec \"$JAVACMD\" $DERBY_OPTS -classpath \"$LOCALCLASSPATH\" org.apache.derby.drda.NetworkServerControl start -noSecurityManager $@"

• There is also the better solution. You can edit the "java.policy" file: 
• Locate the directory of your JDK. 
• Navigate to the directory: /jre/lib/security 
• Open the file "java.policy" in an editor 
• Add following line to the already present grants: 

• permission java.net.SocketPermission "localhost:1527", "listen"; 

• Save the file. 
• Restart the integrated WebLogic server.

Ok. And here's the puzzle: Why I prefer worse (first) solution ... ?

class.getResources()

getClass().getResource()

searches relative to the .class file while

getClass().getClassLoader().getResource()

searches relative to the classpath root.

To obtain current path you can run

public game(){
    String currentPath = this.getClass().getResource("").getPath();
    System.out.println(currentPath);
}

or respectively

public game(){
    String currentPath = this.getClass().getClassLoader().getResource("").getPath();
    System.out.println(currentPath);
}

WebcenterSites Failed gateway redirect java.io.UnsupportedEncodingException: Redirect failed due to illegal URL http://192.168.0.100:7007/sites/wem/fatwire/wem/Welcome

Sometimes after installation and configuration of Webcenter Sites, when we try to log in, we get the 500 error with message:

javax.servlet.ServletException: Failed gateway redirect java.io.UnsupportedEncodingException: Redirect failed due to illegal URL http://172.31.129.214:7007/sites/wem/fatwire/wem/Welcome
 at com.fatwire.wem.sso.cas.filter.CASFilter.sendResponse(CASFilter.java:681)
 at com.fatwire.wem.sso.cas.filter.CASFilter.doFilter(CASFilter.java:598)
 at com.fatwire.wem.sso.SSOFilter.doFilter(SSOFilter.java:51)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
 at COM.FutureTense.Security.Common.ContentSecurityFilter.doFilter(ContentSecurityFilter.java:88)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
 at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:141)
 at java.security.AccessController.doPrivileged(Native Method)
 at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
 at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:649)
 at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:124)
 at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:232)
 at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:94)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
 at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:224)
 at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
 at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3654)
 at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3620)
 at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:326)
 at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:196)
 at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203)
 at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71)
 at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2423)
 at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2280)
 at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2258)
 at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1626)
 at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1586)
 at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:270)
 at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
 at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
 at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
 at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
 at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:617)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:397)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

To resolve this issue you should check, if ESAPI.properties file (in the {install directory}/bin directory) contains a line for Validator.Redirect. By default this line is set to: Validator.Redirect=^.*$

If it's all ok with ESAPI.properties file, in the next step you should verify Sites server stdout log to see from which location the ESAPI.properties file was read. The log can looks like:

Attempting to load ESAPI.properties via file I/O.
Attempting to load ESAPI.properties as resource file via file I/O.
Found in 'org.owasp.esapi.resources' directory: /oracle/fmw/wcportal/common/lib/ESAPI.properties
Loaded 'ESAPI.properties' properties file
SecurityConfiguration for Validator.ConfigurationFile not found in ESAPI.properties. Using default: validation.properties
Attempting to load validation.properties via file I/O.
Attempting to load validation.properties as resource file via file I/O.

If the file is found before finding it in the classpath, remove that file, to make sure it is only found in the classpath (in the {install dir}/bin directory). When the valid log should looks like:

Attempting to load ESAPI.properties via file I/O.
Attempting to load ESAPI.properties as resource file via file I/O.
Not found in 'org.owasp.esapi.resources' directory or file not readable: /path/to/appserver/bin/ESAPI.properties
Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
Not found in 'user.home' (C:\Users\sdasilv) directory: /home/myUser/esapi/ESAPI.properties
Loading ESAPI.properties via file I/O failed. Exception was: java.io.FileNotFoundException
Attempting to load ESAPI.properties via the classpath.
SUCCESSFULLY LOADED ESAPI.properties via the CLASSPATH from '/ (root)' using current thread context class loader! 

Check the directories in the CS application's and appserver's classpath and make sure there is no other instance of ESAPI.properties elsewhere in the classpath.