There are several Java EE APIs that exist as just that - APIs (interfaces, domain objects, enums, etc. but no actual classes that do stuff). APIs like JPA, JDBC or JTA. These APIs must then have implementations; for JPA there are impls like Hibernate, MyBatis or TopLink. For JDBC there are drivers for each specific RDBMS. For JTA there is Bitronix and Atomikos.
But what about JavaMail? Is it just an API? If so, what are some common implementations of it? If I deploy my Java app (as a WAR) to Tomcat 7, where does this implementation come from (specifically)? Does Tomcat have its own JavaMail impl? What JARs/packages/classes compose the Tomcat impl?
JavaMail is a standard JSR 919
TomEE server has support for JavaMail.
The configuration is very easy and goes like this
tomee already comes with apache-tomee-plus-1.6.0/lib/geronimo-javamail_1.4_mail-1.8.2.jar
in tomee.xml (configured at $TOMEE/conf) you add an entry as described by Configuring JavaMail
from inside your classes you can reference the mail session via #Resource like described at javax.mail.Session resource and smtp authentication
Related
I am trying to configure a JDBC XA resource in Tomcat 8 that can be used with Atomikos to implement transactions using Spring and JTA.
However, I have not found a tutorial describing how the configuration must be done. The documents I have read begin with the configuration in Spring and Atomikos, but they do not mention how to configure Atomikos with Tomcat. In addition, their examples configure JTA/XA transactions with PostgreSQL and/or MySQL, but not mention databases in AS/400.
I have found this post, but the response is not clear to me.
Does someone know how to configure a JDBC/XA resource in the server.xml configuration file used by Tomcat?
You can use databases in IBM AS/400-iSeries machines using the (1) Universal DB2 driver, if that option has been enabled in the server, or (2) the traditional IBM Toolbox for Java or jt400/JTOpen opensource library.
Some years ago, I used the JTOpen JDBC XA drivers for accessing the databases and the datafiles in the iSeries. It works just like any other JDBC driver.
If you want to create an stand-alone program, IBM provides documentation for implementing JDBC XA distributed transactions using JTOpen drivers.
If you want to use an application server, you only need to configure the datasource (just like any other database). You may check IBM documentation for configuring XA datasources in Websphere.
If you want to use Atomikos, the XA-datasource must be configured just like you configure any other JTA/XA connection. There is a forum entry describing an example.
I have found this post, but the response is not clear to me.
Check the documentation for Atomikos-Tomcat integration. The resources must be defined in the TOMCAT_HOME/conf/context.xml file. There is an example you can download to understand the Atomikos-Tomcat configuration.
I see URLs like jnp://localhost:1099/ mentioned when reading about HornetQ. What is the jnp protocol? What does it stand for? Where is the specification?
All I could find was this forum thread, "What is JNP", in which the question does not get answered.
In short, JNP is the official JNDI naming implementation of JBoss AS prior to its version < 7.x, based on the JNP project (refer to the code repo URL).
From the new AS7 documentation:
Previous versions of JBoss AS (versions < 7.x) used JNP project
as the JNDI
naming implementation. Developers of client applications of previous
versions of JBoss AS will be familiar with the jnp:// PROVIDER_URL URL
they used to use in their applications for communicating with the JNDI
server on the JBoss server.
Starting AS7, the JNP project is not used.
Neither on the server side nor on the client side. The client side of
the JNP project has now been replaced by jboss-remote-naming project.
There were various
reasons why the JNP client was replaced by jboss-remote-naming
project. One of them was the JNP project did not allow fine grained
security configurations while communicating with the JNDI server. The
jboss-remote-naming project is backed by the jboss-remoting project
which allows much
more and better control over security.
Its specification is poor, most of the references we find about it are located at JBoss docs prior to the version 7, like in https://docs.jboss.org/jbossas/jboss4guide/r1/html/ch3.chapter.html
I followed this NetBeans guide here on RESTful web services using JPA - http://netbeans.org/kb/docs/websvc/rest.html
I thought JPA was supposed to be a specification and you would use something like Hibernate as the actual implementation in your application. But this guide doesn't make any mention of an implementation at all. So where is the implementation coming from, is NetBeans providing its own JPA implementation?
That tutorial uses Glassfish as the Application Server. It provides the implementations for the JavaEE Apis, and in the case of JPA, it is EclipseLink. The idea is that your application does not ship with those libraries (JARs) and instead rely on the ones provided by the Application Server
Once you have it working, if you wish to learn about different JPA implementations, or different Application Servers, then you can try running the same application on JBoss, which has Hibernate as its JPA implementation.
Presumably it is the JPA provided by the container (probably Glassfish).
Where I'm working the guys that are sitting across from me are working on a project. This is a JavaEE app which uses Struts, Spring, EJB 3.0, JPA, and Hibernate 3.0. They are using EJB 3.0 entity beans with annotations. I've been asking them why Hibernate 3.0 is in this mix and noone can seem to tell me. It feels like they've included Hibernate 3.0 because they were told to but are not using it for anything that they can't get from EJB 3.0 entity beans/JPA. They're using CMP and accessing all of the database functions via EJBs.
Can Hibernate give you anything in this setup that can't be provided by EJB 3.0/JPA?
Hibernate does have a JPA implementation but it can also be used standalone. It is possible to use Hibernate as the persistence provider in JavaEE. The JBoss application server for example uses Hibernate for its persistence. So if you are using Hibernate to provide the persistence in the app server, it may make sense.
If you are using an app server that does not use Hibernate for the persistence, then it sounds like you might not need it. Hibernate does have some extensions and things that are not available in JPA. Many other persistence providers also have these extensions (like Toplink or Eclipselink). Check with your app server provide to see if they have the extensions you might need or something similar to what you might have used in Hibernate.
JPA itself is just a specification, not a product, it cannot perform persistence or anything else by itself. JPA is just a set of interfaces and requires an implementation (a persistence provider). There are open source and commercial JPA implementations (Toplink Essentials, EclipseLink, Hibernate EntityManager, OpenJPA, Kodo, etc) and any Java EE 5 (or Java EE 6) application server must provide support for its use (JBoss uses Hibernate EntityManager, GlassFish v2 uses Toplink Essentials by default, GlassFish v3 uses EclipseLink by default, WebLogic uses Kodo by default, etc)1.
Now, one of the nice things with JPA is that it can be used outside a container, for example in a Java SE application or in a testing context (that was one of the big problems with EJB 2.x). But in that case, you need to provide an implementation as you won't get the one provided by the container. As we saw, Hibernate EntityManager - which is build on top of Hibernate Core - is one of them and this may explain why you see it.
1 Note that most (all?) containers offer a way to replace the default implementation that they provide. It is for example possible to use Hibernate instead of Kodo with Weblogic or instead of EclipseLink with GlassFish. This may be another reason why you see it in the mix.
we are wanting to use a JNDI service with our client applications (all written in Java SE 6) and here is our doubt: what are the dependencies? Does the JVM already comes with all the classes that we'll need to access these services? If not, where can we get them?
Like JDBC (Java Database Connectivity), JNDI is not a service, but a set of interfaces; it allows applications to access many different directory service providers using a standardized API. Just as with JDBC, the JDK contains the JNDI interfaces but does not include a JNDI service provider -- although Sun Microsystems provides adapters for connecting to existing directory service providers, such as LDAP (lightweight directory access protocol), DNS (domain name service), and CORBA. However, you can use one of several free or open source JNDI providers in your J2SE (Java 2 Platform, Standard Edition) applications.
What you're looking for is package javax.naming, which is part of JavaSE 6.
Sun's guide to JNDI.
Now, unless you're building a web application, JNDI is quite a complex beast. If you can afford to bundle Spring with your application, the lookup of an object with Spring is a no-brainer.
Yes, Java comes with all classes necessary to use JNDI. See the tutorial for some examples and explanations.