[JBoss Microcontainer Users] - Re: Getting to a ClassInfo's ClassLoader
by alesj
"flavia.rainone(a)jboss.com" wrote :
| Don't you mean that, if the ModifiableClassInfo is modified, it delegates the loading to CtClass::toClass first, and only then to the JavassistUtil.class.getClassLoader()?
| IMO, this is correct, given that CtClass.toClass() uses the ClassPool and the ClassLoader associated with the ClassPool in order to load the class.
| Still, the JavassistUtil class contains a few bugs, because it is not using the correct classpool on the remaining methods.
|
If modified, we just try if we can still load it.
| if(ct.isModified())
| {
| try
| {
| ct.toClass();
| }
| catch (CannotCompileException e)
| {
| throw new org.jboss.reflect.spi.CannotCompileException(e.toString());
| }
| }
|
And yes, JavassistUtil definitely needs fixing.
"flavia.rainone(a)jboss.com" wrote :
| "alesj" wrote :
| | Perhaps new getClassLoader method on TypeInfo?
|
| I think that that is the ideal. The getType method has the collateral effect that the MutableClassinfo can no longer be edited after it has been loaded. The correct way of retrieving the class loader would be:
| ctClass.getClassPool().getClassLoader
| This could be easily done if we added a getClassLoader() method to TypeInfo.
OK, this looks reasonable, as to delay class creation as long as we can.
Like I said, just make sure - perhaps it's already part of javassist code - that there is security enforcement.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260397#4260397
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260397
16 years, 8 months
[JBoss Microcontainer Users] - Re: Getting to a ClassInfo's ClassLoader
by flavia.rainone＠jboss.com
"alesj" wrote : How do we use it elsewhere/before?
Before I added those getType.getClassLoader() calls, the null classloader was being used for loading and creating ctClasses instead.
I don't think that classloader is retrieved elsewhere,apart from BasicClassAdapter.getClassLoader(), that also invokes getType() to get to the ClassLoader.
"alesj" wrote : Looking at the Javassist Reflect usage, it seems we need to change it a bit.
|
|
| | public Class<? extends Object> getType()
| | {
| | if(clazz == null)
| | clazz = JavassistUtil.ctClassToClass(ctClass);
| |
| | return clazz;
| | }
| |
|
| This first delegates the loading to JavassistUtil.class.getClassLoader() and only then to CtClass::toClass.
| Meaning we wouldn't use our new Classpool notion first, only after it would fail via first try.
Don't you mean that, if the ModifiableClassInfo is modified, it delegates the loading to CtClass::toClass first, and only then to the JavassistUtil.class.getClassLoader()?
IMO, this is correct, given that CtClass.toClass() uses the ClassPool and the ClassLoader associated with the ClassPool in order to load the class.
Still, the JavassistUtil class contains a few bugs, because it is not using the correct classpool on the remaining methods.
"alesj" wrote :
| Perhaps new getClassLoader method on TypeInfo?
I think that that is the ideal. The getType method has the collateral effect that the MutableClassinfo can no longer be edited after it has been loaded. The correct way of retrieving the class loader would be:
ctClass.getClassPool().getClassLoader
This could be easily done if we added a getClassLoader() method to TypeInfo.
"alesj" wrote : btw: don't forget to check for security or add permission blocks on who can use it
Ok!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260375#4260375
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260375
16 years, 8 months
[JBoss OSGi Users] - JBossOSGi 1.0.0.Beta4 Released (14-Oct-2009)
by thomas.diesler＠jboss.com
I am happy to announce the release of JBossOSGi-1.0.0.Beta4.
http://jbossosgi.blogspot.com/2009/10/jbossosgi-100beta4-released_14.html
The release comes with improvements in the following areas
* Initial release of our native JBossMC based OSGi Framework.
* Added support for OSGi WebApps using WebApp Extender
* Improved support for the HttpService.
For details please have a look at the latest version of our User Guide.
Here are the change log details
Feature Request
* [JBOSGI-110] - Support WAR deployments in the OSGi runtime
* [JBOSGI-127] - Provide build and hudson support for MC facade
* [JBOSGI-128] - Add Framework launch API
Task
* [JBOSGI-80] - Add support for Framework Launching (RFC-132)
* [JBOSGI-132] - Release JBoss MC Framework 1.0.0.Alpha1
* [JBOSGI-134] - Add support for BundleContext.getDataFile()
* [JBOSGI-142] - Investigate classloading space
* [JBOSGI-148] - Autostart bundles when deployed in JBossAS
* [JBOSGI-156] - Setup r4v42 core TCK
* [JBOSGI-159] - Fire events asynchronously
* [JBOSGI-160] - Use Pax Web instead of Apache Http-Service
* [JBOSGI-164] - Update Blueprint to 1.0.0.Alpha2
* [JBOSGI-165] - Update to jboss-osgi-common-1.0.2
* [JBOSGI-166] - Update to jboss-osgi-common-core-2.2.13.GA
* [JBOSGI-167] - Update to jboss-osgi-husky-1.0.1
* [JBOSGI-168] - Update to jboss-osgi-jmx-1.0.1
* [JBOSGI-169] - Update to jboss-osgi-jndi-1.0.1
* [JBOSGI-170] - Update to jboss-osgi-microcontainer-1.0.2
* [JBOSGI-171] - Update to Eclipse Equinox-3.5
* [JBOSGI-172] - Update to Apache Felix-2.0.0
* [JBOSGI-173] - Update to jboss-osgi-spi-1.0.2
* [JBOSGI-174] - Update to jboss-osgi-webconsole-1.0.1
* [JBOSGI-175] - Update to osgi core/compendium R4v42
* [JBOSGI-176] - Release JBoss OSGi 1.0.0.Beta4
* [JBOSGI-133] - Pass all example tests with MC Framework
Bug
* [JBOSGI-78] - ResourceNotFoundException too verbose
* [JBOSGI-130] - Bundle is still in state INSTALLED after bundle.start()
* [JBOSGI-135] - Cannot handle package being imported and exported by the same bundle
* [JBOSGI-136] - Cannot resolve dependency against unstarted bundle
* [JBOSGI-140] - Invalid delivery of framework events
* [JBOSGI-144] - Framework does not handle ServiceFactory provided services properly
* [JBOSGI-151] - Cannot resolve circular dependencies
* [JBOSGI-155] - OutOfMemoryError on repeated install/unstall bundle
* [JBOSGI-158] - Framework itself must be a bundle
* [JBOSGI-161] - Cannot use commons-logging
* [JBOSGI-162] - Cannot load classes from Bundle-ClassPath
* [JBOSGI-163] - Husky invocation before async extender processing
Enjoy
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260371#4260371
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260371
16 years, 8 months