For usage with #DataSourceDefinition I'd like to have the DataSource class loaded from the application that uses this #DataSourceDefinition annotation (or equivalent data-source element in a deployment descriptor).
This works for basically every server as per the test I added in the Java EE 7 samples project.
For example, considering this data source definition in web.xml:
<data-source>
<name>java:app/MyApp/MyDS</name>
<class-name>org.h2.jdbcx.JdbcDataSource</class-name>
<url>jdbc:h2:mem:test</url>
</data-source>
The jar containing org.h2.jdbcx.JdbcDataSource would reside in WEB-INF/lib.
This is very convenient in CI testing when testing against a server that's automatically downloaded, and where the name of the deployed .war is unknown in advance (since controlled by say Arquillian).
While nearly every server supports this, Liberty 16.0.2 throws the following exception for either java:app/MyApp/MyDS or java:global/MyDS:
CWNEN0011E: The injection engine failed to process bindings for the
metadata due to the following error:
java.sql.SQLNonTransientException: J2CA8022E: Application xyz23-zvf does
not have any shared libraries that provide org.h2.jdbcx.JdbcDataSource
for dataSource java:global/MyDS.
The IBM instructions refer to setting up a shared library that lives on the local file system, but for several classes of data sources (e.g. those that only have internal meaning to the application), as well as for the mentioned CI testing this is not practical.
Is there any way to let Liberty load the data source from the application like most other Java EE servers do?
Related
I am unable to find a code snippet for creating a datasource in Liberty via a Java Client. I looked up the ConnectionManagerMbean, but its documentation says that the Mbean instance wont be available until it is first used.
Can someone point me in right direction. I am kinda new to both Liberty and JMX so please bear with me if this sounds kinda rookyish.
Thanks in advance.
The reason you are unable to locate any examples of creating a Liberty data source via JMX is because it is not possible in Liberty to create data sources via JMX. In Liberty, data sources can be created via server configuration - the dataSource element - or via the #DataSourceDefinition annotation within an application component or <data-source> element within a deployment descriptor (such as web.xml) of an application.
Once you have created the data source, as you mentioned from the ConnectionManagerMBean documentation, you will need to use the data source first (access it from an application) before the MBean is made available. This aligns with Liberty's goals of having fast startup time and only loading/initializing what applications actually use. The behavior you observe sounds consistent with this, and you just need to perform an operation within your application first, and then you should hopefully be able to access the MBean.
I'm relatively new to Websphere. I have created a WAS ( Websphere Application Server 8.5) profile configuration on local, manually from scratch which contains multiple data sources, queues, connection factories and activation specifications. ( Windows 7 PC). I backed this up using backupConfig.bat. I wish to replicate this profile configuration on another system where the Websphere Application Server (installation cannot be altered) has a different Node and Cell name. Is there a way where I can replicate it , without having to manually create the resources again,one-by-one , in the local WAS profile on the new system? When I googled this, it threw up the manageprofiles command, though I am not sure if it's backup option will work in my case. Thanks in advance.
If these are simple queues, datasource etc you can use Property based configuration - see Using properties files to manage system configuration.
You export configuration from one cell and import to the other.
If you have few elements you can use WebSphere Configuration Migration Tool (Eclipse plugin), which will allow you to select graphically which resources to move - it generates jython script that you can execute on target environment.
After several days of searching, trying and head-banging, I post this question to SO although it seems to be answered already.
Here is the scenario:
I have an EAR application containing (for the moment) one WAR and one EJB module. The EJB module uses JPA (persistence.xml) and some Stateless Session Beans are exposed via Web Services. The web services use Basic authentication with a jdbc realm. The web module uses form authentication with the same realm.
The requirement:
I need to be able to deploy this application either on different servers (dev/test/prod) or on the same server (or cluster) with different deployment descriptors. The deployment settings that need to be different in each application instance are:
The jta-data-source in persistence.xml
The realm-name in web.xml
The javax.faces.PROJECT_STAGE in web.xml
The webservice-endpoint\endpoint-address-uri and login-config\realm in glassfish-ejb-jar.xml
The context-root in application.xml (i could move it to web.xml if it made any difference, see below)
The realm in glassfish-application.xml
During my research, I managed the following:
I can override the javax.faces.PROJECT_STAGE using asadmin set-web-context-param
I can override all settings in glassfish-ejb-jar.xml using a deployment plan during asadmin deploy
The same applies for glassfish-application.xml
I can probably override context-root during asadmin deploy (I don't know how would this work with more than one web modules in the EAR)
So far so good. This leaves me with the following problems:
How can I easily modify the the realm-name in web.xml?
How can I easily modify the jta-data-source in persistence.xml?
By easily I mean during deployment or using something similar to a deployment plan jar. Maintaining multiple copies of ejb.jar or war just with a modified .xml file is not an option.
Just to be clear, the need is to have different databases (either in different stages of development or for different customers) using the same application. The application uses one persistence-unit but it needs to point to different databases (hence the jta-data-source). The realm is a jdbc realm (on the same database) that also needs to be different per application instance.
Any help or pointer would be greatly appreciated.
Have you thought about preparing templates for the deployment descriptors, and populating them with value from property file during build? If you are using ant, you can use the expandproperties filter.
You can do all those things with a deployment plan jar.
It looks like the content of the deployment plan jar is pushed into archive/directory tree of the application BEFORE any of the heavy lifting associated with deployment happens.
See
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/deployment/javaee-core/src/main/java/org/glassfish/javaee/core/deployment/DolProvider.java
and
http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/Archivist.java
I am having troubles migrating from OC4J 10.1.2.3 to 10.1.3.1.4. The problem is for applications that have multiple EJBs (all are 2.1, no EJB 3.0). Jdeveloper will take the default ejb-jar.xml (the one required for Jdeveloper to run it on its stand-alone OC4J instance) and package it into each EJB JAR module NO MATTER what. This results in the app server drilling into each EJB JAR module when deploying, and find the same ejb-jar.xml file N times (where N = number of EJB Modules). This results in duplicate EJB references and will break any JNDI lookups such as: "java:comp/env/ejb/EJBName". Thus deploying an app that has 3 EJBs, EJB1, EJB2 and EJB3 causes the app server to register 9 EJBs instead of 3. I need a best practices way, but in between the way 10.1.3.4 and JDeveloper are acting the situation is rather dire...
Side note: They will work if the web app's JNDI look-up code is refractored to just "ejb/EJBName". This is not desirable though.
You should check the Oracle documentation to see which is your case.
The Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide is a good start
According to the Oracle® Containers for J2EE Services Guide, chapter 2: Using JNDI
when you use the form "ejb/EJBName" you perform "local" lookup. If you want to use the full form you must check the "Enabling Global JNDI Lookups" section of the "Using JNDI" chapter.
The problem was multiple reference in our deployment profiles. We were create a deployment profile for EACH EJB. This meant that each EJB had it's own ejb-jar.xml (this file contained a description of all EJBS in the project). Therefore, every time JDeveloper created an EJB, it placed a descriptor of all EJBS in each EJB it generated, causing an NxN amount of references. Therefore Nx(N-1) extra references.
Now, the key point is that Oracle Application Server 10.1.2.3.0 and bellow did not care about these duplicate references. However as we can see, 10.1.3.1.4 is a much different version and this did break.
Our fix: to have only 1 EJB Deployment profile that contains all of the EJB classes and the POJO's that they use. Remember, before there was 1 EJB Profile for each EJB... All this did was allow for Jdeveloper (which is crap IMHO) to correctly generate a valid EAR. A combination of Jdeveloper and Oracle's Application Server's crap is what caused this.
I have a set of EJBs and other Java classes which need to be configured differently based on the system environment in which they are deployed: production, test, or lab. The configuration information includes stuff like URLs and database connection information.
We'd like to deploy the same exact product (EAR file) in each environment, and have the code then figure out where it is and what its configuration should be, without having to reach out to each deployment server in each environment to make changes.
What is the best way to configure all these components in a centralized, reliable, easy-to-maintain fashion?
Thanks for your thoughts.
The best, IMHO, is to use JNDI entries.
You may have to recode some parts of your application in order to use theses entries instead of plain vars, but with this setup:
Configuration is server-independant: each vendor provides its own implementation, but spec is a standard.
In a clustered environment, config can be persisted in a cluster-wide JNDI tree (see JBoss)
Configuration can be changed thru webadmin without restarting server.
How database connection pool information is stored / configured depends on the app server vendor. Put other variable stuff in property files on the classpath.
If you are deploying the exact same EAR to three different instances of a certain container than you will have to edit the deployment settings as there is no way that the deployment process could have any idea about which one of your three versions you would like to use at a particular deployment.
Deployment settings should go into JNDI entries as Piere-Yves said above.
If I were you, I would have my deployment-script (Ant?) properly populate the JNDI entries depending upon which environment you are deploying to.