Using constructor injection with JPA entities

[cowwoc]

Hi,

I am curious whether it conceivably possible for JPA 2.0 to add support for constructor injection for such things as read-only entities. I'm not a fan of the JavaBean design pattern and I'm wondering whether it would be possible to move EclipseLink and JPA closer to the Guice way of doing things. For example:

class Foo
{
  public Foo(@Named("username") String username, @Named("password") String password)
  {}

  // mapping annotations go on getters
  public String getUsername() {}
  public String getPassword() {}

  // no setters
}

It would be even better if you could pick up the property names directly from the variable name but I believe there are technical problems with that approach.

Thank you,
Gili

[James Sutherland]

JPA 1.0 supports field access, so you do not need set methods if you use field access, which is normally the better way to go anyway.

cowwoc wrote:

Hi,

I am curious whether it conceivably possible for JPA 2.0 to add support for constructor injection for such things as read-only entities. I'm not a fan of the JavaBean design pattern and I'm wondering whether it would be possible to move EclipseLink and JPA closer to the Guice way of doing things. For example:

class Foo
{
  public Foo(@Named("username") String username, @Named("password") String password)
  {}

  // mapping annotations go on getters
  public String getUsername() {}
  public String getPassword() {}

  // no setters
}

It would be even better if you could pick up the property names directly from the variable name but I believe there are technical problems with that approach.

Thank you,
Gili

[cowwoc]

But you cannot use constructor injection in JPA 1.0, it still forces you to provide a default constructor.

Gili


JPA 1.0 supports field access, so you do not need set methods if you use field access, which is normally the better way to go anyway.

cowwoc wrote:

Hi,

I am curious whether it conceivably possible for JPA 2.0 to add support for constructor injection for such things as read-only entities. I'm not a fan of the JavaBean design pattern and I'm wondering whether it would be possible to move EclipseLink and JPA closer to the Guice way of doing things. For example:

class Foo
{
  public Foo(@Named("username") String username, @Named("password") String password)
  {}

  // mapping annotations go on getters
  public String getUsername() {}
  public String getPassword() {}

  // no setters
}

It would be even better if you could pick up the property names directly from the variable name but I believe there are technical problems with that approach.

Thank you,
Gili

[James Sutherland]

I think that the default constructor you provide JPA can be marked private, so would be ok.  If a private constructor does not work in EclipseLink, please log a bug.  EclipseLink also has support for an InstantiationPolicy that can use a private static method, or factory.


But you cannot use constructor injection in JPA 1.0, it still forces you to provide a default constructor.

Gili

James Sutherland wrote:

JPA 1.0 supports field access, so you do not need set methods if you use field access, which is normally the better way to go anyway.

cowwoc wrote:

Hi,

I am curious whether it conceivably possible for JPA 2.0 to add support for constructor injection for such things as read-only entities. I'm not a fan of the JavaBean design pattern and I'm wondering whether it would be possible to move EclipseLink and JPA closer to the Guice way of doing things. For example:

class Foo
{
  public Foo(@Named("username") String username, @Named("password") String password)
  {}

  // mapping annotations go on getters
  public String getUsername() {}
  public String getPassword() {}

  // no setters
}

It would be even better if you could pick up the property names directly from the variable name but I believe there are technical problems with that approach.

Thank you,
Gili

[cowwoc]

I am more concerned about JPA (all implementations) than just EclipseLink in this case. In either case, I don't think that a private constructor can be used because CGLIB proxies need to know what superclass constructor to invoke. It is my understanding that all JPA 1.0 implementations (including EclipseLink) require a protected default constructor for this reason.

It is also worth nothing that one of the reasons I want constructor-based injection is so I can centralize all my validation code in a single method. If you use the default constructor and inject values directly into the fields it essentially defeats the point.

We need *real* constructor injection.

The way I would implement it is:

1) Generate a list of all persistent fields (basically anything not marked using @Transient)
2) Either inject the fields using the JPA 1.0 approach (default constructor and setter methods), or
3) Inject the fields using constructor injection. Match the field value to the constructor parameter either by its type or using @Named.

I'm wondering if this is technically doable. I've already thought of the following potential problem:

EntityManager.refresh(Object) does not return an object. Technically speaking this shouldn't be a problem because refresh(immutable) should be a no-op but if someone *does* modify the database directly then this method would need to throw an exception indicating that a change has occurred but cannot be applied because the object is marked as immutable. Alternatively, you could add refresh() that returns a new Object.

Gili


I think that the default constructor you provide JPA can be marked private, so would be ok.  If a private constructor does not work in EclipseLink, please log a bug.  EclipseLink also has support for an InstantiationPolicy that can use a private static method, or factory.


But you cannot use constructor injection in JPA 1.0, it still forces you to provide a default constructor.

Gili

James Sutherland wrote:

JPA 1.0 supports field access, so you do not need set methods if you use field access, which is normally the better way to go anyway.

cowwoc wrote:

Hi,

I am curious whether it conceivably possible for JPA 2.0 to add support for constructor injection for such things as read-only entities. I'm not a fan of the JavaBean design pattern and I'm wondering whether it would be possible to move EclipseLink and JPA closer to the Guice way of doing things. For example:

class Foo
{
  public Foo(@Named("username") String username, @Named("password") String password)
  {}

  // mapping annotations go on getters
  public String getUsername() {}
  public String getPassword() {}

  // no setters
}

It would be even better if you could pick up the property names directly from the variable name but I believe there are technical problems with that approach.

Thank you,
Gili

[cowwoc]

Hi,

As a follow-up to my previous post I have run across "O/R Broker" that does exactly what I am looking for. It allows one to query and persist non-JavaBeans objects. Please see http://orbroker.sourceforge.net/ and http://orbroker.sourceforge.net/documentation/user-guide.shtml

This project has been dead for a few years now but I don't see anything stopping us from applying the same techniques in JPA. If I understand correctly, all we'd need to do is mark up constructor parameters using @Column to indicate what database column should go into each parameter. This seems simple enough. What do you think?

Gili

cowwoc wrote:

Hi,

I am curious whether it conceivably possible for JPA 2.0 to add support for constructor injection for such things as read-only entities. I'm not a fan of the JavaBean design pattern and I'm wondering whether it would be possible to move EclipseLink and JPA closer to the Guice way of doing things. For example:

class Foo
{
  public Foo(@Named("username") String username, @Named("password") String password)
  {}

  // mapping annotations go on getters
  public String getUsername() {}
  public String getPassword() {}

  // no setters
}

It would be even better if you could pick up the property names directly from the variable name but I believe there are technical problems with that approach.

Thank you,
Gili

[tware]

Hi Gili,

   I took a quick look.  'looks like it would be an interesting contribution if
someone wanted to contribute code to support this type of functionality.

-Tom

cowwoc wrote:

> Hi,
>
> As a follow-up to my previous post I have run across "O/R Broker" that does
> exactly what I am looking for. It allows one to query and persist
> non-JavaBeans objects. Please see http://orbroker.sourceforge.net/ and
> http://orbroker.sourceforge.net/documentation/user-guide.shtml
>
> This project has been dead for a few years now but I don't see anything
> stopping us from applying the same techniques in JPA. If I understand
> correctly, all we'd need to do is mark up constructor parameters using
> @Column to indicate what database column should go into each parameter. This
> seems simple enough. What do you think?
>
> Gili
>
>
> cowwoc wrote:
>> Hi,
>>
>> I am curious whether it conceivably possible for JPA 2.0 to add support
>> for constructor injection for such things as read-only entities. I'm not a
>> fan of the JavaBean design pattern and I'm wondering whether it would be
>> possible to move EclipseLink and JPA closer to the Guice way of doing
>> things. For example:
>>
>> class Foo
>> {
>>   public Foo(@Named("username") String username, @Named("password") String
>> password)
>>   {}
>>
>>   // mapping annotations go on getters
>>   public String getUsername() {}
>>   public String getPassword() {}
>>
>>   // no setters
>> }
>>
>> It would be even better if you could pick up the property names directly
>> from the variable name but I believe there are technical problems with
>> that approach.
>>
>> Thank you,
>> Gili
>>
>

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users