JBossDeveloper

"adrian@jboss.org" wrote:

"kabir.khan@jboss.com" wrote:

You and Bill are cut from the same cloth. ;-)
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113494

lol - well he was the one who discovered me - or the other way round or something

That's bizarre, my last post seems to have overwritten yours, and our names have been reversed?!?!?

For completeness, here is the post that I was replying to

"adrian" wrote:

"kabir.khan@jboss.com" wrote:
wrote : Do you have some pointers to the classloading rules? I still need to get my head around this part, but in the meantime do you think we need special ClassPools as well?

I think the javassist ClassPath is closer to how the new classloaders work.
The deployers could create a ClassPool/ClassPath structure
that matches the classloader configuration.

Like I said I don't think determining what configuration applies based on class
locations/visibility is the correct solution anyway, even though I did manage to fix
some issues by making AOP use ClassPool.getClassLoader() instead of the TCL.

>From the tests I wrote in the AOP integration, the basic ScopedClassPool of javassist
seems to be able to handle what we need for OSGi?

"adrian@jboss.org" wrote:

My preferred solution to use the scopes. i.e. you can choose
to deploy aop config at the SERVER, SUBSYSTEM, APPLICATION level, etc.

"kabir.khan@jboss.com" wrote:

Is there an existing deployer for selecting at what level things should be deployed at? Or should this be something specific to the AOP deployer?

Since Module is in the deployers-impl package I assume I should not use that from my AspectDeployer? I don't see any other way to get hold of of the information from ClassLoaderPolicy?

"adrian@jboss.org" wrote:

"adrian@jboss.org" wrote:

My preferred solution to use the scopes. i.e. you can choose
to deploy aop config at the SERVER, SUBSYSTEM, APPLICATION level, etc.
but this requires doing a lot work fixing everything to make sure
it sets the correct thread local MetaData for AOP to know which Scope
applies at runtime.

This thead local is really just a generalization of ejbs/mbeans
setting the correct context classloader and java:/comp/env

In principle once this is done. The only work required by AOP
would be for the deployer to create hierarchical ...

"adrian@jboss.org" wrote:

It's not work in progress, at least not yet.
I only added the deployments scope a week ago.

I'd suggest you try it yourself with a mock test, e.g. write an aspect
that pushes the metadata from the advisor onto the stack and test it using
the aop proxy where you can pass in the metadata.

 public void testDomain() throws Exception
 {
 URL url = null;
 Domain domain = null;
 try
 {
 //Create our instance to be proxied before we start deploying stuff
 TestIntercepted test = new TestIntercepted();

 //Deployer creates metadata and populates that with the necessary domain
 createAndPushMetaData(createScopedDomain("xxx"));

 //We get the domain out of the metadata and deploy into that
 MetaData md = MetaDataStack.peek();
 domain = md.getMetaData(Domain.class);
 assertNotNull(domain);
 url = deploy("1", Thread.currentThread().getContextClassLoader(), domain);

 //create the proxy, the scoped manger is taken from the metadata stack
 AOPProxyFactoryParameters params = new AOPProxyFactoryParameters();
 params.setTarget(test);
 params.setMetaData(md);

 AOPProxyFactory factory = new GeneratedAOPProxyFactory();
 TestIntercepted proxy = (TestIntercepted)factory.createAdvisedProxy(params);
 assertFalse(proxy.getClass() == TestIntercepted.class);

 TestInterceptor.intercepted = null;
 proxy.doSomething();
 assertNotNull(TestInterceptor.intercepted);
 assertEquals("First", TestInterceptor.intercepted);
 }
 finally
 {
 if (MetaDataStack.peek() != null)
 {
 MetaDataStack.pop();
 }
 undeploy(url, domain);
 }
 }

 private ScopeKey createScope(String app, String dep)
 {
 ScopeKey result = ScopeKey.DEFAULT_SCOPE.clone();
 result.addScope(CommonLevels.APPLICATION, app);
 result.addScope(CommonLevels.DEPLOYMENT, dep);
 return result;
 }

 private void createAndPushMetaData(Domain scopedDomain)
 {
 //Deployer creates Domain depending on classloader rules, and adds it to metadata for deployment
 ScopeKey scopeKey = createScope("Test", scopedDomain.getDomainName());
 MutableMetaDataRepository repository = new BasicMetaDataRepository();
 MetaDataRetrieval retrieval = new MemoryMetaDataLoader(scopeKey);
 repository.addMetaDataRetrieval(retrieval);

 if (scopedDomain != null)
 {
 ((MutableMetaData)retrieval).addMetaData(scopedDomain, Domain.class);
 }
 MetaData metadata = repository.getMetaData(scopeKey);
 MetaDataStack.push(metadata);
 }

 private Domain createScopedDomain(String name)
 {
 AspectManager manager = AspectManager.getTopLevelAspectManager();
 Domain scopedDomain = new Domain(manager, name, false);
 return scopedDomain;
 }

"adrian@jboss.org" wrote:

"kabir.khan@jboss.com" wrote:
Since Module is in the deployers-impl package I assume I should not use that from my AspectDeployer? I don't see any other way to get hold of of the information from ClassLoaderPolicy?

When I created the "Module" class, I only anticipated it was an implementation detail
of the classloader dependencies so I didn't put it in the spi.

Any use of it would be a "hack" until the proper scoped metadata solution is done.