Discussions

News: JOnAS 3.3 Released

  1. JOnAS 3.3 Released (19 messages)

    JOnAS 3.3 has been released. This is the last major release before JOnAS 4 (full J2EE 1.4 support) which is expected at the very beginning of next year. JOnAS 3.3 already provides some J2EE 1.4 features such as Web Services deployment and EJB 2.1 Timer Service early implementation.

    JOnAS 3.3 also supports JDO by integrating the ObjectWeb SPEEDO JDO implementation, and provides Certificate based authentication with corresponding JAAS loginModule. JOnAS 3.3 provides a JDBC resource adapter (J2EE Connector) for integrating JDBC drivers, enabling Prepared Statements pooling. The new Management console (JonasAdmin) is also now complete and integrates Tomcat management.

    New Feature List

    - Web Services (endpoints and client) deployment support has been added, conforming to J2EE 1.4; a WebServices JOnAS service is provided for this purpose, on top of AXIS
    - Integration of a JDBC Resource Adapter (J2EE Connector Architecture compliant), that may replace the JOnAS DBM service for integrating JDBC drivers, it provides PreparedStatements pooling
    - First JDO support by integrating the open source JDO implementation from ObjectWeb, SPEEDO (0.9.7.5), and its associated J2EE resource adapter; an example using JDO is provided
    - First Timer Service integration (EJB 2.1 API)
    - The EJB 2.0 CMP, implemented on top of JORM/MEDOR, has been enhanced to support some missing EJB-QL statements (ORDER BY, IS EMPTY, IS NOT EMPTY, CONCAT, MEMBER OF)
    - The JonasAdmin new management GUI is now complete, integrating Tomcat management, it now replaces Jadmin
    - New security features: JAAS realm for Tomcat and Jetty, authentication with client certificate, CRLLoginModule login module for certificate revocation
    - Support of exploded ear files
    - The size of Client.jar has been reduced
    - A new version of PetStore is integrated (with Web Services)
    - Enhanced documentation
    - New versions of CAROL (1.5.5), JORAM (3.6.2), JORM (2.1), MEDOR (1.2.6), Monolog (1.6.3), Javamail (1.3.1), Xerces (2.5.0).

    Visit the JOnAS Home page

    See the Release Notes

    Threaded Messages (19)

  2. JOnAS 3.3 Released[ Go to top ]

    Sounds pretty cool. Now, how hard is it to migrate a project from JBoss to Jonas? We have all the xdoclet tags for jboss, but I'm not sure about xdoclet support for jonas.

    Thanks,
  3. XDoclet et JOnAS[ Go to top ]

    I work with XDoclet and JOnAS since one year and i have no prb.. JonAS is really great and very well supported by XDoclet !

    take a look at my sample project with JOnAS and XDoclet :
    http://www.ashita-studio.com/articles/joffad_sampleproject/index.html

    You can download the sample project at http://joffad.sf.net

    PS : JOFFAD is a generic development framework for JOnAS and XDoclet
  4. JDO and JOnAS[ Go to top ]

    So, another J2EE App Server is bundling JDO. When will the commercial vendors catch on?
  5. XDoclet et JOnAS[ Go to top ]

    Thanks for JOFFAD, Traumat. I believe it can help me build ent. applications quicker with JOnAS. IMHO JOnAS is more attractive compared to JBoss, expecially for me, comming for a Weblogic background. I have worked with JBoss, it's hot deployment/automatic stub-skeleton generation was very attractive.So I tried deploying some applications with it. At the very beginning my CMP applications were not performing well. Only later I found out that JBoss by default uses commit option B and I have to make changes to the deployment descriptor for it to use commit option A. This and many other features are not well documented, I believe it is explained well in the 'payed' documentation though. I don't mind these guys charging for the 'professional services' and all. But when we refer to a software product, the product documentation is also part of it, when they say their product is open source, the documentation should be too.
  6. I agree with you... JOnAS, unlike JBoss, i think play the real game... no ideas hidden behind :)

    If you are interested in JOFFAD, send me an email ( you can find my email on JOFFAD web site ) and i will send u our new documentation with better schemas and the current relase of JOFFAD we are working on. We made it much more simplier and more documented ! and we also add Unit testing wich is one of the best thing i ever seen.

    You should also take a look at our "brother" project ejosa.sf.net
  7. SUN1 AS 7[ Go to top ]

    BTW Sun One application server platform edition is for free too (even production) and it is fully documented. But it is not open sourced. Question is, how often do you need it.
  8. SUN1 not open source[ Go to top ]

    Yep SUN One AS is not open source...

    WIch means less support, less bug corrections, less active community, less control and more vendor lockin :)

    BGesides, if you want to make a cluster, you have to pay.. it's not what i call "free" :D
  9. SUN1 not open source[ Go to top ]

    Yep SUN One AS is not open source...

    >
    > WIch means less support, less bug corrections, less active community, less control and more vendor lockin :)
    >
    > BGesides, if you want to make a cluster, you have to pay.. it's not what i call "free" :D

    Open-source doesn't equate to "better support" as your original message makes out. Just because there may be more people working on something in a public formum doesn't mean that they can provide better support for a customer's problems. More people who know less about a subject doesn't help! Give me a good service level agreement with guaranteed delivery and response times any day, especially if my application is critical and I needed that fix yesterday!

    I'm not saying that open source doesn't have its place, or that commercial (even if they are free) implementations are inherently better. But let's try to be even handed here. The only guarantee I get from open source is that I can see the source! Everything else, such as support contracts etc. has to be added on top just as it does with a commercial venture.
  10. Support and open source[ Go to top ]

    Support in commercial product :
    - you pay we help you
    - if you find a big bug, u wait for next patch (it could take months)
    - the product doesn't fit you, never mind

    Support in open source product
    - we help you
    - if you want full support, you pay and we will help you more
    - if you find a bug, we will correct it and publish a patch or u can correct it urself
    - if the product doesn't fit you, modify it !

    This is why OS support is better than the commercial one.
  11. Support and open source[ Go to top ]

    Support in commercial product :

    > - you pay we help you
    > - if you find a big bug, u wait for next patch (it could take months)
    > - the product doesn't fit you, never mind

    Let's take this one step at a time.

    I buy a product and I want support because it's an important piece of software to me. So yes, I'm happy to pay for 24x7 support if there's a decent SLA (which gives me guaranteed response times, categories of faults, a person who I can talk to etc.) If I'm running a banking system, for example, and am looking to leverage an app. server, then I'd expect a very good SLA or I walk!

    What the SLA now gives me is a guarantee (backed up by my lawyers if necessary) that bugs I report will be looked at within certain time frames. I've already settled on those time frames when I signed up, so I'm happy with them - they suite me. Many companies tailor SLAs to their individual client's needs.

    The SLA will also define when I can expect patches. For critical things, I wouldn't sign if it said "months". What's the point?

    And if I've bought some software it had better "fit" in the first place! What is this? A shoe-shop where I buy without trying? Doh!

    BTW, all of the above is just as applicable if I take an open-source (free) implementation. There's nothing inherently commercial about an SLA.

    >
    > Support in open source product
    > - we help you

    You help me when? Suppose I get a critical failure on Christmas Day that *must* (no alternative) be fixed within that day or I lose money and therefore you lose a customer? You might say that you can do this, but where's your guarantee? How can I trust that you'll be there 24x7 just waiting on the off-chance that a failure happens? What if your network connection goes down? Where's your backup and hence my backup strategy?

    For a lot of people this sort of thing can't be left to "best effort" or "best intentions". This is irrespective of whether it's a commercial venture or open-source.

    > - if you want full support, you pay and we will help you more

    OK, so now where's your SLA (and my guarantees) and how is this different to what I said in my first email? This is the crux of my point: don't just say that because it's open-source there's necessarily better support than from a company. That's just not the case.

    > - if you find a bug, we will correct it and publish a patch or u can correct it urself

    Only if I know what's going on. If I don't then I'm back to relying on people I don't know and don't have guarantees from.

    > - if the product doesn't fit you, modify it !
    >

    See above. You're being extremely overly simplistic.

    > This is why OS support is better than the commercial one.

    A very sweeping statement. So go on then, give me the evidence that backs that one up ;-)

    Mark.
  12. SUN1 not open source[ Go to top ]

    Mark,

    You are in some ways correct, having service agreement is nice. And it sounds good. Except in my experience, it hasn't worked out that way.

    My experience has been that Open Source really *does* have better support for the most part. With a traditional company, you call, log a support request (which you do pay for, but that's OK). A *support engineer* calls you back within 24 hours (or depending on your agreement). Then they work out the problem and get back to you, somtimes never. The support engineers are a hit-or-miss thing sometimes in terms of knowledge and experience.

    While I have no formal open-source support agreement, I find that I get better support, more quickly. For example, I have standardized all J2EE projects on Object/Relational bridge for persistence. When I have a problem with it I post to the mail list. Everyone sees it. So anyone who already knows the answer can respond. I don't have to wait for a "Support Engineer" to spend a lot of time looking for it.

    Further, I often get responses from the people who actually wrote the software and know it thoroughly (Thomas Mahler, Armin Waibel, Jakob Braeuchi). I also usually get a complete response within a couple of hours. I (and everyone else) gets to watch the "support" thread throughout its whole life. Anyone can go back through the thread. It's not internal, inaccessible information once the support has been rendered.

    So my experience (and not just with OJB) has been that the open-source model is faster, more responsive, and more available to users. This certainly hasn't been the case all the time. Some companies are awesome. And some companies are using the open-source model to do support anyway. We use Atlassian Jira, and their support has been great! I think a large part of that is because they do it through email list like most open-source projects. They're quick and helpful. Yeah. But I know some of those guys do tons of open-source anyway (Open Symphony I think).

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  13. SUN1 not open source[ Go to top ]

    My experience has been that Open Source really *does* have better support for the most part. With a traditional company, you call, log a support request (which you do pay for, but that's OK). A *support engineer* calls you back within 24 hours (or depending on your agreement). Then they work out the problem and get back to you, somtimes never. The support engineers are a hit-or-miss thing sometimes in terms of knowledge and experience.

    >
    > While I have no formal open-source support agreement, I find that I get better support, more quickly. For example, I have standardized all J2EE projects on Object/Relational bridge for persistence. When I have a problem with it I post to the mail list. Everyone sees it. So anyone who already knows the answer can respond. I don't have to wait for a "Support Engineer" to spend a lot of time looking for it.
    >
    > Further, I often get responses from the people who actually wrote the software and know it thoroughly (Thomas Mahler, Armin Waibel, Jakob Braeuchi). I also usually get a complete response within a couple of hours. I (and everyone else) gets to watch the "support" thread throughout its whole life. Anyone can go back through the thread. It's not internal, inaccessible information once the support has been rendered.
    >
    > So my experience (and not just with OJB) has been that the open-source model is faster, more responsive, and more available to users. This certainly hasn't been the case all the time. Some companies are awesome. And some companies are using the open-source model to do support anyway. We use Atlassian Jira, and their support has been great! I think a large part of that is because they do it through email list like most open-source projects. They're quick and helpful. Yeah. But I know some of those guys do tons of open-source anyway (Open Symphony I think).
    >

    Jason, I don't know which companies you're referring to, but I can certainly attest to having had similar poor experiences from *some* companies. However, with any good SLA we've never had any problems.

    The problem I have with anything that doesn't come with a good support agreement/organisation (and that goes for commercial as well as open source) is that you don't have any guarantees. Take your example: what if those guys are ill, off on holiday, getting married, ..? Bang goes your critical update!

    OK you may have someone else who's perhaps not as well versed in the intricacies of the software produce a "fix", but has it been fully QA-ed, regression tested etc? All of these things go to giving customers a nice "fuzzy" feeling about using software, whatever the source.

    Mark.
  14. SUN1 not open source[ Go to top ]

    Mark,

    In some ways I think we're both a bit right here. Sure there are plenty of crumby open-source projects on sourceforge that don't do regression testing. But the good ones (ObjectWeb, Apache's various things, OpenSymphony, whatever) all do.

    More importantly, if you're looking for guarantee in business or software engineering, I think you should join the divinity. There's just no such thing. That's because most SLA's say basically that *they* decide if it's a bug or not. And they decide if it's gonna get fixed. This hasn't happened often to me, but it has happened enough that I don't put too much faith in those things.

    Also, that Holiday analogy probably applies more to proprietary software than it does to open-source. With open-source, at least someone else can take a whack at it. I myself wrote plugins allowing Tangosol and OSCache to work woth OJB when I found that there were serious problems with JCache's distributed-caching. In fact, someone on the list wanted to use OSCache, and the lead guys didn't have time to do it. So I did it. I'm not a committer on that project, but I did it anyway. That type of support, communication among customers, and collaboration just isn't usually possible in proprietary models.

    And really, that fuzzy feeling is often a false sense of security. I don't want my software to feel good, I want it to be good. And yes, you're right, there are good propreitary companies, and bad open-source companies. Above all, choose the right tool for the job. But I think the open-source model beats proprietary for support, and that's why some companies are moving that way.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering
  15. SUN1 not open source[ Go to top ]

    More importantly, if you're looking for guarantee in business or software engineering, I think you should join the divinity. There's just no such thing. That's because most SLA's say basically that *they* decide if it's a bug or not. And they decide if it's gonna get fixed. This hasn't happened often to me, but it has happened enough that I don't put too much faith in those things.

    >

    I suppose it depends who you talk to. My experiences are pretty much the opposite: good support from commercial ventures based on good SLAs and poor support from open source. There are exceptions to every rule of course.

    > Also, that Holiday analogy probably applies more to proprietary software than it does to open-source.

    I disagree, but I suspect we'll have to agree to disagree.

    > With open-source, at least someone else can take a whack at it.

    I'd prefer someone to fix it properly than take a "whack" at it.

    > I myself wrote plugins allowing Tangosol and OSCache to work woth OJB when I found that there were serious problems with JCache's distributed-caching. In fact, someone on the list wanted to use OSCache, and the lead guys didn't have time to do it. So I did it. I'm not a committer on that project, but I did it anyway. That type of support, communication among customers, and collaboration just isn't usually possible in proprietary models.
    >

    There are advantages to open source for some things like your example. But it's wrong to give the impression that this is the route for most people. To do what you did requires skills and knowledge that most people just don't have. They can't rely on "doing it themselves" and hence have to rely on others. And then we're back to square one: our experiences of this are opposites, so maybe that just goes to show you can't please everyone all of the time :-)

    > And really, that fuzzy feeling is often a false sense of security. I don't want my software to feel good, I want it to be good.

    Absolutely. There's no substitute for good software. But there will always be bugs and not all of them are easy to find and resolve. So a good support organisation is necessary, rather than an ad hoc approach which doesn't help anyone in the long run.

    > And yes, you're right, there are good propreitary companies, and bad open-source companies. Above all, choose the right tool for the job. But I think the open-source model beats proprietary for support, and that's why some companies are moving that way.
    >

    Do you have any empirical data to back that up? I'd be interested to see some. My point has not been commercial support is better than open-source support, or vice versa. The point has been that a good support organisation with SLAs (or whatever guarantees) is required to backup software, wherever it comes from. I know for certain that critical industries like banking, insurance, air-traffic control, telecoms etc. won't touch software (commercial or open source) without a specific support organisation to talk to. Just saying "Oh, just sent an email to the discussion group and someone will pick it up" ain't going to cut it!

    Mark.
  16. Support you say?![ Go to top ]

    I just had to do this:

    http://www.theregister.co.uk/content/30/33318.html
  17. RE: SUN1 not open source[ Go to top ]

    WIch means less support, less bug corrections, less active community, less control and more vendor lockin :)


    yes; ispecially with some small open source team, which just started and has zero experience

    >>> BGesides, if you want to make a cluster, you have to pay.. it's not what i call "free" :D

    yes; you are right; i call "free" if i have to pay for JBoss documentation
  18. EJOSA and JOFFAD[ Go to top ]

    Also check EJOSA (Enhydra And JOnAS Application) for some examples of using different kind of business layer implementations within JOnAS:
    - Business Layer: SSB - EB 1.1, SSB - EB 2.0, SSB - Hibernate.
      We are adding SSB - DODS and SSB - JDO as well.
    - Presentation Layer: Swing, Enhydra SuperServlet - XMLC.
      We hope to add Struts - JSP as well with the help from JOFFAD as Stephane and
      me think to put more works together, to make JOFFAD and EJOSA compatible.

    EJOSA also includes the JOnAS Alarm example in a better seperate structure: Specification, Business, Presentation, Application.

    For a very BIG application, which uses EJOSA Template check out: http://www.openuss.org (also Open Source: http://openuss.sourceforge.net).

    The KISS software development process of using EJOSA Template is now online:
    http://ejosa.sourceforge.net/ejosa-images/ejosa-template-process-matrix.jpg

    Docu:
    http://prdownloads.sourceforge.net/ejosa/ejosa1.3.5-doc.pdf?download

    Thanks,
    Lofi.
  19. JOnAS 3.3 Released[ Go to top ]

    First, the new management tool seems quite good. So far, I've been configuring Jonas directly editing properties-files, but now it'll be easier to recommend Jonas 3.3 to my colleagues and to production use.
    Jonas has been ready for production (in some cases) for some time, but I'm sure that IT departments that administer Jonas servers will find it easier to use new web-based tool.
    Overall, my first impression of Jonas 3.3 release is very positive. Keep up good work, Jonas team.

    Sami Lehtinen
  20. ObjectWeb and Apache Licence[ Go to top ]

    Interesting discussion about Changing License of ObjectWeb Components (LGPL) with Apache Licence (BSD) in conjunction with Geronimo Projects can be read from:

    http://www.objectweb.org/wws/arc/jonas/2003-10/msg00089.html

    If JOnAS

    1) uses Apache Style Licence
    2) certified by Sun thanks to the Sun's scholarship

    would this means that JOnAS will be "de-facto" standard of J2EE application server just like Apache HTTP Server and Tomcat Web Container?

    A very interesting stuff to discuss!

    Peace,
    Lofi.
    http://www.openuss.org