From: Werner Donné (werner.donne@re.be)
Date: Fri Jun 20 2003 - 05:32:02 PDT
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