Discussions

News: Article: The New Features in EJB 3.1 (Part 2)

  1. This series of articles is a preview of the changes the EJB 3.1 expert group is working on for the next version of the Java EE specification. The idea is to give you a head’s up on the changes as well as gather your feedback early so the expert group has the best chance of getting it right. EJB 3.0 brought simplicity to Java EE 5 by moving away from a heavyweight programming model. EJB 3.1 aims to build on those successes by moving further down the path of simplicity as well as adding a handful of much-needed features. In each article in this series, I will let you know about the progress made by the expert group. In the first article of this series, I covered two of the earliest discussed features – optional interfaces for Session beans and Singleton beans. I also provided an overview of the rest of the features being discussed. In this second article, I’ll cover two more features that have been discussed in detail—EJB Timer Service enhancements and simplified packaging. Remember, none of this has been finalized yet, although a draft of the specification will be released for review soon. All of this is really just a peek into the inner workings of the JCP so that you have a chance provide feedback.

    Threaded Messages (25)

  2. Issues with Feature Creep...[ Go to top ]

    First, let me say that I really like a lot of the things that are proposed in EJB 3.1. The new timer system, singleton beans, asynchronous activation, etc. (If we can get some application and server lifecycle events, that would be dreamy...) I always really liked EJB Lite, and herein lies my concern. On the surface, EJB Lite is really spectacular. It readily fits in the "80%" mark where I think a lot of EJB apps fall. Specifically, web apps wanting declarative transactions and container resources (JDBC pools specifically, but also things like Java mail). But the very "Lite" nature of the EJB Lite is my worry. That fact that it's "Lite" means that at some point, your development is going to have to make some large step up. By that I mean you're working on your application, incremental modifications, your app follows a reasonably smooth slope of complexity and configuration as you add features and leverage the container. But, since you are in "Lite" mode, at some point you're going to hit a wall. That wall is where if you add Feature Q, you're no longer qualified for "Lite" mode, but now you have to jump to EJB Jar and EAR mode. When you cross that line, all of sudden the developer is greeted with "I have to do what??", with "what" being jumping through whatever hoops in terms of configuration, packaging, etc. to make the leap from EJB Lite to EJB. That means, to me, that by selecting EJB Lite, you're specifically constraining your options as to what you can do with your application (in regards to leveraging EJB). You can take it so far using your methodology, but when you reach that point, you need to consider what you need to do to continue farther. Now, that step may be minor. Using the IDEs, it most likely is minor. In NetBeans, you could probably take your Session Beans out of your WAR project, plop them in an EJB project, create an Enterprise project for them both, and be on your merry way with most likely none to be the wiser. But if it also means changing containers (from Glassfish Express to Glassfish, say), then there are other factors to consider. I just think that this will be a pain point. That the EG needs to have a good answer to why "all I want to do is X, and now I have to repackage my code, redo my deploy, and change containers?". Developers see it as a simple addition, whereas EJB 3.1 sees it as an escalation from one mode to another. That tells me that the EJB Lite team should make an extra bit of effort in the spec to ensure that kind of transition is as simple as practical to do, otherwise developers won't transition, at least not necessarily to EJB. I've advocated for a while that if you want to write a web app, you should start with a full pop container (Glassfish or JBoss) rather than simply a servlet container. Save for potentially resource issues (valid point), there's no reason not to use a full boat container. I've advocated that simply because it give yous a smoother path to leveraging the rest of the containers features, making those features more available and more likely to be used. So, when you select the feature set for EJB Lite be cognizant of the fact that you're putting a barrier between that feature set and the larger EJB feature set. When an application hits that barrier, it's going to be a pain point for developers.
  3. Re: Issues with Feature Creep...[ Go to top ]

    Will, While there might be a pain-point in moving to a full Java EE container from an EJB Lite container, I don't think it is going to be a major pain-point, especially if you aren't switching vendors. Also, I hope the article made it clear that you can use simplified web-app packaging even inside full-scale application servers with EAR files and the like. That being said, you have a good point in terms of vendors being conscious about making the "upgrade path" as smooth as possible, perhaps through good tooling... Cheers, Reza
  4. Re: Issues with Feature Creep...[ Go to top ]

    That being said, you have a good point in terms of vendors being conscious about making the "upgrade path" as smooth as possible, perhaps through good tooling...

    Cheers,
    Reza
    That's always been the wrong answer, and one that is too often give in Java, from Swing on down. The question comes up "Why do X if it makes Y more difficult?" The answer is typically: "That's a good point, we don't need to do X, but since it makes Y harder, perhaps someone someday will make tool Z that makes doing Y a little bit less painful." Instead you should be looking at possible alternatives to X. If X is the problem, adding complexity to it is not the answer.
  5. Re: Issues with Feature Creep...[ Go to top ]

    Aaron: As I said, I don't really see this as that big of an issue to begin with :-). In my eyes, tooling would make an easy enough job almost trivial in this case. No one said you have to agree with me though :-( Cheers, Reza
  6. Folks: I'll try my best to pay attention to this thread and answer any questions you might have, so please don't hold back :-) I know one area of interest is probably WebBeans and EJB 3.x integration. Unfortunately, although I briefly mention it towards the end of the article, I did not go into the details in this particular installment in the series, but I'll be happy to chat about what I know. Cheers, Reza
  7. The simplified packaging is great. I haven't actually seen any need at all so far for having an ear consisting of different isolated modules. I think a concept like the java module system might be more suited for this. What I don't understand about the simplified packaging are a number of things: * why must the war be packaged in an ear? Why not just a war? * is there a restriction on the use of EJBs in the war? If so, why is that needed? * how about dependency injection? Why does that only work in some components but why not in all of them? (e.g. regular POJOs) * can't the spec define the requirements on a mini-container/libray allowing EJB development to be done outside of the container in a Java SE environment? Cheers Erik
  8. Erik: Please see the below responses: * why must the war be packaged in an ear? Why not just a war? - It could be, if the container is a Servlet container that supports EJB 3.1. I was just shooting for completeness... * is there a restriction on the use of EJBs in the war? If so, why is that needed? - There are no restrictions. All EJB features will be available, including remoting. * how about dependency injection? Why does that only work in some components but why not in all of them? (e.g. regular POJOs) - You may use WebBeans to inject "non-managed" components in EJBs and vise-versa. I'll talk about this in a later article. The issue in the past has been that EJB is not really the right place for defining full-scale DI, leaving room for a "missing integration framework" like WebBeans (and if I may dare say so, Spring, if it were to be standardized as a JSR). * can't the spec define the requirements on a mini-container/libray allowing EJB development to be done outside of the container in a Java SE environment? - There is some preliminary discussion around standardizing this. In any case, you can do this today using Open Source embedded containers like JBoss Embedded and Open EJB. You can use these for unit/integration testing too. Cheers, Reza
  9. * is there a restriction on the use of EJBs in the war? If so, why is that needed?
    - There are no restrictions. All EJB features will be available, including remoting.
    REALLY? I thought the WAR EJB's were basically limited to local Session Beans. We can have remote session beans as well? What about Message Beans? (Entity Beans are effectively dead, so I don't consider them at all.) What WON'T we be able to do with a WAR EJBs?
  10. Will: Let me try to clarify: * Simplified EJB packaging is effective for all containers, full or EJB Lite. Simplified packaging in no way limits what EJB features you can use, it just gives you more flexibility. * EJB Lite *does* limit you to Session Beans and Singleton Beans, among other things. I'll talk about the details in a later article. * It may well be that most people using an EJB Lite container will opt to use simplified web application packaging, but they don't have to. Hope this helps... Cheers, Reza
  11. Cron[ Go to top ]

    Hey Reza, Nice to see you online after all these years. (Yes, you should have come to Flux back in 2001 when we last talked. ;) Just kidding. Hope all is well with you and your family.) I'm looking forward to seeing the EJB Timer Service Cron specs. Anything interesting, unusual, or out of the ordinary there? Cheers, David Flux - Java Job Scheduler. File Transfer. Workflow. BPM.
  12. Re: Cron[ Go to top ]

    David: Great to hear from you! Please do drop me a note some time, I'd love to chat. Believe it or not, I still do regret not joining you guys in the Big Sky Country from time to time! The family and I are insanely busy, but happy in general... Nothing too unusual about the cron support at this point, primarily the basic cron functionality with some additional features like the ability to specify an activation and deactivation dates. We are also talking about supporting an upper limit of the number of times a trigger fires. Anything more elaborate than that (such as a custom calendar, holidays, etc) would require something like Quartz or even better-Flux :-). Vendors will also likely add some clustering and load-balancing support to Timers. However, I really like the idea of an SPI for EJB, so that you could better integrate third-party non-standard products like Flux or Quartz with EJB, I'm not sure how far I'll be able to go with that, though...you can kind of do that today with Interceptors. Cheers, Reza
  13. Re: Cron[ Go to top ]

    I really like the idea of an SPI for EJB, so that you could better integrate third-party non-standard products like Flux or Quartz with EJB, I'm not sure how far I'll be able to go with that, though...you can kind of do that today with Interceptors.
    I'm not sure it's really necessary. Quartz and Flux can be integrated well enough with EJB on their own. Both Flux and Quartz offer more advanced functionality above what I see coming in the EJB Timer Service, so there would always be non-standard timing specifications in place if there were an SPI. In short, I'm not sure I see an advantage to being able to swap out implementations without also taking advantage of greater capabilities. And with the EJB spec being a spec, I imagine people would want uniform behavior. Quoting from your article:
    Some folks argue that this "pure cron style expression" is way too cryptic, while others point out that a lot of developers are so used to it that it should be supported in EJB.
    It goes both ways. Once you're working with Cron expressions regularly, you want to work with them in a condensed form. When you work with them only infrequently, an API can be nice. Cheers, David Flux - Java Job Scheduler. File Transfer. Workflow. BPM.
  14. Re: Cron[ Go to top ]

    In short, I'm not sure I see an advantage to being able to swap out implementations without also taking advantage of greater capabilities.
    David: To be absolutely clear, I'm visualizing something like: @Stateless public class SomeService { @FluxSchedule(...) public void someMethod() { ... } } Or something like: @Stateless public class SomeService { @FluxEngineFactory(...) private FluxEngine engine; ... } With developers needing to do little more than drop a jar into their application. The third-party tool would automatically register itself through the EJB SPI (geared more towards extensibility) to do whatever it does in terms of additional EJB declarative services. Cheers, Reza
  15. WorkManager[ Go to top ]

    Sorry for my ignorance in case this is already possible but is there (or will be) a way to inject WorkManager the same way a TimerService is injected? So instead of @Resource TimerService timerService to have @Resource WorkManager workManager. Also, is it planned to have a standardized global JNDI naming for resources? e.g. if I have @Stateless public class FooBean implements Foo { .. } GlassFish gives it a global JNDI name of the full name of the interface Foo. For OpenEJB the global JNDI naming can be configured. I guess JBoss also has it's way of doing it. Can't we have this specified by the spec? I know about "mappedName" but from what I've read it is not required to be supported by a JavaEE 5 implementation (OpenEJB ignores it) and also the yntax/semantics of mapped-name values are vendor-specific.
  16. Re: WorkManager[ Go to top ]

    Mihai:
    So instead of @Resource TimerService timerService to have @Resource WorkManager workManager.
    I'm not quite sure what you mean--If 'WorkManager' is in JNDI somehow it can be injected through @Resource...
    Also, is it planned to have a standardized global JNDI naming for resources?
    Yes, although this is something in the works, but is being treated pretty seriously. I would suggest this is worth sending a comment to the EG: jsr-318-comments at jcp dot org and/or jsr-316-comments at jcp dot org. Cheers, Reza
  17. Re: WorkManager[ Go to top ]

    I'm not quite sure what you mean--If 'WorkManager' is in JNDI somehow it can be injected through @Resource...
    Well, WorkManager (javax.resource.spi.work.WorkManager) is available in JBoss, GlassFish, BEA, Weblogic ... but getting an instance (through JNDI or other means) is not as easy/independent as getting a TimerService using annotation. So what I wanted to know is if accessing this kind of service/resource was going to be made easier like injecting a TimerService using annotations (no need to specify any JNDI). I know that as an admin you can define any number of WorkManager's and give them any global JNDI name you want but I would like that j2ee spec mandate that there should be a "default" one and if you annotate @Resource WorkManager workManager and don't specify the JNDI name then the default one should be injected. This way I can have my code deployed on any J2EE server w/o the need to have specific xml deployers for each server.
  18. Re: WorkManager[ Go to top ]

    Well, WorkManager (javax.resource.spi.work.WorkManager) is available in JBoss, GlassFish, BEA, Weblogic ...
    I see..sorry I wasn't aware of this, looks like a JCA thingamabob. This is probably not used often enough to add anything specific for it in terms injection rules... But it might be worth pointing out to Ken in an email, he might feel differently. Cheers, Reza
  19. If the ejbs can be included under a war module : a) Does it mean that JEE appservers need to embed the EJB container into the Web Container (example WebSphere which uses 2 containers) b) How does this affect classloading policies and modes ? Thanks SJ
  20. Sujay:
    Does it mean that JEE appservers need to embed the EJB container into the Web Container
    Generally, yes.
    How does this affect classloading policies and modes?
    Depends on the implementation, probably pretty similar to current vendor strategy. Cheers, Reza
  21. Simplified JNDI[ Go to top ]

    Though with annotation based dependency injection we can avoid jndi lookups, it's not always the case. The dependency injection is available only for container "managed" components like servlets, jsf managed beans, session beans etc. So if you are using a standalone client or pojo service locator class to access an ejb, you have no choice but to stick with jndi. I'm glad to see that the "simplification of jndi" is also in the possible "feature list".
  22. comments & questions[ Go to top ]

    Hi Reza, - Why is an ear required? I understand that it should be optional for backward compatibility, but why is it mandatory? It seem that the container could work like JPA and look for an ejb-jar.xml, if one was found, then load the ejbs. - I like the idea of EJB Lite. No reason to have all or nothing. I like the idea of being able to apply the 80/20 rule. EJB lite is probably going to work for most of the EJB developers that I work with. I think this is a very good move, to give us more choices and options on what we need form the container. I personally like just running a jetty server if I can get away with it. - JNDI really should be standardized. I am a fast become a Guice fan. I will be very interested to see how much of Guice makes it into web beans. I'm still trying to find time to look at the web beans draft, hopefully some day soon..... I think you guys are doing a great job of turning this spec around. Thanks,
  23. Re: comments & questions[ Go to top ]

    I think you guys are doing a great job of turning this spec around.
    Thanks for the kind words. Everyone is trying their best, especially the spec lead Ken.
    Why is an ear required?
    It's not, particularly in a web container + EJB Lite. As I see it, this is one of the great side-effects of the simplified packaging enhancement.
    I will be very interested to see how much of Guice makes it into web beans.
    As I understand it, quite a bit... Cheers, Reza
  24. Nasty mix of nuts[ Go to top ]

    I find adding EJBs into the web-modules rather nasty. I would prefer for compatible web-containers to look for ejb.jar:s instead. But thats probably just me being an old geezer with my mind stuck in old tracks :) Shared resources should really be defined in application.xml in my opinion. If EJBs are to be allowed in the web-modules, why not also look for a application.xml in there? It would require a definition of overriding in the spec though, or we would end up shared resources getting overriden in all sorts of mysterious ways depending upon the load-order of the implementation used. I would also like to thank the Expert group for all your hard work. EJB 3.1 will be great!
  25. Re: Nasty mix of nuts[ Go to top ]

    I would also like to thank the Expert group for all your hard work. EJB 3.1 will be great!
    Thanks and I'll pass on the kind words... Cheers, Reza
  26. Re: Nasty mix of nuts[ Go to top ]

    I would also like to thank the Expert group for all your hard work. EJB 3.1 will be great!
    +1