On Fri, 2002-08-16 at 14:11, David Jencks wrote:
> On 2002.08.16 05:13:25 -0400 Marius Kotsbak wrote:
> > What will scoped ears be replaced with in jboss 3.2? I heard that
> > scoping will not be used in 3.2.
>
> Where did you hear this? AFAIK it is a permanent feature. There is no
> reliable way to load two versions of the same class otherwise.
>From Scott Stark (possibly in a bug comment).
>
> >
> > We have used it in 3.0 and found some limitations (I can detail this if
> > it isn't clear).
>
> Please detail the problems.
A.jar(scoped): com.mycomp.Beanclass1(version 0.5) impl. intfI
B.jar(scoped): com.mycomp.Beanclass1(version 1.0) impl. infI
C.jar com.mycomp.CallerBean need to call a interface that both
Beanclass1 in both A and B, and there can be only one of this (it
process incoming messages and dispatch them to the right bean). When it
is placed in one of A or B, it can't call the other because it is loaded
with another classloader. It can't be placed outside, because the beans
does't implement infI when loaded in another classloader. Would this
problem be solved if intfI is placed in C.jar and not in A or B?
>If there are bugs, have they been fixed in
> later versions?
No bugs now AFAIK, after I have reported and got fixed 2 bugs.
>
> Our preferred solution is, I think, to have the
> > classloader first look in the jar the bean is placed in, and if it
> > doesn't find it there, look in the global scope, including other
> > jars/ears. This will solve our problems, and remove the need for scoped
> > ears.
>
> Possibly for your particular application, but not in general.
>
> If your app has packages A and B, with classes in A referring to classes in
> B, and you wish to deploy 2 versions of this app (A1 B1 and A2 B2), with
> your scheme there is no way to determine if A1 should get classes from B1
> or B2. Scoping is required so A1,B1 is invisible to A2,B2 and vice versa
Then scoping should be supported as well as the solution I described. In
my case, scoping is really not required, but I have to use it because of
the lame search for classes, which gives us unneeded complexity of
deployment.
>
> david jencks
>
> >
> > --
> > Marius Kotsbak
> > Boost Communications A/S
> > Trondheim, Norway
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone? Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-user
> >
> >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
--
Marius Kotsbak
Boost Communications A/S
Trondheim, Norway
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
