Please use the google group to ask questions - thanks.

by Adun 11 Dec 15:27
enhancement field acecss interception for public fields

Hi

I recently found out about Ebean from a theserverside.com post. After reading the user guide I believe Ebean really is made by people knowledgeable about ORM and databases.

Like you, my needs don't fit in the envelope of JPA. My reasons are different however: All JPA/JDO/Hibernate work in a way that requires any machine running code that uses entities to have direct access to the database (so as for lazy loading to work, etc).

In our company, our software is not web-based but webstarted rich client (Java Swing), which means we cannot afford the luxury of having client code connecting directly to the database like web apps do. We have a layer of indirection for DB access, in which clients make requests to a service of our own, which is the one really performing database access, handling transactions and keeping track of sessions.

Because of it's remote use, this layer of indirection needed to have the proper granularity on its API. JDBC is just too chatty, so JDBC "bridges" (remote JDBC) just didn't cut it. We made it ourselves and thats how we like it. I built our own simple ORM around it, so I've walked a tiny bit of the path you have.

Anyway, after all the background, going forward to my question:

When I tried to add transparent lazy loading, I tried bytecode enhancement, ASM-subclassing, and dynamic proxies. As I remember, bytecode enhancement for field access interception had the limitation (for me) that only the field access within the entity itself was intercepted. Field access from external objects was not intercepted. Hibernate expresses this limitation as "fields have to be private". I'm not fond of the JavaBeans paradigm, and I want protected and public fields to also work safely. I ended up discarding the enhancement approach (along with the transparency of our lazy loading).

In the ebean user guide you are very clear about the details of property/field access, and state that "ORM interception occuring as and how you'd expect", however, I wonder whether you found a solution to the above issue, or rather that was not an issue for you (for example, you want fields to be private, the javabean way).

??how did you do it?

16 Dec 01:24
by Rob

Ok, I believe your question in short is:

Q: Can Ebean intercept public fields?

I believe the answer is no. More than that, I believe this would only be possible by 'enhancing' the caller (and I don't think we want to do that). Said another way, the bytecode that does the "GETFIELD" is in the caller and to intercept that (for lazy loading) you'd have to intercept that "GETFIELD" and hence enhance the caller.

As an alternative (which I think is the better approach)...

You might want to look at http://projectlombok.org/

Also note that to me this is similar to Scala properties (and groovy properties)... the Scala compiler effectively generates the getters and setters for you (scala style or java bean style).

I think we should NOT use public fields (I don't like that idea) - if we want to reduce/remove the 'noise' of the getters and setters I think we should be looking at Lombok/groovy/scala style (where the getters and setters are generated for us).

I think this is better for interception and better for other tools (EL - bean inspection/reflection based tools etc).

Does that make sense?
Did it answer your question?

Cheers, Rob.

01 Mar 17:01
by Adun

Thank you for your reply.

You are correct, the problem I faced was that for non-private fields I needed to enhance the caller, and I wondered if eBean had found a nice solution to do it.

I agree that we should NOT use public fields, however I also believe that there is a reason and a need for the existence of the "protected" access modifier. For me getters and setters are just another form of "public". I really don't like how the requirement of getters/setters for protected fields ends up polluting the APIs that those objects expose.

It seems the only way around it would be to enhcance all callers within the same package, but sadly I was unable to acheive that within a reasonable time.

02 Mar 00:32
by Rob

Ok. I didn't know you wanted it for package protection.

Hmmm. Did you not just use a protected getter/setter method?

Create a New Topic

Title:
Body:
 
Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements
woResponse