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

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

by Kabir Khan

JBoss development, A new message was posted in the thread "ClassPool Refactoring": http://community.jboss.org/message/522340#522340 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- > mailto:flavia.rainone@jboss.com wrote: > - why is it that calling get on the default domain returns a different version of the same class? This needs further investigation because it is clearly a bug Yes, this definitely needs fixing. But I thought we had tests for this already? e.g. this from SimpleDelegatingClassPoolTestCase. I added a few extra checks as indicated to make double sure public void testOnePoolPerClassLoadedByA() throws Exception { ClassPoolDomain domain = createClassPoolDomain("SIMPLE", null, false); ClassPool poolA = createDelegatingClassPool(domain, JAR_A_URL); ClassPool poolB = createDelegatingClassPool(domain, JAR_B_URL); //The first time we access the pool it will create the classes, second time will use the cache accessOnePoolPerClassLoadedByA(poolA, poolB); accessOnePoolPerClassLoadedByA(poolA, poolB); } private void accessOnePoolPerClassLoadedByA(ClassPool poolA, ClassPool poolB) throws Exception { CtClass a = poolA.get(CLASS_A); assertEquals(a, poolA.get(CLASS_A)); assertEquals(a, poolB.get(CLASS_A)); CtClass b = poolA.get(CLASS_B); assertEquals(b, poolA.get(CLASS_B)); assertEquals(b, poolB.get(CLASS_B)); assertNotSame(a.getClassPool(), b.getClassPool()); assertEquals(poolA, a.getClassPool()); assertEquals(poolB, b.getClassPool()); } > mailto:flavia.rainone@jboss.com wrote: > > - why wasn't the classes cache being used by BaseClassPool.get before? Any reason for this? This has been copied from previous versions, I think that it definetly causes some overhead (the above should work, but it would be faster if the classpool finds out it has already created the class and returns the same class instead of delegating to the domain first). I can't see anything in BaseClassPool.get() or get0() regarding this? I think you mean DelegatingClassPool.get0()? I don't see the ClassPool.classes cache being used there either, so maybe I am looking in the wrong place. If I am in the right place, it might be an idea to try to load it locally in the initiating classpool first before hitting the domain if the cachedLookups == null. //TODO KABIR was synchronized - I don't see why apart from that the standard javassist.ClassPool implementation was synchronized? public final CtClass get0(String classname, boolean useCache) throws NotFoundException { //KABIR Made final just to make sure that cached lookups are only handled in one place. if (cachedLookups != null) { CtClass cachedLookup = cachedLookups.get(classname, domain.getModCount()); if (cachedLookup != null) { logger.trace(classname + " was found in the cache of " + this); return cachedLookup; } } else { CtClass cached = getCachedLocally(classname); if (cached != null) return cached; } ... } > mailto:flavia.rainone@jboss.com wrote: > - if the cache starts being used as a first step of BaseClassPool.get, as it is in my local fix (not committed yet), is there need for a second level cache as Kabir wrote? Yes. It caches all CtClasses looked up by that classpool, and they might come from any classpool in the domain. The cacheLookups of all the classpools in the domain are invalidated when a classpool is added/removed to the domain or its parent domain. Basically, it means that if we look something up in a classpool, we don't need to do all the work in the domain. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522340#522340

14 years, 11 months

1
0
0 / 0

[JBoss Portal Development] New message: "[portlet container] actionURL generated too long because of large render parameter?"

by Chen Wang

JBoss development, A new message was posted in the thread "[portlet container] actionURL generated too long because of large render parameter?": http://community.jboss.org/message/522334#522334 Author : Chen Wang Profile : http://community.jboss.org/people/chenwang Message: -------------------------------------------------------------- Hello, As I mentioned in my earlier posts in this form I'm in the process of developing an in-house portal on top of gatein portlet container. So far I've been very pleased with the container but running some user acceptance tests revealed one particular problem around portlet actionurl generation when there are large render parameter put into ActionResponse in processAction stage. The action url generated by calling RenderResponse.createActionUrl() in doView stage is too long, sometimes the browser/server just complains and refuses to proceed. I had a look at source code (as I always like to do), it seems that render parameters are being serialised as part of navigational state, I wonder if it can be done slightly better? My impression is that current solution relies on client-side url to keep the state which offloads burden on server-side but the length of url is easily out of control; would a session-like solution be more suitable here, say a unqiue id is sent to client instead of actual serialised data? My workaround is to put data to be transfered between processAction and doView stages to portlet session instead of as render parameter. It's working but not perfect. Thanks, Chen -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522334#522334

14 years, 11 months

1
0
0 / 0

[JBoss Web Services Development] New message: "WS-* and SOAP Stack Spec Versions?"

by Greg Totsline

JBoss development, A new message was posted in the thread "WS-* and SOAP Stack Spec Versions?": http://community.jboss.org/message/522324#522324 Author : Greg Totsline Profile : http://community.jboss.org/people/javatots Message: -------------------------------------------------------------- Hi - Can someone please point me to an up to date referece that shows the specific versions of each WS-* and SOAP related specification that JBoss AS 5.0 supports? I can't seem to find anything specific in this area. Thanks. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522324#522324

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Optimizing org.jboss.aop.pointcut.Util"

by Flavia Rainone

JBoss development, A new message was posted in the thread "Optimizing org.jboss.aop.pointcut.Util": http://community.jboss.org/message/522305#522305 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- During debugging of the http://community.jboss.org/thread/88687, I discovered that, for every transformation, the same classes were being retrieved from the classpool again and again during pointcut matching, all invocations being indirect invocations originated in org.jboss.aop.pointcut.Util. I have locally added a very simple cache (that definetly will need improvement if it proves to have a positive impact) to Util class. This cache basically stores the result of previous queries, which not only skips calls to the ClassPool, but also avoids recalculation of the entire query result. As soon as I'm able to run the tests without failures, I'll measure the performance gain we may have with this cache, if any. All my findings will be posted here. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522305#522305

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Re: Help: Error [Instrumentor] AOP Instrumentor failed"

by Flavia Rainone

JBoss development, A new message was posted in the thread "Help: Error [Instrumentor] AOP Instrumentor failed": http://community.jboss.org/message/522298#522298 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- Can you enable the verbose mode of AOP to see which classes are being woven? Maybe that can show us why is there an unexpected super class? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522298#522298

14 years, 11 months

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/522295#522295 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- A quick update on this: for some reason, the behavior of ClassPool.get method is no longer consistent with ScopedClassPool.getLocally method. The first time AOP asks for a class, during transformation, it knows that the class should be generated by the exact same classpool that corresponds to the classloader that loaded the class, so it uses getLocally. The second time AOP asks for the class is during the same transformation (these are actually indirect calls made from inside javassist, during call weaving, for example), the class is retrieved through get. Currently, the classpool delegates the retrieval of the class to the default domain, and the default domain returns a different class. I think that clearly every call to get should check first whether the class is already in the local classes cache. Adding such a check fixed most of the failing tests in AS trunk (only two failures left), but broke the cache tests of Kabir's implementation. So, I have a few questions regarding this: - why is it that calling get on the default domain returns a different version of the same class? This needs further investigation because it is clearly a bug - why wasn't the classes cache being used by BaseClassPool.get before? Any reason for this? This has been copied from previous versions, I think that it definetly causes some overhead (the above should work, but it would be faster if the classpool finds out it has already created the class and returns the same class instead of delegating to the domain first). - if the cache starts being used as a first step of BaseClassPool.get, as it is in my local fix (not committed yet), is there need for a second level cache as Kabir wrote? My next steps will be: - investigate the next couple of AOP tests that are failing - investigate the majority of scoped AOP tests that are failing - investigate why is it that the default domain pool is returning a class that it shouldn't return at all -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522295#522295

14 years, 11 months

1
0
0 / 0

[JBoss XML Binding Development] New message: "Re: Binding to multiple namespaces"

by Ales Justin

JBoss development, A new message was posted in the thread "Binding to multiple namespaces": http://community.jboss.org/message/522171#522171 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- Afaik, that should be doable. As that was the reason Alexey changed the resolved type to multiple resolver. Search older posts, I think it was the JCa guys that asked for similar feature. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522171#522171

14 years, 11 months

1
0
0 / 0

[JBoss XML Binding Development] New message: "Binding to multiple namespaces"

by David Lloyd

JBoss development, A new message was posted in the thread "Binding to multiple namespaces": http://community.jboss.org/message/522170#522170 Author : David Lloyd Profile : http://community.jboss.org/people/david.lloyd@jboss.com Message: -------------------------------------------------------------- I posted a discussion in the user forum (the first, and only post there) at http://community.jboss.org/message/520932#520932 but have not yet received any response. I'm assuming that due to the lack of volume there, nobody is actually monitoring that forum, so I'm posing the question here. Basically I need to bind my SchemaResolverDeployer to more than one namespace. Any thoughts? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522170#522170

14 years, 11 months

1
0
0 / 0

[JCA Development] New message: "Re: JBJCA-260: New WorkManager"

by Jesper Pedersen

JBoss development, A new message was posted in the thread "JBJCA-260: New WorkManager": http://community.jboss.org/message/522156#522156 Author : Jesper Pedersen Profile : http://community.jboss.org/people/jesper.pedersen Message: -------------------------------------------------------------- Thanks for the update, David. I don't see having a direct dependency on JBoss Threads for this project as a problem. So I'll go ahead and use 2.0.0.CR2's BlockingExecutor interface. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522156#522156

14 years, 11 months

1
0
0 / 0

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

by Stan Silvert

JBoss development, A new message was posted in the thread "Deployment of on-demand web applications": http://community.jboss.org/message/522153#522153 Author : Stan Silvert Profile : http://community.jboss.org/people/stan.silvert@jboss.com Message: -------------------------------------------------------------- > mailto:bstansberry@jboss.com wrote: > > Stan, can you create a blocker JIRA for M3 for revisting the set of profiles we ship? M3 is when some ProfileService changes will be in to make it easier to preconfigure a bunch of profiles. It's a PITA now; doing it for M2 (beyond trivial stuff like dropping admin-console from default) will waste a lot of time on something that will be thrown away. > Sure. Sounds good. https://jira.jboss.org/jira/browse/JBAS-7651 -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/522153#522153

14 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2010