January 2009 - jboss-dev-forums - Jboss List Archives

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Module.getModuleForClassLoader()

by kabir.khan＠jboss.com

OK, since the in/uncallbacks are retroactive I will experiment with using those. Since I will now have a Module and need the loader, I need an additional static method on ClassLoading/Module: ClassLoader getClassLoaderForModule() I'll try to add that a bit later today View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204774#4204774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204774

17 years, 2 months

1
0
0 / 0

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by kabir.khan＠jboss.com

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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204768#4204768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204768

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : or even the system classloader? The system classloader would probably be a bad idea if the aop classes themselves got redeployed. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204765#4204765 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204765

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I guess the question Is what is the reason why you define these classes against | the user classloader instead of having one implementation against the jboss-aop | classloader or even the system classloader? | I'd further guess that it doesn't really matter (unless you had some name mangling scheme) since in the old UCL mechanism the first classloader to have these classes would always be used to load the classes. In fact, that would potentially be a memory leak if that first classloader got redeployed while other classloaders were sharing those classes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204764#4204764 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204764

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : I see your difficulty, but for the reasons stated above, | we can't just implicitly start exporting the default package | since that could reveal "module private" classes that the user doesn't want to be shared. | | Wouldn't it make more sense to have these "java.xxx proxies" in some jboss aop | package that its classloader explicitly exports and define then against jboss aop's classloader? | I would have less qualms about an org.jboss.aop.xxx package automatically exported by user classloaders since it is unlikely to be a user package and it is trivial to warn/document that it happens if you use choose to use jboss aop. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204762#4204762 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204762

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by adrian＠jboss.org

I see your difficulty, but for the reasons stated above, we can't just implicitly start exporting the default package since that could reveal "module private" classes that the user doesn't want to be shared. Wouldn't it make more sense to have these "java.xxx proxies" in some jboss aop package that its classloader explicitly exports and define then against jboss aop's classloader? That way your not going to interfere with the import/export rules of the user classloaders. I guess the question Is what is the reason why you define these classes against the user classloader instead of having one implementation against the jboss-aop classloader or even the system classloader? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204758#4204758 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204758

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: jta/jts jar/config file change

by jhalliday

This update will probably go into TS trunk tomorrow, from which time integrating with JBossAS will be a bit hairy until the TS 4.6.0.CR is out and JBossAS is updated for the new integration process. Think twice about 'svn update' for the next week or so if you need to integrate with the AS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204754#4204754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204754

17 years, 2 months

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009