Hi,
I though I could make a manifest file like this:
------
Manifest-Version: 1.0
Created-By: 1.3.0 (jboss rules)
Class-Path: /home/toppk/src/
----
and run:
jar -c0vfm server/jboss/deploy/myejb.jar files/mymanifest \
-C src/myejb META-INF/ejb-jar.xml \
-C src/myejb META-INF/jboss.xml
And put that in myejb.jar so it' would just have the .xml files.
I'm I wrong, that this isn't supported?
Hopefully yes, or something. I kinda thought this would be slick.
Kenneth Topp
On Wed, 16 Aug 2000, Rickard [iso-8859-1] �berg wrote:
> Hi!
>
> Sebastien Alborini wrote:
> > > I placed the archive (parser.jar) which contains those
> > > classes in the lib/ext directory (maybe that's wrong
> > > from the beginning) and jBoss adds the archive to the
> > > classpath at startup (or looks like).
> >
> > This is wrong. Jboss and your beans won't share the same classloader, so
> > it's no use giving the jar to jboss.
> >
> > Your beans can only access the classes which are in the
> > <jboss>/deploy/your_app.jar file. You must put all you need in here.
>
> WHOA! Stop right there! Sorry, but this is wrong. Classloader
> delegation. The classloader used to load the EJB's use the server
> classloader as parent, so EJB's can indeed use any class in /lib/ext.
>
> Furthermore, any libraries that do EJB-restricted operations, such as
> reading files and creating threads, MUST be in /lib/ext (or whereever,
> just not in the EJB-jar). Fransisco is doing this absolutely correct.
>
> The problem is something else. Do you have the possibility of putting a
> try/catch(e.printStackTrace) around the operation that fails? That
> should give more info on what goes wrong.
>
> /Rickard
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
