[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of
by adrian@jboss.org
"kabir.khan(a)jboss.com" wrote : I can generate the proxies in org.jboss.aop.generatedproxies package in the user's classloader.
|
| Can you guys make the necessary changes to jboss-cl/AS deployers for this to work? Or let me know where to fix this.
Hold your horses. :-)
You haven't answered why it is defined against the user classloader?
See my point about classloader leaks.
Having every classloader export that package will make the classloader
search in that package slow. It will need to check every classloader.
Of course once it has done it once, the result will be cached
(at least until somebody deploys/undeploys a classloader).
We also haven't discussed your other point about needing to flush the blacklist.
START OF IMPLEMENTATION DISCUSSION
Anyway, there's a number of ways to do it. It really depends upon how much you
want to make this configurable, i.e. allow different configuration per classloader ,etc.
and how you want to use it.
The simplest mechanism would be to add an "always exported packages"
to the ClassLoading bean. Then in Module.getCapabilities() you add
those package capabilities to what the modules decides by the Module itself
or are generated by the "defaultCapabilities".
But this could be generalized to "global capabilities' rather than
"always exported packages" such that the Classloading bean could be configured
with packages that have a version if that is important?
e.g.
| <bean name="ClassLoading">
| <property name="GlobalCapabilities">
| <capabilities xmlns="urn:jboss:classloading:1.0">
| <package name="org.jboss.aop.generatedclasses" version="2.0.0"/>
| </capabilities>
| </property>
| </bean>
|
I'm not sure how useful this really is as a generalization? :-)
It also introduces complications:
1) if you somebody makes the mistake of adding a module capability that is global
then all modules would get the same module name as an alias :-)
2) Do we try to merge the global capabilities with what the classloader defines?
e.g. we ignore the global capability if the classloader defines version 2.0.1 of the same package?
etc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204780#4204780
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204780
17 years, 2 months
[Design the new POJO MicroContainer] - Re: MutableClassInfo?
by stale.pedersen@jboss.org
"alesj" wrote : Why do all these MutableX take MutableY as parameters?
| e.g.
|
| | public interface MutableMethodInfo extends MethodInfo
| | {
| | void setReturnType(MutableClassInfo returnType);
| |
| Why would you force a MutableY as a return type?
|
mostly because then we are sure that we will get a CtClass instance within the parameter. there is also a String parameter if you would prefer to use that. it makes little sense to have a ClassInfo param since then we would just do the same work internally as with the String param.
"alesj" wrote :
| "stale.pedersen(a)jboss.org" wrote :
| | The usage of the Class parameter needs to be removed, internal methods using it will just use the CtClass object.
| |
| How does this effect the (weak type) cache?
|
| "stale.pedersen(a)jboss.org" wrote :
| | The question is the method getType(), can we just remove it altogether? -its been marked as deprecated.
| |
| You can, but then you have to fix all MC code. :-)
| Unfortunately we have quite a few places where we use it.
| MDR, Kernel, ...
|
hm, ok. after talking to Kabir we could add logic to the getType() method that if the class isnt loaded, we could try to weave it on demand.
"alesj" wrote :
| "stale.pedersen(a)jboss.org" wrote :
| | We need functionality to get the method signature from a method. This could be implemented in a utilclass, but i would rather see it added to the MethodInfo interface.
| |
| Signature API is part of MDR sub-project.
|
its another signature, this is something similar to CtBehaviour.getSignature(). imo it belongs in MMI.
is it ok if i start commit to jboss-reflect? i can exclude the new files in the pom if needed.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204772#4204772
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204772
17 years, 2 months
[Design the new POJO MicroContainer] - Re: Module.getModuleForClassLoader()
by adrian@jboss.org
"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote :
| | What is different between that and using the bootstrap if you are asking the question
| | part way through the bootstrap process?
| |
| The Bootstrap implementations are invoked AFTER the bootstrap deployments are deployed, so all the classloaders have been created. AbstractServerImpl:
|
| | public void start() throws IllegalStateException, Exception
| | {
| | ...
| | // deploys conf/bootstrap.xml and conf/bootstrap/*.xml
| | doStart(watch);
| |
| | // TODO Fix the TCL hack used here!
| | ClassLoader cl = Thread.currentThread().getContextClassLoader();
| | try
| | {
| | // Run the bootstraps
| | for (Bootstrap bootstrap : bootstraps)
| | {
| | Thread.currentThread().setContextClassLoader(bootstrap.getClass().getClassLoader());
| | startedBootstraps.add(0, bootstrap);
| | bootstrap.start(this);
| | }
| | }
| | finally
| | {
| | Thread.currentThread().setContextClassLoader(cl);
| | }
| | ...
| | }
| |
| /quote]
|
| Isn't that actually a bit late? I assume if the one of the bootstraps
| wants to use aop you would need to know about the Module once it is installed
| rather than the end of the bootstrap process?
| i.e. the pojo deployment will try to load a class that needs to be weaved.
|
| In practice, once all the boostraps have run, the server is fully deployed,
| see for example ProfileServiceBootstrap.start()
| so you would actually be looking at the end of the full server boot wouldn't you?
|
| anonymous wrote :
| | "adrian(a)jboss.org" wrote :
| | | Maybe a better mechanism would be to use the in/uncallback to be notified of the Modules
| | | as they are constructed/destroyed.
| | |
| | Why is that better? I'm happy with using bootstrap, as long as the following is ok:
| | - use KernelDeployment.getClassLoader() to get classloader name and look that up in MC
| | - use ClassLoading.getModuleForClassLoader() to get the module corresponding to the classloader rather than the findModule() stuff from my workaround example
| |
|
| It's better because you are not mixing policy and implementation.
|
| But I'm what I'm really saying is that you are relying on one particular
| configuration/implementation of the bootstrap.
|
| Even the fact that the bootstrap is based on pojo deployments could change.
| I know this is not likely but you are making integration assumptions around
| implementation details which is always a bad plan.
|
| Futher, there could be other pojo deployments that are not part of the bootstrap
| but still create their own classloader/module.
|
| anonymous wrote :
| | If I have understood correctly, using a bootstrap I only need to modify aop.xml, making it easy to upgrade older versions of AS. Otherwise I need to modify classloader.xml to add the in/uncallback stuff. Will that work when the classes I need are in the aop classloader that has not been deployed yet? If I add the un/incallback in aop.xml, is that retroactive, i.e. will classloaders added previously in the bootstrap process (from classloader.xml) be added?
|
| No, you modify your pojo to have add/removeModule() methods
| and then define the in/uncallback methods in your aop.xml for that bean.
|
| You are then using the same mechanism as the ClassLoading uses to be notified
| of what Modules are created "manually" (rather than through the deployers).
| So you are unlikely to have an inconsistent view. ;-)
|
| This also makes your integration cleaner.
| You have some bean that just has add/removeModule() as your api.
|
| You then tell the MC to make the necessary calls.
|
| If somebody really needs to do extra work in certain specifc cases,
| (e.g. they create a Module programmatically outside either the jboss-beans.xml or the deployers) it is possible for them to tell you about it using that simple api.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204752#4204752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204752
17 years, 2 months