Some software suppliers are bundling external classes inside their propriety jars. A good, or should I say bad, example is ATG…..
JAXB conflict
With GlassFish Metro’s wsimport.sh script I generated Java interfaces and other supporting classes from a wsdl file. In a small test project it all worked like a charm.
Then I copied my code to an ATG project which needed my code. My testcase suddenly failed with a java.lang.NoSuchMethodError: javax.xml.bind.JAXBContext.newInstance(..
Ouch.
It took me some time to understand the problem. The problem is that the ATG das2007.1.jar contains a lot of external libraries. For instance Xerces or Xalan. However they changed the namespace to for instance atg.apache.xerces.. So conflicts are less likely.
But it also contains javax.xml.bind.JAXBContext. Grr this is JAXB 1 and my JAX-WS Metro stuff needs JAXB 2. Of course I can change the class-path order and I can do this in Eclipse, so my tests will work.
However ATG specification says that ATG-Required modules will be started up, in the order specified, before any modules started with ATG-Class-Path. So DAS will always be loaded before any custom jars according to the specification… I have not validated this yet, but I’m afraid that the specification is the way it works and thus my code will not work inside the Application container.
This will mean that this lovely solution will not work
And Spring, and CGLib, and Mozilla packages, and Sun packages and IBM BSF, Apache Commons etc etc?
IBM BSF? The Bean Scripting Framework got promoted to Jakarta in 2002 and for some time now it has an Apache namespace and not an IBM namespace. That is some old stuff in the das jar. This is taking “If it aint broke don’t fix it” to a new level.
And does anybody else find it funny that an ATG jar, especially the one containing Nucleus, contains Spring classes. Ok it is just the Spring AOP classes, but still. Nucleus and Spring IOC are birds of a feather. These are just some of the examples of some of the embedded classes.
Why bundle libraries?
I sort of understand that you want to control the versions of external libraries you need, but bundling them in stealth mode is bad practice in my opinion. Especially if you are a framework like ATG. Frameworks don’t live in a vacuum, they need extra custom code and thus clashes are likely. I rather see the jars and documentation for which library versions your product is tested.
I’m not really fluent in Ruby but Ruby’s require_gem with the version argument sounds like a nice feature.
KnobsLeversButtons 
The best way to include frameworks is to repackage them… For example, classes in org.springframework.* should be moved to atg.org.springframework.*.
In the past I’ve seen JiveSoftware doing this consistently, unfortunately ATG isn’t doing this and it’s very, very wrong. Every single occurence of such a problem should be, in my opinion, raised to them as a bug of serious priority.
I agree. Even internally they cannot get it right: They also bundle them in the assembler.jar!
See Bug ID: 144364
The JAXB classes used by runAssembler and found in home/lib/assembler.jar are incompatible with those shipped with DAS.
This is because runAssembler has been built to support J2EE 1.3 and so contains an older version of JAXB for XML parsing.
I also agree with you guys. I’m having lots of conflict problems with XML Parsers. I’m JAXB with oc4j which have also a xml parser. Fix that by removing the xml from oc4j. Now I also need xerces with has also some parsers. Again some more conflicts.
Why don’t just stick with theirs core business. Or at least they should do two packages. One just with core and another with third party libraries.
Another thing that is missing most the time is a list of libraries used and theirs versions. It’s not so difficult to specify them.