Has anyone done this or attempted to do this for a preexisting project?
It seems there are two options to go with here, either using the embedded EJB API basically the following class
javax.ejb.embeddable.EJBContainer
Which expects a configured glassfish v3 install to be available (application scoped resources will make this easier).
The alternative is using the embedded glassfish jar files and the embedded glassfish API
I am looking for feedback from someone who has or who is in the process of doing this, links to blogs etc with a simple EJB & test case are dime a dozen.
If you've done this with any other EJB 3.1 container feel free to share.
Did you use any particular test framework for reasons other than it been your preferred tool?
Which JPA 2.0 implementation did you use, and was there a particular reason for doing so?
If you used glassfish which of the above strategies did you use? If not then which EJB 3.1 container did you use?
If you successfully did this, was it worth the effort and would you do this again for another existing project?
It seems there are two options to go with here, either using the embedded EJB API (...) which expects a configured glassfish v3 install to be available.
No, you can also use a minimal domain inside your project.
I am looking for feedback from someone who has or who is in the process of doing this, links to blogs etc with a simple EJB & test case are dime a dozen.
I've done integration testing of EJB 3.1 and JPA on my pet project (under Maven), inspired by Unit Testing EJBs and JPA with Embeddable GlassFish. Reading it is definitely worth it.
Did you use any particular test framework for reasons other than it been your preferred tool?
Nope.
Which JPA 2.0 implementation did you use, and was there a particular reason for doing so?
I used EclipseLink (because it was available at that time).
If you used glassfish which of the above strategies did you use? If not then which EJB 3.1 container did you use?
I used the Embedded EJB API, I was planning to run my code on other Java EE 6 containers when they'll be available.
If you successfully did this, was it worth the effort and would you do this again for another existing project?
Well, I think that integration / functional testing have value and find that the Embedded EJB API is really nice for that. It was not a pain to use it even if I don't consider my sample as a real life project.
For more complex scenarios, I keep an eye on the maven-embedded-glassfish-plugin (see also this answer).
I have written a small tutorial on my blog for using embedded glassfish 3.1 for unit-testing EJBs using javax.ejb.embeddable.EJBContainer. There are some pitfalls to it, which I got around by modifying the default embedded glassfish domain and putting some properties to createEJBContainer() call.
Related
I have a Java EE web application using features from the Java EE 6 web profile + the EJB Timer service and JavaMail. I'm currently using GlassFish 3.1.2 full profile during development, but I want to investigate the alternatives because:
There seems to be a bug with multipart forms in GlassFish 3.1.2 and GlassFish 3.1.1 had other problems hurting me which are fixed in 3.1.2. (catch 22...) That bug is fixed by the jar in the ticket.
There seems to be a lot more options for application servers supporting the "web profile" than the "full profile" and the former is supposed to be so much more lightweight.
I want to choose the best option for deployment
I am currently using the embedded application server feature of GlassFish for tests, so a similar facility for any alternative is desirable. At worst, I can live with stiking to GlassFish embedded for the automated tests.
Is it possible to "add" a JavaMail and EJB Timer Service implementation module to an applicaton server implementing only the web profile? Does it work well? If this is not possible, are there alternatives to using JavaMail and the EJB Timer Service?
Which application servers meeting my requirements can you recommend?
Finally, I considered using the "Asynchronous invocation" feature of EJBs which is not part of EJB lite. If I understood correctly, it is illegal to start threads manually when running in a Java EE container. In that case, how can asynchronous operations be started in the Java EE Web Profile?
I'm still relatively new to the whole Java EE ecosystem and terminology so please don't hesitate to ask me to clarify any parts of my question.
Supporting doc
Java EE 6 web profile vs Full profile
EJB 3.1 vs EJB lite
edit 1
According to the Apache TomEE doc, TomEE, TomEE+ and OpenEJB would fit the bill.
edit 2
Based on the AS 7.1 release notes, this thead and this issue JBoss AS 7.1.0 seems to implement all the features I need.
First of all, I have never used GlassFish so I cannot give you any information about that.
I'm not sure if your application is being build for a true production envrionment but jboss 7.1 does not yet have any official commercial support in case you run into trouble.
Jboss 5.1 optimized for JDK 6 has commercial support via red hat.
That being said, a jboss instance can be fully configured and is very flexible. That means that you can start with the 'web' profile and add/remove services you do not need. (Removing unused services is always advised for production environments.)
Here is a wiki that gives information about slimming a jboss profile in jboss 5. It indicates all steps needed to remove a service.
The slimming operation can also be reversed, so you can add anything you need to a certain profile.
So there are basicly two approaches:
Start with a profile like 'default' or 'all' and start removing services that are not needed for your application
Start with the 'minimal' or 'web' profile and start adding services you are missing for your application. You copy the services from a profile that has it. (I personally prefer this approach)
Adding and removing services can be a work of trial and error though. You need to search the internet for a correct guide for the service you are trying to add or remove. (Tip, always do your operations on a copy of the profile provided by the AS and document each step. That way you can start over if you did something that seems irreversible.)
I hope this is of any help.
tom's right that JBoss AS7 doesn't have commercial support yet. However, it is coming - AS7 is being productised as EAP 6 (annoyingly!), and is going into beta in a few days. The community version has been out for a few months now, and although it does have a lot of rough edges, it basically works pretty well.
AS7 has a much more modular architecture than previous versions. The idea is that you only load the modules you need, which means that although it's a full-profile implementation (as of 7.1), if you only use web profile features, you only pay the runtime cost of a web profile implementation. You still have the bits you don't need sitting on disk, but disk is cheap (7.1.0 is 125 MB all in - hardly huge).
I'm afraid i haven't used any other fully-grown app servers (not in the last decade, at least), and so can't comment on them. I believe Geronimo supports full-profile EE6, so if you don't need commercial support, that might be worth a look.
I have spent some time using Tomcat-based setups. Yes, you can add enough extras to Tomcat to create a sort of 'bionic Tomcat' that is basically an app server, but doing it yourself is work you really shouldn't be doing - pure waste. I haven't used TomEE. I'm not a big fan of Tomcat generally, i have to admit.
As you state, OpenEJB/TomEE definitely fit the bill. Here are some examples you might like based on the things you mention:
TimerService and #Schedule
TimerService and ScheduleExpression
#Asynchronous Methods
To configure your JavaMail resource in your test case, just do like so:
Properties p = new Properties();
p.setProperty("superbizMail", "new://Resource?type=javax.mail.Session");
p.setProperty("superbizMail.mail.smtp.host", "mail.superbiz.org");
p.setProperty("superbizMail.mail.smtp.port", "25");
p.setProperty("superbizMail.mail.transport.protocol", "smtp");
p.setProperty("superbizMail.mail.smtp.auth", "true");
p.setProperty("superbizMail.mail.smtp.user", "someuser");
p.setProperty("superbizMail.password", "mypassword");
EJBContainer.createEJBContainer(p);
Then inject the JavaMail Session into your EJB via:
#Resource
private Session superbizMail;
Behind the scenes the 'superbizMail.' part is shaved off all the properties and the resulting set of properties is passed into javax.mail.Session.getDefaultInstance(Properties props). The resulting Session is what is injected into the #Resource reference
I have a very small Java codebase that I would like to expose as a REST service that responds in JSON format (to be used by a Ruby on Rails project).
I have only notions about Java web servers / web frameworks. What would be:
a. a suitable Java MVC and
b. a java server
to ease my deployment? I am interested in:
easy to build(wrap) the solution
easy to maintain / configure the server
stable (not experimental)
We use CXF extensively. It is very simple standard JAX-RS annotation based. There is a good tutorial to set it up quickly. It works with or without Spring, but easier with spring, this is my preference. The other option would be Spring REST it is very similar to Spring MVC which is very easy if you know spring already, but on the other hand it is not JAX-RS based.
you might want to give Grails a try - it:
shares some similarities with RoR
comes bundled with an application server so it's very easy to get up and running
allows very simple deployment to a Java application server (e.g. Tomcat, Jetty)
has built-in support for JSON
has recent stable releases
is under active development
http://www.restlet.org/
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html
https://github.com/dhanji/sitebricks (my favorit)
For the server part of the problem, build your code so that it is a servlet and then deploy in a container like Tomcat or Jetty. (There are many others too, but Tomcat and Jetty work very well and are pretty easy to use.)
For the framework, I'd recommend CXF (I've had good success with it in my project) as it keeps the amount of configuration you need to write small (typically just add annotations to mark which methods are to be exposed; the annotations are standardized as JAX-RS), but many others are valid choices too.
Can anyone tell me if it is currently possible to "glue together" a partial Java EE 6 Web Profile over Jetty?
I've found a lot of articles about integrating standalone EJB 3 containers, JTA providers, etc with older Jetty versions, so I wounder if I could make it all work together.
I would like to assemble a Servlet 3.0 + CDI + EJB 3.1 + JTA (if needed, all I really want is declarative transaction management) + JPA 2 environment over Jetty 8 (or Tomcat 7 if no Jetty alternatives are available).
My questions are: Can it be done? Has anyone managed to do that? Any articles about getting OpenEJB, Atomikos, Weld, EclipseLink and Jetty (or any other similar stack) working together? Any magical "do it all" pom.xml files out there?
PS: Yeah, I know I could just use GlassFish (which I like very much). I'm just wondering about how hard would it be to get something similar working with a Servlet Container, and how the two environments would compare in terms of complexity, performance, size, deploying speed, hardware resource consumption, etc.
I'd describe this as still in the early stages, but here is what we have so far:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/assembly/openejb-jetty/
Note, Apache TomEE lives at a similar path, i.e. 'assembly/openejb-tomcat'. Plan is to call the Jetty version Apache JetSet and have it be fully embeddable. Most people with commit are currently working on getting Apache TomEE to be officially Java EE 6 Web Profile certified. I'd describe that work to be in the late stages. We've a great setup in Amazon EC2 to run the web profile TCK against TomEE using a hundred EC2 t1.micro spot instances. It's pretty sweet. The TCK agreement with Apache and Oracle does not allow us to share access publicly. However, any Apache committer can sign an NDA to get access.
Ok, so I mention all that about TomEE because the plan is once we're done with the Tomcat version, to do it all over again with Jetty (JetSet). Many of us committers, myself and Jonathan Gallimore for example, actually prefer Jetty by a large margin. But as the Tomcat integration code was much further along and had more users, we decided to just finish that one first. There is an incredible amount of work that isn't Tomcat specific that we will be able to leverage in the Jetty version; getting access to the TCK legally, the heaps of code to get it to run, the more heaps of code to get it automated, and numerous integration bits which are generic and not specific to Tomcat.
All that said, there's no reason others have to wait to work on a Jetty version just because most of us are still finishing the Tomcat version. Apache projects should be viewed as individuals working together, not companies like Oracle or Redhat or VMWare. That can be both good and bad. The good part is that if you or anyone else wants to hack on the Jetty version you can do that right now. You'll have to submit patches for awhile till you earn commit, but having someone else do the actual commit command is not that bad. If you start small and stay active and open, it's usually pretty easy to earn commit. The key to getting patches in quickly is a steady stream of small to moderately sized patches. Any step forward or sideways with no steps backward is a good patch in my opinion. As long as people can see where you're going it's good enough. Certainly more Agile than the one-big-patch approach and allows for all the really fun and collaborative magic to happen along the way.
Some threads which would be good places to say hello. Step 1 is just to say hello. No need to have code in hand to talk on the dev list or be taken seriously:
http://openejb.979440.n4.nabble.com/Jetty-Integration-td1457408.html
http://openejb.979440.n4.nabble.com/Jetty-Integration-td2318962.html
Tomcat has that stack implemented in a server called TomEE(formerly TomTom).
These are the components it uses.
Connector Apache Geronimo Connector
CDI Apache OpenWebBeans
EJB Apache OpenEJB
Javamail Apache Geronimo JavaMail
JPA Apache OpenJPA
JSF Apache MyFaces
JSP Apache Tomcat
JSTL Apache Tomcat
JTA Apache Geronimo Transaction
Servlet Apache Tomcat
As far as Jetty I'm not sure. OpenEJB is your only option for EJB outside of a JavaEE6 container(AFAIK) and I'm not sure Jetty is 100% tested with this. For CDI you can always use something like Seam.
In my opinion I believe the Spring framework would be your best option for the Jetty container(that's just my opinion though). In my experience after trying to get Tomcat working with Open EJB, Spring is a lot easier to set up.
You also have to remember Open EJB doesn't implement the entire EJB 3.1 stack at this point.
Also Open EJB is not tested on Tomcat 7 either. So you have to stay with Tomcat 6 if you go that route.
OpenEjb has not released a version with JPA2 support, although their development version supports JPA2 fine AFAIK.
I'm using embedded OpenEjb in Jetty6, because I could not get my app working in newer jetties yet. I think there is work under way to get an OpenEJB tightly integrated with Jetty like TomEE, but that may be some way off..
Geronimo is a complete J2EE stack which runs on top of Jetty.
There's a document on its setup on https://cwiki.apache.org/GMOxDOC30/configuring-virtual-host-in-jetty.html
We are looking at which REST framework to use and where to run it.
Given an existing WebSphere (6.1.0.17) environment would you use Jersey of Wink?
Or would you recommend a different platform?
As a third option why not use Spring's own RESTful features in Spring MCV. This is easy to code, test and maintain and (obviously) works for Spring right out of the box. The ease of managing code based on Spring REST is due to an architecture based on MVC, IoC and annotations. And you can choose best in class solutions to enhance your solutions such as XStream for serialization, Jackson JSON Support, and Springs own REST Template for a REST Client or unit-tests.
At its heart Spring MVC's REST features deal with REST as an Architecture not a Protocol and blends it well with other proven approaches such as IoC and MVC. When considering a framework the following REST litmus test is useful: see innoq.com/blog/st/2010/07/rest_litmus_test_for_web_frame.html.Springs approach checks more of the boxes, thanks to it's effective content delivery.
One thing all these frameworks fall down on is HATEOAS support, a way of in which the REST response contain links that correspond to all the actions that the client can currently perform from this resource. Most frameworks promises to introduce this soon, but a critical eye will be needed to understand what the best approach to this will be.
When delivering JAX-RS solutions such as Wink and Jersey, I've found more emphasis on conforming to a Java standard and less flexibility in the architecture (such as using other 3rd party packages). If conforming to JAX-RS is a requirement consider Restlets, Wink or Jersey. Otherwise, maybe it's worth considering Spring MVC's REST support.
I've deployed this kind of solution to WAS 7 without any issues or dependency conflicts.
I have no experience in using Wink, but I can share some of my experience in using Jersey running on Websphere.
The pros... very easy to use, it took me 5 minutes to get familiarized and I'm ready writing my first hello world. Jersey does automatically generate WADL for you based on your Resources package, albeit pretty basic... but you can customize the WADL documentation yourself.
The cons... sigh, I like Jersey, but with Websphere, it almost made me cry. First (this is not related to Websphere), I'm using Spring in my project and the Jersey release I use is 1.2. The problem is that release uses Spring 2.5 whereas I'm using Spring 3.x. So, I pulled out Jersey's Spring 2.5 to use Spring 3.x. Everything works fine. However, the Jersey test framework started to fail. I'm not able to boot up the built-in Grizzly server to test my web services anymore. Second, I'm currently tied to Websphere 6.1 which uses JDK 5. I believe all Jersey releases after 1.2 are compiled with JDK 6... that means, I'm out of luck until my company upgrade to WAS 7.
It is indeed a very stable Rest framework, very easy to use... but in my case, I'm just bummed out because all existing unit tests for the web services are currently commented out because I upgraded my Spring release to 3.x. I'm sure the latest Jersey release should be using Spring 3.x by now, yet I can't use them because I'm still using JDK 5 in WAS 6.1.
So, it's up to you to decide. By the way, I'm still using Jersey 1.2 in my project running in WAS 6.1.
On websphere 6.x the prefered method is jersey because it is easier to implement and it supports JAX-RS 1 and 2. (Watch out for the JVM version issues, Websphere 6 might not support the latest version)
Now starting in Websphere 8.x IBM introduced Apache Wink that will actually bring dependency and classloader issues if used together with jersery (because of the same interface implementations for JAX-RS 1 and 2).
There are a lot of examples on how to overcome this issues and make it work but I don't believe is worthy and perhaps Wink will have a better performance within websphere.
IBM recommends to use Apache wink. In fact, IBM has his own implementation of Apache wink.
I vote for Wink.
The reasons:
It's developed by HP and IBM guys. So I believe that IBM guys tested it with Websphere.
Actually AFAIK Wink is built-in in the Websphere 7.*
Also see this video
I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.
It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.
You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.
I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.