BEA: What have you done to Kodo?

Discussions

News: BEA: What have you done to Kodo?

  1. BEA: What have you done to Kodo? (27 messages)

    Marc Logemann, in "Sad state of Kodo after the merger," says that the "quality of support drastically decreased since the merger." He points out that issue reports have been lost, user accounts have been misplaced, and features are missing or in error. It's unfortunate to see user complaints like this: BEA, what now? Mr. Logemann suggests that he might go to JPA after his experiences with Kodo 4.0 after Solarmetric's acquisition. One might be able to assume he doesn't mean transitioning to OpenJPA (BEA's JPA portion of Kodo), if Kodo itself is indeed suffering from lack of support or incorrectly implemented features. After Mr. Logemann posted the blog entry, Patrick Linskey posted comments detailing how to escalate issues within BEA as well as pointing out available documentation - and following up with "Anyone with similar issues with BEA support should feel free to contact me." This is excellent, and Patrick's dedication is admirable. However, it's better to not have a problem to manage than manage a problem well. One would hope such issues wouldn't exist in the first place. What are your experiences with Kodo after the acquisition? Has BEA managed the transition well? What do you think BEA's next action should be?

    Threaded Messages (27)

  2. KODO and Data Service(Liquid Data)[ Go to top ]

    How is BEA gonna "mess up" with KODO? :-) My real question: How does BEA align KODO with other products, like Data Service, which supports SDO and OR data mapping/modeling as well. Thanks, Rick
  3. Weblogic is not the only product of BEA[ Go to top ]

    I first heared of weblogic,then I knew it's a product of weblogic.Recently the Weblogic's market share on JAVA application decreases beaxuse most developers swith to websphere. So bBE wants to boost their other products. The first step is to buy NitroX.them is KODO. I think BEA will buy more products. http://www.filig.com
  4. How do you know that Weblogic's market share on JAVA application decreases and that most developers switch to websphere? Does it come from your imagination or do you have access to some market studies report?
  5. Bruno, I think websphere passed weblogic back in 2003 (see this story from TSS) And this story is from Gartner in 2005. The market share data doesn't seem to be at the application server level, but the text indicates that IBM is still the leader there. No telling what the report says about the impact of open source on the app server market. IBM does however have websphere app server community edition and they offer support options for Apache Geronimo, so that should help IBM maintain their relative share in the market.
  6. Typical for BEA[ Go to top ]

    Today BEA is a bunch of scared representatives, salesmen and quasi-tecnician. They are SCARED. It's so sad.
  7. Re: Typical for BEA[ Go to top ]

    As a BEA customer, and BEA sales representative facing architect I do not feel the same. Can you elaborate ?? if you don't this kind of comment is a nonsense! By the way, how does this fit with the kodo subject ? Stephan
  8. Re: Typical for BEA[ Go to top ]

    Today BEA is a bunch of scared representatives, salesmen

    and quasi-tecnician.

    They are SCARED.

    It's so sad.
    Have you actually used any part of the weblogic platform? I guess you have not worked on serious production sites where performance, stability and throughput are major issues.
  9. Marc Logemann wrote QUOTE: last word on that Posted by: Marc Logemann on August 23, 2006 in response to Message #216287 I just want to point out that its more about the support quality than about Kodo itself. If i would have major problems with kodo, i would have switched but i still like Kodo and the way it works. Of course over the time i also have created some valuable skillset with kodo which i dont want to miss. IMO there are not many products (if any at all) that let me switch JPA/JDO operation modes so easily. Marc Logemann http://www.logemann.org As you might imagine, we at BEA have been following this dialogue very closely. In addition to contacting Marc Logemann directly, I’d like to respond directly to the issues he raised in his blog and reiterated in the post above. As detailed above, Mark’s concern is not with the viability or quality of the Kodo product, but with the support he’s gotten for it from BEA. The bottom line is this: somewhere along the line we in BEA Support dropped the ball on Marc and did not live up to the expectations he had from us. For that I’d like to apologize to Marc. Thanks, Marc, also--for bringing our attention (and my attention, personally) to an area of our customer support where we have been unwittingly lacking. Namely, in communicating with our developer community via newsgroups. Part of that is our former lack of presence in this forum and the others like it. This issue has been a topic of discussion at BEA today not because we’re “running scared”, but because it caught us unexpectedly. We set the bar very high for our support at BEA, and we’ve prided ourselves in our great reputation for that. That isn’t hype or marketing-speak, but something we’ve earned by listening to and working closely with our customers. On top of that, we are now realizing we need to offer you all a bit more transparency, so you are aware of the status of Kodo at BEA, our commitment to it, and the efforts we are currently expending to support it properly. Naturally, any new product acquisition has a learning curve associated with it, both for new customers learning BEA’s support procedures, and for us in learning how our new customers want that information conveyed. We realize we should have done a better job of familiarizing long-time Kodo users like Marc with our support programs and the processes we have in place for customers to raise and escalate concerns and get issue resolution. Such concerns are always reviewed jointly between Kodo Engineering and Support to ensure that both technical and process issues are addressed. It is also true that our level of Support expertise for Kodo does not yet match the expertise of the original Kodo engineers, but it is something to which we have already been actively dedicating resources. We’ve been focusing so carefully on bringing our internal Kodo teams up to speed, in fact, that we realize we may have neglected to communicate that to the entire Dev community. I’d like to amend that in part by sharing with you now some of the commitments BEA is making to Kodo: a. There are more BEA Support engineers assigned to Kodo (and currently coming up to speed) than the size of the entire original SolarMetric engineering team prior to acquisition. b. We have Kodo Support engineers training in all regions worldwide. This enables us to provide business hour support including phone support in EMEA and APAC as well as in the Americas. c. We are able to provide 24x7 Production Support, another first for Kodo customers. Previous SolarMetric support was email-only and on a 12x5 basis (10 AM – 10 PM EST). d. As for BEA’s next actions: we have been focusing the expertise of the Kodo Engineers less on support and more on product development: This year, the BEA Kodo team delivered a major release for EJB3 (Kodo 4.0) and released that technology to the open source community via Open JPA. We are also nearing the release for JDO2 (Kodo 4.1). e. We are continuing to add staff and conduct additional trainings in preparation for these future releases of Kodo. Our resource commitment to Kodo support and development is very strong. Rapid development and release of up-to-date technology is a major benefit for Kodo customers, new and old, and we are in the process of building a strong and lasting infrastructure to provide Kodo with BEA’s customary level of comprehensive support. I hope this provides some insight into the questions raised here. You can be sure everything that has been said in this discussion will impact BEA’s future communications with Kodo users. You can also expect us to be a more active participant in these and similar forums, so that we might prevent valued customers like Marc from feeling frustrated at not getting the answers they need for a product they so clearly value. Like Patrick Linskey, I want to encourage you to contact me if you have concerns about the support you are receiving from BEA. Thank you again for your valuable feedback and for offering us the opportunity to adapt better to your needs. Terry Clearkin SVP, WW Support BEA Systems
  10. Support to Kodo customers[ Go to top ]

    Thanks Terry for your (and BEA's) support committment. But Marc, is not the only one. As existing Kodo customer we felt as if BEA has disowned us which is not desired impact of any merger unless the merger had some hidden intentions. Our developers cannot login as customers and download latest versions of 3.x for which we had licenses from Solarmetric. I do not want to get into JDO Vs. anyother other competing technology comparison as I believe every technology has its strengths & limitations. But in any case customers should be the only focus for any business to SUSTAIN. Hope corrective & preventive actions will be taken soon.
  11. Oh, 24x7 live support is great! But I would take Solarmetric's original 12x5 email support ANY TIME. On the positive side, Patrick's 4.1 post is a very good news and we can certainly trust Abe's assurance that the product is still alive and evolving :-) Alex Roytman Long term Kodo customer :-)
  12. First, I want to state that the summary of this thread is misleading. Marc has valid complaints about support and migration. He does not, however, complain about missing or wrong features as the summary implies. He points out that he has reported a bug with sequence holes that has been handled badly. While that is inexcusable, it is not equivalent to an overall decline in the quality of Kodo, nor does Marc make such a claim. Additionally, I believe that Marc was referring to BEA's OpenJPA when he spoke of switching to JPA in the mid term, contrary to TSS's claim (hence the "perhaps this is exactly what BEA wants" in his post). I'm not sure why TSS felt the need to put negative words in Marc's mouth, especially given that Kodo powers their site. It is unfortunate that Marc has had problems, because he's a valued Kodo customer who has contributed suggestions that have improved the product. All I can say is that while there are growing pains, as a Kodo developer, I'm more excited than ever about its future. In the short term, things are a little rough around the edges. Many things are happening almost simultaneously: - Integrating with BEA's processes and teams. - Transitioning to Kodo 4.0. - Implementing JPA 1.0 and JDO 2.0. - Open-sourcing most of the Kodo 4.0 kernel and JPA bindings as OpenJPA. In the long term, though, we have expanded development resources and a great open source core. The future is bright. For now, projects that start with Kodo 4.0 or migrate from a fairly "vanilla" 3.x app shouldn't notice the rough patches much. But Kodo 3.x users with lots of custom mappings and query extensions and so forth -- like Marc -- will certainly have a harder time in this period of transition. For example, as Marc points out, the distributed Javadoc on extension points is limited in the 4.0 release (not to be confused with our user guide, which is very complete... to the tune of 600 pages). This is actually by design, as the packages of many internal classes will change when Kodo becomes a layer on top of OpenJPA in 4.1. We only supplied Javadoc for the primary interfaces that will have backwards-compatible equivalents moving forward. With 4.1, not just the Javadoc, but the code itself for all extension points will be readily available in OpenJPA (in fact, it is available now). To summarize: Marc has valid complaints about the way his support issues have been handled, and we're working to improve in this area. But as a primary developer, I can say with confidence that the quality of the Kodo product is as high as ever. Moreover, the resources that BEA provides will only serve to improve Kodo over time. Finally, with the upcoming 4.1 release, Kodo will be a layer on top of the OpenJPA (a robust and fast JPA implementation in its own right), so users will not only have extensive API docs, but the code itself.
  13. I only hope BEA won't end-up re-writing this product, to fit into the rest of their stack, in couple of years down the road. If one gets to know what must be done to migrate Weblogic Integration Server 6.x/7.x implementations to Weblogic Integration Platform 8.x or higher, my comment could make some sense.
  14. I only hope BEA won't end-up re-writing this product, to fit into the rest of their stack, in couple of years down the road.
    I doubt this will happen, as much of it is being released as open source - as OpenJPA (why not the JDO 2.0 implementation as well?)
  15. Weblogic was a neat little product before it became BEA Weblogic. Tuxedo was still nice the last time I looked, but I think BEA has had the good sense to leave that alone. No one is buying into their BEA Workshop rubbish and they are really scared as one poster already mentioned. IMO the Java feeding frenzy is over. And no one is going to be fooled by JSF this time round. BEA seems more exposed then the others (IBM, Sun, Oracle etc). So when EJB3.0 turns out to be a commercial failure what for BEA then? Personally I won't miss BEA, as long as someone salvages Tuxedo before they go bust! Paul.
  16. br>IMO the Java feeding frenzy is over. And no one is going to be fooled by JSF this time round.
    This is nothing to do with JSF. Kodo is a JDO/JPA product.
  17. br>IMO the Java feeding frenzy is over. And no one is going to be fooled by JSF this time round.


    This is nothing to do with JSF. Kodo is a JDO/JPA product.
    No, but it has got a lot to do with BEA. BEA as a company have bought their way into the Java development space. First by buying Weblogic (way back in around 97 I believe) and now Kodo amongst others I believe. As a company their focus is on pseudo consultancy and sales. They tend to sell to management and "strategy" types rather then direct to developers and in my experience Weblogic was a better product before they got their hands on it. They have also tried to sell some home grown products that have been "wizard like" in nature which haven't taken off. I'm sure that they are probably looking to sell a JSF wizard too. BEA and I go way back, Paul.
  18. Re: BEA: What have you done to Kodo?[ Go to top ]

    in my experience Weblogic was a better product before they got their hands on it.
    In what way? Exactly what is it that you dislike about WebLogic 9.x as opposed to Tengah? Give us some specifics. I'll tell you one thing I like about BEA WebLogic and that's JRockit. Damn good JVM even if they did name it after a type of lettuce. One thing I don't like is their JMS implementation and the way it can silently lose persistent messages if the database runs out of space. (Not sure if they've fixed this one in 9.x or not.) I've never used JDO so I can offer no opinion on that as to whether BEA have improved it or made it worse.
  19. Re: BEA: What have you done to Kodo?[ Go to top ]

    in my experience Weblogic was a better product before they got their hands on it.


    In what way? Exactly what is it that you dislike about WebLogic 9.x as opposed to Tengah? Give us some specifics.

    I'll tell you one thing I like about BEA WebLogic and that's JRockit. Damn good JVM even if they did name it after a type of lettuce. One thing I don't like is their JMS implementation and the way it can silently lose persistent messages if the database runs out of space. (Not sure if they've fixed this one in 9.x or not.)

    I've never used JDO so I can offer no opinion on that as to whether BEA have improved it or made it worse.
    It's been a looong time since BEA got their hands on Weblogic. Up to weblogic 4.5 I think, it was a simple clean tool which felt like it was written by developers for developers. The weblogic console was a decent desktop app that gave loads of useful info, and you could configure the server using a simple property file and restart your server in secounds. Then XML hell kicked in. It wasn't too bad at first. An XML equilvalent to the old property file (5.x?), but By 6.1/6.2 we had the dreaded config.xml file. If you've ever tried to edit this file by hand you know what I'm talking about. And if you get it wrong the server will not start, so no console. All of a sudden you needed to worry about admin server/managed server config etc, even though you were doing standalone development. At the same time we got the slow and clunky web console. Why get rid of the desktop app? It was much more user friendly and informative. By now feature bloat had kicked in too. Since then I've dreaded having to use Weblogic, although it is still the way I make a lot of my money as a Consultant. It is clearly a marketing driven product these days, with loads of features. JRockit is a good JVM by all accounts, but that doesn't help me develop software quickly. I'm using Weblogic 8.1 at present and it takes a good 5 minutes to startup the server. My ant build takes a good 7 minutes to compile, package and deploy the app, so I spend most of my time building and deploying to Weblogic. This situation is not all weblogic's fault, but the feature bloat over the years hasn't help. Paul.


  20. It's been a looong time since BEA got their hands on Weblogic. Up to weblogic 4.5 I think, it was a simple clean tool which felt like it was written by developers for developers. The weblogic console was a decent desktop app that gave loads of useful info, and you could configure the server using a simple property file and restart your server in secounds.

    Then XML hell kicked in. It wasn't too bad at first. An XML equilvalent to the old property file (5.x?), but By 6.1/6.2 we had the dreaded config.xml file.

    If you've ever tried to edit this file by hand you know what I'm talking about. And if you get it wrong the server will not start, so no console. All of a sudden you needed to worry about admin server/managed server config etc, even though you were doing standalone development.

    At the same time we got the slow and clunky web console. Why get rid of the desktop app? It was much more user friendly and informative.

    By now feature bloat had kicked in too. Since then I've dreaded having to use Weblogic, although it is still the way I make a lot of my money as a Consultant. It is clearly a marketing driven product these days, with loads of features. JRockit is a good JVM by all accounts, but that doesn't help me develop software quickly.

    I'm using Weblogic 8.1 at present and it takes a good 5 minutes to startup the server. My ant build takes a good 7 minutes to compile, package and deploy the app, so I spend most of my time building and deploying to Weblogic.

    This situation is not all weblogic's fault, but the feature bloat over the years hasn't help.

    Paul.
    Ever tried Websphere? At least with WebLogic and config.xml you've got a CHANCE of doing it by hand. With WebSphere and the enormous repository (which is some kind of hierarchical database or something... possibly written by Martians) there's approximately a 0.1% chance of hand editing configuration and having the server start up. Oh, and if it's messed up? You get to re-install. Which takes like 4 hours. Unless you have a custom install that needs to set up resources for your development, which you most likely will, so that can make it a whole-day process to get WebSphere re-installed. That was back with the 5.x line... Maybe 6.0 is better, but I doubt it. I haven't had to touch either WebLogic or WebSphere in the last couple of years, and it's been nice to have more control and not be waiting for things to start up for 5 minutes at a time.
  21. This is a repost from BEA forum. It is not a critique to anyone, just my reading of the events. It is my feeling, nothing more, nothing less. And I will be happy to eat my words if the future will be different. I have been a happy Solarmetric KODO customer and I still preserve a mail from Neelan Choksi asking support for JDO2 approval. And KODO 4, NOW, is not JDO2 compliant yet. I think that JDO, and KODO was the best implementation IMHO, was too usable in a J2SE env to be acceptable by container vendors. Guido. P.S. I think that KODO will never get JDO2 compliance. It is against BEA goals.
  22. I think that KODO will never get JDO2 compliance. It is against BEA goals.
    FTR, Kodo 4.1 is (or rather, soon will be) JDO2-compliant. The goals of 4.1 are JDO2 compliance, OpenJPA switchover, and more BEA / WLS integration. -Patrick -- Patrick Linskey http://bea.com
  23. I think that KODO will never get JDO2 compliance. It is against BEA goals.


    FTR, Kodo 4.1 is (or rather, soon will be) JDO2-compliant. The goals of 4.1 are JDO2 compliance, OpenJPA switchover, and more BEA / WLS integration.

    -Patrick

    --
    Patrick Linskey
    http://bea.com
    As I said, I will be happy to eat my words (this means that I can use and promote KODO again). We will see, even if I already wrote the same things few months ago. Guido
  24. last word on that[ Go to top ]

    I just want to point out that its more about the support quality than about Kodo itself. If i would have major problems with kodo, i would have switched but i still like Kodo and the way it works. Of course over the time i also have created some valuable skillset with kodo which i dont want to miss. IMO there are not many products (if any at all) that let me switch JPA/JDO operation modes so easily. Marc Logemann http://www.logemann.org
  25. switch to JPA[ Go to top ]

    Forgot one thing. Yes. Abe is correct. I meant OpenJPA and not a different implementation. As i said. I am still convinced regarding kodos product quality. Perhaps my blog title is misleading but the content shouldnt be. Marc http://www.logemann.org
  26. Kodo 4.1[ Go to top ]

    The goals of 4.1 are JDO2 compliance, OpenJPA switchover, and more BEA / WLS integration.

    -Patrick

    --
    Patrick Linskey
    http://bea.com
    Now this is good news! :-) Personally I haven't got the feeling of when JDO2 was to go final in Kodo. From the BEA website, this information has not been so visible, but I could have missed it if it already was there. Initially we went for JDO2 one year ago but going with the "shadowed" JDO2 implementaion of Kodo 3.x. However we really want to use the offiical API as soon as possible. When is Kodo 4.1 scheduled for release? Cheers, Johan Strandler Chief Architect OMX Market Technology, Banks & Brokers http://www.omxgroup.com
  27. Re: Kodo 4.1[ Go to top ]

    The goals of 4.1 are JDO2 compliance, OpenJPA switchover, and more BEA / WLS integration.

    -Patrick

    --
    Patrick Linskey
    http://bea.com


    Now this is good news! :-)

    Personally I haven't got the feeling of when JDO2 was to go final in Kodo. From the BEA website, this information has not been so visible, but I could have missed it if it already was there.

    Initially we went for JDO2 one year ago but going with the "shadowed" JDO2 implementaion of Kodo 3.x. However we really want to use the offiical API as soon as possible.

    When is Kodo 4.1 scheduled for release?

    Cheers,
    Johan Strandler
    Chief Architect
    OMX Market Technology, Banks & Brokers
    http://www.omxgroup.com
    I would hope that Kodo 4.1 would have better support for some popular databases. Kodo 4.0.0 only supported Postgres 7.2.1 (yes, that old!). It seems a little misleading to advertise support for PostgreSQL and then only support a version that is so old that virtually no current OS distribution supports it. Even Debian stable is up to Postgres 7.4.7.
  28. Re: Kodo 4.1[ Go to top ]

    The goals of 4.1 are JDO2 compliance, OpenJPA switchover, and more BEA / WLS integration.

    -Patrick

    --
    Patrick Linskey
    http://bea.com


    Now this is good news! :-)

    Personally I haven't got the feeling of when JDO2 was to go final in Kodo. From the BEA website, this information has not been so visible, but I could have missed it if it already was there.

    Initially we went for JDO2 one year ago but going with the "shadowed" JDO2 implementaion of Kodo 3.x. However we really want to use the offiical API as soon as possible.

    When is Kodo 4.1 scheduled for release?

    Cheers,
    Johan Strandler
    Chief Architect
    OMX Market Technology, Banks & Brokers
    http://www.omxgroup.com
    I would hope that Kodo 4.1 would have better support for some popular databases. Kodo 4.0.0 only supported Postgres 7.2.1 (yes, that old!). It seems a little misleading to advertise support for PostgreSQL and then only support a version that is so old that virtually no current OS distribution supports it. Even Debian stable is up to Postgres 7.4.7.