Using EJB 3.0 outside the container

Home

News: Using EJB 3.0 outside the container

  1. Using EJB 3.0 outside the container (42 messages)

    In "Using EJB 3.0 outside the container," Doug Clarke offers a quick how-to on using TopLink (an EJB 3.0 implementation, and the reference implementation, at that) from a standalone Java application.

    There are four basic steps to using EJB 3.0 outside of a container: creation of the entity model itself, creation of a class that returns the list of classes in the entity model (and provision of that class name to the JVM), adding the TopLink agent to the JVM, and lastly, creation and use of six properties in a map to get the EntityManager.

    One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager; is this a repeat of the same things that bother many developers about past versions of EJB? While surely light frameworks can ease any pain associated with this, should there be an easier (meaning less code, with more self-discovery on the part of the EJB 3.0 container) mechanism for this?

    Threaded Messages (42)

  2. Give me a break[ Go to top ]

    One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager; is this a repeat of the same things that bother many developers about past versions of EJB?


    Joe, I think you're a well-intentioned guy, but this rises to the level of the worst kind of FUD I have ever seen on this site.

    To configure Hibernate's EJB3 persistence provider (Hibernate EntityManager) requires exactly one XML file, persistence.xml, that specifies the exact same information (right down to the same property names) that Hibernate users specify today in hibernate.cfg.xml.

    There is no need for a "class that returns the list of classes in the entity model" or "adding the ... agent to the JVM".

    And as far as I am aware, neither of those things are "things that bother many developers about past versions of EJB". In fact, I have never, ever once heard either one of them mentioned as a problem with EJB2.

    This practice of trawling the web for blogs and then trying to add some kind of silly political spin has log ago turned this site into a total joke.
  3. Byebye discussion[ Go to top ]

    Ohwell, it usually takes a dozen or so messages before berk comes in and hijacks a thread and turns it into a jboss one, guess we're starting early on this one.

    Gavin, if you had read Joe's message, he makes no mention of hibernate. He in fact discusses toplink, and how it's potentially annoying to have to configure so many things in toplink to use it outside the container.

    It's great that it's easier in hibernate. It's great that hibernate will do class auto-discovery out of the container (not required by the spec, so a nicety your product supports that toplink doesn't). It's great that hibernate beats toplink in terms of ejb3 out of container ease of use. How is the original news entry inaccurate? There's an interesting tech piece on how to deploy a specific vendor's implementation of ejb3 out of container.

    Nobody is insulting you or challenging your manhood (unless you count me laughing at you for being such a petulant baby and throwing all your toys out of the pram and proceeding to soil yourself in protest at some imagined slight).
  4. Byebye discussion[ Go to top ]

    Title of the post:
    Using EJB 3.0 outside the container

    Quote from the post:
    There are four basic steps to using EJB 3.0 outside of a container

    The post absolutely does not make clear that this is only true in one particular implementation of EJB3. In fact, it reads as if it is using TopLink as an example of how all EJB3 implementations will work.
    Nobody is insulting you or challenging your manhood [blah blah blah]

    No, and I am perfectly thickskinned enough to not be bothered if they were. However, the casual reader would certainly be mislead by the above post and I'm amazed that you are trying to deny that. (Perhaps the opportunity to call me a "petulant baby" was just too big to resist?)
  5. Byebye discussion[ Go to top ]

    Quote from the post:
    There are four basic steps to using EJB 3.0 outside of a container
    The post absolutely does not make clear that this is only true in one particular implementation of EJB3.

    .. except that one of the steps was adding the TopLink agent to the JVM.

    I have to say I read nothing in the original post that made me think this was generic EJB3. But then different people can read the same things in different ways depending on their background.

    Kit
  6. Byebye discussion[ Go to top ]

    Hey guys, it's from a couple of months that I see a bit of stress in the Java community !!!
    It's a matter of specifications ? It's .NET that is taking more and more ground or RoR that is killing both ?
    If you need to relax a bit you can come with me tonite and watch a good footbal match !!!
    There we can beat every guys that wear an blue-black scarf !!!
    ;-)
    L.
  7. Re: Byebye discussion[ Go to top ]

    Gavin,
    The post absolutely does not make clear that this is only true in one particular implementation of EJB3. In fact, it reads as if it is using TopLink as an example of how all EJB3 implementations will work.

    At no point was this blog entry intended to imply that this is how all EJB 3.0 Persistence implementations will work. I certainly did not post it here on TSS and did not write the entry with that intention.

    I opened the blog entry stating that is based on a specific version of Toplink offering preview support. I have also just added a disclaimer to make it clear that our implementation of the completed specification will leverage persistence.xml. Hopefully this will clarify things for other readers.

    Again, TopLink Essentials already offers this much simplified configuration approach using the persistence.xml and supports entity auto-discovery both inside and outside the container.

    Doug
  8. Re: Byebye discussion[ Go to top ]

    Gavin,
    The post absolutely does not make clear that this is only true in one particular implementation of EJB3. In fact, it reads as if it is using TopLink as an example of how all EJB3 implementations will work.
    At no point was this blog entry intended to imply that this is how all EJB 3.0 Persistence implementations will work. I certainly did not post it here on TSS and did not write the entry with that intention.

    Exactly, that is why I criticised the TSS "post", and not your "blog".

    I hope that clarifies any potential worries?
  9. Misleading Post[ Go to top ]

    This TSS post is really misleading, especially the title. It says EJB3 out of container, then links to a blog about toplink, then says its very troublesome to configure to use EntityManager. So you see something like EJB3-NOISEtoplinkNOISE-ENTITYMANAGER-HARDTOUSE. Instead the post should say Using EJB 3.0 outside the container With TOPLINK. Then point to the blog, then make the silly comment

    One potentially worrisome factor, when using TOPLINK's EJB3 IMPLEMENTATION, is how many properties have to be specified (in so many places) to acquire the EntityManager.

    Remember in Java Land for each spec there's potentially half a dozen implementation from different vendors. Without proper wording (or editing in this case), articles will tends to mislead ppl, especially the ppl in suits, to think that that that particular spec has problems when in fact only one of the implementation has it.
  10. Misleading Post[ Go to top ]

    This TSS post is really misleading, especially the title. It says EJB3 out of container...

    I totally agree with this. A serious technical Web site shouldn't need cheap media tricks to create interest, such as making the news article sound controversial or generic etc. Leaving "Toplink" out of the title can only be intentional and I'm getting more and more convinced that TSS is technically dying. However I'm sure that its rating is increasing as an entertainment site (I could've added, "given the number of Microsoft clowns performing their best shows in here" but I don't want to add to flame the useless arguments :).
  11. Byebye discussion[ Go to top ]

    It's great that it's easier in hibernate. It's great that hibernate will do class auto-discovery out of the container (not required by the spec, so a nicety your product supports that toplink doesn't). It's great that hibernate beats toplink in terms of ejb3 out of container ease of use.

    Just to be crystal clear, in case it was not obvious from my previous post, the steps described in the blog were for a preview implementation of a very early version of the spec.
    In its current form TopLink does support all of these things and does not get beat by Hibernate or any other EJB 3 persistence implementation ;-)
  12. Byebye discussion[ Go to top ]

    There's an interesting tech piece on how to deploy a specific vendor's implementation of ejb3 out of container.

    But that wasn't the theme of the article here. The original blog entry was about an early preview release of EJB 3.0 in TopLink, and had a clear disclaimer to that effect. The article here discusses the blog entry as if it applied to EJB 3.0 in general, and not to a specific vendor's implementation. There are current preview releases of EJB 3.0 which are far simpler to set up. The original article was clumsily titled, but the article here should have been better worded to avoid confusion, and posts questions like
    is this a repeat of the same things that bother many developers about past versions of EJB?
    which could be easily be answered in the negative just by taking a quick look at some other implementation: Hibernate, or Kodo perhaps.
  13. Give me a break[ Go to top ]

    To configure Hibernate's EJB3 persistence provider (Hibernate EntityManager) requires exactly one XML file, persistence.xml, that specifies the exact same information (right down to the same property names) that Hibernate users specify today in hibernate.cfg.xml.There is no need for a "class that returns the list of classes in the entity model" or "adding the ... agent to the JVM".

    I think he's only talking about TopLink
  14. Give me a break[ Go to top ]

    I see nothing wrong in article, it is published on TopLink Blog and it is about TopLink configuration, it is technical and clear.
    But you must write something controversial to link article on TSS. It is very fun site, do not pollute it with technical stuff please.
  15. Give me a break[ Go to top ]

    Joe, I think you're a well-intentioned guy, but this rises to the level of the worst kind of FUD I have ever seen on this site...has log ago turned this site into a total joke.
     
    Ouch! It couldn't be that bad since I'm not any more afraid after reading his summary (you know the fear part of FUD).
     
    Joe's summary is a little sloppy. I'd rather it separated out what is required for the EJB3 spec and what is Toplink-specific configuration. It is hard to question EJB3's ease of use if you mix in implementation-specific plumbing. Also, the blog's example shows the properties being set in code, which always looks ugly - I'm sure a property file with sensible defaults is available.
     
    BTW: What is the definition of a container? To me the line has gotten pretty fuzzy. Is Hibernate a tool, framework, container or a little of each? Everybody here seems to agree that a web-server is a "container" and that it is really super to do things outside of a container. So what is it that a container contains that makes it a container and not something else?

    In my view it seems that any implemenation of EJB3 is a container regardless of any web-enabled side functionality. Unless EJB3 is seen as a framework that is.
  16. Give me a break[ Go to top ]

    BTW: What is the definition of a container?
    There is no formal definition, but in component oriented development generic container is a component life cycle manager and component can not live longer than container( Component can be a container too).
     
    In short container calls init/destroy, component implements life cycle methods, everything else are optional extensions.
  17. Give me a break[ Go to top ]

    BTW: What is the definition of a container?
    There is no formal definition, but in component oriented development generic container is a component life cycle manager and component can not live longer than container( Component can be a container too). In short container calls init/destroy, component implements life cycle methods, everything else are optional extensions.

    I was being cheeky in my original post but if we use your container definition then can one even do EJB3 outside of a container? Doesn't Toplink and Hibernate control the lifecycle of our EJB3 bean?
  18. Give me a break[ Go to top ]

    It is more description than definition, but you can not use component without container. If you instantiate and manage component life cycle in your "main" method then your application is a container (it hosts components).
    But component and component oriented framework description is not so trivial, framework defines container/component contracts. Interface concept is used for contract definition, events for stateful components,properties to customize component,lookup/naming service to find components.
    POJO is not an EJB framework component, EntityManager is a component.
    Good analogy are ActiveX controls, IDE is component container at development time, application is component container at runtime(well implemented ActiveX control supports both modes).
  19. Container?[ Go to top ]

    BTW: What is the definition of a container?
    There is no formal definition, but in component oriented development generic container is a component life cycle manager and component can not live longer than container( Component can be a container too). In short container calls init/destroy, component implements life cycle methods, everything else are optional extensions.
    I was being cheeky in my original post but if we use your container definition then can one even do EJB3 outside of a container? Doesn't Toplink and Hibernate control the lifecycle of our EJB3 bean?

    Is a Java Persistence API (JPA) EntityManager a container? Well, the answer depends on your definitions of container and lifecycle. :)

    Strictly speaking, the JPA EntityManager doesn't create or destroy your persistent POJO data objects -- your application does. (Well, of course, the JVM garbage collector destroys them after your app lets go of them, but you get the idea.)

    The EntityManager does copy values from the back-end persistent store to variables/methods in your persistent POJO based on the results of the query you hand the EM. And it stores values from your POJO back to the database at the appropriate time (user-definable). But it doesn't itself control the lifecycle of your POJO object. In this respect it's more like a very snazzy persistence utility than a "container."

    However, the definitions of container that I have seen involve some kind of wrapping, proxying, or interception of the "user" component's methods, to provide enhanced quality of service over what the user component could provide by itself. Since the JPA EntityManager may intercept method calls on the POJO object in order to track state changes, and provides data transfer and mapping functions to the POJO, in that respect a JPA EntityManager does behave like a container.

    So in my view, there is still some "containerness" in a JPA EntityManager, but not as much as with EJB2 EntityBeans. (After all, that's what people were asking for.) Under EJB2, the container controls all aspects of lifecycle and data retrieval/storage -- your application never actually invokes the EJB2 EntityBean's methods; you invoke methods on a proxy object that forwards the requests to the container, which in turn invokes the corresponding methods on your EJB2 EntityBean. People didn't like that much indirection on their data objects, so JPA removes the indirection while still providing the data transfer and mapping functions.
  20. Re: Container?[ Go to top ]

    From my perspective, a container is something that "manages" some sort of "components" and provides "services" to those components. This definition allows for containers that manage the components to different degrees and provides only a few or many services.

    I would say that JPA is a container that provides manages entity beans providing a persistence service. A POJO needs to be "registered" with an Entity Manager before it gets persistence, and when registered the Entity Manager will track changes etc and save them when requested.

    So we have light-weight containers like those satisfying the JPA specification and heavy-weight containers like those satisfying the EJB specification (that offers many more service and more management). Of course, there are many ways to implement containers (frameworks, interception, reflection).

    Just my 2 cents.

    Cheers,
    Ashley.

    --
    Ashley Aitken
    Perth, Western Australia
    mrhatken at mac dot com
  21. Give me a dummy[ Go to top ]

    This practice of trawling the web for blogs and then trying to add some kind of silly political spin has log ago turned this site into a total joke.
    I can agree with that, but then again your continual spitting out of your dummy for the slightest reason hasn't done much for you either
  22. Gavin, stop smoking that thing![ Go to top ]

    One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager; is this a repeat of the same things that bother many developers about past versions of EJB?
    Joe, I think you're a well-intentioned guy, but this rises to the level of the worst kind of FUD I have ever seen on this site.To configure Hibernate's EJB3 persistence provider (Hibernate EntityManager) requires exactly one XML file, persistence.xml, that specifies the exact same information (right down to the same property names) that Hibernate users specify today in hibernate.cfg.xml.There is no need for a "class that returns the list of classes in the entity model" or "adding the ... agent to the JVM".And as far as I am aware, neither of those things are "things that bother many developers about past versions of EJB". In fact, I have never, ever once heard either one of them mentioned as a problem with EJB2.This practice of trawling the web for blogs and then trying to add some kind of silly political spin has log ago turned this site into a total joke.

    This is a clear indication that smoking is not good for you!

    J
  23. Using EJB 3.0 outside the container[ Go to top ]

    Joe,

    The how-to was a description of using TopLink's early preview of the EJB 3.0 persistence outside the container.

    Our final implementation based on the completed specification (when it becomes available) will be based on the usage of persistence.xml for simplified configuration.

    The community edition of TopLink, TopLink Essentials, contains support for the more recent drafts of the specification including persistence.xml support.

    http://glassfish.dev.java.net/javaee5/persistence/

    You can see an example of the simplified usage of the persistence API here:

    https://glassfish.dev.java.net/javaee5/persistence/entity-persistence-support.html

    I hope this dispels your worries,

    Doug
  24. Using EJB 3.0 outside the container[ Go to top ]

    Can someone from TSS please rename this artcile something more accurate like
    "Using TopLink's early preview of the EJB 3.0 persistence outside the container"

    I for one opened the link to read about EJB 3.0, not about configuring an old version of Toplink that had some worrisome issues 3 or 4 months ago.
  25. editorial issue[ Go to top ]

    I think this more an editorial issue than the actual blog. It is the role of the TSS editors to manage the posts and make sure the title reflects the true intent of the post and not posting some title just to get more hits. Before this thread goes in the wrong direction can the TSS editors fix it.

    Secondly:
    I also am not sure why some of the hibernate folks are taking this particular blog so personally just because they saw the word TopLink related to EJB persistence.

    I think there is a good deal of over-reaction (frankly).

    Take it easy!
  26. see the home page[ Go to top ]

    If one sees the main page post on TSS this is what it says...
    In "Using EJB 3.0 outside the container," Doug Clarke offers a quick how-to on using TopLink (an EJB 3.0 implementation, and the reference implementation, at that) from a standalone Java application. One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager

    I think the hibernate folks are unnecessary loosing sleep over something small.
  27. see the home page[ Go to top ]

    If one sees the main page post on TSS this is what it says...
    In "Using EJB 3.0 outside the container," Doug Clarke offers a quick how-to on using TopLink (an EJB 3.0 implementation, and the reference implementation, at that) from a standalone Java application. One potentially worrisome factor is how many properties have to be specified (in so many places) to acquire the EntityManager
    I think the hibernate folks are unnecessary loosing sleep over something small.

    The point is that the version of TopLink was not (yet) an EJB 3.0 implementation, and was not (yet) the reference implementation. It was an early preview.

    I am not even an EJB 3.0/Hibernate/TopLink user - I am sticking with JDO for now - but even I think that this article (not the blog) is seriously misleading.
  28. see the home page[ Go to top ]

    - but even I think that this article (not the blog) is seriously misleading.

    Well, I agree the title is misleading, but it only took me a cursory scan of the full post to understand it was for TopLink only.

    And since the "FUD" is at the end of the post, you had to have seen all the TopLink references first before you reached it.

    Storm in a tea cup, IMO.
    Kit
  29. see the home page[ Go to top ]

    - but even I think that this article (not the blog) is seriously misleading.
    Well, I agree the title is misleading, but it only took me a cursory scan of the full post to understand it was for TopLink only. And since the "FUD" is at the end of the post, you had to have seen all the TopLink references first before you reached it.Storm in a tea cup, IMO.Kit

    Sorry to be so pedantic, but I am not talking about the full post. The problem as I see it is that many readers will simply skim the articles posted here for news, opinions and current trends in Java.
  30. see the home page[ Go to top ]

    - but even I think that this article (not the blog) is seriously misleading.
    Well, I agree the title is misleading, but it only took me a cursory scan of the full post to understand it was for TopLink only. And since the "FUD" is at the end of the post, you had to have seen all the TopLink references first before you reached it.Storm in a tea cup, IMO.Kit
    Sorry to be so pedantic, but I am not talking about the full post. The problem as I see it is that many readers will simply skim the articles posted here for news, opinions and current trends in Java.

    And sorry to be unclear. By "full post" I meant the full article posted here, as opposed to it's title, or the original blog.

    Do people skim to such an extent? You may be right of course, but I can only go by my experience. I skimmed (skam, skum?) and came out with the impression it was Toplink only. No doubt others have experienced differently. Note to editors: There is a reciprocal relationship between the levels of care needed to edit a post and read it.

    Kit
  31. see the home page[ Go to top ]

    So true!
  32. Using EJB 3.0 outside the container[ Go to top ]

    Note to Editors:

    Does Preston get a special prize for posting the 200,000th message on TSS? Bottle of champagne, free copy of IDEA, or maybe a year's free subscription to MSJ? :)

    And who were the top 10 posters of the previous 199,999?
  33. This article should have been titled "Using the Java Persistence API outside the container." JPA != EJB3; they are two separate specifications. TopLink, etc. is a JPA implementation, not an EJB3 implementation.

    Persistent objects are very important, but occasionally one needs to run some business logic on them. :) EJB3 handles the business logic; JPA handles the persistence.
  34. Using EJB 3.0 outside the container[ Go to top ]

    As Doug has already mentioned, he blogged this to help people who were using the TopLink EJB 3 preview that was based on an early, incomplete version of the spec which pre-dated the existence of the persistence.xml file.

    These steps are no longer necessary for the current TopLink EJB 3 implementation. The community edition, open source TopLink Essentials is the reference implementation for EJB 3 Java Persistence API and available through Glassfish. It reflects as best as possible the latest changes in the EJB 3 spec, which is nearing completion.

    The configuration of persistence entities is very simple and can be portably specified explicitly in the persistence.xml file.

    Alternatively, TopLink Essentials also supports auto-discovery of persistence entities both inside and outside the container (spec only mandates inside container auto-discovery).

    This confusion is one of the risks we took in providing preview implementations of an emerging specification. The valuable feedback we received exceeded the drawbacks.

    The TopLink Essentials EJB 3 Java Persistence API reference implementation is updated about once a week at GlassFish and reflects more recent versions of the spec.

    -Mike
  35. Using EJB 3.0 outside the container[ Go to top ]

    OK, so what I am getting from everyone here is that *everyone agrees* the problem that was so "potentially worrisome" is a problem that applied to exactly one early release implementation of the spec. And that everyone agrees that the "potentially worrisome" problem is hence potentially not really at all worrisome.

    So I will go back to being potentially not worried.

    I am of course left with a big question mark in my head about why there was something so "potentially worrisome" in the first place that called for a post on TSS, complete with handwringing about potential worries.

    But apparently it is all my fault. (Hey, I work for JBoss.)
  36. Mark Fleury[ Go to top ]

    Gavin,

    Before you joined JBoss you were a clean gentleman. But I've noticed that you've developed a lot of bile after you joined Mark Fleury. Is it a requirement at JBoss that you smoke some weeds every morning before you start work? Please don't listen to Mark. Smoking weeds is not good for you.

    J
  37. Another tangential message[ Go to top ]

    Since none of the messages in this thread are about TopLink, I don't posting a distantly related question: does anybody know if TopLink provides a replicated cache, and if so, how does it work?

    Thanks
    Guglielmo

    Enjoy the Fastest Known Reliable Multicast Protocol with Total Ordering

    .. or the World's First Pure-Java Terminal Driver
  38. Another tangential message[ Go to top ]

    does anybody know if TopLink provides a replicated cache, and if so, how does it work?

    TopLink has a cache coordinatation feature that when enabled will cause all committed changes to be propagated to other caches in a cluster. The changes are bundled as deltas and sent to all participating sessions via a pluggable transport. You can also configure it just to send eviction messages instead of the delta packets, depending upon the cluster access patterns and data modification rates. Note that this is not as much of a replicated cache as it is a coordinated cache, which is often more useful than shipping loads of data across the cluster to fill any number of caches with data that will never be read or accessed there.

    -Mike
  39. Another tangential message[ Go to top ]

    Guglielmo,

    TopLink's caching solution for clustered deployments is not based on cache replication. It instead offers a cache coordination approach where independent caches in each node are coordinated through change-set messages. These messages contain the delta from a transaction and their contents are configurable. The coordination can be configured per entity type to synchronize changes, synchronize changes and create new instances, invalidate instances in other caches, or do nothing.

    The goal of cache coordination is to allow the application to benefit from caching their entities across transactions, users, and application nodes where the performance benefit warrants. Highly volatile entity types may be best retrieved from the data source when needed.

    Any data read from the database requires some form concurrency protection to avoid corruption. The most common and recommended is optimistic locking. The TopLink cache's concurrency protection is based on the locking policy configured and underlying database, not on a mid-tier distributed lock manager. The goal is for cache coordination to minimize the potential for optimistic lock failures on cached entities in the least intrusive manor possible.

    If having a replicated data cache closer to the application is beneficial then solutions such as Oracle's TimesTen In-Memory database or similar mid-tier data caching technology can be incorporated into the architecture.

    I hope this answers your question. There is an active and open TopLink forum if you are interested in exploring TopLink's capabilities. For more general information including a documentation, examples, how-to's, and the software check out TopLink's main page on OTN.

    Cheers,

    Doug
  40. Another tangential message[ Go to top ]

    TopLink's caching solution for clustered deployments is not based on cache replication.

    Is this available in Toplink Essentials? Is there a publicly available resource comparing Toplink Essentials to other flavours of the product?
  41. Another tangential message[ Go to top ]

    Is this available in Toplink Essentials?

    The cache coordination capabilities are a value-add of the Oracle TopLink product. Essentials does however offer the full object caching with flexible cache policies by entity type as well as control over queries refreshing the cache.
    Is there a publicly available resource comparing Toplink Essentials to other flavours of the product?

    There is not one available publicly yet. This will be made available as Essentials approaches its spec compliant release.

    Doug
  42. Performance?[ Go to top ]

    The last time I used it (I think OPS 3.0 beta 2) it was very slow and used very much memory. For every request (to one of their demos, don't know which one) I made the CPU was spinning at 100% for several seconds. There were plans at that time to rewrite a major portion on code, but that experience made me think that maybe that xml-based approach just is not suitable to applications where you cannot cache the output of some pipelines. I then took a look on apache cocoon, but in the end I ended up using Spring (because the xml based approach was not sellable to my management, but that is another story...)

    How is the OPS 3.0 performance today (Average processing time and memory footprint per concurrent user of one of the more complex demos)?
  43. Performance?[ Go to top ]

    How did that happen? Pardon me, that was supposed to go under the OPS 3.0 news. Strange. Please ignore it.