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,
JBoss Group, LLC.
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.
#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
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?
Neither JBoss.org (the open source project)
nor JBossGroup (the service company) has
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.
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.
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?
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.