I have an ear that use a datasource (for a JPA persistence unit).
Now I need to deploy multiple versions of this ear in the same jboss, each pointing to a different database.
How can I handle this.
I've seen that it's not enough to deploy the datasource xml file inside the ear, with different parameters in each ear (jdbc url/user/password) since the datasource is globally scoped and will be shared by all the ears.
Do I need to use a different datasource name for each ear and to change the persistence.xml file for each deployment? Isn't there any other option?
I'm using JBoss 6.
Edit: Some more details
As I said the datasource is used for a JPA persistence unit, but I didn't mention that the same datasource is used directly inside several classes that need to do direct jdbc access. So changing the name of the datasource isn't a good option.
I think there isn't any option to do this. JBoss AS always scopes data sources globally. There would theoretically be the #DataSourceDefinition or data-source element in application.xml that can be app scoped.
Unfortunately, this one doesn't seem to work in JBoss AS 6 at all and even if it would work, it was stated by Jaikiran Pai that such a data source is not allowed to be used for a persistence unit anyway.
See http://community.jboss.org/thread/161032 and https://issues.jboss.org/browse/JBAS-8816
But if you're already putting different *-ds.xml files inside each EAR, then it wouldn't be that bad to also put a different persistence.xml inside each one, would it? At least you have the indirection that the persistence unit offers you. It would be worse if the data source name would be used directly at many places inside the EAR.
It's probably not an option, but just in case, GlassFish does allow embedded data sources to be app scoped.
If you're interested in this feature for JBoss AS, you might want to express this here: http://community.jboss.org/message/642506
Related
I would like to add some persistence to save some application data and I feel like I have searched the web for days without any success.
I have found some older links and the eclipse Gemini project. However, I suppose I am too new to understand the implementation or it is just a little dated. Probably, more of my lack of knowledge.
Anyway, is anyone willing to point me to a working example and/or provide me with some assistance offline?
If you want to use H2 with plain JDBC, you won't need the Gemini project. In this case you can wrap the H2.jar with the corresponding JDBC driver in a single bundle (plugin) and implement your db access there.
The Gemini project is for using persistence via JPA, which works with any JDBC capable database.
In either case, be aware that in an OSGi environment like Eclipse RCP, there is one classloader per bundle. This leads to lots of complications. We are using Hibernate as JPA engine within our E4 application and we cannot split the JPA configuration, the JPA engine and the entity beans :-(
We tried using EclipseLink as JPA engine but this doesn't work on all our entities :-(
I found this blog article by Raja Kannappan which briefly explains class loading in OSGi.
You can read more about JPA in The Java EE Tutorials (although JPA is part of Java SE, too).
Hope this helps.
I have seen some documentation on connecting to more than one database/data source via JPA, but this is not what I want to do exactly. I want to use one database provider for development and a completely different database provider for production (and probably QA). This question would also be applicable to supporting different production environments with different database providers (ie, DB2 for Client 1, Oracle for Client 2, MySQL for Client 3, etc).
In my case, I would like to do the following:
use JPA with Apache Derby for development purposes
use JPA with IBM DB2 for production purposes
We do not use Spring :(
With MyBatis, I could simply provide XML mappings for each database I wanted to support. And map all of results back to the same entities/POJOs.
So far it seems to me, that JPA will require custom everything up to maybe the Service layer (with entities, DAO, sql all being custom per database).
I want to know how you would go about setting up your application to use Derby for development and DB2 for production. Can I get by with using the same entities for both, should I separate the DAO layer into separate projects, can I use one persistence.xml, etc.?
Please let know what approach you would suggest to accommodate this.
This is a pretty common scenario, you don't need to duplicate anything if you are using JPA properly. You can use the same #Entity classes and DAOs.
If you are using Maven you can make the connection settings specific to some Maven profile, e.g. create profile for each environment and then let Maven resource filtering populate properties in your persistence.xml file (see this answer).
I am working on a web application which uses RAP. In the application there is one bundle which contains the model which is backed by a database. I would like to create bundles which provide REST services which will make use of the model bundle.
I looked at the Application#addEntryPoint but that it just for UI contributions - not for services as such.
I also read FrankAppel's post http://www.codeaffine.com/2011/08/26/raprwt-osgi-integration/ and wonder if RWT and Felix might be the way to go. It looks promising but Felix is new to me.
Is it possible to add these REST bundles to the RAP application and set them up to handle /rest/* URLs? Or would it be more sensible to keep the 2 parts completely separate and to share the model bundle in a different way?
When using RAP, any active bundle may contribute to the usual "org.eclipse.equinox.http.registry.servlets" and "org.eclipse.equinox.http.registry.resources" extension points. You just need to make sure the name of your RAP application's entry point(s) and the paths of your ressources and servlets won't overlap.
So in practice, you can just develop your REST services as if there was no RAP component. The two will happily live side-by-side within the same servlet context.
In a Java EE project, I've found a recurrent solution for configuring the application that consists on the use of #Injection of primitives/Strings on managed beans, avoiding external dependencies on that way.
What about #Entity? Is there some "good practice code" for configuring entities using only Java EE (no Spring)?
CDI does not support injection into objects that are not created by the CDI container (more info here). Since entities are created by JPA provider when they are loaded from the DB, CDI would obviously not work.
So, in plain Java EE world your only options are to move the logic depending on the injected resources out of the entities, or to access the resources via static methods from within the entities. Keep in mind the increased complexity when testing the entities if static state/methods are used.
I've recently been given a project to work on that involves writing a web application. I've never done Java EE before. A lot of resources on the web are dated and I'm having trouble figuring out what the current differences are between the various standards and Java technologies.
Originally I thought I really needed EJB 3.1 due to dependency injection, JPA, session management, and web services. I started experimenting with Glassfish but was told that we had to write the thing in Tomcat. So I've been trying to figure out what I need as well as what and how to put into Tomcat to get there. I've begun to question whether I even need EJB at all.
I want to use JFS, I think, for the MVC architecture. In learning about that I've run into both ManagedBeans and CDI, which according to some renders the former obsolete and also seems to provide all the dependency injection stuff I want to enable unit testing. I've also come to realize that I can get JPA outside of EJB in the form of Hibernate and maybe a few others. Additionally it seems that web services, which I don't know that I need anyway, come in the form of another standard I can't think of the name right now and this also can be installed independently.
My major issue here is session management and state. It seems to me that all which remains for EJB to do is provide #Stateless/#Stateful and #Local/#Remote. However, as I understand it, some of this is already exists in the form of session management in the servlet container...but I don't know how much or what the major differences are that I need to account for in order to decide if I need these things at all.
So my question is, what are the basic, essential differences that I need to know in order to decide if EJB is worth looking at or if I have enough in the form of other libraries and technologies? I've been all over google and Usenet and have not been able to find this information anywhere.
Just thought of another bit. As I understand it, the #Stateful bean annotation provides me thread-safe state saving. I'm probably not going to directly use threads, but I know Java does so behind the scenes a lot and suspect EE especially so. When I need to keep state I don't want to be dealing with threads if this already provides it.
ManagedBean
Java EE 6 has three different ways of defining beans that are managed in one way or another:
#javax.faces.bean.ManagedBean
JSF 2.0 introduced this annotation declaring managed beans in faces-config.xml. This annotation is used to access a bean from the Expression Language.
#javax.inject.Named
In an EE 6 container CDI this annotation is a built-in qualifier types to provide a name to a bean, making it accessible through EL.
#javax.annotation.ManagedBean
This annotation attempts to generalize JSF managed beans for use elsewhere in Java EE.
If you deploy in an EE 6 container (If you use Tomcat or another servlet container, you can also get CDI by adding the Weld jar to your web app), then there is really no reason to use #javax.faces.bean.ManagedBean. Just use #javax.inject.Namedand start taking advantage of CDI sevices.
CDI
One of the objectives of CDI specification is to bring together the Web tier and the transactional services, making easy for developers to use EJB along with JSF in web applications of the Java EE platform.
With CDI you have the following services among others : well-defined lifecycle contexts(influenced by seam 2 and conversation scope), Dependency injection, loose coupling facilities like interceptors, decorators and events and portable extensions, which allows third-party frameworks to integrate in the Java EE 6 environment like SEAM 3 extensions
Managed beans and EJB Services
First of all CDI applies to any managed bean. Some managed beans are EJBs. When we need to use the EJB services in a managed bean, we just add a #Stateless, #Stateful or #Singleton annotation. IMO they act as complementary technologies allowing you to have a flexible and gradual development just only adding some annotations.
So, when should we use a session bean instead of a plain managed bean?
When you need some EJB features that CDI is missing : declarative transactions, concurrency management, pooling, remote or web service invocation ,timers and asynchronous method invokation.
Of course you could also get all aspects using third party libraries - but this would introduce additional complexity to your project. In terms of functionality IMHO EJB are the place to implement :
Business logic, allowing you to have a cleaning separation of busniness logic and web tier logic (implemented by "JSF backing beans" which are CDI managed beans but no EJB)
Functionality which makes most sense for components which are entrypoints to the application (endpoints for remote invocations delivered via RMI or HTTP)
Finally if you need EJB services then you need an Aplication Server (eg. GlassFish or Jboss AS) if you only need CDI services you need a Servlet Container(e.g Tomcat) plus CDI libraries.
Do you need the features provided by EJBs, i.e. security and transaction management? If the answer is yes, EJBs might be a good option.
If the answer is no, and you only need dependency injection, CDI could then be a good option.
You can also get similar capabilities with other 3rd party products, like Spring (dependency injection, Spring security, etc), but deciding whether you use one (EJB) or the other (e.g. Spring) is in many of the cases a matter of previous skillset.
In my opinion, if there are no previous constraints, going Java spec compliant is a good investment.
I would suggest you to start with the CDI and proceed to the EJB's (which is really adding one annotation on top of your POJO) if the requirements needs them (just as it was told - transactionality, web services, JMX, timers, EJB asynchronous invocations).
It's quite reasonable to develop an application in which your entry point is an EJB which encompasses your call in the transaction and allows you to define multiple entry points. The EJB then invokes the CDI beans with the business logic in them.
It's also worth noticing that the TomEE is a certified Java EE 6 Web Profile developed on top of the Apache Tomcat.