-
1. Re: Classloader Domain scoping
starksm64 Feb 8, 2004 9:28 AM (in response to bill.burke)The ClassLoaderDomain cannot be a contract required at the ClassLoader imiplementation level as this is too restrictive on the ClassLoader choice. This should be a contract coming in at the LoaderRepository, and could be supported by adding the class loader domain as a property in the JMX object name of the LoaderRepository. A domain is also likely to have multiple ClassLoaders associated with it.
-
2. Re: Classloader Domain scoping
rythos Feb 8, 2004 12:20 PM (in response to bill.burke)So for some versions of the class being loaded the advice applies, and for others it doesn't? I don't have much "real world" experience, can you give an example where such a thing would be useful?
-
3. Re: Classloader Domain scoping
bill.burke Feb 8, 2004 8:21 PM (in response to bill.burke)
he ClassLoaderDomain cannot be a contract required at the ClassLoader imiplementation level as this is too restrictive on the ClassLoader choice. This should be a contract coming in at the LoaderRepository, and could be supported by adding the class loader domain as a property in the JMX object name of the LoaderRepository. A domain is also likely to have multiple ClassLoaders associated with it.
I don't think I stated clearly what I was saying.
ClassLoaderDomain.getDomainName() would return a string representation of the LoadRepository the CLassLoader belonged too. So in AOP XML you would reference the LoadRepository's ObjectName, not some arbitrary ClassLoaderDomain name. Do you think it is ok to require ClassLoaders to implement this interface now?
If not, then here's another reason. In JBoss AOP, advice bindings are triggered when a static variable within the Class is initialized:
POJO {
static ClassAdvisor advisor = AspectManager().instance().getAdvisor(POJO.class);
}
The lookup of the advisor triggers advice bindings. I would need some way of going from Class to ClassLoader to the Domain the ClassLoader belongs to. I also need this mechanism to work inside and outside of JBoss.
Bill -
4. Re: Classloader Domain scoping
bill.burke Feb 8, 2004 8:23 PM (in response to bill.burke)"rythos" wrote:
So for some versions of the class being loaded the advice applies, and for others it doesn't? I don't have much "real world" experience, can you give an example where such a thing would be useful?
Sure, happens often in J2EE applications. You either have multiple applications being deployed to the same application server, or you have different separate groups (one offshore, one local) developing different components of a large application. They may use different versions of thirdparty libraries (i.e. xerces, Axis, Xalan etc....) J2EE application servers support having multiple versions of the same class as they define specfic classloader hierarchies.
Bill -
5. Re: Classloader Domain scoping
starksm64 Feb 9, 2004 1:43 PM (in response to bill.burke)Its too big a requirement to need the ClassLoader to implement a proprietrary interface. Simply have something like this:
public interface ClassLoaderDomainMgr { public ClassLoaderDomainMgr getClassLoaderDomainMgr(); public String getDomainName(Class c); public String getDomainName(ClassLoader cl); }
-
6. Re: Classloader Domain scoping
bill.burke Feb 9, 2004 3:10 PM (in response to bill.burke)Yeah, you're right Scott on the simpler interface. Sorry.... And thanks.
Bill