We Keep Coding

(Java/Spring) Accessing class elements using entityType.getJavaType()

I created a generic Spring Entiy-Class "TableWithId" which is intended to be inherited by other classes.
Here a snipped from the base class:
#Entity
#Inheritance(strategy = InheritanceType.JOINED)
#Table(name = "__base_table")
public class TableWithId {
public static String EntityLabel = "All data";
#Id
#GeneratedValue
protected Long id;
So in my subclasses I am implementing further fields etc. This works very well, It creates, fills and lists content as expected ...
Now I want to be able to get a list of all my entities. This works fine with, well at least to get the names and class-names.
entityManager.getMetamodel().getEntities()
Based on the entity name I can also load entities based on user parameters:
entityManager.createQuery("Select t from " + entityName + " t").getResultList();
Now there are two things I cannot do:
(1) Access static java properties of my classes, I actually want to access "public static String EntityLabel" at runtime using the java-class returned by "entityType.getJavaType()". In fact I'd like to do something like this:
((TableWithId) entityType.getJavaType()).EntityLabel
(2) For security reasons I also like protecting the system by not allowing the user to make queries on other entities which do not inherit from TableWithId. I'd like to do something like:
entityType.getJavaType() instanceof TableWithId
Any help is appreciated :)

getJavaType gives you a class instance. you could access a static field via reflection:
entityType.getJavaType().getField("EntityLabel").get(null)
if you want to test if a class is the same as another of its superclass or superinterface you should use isAssignableFrom:
Class.forName("xxxx.TableWithId").isAssignableFrom(entityType.getJavaType())

Thx to pero_hero I figured it out, except classpath...
Here my complete solution ...
public class EntityInfo {
public Class myclass;
public String label;
public Hashtable<String, Action> actions;
public String name;
public EntityInfo(String name) {
this.name = name;
try {
this.myclass = Class.forName(name);
this.label = (String) this.myclass.getField("EntityLabel").get(null);
this.actions = (Hashtable<String, Action>) this.myclass.getMethod("getActions").invoke(null);
} catch (Exception e) {
e.printStackTrace();
}
}
}

How to extend object with no setters to obtain superclass state

I am extending a class to store some extra fields that I need to my application, but the class I am extending has no setter methods, and just a default constructor.
http://restfb.com/javadoc/com/restfb/types/Post.html#Post()
I am using a framework that requires the getters to be in a correct naming format as the fields in the type. However, as I cannot set the fields from the constructor, or from setters, I have kept a local copy of the initial object that I wish to store in my new object.
I then have overridden the methods to pull the data from the initial object as follows:
#Override
public String getMessage() {
return initialPost.getMessage();
}
This does not seem like a good way to do things, one annoying reason being that I would have to override every method if I wish to use all fields.
What is the best way to solve this issue? Would this be a use case for composition over inheritance?
I think I may have tried to combine both here, which seems incorrect!
public class MyPost extends Post{
private String postId;
private Post initialPost;
private PostType type;
private Brand brand;
private Product product;
private List<Photo.Image> postImages;
Thanks for all advice.

You indeed combined both composition and inheritance; which is a pretty confusing situation. I would go with inheritance since you are extending the behaviour of an object with a more specific purpose to just that object.
This also solves your problem because a public method from the Post class is also available as a public method from its subclasses (and as such, the framework can happily use getMessage() without you having to redefine it).
From my comment below:
Post is essentially an immutable object so it is not intended to be constructed by you. You could override the methods from Post in MyPost and add your own getters/setters, but you should reflect whether or not this is an approach you want to take.
An example of how you would implement this:
class Post {
private String body;
public String getBody() {
return body;
}
}
class MyPost extends Post {
private String body;
public void setBody(String body) {
this.body = body;
}
#Override
public String getBody() {
return body;
}
}
Now the getBody() method from the Post class is overridden by the selfdefined one from MyPost.

Usage of generics in Morphia

Although I tagged this question as a Morphia issue, I think it's more general, but anyway, help is appreciated.
I have IUser interface that I don't have control over it:
public interface IUser<T> {
...
public String getFirstName();
...
}
I, also, have an implementation User (Morphia entity) of this interface:
#Entity
public class User implements IUser<ObjectId> {
#Id
private ObjectId id;
#Property
private String firstName;
public String getFirstName() {
return this.firstName;
}
...
}
When Morphia asks for the classes to be mapped, I provide User.class, since this is the Morphia entity. Therefore, when I extend the BasicDAO, I provide User and ObjectId as types:
public class UserDAO extends MongoDAO<User, ObjectId> {
public List<IUser<ObjectId>> getUsers(String id) {
return ds.find(IUser.class, Mapper.ID_KEY, new ObjectId(id)).asList();
}
}
Now, the problem appears in the getUsers method. As you can see, I want to continue working with the interface outside this class; that's why I expect List<IUser<ObjectId>> as a return type.
The first argument of the ds.find(...) method is a Class<T> type, so I provide IUser.class. But, because of this, I cannot anymore expect List<IUser<ObjectId>> as a result, but just List<IUser>. This way, I have lost the type of IUser. Is it possible at all to force this Morphia's method to return a list of parameterized IUser objects?
Thank you in advance,
Zlatko

There are a couple of options.
What Guava, Guice and similar libraries do is accept a TypeToken which leverages an anonymous inner class to reify the types. It would look something like this:
return ds.find(new TypeToken<IUser<ObjectId>>(){}, ...);
But obviously that's not really an option here since you can't change the library. It is what I'd consider to be the correct solution however.
The second option is to just cast the class to contain the generic parameter. This results in an unchecked warning however that needs to be suppressed or ignored:
#SuppressWarnings({"unchecked"})
Class<IUser<ObjectId>> userClass = (Class<IUser<ObjectId>>) (Object) IUser.class;
return ds.find(userClass, ...);
Edit:
It should really be noted that the suggestion above is really no better than just casting the entire list from a List<IUser> to a List<IUser<ObjectID>> before returning it. Both carry the same need to suppress warnings.

Can I use jackson mixIns to modify "getters" behavior?

I'm in the need of do some clean up of some invisible characters (\r\n) and html tags for specific getters on my entities.
I've been trying to use mixIns to modify what's returned from the entity but I'm not sure how can I reference the target class in my MixIn so I can add the clean up logic there. From the my tests seems that not even my method is called.
This is what I have so far, but it never gets called
public abstract class BookMixIn {
#JsonProperty
public String getTitle() {
return StringUtils.deleteWhitespace(getTitle());
}
}
public class Book {
private String title;
// getter/setters omitted...
}
And the ObjectMapper config:
mapper.getSerializationConfig().addMixInAnnotations(com.company.Book.class,
com.company.BookMixIn.class);
mapper.configure(SerializationConfig.Feature.FAIL_ON_EMPTY_BEANS, false);
String tmp = mapper.writeValueAsString(book);
log.info(tmp);
Can this be accomplished via MixIns?
Thanks

Jackson mix-ins are purely for associating annotations; they are not used for adding behavior (code).
So they would not help you here.
But the simple way that would work (possibly using mix-in too) is to add annotation for using custom serializer, which can use whatever filtering is needed:
#JsonSerialize(using=MyCoolSerializer.class) public String getTitle() { }
so either add that to POJO, if possible; but if not, associate it using mix-in.

If you are running Jackson 1.9, this works:
BookCleaner cleanBook = new BookCleaner(book);
mapper.getSerializationConfig().addMixInAnnotations(Book.class, BookMixIn.class);
mapper.writeValueAsString(cleanBook);
#JsonSerialize
class BookCleaner {
private Book book;
public BookCleaner(final Book book) { this.book = book; }
#JsonUnwrapped
public Book getBook() { return book; }
#JsonProperty("title")
public String getCleanTitle() { return cleanup(getBook().getTitle()); }
}
public interface BookMixIn {
#JsonIgnore public String getTitle();
}

I don't think it works like this; the class or interface is just used as a signature.
You could use AspectJ to modify the return value, but it might be easier to just create a decorator and serialize that instead of the underlying object.
Alternatively, you could create specific getters for the "safe" versions of things and use the #JsonProperty annotation to give it the name you need, and use #JsonIgnore on the "non-safe" getters.

Does the code-to-interface principle apply to entity classes?

I'm trying to follow code-to-interface on a project. Should I be creating an interface first then implementing that interface for entity classes? I'm thinking this might be taking the interface first approach too far and entities should be ignored. This is what I mean...
public interface Address {
public String getStreet();
public void setStreet(String street);
}
#Entity
public class AddressImpl implements Address {
private String street;
public String getStreet(){
return this.street;
}
public void setStreet(String street){
this.street = street;
}
}
#Entity
public class OfficeImpl /* implements Office */ {
private Address location;
public Address getLocation(){
return this.location;
}
public void setLocation(Address location){
this.location = location;
}
}
public class Driver {
public static void main(String[] args) {
Office work = new OfficeImpl();
Address workAddress = new AddressImpl();
workAddress.setStreet("Main St.");
work.setLocation(workAddress);
}
}

I think creating Interfaces for Entities is probably not necessary.
The purpose of creating Interfaces (or at least, one of the purposes) is to make it easier to swap out one concrete implementation in favour of another. This is obviously a good thing for your DAOs, Business Logic etc.
But unless you have plans for the implementation of your entities to change as well, I would avoid it!

In your example, you are probably taking it too far, but once you add methods, write test cases and possibly use dependency injection, it will make more sense.
For simple projects like this, it is overkill, but once you get into a 'real' application, then it is often a good idea. Just be careful not to overdo it, everything doesn't need to implement an interface, just where it makes sense.

the interface for Entities should be the behaviors and properties that are common to all Entities!
public interface IEntity
{
int EntityId { get; set; }
bool FindById(int id);
bool Create(object [] values);
bool Delete(int id);
//etc.
}
sorry for the C# example, but the language doesn't matter. Interfaces are for 'plug compatability'.

I think when you're talking about entities, it's probably overkill.
Interfaces are useful when you're working with entities that have a common usage, but aren't necessarily the same. Can't think of a good way to explain it, but here's an example:
interface IFlaggable {
bool IsFlagged ...
string Reason ...
}
class ForumPost implements IFlaggable { }
class PrivateMessage implements IFlaggable { }
Hope that helps!

I generally don't make interfaces for data holding beans, that is I don't make interfaces for classes with primitive type values and getters/setters for them. Haven't really ever hit a moment where I would've needed interfaces for anything I usually use them for (polymorphism and mocking, mostly) so I haven't bothered doing that.
I guess I should point out that most of the time when I use databeans I also reflect the values from those same objects with custom classes which work like this:
Reflector r = new Reflector(new DataBean( [ values given through constructor ] ));
long someNumber = r.get("method", Long.class);