Opinion: Injection in EJB going too far?

Discussions

News: Opinion: Injection in EJB going too far?

  1. Opinion: Injection in EJB going too far? (40 messages)

    Brian Repko posted a PDF of his concerns about the use of injection in EJB 3. Among the points he brings up: resource deallocation, changes to the objects being injected (as the changes wouldn't be propagated to the resources unless they were "re-injected"), what happens when an injection doesn't happen, and backward compatibility with dependency lookups.
    In the end, I find the proposed change in the EJB3 draft specification neither aesthetically pleasing nor
    technologically pleasing. I feel that adding dependency injection solves no problem that can’t be solved more easily, and it potentially introduces new problems.
    Brian points out that a JNDI Context can easily be mocked to handle out-of-container testing in EJBs, but this seems to be one of the prime movers behind the push for dependency injection. Plus, his concerns about the EJB lifecycle seem valid: an injected JDBC connection couldn't be reallocated to a different component by the container, raising the spectre of running out of managed connections if a large number of EJBs were present.

    What do you think?

    Threaded Messages (40)

  2. Injection per invocation ?[ Go to top ]

    I've not read the spec in detail, but could the container inject on a per ejb method invocation ? That way it knows when to deallocate this such as jdbc connections, naming contexts etc.
  3. Injection per invocation ?[ Go to top ]

    I've not read the spec in detail, but could the container inject on a per ejb method invocation ? That way it knows when to deallocate this such as jdbc connections, naming contexts etc.

    Interesting question. I don't know, myself - but even then, you end up with long-lived allocations (moreso than you would have with dependency lookups) and you would also potentially have allocations that aren't necessary - imagine a case where an EJB looks up resources on a datasource and, if they match a given criteria, submit them to a JMS queue.

    If there isn't any matching data, the JMS queue wouldn't be necessary at all. Yet it'd still have been acquired, which can have implications for system resources. Does the JMS queue connection use sockets? File handles? DB handles? Yes... or no. The whole point is that the JMS client doesn't necessarily know.

    I think the point's certainly worth raising.
  4. Injection per invocation ?[ Go to top ]

    This is definitely an interesting question. Could somebody answer that. Since DI happens prior to ejbCreate(), it adds a deployement dependency on the EJBs. Although, it's easy to handle that in the configuration file in the container, it's still an aesthetic issue.
  5. I think the author of the white paper is complaining about implementation issues.

    The actual lifecycle of the dependencies will be managed by the container. Container A may not support live configuration of dependencies, but container B may. This should NOT be forced in the spec.

    As a Bean Provider you should not care about this. And it make you code a lot more business oriented (rather than framework oriented). If service A depends on service B, then service B should be always availlable and if it's not, then it's a system/runtime exception. Why would you actually care about catching this error at the Enterprise Bean level.

    Resource allocation an management can be easily done by the container. It can just provide proxies to the actual resource so the resource is not actually create/allocated unless it is used (this is already used by most lightweight container implementations). The same mechanism can provide live configuration changes.

    As for resource deallocation... Again this is the container business... It can be easily done in at the end of the invocation lifecycle.

    DI does make it easier to concentrate only on business logic and have less dependency on the framwork. Granted, for some kind of resources, DL may be better. But the mechanism for DL are still in place in the spec.

    Just like the 2.1 spec does not requires to use the specified mechanism for DL, the 3.0 spec does not requires you to use DI. But for at least 80% of the code outhere, DI will make the code a lot more easier to read and less dependent on the framework (you code will not depend on framework specific APIs).
  6. I think the author of the white paper is complaining about implementation issues.The actual lifecycle of the dependencies will be managed by the container. Container A may not support live configuration of dependencies, but container B may. This should NOT be forced in the spec.As a Bean Provider you should not care about this. And it make you code a lot more business oriented (rather than framework oriented). If service A depends on service B, then service B should be always availlable and if it's not, then it's a system/runtime exception. Why would you actually care about catching this error at the Enterprise Bean level.Resource allocation an management can be easily done by the container. It can just provide proxies to the actual resource so the resource is not actually create/allocated unless it is used (this is already used by most lightweight container implementations). The same mechanism can provide live configuration changes.As for resource deallocation... Again this is the container business... It can be easily done in at the end of the invocation lifecycle.DI does make it easier to concentrate only on business logic and have less dependency on the framwork. Granted, for some kind of resources, DL may be better. But the mechanism for DL are still in place in the spec.Just like the 2.1 spec does not requires to use the specified mechanism for DL, the 3.0 spec does not requires you to use DI. But for at least 80% of the code outhere, DI will make the code a lot more easier to read and less dependent on the framework (you code will not depend on framework specific APIs).

    I think Emmanuel said it all. It boils down to the implementation of the vendor and how they manage dependencies.
  7. I think Emmanuel said it all. It boils down to the implementation of the vendor and how they manage dependencies.

    Yeah this is the crux of it. There are plenty of smart ways to make this pattern work, respecting expensive resources.

    For instance, the container could inject the dependency but these could just be proxies that lazily obtain the resource.
  8. I think maybe the first and fourth issue might be possibly a container issue but the other issues are definitely issues that should be covered in the spec. This article in my opinion has brought up some valid concerns with ejb3. Accessing ejbs remotely from java clients running outside the container needs to be addressed. I'd prefer to have these resolved by the spec instead of having to be tied into one container’s implementation.
  9. Injection per invocation ?[ Go to top ]

    I havent read the spec as yet. Can't there be annotations for each method listing out the resources it needs. The resources could be allocated before the method executes and deallocted after the completion of execution of that method.

    I dont know how top make sure that the method does use "only" the resources specified in the annotations and not others.


    Does this make sense :) or it is completely useless :( . What do experts feel.
  10. I don't think the arguments in the PDF hold water. So far as I can tell from reading the Draft 2 spec, injection is functionally to a JNDI lookup at the beginning of the method (section 8.1.2). The following two code snippets would be functionally equivalent:

    // Injection syntax
    @Inject public DataSource ds;
    public void doSomething() {
        // Use this.ds;
    }

    // JNDI syntax
    public DataSource ds;
    public void doSomething() {
        Context ctx = new InitialContext();
        this.ds = (DataSource) ctx.lookup("java/comp:env/…")
        // Use this.ds;
    }

    Granted, the JNDI lookup does need to assign the value to an instance variable, but it *could* if it wanted to. Therefore, the arguments that "the container can't manage long held references" simply are not true, because resources retrieved via JNDI can be held equally long. The EJB containers will use the same resource management techniques they always have whether resources are retrieve via JNDI lookup or injection.

    The only case I can think of where JNDI lookup is superior is when the EJB that needs to conditionally use a given resource. You can always fall back to JNDI in that case, or use the new EJBContext.lookup() method.

    Personally, I would say that an EJB using multiple resources would be better off split into two multiple EJB, such as a "database lookup" EJB that conditionally uses a "messaging" EJB. In that case, injection should be just as effective as JNDI lookup, and much easier to test.
  11. The specification only guarantees that injection occurs after the context has been set and before the first business method has been invoked. Injection is a one time operation for the life of the bean.

    The author of the paper is concerned that injected references will unnecessarily hold onto server resources. As Bill mentioned, this is an implementation detail, but in practice you are injecting factories and proxies, not active resources.

    The one area of concern for dependency injection in EJB 3 that I do think is valid is the notion of injecting a stateful session bean instance into anything other than a stateful session bean. Like a mail session, it just isn't the type of resource that is injection friendly. Lookups via the context are still going to be used in these situations.

    In practice, the dependency injection mechanism outlined in the specification works quite well. There is plenty of prior art in this area and the problem is well understood. But, like everything else, there is more than one way to do it, and developers uncomfortable with dependency injection are free to ignore it and use context lookups instead.

    Merrick
  12. Hitting the Nail on the Head[ Go to top ]

    The referenced article, EJB New Life found at http://today.java.net/today/2004/08/05/ejbnewlife.pdf, nicely summarizes my opinions on EJB3:
    The EJB 3.0 model, with the stated aim of reducing complexity, is nevertheless introducing a learning curve of its own by requiring developers to learn basic annotation grammar and a large annotation vocabulary, along with concepts such as dependency injection, detached entities, a more complex entity bean lifecycle, the new notion of “persistence context”, and others before they can start developing applications.

    I learned from some wise programming sage that it was better to fix what's broken, and then add new features.

    Of course, obsoleting all the existing knowledge about enterprise application development has it's advantages - for the vendors & sellers of services (oh, I forgot it's going to be backwards compatible, too).

    When can we expect a stable EJB3 product?
  13. Hitting the Nail on the Head[ Go to top ]

    The EJB 3.0 model, with the stated aim of reducing complexity, is nevertheless introducing a learning curve of its own by requiring developers to learn basic annotation grammar and a large annotation vocabulary, along with concepts such as dependency injection, detached entities, a more complex entity bean lifecycle, the new notion of persistence context, and others before they can start developing applications.

    This comment is really bizarre. Annotation grammar is part of J2SE and many other components. It is a new feature of the language that is being used by components and systems across the board, not just EJB 3. I would say that anybody that doesn't want to learn annotations is going to be left behind in the Java world regardless of whether they ever use or have even heard of EJB.

    EJB 3 users asked for dependency injection because they already knew it and liked it. Much as we would like to, the EJB group cannot take credit for inventing it :-) but anybody that has not used it can continue to use the JNDI apporach and not even try to understand it. I would recommend that if somebody does not know it that they learn it, though. A LOT of people are testifying that it helped them write software better.

    The concept of detachment and a persistence context is not new either. These things always existed before EJB 3, it is just that EJB 3 is standardizing them. People have had to deal with detachment from the beginning of tiered development. EJB 3 is just naming it and calling it out. Every customer that uses TopLink, Hibernate or any other mapping product has some notion of the persistence context or session. We could have called it a session as TopLink and Hibernate do, but that is already way too overloaded I think.
     
    I learned from some wise programming sage that it was better to fix what's broken, and then add new features.

    I think that most people agree that EJB 2 was broken. It had to be fixed. I agree that new features are not required, though, to get it out. The problem is that then some people say that it doesn't have enough features compared to this or that. I guess you can't please everybody all the time...
    When can we expect a stable EJB3 product?

    Have you tried the previews? There are already two of them, one from Oracle and one from JBoss. Try them out and see if you don't think they offer stable preview functionality (even before the spec is final).

    -Mike
  14. Hitting the Nail on the Head[ Go to top ]

    Yes, EJB3 is probably a golden opportunity for Oracle to gain market share from BEA and IBM.
  15. Hitting the Nail on the Head[ Go to top ]

    <br>
    Yes, EJB3 is probably a golden opportunity for your company (Oracle) to gain market share from BEA and IBM.
    <br>
  16. For people who don't want to abuse every new idea/new design pattern, there is an article by Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern
  17. Mr Repko:
    I think that the interface described in [New Life] or here is a cleaner API (no need
    for casting, more readable code, define the method parameters per resource type).

    Could anyone deny that this is safer and more maintainable than EJB-3? I mean, come on. Mr Repko can eliminate downcasting and allow custom signatures!
  18. I think that the interface described in [New Life] or here is a cleaner API (no need for casting, more readable code, define the method parameters per resource type).

    Could anyone deny that this is safer and more maintainable than EJB-3? I mean, come on. Mr Repko can eliminate downcasting and allow custom signatures!

    I think that the factory-method approach in [New Life] is seriously flawed for the EJB specification. You end up with an unending list of new methods for different resources:

    getDataSource()
    getTimer()
    getJMSSession()
    getQueue()
    [50 more methods follow]

    If these kinds of factories were added to the EJB standard, it would be tightly couple to a dozen other J2EE standards. Suppose that in the future JMS queues were reorganized to use a different interface. We would need to maintain factory methods for both the old and new queue types in the EJB factory methods:

    getQueue() // The old queue
    getQueue2() // The new queue

    As I see it, point of JNDI is that it keeps the different J2EE APIs independent of one another. EJBs are able to retrieve resources without being constrained as to what those resources are (the available resources are left as an implementation detail). Injection has the same freedom as JNDI, but eliminates the need for typecasting (albeit with some loss of control in terms of resource lifecycle management).

    Beside, it is easy enough to write your own New-Life-Style ResourceManager classes that use JNDI under the covers. The following would work just fine in EJB 2.x or 3.0:

    public class ResourceManager {
        private static final DB_JNDI = "java:comp/env/mydatasouce";
        public static DataSource getDataSource() {
            Context ctx = new InitialContext();
            return (DataSource) ctx.lookup(DB_NAME);
        }
    }
    // Error handling omitted for brevity
    // Usage: ResourceManager.getDataSource();
    // Add other factory methods as needed

    Since this kind of factory classes so simple to implement, I see no reason to add them to the spec.
  19. I think that the factory-method approach in [New Life] is seriously flawed for the EJB specification. You end up with an unending list of new methods for different resources:getDataSource()getTimer()getJMSSession()getQueue()[50 more methods follow]If these kinds of factories were added to the EJB standard, it would be tightly couple to a dozen other J2EE standards. Suppose that in the future JMS queues were reorganized to use a different interface. We would need to maintain factory methods for both the old and new queue types in the EJB factory methods:getQueue() // The old queuegetQueue2() // The new queueAs I see it, point of JNDI is that it keeps the different J2EE APIs independent of one another. EJBs are able to retrieve resources without being constrained as to what those resources are (the available resources are left as an implementation detail). Injection has the same freedom as JNDI, but eliminates the need for typecasting (albeit with some loss of control in terms of resource lifecycle management).Beside, it is easy enough to write your own New-Life-Style ResourceManager classes that use JNDI under the covers. The following would work just fine in EJB 2.x or 3.0:public class ResourceManager {&nbsp;&nbsp;&nbsp;&nbsp;private static final DB_JNDI = "java:comp/env/mydatasouce";&nbsp;&nbsp;&nbsp;&nbsp;public static DataSource getDataSource() {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Context ctx = new InitialContext();&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return (DataSource) ctx.lookup(DB_NAME);&nbsp;&nbsp;&nbsp;&nbsp;}}// Error handling omitted for brevity// Usage: ResourceManager.getDataSource();// Add other factory methods as neededSince this kind of factory classes so simple to implement, I see no reason to add them to the spec.

    DI is a double-edged sword. In our model, the container explicitly implements a contract with the application: "Here is the list of resources I have to offer. Make sure you stick to it."

    In the DI model, the first time you may get to know that a resource (that you expect to be injected) is not supported by the container (possibly because of the usage of an older container) will be when you run your code. The application will probably throw a NullPointerException at some strange location, leaving you scratching your head wondering what went wrong.
     
    No doubt you can write the factory methods yourself, but why should you do it? Let the container do it for you. In order for your code to stay portable, the factory methods must be included in the spec. Our model uses a uniform approach to get resources, services and entities via a consistent set of factory methods. The usage of these factory methods makes sure that ALL containers explicitly state what they support.

    Ganesh Prasad (on behalf of Rajat Taneja)
  20. I agree with some of the other posters that most if not all of the issues raised are implementation specific issues. Particularly, I want to point out that the dependency reference can be easily swapped out for a new one without even the component knowing about it. A simple proxy can take the place of the dependency reference and pass through messages to the actual component. Now you can dynamically change the component as you please without disturbing the injected references. This is exactly what I have done with my IoC container and it works absolutely fine.
  21. A simple proxy can take the place of the dependency reference and pass through messages to the actual component.

    Presumably you want the container to define the proxies. This implies that POJOs that perform well with one such EJB-3 container will perform poorly (or break?) with another EJB-3 container that lacks such proxy automation. So why not put the proxy automation in the EJB-3 specification?
  22. I don't think something as discrete as proxy automation belongs in the specification. Besides, at a high level this is nothing but a simple object composition technique to achieve dynamism and it would be ridiculous to add such things to the EJB spec. Just my 2 cents no offense.
  23. Maybe I'm missing something as I have not read any of the EJB 3 proposals but much of what I see vis-a-vis dependency injection is horribly (ok, maybe that's a bit strong) wrong.

    Consider the example

    public void setTestDS(DataSource ds) {this.ds = ds;}

    public void someMethod() {
     Connection conn = ds.getConnection();
      ...
    }

    Why in the world would an EJB have a setTestDS() method?
    Just for IOC - just for testing?
    Why not put someMethod() in a business object and have the EJB delegate the call to it. The business logic can obtain the datasource connection from whereever - use IOC if that makes you happy.
    As much as posible keep EJB relationships/dependencies in the "using" realm as much as possible. Stay away from EJB "having" dependencies.

    If your EJBs are doing a lot of lookups of services and dependencies then you have a semi-serious design issue.

    Use EJBs as pass-throughs; leverage the EJBs security, remotability, poolability, and transactioncal services. But keep your business (and that includes things needed to do your business) out.
  24. As long as it is under a Doctor's care and not in the locker room. Oh sorry wrong forum and wrong kind of injection. I was watching the MLB hearings - http://www.c-span.org/.
  25. Thanks for comments[ Go to top ]

    Just want to thanks folks for their comments. The consensus of criticism seems to be that these issues are application server implementation specific. I would argue that the following items need to be in the specification and are clearly not implementation details. (1) EntityManager injection syntax, (2) remote JNDI object injection syntax, (3) a list of the specific objects that can be injected, (4) how to access an EJB from J2SE client (without IoC) and (5) what is the object injected for an EJB-EJB dependency; home or object?

    I would also argue that whether or not re-injection occurs needs to be clarified and is not an implementation detail. I would hate to build a system that on one server can stay up regardless of changes to the underlying JNDI and on another server requires a reboot to pick up the changes. If that were the case, then I would never use DI at all - I would build my own locator interface and inject an implementation into the EJB (ie. interface injection).

    Proxy objects will make no difference as that only delays instantiation until the first use and then you are right back to not using a proxy. There is no release mechanism (from the aquire-use-release paradigm).

    I should mention that I do use DI for other things, it just isn't a fit for this particular use (EJB dependencies). Again we can fix what is there without introducing new problems.
  26. Thanks for comments[ Go to top ]

    Proxy objects will make no difference as that only delays instantiation until the first use and then you are right back to not using a proxy. There is no release mechanism (from the aquire-use-release paradigm).

    I don't think this statement is accurate. With the standard Java proxy, the messages are always delegated to the actual component via the proxy's InvocationHandler. Now of course what you are saying is possible with frameworks like Javassist or CgLib or ASM.
  27. Re: Proxies[ Go to top ]

    Got it - a DataSource proxy, on a getConnection method could do the lookup of the actual DataSource, get the connection and then lose the reference to the actual DataSource at the end of the getter method. That works fine for the connection factory objects for not for some of the other objects - for example a JMS Queue or Topic. You don't want to lookup/release on every method call in that case - you need the reference to the real object for the block of code that is using it and then you can let it go out of scope. This is what I mean by there not being a good place to release the reference with DI.
  28. Re: Proxies[ Go to top ]

    I haven't completely read the spec draft, so I am not fully aware of the current component life cycle, but what you seem to be asking is an enhacement to the currently defined lifecycle, right? I was simply addressing your concerns under the section "Changes" in your document.
  29. Re: Proxies[ Go to top ]

    Harish - I appreciate the comment about proxies - it came up with a previewer of the paper. It just won't work as a standard strategy for all the types of dependencies that are listed. You are totally correct in this last comment - a change to the current and draft spec for a proper cleanup point for SLSB would be A Good Thing.
  30. My bad - Queue and Topic proxies are fine. JavaMail Session would not be but that is really more of an issue with JavaMail. In the end however, I wouldn't want to do a lookup, delegate the call and release the reference for every method call.
  31. Connection?[ Go to top ]

    "an injected JDBC connection couldn't be reallocated to a different component by the container, raising the spectre of running out of managed connections if a large number of EJBs were present."

    If I read the spec corretly, the DataSource was injected, not the Connection?? So the EJB would not hold onto the connection.

    Some best practices stay the same, I would not declare a Connection as a class variable in the Bean class in the current (2.1)spec, so why would I inject the connection as a member? Connections are obtained from a pool through the DS and the same usage patterns should apply (getConnection() and close it during the scope of the Facade.
  32. Hi

    This post is asking important questions, but I think we should be confident JCP will answer them in the proper way.

    The draft we have seen so far is not, as I understand it, the complete requirement (which by the way is refered to in the spec) for EJB 3 but only gives the developper view of what is proposed (for example, it is quite clear that EJB 3 SLSB implementations are thread-safe but not that they should be pooled as in the complete 2.1 specification).

    So let's go back to the developper view. In my opinion, the draft is not going far enough with IoC. For example, it would be interesting to have POJO dependancy (I've read from B. Burke in another post that it would have been to late for this to be integrated in the spec).

    We could have this done if we had the possibility to easily extend the EJB framework. The new interceptor has a way to it. But I think what we lack is the possibility to execute code once after the ejb-jar has been deployed: this way we could execute expansive initializations that could be shared by all ejbs in the jar. I'm thinking for example about seemless Spring integration for example (where EJB would be the starting points of spring managed object hierarchies): the Spring initialisation could be made once for all objects in the jar.

    What do you think?
  33. Re: Pooled and more injection[ Go to top ]

    Guillaume - I think that if you are thread-safe w/o using synchronized, then you have to have a pool of objects (or create them for every invocation).

    Your comments about more injection are interesting - I'm using SLSB as a wrapper to a service POJO that gets DAO POJOs injected into it. We are using Spring (and Hibernate for DAO) but within an EJB container (for remoteness/transaction/pooling). In the end we will probably get rid of the EJB all together - the SLSB is just an architectural component housing the actual component. All of those objects are stateless - objects that are needed by the thread are "managed" (put on a thread local).

    Like I said in the paper, I'm a fan of these technologies, just not how they are being used in EJB3 (or for resources for that matter).
  34. Re: Pooled and more injection[ Go to top ]

    Guillaume - I think that if you are thread-safe w/o using synchronized, then you have to have a pool of objects (or create them for every invocation).
    You can also have ThreadLocal objects (agreed, this is some kind of pool too).
    We are using Spring (and Hibernate for DAO) but within an EJB container (for remoteness/transaction/pooling). In the end we will probably get rid of the EJB all together - the SLSB is just an architectural component housing the actual component. All of those objects are stateless - objects that are needed by the thread are "managed" (put on a thread local).
    I also think this is the way to go, except for the "get rid of SLSB" part of you answer. Indeed, SLSB offer you first class transaction and security (I have not so far used the remoteness part of it that seems rarely needed).

    Spring standalone, in its current version has limitations on this matters (for example, you don't have out of the box multi-transactionnal resource support, security (with acegy) is beta, and all these are complexe to configure decalratively because there are not stable (current transactionnal apache commons annotations will be deprecated by coming soon jdk 1.5 annotations) ad hoc supports for this: you must use low-level aop and very verbose bean wiring declarative glue to "magically" add declarative transactionnal support to managed bean methods.

    The point is the following: yes you rarely need full xa multi-resource support, and yes 80% of applications don't bother about declarative security (you can always transmit the Principal as an extra parameter to security aware service methods). And I agree we should use the right tool for the right job. But the agility that the former statement is demanding is often too much for the average corporate developper (he risks to have to learn new technology and methodologies with each new project that he takes part to): I prefer a solid methodologie ant toolset set that can apply in every situation, even if it is sometime a bit overkill.
  35. Re: Pooled and more injection[ Go to top ]

    I also think this is the way to go, except for the "get rid of SLSB" part of you answer. Indeed, SLSB offer you first class transaction and security (I have not so far used the remoteness part of it that seems rarely needed).
    Spring standalone, in its current version has limitations on this matters (for example, you don't have out of the box multi-transactionnal resource support...
    The semantics of Spring transaction management are significantly richer than EJB transaction management (any version). For example, Spring supports "rollback rules" (declaratively specifying behaviour to avoid the need to call setRollbackOnly) and nested transactions on supporting resources. Plus of course transactional behaviour can be applied to POJOs, and you can use a choice of transaction infrastrutures underneath: JTA, or a strategy for a single resource that can run standalone.

    Spring does provide "out of the box multi-transactional resource support" when you use the JtaTransactionManager supplied with Spring. This delegates to the application server (or a standalone transaction management) for the infrastructure-level stuff. Spring, like EJB, provides the programming model, not the low-level resource coordination. Spring does not aim to fully replace the transaction infrastructure of an app server, and nor should it.
    security (with acegy) is beta
    True, but it's very solid and widely adopted. Version 1.0 will be released very soon, and it will move to an official Spring subproject. Acegi is significantly more capable than standard EJB declarative security, which is insufficient for many requirements.
    and all these are complexe to configure decalratively because there are not stable (current transactionnal apache commons annotations will be deprecated by coming soon jdk 1.5 annotations) ad hoc supports for this: you must use low-level aop and very verbose bean wiring declarative glue to "magically" add declarative transactional support to managed bean methods.
    Yes, annotations are compelling here, if you get to work with Java 5.0. (Commons Annotations, which Spring has supported since 1.0, is actually a pretty nice technology, but unfortunately it isn't likely to have much of a future as people gradually move to Java 5.0.) Spring 1.2 (due for final release April) will support Java 5.0 annotations.

    However, you are not forced to work directly with Spring AOP to perform transaction management. There are several ways to apply transactional behaviour to multiple objects with minimal config complexity, such as "auto proxy creators" (define the transactional behaviour and apply it to any number of plain bean definitions without special transaction content) and template ("parent") bean definitions (define transactional behaviour in a parent definition and any number of child beans can inherit that behaviour). In all cases, the EJB 2.x transaction configuration is likely to be more verbose.

    Rgds
    Rod
  36. Acegi Security status[ Go to top ]

    security (with acegy) is beta

    Just a few notes on Acegi Security maturity...

    Acegi Security's present status is discussed at http://acegisecurity.sourceforge.net/docbook/acegi.html#security-introduction-status. As noted there, "The APIs are considered stable and only minor changes are expected" and "Some minor improvements are currently intended prior to the 1.0.0 release, although each of these represent additional functionality that will in no way modify the project's central interfaces or classes".

    As shown at http://sourceforge.net/project/stats/index.php?report=months&group_id=104215, there are around 1,000 downloads per month of the project. It is also very active on the Spring forums. The project home page (http://acegisecurity.sourceforge.net/) lists many external web pages and books mentioning Acegi Security. You can also access Clover coverage reports online.

    Acegi Security's next release will be a maintenance 0.8.1 release, followed by 1.0.0. We expect release 0.8.1 within a couple of days, and 1.0.0 in approximately one month. There's nothing technical or feature-related stopping us - we're just being conservative regarding production deployment testing of 0.8.0 enhancements, and allowing some finalisation of Spring subproject-related matters.

    Overall Acegi Security is quite suitable to use in most applications in its present form.

    In relation to this broader thread, the suggestion that EJB declarative security is somehow "first class" is hard to justify when a large proportion of EJB developers just go away and write their own adhoc security code instead (a point reflected by the comment, "80% of applications don't bother about declarative security"). At least using a popular, open-source, framework-oriented approach to security (like Acegi Security) you can enjoy feature-rich declarative security, community support, best practice design patterns, avoid reinventing the wheel, and get more flexibility than most people would have time to write in-house.

    Cheers
    Ben Alex
    Project Admin - Acegi Security
  37. Lifecycle enhancement and IoC[ Go to top ]

    HiThis post is asking important questions, but I think we should be confident JCP will answer them in the proper way. The draft we have seen so far is not, as I understand it, the complete requirement (which by the way is refered to in the spec) for EJB 3 but only gives the developper view of what is proposed (for example, it is quite clear that EJB 3 SLSB implementations are thread-safe but not that they should be pooled as in the complete 2.1 specification). So let's go back to the developper view. In my opinion, the draft is not going far enough with IoC. For example, it would be interesting to have POJO dependancy (I've read from B. Burke in another post that it would have been to late for this to be integrated in the spec).We could have this done if we had the possibility to easily extend the EJB framework. The new interceptor has a way to it. But I think what we lack is the possibility to execute code once after the ejb-jar has been deployed: this way we could execute expansive initializations that could be shared by all ejbs in the jar. I'm thinking for example about seemless Spring integration for example (where EJB would be the starting points of spring managed object hierarchies): the Spring initialisation could be made once for all objects in the jar.What do you think?

    Please spam ejb3-feedback at sun dot com as much as possible on getting POJO/bean injection into the EJB 3.0 spec. Its something a few of us on the EG are interested in.

    Also, I call on the Spring folks to use their influence on the J2EE spec committee to get full IoC into the J2EE specification in general. We all know J2EE would be stronger for it.

    Bill
  38. Lifecycle enhancement and IoC[ Go to top ]

    Also, I call on the Spring folks to use their influence on the J2EE spec committee
    Do we have influence on the J2EE spec committee?
  39. Lifecycle enhancement and IoC[ Go to top ]

    But I think what we lack is the possibility to execute code once after the ejb-jar has been deployed: this way we could execute expansive initializations that could be shared by all ejbs in the jar.

    This and other things have always bothered me about the specification. There's not enough lifecyle hooks defined. There's also not enough EAR level specifications defining classloading and lifecycle hooks.
    WARs have WE-INF/classes and lib defined in the spec (at least I think it's in the spec).
    Why not EJB/*-INF/classes and lib as well as EAR/APP-INF/classes and lib?

    Give us hooks for EJB deployment, EAR deployment, JNDI event hooks (if JNDI is part of the J2EE app server spec.), etc.

    Web applications have the mandated events, hooks, class loading scheme definitions, extend those to EJBs, EARs, etc.

    Then you can IOC the whole shebang.
  40. Lifecycle enhancement and IoC[ Go to top ]

    This and other things have always bothered me about the specification. There's not enough lifecyle hooks defined.
    I agree. There was a strong argument for first fixing the problems and gaps with EJB 2.x before moving into new features. A layer of ease-of-use veneer over the top isn't enough unless it addresses some of those long-standing problems. Hopefully it may still do so.
  41. In my linked blog entry I point out that AOP can be used to well solve the problems that have been raised regarding dependency injection. These days the frameworks providing the dependency injection feature are also general purpose AOP frameworks. Consequently the frameworks themselves have the tools well in hand to tackle the thorny issues raised.

    Use AOP to wrap objects (and solve thorny dependency injection issues)