I just updated my Wildfly-8.1.0.Final installation to 8.2.0.Final and deployed my WAR application and ran into deployment error.
It said
ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2)
JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "MYAPPNAME.war")]) -
failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
and then listed all my EJBs in the following manner:
"jboss.deployment.unit.\"MYAPPNAME.war\".component.EJBNAME.CREATE is missing [jboss.security.security-domain.java:/jaas/MYSECURITYDOMAIN]"
When I rolled back to 8.1.0.Final everything worked as expected again.
All my EJBs are declared with #Stateless and there exists an empty beans.xml for CDI there aren't any other special configurations for EJB or CDI except compontents.xml with the following content:
<components>
<component name="org.jboss.seam.core.init">
<!-- JNDI name pattern for JBoss EJB 3.0 -->
<property name="jndiPattern">#{ejbName}/local</property>
</component>
</components>
Has anyone encountered this case and could give me a hint how to resolve it?
Take a look at this Wildfly issue;
https://issues.jboss.org/browse/WFLY-4116
This issue relates to;
"WAR deployment fails on missing security domain dependency"
and contains error traces in the log output that are similar in nature to the ones reported.
Specifically, constructs like;
<jboss-web>
<security-domain>java:/jaas/haa-portal</security-domain>
</jboss-web>
should be replaced with;
<jboss-web>
<security-domain>haa-portal</security-domain>
</jboss-web>
I had a similar issue and the advice in this issue rectified it for me.
Related
As the title says. I have some EJBs in an EAR and I have a client jar providing remote methods to a JSF app also sitting in liberty (different server/machine). The client jar tries to access the remote EJBs via lookup.
This is breaking my heart for two days now. As the title says...
I am aware of other stackoverflow questions from the past and I am aware of the following resources:
https://www.ibm.com/docs/en/was-liberty/core?topic=liberty-using-enterprise-javabeans-remote-interfaces
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
I have tried every combination provided in the above but no joy.
I use (wlp-javaee8.21.0.0.8) with javaee8 feature enabled, this enables everything else I need e.g. ejb-3.2, ejbRemote-3.2, jndi-1.0 and a few others)
I have an EAR my-ear that contains a module my-module-1.0.4-SNAPSHOT.jar which contains my beans. I am using gradle/liberty plugin and IntelliJ.
I am using tests from within IntelliJ in the client jar module to try to access the remote beans.
My myEAR deploys fine and starts up fine and the app shows running in admincenter. In messages.log I see my EJB bindings. Just picking one example.
[16/08/21 10:58:42:384 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
[16/08/21 10:58:42:385 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
my.org.functiona.ejb.advance.MyAdvance [16/08/21 10:58:42:385 IST]
00000022 com.ibm.ws.ejbcontainer.runtime.AbstractEJBRuntime
I CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
java:global/my-ws-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean!my.org.functiona.ejb.advance.MyAdvance
This is my corresponding interface:
package my.org.functiona.ejb.advance;
import javax.ejb.Remote;
#Remote
public interface MyAdvance {
This is my corresponding implementation:
package my.org.functiona.ejb.advance;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
#Stateless(mappedName = "MyAdvance")
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class MyAdvanceBean implements MyAdvance {
Like I said, its breaking my heart. I tried every combination of provided in the (patchy) documentation and other sources. The most progress I made was by accessing "corbaname::localhost:2809/NameService" through a default InitialContext().lookup. So at least I was able to confirm I can gwet through to the NameService. But any subsequent bean lookup using that context with any combination of the names provided in messages.log or in the code snippets from documentation all fail with the exception below.
javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
Same for InitialContext() lookups where I prefix the names with "corbaname::localhost:2809/NameService#".
I tried
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
my.org.functiona.ejb.advance.MyAdvance
and probably a few others
I replaced the # sign with an exclamation mark in all of the above. And went through it again.
I tried corbaloc:: and corbaloc:iiop: for context. Nothing.
I am no web dev expert but this feels very try and error and I dont feel it should be like that. I understand in websphere proper I could identify the names in the admin console but then I'm not even certain websphere proper and liberty behave the same way.
Sine accessing EJBs from remote seems bread & butter stuff I assume I am overlooking something basic and silly due to my inexperience.
Any pointers anyone? Thank you so much for your time reading this.
Carsten
Edit: server.xml
<server description="disbCoreServer">
<featureManager>
<feature>javaee-8.0</feature>
<feature>adminCenter-1.0</feature>
<feature>websocket-1.1</feature>
</featureManager>
<quickStartSecurity userName="admin" userPassword="carsten" />
<!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
<httpEndpoint id="defaultHttpEndpoint"
host="${hostname}"
httpPort="${default.http.port}"
httpsPort="${default.https.port}">
<accessLogging filepath="${com.ibm.ws.logging.log.directory}/accessLog.log" logFormat='%h %i %u %t "%r" %s %b %{R}W' />
<tcpOptions soReuseAddr="true" />
</httpEndpoint>
<include location="appConfXML/disb_core_jndi.xml"/>
<include location="appConfXML/disb_core_jdbc.xml"/>
<include location="appConfXML/disb_core_jms.xml"/>
<include location="appConfXML/disb_core_mail.xml"/>
</server>
The example provided through the FAT test (remoteLookup) works just fine. I just didnt have all my ducks in a row.
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
My scenario is serverA hosting EJBs and serverB running the remote client calling serverA's EJBs.
Steps on serverB are:
Get (local) InitialContext with no properties: InitialContext initialContext = new InitialContext();
With the above lookup the remote Context: Context remoteContext = (Context) initialContext.lookup("corbaname::remotehost:remotePort/NameService");
With the remoteContext lookup the EJB remote interfaces and 'narrow' and cast them to appropriate type
String lookupName = "ejb/global" + "/" + "MyAppName" + "/" + "MyModuleName" + "/" + jndiName;
Object remoteObj = remoteContext.lookup(lookupName);
return interfaceClass.cast(PortableRemoteObject.narrow(remoteObj, interfaceClass));
Where
"MyAppName" is my apps name, the name of the EAR in my case (without .jar)
"MyModuleName" is the name of the EJB module within my EAR (without .jar)
and jndiName is the bean name / fully qualified interface name separated by exclamation mark e.g. "MyBean!myorg.ejb.interfaces.MyBeanIfc"
Call the interfaces to remotely execute serverA EJB code
Note: When running serverA and serverB on the same machine (e.g. localhost) ensure they are not operating on the same port for NameService.
Thanks to everyone who tried to help!
I have an ear file that has a validation.xml file in one of its ejb modules when I want to deploy it on Weblogic 12.2.1, then the Weblogic throws the following exception:
<BEA-000000> <Error parsing validation.xml synchronously
java.lang.IllegalArgumentException: URI is not hierarchical
at java.io.File.<init>(File.java:418)
at org.eclipse.persistence.jaxb.ValidationXMLReader.parseValidationXML(ValidationXMLReader.java:147)
at org.eclipse.persistence.jaxb.ValidationXMLReader.call(ValidationXMLReader.java:67)
at org.eclipse.persistence.jaxb.BeanValidationHelper.parseValidationXml(BeanValidationHelper.java:178)
at org.eclipse.persistence.jaxb.BeanValidationHelper.getConstraintsMap(BeanValidationHelper.java:143)
at org.eclipse.persistence.jaxb.BeanValidationHelper.isConstrained(BeanValidationHelper.java:120)
at org.eclipse.persistence.jaxb.JAXBBeanValidator.isConstrainedObject(JAXBBeanValidator.java:255)
at org.eclipse.persistence.jaxb.JAXBBeanValidator.shouldValidate(JAXBBeanValidator.java:206)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.validateAndBuildJAXBElement(JAXBUnmarshaller.java:235)
at org.eclipse.persistence.jaxb.JAXBUnmarshaller.unmarshal(JAXBUnmarshaller.java:640)
at org.hibernate.validator.internal.util.privilegedactions.Unmarshal.run(Unmarshal.java:38)
at org.hibernate.validator.internal.util.privilegedactions.Unmarshal.run(Unmarshal.java:20)
at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:201)
at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:125)
at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:81)
at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:353)
at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:120)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.jboss.weld.util.ServiceLoader.prepareInstance(ServiceLoader.java:240)
at org.jboss.weld.util.ServiceLoader.loadService(ServiceLoader.java:214)
at org.jboss.weld.util.ServiceLoader.loadServiceFile(ServiceLoader.java:182)
at org.jboss.weld.util.ServiceLoader.reload(ServiceLoader.java:162)
at org.jboss.weld.util.ServiceLoader.iterator(ServiceLoader.java:297)
at com.oracle.injection.provider.weld.BasicDeployment.getExtensions(BasicDeployment.java:106)
at com.oracle.injection.provider.weld.WeldInjectionContainer.initialize(WeldInjectionContainer.java:92)
at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:64)
at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:41)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:39)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:753)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:263)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:67)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:601)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:171)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:121)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:343)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:895)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1422)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:454)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:181)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
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)
The validation.xml file's content shows in the below:
<?xml version="1.0" encoding="UTF-8" ?>
<validation-config
xmlns="http://jboss.org/xml/ns/javax/validation/configuration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://jboss.org/xml/ns/javax/validation/configuration
validation-configuration-1.1.xsd"
version="1.1">
</validation-config>
How to deploy ear file with validation.xml on weblogic 12.2.1?
It drives me crazy too. I tried to downgrade bean validation to 1.0, but did not help.
Here they suggest to ignore it since it is warning only, set the logger to SEVERE level.
I had the same problem with web application.
In my case validation.xml was in one of my jars. I was able to fix the problem by moving the file directly to the war that was being deployed.
In case of ear file I believe the same solution should work.
I think this is a bug in EclipseLink/TopLink (which is used for JPA and JAXB binding in WLS 12.2.1 and upwards). I opened a FORUM entry in the EclipseLink forum: https://www.eclipse.org/forums/index.php/m/1759047/#msg_1759047
Summary: They try to read the validation.xml resource like this:
URL validationXml = Thread.currentThread().getContextClassLoader().getResource("META INF/validation.xml");
and then:
new File(validationXml.toURI())
but the toURI contains an URI that looks like this:
The URL.toString is: zip:/local/saladin/wls12/weblogic/12.2.1.0.0/domains/XXXX/servers/AdminServer/tmp/_WL_user/xxxx-application_1.5.5_dev-SNAPSHOT/s86txs/lib/xxx-xxxx-xxxxdatamodel-1.5.5_dev-SNAPSHOT.jar!/META-INF/validation.xml
So this is not a file, and therefore it cannot work.
The correct way would be to get the resource as Stream and not as File. But as to a solution, I don't know really how to fix it without modifying the EclipseLink source code. It is quite ugly to have those Warnings in the logfile and not being able to do anything about it.
As mentioned here, I am having a heck of a time getting my small Spring-Boot project to deploy "correctly" to Glassfish. It runs fine using the embedded Tomcat, but once I try and move it into my organization's environment (Glassfish 3.1.2) I get some strange behavior.
Thinking it was my code, I reverted to the time-tested "Hello World"-approach and built a super-basic app following this tutorial on Spring's blog.
I did make a few very minor deviations as I went along but nothing that should have affected the app like this at all.
The only major deviation I made was that I found I could not exclude "spring-boot-starter-tomcat" from "spring-boot-starter-web" -- when I tried to that, I got 2 errors in the STS "Markers"-tab:
The project was not built since its build path is incomplete. Cannot find the class file for javax.servlet.ServletContext. Fix the build path then try building this project
The type javax.servlet.ServletContext cannot be resolved. It is indirectly referenced from required .class files Application.java
If I cleaned the STS project, then ran Maven Clean, Update, Install the Install goal gave the following error:
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project test: Compilation failure [ERROR] /Users/brandon_utah/Utah Development/sts_workspaces/NidTools Rebooted/test/src/main/java/test/Application.java:[13,8] cannot access javax.servlet.ServletException [ERROR] class file for javax.servlet.ServletException not found
So what I did instead was include this dependency (which I found mentioned in several other SpringBoot resources):
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
In this deployed fine to the embedded Tomcat and it did deploy to my Glassfish (local install) -- but with a whole bunch (about a half-dozen) errors similar to this one:
2014-04-03T16:23:48.156-0600|SEVERE: Class [ Lorg/springframework/jdbc/datasource/embedded/EmbeddedDatabase; ] not found. Error while loading [ class org.springframework.boot.autoconfigure.jdbc.EmbeddedDataSourceConfiguration ]
Most of them are SEVERE, but I am also getting a few with a WARNING:
2014-04-04T06:57:35.921-0600|WARNING: Error in annotation processing: java.lang.NoClassDefFoundError: org/springframework/batch/core/configuration/annotation/BatchConfigurer
Except that I'm not referencing any of these missing classes anywhere in my project (other than what might be referenced by Spring Boot itself).
Also, the app doesn't quite work as expected. If I hit the RestController, I do get my page rendered as I expect -- but if I put any sort of System.out or Logger.log statement in the controller's method, that line of code seemingly never gets executed; by all appearances, it just gets skipped.
To demonstrate this problem, in my sample app's RestController I created a static counter. Then in the GET-/ method I increment that counter and System.out.println it's value. I also return the value as part of the Response.
And again, from a user's perspective, it seems to be working: the screen renders "Hello World" and in parentheses it shows the counter's value. I refresh the window, the counter increments. But nothing in the STS Console. And if I navigate to the Glassfish log for the app, nothing there either. Nothing. Nada. Zip. From what I can tell, something is mysteriously eating any attempt to log anything.
To add to the mystery, if I add a System.out to the SpringBootServletInitializer#configure(), that does make it to the Console. But if I declare a constructor in my RestController and include a System.out there, that one does not make it to the Console. For good measure, I even tried including a System.err in the constructor and a Logger.getAnonymousLogger.severe in the method; neither of those result in anything.
I should note that this also deploys and runs as expected using an external Tomcat.
I would very much appreciate any input, as it's not likely that I can convince my organization to deploy this to Tomcat nor use the embedded-Tomcat approach (due to politics and an overwhelming existing Glassfish environment).
My test project on Github is here.
This has been answered here: https://stackoverflow.com/a/29438821/508247
There is a bug in Glassfish 3.1.X. You need to include metadata-complete="true" in your web.xml root element.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1"
metadata-complete="true"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
</web-app>
I had this problem with Payara 5, I understand the problem became from Glassfish.
Versions:
Payara 5.192
Spring Boot 2.1.6
The solution worked for me:
I added this dependency in the pom.xml.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-batch</artifactId>
<version>2.1.4.RELEASE</version>
</dependency>
My glassfish-web configuration:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC ...>
<glassfish-web-app error-url="">
<class-loader delegate="true"/>
<jsp-config>
<property name="keepgenerated" value="true">
<description>Keep a copy of the generated servlet class' java code.</description>
</property>
</jsp-config>
<!-- set a friendly context root -->
<context-root>/micuenta-api</context-root>
<!-- Change the default character encoding from ISO-8859-1 to UTF-8 -->
<parameter-encoding default-charset="UTF-8"/>
</glassfish-web-app>
I don't understand why I get an error during deploying of my webapp. At first time the deploy works but from the second I get this error:
DEPLOYMENTS IN ERROR:
Deployment "vfszip:/C:/jboss/deploy/TestServlet.war/" is in error due to the following reason(s): org.
jboss.deployers.spi.DeploymentException: Web mapping already exists for deployment URL file:/C:/jboss/tmp/a6q5r3z-z5l3qt-hfcant4w-1-hfclha33-ta/TestServlet.war/
I read in several threads on the web that I have to add into WEB-INF folder the jboss-web.xml file. So i added with the following content, but I still get the same error:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-web PUBLIC
"-//JBoss//DTD Web Application 5.0//EN"
"http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd">
<jboss-web>
<context-root>/TestServlet</context-root>
</jboss-web>
The AS is JBOSS 5.1
Change <context-root>/TestServlet</context-root> to <context-root>TestServlet</context-root>. '/' is not required here. Please try that. And one more thing, do you have ROOT.war in Jboss
I have a problem in my application post moving to tomcat7. I am seeing the below issue when my app tries to connect to the "Oracle 11.2 DB".
org.springframework.jdbc.CannotGetJdbcConnectionException: Could not get JDBC Connection; nested exception is org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (ORA-12541: TNS:no listener
)
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:82)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:382)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:458)
at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:466)
The connection details in the server.xml and context.xml looks like below.
context.xml
ResourceLink global="jdbc/ctb" name="jdbc/ctb" type="oracle.jdbc.pool.OracleDataSource"/>
server.xml
<Resource name="jdbc/XXXX"
auth="Container"
scope="Shareable"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:oci8:#database"
username="username" password="pwd"
maxActive="30" maxIdle="3"
removeAbandoned="true" removeAbandonedTimeout="60"
testOnBorrow="true"
validationQuery="select 1 from dual"
logAbandoned="true" />
One observation i see is below:
The tomcat7 comes with a default jdbc driver in the "lib" folder called "tomcat-jdbc.jar". But in my app we are using spring-jdbc.jar from quite long.
Tried to remove each of them to make sure there wont be any conflict in the classes, but it never helped me.
tomcat6 workes fine with the same "context.xml" and "server.xml" and spring-jdbc.jar.
your help will be highly appreciated as this has become a blocker for our tomcat7 migration. Let me know if you need any further details.
==Benki
Oh Ghosh, pinned down the issue.
The setenv.sh script created never had the "ORACLE_HOME" path set for it which created in the above error. Also as i was using the init script was starting and stopping the tomcat, which loaded only the basic ENV variable required and set by setenv.sh script.
Everything is working fine now.