We Keep Coding

Is it good to duplicate jpa entities for business objects?

I have a design/architectural problem:
I've started developing a java web application. I thought of using 3 layers: a persistence layer (with jpa and hibernate), a business layer and a presentation layer. My problem now is:
the jpa entities would make the model but can or may I use the entities as business objects?
Is this a practice? My common sense says I shouldn't, but then, I need to duplicate these entities as business objects?
Finally, I'd like the presentation layer to be really decoupled from the other layers. While using spring mvc with jsp at first, I'd like. if it's suitable, at some moment to switch to javascript-based application that communicates with the backend through rest requests.

Yes, you can. Outside the persistence context, the JPA Entities are like simple POJOs. It is legal to use them in business code (actually, as hinted by JB Nizet, you usually ALWAYS use them in your business layer without DAO). If it is tightly related to the Entity, you can even add business logic into your JPA beans. Nevertheless, it will be harder to read and understand what the code does. But if you have a reason to do that - there is nothing illegal. It all comes down to software design practices and what you need most.
When you want to change your app into the REST-powered service, it is not difficult. You will have to change the Servlet you are currently running your app with for a JAX-RS or other framework Servlet which will handle HTTP requests in a REST manner for you. It is done in web.xml. Then, you will place your html-pages in any place, where it is accesible for the remote hosts, and connect them to your REST-service with the Javascript AJAX or sth. You should take care of CORS then.

Creating a webservice with proper layering in JavaEE

I am using Java EE for running my backend system and I have a question regarding how to layer it appropriately in terms of creating a web service.
I am pretty much organizing my application after the principles of DDD which means I have a domain layer, repository layer and a service layer. So the service layer are annotated with #Stateless and they are my EJBs.
Now, I could go crazy and annotate this service class with more annotations for the JAX-RS framework...but I don't know if this is correct for several reasons:
Wouldn't this mix the layering a bit?
How could I then version my webservice? Let say that I create a webservice today, and tomorrow I find out that it is really bad, however during the night someone have created an application that uses it and if I trash it the applications could no longer be used. What I want is a webservice that can be found on www.myurl.com/api/v1/customers
and the new webservice on www.myurl.com/api/v2/a_new_customers_webservice
That is what I want in some sort.
There may be other cons too?
So what would the solution be? Am I correct if I say that I create another set of classes that I annotate with JAX-RS annotations and then the methods could internally use the methods from the EJBs in the service layer?
If there is going to be another webservice version I can create another set of classes that uses other URLs and logic. Or am I all wrong? How would you organize this?

The underlying question is how to organize code for reuse. As you pointed out, you can:
annotate your EJB services with JAX-RS to make them web service;
create EJB web services (i.e. with JAX-RS annotations) that reuse other common EJB services (one level of indirection);
create EJB web services that reuse common logic as POJO (one level of indirection).
All three a valid choices to me.
If you're confident about the API of the EJB service, but not the API of the web service (there could be some impedance mismatch), I would go for 2.
If you are not confident about what your EJB service should do, then that's probably the first thing to figure out ;)
If you're confident now, but suspect it might change in the future, I would pick the simplest solution 1 for now, and refactor later as necessary depending on what must be changed. Apply YAGNI.

The proxy object in EJB

I am reading the Enterprise JavaBeans 3.1 book and I wonder if I have understood the concept of EJB proxy object correctly. I now know that it follows the proxy pattern and I have read some about it.
When we make the interfaces for the beans, we are doing it because we want to have the proxy pattern implemented. This helps us because the clients are only concerned about what we can do and not tied to directly to a class but rather a interface that can act as if it where the real object.
So, the container probably instantiate the proxy objects implementing the corresponding interface and add some magic code (networking code) before invoking upon the real EJB for us, because the proxy object is automatically made right?
Have I misunderstood the concept? If thats the case could someone tell me whats wrong?

Correct. The interfaces you're writing for your beans would have been sufficient if your application was confined to a local JVM. In this case no proxy would be needed, as the implementing class could be instantiated and supplied directly.
Clients of EJBs cannot work on their implementing classes, as they don't have them in their classpath. EJBs are location-transparent, you can call them across the network, or from another application located on the same server, but isolated out by different class loaders. In such cases, you need to have proxy objects to marshal, send over the network, and unmarshal the parameters you supply to EJB calls and results of these calls that you receive. And on the client side, you need a dummy EJB interface implementation, that forwards your calls to the server where this EJB is installed.
Proxies also handle other functions, such as starting/ending transactions around EJB method calls.
EDIT: if you're curious what EXACTLY such proxies could do, take a look at overviews of RMI in Java and AOP (either in AspectJ or Spring). It will give you the idea what kinds of tasks can be implemented this way.

Are you referring to the proxy interfaces to stateless (and stateful) session beans and message driven beans?
If so, I think your understanding is correct. The only thing you seemed to have missed is the concept of instance pools for stateless beans. The container does not instanciate these per request, but instead provides an implementation when needed.
Also, using proxies allows the container managed things to take place: transaction management, asynchronous thread management etc.

Inherent dangers of using ThreadLocal variables with EJB3?

I'm experimenting with a solution to authorization and authentication by storing a subject class in a ThreadLocal map. The design is for an API, so I won't have access to the servlets involved, and I need to use EJB3 (so CDI is not an option). I have a few questions about using ThreadLocal with EJB3
Presuming that each request cleans its ThreadLocal map after it's done, is there any risk in using a ThreadLocal variable with stateless session beans? In other words, is there any risk that two requests get access to the same thread at the same time?
Is there any way of enforcing servlets to clean the ThreadLocal after they're done? I've looked into interceptors, but I've understood that they work poorly with EJB3, and work varyingly well in different application servers. Any other way?

Regarding Martin's answer, it's worth noting that Spring Security itself uses a ThreadLocal anyway by default (SecurityContextHolder), so I'd be cautious about using it if you need the security context to survive across EJB invocations. Certainly it won't work across remote invocations; it might with local, but I don't think there are any guarantees.
Typically, when using Spring Security I avoid EJB and use Spring Framework for wiring a POJO middle-tier and for providing services like transaction demarcation via AOP. The security context is then available throughout the middle tier as the thread remains the same across the entire call.

I'd recommend against using ThreadLocal in an EJB container. Authorisation and Authentication is a cross-cutting concern, I'd personally look at using something like AOP for that (e.g. How Spring security deals with it).

To answer my own question, no, not with any security it seems. Using a threadlocal variable may work if I have control of the whole process, but if I did then I could use CDI och JSP to keep request local variables.
Points to everybody who answered though.

Using a Servlet for a non-servlet application

I know 'normal' Java, but am new to the world of servlets, containers etc. Because of that I am not sure which approach is most sensible.
Situation: I have created a Servlet that receives information and stores it in a database. This database gets read by other applications.
Now what I need is an application that receives the exact same information and stores it in the same database. However this new application needs to pull this information from another server (I'll be using httpClient for this) instead of it being pushed to it. Both applications will co-exist.
For this new applications I see the following two options:
Make a stand alone application. For this I can copy paste a lot of the existing back-end code, but I will need to make some modifications (the servlet container offers a context, easy database connection pooling etc.) Further I might need to use some wrapper so this can work like a proper daemon that I can start, but also gracefully stop/restart etc.
Make the new application part of a Servlet. That is: just start a new Thread in the init() of the servlet that will run the new application. This would allow me to reuse all the backend code I already have, without needing to rewrite any of it. I only need to write the code that does the HTTP-GET requests to the other server. With this approach it will also be easier to start and stop the service, because I can use the Servlet container for that.
Some info about the project: the backend code that parses and writes the data to the database has a few threads, but is not very complicated. Writing the code for the original servlet was about one week of work. With the existing code base I feel this new application should probably be 1, 2 days of work max.
The way I see it option 2 is easier. But it feels a bit like I would 'abuse' servlets.
So my question is: Aren't servlets for applications that should handle requests, instead of applications that make request? Are there some huge drawbacks I don't see here? Which option would make most sense?
tl;dr: Can I write an application that doesn't serve requests as a Servlet?

Don't copy and paste code.
Write a re-usable class/module which handles storing the information in the database which can be used by both 1) the servlet and 2) standalone code which retrieves information from a HttpClient.
This way the same piece of code handles the same logic - how to store the information in the database - whether the information in question is being pushed to a servlet or being fetched from a remote URL.

Servlet containers are thread-managed environments. In general, don't start your own threads in a servlet, or bad things can happen... starting and stopping the application context, for example - the appserver doesn't know about the threads you might have started so won't stop them with your app... (More detail in this SO question)
I would try to extract the logic I need from the servlet into classes that don't depend on the Servlet API, and redesign the servlet to make use of these classes. (Refactoring). The servlet API, as you note, is all about receiving requests and sending responses.
I can re-use the logic in my new non-servlet classes anywhere I like, including a non-servlet part of the application that polls out pull that info.

You could use, but you shouldn't, it is a very poor design.
If you have two different ways to access your application (one through servlets and other as standalone), you should create at leats three classes:
One class that does all the work relating database, etc.
One servlet that calls the first class
One stand alone class (or whatever) that calls the first class
In this way, you don't copy/paste, and you can reuse your code (even you can have a third way to call the class that do the heavy work

If you want to reuse code, have this code as part of a "Service" or "Business Logic" layer that will be used both by your servlet and non servlet application.
Package the code as a jar and use it in both applications.