February 2010 - jboss-dev-forums - Jboss List Archives

[Javassist Development] New message: "Re: ScopedClassPoolRepositoryImpl and default ClassPool"

by Flavia Rainone

JBoss development, A new message was posted in the thread "ScopedClassPoolRepositoryImpl and default ClassPool": http://community.jboss.org/message/525606#525606 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- On a side note, the class pool that is used by factories to represent null class loaders is configured on org.jboss.classpool.spi.AbstractClassPoolFActory. Currently it can be set by callling AbstractClassPoolFactory.setDefaultClassPool() and it can be retrieved by callling AbstractClassPoolFactory.getDefaultClassPool(). The problem is that, IMO, this nomenclature is not appropriate. Javassist uses default ClassPool to denote the classpools that is used by default on some operations. In my case, I'm configuring the class pool that is used to represent null class loaders. Any ideas on how to name those methods? I thought on setNullClassPool or on setBootstrapClassPool Notice that anyway we will have a gap with the SystemClassPool nomenclature, which is being used because this class pool is associated to the SystemClassLoader. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525606#525606

16 years, 1 month

1
0
0 / 0

[JBoss AOP Development] New message: "Re: ClassPool Refactoring"

by Flavia Rainone

JBoss development, A new message was posted in the thread "ClassPool Refactoring": http://community.jboss.org/message/525602#525602 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- All tests are passing now in my system, which allowed me to validate two previous fixes Kabir and I implemented for the problem of duplicate CtClasses. Kabir's fix consists of https://jira.jboss.org/jira/browse/JBAOP-766 : public class DelegatingClassPool extends BaseClassPool { ... public CtClass getCached(String classname) { >>> //TODO Not 100 sure this is correct, but it seems to do the job where repeated calls to get() on a pool in a hierarchy returns a different instance of the class >>> CtClass clazz = super.getCachedLocally(classname); >>> if (clazz != null) >>> return clazz; if (isGeneratedClass(classname)) { return null; } return domain.getCachedOrCreate(this, classname, false); } } My fix has never been comitted and consists of adding a check on the classes cache to BaseClassPool.get: public class BaseClassPool extends AbstractClassPool { ... @Override public final CtClass get(String classname) throws NotFoundException { boolean trace = logger.isTraceEnabled(); if (trace) logger.trace(this + " initiating get of " + classname); if (this.getClassLoader() == null) { throw new IllegalStateException("Illegal call. " + " A class cannot be retrieved from ClassPool " + this + " because the corresponding ClassLoader is garbage collected"); } try { >>> if (this.classes.containsKey(classname)) >>> { >>> return (CtClass) classes.get(classname); >>> } CtClass clazz = super.get(classname); if (trace) logger.trace(this + " completed get of " + classname + " " + getClassPoolLogStringForClass(clazz)); return clazz; } catch (NotFoundException e) { if (trace) logger.trace(classname + " could not be found from " + this, e); throw e; } } } It turns out that, once all tests were fixed for issue https://jira.jboss.org/jira/browse/JBREFLECT-94, those fixes weren't needed anymore, which means that JBREFLECT-94 was the real issue. Now I'm left with the dillema of whether should I commit those fixes. I have started running some tests to try to figure out if any of those bring some improvement, and it seems that looking up classes cache in BaseClassLoader.get does bring a few improvements to the performance of aop tests, but I need to run those tests more times in order to do a reasonable investigation. While working with Kabir to fix the AOP tests for AS, he pointed out that there could be an issue related to my fix. It seemed obviously right to me to look in the classes cache (a cache declared in ScopedClassPool that contains all classes created by the current class pool) before doing anything else. To me, if we have a hit in the cache, it means that the current pool is the one that is supposed to load the class, and that there is no need to look further by calling super.get method. But Kabir raised the following possibility. What if the class pool scenario (a reflection of the class loader/domain scenario) changes after the current class pool loaded the class, in a way that this class pool is no longer the one responsible for loading that class? In that case, looking for the class in the classes cache would be a serious mistake. Is this scenario possible? Regarding Kabir's fix, I'm also looking for any opnion regarding whether it should be committed. It seems, though, that adding both fixes brings some small performance penalty. I'll continue running tests to be able to assert whether this is really true, and what is the penalty we're talking about. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525602#525602

16 years, 1 month

1
0
0 / 0

[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"

by Brian Stansberry

JBoss development, A new message was posted in the thread "Deployment of on-demand web applications": http://community.jboss.org/message/525591#525591 Author : Brian Stansberry Profile : http://community.jboss.org/people/bstansberry@jboss.com Message: -------------------------------------------------------------- Fair enough. The above JIRAs are mostly to document this for later consideration so I could move on to other stuff today. I don't see much use case for hot deploying these apps. If someone really wanted to they could just move them to the hot deploy profile. Hmm, but deploy-hasingleton is a bit of a different story. That's a profile that gets activated after startup but is a legit hot deploy profile. For that we'd need to make sure the JBAS-7721 problem is fixed. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525591#525591

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by John Bailey

JBoss development, A new message was posted in the thread "Classloader VFS3 Integration": http://community.jboss.org/message/525581#525581 Author : John Bailey Profile : http://community.jboss.org/people/johnbailey Message: -------------------------------------------------------------- This sounds good by me. I am gunning for getting started as soon as possible, so if you think Feb 16th is the best, lets go with that. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525581#525581

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by Ales Justin

JBoss development, A new message was posted in the thread "Classloader VFS3 Integration": http://community.jboss.org/message/525579#525579 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > To follow up to my last post, I would like to attempt a somewhat controlled an order migration. Is it possible to go one at a time, or do the MC projects have to go all at once? No, not all at once, but in dependency order. e.g. VFS -> CL - > Deployers -> OSGi ... others probably all go after Deployers as well We will need a proper release of them all, at least of the dependecies -- leaves don't need to be tagged/released. (it's mostly gonna be 2.2.0.Beta1) Let's now settle on a date, which will be the deadline after which all trunk work for all involved projects must halt for a while. I suggest 16th Feb, as it gives us enough time to finish whatever we have, and it's not on the first day of the week. Once we agree, I'll send an announcement on the needed mls. OK? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525579#525579

16 years, 1 month

1
0
0 / 0

[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"

by Emanuel Muckenhuber

JBoss development, A new message was posted in the thread "Deployment of on-demand web applications": http://community.jboss.org/message/525567#525567 Author : Emanuel Muckenhuber Profile : http://community.jboss.org/people/emuckenhuber Message: -------------------------------------------------------------- IMHO no deployment outside of "hot-deployment profile" should be checked for modifications. In future (once i integrated the new profileservice stuff) hot-deployment won't be available for any jboss deployments anymore. Redeployment will only happen as part of a ManagementAction - where we know if we have to restart the whole server to apply changes or can just redeploy the deployment. So i would rather prefer to just disbale hot-deployment checking for those deployments in general - what do you think? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525567#525567

16 years, 1 month

1
0
0 / 0

[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"

by Brian Stansberry

JBoss development, A new message was posted in the thread "Deployment of on-demand web applications": http://community.jboss.org/message/525562#525562 Author : Brian Stansberry Profile : http://community.jboss.org/people/bstansberry@jboss.com Message: -------------------------------------------------------------- https://jira.jboss.org/jira/browse/JBAS-7721 to fix ProfileService problem; https://jira.jboss.org/jira/browse/JBAS-7720 to then figure out how to set up the profile such that the HD scan understands that it's not supposed to look at each file in the war as a deployment. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525562#525562

16 years, 1 month

1
0
0 / 0

[Tomcat Integration Development] New message: "Re: Deployment of on-demand web applications"

by Brian Stansberry

JBoss development, A new message was posted in the thread "Deployment of on-demand web applications": http://community.jboss.org/message/525556#525556 Author : Brian Stansberry Profile : http://community.jboss.org/people/bstansberry@jboss.com Message: -------------------------------------------------------------- Running in a debugger confirms that the HDScanner is treating each file inside the war as a new deployment. This doesn't happen with -Djboss.as.deployment.ondemand=true because there's a bug in the way profiles are configured for HD scanning. It only gets turned on via this bit in ProfileServiceBootstrap.start(...) // Enable modification checks on all mutable profiles for(ProfileKey key : profileService.getActiveProfileKeys()) { try { Profile profile = profileService.getActiveProfile(key); if(profile.isMutable() && profile instanceof MutableProfile) { ((MutableProfile) profile).enableModifiedDeploymentChecks(true); } } catch(NoSuchProfileException ignore) { } With -Djboss.as.deployment.ondemand=true when that code executes, the profiles for the on-demand wars are not yet "active" so the enableModifiedDeploymentChecks(true) call is never made. With -Djboss.as.deployment.ondemand=false the profile is active and the profile is exposed to the HDScanner. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525556#525556

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by John Bailey

JBoss development, A new message was posted in the thread "Classloader VFS3 Integration": http://community.jboss.org/message/525547#525547 Author : John Bailey Profile : http://community.jboss.org/people/johnbailey Message: -------------------------------------------------------------- To follow up to my last post, I would like to attempt a somewhat controlled an order migration. Is it possible to go one at a time, or do the MC projects have to go all at once? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525547#525547

16 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Classloader VFS3 Integration"

by John Bailey

JBoss development, A new message was posted in the thread "Classloader VFS3 Integration": http://community.jboss.org/message/525544#525544 Author : John Bailey Profile : http://community.jboss.org/people/johnbailey Message: -------------------------------------------------------------- As we near the Feb, 11th date, are we ready to start moving forward with the initial MC VFS3 integration projects? How big of a chunk do we want to take on at first? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/525544#525544

16 years, 1 month

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 February 2010