13 Replies Latest reply: Apr 29, 2003 3:05 PM by PaulWard RSS

Let's Begin

Bill Burke Master

Rather than responding to JBoss J2EE compliance on The Server Side, JDJ, or other forums, we've decided to open up discussions on www.jboss.org so that the JBoss team can become aware of J2EE compliance issues immediately and you readers can have a central place to discuss JBoss J2EE compliance issues.

PLEASE ONLY TECHNICAL POSTS! Tell us how JBoss is non-compliant so that we can address the issues. Although we have done our best to follow the specifications religiously, there may be some ambiguities in the spec that you can help define.

Thanks for your help,

Bill Burke
Chief Architect
JBoss Group, LLC.

  • 1. Re: Let's Begin
    Fabiano C. de Oliveira Newbie

    JBoss implementation want to be complient with J2EE 1.4 ?
    Because I dont see any implementation of JSR 88. Is there a work in any JBoss version about this JSR ?

  • 2. Re: Let's Begin
    Nicholas Whitehead Novice

    Bill;
    According to a recent interview with Saletta,(http://www.openenterprisetrends.com/cgi-bin/page_display.cgi?193) the two JBoss failures in compliance (that he knows of) are as follows:

    1. javax.resource.cci.InteractionSpec fails to extend the interface java.io.Serializable.

    I figure if this is a serious issue, it will result in bugs when implementing an Interaction with an EIS instance, in which case it is easily fixable. If not, it must be a non-issue because if you ported your code from JBoss to BrandX, you would then be using BrandX implementation rather than JBoss's. I suppose there is also the chance that Saletta is plain wrong, but I don't even know what that package is for, and I cannot find any references to InteractionSpec in the JBoss portion of (an admitedly month old) archive of JBOSS-HEAD.

    2. Saletta also says additional methods [JBoss has implemented] in the Java Mail API lead to failures. That additional methods can cause errors seems a bit suspect to me. If they are additional, why would any certification test even call them ? Is Saletta saying that implementors may not implement additional methods beyond what's in the spec ? If so, I suppose we will all be stuck using the Sun RI.

    Can you clarify these issues ?

    Also, there was some grumbling about how Marc had said he was not going to rush to implement the web services portion of the spec, but the 3.2 release and its integrated Axis (JBoss.net) seem to have admirably achieved this at least as well as some certified products that also use Axis to achieve compliance.

    Cheers.

    //Nicholas

  • 3. Re: Let's Begin
    Juha Lindfors Master

    #1 has already been fixed, it was simple 1 line 1 minute fix of adding "implements Serializable". I cannot imagine why Mr. Saletta would even bring that kind of issue up in an interview like he did rather than just have somebody drop an email and point out an accidental omission. Either Saletta has serious lack of knowledge when it comes to Java technology or Sun is really desperate trying to get the de facto reference implementation certified.

    #2 i'd be curious to know what exactly are the issues with our implementation of javax.mail interfaces -- it is not like this is a critical piece of the platform and there would be any demand to differentiate the JBoss server from other J2EE servers by breaking the mail interface -- the idea in itself is ridiculous. Perhaps Mr. Saletta will reveal his issues with JBoss mail interfaces in his next interview -- we shall see.

    Web Services: there hasn't been a rush to implement Web Services because there has been very little demand for them. Obviously Dr. Jung and others make improvements to the web service support as they need them. But there's no point in implementing functionality that is just a result of Sun and other vendors jumping to a hype bandwagon of a competitors technology. It only goes to show that they've lost their ability to truly innovate the J2EE platform. But like you said, Web Services on JBoss are in good shape and will no doubt be standards compliant just like all other parts of JBoss implementation.

    Disclaimer: my views are my own and no one else's

  • 4. Re: Let's Begin
    Barry Andrews Newbie

    Hi,
    I just read in Software Development Times, "Sun charges that JBoss has been able to claim it's compliant without having to prove it by running the test suite, which had been required..." What is this test suite? Is this a test suite from Sun?


    thanks,

    Barry

  • 5. Re: Let's Begin
    Juha Lindfors Master

    yes, J2EE TCK

  • 6. Re: Let's Begin
    Barry Andrews Newbie

    And where can I download this test suite from? I searched at java.sun.com but could not find anything. They have a J2EE AVK, but I believe that is for certifying that your application will work on a fully compliant J2EE server.

    thanks,

    Barry

  • 7. Re: Let's Begin
    Juha Lindfors Master

    As far as I know, you still have to pay for it.

  • 8. Re: Let's Begin
    Barry Andrews Newbie

    Then if JBoss had this test suite, they could use it to find all the problems (if there are any), right? And this forum is not needed.



  • 9. Re: Let's Begin
    Ken Kachnowich Newbie

    Does JBoss.org have the certification tests (I thoughtI read
    somewhere that Sun did give a copy to JBoss)?

    If so, has it been run and could we see the results?

    Not sure how these tests work. Can you just keep running
    them and making fixes till you pass or do you only get one
    shot and then have to pay for an other test?

    Ken

  • 10. Re: Let's Begin
    Adrian Brock Master

    Neither JBoss.org (the open source project)
    nor JBossGroup (the service company) has
    the TCK.

    There are negotiations underway subject to
    an NDA (I am not privy to either) for JBossGroup
    to get the TCK.

    It is unlikely that the tests can be made public
    since they are the intellectual property of Sun.

    The tests can be run as many times
    as necessary. But it is rumoured they are
    difficult to use (some other containers have
    taken 6 months to pass them).

    Judging by my experience with JMX, the TCKs
    aren't that useful. The JMX RI has plenty
    of bugs and yet it passes the JMX TCK.

    The work cannot really start yet anyway since
    the TCK available is for j2ee1.4
    which will not be a finalised spec until the Summer.

    Regards,
    Adrian

  • 11. Re: Let's Begin
    Cristian Golumbovici Newbie

    Now I don't know what's in those tests, but somehow I'd assume that if anyone needed 6 months, it was to fix the problems with their J2EE implementation. Not just to get the thing deployed.

    Which would just be the point of why such a test is needed in the first place.

    And I don't know... please don't take it as a flame or anything, but the more I read through this forum, the more I get the idea that the JBoss group takes the J2EE specification as something between a mere suggestion and just a joke.

    There is a standard. You either implement it or you don't. And the moment it ends up in answers like "but I don't think anyone actually needs that part", or "but that would waste CPU cycles", the short answer is: you don't.

    If, as a purely hypothetical example, I were to implement a highly optimized Java implementation which no longer uses bytecode or an automated garbage collector (surely noone actually needs those, and besides it's much more efficient without them), the short story is: it's no longer Java at all. It may be useful, it may even be popular with some people, it may even end up giving Bea headaches... but nevertheless, Java it ain't.

    Same here. A J2EE implementation which ignores whichever parts of the J2EE spec noone felt like coding, isn't a J2EE implementation in the first place.

  • 12. Re: Let's Begin
    Adrian Brock Master

    Stop putting words in other peoples mouths.

    All I said was that I know of a number of
    bugs in the JMX RI, because
    I have been poking around validating our
    testsuite against the RI.
    They are in pretty obscure places.
    Should I implement those bugs?

    When I find important ones, I point them out.
    Sometimes they change the spec to match the RI,
    simply to not break backwards compatibility
    for people that relied on the buggy implementation.

    The j2ee TCK will help us in one sense.
    We'll have already implemented the bugs
    when they have to patch the spec in future. :-)

    Which is my main point. Who validates the TCK
    against the spec? At least our open source
    testsuite is available to everybody so they can
    point out where it does not match.

    Would you rather code to a standard that
    is maintained through a non-public TCK or
    a public spec?

    Regards,
    Adrian

  • 13. Re: Let's Begin
    PaulWard Newbie

    I'm a little lost here. I've been using the web services features Dr. Jung and others have added to the JBoss distribution for quite some time now (Seems like it's been at least 6 months since I started using it.)

    I've written software in Delphi, VB.net and C# for clients of our, JBoss-based, commercial solution and have had only a single problem with the JBoss side of the implementation. I'm not really going to go into the details, but it relates to how Apache Axis handles (or at least handled at the time, not sure if it's fixed now since I have a workaround) soap attachments in a non-standard manner.

    I just wanted to say that I am exceedingly pleased at the web service support that is in JBoss and wanted to know if there was some reason people seem to keep implying that there's no web service support in JBoss at all.

    On a completely different note, I absolutely despise the fact that every page on the new JBoss site requires flash. It would be very nice if there was some way to opt out of the flash content.