I am try to convert a WAS traditional 8.5 websphere configuration to a websphere liberty 20.x configuration and getting an error. I believe the connection settings are right, the names are correct, the jar file for the driver exists but getting the error below.
Here is essentially the configuration.
<dataSource jndiName="jdbc/db2a" type="javax.sql.DataSource">
<jdbcDriver javax.sql.DataSource="com.ibm.db2.jcc.DB2Driver" libraryRef="DB2JCCLib"/>
<properties.db2.jcc driverType="4" databaseName="DB1" serverName="host.name" portNumber="446"/>
</dataSource>
<web-bnd
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://websphere.ibm.com/xml/ns/javaee"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-bnd_1_0.xsd" version="1.0">
<virtual-host name="default_host"/>
<resource-ref name="jdbc/db2a" binding-name="jdbc/db2a"/>
</web-bnd>
...
Configuration at top of server.xml
<!-- Enable features -->
<featureManager>
<feature>appSecurity-2.0</feature>
<feature>jaxrs-2.0</feature>
<feature>jsp-2.3</feature>
<feature>localConnector-1.0</feature>
<feature>jaxws-2.2</feature>
<feature>ldapRegistry-3.0</feature>
</featureManager>
The jar file is : db2jcc4-4.22.29.jar
And has as reference to that jar / class file.
The java code for the connection is standard jdbc connection:
DriverManager.getConnection (connStr);
And this:
InitialContext initialContext = new InitialContext();
Context context = (Context)initialContext.lookup("java:comp/env");
DataSource dataSource = (DataSource)context.lookup(string5);
logger.info((Object)"CVDBBackendHandler.getConnection() out");
return dataSource.getConnection();
The error is below.
Root exception is com.ibm.wsspi.injectionengine.InjectionException: CWNEN0030E: The server was unable to obtain an object instance for the java:comp/env/jdbc/db2a reference. The exception message was: CWNEN1003E: The server was unable to find the jdbc/db2a binding with the java.lang.Object type for the java:comp/env/jdbc/db2a reference.
You need to add one of the JDBC features to your feature list, e.g.
<featureManager>
<feature>jdbc-4.3</feature>
</featureManager>
(or one of the earlier JDBC features, e.g.jdbc-4.2, etc.).
Though your messages.log should show a feature set like this (including features pulled in from the features you explicitly enabled):
CWWKF0012I: The server installed the following features: [appSecurity-2.0, distributedMap-1.0, el-3.0, federatedRegistry-1.0, jaxb-2.2, jaxrs-2.0, jaxrsClient-2.0, jaxws-2.2, jndi-1.0, json-1.0, jsp-2.3, ldapRegistry-3.0, localConnector-1.0, servlet-3.1, ssl-1.0].
this list doesn't include any activating the JDBC feature, so you must explicitly enable it. (On the other hand, note the jndi-1.0 feature required to do JNDI lookups is included even though it wasn't one you added directly to server.xml, since one of the other features included it).
Some helpful links for reference:
https://openliberty.io/docs/latest/reference/feature/jdbc-4.3.html
https://openliberty.io/docs/latest/relational-database-connections-JDBC.html
There is an error in the configuration. com.ibm.db2.jcc.DB2Driver is not an implementation of javax.sql.DataSource.
You can remove the configuration attribute javax.sql.DataSource="com.ibm.db2.jcc.DB2Driver" and let the built-in knowledge in Liberty infer it from the JDBC driver jar, or you can specify it as,
javax.sql.DataSource="com.ibm.db2.jcc.DB2DataSource"
The above data source class name can be found in DB2 documentation here
Related
I have downloaded the latest stable WLP runtime with JAVA EE7 for solaris environment.
Version : 16.0.0.3
The zip file is extracted and profile is created. AdminCenter installed by using below command:
.\installUtility install adminCenter-1.0
Server.xml file :
<?xml version="1.0" encoding="UTF-8"?>
<server description="new server">
<!-- Enable features -->
<featureManager>
<feature>jsp-2.2</feature>
<feature>adminCenter-1.0</feature>
</featureManager>
<quickStartSecurity userName="admin" userPassword="adminpwd" />
<keyStore id="defaultKeyStore" password="Liberty" />
<featureManager>
<feature>ssl-1.0</feature>
</featureManager>
<keyStore id="defaultKeyStore" password="{xor}PjsyNjEfbm1s" />
<httpEndpoint id="defaultHttpEndpoint"
host="*"
httpPort="9060"
httpsPort="9443" />
<!-- Automatically expand WAR files and EAR files -->
<applicationManager autoExpand="true"/>
</server>
The WAS service also started. In Browser, after providing the credentials, it shows blank page. The log message is given below:
[ERROR ] CWWKF0033E: The singleton features servlet-3.0 and
servlet-3.1 cannot be loaded at the same time. The configured
features adminCenter-1.0 and
com.ibm.websphere.appserver.restConnectorjaxrs-1.0 include one or more
features that cause the conflict. Your configuration is not supported;
update server.xml to remove incompatible features.
[ERROR ] CWWKF0033E: The singleton features
com.ibm.websphere.appserver.internal.jaxrs-1.1 and
com.ibm.websphere.appserver.internal.jaxrs-2.0 cannot be loaded at the
same time. The configured features adminCenter-1.0 and
com.ibm.websphere.appserver.restConnectorjaxrs-1.0 include one or more
features that cause the conflict. Your configuration is not supported;
update server.xml to remove incompatible features.
[ERROR ] CWWKF0033E: The singleton features
com.ibm.websphere.appserver.javax.annotation-1.1 and
com.ibm.websphere.appserver.javax.annotation-1.2 cannot be loaded at
the same time. The configured features jsp-2.2 and
com.ibm.websphere.appserver.restConnectorjaxrs-1.0 include one or more
features that cause the conflict. Your configuration is not supported;
update server.xml to remove incompatible features.
[ERROR ] CWWKF0033E: The singleton features
com.ibm.websphere.appserver.javaeeCompatible-6.0 and
com.ibm.websphere.appserver.javaeeCompatible-7.0 cannot be loaded at
the same time. The configured features jsp-2.2 and
com.ibm.websphere.appserver.restConnectorjaxrs-1.0 include one or more
features that cause the conflict. Your configuration is not supported;
update server.xml to remove incompatible features.
[AUDIT ] CWWKZ0058I: Monitoring dropins for applications. [ERROR ]
CWWKE0702E: Could not resolve module: com.ibm.ws.jaxrs-2.0.common
[502]
But the service is up and running. Kindly help to fix this issue.
This error is caused by a rare scenario where the feature resolution of installUtility leaves the Liberty runtime feature resolution with an incompatible set of features.
To resolve the issue:
Remove the jsp-2.2 feature from your server.xml. The correct JSP feature will be pulled in automatically by adminCenter-1.0
This error happened because...
You have the following features configured in your server.xml:
jsp-2.2
adminCenter-1.0
ssl-1.0
If you had every feature in Liberty installed, the runtime would be able to figure out the correct set of features. However, the installUtility is not quite as smart as the Liberty runtime when it comes to feature resolution, which is why you've been stuck with this incompatible set of features in your install image, which has resulted in a feature conflict.
Side note:
It is best practice to only use a single <featureManager> element (per xml file).
Additionally, you have <keyStore id="defaultKeyStore"> defined twice in your server.xml (the second one will be used). This is likely a typo, but in any case the behavior is defined by Liberty:Configuration element merging rules
I am deploying a WAR to JBoss EAP 7. In my WAR's META-INF/context.xml file I have the following:
<Context unloadDelay="500000">
<Resource name="jdbc/sybase/somedb"
auth="Container"
type="javax.sql.DataSource"
driverClassName="net.sourceforge.jtds.jdbc.Driver"
url="jdbc:jtds:sybase://localhost:12501/somedb"
username="username" password="secret"
validationQuery="select 1"
maxActive="2" maxIdle="0" maxWait="-1"/>
...
From my Java code I try to obtain the DataSource doing a:
InitialContext cxt = new InitialContext();
DataSource ds = (DataSource) cxt.lookup( "java:/comp/env/jdbc/sybase/somedb" );
The exact above code works and the name is found in the context when I deploy to Tomcat 8 but not when I deploy to JBoss EAP 7. In the latter case I get:
Caused by: javax.naming.NameNotFoundException: comp/env/jdbc/sybase/somedb -- service jboss.naming.context.java.comp.env.jdbc.sybase.somedb
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
What am I doing wrong and how can I fix the above problem?
Your META-INF/context.xml file is a Tomcat deployment descriptor (not defined by the Java EE specification) so it is not seen or parsed by JBoss EAP 7.
There are many alternatives to this including the solution to is there a standard way to define a JDBC Datasource for Java EE containers.
If you were to ask RedHat support they would likely recommend that you create the datasource using server administration tools such as the admin console or jboss-cli.sh. This decouples your application from the datasource definition so that you can specify environment specific settings (such as pool sizes and hostnames) without repackaging your WAR.file. This method also requires you to deploy the JDBC driver jar separately from your application.
I am starting introduction with wildfly learning.
I have downloaded distribution of server.
Now I am trying to configure datasource but I see following error:
Unexpected HTTP response: 500
Request
{
"address" => [
("subsystem" => "datasources"),
("data-source" => "PostgreDataSource")
],
"operation" => "test-connection-in-pool"
}
Response
Internal Server Error
{
"outcome" => "failed",
"failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0042: failed to match pool. Check JndiName: java:jboss/datasources/PostgreDataSource",
"rolled-back" => true
}
My steps:
1. Created folder wildfly-10.0.0.CR2\wildfly-10.0.0.CR2\modules\org\postgres\main and copy postgresql-9.0-801.jdbc4.jar from \.m2\repository\postgresql\postgresql\9.0-801.jdbc4 there.
2.Created module.xml(inside wildfly-10.0.0.CR2\wildfly-10.0.0.CR2\modules):
with following content:
<module xmlns="urn:jboss:module:1.0" name="org.postgres">
<resources>
<resource-root path="postgresql-9.0-801.jdbc4.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
Modified standalone.xml(wildfly-10.0.0.CR2\wildfly-10.0.0.CR2\standalone\configuration) like this(sorry - I don't know how to copy xml that it can be visible for another users(full content visible here: http://collabedit.com/psk4a)):
Please help to understand what do I wrong?
Below given is driver configuration and data source creation and how to make it globally visible so that all J2EE deployments can access the particular module if needed.
1. PostGreSQL Driver Configuration
Create directory structure as below inside the modules in wildfly-8.2.0.Final\modules directory and place the mentioned files and driver jar.
Directory: wildfly-8.2.0.Final\modules\org\postgresql\main
File: module.xml
<!--<?xml version="1.0" encoding="UTF-8"?>-->
<module xmlns="urn:jboss:module:1.0" name="org.postgresql">
<resources>
<resource-root path="postgresql-9.4-1204.jdbc41.jar"/>
</resources>
<dependencies><module name="javax.api"/></dependencies>
</module>
JAR : PostGreSQL Driver: postgresql-9.4-1204.jdbc41.jar
Note : Driver version can be your choice and please ensure to reflect that version name in module.xml file.
Please note that the driver name="org.postgresql” mentioned in the module.xml file should be matching with the data source(s) configuration in the standalone.xml file.
Note: The PostGreSQL driver version should be compatible to the java version in the system.
In this example, java is 1.7 & PostGreSQL driver used is postgresql-9.4-1204.jdbc41.jar.
2. Configuring the DataSources
Datasources are configured in the standalone.xml file in the WildFly 8.2.0.Final\standalone\configuration.
As the first step configure the PostGreSQL driver reference in the standalone.xml file as below inside the tag
<driver name="postgresql" module="org.postgresql">
<datasource-class>org.postgresql.Driver</datasource-class>
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
</driver>
1. Add the datasource details:
Please add this inside tag
<datasource jndi-name="java:/db1" pool-name="db1" enabled="true" use-java-context="true">
<connection-url>jdbc:postgresql://localhost:5432/dbname</connection-url>
<driver>postgresql</driver>
<security>
<user-name>user_name</user-name>
<password>password</password>
</security>
</datasource>
2.make the published drivers globally visible by adding
to the section
Here it is:
<global-modules>
<module name="org.postgresql" slot="main"/>
</global-modules>
Note : Global modules is a set of JBoss Modules that will be added as dependencies to the JBoss Module of every Java EE deployment. Such dependencies allows Java EE deployments to see the classes exported by the global modules. Refer : https://docs.jboss.org/author/display/WFLY8/Subsystem+configuration
Once configured the above, please start your WildFly instance.
Problem resolved after move module.xml to wildfly-10.0.0.CR2\wildfly-10.0.0.CR2\modules\org\postgres\main
I am not 100% positive, but if I see some links around the net it may be caused by default pool settings. You might try by adding specific pool configuration settings to your datasource:
<datasource jndi-name="blabla"... >
<pool>
<min-pool-size>1</min-pool-size>
<max-pool-size>20</max-pool-size>
<prefill>true</prefill>
</pool>
</datasource>
I base that on this stackoverflow thread: WildFly jdbc connection with Oracle
where an answer links to this related JBoss forum thread: https://developer.jboss.org/thread/257721
The pool settings are mentioned in the Wildfly configuration documentation by the way. This is Wildfly 9, but I can't imagine things changed much in Wildfly 10: https://docs.jboss.org/author/display/WFLY9/DataSource+configuration
I'd like to say that I solved the problem only by using wildfly admin console (http://localhost:9990/console/). Not so spartan solution, but it works. I only pointed the JDBC driver jar from external directory and after I created a datasource. No xml by hand and no modifying wildfly's directory structure.
For java 8 + postgresql 9.5 I used postgresql-42.1.1.jar. I had problems befor only because I chose the wrong driver and database's name was wrong.
Although this topic is a bit old, I'd like to stress that the recommended way to install a datasource as a module is using the CLI 'module add' command which creates the full path for the module and the module.xml configuration file. This makes the whole process less error-prone.
module add --name=org.postgres --resources=[JDBC JAR FILE] --dependencies=javax.api,javax.transaction.api
Also, I see mentioned here the usage of global modules for datasource. This is not a common practice for JDBC drivers as global modules are meant to be used for shared libraries which are common to all applications and don't require maintenance. You might end up with an unconsistent datasource configuration if the Database is upgraded and you forget to update the JDBC Driver in your modules configuration.
Ref: How to configure a Datasource in WildFly
I'd like to use a ServletFilter that reads it configuration from the java:comp/env/ JNDI namespace. As the value will be different on devel and production servers, it should not be hardcoded via in web.xml but instead be configured in the application server.
I already tried the following places but none seemed to be right:
System Properties
Web Container / General Properties
JVM Settings / Additional Properties (suggested in How to set an env variable in Glassfish 2.1)
Resource Connectors (didn't work)
asenv.conf (only in Glassfish 2?)
How can I set a custom JNDI variable in Glassfish 4.1?
I installed only the Glassfish 4.1 Web Edition. While it has JNDI support, the web GUI comlpetely lacked the Resources -> JNDI menu to configure own variables!
In the Web Profile Glassfish, custom JNDI variables can be written in the domain.xml, they seem to survive other changes via the Admin GUI:
<resources>
...
<custom-resource res-type="java.lang.String" jndi-name="cas/serverName" factory-class="org.glassfish.resources.custom.factory.PrimitivesAndStringFactory">
<property name="value" value="https://sso.example.com/"></property>
</custom-resource>
</resources>
...
<servers>
<server name="server" config-ref="server-config">
...
<resource-ref ref="cas/serverName"></resource-ref>
</server>
</servers>
After adding a JNDI variable to Glassfish, it's only availble with InitialContext.doLookup("cas/serverName") though, not within the java:comp/env namespace. To get that, I had to add the following to my web.xml (it did not work in glassfish-web.xml!):
<resource-ref>
<res-ref-name>cas/serverName</res-ref-name>
<res-type>java.lang.String</res-type>
<lookup-name>cas/serverName</lookup-name>
</resource-ref>
I am developing a Java EE 7 application and have a requirement for the application to be deployed onto application servers running either GlassFish 4.0 or WildFly 8.1.0. The issue I've got is GlassFish and WildFly use slightly different formats for JNDI names but I can't see how to make my application compatible with both.
In GlassFish my persistence.xml file references the data source jdbc/myDataSouce, but in WildFly the data source needs to be java:/jdbc/myDataSource.
The same is also true for classes that are annotated with #Resource. In GlassFish the annotation for a class using JavaMail would be #Resource(name = "mail/myMailSession"), but to deploy onto WildFly this would need to be #Resource(name = "java:mail/myMailSession").
I know that I could unpack the EAR and JAR files to manually edit files such as persistence.xml but I can't do that for classes that have been annotated with #Resource.
Is there a way I can allow my complied application to be deployed onto GlassFish and WildFly without maintaining two different versions of the code? I'm assuming the answer probably lies with application specific deployment descriptors but I can't find any examples that cover these two scenarios.
Can anyone point me in the right direction please?
You can modify the Wildfly JNDi names and strip the undesired prefixes from the respective JNDI names to find the least common denominator in both app servers. The following works for me with Glassfish and JBoss AS 7.1. Since I expect Wildfly to be backwards-compatible to JBoss in this regard, I guess it'll work for Wildfly as well.
Persistence
Inject as:
#PersistenceContext(unitName="TestPU")
private EntityManager entityManager;
or via ejb-jar.xml:
<persistence-context-ref>
<persistence-context-ref-name>entityManager</persistence-context-ref-name>
<persistence-unit-name>TestPU</persistence-unit-name>
<injection-target> ... </injection-target>
</persistence-context-ref>
The corresponding persistence.xml:
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="TestPU" transaction-type="JTA">
<jta-data-source>datasources/TestDS</jta-data-source>
<class>org.jeeventstore.persistence.jpa.EventStoreEntry</class>
<properties>
<property name="hibernate.show_sql" value="false"/>
<property name="hibernate.format_sql" value="true"/>
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
<property name="hibernate.connection.charSet" value="UTF-8"/>
<property name="eclipselink.logging.level" value="FINE"/>
<property name="eclipselink.logging.level.sql" value="FINE"/>
<property name="eclipselink.logging.parameters" value="true"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
</properties>
</persistence-unit>
</persistence>
(note the simple jta-data-source JNDI name)
Here's a glassfish-resources.xml file used to specify a Derby database on deployment, a similar setup can be used for MySQL or Postgres.
<resources>
<jdbc-resource pool-name="ArquillianEmbeddedDerbyPool"
jndi-name="datasources/TestDS"/>
<jdbc-connection-pool name="ArquillianEmbeddedDerbyPool"
res-type="javax.sql.DataSource"
datasource-classname="org.apache.derby.jdbc.EmbeddedDataSource"
is-isolation-level-guaranteed="false">
<property name="databaseName" value="target/databases/derby"/>
<property name="createDatabase" value="create"/>
</jdbc-connection-pool>
</resources>
And the settings from the JBoss standalone.xml:
<datasource jta="true" jndi-name="java:/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="false">
<connection-url>jdbc:postgresql://localhost/test_db</connection-url>
...
</datasource>
Resources
I have not injected a JavaMail component on Glassfish, but similar to the datasoruce settings, it might be worth a try to strip the "java:" part from the #Resource annotation as well.
#Resource(name = "mail/myMailSession")
and then configure Wildfly such that that the mail resource is available at the "java:mail/myMailSession" JNDI location.
Injection via ejb-jar.xml
Another option is to manually inject the fields via a ejb-jar.xml file, and then use a build tool such as maven to copy either of ejb-jar-glassfish.xml or ejb-jar-wildfly.xml to the desired ejb-jar.xml at assembly time.
In one of our projects we use a mixed approach to avoid the burden with the xml configuration: We configure a small number of "provider" beans via ejb-jar.xml to inject, e.g., the persistence context into a PersistenceContextProvider, and then use CDI to inject the PersistenceContextProvider into the EJBs via #EJB, which are found without further configuration since they reside in the same EAR.
I haven't hit the mail-dilemma just yet. But I've ran into the same problem your having when it comes to data source definition and my solution has been to not setup the data sources using the server's console, but make them deployable together with your archive using the #DataSourceDefinition annotation. Turns out WildFly won't complain about java:app/blabla.. if the data source is setup during deployment!
Here is a real world example for you that works on both GlassFish and WildFly:
https://github.com/martinanderssondotcom/java-ee-concepts/../ArquillianDS.java
Note that the data source JNDI name declared is:
java:app/env/ArquillianDS
And here is the related persistence.xml file (don't mind the name of the file in this repository, the repository represents a test project that build archives during runtime and the app will change the name of the file in the archive to persistence.xml):
https://github.com/MartinanderssonDotcom/java-ee-concepts/../persistence-update.xml
Also note that the persistence unit need a data source located using this JNDI name:
java:app/env/ArquillianDS
This deployment works perfectly fine with both GlassFish and WildFly. I've noted that if we declare the data source during deployment, then we pay the price of not seeing the data source listed anywhere in the admin gui/console. For me, that is a small price to pay in order to have a truly portable application. As an added bonus, I don't have to write lengthy installation/setup instructions. For all my projects, the data source is an intrinsic part of the application and I don't mind having a class file in the archive that represents the data source.
The above data source is using a Java DB (or "Apache Derby" for old school people). As some comments in the ArquillianDS.java file describe: GlassFish has problems using a simple URL connection string combined with Java DB. Hence I resorted to specifying all attributes of the #DataSourceDefinition explicitly. Recently in another project of mine (alas not a public one), I used the same construct of deployment time data source definition but targeting MySQL. Here's that data source definition and it works on both servers:
#DataSourceDefinition(
name = "java:app/env/maLivechatDS",
url = "jdbc:mysql://localhost:3306/malivechat_db?createDatabaseIfNotExist=true&user=root&password",
className = "com.mysql.jdbc.jdbc2.optional.MysqlDataSource"
)
#ManagedBean
public class MySQLDataSource { }
Note that the driver is MysqlDataSource and not MysqlXADataSource. One point in my application uses a rather complex transaction scheme and GlassFish ran into problems if I used the XA-driver. However, the non-XA driver used by my application still work properly with JTA transactions so for me, it was just a cheap trick to get the boat floating. You should probably use the XA-driver.
For JNDI Portability with portable DataSourceDefinition annotation, I test it On payara-5.192, wildfly-17.0.1, tomee-8-M3 and openLiberty-19.0.0.7
#DataSourceDefinition(
name = "java:app/env/jdbc/mysql_app_name",
className = "com.mysql.cj.jdbc.MysqlConnectionPoolDataSource",
url = "jdbc:mysql://localhost:3306/db_name?characterEncoding=utf-8&zeroDateTimeBehavior=CONVERT_TO_NULL&user=root&password=password",
minPoolSize = 1,
properties = {"characterEncoding=utf-8","zeroDateTimeBehavior=CONVERT_TO_NULL"})
I used it with MySQL connector 8.
refer to reference. for wildfly I created a startup bean class for configuration and set the annotation in the startup class.
for openLiberty add in server.xml
<application id="app_name" contextRoot="/app_name" name="app_name" location="../app_name.war" type="war">
<classloader commonLibraryRef="mysql"/>
</application>
<library id="mysql">
<file name="/path_to/mysql-connector-java-8.0.17.jar"/>
</library>
and put the war file in
usr/servers/defaultServer
folder