J2EE 1.4 certified containers - weak cert?
It is my understanding that a "properly written" application packaged as an EAR should be deployable in any container that is certified.
I am having a problem with a J2EE 1.4-certified application server that is leaking class and logging visibility from the server to the app. Since the server uses log4j, xerces, and many apache commons jars that our apps also use (but different versions), it is not rare for classes to be called across the server/EAR boundary causing ClassDefNotFoundException because of version incompatibility. Also, if the app uses and initializes log4j, the application log picks up messages that the server issues and should be going to the server log.
Is this acceptable and common server behavior, or just a peculiarity of this particular server?
If not, how could the server have possibly passed J2EE 1.4 certification?
Is this an issue that would revoke an already granted J2EE 1.4 certification?
[958 byte] By [
bmellonia] at [2007-10-1 8:24:11]
HiThis forum is for discussing avk and portability issues of j2ee applications. Please post your question to appserver specific forum. ThanksSudipto
> I am having a problem with a J2EE 1.4-certified> application server that is leaking leaking ?:-)leaking what ?
This *is* a portability issue. And a critical one at that.
If the J2EE 1.4 cert allows some application servers to expose versions of frequently used library JARs to "portable EARs", then "write once deploy anywhere" cannot exist.
I am trying to find out whether that is the case, because I am using a very popular J2EE-certified server that is interfering with the library JARs of an application. The EARs don't interfere with each other, but server library JARs and logging are leaking into my app. This does not happen with other servers.
In reply to Maris,
The leaks are of two types:
1) The server uses very common open source library JARs (i.e.: log4j, many Apache commons, and other JARs). The server uses version "x" of the JARs, while the application uses version "y". The version "y" JARs are included in the EAR/WAR. Normal behavior would be for the server to always use its version "x" JARs, and the EAR its version "y" JARs. The actual behavior is that the server calls some classes from version "y" (located in the EAR) and/or the EAR calls some classes from version "x" (located in the server). Since the library versions are different, they don't always contain the same classes/methods and therefore you get ClassDefNotFoundException even though the class is present in the "correct" JAR.
2) This is probably a symptom of (1) and not an independent issue: Messages that normally go to the server log (i.e.: "server started", "application deployed" messages, etc) start going to the application log specified in the EAR's log4j.xml as soon as the application is deployed.
> I am trying to find out whether that is the case,
> because I am using a very popular J2EE-certified
> server
Is it JBoss ?
> that is interfering with the library JARs of
> an application. The EARs don't interfere with each
> other, but server library JARs and logging are
> leaking into my app. This does not happen with other
> servers.
Maybe it's better to use one of those servers that don't have this problem ?
Perhaps it's possible to solve it by changing some configuration.
http://www.jroller.com/page/fate/?anchor=toilet_fishing_with_jboss_4
There are some silver linings though. For one thing, JBoss 4.0 should serve as a great motivator for the Geronimo folks. It sets such a low bar that their goal actually seems attainable (as long as they avoid going after commercial vendors, who will wipe the floor with them). It's also an excellent advert for BEA, IBM, and pretty much all the other players in the field. People who start with JBoss will learn to appreciate professional products so much more (alright, well maybe not websphere, but anything else).
rofl... I am trying to be polite to the vendor until I find out whether they broke the rules or not, and since Sun certified them as J2EE 1.4 compliant the blame does not reside totally on this misguided vendor.
I'll just say that it "is" an open source product, that my EARs have to function unmodified on Weblogic, Websphere, Novell Extend, and on at least one open source vendor.
If you are familiar with the various products, you can figure out who the vendor is and look at the full bug report in the vendor site - bug ID = JBAS-1551 (yes, I know I am still not mentioning the vendor, and I ask you to do the same until after verifying that they broke the rules). The bug report includes test source code and EARs that can be used to verify this problem (or even whether the error is mine - in coding).
So, back to the question: What is the expectation of the J2EE 1.4 cert? Should my app have worked correctly or is the "leakage" not prohibited by J2EE 1.4?
> If you are familiar with the various products, you
> can figure out who the vendor is and look at the full
Yes,I figured it out.I guessed right.
:-)
> So, back to the question: What is the expectation of
> the J2EE 1.4 cert? Should my app have worked
> correctly or is the "leakage" not prohibited by J2EE
> 1.4?
It's not prohibited.Because such details as classloader behaviour is not mentioned in J2EE spec.
Maris
> Is this acceptable and common server behavior, or
> just a peculiarity of this particular server?
No.
> If not, how could the server have possibly passed
> J2EE 1.4 certification?
But J2EE certification doesnt check such things.
Just look at J2EE spec. and you will see that it doesnt say a word about whether an application server should create a classloader for every ear, or not.
Hani was right:
I'm sure we're all highly impressed that the fleury clan actually managed to get compliance for J2EE 1.4. When I heard the news, I naively and foolishly thought that their incompetent days are now over. This is the dawn of a new era in the dirty incestuous little family's sordid history.
...
For anyone having high expectations of JBoss 4.0, time to put them away. It's the same old ****, just 9 times the size, half the speed (well, twice the slowness, to be accurate), 3 times the incompetence, and an order of magnitude more hype. Calling this 'professional' open source can only be a very very sick joke, or the most filthy example of doublespeak yet this year.
:-)
> rofl... I am trying to be polite to the vendor why should we be polite ?Are you familiar with this famous quote of Mr. Marc ? http://sourceforge.net/mailarchive/message.php?msg_id=1313852
Thank you for all the insight. Sorry about slow reply... watchlist seems broken.
On the one hand, I must say I am disappointed at Sun for allowing a certification that does not ensure portability. It defeats the whole point of using Java!!!
On the other hand, I am going to have to find another open-source J2EE container that we can recommend to our cash-poor customers. Ideally, one that has EAR isolation and even better if it allows redistribution of the software. Any suggestions would be greatly welcome.
> On the one hand, I must say I am disappointed at Sun
> for allowing a certification that does not ensure
> portability. It defeats the whole point of using
> Java!!!
No one certification test is able to find out every problem, that a server may have.
> On the other hand, I am going to have to find another
> open-source J2EE container that we can recommend to
> our cash-poor customers. Ideally, one that has EAR
> isolation and even better if it allows redistribution
> of the software. Any suggestions would be greatly
> welcome.
SUN has a free J2EE server. AFAIK from my experience, it's quite nice.
I had a J2EE1.3 problem with a popular app server. We were using an MDB with a 3rd party JMS messaging vendor. This app server decided its MDB would nly work it's own messaging, and any 3rd party JMS implementation would not work with it's MDB. I saw this as a clear violation of certification, yet the app server was j2ee certified. Not to mention quickly switching App servers to one that honored standard JMS messaging and had the same common sense we had.
BTW it was fixed on J2EE1.4. A year and a half is a long time to wait to implement a use case. But needless to say all the (j2ee non-standard) web service stuff was there that hardly anyone was using. So the market was the motivation for skipping the smaller market share J2EE standards, I guess.
"but the main problem with common sense is that it is not as common as people think it is"
So maybe that is why part of the AVK is testing on the reference implementation.
