The following configuration is ok for WebLogic, but in OpenEJB it raises a error "javax.naming.NameNotFoundException: Name "AppDB" not found."
And if I removed the property javax.persistence.jtaDataSource, it works. And why set 2 duplicated datasource? Because it's a bug of Eclipselinks (see http://bugs.eclipse.org/246126)
<persistence-unit name="app1" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>AppDB</jta-data-source>
<properties>
<property name="javax.persistence.jtaDataSource" value="AppDB" />
</properties>
</persistence-unit>
The following is jndi.properties
java.naming.factory.initial=org.apache.openejb.client.LocalInitialContextFactory
openejb.validation.output.level=VERBOSE
openejb.nobanner=false
jdbc/AppDB = new://Resource?type=DataSource
jdbc/AppDB.provider = org.eclipse.persistence.jpa.PersistenceProvider
jdbc/AppDB.JdbcDriver = oracle.jdbc.OracleDriver
jdbc/AppDB.JdbcUrl = jdbc:oracle:thin:#xx.xx.xx.xx:xxxx:xxxx
jdbc/AppDB.JtaManaged = false
jdbc/AppDB.UserName = xxxx
jdbc/AppDB.Password = xxxx
Because this is a jar packaged by other team, I cannot change the content but I still want to use it in my OpenEJB, any suggestion? thanks.
Not at all sure how EclipseLink processes the javax.persistence.jtaDataSource property. I have to assume it's a JNDI lookup of some kind, but there's incredible significance in how they might do that. If they prepend java:comp/env/ for example, that significantly changes the semantics.
Maybe try overriding javax.persistence.jtaDataSource to use the OpenEJB global JNDI name for your datasource. So in your jndi.properties file, add
app1.javax.persistence.jtaDataSource = openejb:Resource/jdbc/AppDB
Definitely let me know if that works. Seems that might a good feature to add to OpenEJB even though the property is actually used by the JPA provider. Fixing invalid JNDI names could be more than convenient.
On a side note, there should be a logging statement saying 'jdbc/AppDB.provider' is not a property supported by the datasource. Probably best to delete that property.
Related
Believe me, I know this question has been asked many times and has gotten an answer many times, and these answers seemed to have worked for some users. I've spent many hours trying the various proposed solutions and, while they work on Linux (Ubuntu) they seem to have no effect on Windows (Windows 10 Home with jdk1.8.0_161). The web application is using EclipseLink 2.5.0 for persistence.
I've tried including the mysql-connector-java-5.1.46-bin.jar file in the WAR archive (WEB-INF/lib; using the Deployment Assembly screen in Eclipse), copying it to the payara5/glassfish/lib folder, as well as the payara5/glassfish/domains/domain1/lib/ and payara5/glassfish/domains/domain1/lib/applibs folders. I also tried specifying the library when deploying the web application, i.e., putting mysql-connector-java-5.1.46-bin.jar as the value in the library field. I updated the CLASSPATH environment variable with the path to the JAR file. Every time, the server was restarted. None of these actions have any effect. Note that they did work on Linux Ubuntu.
See below for the well-known exception trace:
Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.7.0.v20170811-d680af5): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: No suitable driver found for jdbc:mysql://localhost:3306/rom
Error Code: 0
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:331)
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:326)
at org.eclipse.persistence.sessions.DefaultConnector.connect(DefaultConnector.java:138)
at org.eclipse.persistence.sessions.DatasourceLogin.connectToDatasource(DatasourceLogin.java:170)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.setOrDetectDatasource(DatabaseSessionImpl.java:228)
at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:804)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:254)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:757)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:216)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:324)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:348)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:311)
...
Any thoughts would be greatly appreciated.
UPDATE: as a sanity check (got the idea thanks to #Abhi) I added the line
try {
System.out.println("JDBC driver: " +
Class.forName("com.mysql.jdbc.Driver"));
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
Which correctly prints the following line (without throwing an exception):
JDBC driver: class com.mysql.jdbc.Driver
But does nothing to solve the problem. In other words, the driver seems to be loadable but somehow EclipseLink is not able to find it (?)
Looks like I'm able to answer my own question. I asked the exact same question on the Payara Forum and was recommended to define a data source instead of using the driver directly (#Chris pointed in this direction as well). A data source is likely the best way to go anyway but I wanted to avoid the complexity and use the simplest setup .. which clearly didn't work.
For reference, you can find the working setup below:
In Payara 5, goto JDBC > JDBC Connection Pools > New: enter a pool name, select javax.sql.DataSource as resource type, and MySql as vendor. On step 2, com.mysql.jdbc.jdbc2.optional.MysqlDataSource should be preselected for Datasource Classname. Fill out the Username and Password (e.g., root, changeit) properties under the Additional Properties header. Select finish. On the page for the newly created connection pool, select PING to make sure it was setup correctly.
In your persistence.xml file, make sure the persistence-unit element starts as follows:
<persistence-unit name="ROM" transaction-type="JTA">
<jta-data-source>java:global/<connection pool name></jta-data-source>
Create a web.xml file (this may also be done using Java Annotations):
<?xml version="1.0" encoding="UTF-8"?>
<web-app 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"
version="3.1">
<data-source>
<name>java:global/<connection pool name></name>
<class-name>com.mysql.jdbc.jdbc2.optional.MysqlDataSource</class-name>
<server-name>[host name, e.g., localhost]</server-name>
<port-number>3306</port-number>
<database-name>[db name]</database-name>
<user>[username, e.g., root]</user>
<password>[password]</password>
</data-source>
</web-app>
This configuration worked for me at least. Hoping this will help someone else down the road. Note that there are various useful settings for a connection pool - see e.g., here for more options.
to the line of code to connect:
con = DriverManager.getConnection(urlBaseDatos, usuario, clave);
Add the following:
DriverManager.registerDriver(new com.mysql.jdbc.Driver());
con = DriverManager.getConnection(urlBaseDatos, usuario, clave);
Naturally I concur with the answer here, which is "in an Application server you should use a DataSource".
Now just my two cents and to answer the original question:
From JDBC 4, you aren't required to register the driver anymore, and this line shouldn't be necessary:
DriverManager.registerDriver(new com.mysql.cj.jdbc.Driver());
See: https://docs.oracle.com/javase/8/docs/api/java/sql/DriverManager.html
So when using a JDK8+/EE8/JDBC4.2 compliant application server, you shouldn't be mandated to register the driver. Or so I thought...
Though, like you #William, I noticed Glassfish/Payara requires it. It's very strange. Maybe it has to do with the way it handles classloading?
Wildfly, in turn, does the right thing and automatically loads the driver without actually having to manually register it.
My Java EE application cannot find tables. I am using WildFly (as the application server) and H2 (as the DB, in the embedded mode).
The error is:
org.h2.jdbc.JdbcSQLException: Table "MY_TABLE" not found
Look at my table creation:
create table "MY_TABLE" (
-- ...
);
See how my entity is defined:
#Entity
#Table(name = "MY_TABLE")
public class MyTable {
// ...
}
This is how I call JPA (this causes the exception):
#PersistenceContext
private EntityManager entityManager;
// ...
entityManager.find(MyTable.class, 1);
My persistence.xml is:
<persistence-unit name="myapp" transaction-type="JTA">
<jta-data-source>java:jboss/datasources/myappDS</jta-data-source>
</persistence-unit>
And the standalone.xml in my WildFly:
<datasource jndi-name="java:jboss/datasources/myappDS" pool-name="myappDS" enabled="true" use-java-context="true">
<connection-url>jdbc:h2:~/myapp;SCHEMA=PUBLIC</connection-url>
<driver>h2</driver>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
Everything looks good so why the exception? Do I need to flush something? Or set schema somewhere?
If I configure another datasource (having the same DB structure) in WildFly (for example Postgres), everything works fine. That would mean that the datasource configuration is the place causing the error.
(Yes, I am totally sure the DB is not empty and the connection URL is correct as I have tried it from an SQL client.)
Are you running the application as a different user than you are testing to connect with? In that case the the ~ in the connection path will resolve to different home folders, and thus different databases.
Otherwise I would suggest connecting with the Shell in the h2 jar file and run show tables to verify that the table exists and with the correct casing. Start the shell by running:
java -cp h2*.jar org.h2.tools.Shell
Where do you store your script for the table creation? Is it in classpath of the application?
In my test setup I let hibernate generate the tables on startup (and dropping it on shutdown) and using an import.sql script for the test-data generation, which is in the folder src/main/resources.
<persistence-unit name="myapp" transaction-type="JTA">
<jta-data-source>java:jboss/datasources/myappDS</jta-data-source>
<properties>
<property name="hibernate.hbm2ddl.auto" value="create-drop" />
</properties>
</persistence-unit>
I am supposed to check for existence of tables on server startup. If they did not exist I have to create them using entity classes. Is this even possible?
I am using Eclipse and my server is wildfly10. I am connecting to Oracle 11g xe but I don't think it is database that is causing issues
Anyway, this is what I have done so far
My persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
<persistence-unit name="Lab5">
<properties>
<property name="javax.persistence.schema-generation.database.action" value="create"/>
</properties>
</persistence-unit>
</persistence>
Without above property my database query throws Exception. But what is really strange, is that with this property query returns empty list, but table does not exist in database.
Also, I noticed warning showing on server startup
HHH000431: Unable to determine H2 database version, certain features may not work
I tried various fixes for this warning found on stackoverflow and other sites but they did not help. I don't even know if this is related to my problem
JPA 2.1 made DDL generation a part of the specification. You can use the "javax.persistence.schema-generation.database.action" persistence property with a "create" value to have 2.1 providers create the database schema for you during deployment. JPA can be used to generate or even run custom scripts should you need to modify the table creation/tear down and population process.
The problem you are likely encountering is your persistence unit does not specify a datasource, leaving it up to the container to figure out which you want to connect to, and Wildfly must be defaulting to an H2 database. The tables will be setup in this database, but not the Oracle XE database you are expecting - which is why queries return no values and yet in your console, the tables don't even exist.
You need to setup a datasource to your database in the server, and then point your persistence unit to it using the <non-jta-data-source> or <jta-data-source>. Your persistence.xml is incomplete, so I would urge you to look at a demo persistence unit first.
This will likely depend on the implementation you're including with your project. Assuming you're using hibernate for persistence, you'll need to add the following:
...
<persistence-unit ...>
<provider>org.hibernate.ejb.HibernatePersistence</provider>
...
<properties>
<property name = "hibernate.hbm2ddl.auto" value="create" />
...
</properties>
</persistence-unit>
Note that this will assume that your connection is formed with a user having the required privileges in the db for table creation. Take a look at the hibernate docs here.
i'm having a problem with hibernate and don't know exactly what's going on, i have this project at work where i connect to an Oracle 10g Database using the following settings:
Host Name: localhost
port:1521
SID:orcl
user:anfxi
password:password
Now i'm at home trying to work with the same database remotely, im connected via VPN and the database ip is now 10.73.98.230 , i imported my WAR and changed the settings in my
hibernate.cfg.xml from:
<property name="hibernate.connection.driver_class">oracle.jdbc.OracleDriver</property>
<property name="hibernate.connection.url">jdbc:oracle:thin://localhost:1521:orcl</property>
<property name="hibernate.connection.username">anfexi</property>
<property name="connection.password">password</property>
<property name="connection.pool_size">1</property>
<property name="hibernate.dialect">org.hibernate.dialect.OracleDialect</property>
<property name="show_sql">true</property>
<property name="hbm2ddl.auto">validate</property>
<property name="current_session_context_class">thread</property>
to:
<property name="hibernate.connection.driver_class">oracle.jdbc.OracleDriver</property>
<property name="hibernate.connection.url">jdbc:oracle:thin://10.73.98.230:1521:orcl</property>
<property name="hibernate.connection.username">anfexi</property>
<property name="connection.password">password</property>
<property name="connection.pool_size">1</property>
<property name="hibernate.dialect">org.hibernate.dialect.OracleDialect</property>
<property name="show_sql">true</property>
<property name="hbm2ddl.auto">validate</property>
<property name="current_session_context_class">thread</property>
but i keep getting this error:
ERROR [main] (SchemaValidator.java:135) - could not get database metadata
java.sql.SQLException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
The Connection descriptor used by the client was:
localhost:1521:orcl
so it seems to be still using localhost as the DB address, i cleaned my project and rebuilt, still with no luck, is there something else that i could be missing? does the hibernate configuration gets cached in some file i have to erase or something?
EDIT
For what it may serve, i can connect using SQL developer,the problem is just hibernate still using the old localhost:1521:orcl Connection descriptor.
Thanks for your help!
Verify that the xml file you are changing in Eclipse is actually being deployed to the server. I run into problems every once in awhile where Eclipse doesn't know it needs to redeploy certain files for my webapp.
If you are using Tomcat and deploying using the workspace metadata (the default), you can check what the actual deployed WAR files look like by looking at your filesystem under:
WORKSPACE/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/APPNAME/.../path/to/hibernate.cfg.xml
If you find the config file is NOT being updated, I would recommend undeploying you app in Eclipse, deleting the entire APPNAME directory in the above path, and redeploying clean.
If none of that works, do a project-wide search for "localhost" and see if there could possible be any hardcoded connections strings anywhere.
This kind of problem is usually due to the wrong configuration file being present. Maybe you have two copies of the file and you changed one but the system is using the other
Typically when building/compiling, resources get copied to a target/build folder. Check source folders and build target folders etc.
Search the file system for all files with the name hibernate.cfg.xml or with the contents localhost:1521:orcl
Check the classpath, or try explicitly putting the folder with the configuration file you want first in the classpath.
It can also be a case of some other configuration overriding your configuration, for instance a datasource filer or a persistence.xml-file. Check those if you have them as well.
How are you running your application? Through a test case, standalone console application, servlet/j2ee container?
It is unable to understand the "orcl" SID. May be the SID is present on your "localhost" but not on the server "10.73.98.230". verify you are using the correct SID available on "10.73.98.230".
Try changing this line in your config file.
<property name="hibernate.connection.url">jdbc:oracle:thin:#10.73.98.230:1521:orcl</property>
replace // with #
you can follow the link the have infomation http://www.cryer.co.uk/brian/oracle/ORA12505.htm
Hope this will help
I have a web-app that requires two settings:
A JDBC datasource
A string token
I desperately want to be able to deploy one .war to various different containers (jetty,tomcat,gf3 minimum) and configure these settings at application level within the container.
My code does this:
InitialContext ctx = new InitialContext();
Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
token = (String)envCtx.lookup("token");
ds = (DataSource)envCtx.lookup("jdbc/datasource")
Let's assume I've used the glassfish management interface to create two jdbc resources: jdbc/test-datasource and jdbc/live-datasource which connect to different copies of the same schema, on different servers, different credentials etc. Say I want to deploy this to glassfish with and point it at the test datasource, I might have this in my sun-web.xml:
...
<resource-ref>
<res-ref-name>jdbc/datasource</res-ref-name>
<jndi-name>jdbc/test-datasource</jndi-name>
</resource-ref>
...
but
sun-web.xml goes inside my war, right?
surely there must be a way to do this through the management interface
Am I even trying to do the right thing? Do other containers make this any easier? I'd be particularly interested in how jetty 7 handles this since I use it for development.
EDIT Tomcat has a reasonable way to do this:
Create $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml with:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true">
<!-- String resource -->
<Environment name="token" value="value of token" type="java.lang.String" override="false" />
<!-- Linking to a global resource -->
<ResourceLink name="jdbc/datasource1" global="jdbc/test" type="javax.sql.DataSource" />
<!-- Derby -->
<Resource name="jdbc/datasource2"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.apache.derby.jdbc.EmbeddedDataSource"
url="jdbc:derby:test;create=true"
/>
<!-- H2 -->
<Resource name="jdbc/datasource3"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.h2.jdbcx.JdbcDataSource"
url="jdbc:h2:~/test"
username="sa"
password=""
/>
</Context>
Note that override="false" means the opposite. It means that this setting can't be overriden by web.xml.
I like this approach because the file is part of the container configuration not the war, but it's not part of the global configuration; it's webapp specific.
I guess I expect a bit more from glassfish since it is supposed to have a full web admin interface, but I would be happy enough with something equivalent to the above.
For GF v3, you may want to try leveraging the --deploymentplan option of the deploy subcommand of asadmin. It is discussed on the man page for the deploy subcommand.
We had just this issue when migrating from Tomcat to Glassfish 3. Here is what works for us.
In the Glassfish admin console, configure datasources (JDBC connection pools and resources) for DEV/TEST/PROD/etc.
Record your deployment time parameters (in our case database connect info) in properties file. For example:
# Database connection properties
dev=jdbc/dbdev
test=jdbc/dbtest
prod=jdbc/dbprod
Each web app can load the same database properties file.
Lookup the JDBC resource as follows.
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* #param resourceName the resource name of the connection pool (eg jdbc/dbdev)
* #return Connection a pooled connection from the data source
* associated with resourceName
* #throws NamingException will be thrown if resource name is not found
*/
public Connection getDatabaseConnection(String resourceName)
throws NamingException, SQLException {
Context initContext = new InitialContext();
DataSource pooledDataSource = (DataSource) initContext.lookup(resourceName);
return pooledDataSource.getConnection();
}
Note that this is not the usual two step process involving a look up using the naming context "java:comp/env." I have no idea if this works in application containers other than GF3, but in GF3 there is no need to add resource descriptors to web.xml when using the above approach.
I'm not sure to really understand the question/problem.
As an Application Component Provider, you declare the resource(s) required by your application in a standard way (container agnostic) in the web.xml.
At deployment time, the Application Deployer and Administrator is supposed to follow the instructions provided by the Application Component Provider to resolve external dependencies (amongst other things) for example by creating a datasource at the application server level and mapping its real JNDI name to the resource name used by the application through the use of an application server specific deployment descriptor (e.g. the sun-web.xml for GlassFish). Obviously, this is a container specific step and thus not covered by the Java EE specification.
Now, if you want to change the database an application is using, you'll have to either:
change the mapping in the application server deployment descriptor - or -
modify the configuration of the existing datasource to make it points on another database.
Having an admin interface doesn't really change anything. If I missed something, don't hesitate to let me know. And just in case, maybe have a look at this previous answer.