[jdom-interest] Newbie: JDom-Test (Can this actually be run)
brett.mclaughlin at lutris.com
Thu Oct 5 16:26:16 PDT 2000
Richard Landon wrote:
> JAR consolidation.
> These are the JAR files that are bundled with the "lastest" JDOM milestone
> (what do we call it? I got the CVS code two days ago? Beta-5? Sorry if I am
> using the wrong release name for the milestone).
> I seem to need to have these JAR files in my classpath to execute the
> various jdom or jdom-contrib samples and test code
> (I'm also messing with the Java and XML book code samples)
You need jdom.jar and xerces.jar. The rest is used for XPath or other
> (I've dropped the junit.jar file from this list as we already have it tucked
> away into our test environment. I can probably drop the jdom-test.jar? and
> the collections.jar file since we using JDK 1.2.x?)
> I'll also suppose that I'll eventually need or want a different DOM XML
> parser jar (any recommendations other than xerces from Apache) and the SAX 2
> parser jar and of course JAXP API from Javasoft?. I'd like to put all of
No you won't - why? Xerces is the only open source parser effort still
ongoing. So you want xerces.jar, and don't want to change that. And no,
you don't need or want jaxp.jar from Sun, because it doesn't offer you
anything used or needed with JDOM.
> these into 1 JAR, but I'm not sure how or if I can do this by directly
> packaging these jar's into (say) a zip file, which I stick into the
> CLASSPATH (is this possible with JAR's: to insert multiple JARS and then
> somehow define an
> appropriate manifeast indicating what jar in the jar or zip contains what
> Java classes
> or am I dreaming?)
Why? That's a bad idea. You don't want one large jar for all your APIs
like servlet.jar, jms.jar, jndi.jar, and the rest (you shouldn't - if
you do, stop that ;-) ), so don't do the same here. It makes it
impossible to upgrade one component without upgrading the others.
> I've looked at the BeanMapper example in the jdom-contrib and want to
> simulate something
> akin to it for Entity EJB: we're using an MVC based EJB-centric design for
> our system.
> The idea being that we can return an XML document in a String as data when
> we dispatch
> the model change notification to the View (which exists within a JavaBean in
> the Web-Tier).
> I am dreaming, or just insane? I would appreciate any feed-back on the
> general design
> and approach (Really I would). I understand this is an XML not EJB forum,
> but hey, it's
> worth a shot? Here's a pointer to a discussion on XML and EJB that I'm
> pretty much modeling
> the approach after:
This is a bad idea, frankly. I've been on Floyd to dump that one, but it
is an open forum ;-) You don't want your EJBs returning XML; it exposes
your business layer in a way that makes no sense in a Java application.
Your servlet should talk RMI to th EJB layer - talking RMI to get back
XML is a huge performance hit that gains you nothing in an all Java
application. If your EJBs are returning XML to be used in presentation,
then you have coupled your business layer to the presentation layer,
which isn't good; if they are returning XML object graphs, then you are
spending tons of time decoding XML into Java for no purpose.
I've seen lots of people doing this lately, and its just bad design.
People are incredibly infatuated with XML, and using it way too much -
use RMI for Java to Java, that's what it's there for. Then build
presentation with your servlet. EJBs are business logic, not application
or presentation logic.
> Thanks for any pointers you may be willingly to provide.
> Regards, Rick Landon
> -----Original Message-----
> From: philip.nelson at omniresources.com
> [mailto:philip.nelson at omniresources.com]
> Sent: Thursday, October 05, 2000 12:51 PM
> To: jdom-interest at jdom.org
> Subject: RE: [jdom-interest] Newbie: JDom-Test (Can this actually be
> > I've recently download and built the beta-4 milestone of JDOM.
> > Is there a way to verify the build using the JDom-test package?
> > We also use JUNIT ourselves.
> No, this would not be possible because there is no snapshot of or even
> versions of test most cases for beta 4. Development of test cases for beta
> 5 is "mostly" through the top level classes and not at all into sub
> > Is there an easy way to consolidate all these JAR files?
> which ones?
> To control your jdom-interest membership:
> To control your jdom-interest membership:
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
More information about the jdom-interest