EJB3

[djeang]

I'm looking at EJB 3 draft spec. It seem that this model has many common elements with Spring. So i'd like to have your though about expanding Spring and Hibernate to support EJB 3 spec. How difficult it'll be and if it is a coherent approch.

thanks.

[Rod Johnson]

As far as session beans are concerned, EJB3 introduces Dependency Injection features that are a small subset of those offered by Spring. We could support this style of DI very easily as an additional option (and may well do), but as Spring already does a lot more wrt IoC I'm not convinced that it would provide a lot of value. Support for EJB3 style DI could be added without changing the Spring core, due to our flexible architecture. The EJB spec is still undergoing change--we've only seen an "early release draft" and no binaries have been released yet, so there's nothing to build against.

As far as the EJB3 POJO persistence model is concerned, this will end up separated from EJB3 as a distinct deliverable in JSR-220. Spring will fully support integration with this persistence API as soon as it is stable.

Note that Spring will not become EJB3 compliant, even if we choose to support certain features. Compliance would require support for both EJB 1.x and 2.x APIs--regardless of the fact that most users will never want to go near that stuff once EJB3 ships.

[cepage]

We could support this style of DI very easily as an additional option (and may well do), but as Spring already does a lot more wrt IoC I'm not convinced that it would provide a lot of value.

I would very much enjoy having the option of doing something like:

@inject MyService _myService;

instead of:

private MyService _myService;

public void setMyService( MyService myService )
{
   // This public method exists for no other purpose than to hook into Spring
   _myService = myService;
}

Although a little more controversial, I would even like an optional annotation that specifies an autowiring strategy. In simple scenarios, this could completely replace the declaration in applicationContext.xml

[Rod Johnson]

I would very much enjoy having the option of doing something like:

@inject MyService _myService;

instead of:

private MyService _myService;

public void setMyService( MyService myService )
{
   // This public method exists for no other purpose than to hook into Spring
   _myService = myService;
}

The main issue I have with the first version (which presumably applies to a field) is that sure, you've reduced the amount of code, but you now can't test that class easily without a container. So it's one step forward and two steps backwards. An IDE can easily generate the getter.

Nevertheless, we could support this easily enough and would consider it if enough people ask for it. I doubt I would recommend it though.

Although a little more controversial, I would even like an optional annotation that specifies an autowiring strategy. In simple scenarios, this could completely replace the declaration in applicationContext.xml

I think this is a good idea. There are, however, two problems:

- J2SE 5.0 isn't likely to be commonly used for quite a while. We could consider adding Commons Attributes support in the meantime, however. I'd be interested to get more reactions on that.

- AFAIK J2SE 5.0 annotations do not allow indexing (unlike Commons Attributes). This it could be very expensive to work out which classes have annotations. It would be great to have a way around that without a special step in the build process.

Certainly there are a number of ways in which annotations can help to simplify config, and we're open to exploring them as annotations come into common use.

[cepage]

The main issue I have with the first version (which presumably applies to a field) is that sure, you've reduced the amount of code, but you now can't test that class easily without a container. So it's one step forward and two steps backwards. An IDE can easily generate the getter.

Certainly, my beloved IntelliJ generates the setters easily, and the effort is not the issue for me. I just prefer to reduce the code size and eliminated unneeded mutators, when it is appropriate.

Funny thing about Spring, as I use it I keep generating lots of elegant but small classes. While TDD-zealots may disapprove, I usually don't write unit tests for classes that I consider extremely simple. It is for these classes that I would enjoy the option of the annotated injection, because I only test them with (in-container) integration tests.

Certainly there are a number of ways in which annotations can help to simplify config, and we're open to exploring them as annotations come into common use.

Maybe there could be a separate experimental .jar for some of these annotations. You wouldn't have to support pre-5.0 users, only the people who are really interested would mess around with them, and you would have the option of dropping annotations you don't like in future releases.

Thanks,
Corby

[Rod Johnson]

Corby

Maybe there could be a separate experimental .jar for some of these annotations. You wouldn't have to support pre-5.0 users, only the people who are really interested would mess around with them, and you would have the option of dropping annotations you don't like in future releases.

This is a good idea. We'll consider it. It would help to get feedback. We'll be releasing a transaction annotations JAR very soon. The work is pretty much done.

Rgds
Rod

[ihaveican]

I think field injection is a good idea, it reduce many lines, and it explicit indicates that this field is a IOC field,
And it can be test out the container,you can simply make this field public, or can use a simple util to set the IOC fields(use java reflect).

[Chris Lee]

Recently posted a proposal for annotation indexing here

http://forum.springframework.org/showthread.php?t=23991

[Rod Johnson]

I think field injection is a good idea, it reduce many lines, and it explicit indicates that this field is a IOC field,

Which kinda defeats the purpose of IoC, one goal of which is to enable you to write code fairly naturally (with constructors and/or setters) and have them configured inside or outside a container.

And it can be test out the container,you can simply make this field public, or can use a simple util to set the IOC fields(use java reflect).

The first approach (making them public) is inelegant IMO. Setter methods offer the ability to validate and otherwise add value. Constructors have the benefit of validation. The second approach (reflective set) loses type safety.

We will be supporting the JSR-250 API, with @Resource and other DI annotations in an add-on project to Spring. As it relates to a small subset of what Spring can do, it's relatively easy. This project will be released before Java One. Nevertheless, we don't regard the use of field injection or most of these annotations as best practice.