Re: [xep-support] XEP class loading

From: Werner Donné (werner.donne@re.be)
Date: Fri Jun 20 2003 - 05:32:02 PDT

  • Next message: David Tolpin: "Re: [xep-support] XEP class loading"

    Ewan,

    You're welcome. This is, however, not a J2EE class loading issue. It is part
    of J2SE, meaning that, for example, even for the command-line this might be
    usefull. You could write:

    java -Dcom.renderx.xep.ROOT=$XEP -cp $XEP/lib/xep35_client.jar com.renderx.xep.XSLDriver $*

    If the manifest file also contains:
       Main-Class: com.renderx.xep.XSLDriver

    it would just be:

    java -Dcom.renderx.xep.ROOT=$XEP -jar $XEP/lib/xep35_client.jar $*

    But there are several drivers in XEP, so there is a problem of choice. Note that anyway
    all of this doesn't affect the current launch scripts at all. They continue to work.

    Werner.

    Thonger, Ewan wrote:
    > Werner,
    >
    > Thank you very much for the pointer. I've tried this and it would appear
    > that the cryptix-pgp.jar's MANIFEST.MF also needs to be modifed, as this jar
    > references classes within cryptix32.jar. I guess this is a J2EE class
    > loading issue, but I've attached the two manifest files I've used in case
    > anyone else encounters the same problem. Perhaps RenderX may want to
    > consider adding these manifest files to their future releases, given that it
    > would simplify the build process for customers wishing to deploy XEP within
    > EAR files. I can't see any drawbacks with their inclusion, anyhow.
    >
    > Many thanks,
    > Ewan.
    >
    > -----Original Message-----
    > From: Werner Donné [mailto:werner.donne@re.be]
    > Sent: Friday, June 20, 2003 9:59 AM
    > To: xep-support@renderx.com
    > Subject: Re: [xep-support] XEP class loading
    >
    >
    > Ewan,
    >
    > You are using the J2SE bundled optional package mechanism. Each jar file
    > should state its dependency on other packages in its manifest file with
    > the Class-Path property. If two jar files, for example, depend on the same
    > utility jar, then it is not enough that just one of them states this. It is
    > like that for security reasons.
    >
    > So, in fact the xep35_server.jar should list the other jars in its manifest
    > file. To establish this you could do an experiment in which you add such a
    > manifest file to the XEP jar. The real solution is, of course, that the
    > manifest file is in one the future releases of XEP.
    >
    > Regards,
    >
    > Werner.
    >
    > Thonger, Ewan wrote:
    >
    >>Hi,
    >>
    >>We're currently attempting to deploy XEP within a J2EE EAR file, but are
    >>having problems accessing classes located within the cryptix and xt JAR's
    >>from within the deployed EJB's. If we deploy cryptix32.jar,
    >>cryptix32-pgp.jar, xep35_server.jar, and xt.jar into the root of the EAR
    >>file, and list these in the MANIFEST.MF file of the deployed EJB, we
    >
    > should
    >
    >>be able to access XEP succesfully from within the EJB. Instead, we get the
    >>following error:
    >>
    >>java.lang.NoClassDefFoundError: cryptix/provider/Cryptix
    >> at com.renderx.xep.lib.Conf.checks(Conf.java:416)
    >> at com.renderx.xep.lib.Conf.init(Conf.java:162)
    >> at com.renderx.xep.Driver.init(Driver.java:29)
    >>...
    >>
    >>However, if we then copy cryptix32.jar, cryptix32-pgp.jar, and xt.jar into
    >>the Websphere 'lib' folder, effectively adding them to the global
    >
    > classpath,
    >
    >>the classes are found successfully.
    >>
    >>I realise this question may appear to belong on a Websphere mailing list,
    >>but I suspect this behaviour may be caused by the ClassLoader XEP uses to
    >>load the cryptix and xt JAR's. Is there anything peculiar about the way
    >
    > XEP
    >
    >>accesses classes within the Cryptix and/or xt JAR's? Incidentally, this
    >>behaviour is not occuring when we test within Websphere Application
    >>Developer, only when we deploy it to our Websphere installation on
    >
    > Solaris,
    >
    >>again leading me to believe this a ClassLoader issue.
    >>
    >>Thanks,
    >>Ewan.
    >>
    >>
    >>-----------------------------------------------------------------------
    >>Information in this email may be privileged, confidential and is
    >>intended exclusively for the addressee. The views expressed may
    >>not be official policy, but the personal views of the originator.
    >>If you have received it in error, please notify the sender by return
    >>e-mail and delete it from your system. You should not reproduce,
    >>distribute, store, retransmit, use or disclose its contents to anyone.
    >>
    >>Please note we reserve the right to monitor all e-mail
    >>communication through our internal and external networks.
    >>-----------------------------------------------------------------------
    >>
    >>-------------------
    >>(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    >>in the body of the message to majordomo@renderx.com from the address
    >>you are subscribed from.
    >>(*) By using the Service, you expressly agree to these Terms of Service
    >
    > http://www.renderx.com/tos.html
    >
    >>
    >
    >
    > ------------------------------------------------------------------------
    >
    > Manifest-Version: 1.0
    > Class-Path: cryptix32-pgp.jar cryptix32.jar xt.jar
    >
    >
    >
    > ------------------------------------------------------------------------
    >
    > Manifest-Version: 1.0
    > Class-Path: cryptix32.jar
    >

    -- 
    Werner Donné  --  Re BVBA
    Engelbeekstraat 8
    B-3300 Tienen
    tel: (+32) 486 425803	e-mail: werner.donne@re.be
    -------------------
    (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
    in the body of the message to majordomo@renderx.com from the address
    you are subscribed from.
    (*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/tos.html
    


    This archive was generated by hypermail 2.1.5 : Fri Jun 20 2003 - 05:34:57 PDT