We Keep Coding

Is it necessary to use #Embedded for Spring?

I have models with nested entity inside them. Is it necessary to write annotation #Embedded and #Embedeable or it's not necessary in actual Spring version?

Yes you still need to use these in Spring, since these are JPA annotations and are necessary when you are embedding a given type within another entity.

Is it possible to add functionality to the #Column annotation?

I'm wondering whether it is possible to add additional functionality to the #Column annotation in JPA. Specifically, what I would like to do is tag columns of sensitive data with an #ProtectedColumn annotation: this would then tell the persistence framework to apply some type of data protection (encryption, tokenization, whatever...) to the values when storing them into the actual data store, and then reverse that process when reading the values from the data store.
So I might have a Customer class that included this code:
#Column(value="Name")
private String name;
#ProtectedColumn(value="CreditCardNumber", protectionType="ultra")
private String creditCardNumber;
Instead of storing the actual credit card number, this would then store the result of protecting the credit card number with the protection type "ultra" (whatever that may be).
Obviously, I don't want to re-implement all the database access functionality already present in the #Column annotation: I just want to extend its functionality. I know that annotations are not directly extensible (see Why is not possible to extend annotations in Java?), but it seems to me that it might be possible to intercept the value before it gets to the #Column annotation, so perhaps the field definition looks like this:
#Protected(protectionType="ultra")
#Column(value="CreditCardNumber")
private String creditCardNumber;
So my first question is whether this is even theoretically possible: if so, I'd appreciate any pointers on how to combine/extend annotations in this way.

You can use a converter. For example you can implement a Converter like he did:
use converter
He uses xml configuration.
If you want to use annotations, just have a look at these two java classes in this git repository:jpa converter with annotation
Therefore you can use the annotation
#Convert(converter = JPACryptoConverter.class)
(Given that JPACryptoConverter is a child of AttributeConverter).

Well short answer is No you can't simply extend the #Column annotation in Hibernate by adding a protection option to it but to provide a complete answer you can surely combine it with other annotations, to protect/encrypt a column in Hibernate you have two possible options:
Use Hibernate's #ColumnTransformer annotation to provide a customised column transformer for your column.
Use JPA Attribute Converter to provide a custom representation of your column.
Useful links:
For further reading about these two options you can check the following Thoughts On Java's tutorials:
How to map encrypted database columns with Hibernate’s #ColumnTransformer annotation.
How to implement a JPA Attribute Converter.
You can also check this answer to see how can you implement a custom Column Transformer.
A third option is to use Jasypth Integration library with Hibernate, you can read more about it in Integrating Jasypt with Hibernate 3.x or 4.x.

Best approach for linking diverse entity types in JPA

Short version for the hasty:
There's various tables/entities in my domain model which have the same field (a UUID). There is a table where I need to link rows/instances of such entities to other JPA-managed entities. In other words, the instance of the field in that link table won't be known up-front. The two approaches I can think of are:
Use an abstract entity and a TABLE_PER_CLASS strategy, or
use an #MappedSuperClass store the class name of the instance in the link table as well, or something similar that lets me define logic for getting the actual instance from the right table.
Both have advantages and disadvantages in terms of complexity and performance. Which do you believe to be best, is there maybe a third option, or have you tried something like this in the past and would advice/strongly warn against?
Long version in case you want more background:
I have a database/object model wherein many types have a common field: a universally unique identifier (UUID). The reason for this is that instances of these types can be subject to changes. The changes follow the command model and their data can be encapsulated and itself persisted. Let's call such a change a "mutation". It must be possible to find out which mutations exist in the database for any given entity, and vice-versa, on which entity a stored mutation operates.
Take the following entities with UUIDs as an (extremely simplified) example:
To store the "mutations", we use a table/entity called MutationHolder. To link a mutation to its target entity, there's a MutationEntityLink. The only reason this data isn't directly on the MutationHolder is because there can be direct or indirect links, but that's of little importance here so I left it out:
The question comes down to how I can model the entity field in MutationEntityLink. There are two approaches I can think of.
The first is to make an abstract #Entity annotated class with the UUID field. Customer, Contract and Address would extend it. So it is a TABLE_PER_CLASS strategy. I assume that I could use this as a type for the entity field, although I'm not certain. However, I fear this might have a serious performance penalty since JPA would need to query many tables to find the actual instance.
The second is to simply use #MappedSuperClass and just store the UUID for an entity in the entity field of MutationEntityLink. In order to get the actual entity with that UUID, I'd have to solve it programmatically. Adding an additional column with the class name of the entity, or something else that allows me to identify it or paste it in a JPQL query would do. This requires more work but seems more efficient. I'm not averse to coding some utility classes or doing some reflection/custom annotation work if needed.
My question is which of these approaches seems best? Alternatively, you might have a better suggestion, or notice I'm missing something; for example, maybe there's a way to add a type column even with TABLE_PER_CLASS inheritance to point JPA to the right table? Perhaps you've tried something like this and want to warn me about numerous issues that would arise.
Some additional info:
We create the database schema, so we can add whatever we want.
A single table inheritance strategy isn't an option. The tables must remain distinct. For the same reason, joined inheritance doesn't seem a good fit either.
The JPA provider is Hibernate and using things that are not part of the JPA standard isn't an issue.

If the entities don't have anything in common besides having a uuid I'd use the second approach you describe: use MappedSuperclass. Making the common superclass an entity would prevent you to use a different inheritance strategy if needed, would require a table for that super entity even if no instances exist and from a business point of view it's just wrong.
The link itself could be implemented in multiple ways, e.g. you could subclass MutationEntityLink for each entity to map (e.g. CustomerMutationEntityLink etc.) or do as you described it, i.e. only store the uuid as well as some discriminator/type information and resolve programatically (we're using that approach for something similar btw.).

You need to use #MappedSuperclass while inheriting associations/methods/properties whereas TABLE_PER_CLASS is generally used when you have entity and sub-entities. If there are entities having an association with the base class in the model, then use TABLE_PER_CLASS since the base class behaves like an entity. Otherwise, since the base class would include properties/attributes and methods which are general to such entities not related to each other, using #MappedSuperclass would be a better idea
Example1: You need to set alarms for some different activities like "take medicine", "call mom", "go to doctor" etc. The content of the alarm message does not matter, you will need a reminder. So use TABLE_PER_CLASS since alarm message, which is your base class is like an entity here.
Example2: Assume the base class AbstractDomainObject enables you to create login ID, loginName, creation/modification date for each object where no entity has an association with the base class, you will need to specify the association for the sake of clearing later, like "Company","University" etc. In this situation, using #MappedSuperclass would be better.

JPA - Retrieve all Entity Classes

I need to have a List of clasess that are Persistence Entities, I need have Entity Information, using Reflection API of JPA
I have the EntityManager, But I do not know if that is the way.
I want to do a generic logging for my Entities using a EntityListener. That works well, but I do not have the way to register the listener to all my entities.

Use the JPA2 MetaModel? It has assorted methods to see the entities (or managed types).
Set<javax.persistence.metamodel.EntityType<?>> entityTypes = entityManagerFactory.getMetamodel().getEntities();
for (javax.persistence.metamodel.EntityType entityType : entityTypes){
logger.info(entityType.getName());
logger.info(entityType.getJavaType().getCanonicalName());
logger.info("******************************");
}

Take a look at Configuration#getClassMappings()
Returns: Iterator of the entity mappings currently contained in the configuration.

Can I override generated IDs?

I'm using JPA 1, Hibernate and Oracle 10.2.0 and my entities are defined like this:
#Entity
#Table(name="TERMS")
public class Term implements Serializable {
#Id
#GenericGenerator(name = "generator", strategy = "guid", parameters = {})
#GeneratedValue(generator = "generator")
#Column(name="TERM_ID")
private String termId;
}
I have a situation where an XML representation of the Entity (and child entities) will be coming in through a web service to update/replace existing ones. My thought was to just delete the old ones and re-create it from the incoming XML.
However, doing a persist when my entities having existing IDs seem to make Hibernate very angry. So is this actually possible or is it better to avoid deleting them and just trying to do it with merge?
Angriness from hibernate:
org.hibernate.PersistentObjectException: detached entity passed to persist: com.idbs.omics.catalog.entity.Term
Thanks

My thought was to just delete the old ones and re-create it from the incoming XML. However, doing a persist when my entities having existing IDs seem to make Hibernate very angry..
Indeed, you cannot assign an Id when it is supposed to be generated, at least not with Hibernate that won't consider the entity as new but as detached (the JPA specification is a bit blurry on the exact rules in this case but that's how Hibernate behaves, see 5.1.4.5. Assigned identifiers for more hints).
So is this actually possible or is it better to avoid deleting them and just trying to do it with merge?
To make the delete/insert possible for the web service use case, you'd have to either:
not assign the id ~or~
use a special version of the entity without a generated identifier ~or~
use bulk operations(?)
The alternative if you're actually updating detached entities would be indeed to use a merge (but have a look at these previous questions just in case).
Which approach is better? I don't know, it think it depends on your needs. The later seems more natural if you're updating existing entities. With the former, you'd really get "new" entities (including a new value for the optimistic locking column). Depending on the exact implementation of the process, performances might also vary. And, by the way, what about concurrency (just to mention it, I'm not really expecting an answer)?

You can use EntityManager.merge to save an updated version of the entity. Be aware that this returns another object than the one you pass to it, because it basically fetches the entity from the database, updates the persistent properties from the object you pass and saves the persistent object.
See http://blog.xebia.com/2009/03/23/jpa-implementation-patterns-saving-detached-entities/ for more information on this problem.