No,
JBoss doesn't support the relative ejb-links yet.
I've got a patch (uncommitted) that nearly fixes this, but it doesn't work with njar.
For it to work with njar, I would need to add
parseURL support to the stream handler.
I saw mention on this list that njar was being dropped,
so I haven't d
> There's an example in spec (EJB2.0 - 20.3.2) with
> the
> following relative
>
> ../products/product.jar#ProductEJB
>
> Does your patch still deploy product.jar?
>
> Regards,
> Adrian
That's a new one on me. No, my patch would not allow this to deploy. (Nor would it
allow your applicati
Ehm, does this example deploy without the patch? I think that finding a
relative container from a module is not implemented in current CVS HEAD.
I have org.jboss.test.naming.test.EjbLinkUnitTestCase failing :-(
Claudio
---
Hi,
> Here is an example
> of what I restricted:
> [code]
> foo.jar <- deployed
> +- temp (directory)
> | +- bar.jar (used to be deployed, but no
> o longer)
> +- sub.jar (still deployed)
> +- junk (directory)
> | +- stuff.jar (used to be deployed, but no
> no longer)
> +-
Jencks [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 11, 2002 7:10 PM
> To: Vesco Claudio
> Cc: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Exploded archive deployment
>
> How about making this step in MainDeployer/SubDeployer mutually recursive?
> so SubDeployer
1.sar
> jboss-ejb.jar
> jboss-service2.sar
> ...
>
>
> My bad English have hit another time?
>
> Claudio
>
> > -----Original Message-
> > From: David Jencks [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, April
day, April 11, 2002 2:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Exploded archive deployment
>
> OK. I haven't looked yet but am a little worried about a couple of
> things,
> although maybe I misinterpreted your comments-
>
> 1. indefinitely ne
Yeah, my comments weren't the best. I suck at coming up with concise, descriptive
comments. Anyway:
> 1. indefinitely nested deployments are useful and
> used. I don't see any
> reason to restrict the depth. The spec requires jar
> in rar in ear.
This is of course still allowed. Here is an
OK. I haven't looked yet but am a little worried about a couple of things,
although maybe I misinterpreted your comments-
1. indefinitely nested deployments are useful and used. I don't see any
reason to restrict the depth. The spec requires jar in rar in ear.
2. As I recall deploymentInfo had
I just submitted a bunch of patches to allow archives (sar,rar,jar,war and ear) to be
deployed in their exploded form. Could someone with CVS write permissions look them
over?
http://sourceforge.net/tracker/index.php?func=detail&aid=542341&group_id=22866&atid=376687
Thanks
__
10 matches
Mail list logo
