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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Fix for ClusterViewUpdateTest

by clebert.suconic＠jboss.com

2 seconds for the ping is too short. That should only happen on tests... please don't deliver the release with that change. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201775#4201775 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201775

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by adrian＠jboss.org

"alesj" wrote : | But I guess this shouldn't be a problem to add/impl, | as our current scoped classpool impl is simply a map of CL,Pool pairs | and all TypeInfoFactory::get methods have a means to get CL. | The scoped classpool isn't that though. It works at the "domain" level assuming all peer classloaders are visible to each other and that they all export everything. anonymous wrote : | It's probably just the case of delaying class loading as late as possible | plus changing how we cache things with non-introspection TypeInfoFactory impls. | e.g. Class == CL + classname If everybody used the ClassInfo stuff there should be no real classloading at all until it is really needed, i.e. objects constructed. And all the reflection would be optimized (faster and stored only once) using the javassist implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201766#4201766 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201766

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by adrian＠jboss.org

"alesj" wrote : "stale.pedersen(a)jboss.org" wrote : as we've stated in the aop design forum (and here) is that the current state of jboss-reflect is too limited for aop to use at all. a well designed MutableClassInfo can change that though. | | | What about if we just added 'mutable' wrapper/delegate. | e.g. you would actually create your own ClassInfo impl based on existing JavassistCI: | Extra stuff would be held in this mutable wrapper/delegate. | When invoked, first check extra stuff if it exists, else delegate. | No. It should evolve into a one-stop shop for reflection and byte-code manipulation implemented on top of javassist (or any other byte code tool). That's the purpose of the abstraction. The original idea was that ClassInfo would be able to represent classes before they are loaded. The code was originally ported by Bill from AOP. Having additional functionality to add/change methods, etc. should also be a part of this api. That additional functionality obviously wouldn't work if you just chose to use the basic introspection implementation as now which is "read-only". But to make it properly useful it needs deeper integration with the classloading structure, see below. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - the possibility to create a classobjectrepresentation from a byte[]/File/Url | | | What exactly do you mean here? | e.g. ClassInfo ci = factory.getClassInfo(byte[]/File/Url); ? | This just lets you create a ClassInfo from the bytecode. But for this to work properly it needs to have a understanding as to which classloader the class/bytecode should be assigned. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - be able to change/add/remove fields/methods/constructors/classes similiar to what javassist support | | | How do you do this in your prototype? | I guess a single place where you know the aop rules would be enough? | e.g. AOP impl of TypeInfoFactory overridding instantiate method | See above. It just needs a new interface to say the Javassist*Info implements the Mutable behaviour. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - do finegrained operations/checks ala annotation visibility (which is only possible with javassist and not java.lang.reflect afaik) | | | Annotation visibility? | Not sure why you need this. I assume you mean being able to look at annotations that are not Runtime visible? Is that really a good idea? anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - be able to get a classobjectrepresentations (ala ClassFile in javassist) from an existing ClassInfo object | | | Why? | This is/shoule be impl detail. | Unless you mean being able to get the resulting byte code from the manipulation so you can defineClass() on it I don't think it is a good idea. Allowing access to implementation details is not a good idea, e.g. the deprecated TypeInfo.getClass() should not be there. Instead we need to extend the abstraction to make this unnecessary. This could include some helper methods to defineClass() from a ClassInfo. anonymous wrote : | "stale.pedersen(a)jboss.org" wrote : | | - support scoped classpools | | | Yup. | Nope/Yup. The Scoped classpools are wrong. They don't understand the classloading rules properly - except in JBoss4, although they are better than what we have now. See the discussions in the aop forum I had repeatedly last year with Kabir. SUMMARY Besides completing the generics stuff in the javassist class info so we can use it, the TypeInfo needs additional "optional" interfaces for mutable behaviour. But the real work is making aop/classinfo properly integrate with the classloading structure. Additionally as Ales and I discussed in Slovenia, the MDR introspection stuff (Class annotations) and a number of other places should also be using the ClassInfo stuff. Especially when it comes to the more efficient method/field reflection stuff I wrote in the JavassistClassInfo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201761#4201761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201761

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by alesj

"adrian(a)jboss.org" wrote : | Its not complete. | | * The generics stuff isn't done because javassist didn't support generics when I | originally wrote it. | * There's an issue with the method reflection for non-public methods/fields when not using | Sun's JDK. I meant more about wrt scoped classpools. But I guess this shouldn't be a problem to add/impl, as our current scoped classpool impl is simply a map of CL,Pool pairs and all TypeInfoFactory::get methods have a means to get CL. It's probably just the case of delaying class loading as late as possible plus changing how we cache things with non-introspection TypeInfoFactory impls. e.g. Class == CL + classname View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201753#4201753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201753

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Per window customization even when it is not dashboard

by vivek_saini07

sorry that is not a good solution the better way is change org.jboss.portal.core.model.portal.command.action.MoveWindowCommand.execute() I commented the following condition | if (isDashboard()) | | And made that block executed always. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201751#4201751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201751

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by adrian＠jboss.org

"alesj" wrote : | Adrian, what would happen now if we used Javassist impl of TypeInfo? | Probably CtClass not found for some non 'default' classes? Its not complete. * The generics stuff isn't done because javassist didn't support generics when I originally wrote it. * There's an issue with the method reflection for non-public methods/fields when not using Sun's JDK. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201743#4201743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201743

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by alesj

"stale.pedersen(a)jboss.org" wrote : as we've stated in the aop design forum (and here) is that the current state of jboss-reflect is too limited for aop to use at all. a well designed MutableClassInfo can change that though. | What about if we just added 'mutable' wrapper/delegate. e.g. you would actually create your own ClassInfo impl based on existing JavassistCI: Extra stuff would be held in this mutable wrapper/delegate. When invoked, first check extra stuff if it exists, else delegate. "stale.pedersen(a)jboss.org" wrote : | - the possibility to create a classobjectrepresentation from a byte[]/File/Url | What exactly do you mean here? e.g. ClassInfo ci = factory.getClassInfo(byte[]/File/Url); ? "stale.pedersen(a)jboss.org" wrote : | - be able to change/add/remove fields/methods/constructors/classes similiar to what javassist support | How do you do this in your prototype? I guess a single place where you know the aop rules would be enough? e.g. AOP impl of TypeInfoFactory overridding instantiate method "stale.pedersen(a)jboss.org" wrote : | - do finegrained operations/checks ala annotation visibility (which is only possible with javassist and not java.lang.reflect afaik) | Annotation visibility? "stale.pedersen(a)jboss.org" wrote : | - be able to get a classobjectrepresentations (ala ClassFile in javassist) from an existing ClassInfo object | Why? This is/shoule be impl detail. "stale.pedersen(a)jboss.org" wrote : | - support scoped classpools | Yup. Adrian, what would happen now if we used Javassist impl of TypeInfo? Probably CtClass not found for some non 'default' classes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201729#4201729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201729

17 years, 2 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Maven refactoring

by kabir.khan＠jboss.com

jboss-aop-head-testsuite passes, but I am getting failures in http://hudson.qa.jboss.com/hudson/view/AOP/job/jboss-aop-head-jbossas-4.0... It is because jboss-aop_1_0.dtd and jboss-aop_2_0.xsd are missing from jboss-aop.jar. I added the following to aop/pom.xml | <resources> | <resource> | <directory>docs</directory> | <includes> | <include>jboss-aop_1_0.dtd</include> | <include>jboss-aop_2_0.xsd</include> | </includes> | </resource> | </resources> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201726#4201726 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201726

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Per window customization even when it is not dashboard

by vivek_saini07

i got it just change in org.jboss.portal.core.model.portal.command.isDashboard(). Make it return true always. I changed it to following. | public boolean isDashboard() | { | | // return dashboard; | return true; | } | | And it reflecting the change i wanted. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201723#4201723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201723

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by stale.pedersen＠jboss.org

if we could design us away from the usage of javassist.bytecode.ClassFile and perhaps include that into MutableClassInfo we would get away with only using the MCI object in aop. from what i can see now there is only one place where we use ClassFile for something else than getting annotation metadata and that is in org.jboss.aop.standalone.Compiler where its used to find classname from a byte[]. this can be done with CtClass too, but i guess that doing it with ClassFile is more efficient...? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201721#4201721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201721

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