i want to write a Java EE framework for a generic type of applications.
I'm looking for a way to handle application specific config values in my framework.
To give an example:
A component supplies a stateless session bean that handles persistence and i want to configure the name of the datasource that is used in a config file in my application (for example in the web-inf folder of the applications ear).
Now i have X>1 Applications that want to configure X different datasources for their specific persistence management.
Can anybody give me an example how to do that?
Greetings,
Alexander
You should use the JNDI provider thats bundled with the application container. One of its purposes it to access resources, data sources in your case, in a highly dynamic fashion.
For JBoss, setting up a data source involves the following steps:
deploy a *-ds.xml configuration file to the JBoss server's deploy directory. This defines the global JNDI name of the resources. There should be plenty of examples for a lot of databases available on the internet.
add a resource-ref to the jboss-web.xml of any WAR or to the jboss.xml of any EJB jar for any bean that needs the resource. This defines the global JNDI name to local/component JNDI name mapping.
add a resource-ref using the local JNDI name to the web.xml of any WAR or to the ejb-jar.xml of any EJB jar for any bean that needs the resource.
Once those things are in place, you can perform JNDI lookups to access the configured resource.
You can do these things to configure multiple data sources in JBoss and then make one or more of these data sources available to the web applications and EJBs.
Related
Similar to What to put into jta-data-source of persistence.xml? and How to map jpa datasources in WildFly?
However, I am asking for something that would work on all vendors or at least WildFly, Glassfish/Payara, WebSphere Application Server classic, WebSphere Application Server Liberty, TomEE. I am not looking for something that works in a Java SE Unit test.
So far I found that java:comp/env/jdbc/xxx works in WebSphere Application Server and TomEE. There's a mapping exercise (which is expected) to get it working but I cannot get the same to work on GlassFish/Payara and JBoss/WildFly.
More specifically I do not wish to use default data source because for my scenario I am actually working on two different data sources. E.g. for reference data and another for transactional.
If all of the app servers you work with are Java EE 7 compliant, you can use the default data source, which is required per EE7 spec to be available at:
java:comp/DefaultDataSource
The app server you run on ought to let you customize the configuration of the DefaultDataSource.
Since I'm familiar with WebSphere Liberty, I can point you to this doc for default data sources on Liberty:
Configuring a default data source
If you are using WebSphere traditional, as of v9.0 it supports Java EE 7, and has a default data source available out of the box (under the spec mandated JNDI name).
If you want to use the same JNDI name that works on all servers, it's best to use resource references, as explained in What is resource-ref in web.xml used for?
Basically, you would define an arbitrary JNDI name (ideally without any java:comp prefix or similar, just something like "myDatasource") and then map it to the concrete JNDI name provided by the target server.You would need to define a server-specific descriptor for each server with the mapping the if the server cannot use the JNDI directly (e.g. glassfish-web.xml for GlassFish/Payara, jboss-web.xml for WildFly, ibm-web-bnd.xml for WebSphere Classic and Liberty). TomEE seems to support references without any prefix, so it should be able to configure a datasource without any additional mapping if you choose a name without a prefix.
We developed an app using JPA (via Hibernate).
And in WSO2 we expose a service in soap that uses the models defined in our app.
The persistence is configured through a persistence.xml file.
The way we deployed it is :
.car contains .aar (our app that contains a jar with our models)
inside the .jar in META-INF I can see the persistence file, but when calling the service it complaines about the fact that it can't find the persistence.
I tried to put the persistence file at the .aar level too but no success.
Do I need to put the persistence file at a particular place ?
Thanks !
We're using Maven and Artifactory, and therefore our ear files have names like
our-project-ear-0.0.1-20151215.151526-3.ear.
So JNDI names for our EJBs have names like
java:global/our-project-ear/our-project-ejb/AnEjbJar!com.acme.ourproject.SomeEjb.
These names are not just ugly and complex, they also embed temporary suffixes added by Maven/Artifactory.
I thought we could simplify the names via the JBoss-specific #RemoteHomeBinding annotation, but I do not find this annotation in EAP 6.3. Is there still a way to do this? If not, how can I control the JNDI name under which my EJBs are published?
Figured it out myself. The #RemoteBinding, #LocalBinding, #RemoteHomeBinding and #LocalHomeBinding annotations have been phased out in AS7.x. A version of the JBoss instructions for migrating from AS5/6 to AS7 (not the current one) states:
>In AS7 there is no possibility for custom JNDI names of EJB beans and it's not planned for 7.1.
>Therefor the annotation #RemoteBindings and #LocalBindings are not available.
The recommended approach is to use the default bindings. However, custom JNDI names can also be defined via the #EJB annotation, as stated in this Oracle blog:
The developer can select an additional JNDI name that resolves to a particular client view of a session bean by using the #EJB annotation. Starting with Java EE 6, the #EJB name() attribute value can be prefixed with any one of the three portable Java EE namespaces : java:global, java:app, java:module. This has the effect of exporting the dependency into the selected scope.
I think what you are looking for is :
#Ejb(lookup="java:/global/somecustomPath")
As this will not affect where in JNDI the bean is bound but rather where to find it in JNDI.
If I'm right this is because JBOSS7 is a JEE6 application server and JEE6 introduced the concept of Portable Global JNDI names in JEE6.
Is it possibile to scan some directories to find all jars and add them as dependencies in ears at runtime?
I'm using wildfly 8.1.0 final.
For example we have two separated ear:
ear1
ear2
And an external jar with some jsf managed beans, facelets, and static content (images, css, js):
jar1
Does exist any way to make all resources in jar1 to be accessible from ear1 and ear2 without put jar1 as module in ear1 or ear2?
I don't know any other way than add jar1 as dependency in ear1 and ear2 and redeploy ear1 and ear2.
Standard Java EE way is create EJB services in war1 module. After this you should use JNDI name lookup in ear1, ear2 and consume EJB interfaces provided by war1. If you need dynamicly add JSF resources (jsf pages, and static files) you should write custom implementation of javax.faces.application.ResourceHandlerWrapper. Your implementation should transfer resource request to war1 module (using EJB interface).
In this case you have weak dependency between ear1,ear2 and war1 modules. Also you can have a set of war modules and some registry with JNDI names or use list method: Wildfly jndi list.
But I am not sure how transfer call to war1 managed bean. I think you should use EJB in war1 module, and write some proxy JSF bean in ear1,ear2.
In JBoss, how is the sequence of the deployment phase? What is the order of object being instantiated and available to use?
Considering an enterprise application (*.ear), inspecting all deployment log (server.log) the deployment phase looks like:
All libs are deployed - .class files are loaded and available;
All *.jar modules are deployed - .class files are loaded and available;
If some *.jar is an EJB Jar, through the configuration files (Ex. ejb-jar.xml) or annotations, the JNDI tree is created;
If some *.jar has a persistence.xml file configuration, all entity and link to datasources are loaded;
All *.war modules start the deploy phase;
Through configuration files (web.xml), listeners and context-root are loaded and eventually security aspects.
Ear deployed successful.
Questions:
What about the resource adapters modules, the PersistenceContext and the EJB Pool?
When a persistence.xml is found, does a connection to the data-source and so to the DB pool start?
Since the datasource (DB) is configured in the standalone.xml or domain.xml, when happens the first connection to the DB pool? When I inject the PersistenceContext and use the EntityManager?
When the EJB pool is loaded and available to use?
Is correct to say that during the EJB jar deploy, the JNDI tree is created and then available?
When an EJB is discovered, it's loaded inside the pool (as reference to inject/lookup)?
When a .war module is deployed and ready, even if the full deploy of the .ear is not completed yet, possibly servlet or listener are started from the container.
What happens if some of this objects (listener, servlet) try to use EJBs or PersistenceContext or other objects? Are those objects available?
Is it possible to have deadlock problem and hang the deployment thread/phase?
It is possible to control the deployment order of jars and wars in application.xml using <initialize-in-order>true</initialize-in-order>
The lifecycle of the resource adapters is controlled by the connector architecture
The lifecycle of Container-Managed Entity Managers are managed by JBoss. Assuming you are injecting into an EJB using #PersistenceContext, this happens prior to #PostConstruct.
Singleton EJB initialization order can be defined using #DependsOn("OtherBean")
You can ensure the EJB endpoints are available using the deployment order in the first bullet
Not sure if it is possible to dead lock - it is far more likely that you will see a JNDI exception
I will try to address the rest of your questions:
When a persistence.xml is found, does a connection to the data-source
and so to the DB pool start?
Yes, that must happen (if no connection already is made), otherwise no table structure (DDL) could be validated or be created.
Since the datasource (DB) is configured in the standalone.xml or
domain.xml, when happens the first connection to the DB pool? When I
inject the PersistenceContext and use the EntityManager?
The answer to this question is: it depends. If your JDBC Datasource is configured with a minimum pool size MIN_POOL_SIZE>0 and has the prefill flag set to true, then WildFly will create MIN_POOL_SIZE connections to the DB server, without any deployments at all that use that datasource (after changing that flag you will need to disable/enable the datasource). Otherwise on deployment: it is created as many connections as needed (depending on what you do on deployment, but for simple applications a single one), except you have a MIN_POOL_SIZE>0 defined and the strict minimum flag is set to true, in which case AT LEAST MIN_POOL_SIZE connections will be created.
When is the EJB pool loaded and available for use?
It is available for use after deploying the EJB submodule, with all its dependencies.
Is correct to say that during the EJB jar deploy, the JNDI tree is created and then available?
I would formulate that in the following way: After (not during) it is checked that all EJBs can be deployed (e.g all their dependencies could be solved), then JNDI entries are created (in the JNDI tree). According to what I noticed, if a single EJB fails, nothing is deployed, which makes me think I am right here.
[When a .war module is deployed] What happens if some of this objects (listener, servlet) try to use EJBs or PersistenceContext or other objects? Are those objects available?
Yes, definitely. We use that feature to execute some init code from a servlet, when the WAR file is deployed (e.g to create some entities with some default values).
Is it possible to have deadlock problem and hang the deployment thread/phase?
Theoretically yes, practically no (I doubt the guys at RedHat did not think about this).
Some tips: if you use MySQL, you can check what connections are made to the server with show processlist. Otherwise if you use Linux/Unix, you can check all made connections to your DB server with netstat.