BEA Workshop Studio 3.1 released: Now with WTP and EJB/JPA.

Discussions

News: BEA Workshop Studio 3.1 released: Now with WTP and EJB/JPA.

  1. BEA has recently released BEA Workshop Studio 3.1. The primary change in this release is updating the Studio product so it leverages the Eclipse Web Tools Project 1.0.2. This release supports the final specification of EJB3 Persistence (aka JPA). Full support is provided for BEA Kodo 4.0. For more information, see the release notes. You can download it from the download site with a free 15-day trial. The license for BEA Workshop Studio is $899 USD.

    Threaded Messages (23)

  2. Features ???[ Go to top ]

    Did I miss something or does this thing not support NetUI and Controls????
  3. two different workshops from BEA[ Go to top ]

    BEA Workshop is the former eclipse M7 toolset. WebLogic Workshop is the toolset go for NetUI and the control framework that is being standardized as part of the Apache Beehive project. There will be a unified Workshop soon, so this confusion from this name "overloading" will go no longer be an issue. hth, jr
  4. Re: two different workshops from BEA[ Go to top ]

    I thought that pollinate had been retired. Do you work for bea?
  5. Pollinate[ Go to top ]

    I thought that pollinate had been retired. Do you work for bea?
    I do. We did retire pollinate. We will be delivering support for Beehive in the Workshop for WebLogic release, coming up later this year. You can still access the beta at: http://wlp.bea.com/ br
  6. two different workshops from BEA[ Go to top ]

    John has got it exactly right. When we acquired M7 we acquired a separate code line. Our team is now working on integrating the two code lines. This, as you can imagine, is not a "cut and paste" activity. However, we are working on bringing the two lines together as soon as is practicably possible. Bill Roth VP, BEA Workshop BEA Systems.
  7. what about The old codebase?!!!!![ Go to top ]

    Do u intend to donate the old code base to the apache software foundation :-) it is really a good idea to mentain it(if u want and if u own the code IP)
  8. There will be a unified Workshop soon, so this confusion from this name "overloading" will go no longer be an issue.
    It seems to be the only OO feature that the framework supports. (Framework name overloading). That's great! Almost it support some kind.
  9. So JDO2 is killed?[ Go to top ]

    Hi. Now EJB 3 is within the Kodo 4 release and only JDO 1.x. Is it possible to get some credible statement from BEA, Neelan or Patric about JDO2? I mean - really - *any* believeable statement would do. Please tell me if its time to leave the BEA Kodo product or not? Is JPOX the way to go or are there any reason to go Kodo? Johan Strandler
  10. Re: So JDO2 is killed?[ Go to top ]

    Hi.

    Now EJB 3 is within the Kodo 4 release and only JDO 1.x.
    Where did you get the idea that Kodo 4 contains only JDO 1.x? Kodo 4.0.0 implements both EJB 3.0/JPA and JDO 2.0.
  11. Re: So JDO2 is killed?[ Go to top ]

    Where did you get the idea that Kodo 4 contains only JDO 1.x?

    Kodo 4.0.0 implements both EJB 3.0/JPA and JDO 2.0.
    Just from reading the Kodo 4.0 product sheet from BEA: http://www.bea.com/content/news_events/white_papers/BEA_Kodo_ds.pdf Cheers, Johan
  12. Re: So JDO2 is killed?[ Go to top ]

    Where did you get the idea that Kodo 4 contains only JDO 1.x?

    Kodo 4.0.0 implements both EJB 3.0/JPA and JDO 2.0.


    Just from reading the Kodo 4.0 product sheet from BEA:

    http://www.bea.com/content/news_events/white_papers/BEA_Kodo_ds.pdf

    Cheers,
    Johan
    Ah, well it is wrong :) Kodo 4 has full JDO 2.0 support - check out all the JDO features in the documentation: If you look at 'Read BEA Kodo 4.0 Documentation' then 'JDO API Reference', you will see the JDO 2.0 API. Looks like someone at BEA needs to sort out their documentation! They have been working hard to support JDO 2.0, and have no plans to drop it as far as I know.
  13. Re: So JDO2 is killed?[ Go to top ]

    Hi again. Well, indeed, I certainly know Kodo is *implementing* JDO 2.0. What I am utterly concerned about is the *market* *message* about JDO 2.0 from BEA. Current market message tells me more about if the Kodo product owner BEA will maintain and continue to develop the JDO path or if it is trying to squeece it out of the product line and put it in legacy mode. I build systems with a *long* lifecycle, so I'm really more concerned about the market message than the current state of the product Cheers, Johan
  14. JDO2 is alive[ Go to top ]

    Hi again.

    Well, indeed, I certainly know Kodo is *implementing* JDO 2.0. What I am utterly concerned about is the *market* *message* about JDO 2.0 from BEA.

    Current market message tells me more about if the Kodo product owner BEA will maintain and continue to develop the JDO path or if it is trying to squeece it out of the product line and put it in legacy mode. I build systems with a *long* lifecycle, so I'm really more concerned about the market message than the current state of the product

    Cheers,
    Johan
    Personally, I have seen no marketing message from BEA that indicates anything other than long-term support for JDO (why otherwise would such effort have been put into JDO 2.0 compliance?). Kodo/JDO has a long history and a strong user base. I also build long-life systems, and I am using JDO 2.0. The marketing message seems clear to me... to quote from an interview with Neelan Choski in February: "Right now, the focus is on supporting the JDO 2 specification and the EJB 3 Persistence specification and offering customers interoperability between the two specs." I don't see how it can be any clearer.
  15. Re: JDO2 is alive[ Go to top ]

    So why is the product sheet very clear to provide EJB 3 and JDO 1.0.2 then? /Johan
  16. Re: JDO2 is alive[ Go to top ]

    So why is the product sheet very clear to provide EJB 3 and JDO 1.0.2 then?

    /Johan
    All I can think it that it is a simple mistake. There is no point in them having spent a condiderable amount of time and effort producing a high-quality JDO 2.0 implementation (which they have), and then stating JDO 1.0.2 on the product sheet. All the other documentation is clear - the JDO 2.0 API is certainly available. I agree this is confusing. Perhaps someone from Solarmetric/BEA could clear this up?
  17. Re: So JDO2 is killed?[ Go to top ]

    Just a another comment about market messages: I'm certainly not into Hibernate, where the product management gives an air of pure arrogance. That really doesn't make it feel safe to invest in that product for a long lifecycle dependency into our product. Furthermore, EJB 3 is not very impressing as a specification, and still breath the EJB crippled specification decease that haunted J2EE for years making even .NET looking as a more future stable approach except for the OS platform independence. I guess were back to the dark DAO days again. Sigh... Cheers, Johan
  18. Re: So JDO2 is killed?[ Go to top ]

    Just a another comment about market messages: I'm certainly not into Hibernate, where the product management gives an air of pure arrogance. That really doesn't make it feel safe to invest in that product for a long lifecycle dependency into our product.

    Furthermore, EJB 3 is not very impressing as a specification, and still breath the EJB crippled specification decease that haunted J2EE for years making even .NET looking as a more future stable approach except for the OS platform independence.

    I guess were back to the dark DAO days again. Sigh...

    Cheers,
    Johan
    So why not use JDO 2.0? There is a good open source implementation (JPOX), and there are commercial vendors providing implementations (BEA, Xcalia). I also strongly suspect that the current limitations of JPA will become an issue and the next version of JPA will be an improvement. I would hardly call .NET a stable approach - it is a single vendor product that runs on a single platform.
  19. Re: So JDO2 is killed?[ Go to top ]

    So why not use JDO 2.0? There is a good open source implementation (JPOX), and there are commercial vendors providing implementations (BEA, Xcalia).
    We do use Kodo. What I want is a quick and firm statement from BEA to say that JDO2 is a path forward. Otherwise I have to prepare for some ugly DAO wrapping of JDO as a strategic way forward - but I would prefer some lifesigns from BEA instead. JPOX might be an option though, provided BEA continues to keep it's mouth shut about their JDO future...
    I would hardly call .NET a stable approach - it is a single vendor product that runs on a single platform.
    Well, I wouldn't say that with regard to EJB persistence track record, which has been worst in class all the time. Single platform, well that is true for sure :-) I have worked with with EJB's for high-transaction volume systems since december 1998. Nowdays I want to use a lot from the Java EE stack like transaction manager, etc - but EJB is a firm no-no. For anyone wondering, we use JBI (ServiceMix), Spring for DI and AOP and POJO persistence through Kodo JDO. No EJB, No SCA (EJB-NextGen-standard-by-committee-disaster? ;-), No SDO.
  20. Re: So JDO2 is killed?[ Go to top ]

    We do use Kodo. What I want is a quick and firm statement from BEA to say that JDO2 is a path forward. Otherwise I have to prepare for some ugly DAO wrapping of JDO as a strategic way forward - but I would prefer some lifesigns from BEA instead.
    Well, I can't speak for BEA, but I can't see what can be firmer than (1) having actually implemented the JDO 2.0 spec, and (2) the statements on their Kodo 4.0 FAQ: "JDO will continue to play an important role in Java persistence for the forseeable future." and "Since EJB3 and JDO can exist side by side in BEA Kodo, both technologies will continue to be supported." I realise that there may be an explanation for the mention of JDO 1.0.2 in their product spec - although they have implemented the JDO 2.0 API, they may not have actually put the results through the TCK yet, so aren't able to officially declare JDO 2.0 support right now.
    JPOX might be an option though, provided BEA continues to keep it's mouth shut about their JDO future...
    From the above statements, I believe they have been pretty clear about a continued future for JDO. Also, there are other JDO products - I have heard very good things about Xcalia (who are also to release a JDO 2.0 implementation).
  21. Re: So JDO2 is killed?[ Go to top ]

    Where did you get the idea that Kodo 4 contains only JDO 1.x?

    Kodo 4.0.0 implements both EJB 3.0/JPA and JDO 2.0.


    Just from reading the Kodo 4.0 product sheet from BEA:

    http://www.bea.com/content/news_events/white_papers/BEA_Kodo_ds.pdf

    Cheers,
    Johan
    Great ! Kodo 4 has been a JDO2 preview for 1 year and now... BEA really made a great job. Indeed. The only thing I can think is that it acquired Solarmetric to get a great OR mapping technology and, last but not least, to stop JDO. The last news I read from BEA about JDO was rather pathetic. They first said that Kodo 4 final release was waiting for JPA final spec, then they said that JDO2 compliance was delayed because the spec was much more complicated than JPA. Well, this is an insult to intelligence. AKAIK Solarmetric/BEA was in JSR243, Kodo 4 has had JDO2 preview features for 1 year, and now they say that JDO2 compliance is delayed. Anyway, nothing wrong with it. It is a precise strategy for survival. JDO was getting too powerful, allowing the development of really serious applications without EJB. And container vendors cannot bear it. Guido
  22. Re: So JDO2 is killed?[ Go to top ]

    Where did you get the idea that Kodo 4 contains only JDO 1.x?

    Kodo 4.0.0 implements both EJB 3.0/JPA and JDO 2.0.


    Just from reading the Kodo 4.0 product sheet from BEA:

    http://www.bea.com/content/news_events/white_papers/BEA_Kodo_ds.pdf

    Cheers,
    Johan

    Great !
    Kodo 4 has been a JDO2 preview for 1 year and now...
    BEA really made a great job. Indeed.
    The only thing I can think is that it acquired Solarmetric to
    get a great OR mapping technology and, last but not least, to stop JDO.
    The last news I read from BEA about JDO was rather pathetic. They first said that Kodo 4 final release was waiting for JPA final spec, then they said that JDO2 compliance was delayed because the spec was much more complicated than JPA.
    Well, this is an insult to intelligence.
    AKAIK Solarmetric/BEA was in JSR243, Kodo 4 has had JDO2 preview features for 1 year, and now they say that JDO2 compliance is delayed.
    Anyway, nothing wrong with it. It is a precise strategy for survival.
    JDO was getting too powerful, allowing the development of really serious applications without EJB.
    And container vendors cannot bear it.

    Guido
    This is nothing but FUD. Kodo 4.0 implements JDO 2.0. Compliance is not delayed. They provide full documentation on their site for use of JDO 2.0 with Kodo right now.
  23. Re: So JDO2 is killed?[ Go to top ]

    This is nothing but FUD. Kodo 4.0 implements JDO 2.0. Compliance is not delayed. They provide full documentation on their site for use of JDO 2.0 with Kodo right now.
    No Steve, I am sorry. For what concerns the motivations behind Kodo 4 release delay that are opinions. The other stuff are here http://weblog.infoworld.com/techwatch/archives/005738.html and here http://www.theserverside.com/news/thread.tss?thread_id=40496#208982 Guido
  24. Re: So JDO2 is killed?[ Go to top ]

    This is nothing but FUD. Kodo 4.0 implements JDO 2.0. Compliance is not delayed. They provide full documentation on their site for use of JDO 2.0 with Kodo right now.

    No Steve, I am sorry.
    For what concerns the motivations behind Kodo 4 release delay that are opinions.
    The other stuff are here
    http://weblog.infoworld.com/techwatch/archives/005738.html
    and here
    http://www.theserverside.com/news/thread.tss?thread_id=40496#208982

    Guido
    Nothing about lack of JDO 2.0 support, and no lack of committment to JDO 2.0, only that it has taken longer to implement than JPA, because it is a more complex and richer API. I am using JDO 2.0 via Kodo 4 right now.