[jboss-user] [JBoss AOP] - Re: Compile Time AOP in JBOSS
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: Compile Time AOP in JBOSS" To view the discussion, visit: https://community.jboss.org/message/777503#777503 -- Great :-) If you had to do anything special to compile it, please post here -- Reply to this message by going to Community [https://community.jboss.org/message/777503#777503] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Compile Time AOP in JBOSS
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: Compile Time AOP in JBOSS" To view the discussion, visit: https://community.jboss.org/message/777439#777439 -- i.e. the fix is identical to what you suggest -- Reply to this message by going to Community [https://community.jboss.org/message/777439#777439] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Compile Time AOP in JBOSS
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: Compile Time AOP in JBOSS" To view the discussion, visit: https://community.jboss.org/message/777438#777438 -- This actually seems to have been fixed in the 1.5 branch: http://anonsvn.jboss.org/repos/jbossas/branches/Branch_AOP_1_5/aop/src/main/org/jboss/aop/instrument/ClassicInstrumentor.java http://anonsvn.jboss.org/repos/jbossas/branches/Branch_AOP_1_5/aop/src/main/org/jboss/aop/instrument/ClassicInstrumentor.java See addHelperField() > [~] > $svn log --limit=3 > http://anonsvn.jboss.org/repos/jbossas/branches/Branch_AOP_1_5/aop/src/main/org/jboss/aop/instrument/ClassicInstrumentor.java > > http://anonsvn.jboss.org/repos/jbossas/branches/Branch_AOP_1_5/aop/src/main/org/jboss/aop/instrument/ClassicInstrumentor.java > > r106068 | mailto:flavia.rain...@jboss.com flavia.rain...@jboss.com | > 2010-06-15 19:33:03 +0100 (Tue, 15 Jun 2010) | 1 line > > > [JBAOP-796] Add an instance(Class) to AspectManager and make woven code > use that method instead of instance() > > r59554 | flavia.rainone | 2007-01-11 21:38:09 + (Thu, 11 Jan 2007) | 1 > line > > > Fixing Kabir's mistake > > r59532 | mailto:flavia.rain...@jboss.com flavia.rain...@jboss.com | > 2007-01-11 16:29:27 + (Thu, 11 Jan 2007) | 1 line > > > [JBAOP-317] Task done > > https://issues.jboss.org/browse/JBAOP-796 https://issues.jboss.org/browse/JBAOP-796 Unfortunately there is no 1.5.7.GA release so you would need to build the branch yourself -- Reply to this message by going to Community [https://community.jboss.org/message/777438#777438] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Compile Time AOP in JBOSS
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: Compile Time AOP in JBOSS" To view the discussion, visit: https://community.jboss.org/message/777402#777402 -- It has been years since I or anybody last touched this, so apologies if what I say is a bit vague. As you mention, there are two steps involved in this: 1) When deploying the .aop file as part of a classloader scoped ear that information should get added to a scoped AspectManager handling aspects for that classloader domain. 2) When populating the Advisor use the scoped classloader to find the scoped AspectManager. There were some slight changes in determining 1 in various app server versions but I don't think that is the problem here, rather as you say it is probably using the wrong classloader in 2). Originally we had this use the thread context classloader but later replaced it with an explicit AspectManager.instance(ClassLoader) method since TCL is not always deterministic. If you have support use the customer support portal for more help. If not, which version of JBoss AS are you using? You might be able to get around this problem by either trying to force the thread context classloader when your AspectManager.instance() method is called, or by building one of the versions at http://anonsvn.jboss.org/repos/jbossas/projects/aop/tags/ http://anonsvn.jboss.org/repos/jbossas/projects/aop/tags/ and upgrading your AS instance. -- Reply to this message by going to Community [https://community.jboss.org/message/777402#777402] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Compile Time AOP in JBOSS
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: Compile Time AOP in JBOSS" To view the discussion, visit: https://community.jboss.org/message/777395#777395 -- You used to need to list your .aop in application.xml http://docs.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/examples/injboss/aopInJbossPackaging.html http://docs.jboss.org/jbossaop/docs/2.0.0.GA/docs/aspect-framework/examples/injboss/aopInJbossPackaging.html (substitute @lib@ with xxx.aop) although that tutorial is from the old J2EE 1.4 days so your milage may vary. Also, note that JBoss AOP only works with JBoss AS 4.x-6.x, i.e. it will not work in AS 7. -- Reply to this message by going to Community [https://community.jboss.org/message/777395#777395] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: org.apache.xml excluded from precompilation?
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: org.apache.xml excluded from precompilation?" To view the discussion, visit: https://community.jboss.org/message/760586#760586 -- Apologies, I didn't see that you were using aopc, and confused it with the loadtime weaving configuration of the aspect manager in AS 4/5. What you did is correct, that system property has the effect of doing what you describe. Hope I didn't confuse you too much! -- Reply to this message by going to Community [https://community.jboss.org/message/760586#760586] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: org.apache.xml excluded from precompilation?
Kabir Khan [https://community.jboss.org/people/kabirkhan] created the discussion "Re: org.apache.xml excluded from precompilation?" To view the discussion, visit: https://community.jboss.org/message/760271#760271 -- It has been some years since looking at this code but you're right. The reason +org.apache.xml+ and other bits are excluded is they are things used by jboss aop internally. However there should be a '.' after the package names. It looks like a include should work, but that you are using the wrong format. Looking at https://svn.jboss.org/repos/jbossas/tags/JBPAPP_4_2_0_GA/aspects/src/resources/META-INF/jboss-service.xml https://svn.jboss.org/repos/jbossas/tags/JBPAPP_4_2_0_GA/aspects/src/resources/META-INF/jboss-service.xml (from jboss 4.2) to refresh my memory I think it should be: There should not be a '.class' at the end, and the separator is '.'. -- Reply to this message by going to Community [https://community.jboss.org/message/760271#760271] Start a new discussion in JBoss AOP at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: AOP in jboss AS 7
Kabir Khan [http://community.jboss.org/people/kabirkhan] created the discussion "Re: AOP in jboss AS 7" To view the discussion, visit: http://community.jboss.org/message/617001#617001 -- JBoss AOP is not part of AS 7. The main reason for having it in previous AS releases was for our EJB container, however in AS 7 a different mechanism is used. The AOP project has not been under active development for > 2 years, and getting it to work with the modular classloading setup in AS 7 will not be an easy task. So, there are no plans to include it in AS 7. -- Reply to this message by going to Community [http://community.jboss.org/message/617001#617001] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: How can I intercept methods in java.net.* or javax.*.*?
Kabir Khan [http://community.jboss.org/people/kabirkhan] created the discussion "Re: How can I intercept methods in java.net.* or javax.*.*?" To view the discussion, visit: http://community.jboss.org/message/605004#605004 -- There is no way using JBoss AOP. Once you start changing classes used by JBoss AOP itself at runtime (since everything is dynamic) you could end up with some very strange and unpredicatable behaviour :-) -- Reply to this message by going to Community [http://community.jboss.org/message/605004#605004] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Error in deploying .aop file
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Error in deploying .aop file" To view the discussion, visit: http://community.jboss.org/message/583862#583862 -- 2 Problems: [kabir ~/Downloads] $unzip -l LoggingAspect.aop Archive: LoggingAspect.aop Length Date Time Name 0 01-27-11 12:16 META-INF/ 71 01-27-11 12:16 META-INF/MANIFEST.MF *3436644 08-19-08 07:44 jboss-aop-jdk50-single.jar* 0 01-27-11 11:50 classes/ 0 01-27-11 11:50 classes/org/ 0 01-27-11 11:50 classes/org/jboss/ 0 01-27-11 11:50 classes/org/jboss/soa/ 0 01-27-11 11:50 classes/org/jboss/soa/esb/ 0 01-27-11 11:50 classes/org/jboss/soa/esb/samples/ 0 01-27-11 11:50 classes/org/jboss/soa/esb/samples/quickstart/ 0 01-27-11 12:12 classes/org/jboss/soa/esb/samples/quickstart/helloworld/ 1184 01-27-11 12:12 classes/org/jboss/soa/esb/samples/quickstart/helloworld/LoggingAspect.class 577 01-27-11 11:50 META-INF/jboss-aop.xml --- 3438476 13 files 1) jboss-aop-jdk50-single.jar should NOT be bundled with your application [kabir ~/Downloads] $unzip -p LoggingAspect.aop META-INF/jboss-aop.xml 2) For deployment in AS your xml must use aop beans namespace, e.g.: -- Reply to this message by going to Community [http://community.jboss.org/message/583862#583862] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: JBoss6 AOP Load-Time-Weaving
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: JBoss6 AOP Load-Time-Weaving" To view the discussion, visit: http://community.jboss.org/message/580150#580150 -- Can you try with 6.0.0.Final? This all looks like it is happening just booting the AS with the javaagent option set to true, which should work since we have tests for that. -- Reply to this message by going to Community [http://community.jboss.org/message/580150#580150] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Intercept an method call within a specific statement
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Intercept an method call within a specific statement" To view the discussion, visit: http://community.jboss.org/message/580146#580146 -- You could use cflow although that is very slow since it would need to create an exception to inspect the stack when you call getAddress() or getStree() -- Reply to this message by going to Community [http://community.jboss.org/message/580146#580146] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Binding annotated methods and session bean methods
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Binding annotated methods and session bean methods" To view the discussion, visit: http://community.jboss.org/message/578734#578734 -- I am not sure about which classloader ear/lib/common.jar belongs to. Try doing a System.out.println(this.getClass().getClassLoader()); System.out.println(Thread.currentThread().getContextClassLoader()); in some classes from your common.jar and ejb.jar to make sure they are the same. If they are not, try logging the parent classloaders. My guess is that the problem is that the common.jar classes cannot see the annotations or something like that. -- Reply to this message by going to Community [http://community.jboss.org/message/578734#578734] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Constructor Execution Pointcut Causing ArrayOutOfBounds
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Constructor Execution Pointcut Causing ArrayOutOfBounds" To view the discussion, visit: http://community.jboss.org/message/564658#564658 -- Is Bean an inner class? Unfortunately nobody is working actively on JBoss AOP at the moment but you seem very capable, so if you create a patch and a test we can make sure it gets included in the upstream code. If you're interested let me know and I can help with getting you set up. -- Reply to this message by going to Community [http://community.jboss.org/message/564658#564658] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Abstract and aop
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Abstract and aop" To view the discussion, visit: http://community.jboss.org/message/563732#563732 -- At a glance both your examples look like they should work but note that everything must be fully qualified. If by "it does not work" you mean you're not seeing any interception at all that is probably your problem. Try something like ... -- Reply to this message by going to Community [http://community.jboss.org/message/563732#563732] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: With compile-time weaving, why does AOP need run-time configuration?
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: With compile-time weaving, why does AOP need run-time configuration?" To view the discussion, visit: http://community.jboss.org/message/563731#563731 -- Because JBoss AOP is fully dynamic when it comes to weaving. It follows a two step process 1) When the class is woven (either at compile time or when the class is first woven) we put in the hooks for interception to happen. These hooks are the same for a member matching the pointcut expression of a element or a element. 2) When you create an instance of the class (at runtime) the advices are created according to the sub-elements of elements for its member hooks. -- Reply to this message by going to Community [http://community.jboss.org/message/563731#563731] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Poincut Expression
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Poincut Expression" To view the discussion, visit: http://community.jboss.org/message/561038#561038 -- You need to specify the return type for methods. So "execution(* com.mycompany.*->*(..))" should work (notice the extra '* ' before 'com.mycompany' -- Reply to this message by going to Community [http://community.jboss.org/message/561038#561038] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Poincut Expression
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Re: Poincut Expression" To view the discussion, visit: http://community.jboss.org/message/561039#561039 -- BTW you should use the user forums for this, not the design forums. I'm moving this thread there -- Reply to this message by going to Community [http://community.jboss.org/message/561039#561039] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/96#96 -- The times with the latest jboss-cl trunk: || || *Deploy (ms)* || *First Load (ms)* || *Load Cached* || | *Big ball of mud* | 977 | 669 | 12 | | *Package* | 1093 | 708 | 60 | | *Module* | 1205 | 710 | 60 | * Deploy is the time taken to install the classloader * First Load is the time taken to load the class first time * Load Cached is the time taken to load the class once it is already loaded In all cases the class comes from another loader than the initiating loader -- Reply to this message by going to Community [http://community.jboss.org/message/96#96] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/554175#554175 -- The new simpler scenario has a 100 jars with 10 packages and 15 classes per package, one loader per jar. The tests are called SiblingVFSXXXBenchmarkTestCase and they run as follows: Use Loader1 to load all its own classes and those from Loader2 Use Loader2 to load all its own classes and those from Loader3 ... For the exact classloading setups I make Loader 1 import the module/packages exported by Loader2 etc. I run the tests individually using e.g. mvn install -Dtest=SiblingVFSImportPackageLoaderBenchmarkTestCase Running each test individually, I get these average results over 7 runs || || *Deploy (ms)* || *Load Classes (ms)* || | *Big ball of mud* | 1439 | 4485 | | *Package* | 1321 | 4880 | | *Module* | 1461 | 4874 | The code lives in svn under https://svn.jboss.org/repos/jbossas/projects/cl-benchmark/trunk https://svn.jboss.org/repos/jbossas/projects/cl-benchmark/trunk Each family of tests uses its own AbstractTestSetCreator implementation which generates jars under their own directory, e.g. ThreeDeepTestSetCreator and SiblingTestCreator. The tests currently -- Reply to this message by going to Community [http://community.jboss.org/message/554175#554175] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/554118#554118 -- > David Bosschaert wrote: > I created the bundle bench mark test model to follow typical OSGi > deployments. Multiple levels are very common in that case, for instance: > > A customer bundle uses a product delivered as OSGi bundles. The product has > an API and an Implementation. The product uses some services from the > compendium which are implemented by a number of util bundles. Voila - that's > the test case structure. I understand and agree, but I think for this Ales wants a bare-bones comparison between exact classloading and the full visibility model, in this case it will probably be clearer with just one level of classes. I'm working on this now, and should hopefully have something in time for today's meeting. -- Reply to this message by going to Community [http://community.jboss.org/message/554118#554118] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/554012#554012 -- > Ales Justin wrote: > > > Ales, can you take a look at how I am setting up the > > VFSClassLoaderFactories? > > > Should be fine. > > So to get the tests straight. > Why the three level hierarchy depth? The three levels was inspired by David's stuff, as I understood it a load of one class triggers load of some others. It can certainly be made simpler though, so I can do a one-level set tomorrow. > Ales Justin wrote: > Who creates requirements and who provides the capabilities? > Why the re-export on module and package? The requirements and capabilities are set up in the individial tests. I'm not sure about the re-export, is it needed when Impl (loaderA) loads its superclass AbstractImpl (loaderB) which in turn brings in its interface (loaderC)? > > The thing I found strange was that for the Module test I had to specify the > > packages as a capability as well as the module, but I'm not that familiar > > with how this works so maybe that's how it should be. > What happens if you don't do this? I get an exception, IIRC NoClassDefFoundError when trying to load the superclass which comes from a loader that only exports the module and not also the packages. But maybe there is another setting to get around this? -- Reply to this message by going to Community [http://community.jboss.org/message/554012#554012] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Benchmarking classloaders"
To view the discussion, visit: http://community.jboss.org/message/553790#553790
--
I have got some basic benchmarks working. Instead of using AS classes, I am now
generating my own using Chiba's ClassFileWriter to have better control over
what exists where. The classes are only generated if the
target/generated-classes and target/generated-jars directories don't exist
already. You tell it how many jars to create, how many packages per jar and how
many classes per package. If you change these numbers, be sure to delete the
target/generated-* directories. So, if 2 is selected for each of these it then
creates the following jars:
interface0.jar:
org.jboss.test.interface0.pkg0.Interface0.class
org.jboss.test.interface0.pkg0.Interface1.class
org.jboss.test.interface0.pkg1.Interface0.class
org.jboss.test.interface0.pkg1.Interface1.class
interface1.jar:
org.jboss.test.interface1.pkg0.Interface0.class
org.jboss.test.interface1.pkg0.Interface1.class
org.jboss.test.interface1.pkg1.Interface0.class
org.jboss.test.interface1.pkg1.Interface1.class
abstract0.jar:
org.jboss.test.abstract0.pkg0.Abstract0.class
org.jboss.test.abstract0.pkg0.Abstract1.class
org.jboss.test.abstract0.pkg1.Abstract0.class
org.jboss.test.abstract0.pkg1.Abstract1.class
abstract1.jar:
org.jboss.test.abstract1.pkg0.Abstract0.class
org.jboss.test.abstract1.pkg0.Abstract1.class
org.jboss.test.abstract1.pkg1.Abstract0.class
org.jboss.test.abstract1.pkg1.Abstract1.class
impl0.jar:
org.jboss.test.impl0.pkg0.Impl0.class
org.jboss.test.impl0.pkg0.Impl1.class
org.jboss.test.impl0.pkg1.Impl0.class
org.jboss.test.impl0.pkg1.Impl1.class
impl1.jar:
org.jboss.test.impl1.pkg0.Impl0.class
org.jboss.test.impl1.pkg0.Impl1.class
org.jboss.test.impl1.pkg1.Impl0.class
org.jboss.test.impl1.pkg1.Impl1.class
An example of the expected inheritance hierarchies is:
class org.jboss.test.impl1.pkg1.Impl1 extends
org.jboss.test.abstract1.pkg1.Abstract1{}
class org.jboss.test.abstract1.pkg1.Abstract1 implements
org.jboss.test.interface1.pkg1.Interface1{}
I then create a classloader for each jar, with different classloading rules per
test and try to load the Impl classes from the implx.jar loaders, which
triggers searches for the superclasses/interfaces in the other classloaders.
Ales, can you take a look at how I am setting up the VFSClassLoaderFactories? I
do this in the TestCase classes. The thing I found strange was that for the
Module test I had to specify the packages as a capability as well as the
module, but I'm not that familiar with how this works so maybe that's how it
should be.
Running this a few times on a set of 50 jars with 10 packages per jar and 10
classes per package, I get the following results.:
Import/Export packages:
Deploying the VFSClassLoaderFactories and creating the loaders: 1862ms 1693ms
1847ms 1725ms 1706ms
Loading the classes: 5008ms 4883ms 4744ms 4893ms 5012ms
Export/ImportAll:
Deploying the VFSClassLoaderFactories and creating the loaders: 1657ms 1627ms
1659ms 1720ms 1573ms
Loading the classes: 4858ms 4693ms 4796ms 4714ms 4899ms
Import/Export module:
Deploying the VFSClassLoaderFactories and creating the loaders: 1785ms 1736ms
1766ms 1819ms 1901ms
Loading the classes: 4992ms 5609ms 5510ms 4991ms 5626ms
--
Reply to this message by going to Community
[http://community.jboss.org/message/553790#553790]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - Benchmarking classloaders
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Benchmarking classloaders" To view the discussion, visit: http://community.jboss.org/message/553265#553265 -- For AS 6 we might want to look at setting up imports and exports for the classloaders, which might be faster than using the current ImportAll/Big-ball-of-mud setting. However, that sounds like a very big task, so I we should benchmark this in isolation to see if imports/exports will actually be faster. I have something simple working for ImportAll, but need to think a bit about how to do this with imports and exports. -- Reply to this message by going to Community [http://community.jboss.org/message/553265#553265] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer] - MC not finding required method defined in beans.xml file
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "MC not finding required method defined in beans.xml file" To view the discussion, visit: http://community.jboss.org/message/552729#552729 -- What does your HRS.start() method look like? -- Reply to this message by going to Community [http://community.jboss.org/message/552729#552729] Start a new discussion in JBoss Microcontainer at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2114] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/551939#551939 -- Since the introspection implementation performs better than the javassist and bytecode implementations, I tried out something we mentioned on a call before JBoss World which was to use the introspection implementation and to generate the accessors. Unfortunately this also slows down bootup times, probably due to the time taken to generate and then load the class. -- Reply to this message by going to Community [http://community.jboss.org/message/551939#551939] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Weld - pull from MC
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Weld - pull from MC" To view the discussion, visit: http://community.jboss.org/message/551520#551520 -- So decorators are not supported for external beans no matter whether they are pushed or pulled. Also, I found that when we have a "pushed" external bean with a producer method which is wrapped with an alternative Producer implementation (such as our ExisitingInstanceMethodProducer), I can't see anything in the CDI api to be able to figure out which bean manager the call came from. i.e. there does not seem to be anything in the ProcessProducer event or in the CreationContext passed in to Producer.produce(). This means it is impossible to have producer methods with injected parameters in these producer methods coming from external beans. This works out of the box with the "pull" approach. -- Reply to this message by going to Community [http://community.jboss.org/message/551520#551520] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Weld - pull from MC
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Weld - pull from MC" To view the discussion, visit: http://community.jboss.org/message/550407#550407 -- Attaching svn diff, since trying to test decorators with this approach I run into some problems. I've also got some problems with decorators in the "push" approach. -- Reply to this message by going to Community [http://community.jboss.org/message/550407#550407] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss AOP] - calling aspect from netty thread inside jboss 5.1
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "calling aspect from netty thread inside jboss 5.1" To view the discussion, visit: http://community.jboss.org/message/550252#550252 -- Is the Thread.currentThread().getContextClassLoader() in MyNetworkListener what you would expect for your application? JBoss AOP doesn't really do anything fancy with classloaders unless your application uses isolated classloading, which I don't think is the case in your application. If you're using loadtime weaving, the -aop.xml stuff must be available before accessing the classes. For your basic.jar the deployers are smart enough to deploy the aop xml before the bean classes are loaded. Can you try getting rid of both jars, and then starting the server with basic.jar only. Once started deploy network.jar. If that helps, I'll dig out some resources on deployment ordering -- Reply to this message by going to Community [http://community.jboss.org/message/550252#550252] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - Weld - pull from MC
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created
the discussion
"Weld - pull from MC"
To view the discussion, visit: http://community.jboss.org/message/549944#549944
--
I have experimented with an alternate implementation of the weld-mc integration
as discussed in Boston. I still need to write more tests but wanted to let the
Weld guys know where I am at.
The idea is to "pull" data from the MC in special cases, which is different
from the "push" we do at the moment for MC beans annotated with @WeldEnabled. I
had a look at using the InjectionServices interface, but this has the following
problems:
-It does not get triggered when calling constructors
-If using a separate @McInject annotation instead of @Inject to do injection
the annotated field does not appear in invocation context's injection points
meaning all the fields etc. need to be parsed from invocation context's
target's class (I am not sure if the target will always be non-null?)
-If using the @Inject annotation with an additional @Mc annotation (to look up
the particular injection point in the MC) falls over when calling proceed(),
also again a problem is that you need to iterate over all fields etc. to look
for the members. This also fails in the validation phase.
As mentioned the ability to do this injection from MC is something that most
Weld applications would not want to do. What I have locally now is an extra
service that can handle this:
package org.jboss.temp.weld.spi;
import java.lang.annotation.Annotation;
import java.util.Iterator;
import org.jboss.weld.bootstrap.api.Service;
public interface ExternalLookupRegistryService extends Service
{
Iterable> getExternalLookups();
void addExternalLookup(ExternalLookup externalLookup);
boolean removeExternalLookup(Class clazz);
}
And then a service to handle particular annotations
package org.jboss.temp.weld.spi;
import java.lang.annotation.Annotation;
import java.lang.reflect.Type;
import java.util.Set;
public interface ExternalLookup
{
Class getAnnotation();
boolean isValid(Type type, Set qualifiers);
Object lookupValue(Type type, Set qualifiers);
}
I'm hoping to be able to push these interfaces into the main spi, the temp
location I am using is just while playing.
Then I have modified the Validator and Field-/ParameterInjectionPoint to look
for this service when validating/injecting:
> [kabir ~/sourcecontrol/weld/core/subversion]
> $svn diff impl/src/main/java/org/jboss/weld/bootstrap/Validator.java
> Index: impl/src/main/java/org/jboss/weld/bootstrap/Validator.java
> ===
> --- impl/src/main/java/org/jboss/weld/bootstrap/Validator.java (revision
> 6577)
> +++ impl/src/main/java/org/jboss/weld/bootstrap/Validator.java (working
> copy)
> @@ -83,6 +83,8 @@
> import javax.inject.Scope;
>
> import org.jboss.interceptor.model.InterceptionModel;
> +import org.jboss.temp.weld.spi.ExternalLookup;
> +import org.jboss.temp.weld.spi.ExternalLookupRegistryService;
> import org.jboss.weld.bean.AbstractClassBean;
> import org.jboss.weld.bean.AbstractProducerBean;
> import org.jboss.weld.bean.DisposalMethod;
> @@ -288,6 +290,16 @@
> Set resolvedBeans =
> beanManager.getBeanResolver().resolve(beanManager.getBeans(ij));
> if (!isInjectionPointSatisfied(ij, resolvedBeans, beanManager))
> {
> + ExternalLookupRegistryService service =
> beanManager.getServices().get(ExternalLookupRegistryService.class);
> + if (service != null)
> + {
> + for (ExternalLookup lookup : service.getExternalLookups())
> + {
> + if
> (ij.getAnnotated().isAnnotationPresent(lookup.getAnnotation()))
> + if (lookup.isValid(ij.getType(), ij.getQualifiers()))
> + return;
> + }
> + }
> throw new
> DeploymentException(INJECTION_POINT_HAS_UNSATISFIED_DEPENDENCIES, ij,
> Arrays.toString(bindings));
> }
> if (resolvedBeans.size() > 1 && !ij.isDelegate())
>
>
>
> [kabir ~/sourcecontrol/weld/core/subversion]
> $svn diff impl/src/main/java/org/jboss/weld/injection/
> Index: impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java
> ===
> ---
> impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java (revision
> 6577)
> +++
> impl/src/main/java/org/jboss/weld/injection/FieldInjectionPoint.java (working
> copy)
> @@ -36,6 +36,8 @@
> import javax.inject.Inject;
>
> impo
Re: [jboss-user] [EJB 3.0 Development] - Looking up no-interface views
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Looking up no-interface views" To view the discussion, visit: http://community.jboss.org/message/547859#547859 -- > jaikiran pai wrote: > > Marius Bogoevici wrote: > > > > Btw, how do you plan on dealing with this? Supply the bean class as the > > "interface" of the EJB reference ? > > > Yes, that's the plan right now. > > I'll update this thread once I am something ready around this. If you're planning on generating classes, javassist now contains a superfast ClassFileWriter API. It is lower level than the CtClass API, meaning you have to code in the Opcodes yourself, but it is fast and outperforms ASM. -- Reply to this message by going to Community [http://community.jboss.org/message/547859#547859] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2030] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss AOP] - Maven plugin annotations parsing
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Maven plugin annotations parsing" To view the discussion, visit: http://community.jboss.org/message/545801#545801 -- Try using pointing to the directory containing your annotated classes. Here is a snippet from the pom of the annotated-aspects example in the aop distribution run . Driver run -- Reply to this message by going to Community [http://community.jboss.org/message/545801#545801] Start a new discussion in JBoss AOP at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2027] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/544244#544244 -- Ales mentioned that it might be worth looking at making the original implementation lazy instead of introducing an extra "wrapper", which sounded like a good idea. However, thinking about this a bit more I then end up having to hit the classpool which is what I wanted to avoid in the first place. The reason is that when calling i.e. JavassistMethodInfo.getReturnType() we don't know the classpool/loader of the return type, instead we call get() in my previous post with the MethodInfo.getDeclaringClass()'s classloader, which is the only way I can think of to find the classloader. Otherwise we end up possibly using the wrong cache when obtaining the type info. So although we avoid the overhead of b) in my last post we still end up with a) If I am to go forward with doing it this way, then I think we'll have to look into optimizing the classpools. -- Reply to this message by going to Community [http://community.jboss.org/message/544244#544244] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/544167#544167
------
> Kabir Khan wrote:
>
> Another observation is that quite a few calls to
> JavassistMethodInfo.getParameterTypes() are only interested in the length of
> the parameters and the names of the parameter types, so it might be an idea
> to return an array of "lazy" type infos which only know the name and the
> declaring typeinfo. I can be found out easily from the raw method signature
> (I am already passing the SignatureKey into JavassistMethodInfo and using
> that in its equals() method to avoid having to load parameters there). Once
> something more advanced is called, then that could obtain the real typeinfo
> and delegate to that. I'm not 100% sure yet if this is what I want to do.
I've looked more into this and will try out "lazy" type infos. When
constructing the BeanInfos, it goes through and calls
MethodInfo.getReturnType() and MethodInfo.getParameterTypes(). These calls are
really heavy, and at least for this use-case we don't care about anything apart
from the name. Behind the scenes, what happens for each parameter is:
a) It hits the classpool to load the CtClass
b) When creating the type info it needs to check if the class is an enum or
annotation, the first time you call anything apart from CtClass.getName() it
needs to load the underlying ClassFile. This is slow, but initialises the
CtClass for future use.
a) and b) seem to take about the same time, although b) probably varies with
class size. I don't think we can do much about b) apart from trying to avoid it
at all costs.
Another observation in favour of optimizing the classpools further is needing
to do this in JavassistTypeInfoFactory.get() (pseudocode)
public TypeInfo get(ClassLoader cl, String name){
Cache cache = getCacheForLoader(cl);
TypeInfo info = cache.get(name);
if (info != null)
return info;
//The passed in classloader is not necessarily the one where the class
lives,
//so we need to hit the pool to find out where it comes from
ClassPool pool = getPoolForLoader(cl);
CtClass clazz = pool.get(name);
if (clazz.getClassPool().getClassLoader() != cl)
{
cl = clazz.getClassPool().getClassLoader();
cache = getCacheForLoader(cl);
info = cache.get(name);
if (info != null)
return info;
}
info = instantiate(clazz);
cache.cache(info);
return info;
}
We need to query the pool to figure out the correct classloader
--
Reply to this message by going to Community
[http://community.jboss.org/message/544167#544167]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/543921#543921
--
Although too early to say yet, it looks like the classpools are a bottleneck. I
have started caching things a bit more and that is speeding things up somewhat.
For example calling CtBehavior.getParameterTypes() is slow since it does not
cache the parameter types, instead for every call to this it parses the method
signature and then hits the classpools for every class. I am attempting to
avoid that as much as possible.
Another observation is that quite a few calls to
JavassistMethodInfo.getParameterTypes() are only interested in the length of
the parameters and the names of the parameter types, so it might be an idea to
return an array of "lazy" type infos which only know the name and the declaring
typeinfo. I can be found out easily from the raw method signature (I am already
passing the SignatureKey into JavassistMethodInfo and using that in its
equals() method to avoid having to load parameters there). Once something more
advanced is called, then that could obtain the real typeinfo and delegate to
that. I'm not 100% sure yet if this is what I want to do.
Once I am done with caching things as much as possible, we'll see if the
classpools are still a bottleneck since there will be a lot less calls. If they
are, I have an idea for how to change them into something simpler, but just
want to jot it down so Flavia can take a look and see if she thinks it is a
good idea or if I have missed something.
The idea is quite simple, rather than managing the domains and pools and
essentially recreating what the classloaders do, it might make sense to
delegate everything to the classloaders. If we had a method like this, as I
discussed with Ales (let's say it goes in the ClassLoading class, although
where is up to Ales):
ClassLoader getClassLoaderForClass(ClassLoader initiating, String classname);
And we have a map of classpools by classloader in the classpool registry.
Then I think our "dumb" class pool would not need much more than this - it has
a null parent
class DumbClassPool extends ClassPool{
WeakReference cl;
ClassPoolRepository repo;
DumbClassPool(ClassLoader cl, ClassPoolRepository repo){
this.cl = new WeakReference(cl);
this.repo = repo;
}
CtClass get(String classname){
//Check cache first, if not found then do the rest
CtClass clazz = super.get0(classname);
if (clazz != null)
return clazz;
String real = adjustForArraysAndPrimitives(classname);
ClassLoader loader = ClassLoading.getClassLoaderForClass(cl.get(),
real);
ClassPool pool = repo.registerClassLoader(loader);
if (pool != null)
{
clazz = pool.getOrNull(classname); //new method from Chiba that does
not throw NFE, but behaves like get()
}
if (clazz != null)
//cache class
else
throw new NotFoundException
}
}
I'd obviously be extending ScopedClassPool or whatever is needed in AOP and
other places. It would also have some knowledge of the domain and get notified
when loaders get added/removed to the domain so the caches in the pools can be
invalidated. There will probably be a bit more to it than this, but this is the
basic idea.
--
Reply to this message by going to Community
[http://community.jboss.org/message/543921#543921]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/542599#542599 ------ > Kabir Khan wrote: > > I'll try to dig in to the errors tomorrow, although I am not sure how much > time I will spend on this since we are only really targeting AS 6 with the > current AOP releases, supporting previous AS versions is just us "being nice". > I ran the tests. In AS 4 it is fine apart from I don't have time to look into this now. I am in the process of releasing AOP 2.2.1.Alpha1 and have raised https://jira.jboss.org/jira/browse/JBAOP-790 https://jira.jboss.org/jira/browse/JBAOP-790 for 2.2.1.GA -- Reply to this message by going to Community [http://community.jboss.org/message/542599#542599] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/542584#542584 -- IRC discussion > > kkhan:ping ALR > > [14:24]ALR:kkhan: Hey > > [14:24]kkhan:ALR: Regarding my bootstrap stuff I think you're right > > [14:24] ggear joined the chat room. > > [14:24] ggear was granted voice by ChanServ. > > [14:25]kkhan:too many dependencies on classpools and other stuuff > > [14:25]ALR:kkhan: Yup, saw your post. > > [14:25]kkhan:ALR: Are you ok with me adding the correct hooks for events > where I need them, or do you prefer doing so yourself > > [14:25]ALR:Also we should be making sure all commits/features get testied > > [14:26]ALR:kkhan: Sure, you can add them. I'll give some opinions and help > guide as you need. > > [14:26]kkhan:ALR: Yeah, what I had wasn't really meant to be committed, it > was more a basis for further instructions > > [14:26]kkhan:*further discussion > > [14:26]ALR:kkhan: Ah OK. I put it in to facilitate testing > > [14:26]ALR:But hadn't really planned on releasing like that > > [14:26]ALR:kkhan: I'll reply to your post, but also > > [14:26]ALR:: > > [14:26]ALR:I got that ClassLoading SPI test passing > > [14:27]kkhan:ok cool > > [14:27]ALR:Let's see what events you need: > > [14:27]kkhan:ALR: It probably makes sense to rever what I had done to get rid > of all the deps > > [14:27]kkhan:and then do it properly > > [14:27]kkhan:so I didn't really look into the ClassLoading SPI test since > that was more deps > > [14:27]ALR: > http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/api/src/main/java/org/jboss/bootstrap/api/lifecycle/LifecycleState.java > > http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/api/src/main/java/org/jboss/bootstrap/api/lifecycle/LifecycleState.java > > [14:28]kkhan:I want something like PRE_KERNEL_BOOTSTRAP and > POST_KERNEL_BOOTSTRAP > > [14:29]kkhan:ALR: Sound ok? > > [14:29]ALR:kkhan: Not really in its current form > > [14:30]ALR:As "Kernel" is an MC construct > > [14:30]ALR:And these LifecycleStates are in the main API > > [14:30]kkhan:Actually, I probably don't need the PRE one that can be done > whenever > > [14:30]kkhan:i.e. early > > [14:30]ALR:kkhan: "INSTANCIATED" > > [14:30]ALR:Or maybe PRE_INIT > > [14:31]ALR:And the "post", when exactly does that need to happen? > > [14:31]kkhan:The post needs to happen after the kernel has been bootstrapped, > but before anything else has been deployed > > [14:32]ALR:kkhan: By "deployed", you mean processing the bootstrap XMLs? > > [14:32]kkhan:yes > > [14:32] pgier joined the chat room. > > [14:32] pgier was granted voice by ChanServ. > > [14:32]ALR:OK > > [14:32]ALR:Lemme look > > [14:33]kkhan:ALR: I think a PRE_CONFIG or POST_CONFIG state would do the > trick, to be raised by AbstractServer.doInitialize() somewhere > > [14:33]kkhan:That should be generic enough > > [14:33]ALR:Yep > > [14:33]kkhan:ALR: Ok, I'll go with that then > > [14:34]ALR:Just need to think of a good name. > > [14:34]ALR:I think "PRE_BOOTSTRAP", "POST_BOOTSTRAP"? > > [14:34]kkhan:Hmm, not sure > > [14:34] vblagoje joined the chat room. > > [14:35]ALR:That's essentially what we're doing. > > [14:35]kkhan:Since only AbtractMCServerBase calls bootstrap > > [14:35]ALR:The generic API knows about bootstraps. > > [14:35]kkhan:So where do I raise it? > > [14:35]ALR:Yes, but that's only because it's our only impl. > > [14:35]ALR:We could also, for instance, have a Fungal (JCA Kernel) > implementation. > > [14:36]ALR:So you'd fire the callbacks in AbstractMCServerBase, yes. > > [14:36]ALR:Or at a higher level, even better, if you could refactor to get > the right wiring. > > [14:37]kkhan:I think I'd like to trigger it from AbstractServer.doInitialize() > > [14:37]ALR: > http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-base/src/main/java/org/jboss/bootstrap/impl/base/server/AbstractServer.java > > http://anonsvn.jboss.org/repos/jbossas/projects/bootstrap/trunk/impl-base/src/main/java/org/jboss/bootstrap/impl/base/server/AbstractServer.java > > [14:37]ALR:Yes, all you need to do is call "setState" > > [14:37]kkhan:Just need the name > > [14:38] smarlow is now known as sm
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/542553#542553 -- I forgot to mention that I have converted the JavassistMemberFactory to use the new http://anonsvn.jboss.org/repos/javassist/trunk/src/main/javassist/bytecode/ClassFileWriter.java ClassFileWriter API -- Reply to this message by going to Community [http://community.jboss.org/message/542553#542553] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/542552#542552
------
> Kabir Khan wrote:
>
> I have done some performance measurements where I compare the times taken
> creating the following class, using javassist.bytecode.* and asm
>
>
> *public* *class* JavassistMethod1 *implements* JavassistMethod
> {
> *public* Object invoke(Object target, Object[] args) *throws* Throwable
> {
> *return*
> Integer.valueOf(((SomeClass)target).someMethod(((Integer)args[0]).intValue(),
> (String)args[1])).intValue();
> }
> }
>
>
>
>
>
>
> Which would be used to call the method:
>
> *int* someMethod(*int* i, String);
>
>
>
>
>
>
> The basic flow for what I do for both approaches is the same, whereby I do
> the following lots of times to generate lots of similar classes:
>
>
>
>
>
> A) - Create class structure
>
> B) - Add default constructor with body to call super
>
> C) - Add invoke method
>
> C1) - Add invoke method body
>
> D) - Convert class structure from A) into byte[]
>
> E) - Define java.lang.Class by calling ClassLoader.defineClass()
>
> F) - Call Class.newInstance()
Chiba has done some great work on creating a new API for Javassist tailor made
to create new classes. Taking the defining of the class and instantiating it
out of the equation (since that is JVM stuff out of our control), so we do A-D
so we have the bytes ready to create the class the times are now for creating
2 JavassistMethod implementations
|| *ASM* || *Javassist ClassFile* || JavassistClassFileWriter ||
| 476 | 1030 | 356 |
| 613 | 1056 | 269 |
| 483 | 1076 | 309 |
| 464 | 1001 | 357 |
| 383 | 1186 | 315 |
I have attached the modified benchmark
--
Reply to this message by going to Community
[http://community.jboss.org/message/542552#542552]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/542427#542427 -- > Andrew Rubinger wrote: > > Corrected the failing tests, made a couple other lil' tweaks. > > https://jira.jboss.org/jira/browse/JBBOOT-134 > https://jira.jboss.org/jira/browse/JBBOOT-134 > > Still something I'd like to investigate is moving some of these bits to event > handlers or elsewhere. This patch brings in a lot of dependencies I'd like > to understand/justify. If this is primarily for AS, what's the overhead in > pure MC servers, where this is placed? If the answer is more than "nothing", > we may have to extract this stuff out a bit so pure MCServer performance > doesn't deteriorate. > > S, > ALR I agree these classpool bits should not be hard-coded in AbstractMcServerBase.doInitialize(). If the events and event handlers can be made more fine-grained or "precise" as to when they occur (as mentioned what I added must happen in *exactly* the place it does, although it might be possible to move the installation of the config bean into MC before the call to super.initialize()) then we should do that. The quick way would be to just add two new events, PRE_BOOTSTRAP and POST_BOOTSTRAP and raise them from where I am doing so, but I don't want to mess up your code if you have other ideas :-) This is primarily for AS since what my new stuff does is basically to set up javassist classpools understanding the AS classloading, normal MC setups probably will not need to do that, or might need to do something else. The overhead is installing a new bean waiting for the ClassLoading bean to be installed, which then installs itself as a ModuleRegistry in the ClassLoading bean. This ModuleRegistry then gets notified as classloader Modules are added/removed and does some work. So the overhead isn't exactly "nothing", so it should go somewhere else once we can have the event handlers triggered where I need them. I guess these event listeners could go into a different module in bootstrap or elsewhere. As long as the jars containing them are on the classpath, I think AS Main could just call registerEventHandler() after creating the server instance but before initializing it. -- Reply to this message by going to Community [http://community.jboss.org/message/542427#542427] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/542120#542120 -- I ran the tests. In AS 4 it is fine apart from > > $more > output/reports/TEST-org.jboss.test.aop.test.ScopedAttachUnitTestCase.txt > > Testsuite: org.jboss.test.aop.test.ScopedAttachUnitTestCase > > Tests run: 6, Failures: 0, Errors: 1, Time elapsed: 2.041 sec > > > > Testcase: testPOJOAdvised1 took 0.276 sec > > Testcase: testPOJOAdvised2 took 0.115 sec > > Testcase: testExpectedValues1 took 0.088 sec > > Testcase: testExpectedValues2 took 0.073 sec > > Testcase: testScoped1 took 0.324 sec > > Testcase: testScoped2 took 0.275 sec > > Caused an ERROR > > null > > javax.management.RuntimeMBeanException > > at > org.jboss.mx.interceptor.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:176) > > at > org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:163) > > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) > > at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) > > at > org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) > > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) > > at > org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) > > at > org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) > > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) > > at > org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) > > at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) > > at > org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) > > at > org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74) > > at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) > > at > org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) > > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) > > at > org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) > > at > org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) > > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) > > at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) > > at > org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) > > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) > > at > org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818) > > at > org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419) > > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) > > at sun.rmi.transport.Transport$1.run(Transport.java:159) > > at java.security.AccessController.doPrivileged(Native Method) > > at sun.rmi.transport.Transport.serviceCall(Transport.java:155) > > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) > > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) > > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > > at java.lang.Thread.run(Thread.java:637) > > Caused by: java.lang.RuntimeException: Error generating joinpoint class for > joinpoint Constructor[constructor=public > org.jboss.test.aop.scopedattach.POJO()] > > at > org.jboss.aop.instrument.JoinPointGenerator.doGenerateJoinPointClass(JoinPointGenerator.java:310) > > at > org.jboss.aop.instrument.JoinPointGenerator.access$300(JoinPointGenerator.java:77) > > at > org.jboss.aop.instrument.JoinPointGenerator$GenerateJoinPointClassAction$2.generateJoinPointClass(JoinPointGenerator.java:1730) > > at > org
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/542104#542104 -- I have committed my changes to AOP against https://jira.jboss.org/jira/browse/JBAOP-788 https://jira.jboss.org/jira/browse/JBAOP-788. I've tested the jars and the new aop.xml in AS 5.1.0 and it seems to work well. Tomorrow I will make sure the install script works for AS 5.1 (so far I have been updating the jars and aop.xml manually) and AS 4.2.3, and run the aop testsuites for both before closing the issue and releasing AOP 2.2.1. -- Reply to this message by going to Community [http://community.jboss.org/message/542104#542104] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/542040#542040 -- The attached patch contains my changes to bootstrap. I still have not refactored it into LifecycleEventHandlers since this needs to happen exactly where it currently does. The initialization of JBossClClassPoolConfig could possibly be moved into one, but the JBossClClassPoolConfig bean needs to be installed before AbstractJBossASServerBase.doInitialize() calls setupBootstrapDescriptorsFromBootstrapUrl(). -- Reply to this message by going to Community [http://community.jboss.org/message/542040#542040] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/541650#541650 -- The AS testsuite aop tests and smoke tests now all pass in my local copy. I need to refactor what I have done for the bootstrap a bit, and then I need releases of: * bootstrap * classpool * reflect * kernel * aop Andrew has volunteered to do bootstrap, and I will do the rest. -- Reply to this message by going to Community [http://community.jboss.org/message/541650#541650] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/541611#541611 ------ > Kabir Khan wrote: > It is getting confused somewhere about the > ControllerStateModel.ControllerStateWrappers Fixed for https://jira.jboss.org/jira/browse/JBKERNEL-119 https://jira.jboss.org/jira/browse/JBKERNEL-119 -- Reply to this message by going to Community [http://community.jboss.org/message/541611#541611] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"ClassPool bootstrap refactoring"
To view the discussion, visit: http://community.jboss.org/message/541501#541501
--
I have modified JBoss AOP and my local bootstrap/aop.xml to understand the new
classpool setup. AS boots up properly with this and all the aop AS testsuite
passes apart from ScopedWovenDependencyTestCase and
NotWovenScopedDependencyTestCase. I have reproduced the problem I see for those
in kernel with the following test
public void testInstallAndUninstallDependencyWithExtraState() throws
Throwable
{
getKernel().getController().addState(ControllerState.newState(),
ControllerState.INSTALLED);
installAndUninstallDependencyWithExtraState();
//context2 goes in scoped controller and depends on context1
ControllerContext context2 = assertInstall(offSetNumber(1), "Name2",
ControllerState.INSTANTIATED);
//context1 goes in main controller
ControllerContext context1 = assertInstall(offSetNumber(0), "Name1",
ControllerState.INSTALLED);
context1 = assertContext("Name1");
context2 = assertContext("Name2");
assertUninstall("Name1"); //Gives error
assertContext("Name2", ControllerState.INSTANTIATED);
assertUninstall("Name2");
assertNotInstalled("Name1");
assertNotInstalled("Name2");
}
The error is
> 1357 WARN [AbstractKernelController] Error uninstalling from Installed:
> name=Name2 state=Installed
>
> java.lang.NullPointerException
>
> at
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1632)
>
> at
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1476)
>
> at
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1541)
>
> at
> org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:1476)
>
> at
> org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:760)
>
> at
> org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:673)
>
> at
> org.jboss.test.kernel.dependency.support.TestUtil.uninstall(TestUtil.java:110)
>
> at
> org.jboss.test.kernel.dependency.support.ScopedTestUtil.uninstall(ScopedTestUtil.java:81)
>
> at
> org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.uninstall(OldAbstractKernelDependencyTest.java:118)
>
> at
> org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.assertUninstall(OldAbstractKernelDependencyTest.java:151)
>
> at
> org.jboss.test.kernel.dependency.test.ExtraStateTestCase.testInstallAndUninstallDependencyWithExtraState(ExtraStateTestCase.java:95)
>
>
It is getting confused somewhere about the
ControllerStateModel.ControllerStateWrappers
--
Reply to this message by going to Community
[http://community.jboss.org/message/541501#541501]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPool bootstrap refactoring" To view the discussion, visit: http://community.jboss.org/message/541026#541026 -- https://jira.jboss.org/jira/browse/CLASSPOOL-7 https://jira.jboss.org/jira/browse/CLASSPOOL-7 As part of this, I have had to refactor things a bit so there is another module called jbosscl-as which contains the reference to AbstractDeploymentClassLoaderPolicyModule previously done in VFSClassLoaderDomainRegistry. The reason for this is that ADCLPM is not available until the deployers.xml classloader is deployed, so I was getting some errors trying out this in the AS bootstrap. The next step is to change aop.xml to reuse the classpools from the bootstrap. -- Reply to this message by going to Community [http://community.jboss.org/message/541026#541026] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/540441#540441
------
> Kabir Khan wrote:
>
> Removing the cache for parameterized types largely works, although I need to
> fix some StackOverflowErrors when using recursive bound type variables such as
>
> *public* *class* ClassInfoTypeVariableRecursiveBounded ClassInfoTypeVariableRecursiveBounded>
> {
> *public* T genericTypeVariableRecursiveBounded(T param, String s)
> {
> *return* *null*;
> }
>
> }
>
This has been fixed. I needed to add this method to ClassInfo
/**
* Gets the type variable if we are a parameterized type which is part of a
* parameterized type and there is a type variable for this type. This is
* useful in avoiding infinite recursion
*
* @return the type variable
*/
String getTypeVariable();
--
Reply to this message by going to Community
[http://community.jboss.org/message/540441#540441]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/540332#540332
--
Removing the cache for parameterized types largely works, although I need to
fix some StackOverflowErrors when using recursive bound type variables such as
*public* *class* ClassInfoTypeVariableRecursiveBounded>
{
*public* T genericTypeVariableRecursiveBounded(T param, String s)
{
*return* *null*;
}
}
--
Reply to this message by going to Community
[http://community.jboss.org/message/540332#540332]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539885#539885
--
> I have tried turning off caching for these parameterized ClassInfos, which
> causes some of the tests to fail. From what I can see fixing them means
> having to adjust some of the tests to use assertEquals() instead of
> assertSame() for parameterized ClassInfos. I think this is necessary, and
> that the idea of enforcing object equality for parameterized ClassInfos is a
> misunderstanding :-)
Apart from this local fix in BeanInfoCacheTestCase, all the other places that
test object equality for parameterized class infos are in tests written by me
as part of JBREFLECT-5, so I think I am safe to readjust the tests
[kabir ~/sourcecontrol/jboss-reflect/trunk/jboss-reflect]
$svn diff src/test/
Index: src/test/java/org/jboss/test/beaninfo/test/BeanInfoCacheTestCase.java
===
---
src/test/java/org/jboss/test/beaninfo/test/BeanInfoCacheTestCase.java (revision
104118)
+++
src/test/java/org/jboss/test/beaninfo/test/BeanInfoCacheTestCase.java (working
copy)
@@ -125,16 +125,45 @@
{
BeanInfo beanInfo = getConfiguration().getBeanInfo(typeInfo);
ClassInfo typeInfo2 = beanInfo.getClassInfo();
- assertSame(typeInfo, typeInfo2);
+ assertClassInfos(typeInfo, typeInfo2);
}
-
+
private void assertClassInfo(ClassInfo typeInfo, String className,
ClassLoader cl) throws Exception
{
BeanInfo beanInfo = getConfiguration().getBeanInfo(className, cl);
ClassInfo typeInfo2 = beanInfo.getClassInfo();
- assertSame(typeInfo, typeInfo2);
+ assertClassInfos(typeInfo, typeInfo2);
}
+ private void assertClassInfos(TypeInfo typeA, TypeInfo typeB)
+ {
+ ClassInfo classA = assertInstanceOf(typeA, ClassInfo.class);
+ ClassInfo classB = assertInstanceOf(typeB, ClassInfo.class);
+
+ if (classA.getRawType() == classA)
+ assertSame(classA, classB);
+ else
+ {
+ assertEquals(classA, classB);
+ TypeInfo[] argsA = classA.getActualTypeArguments();
+ TypeInfo[] argsB = classB.getActualTypeArguments();
+
+ if (argsA != null)
+ assertNotNull(argsB);
+ if (argsB != null)
+ assertNotNull(argsA);
+ if (argsA == null)
+ {
+ assertNull(argsB);
+ return;
+ }
+
+ assertEquals(argsA.length, argsB.length);
+ for (int i = 0 ; i < argsA.length ; i++)
+ assertClassInfos(argsA[i], argsB[i]);
+ }
+ }
+
@SuppressWarnings("unchecked")
protected Type getType(String type, Class clazz) throws Exception
{
--
Reply to this message by going to Community
[http://community.jboss.org/message/539885#539885]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBREFLECT-5 - Implementing generics in JavassistClassInfo" To view the discussion, visit: http://community.jboss.org/message/539884#539884 -- Some information from Andrew Haley to a mail where I asked him about the class loaders of parameterized types: > I don't think that it makes any sense even to talk about the class > loader that was used to create a ParameterizedType. Clearly there was > a class loader used to resolve the class names that are passed when a > ParameterizedType is created, but I don't think the information is > recorded anywhere. > > > > The core bug here seems to be that cacheing is being done > inappropriately. > > > > Can you write a test case, please? One that demonstrates the bug in > > > > //Fails - loader is loaderA > assertEquals(loaderB, infoB.getActualTypeArguments[0].getClassLoader()); > > > > It has to be complete and runnable as a standalone program. -- Reply to this message by going to Community [http://community.jboss.org/message/539884#539884] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539876#539876
--
>
> Type t1 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
> Type t2 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
>
Should be
Type t1 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
Type t2 = DeleteMe.class.getDeclaredMethod("m2").getGenericReturnType();
but the result is the same
--
Reply to this message by going to Community
[http://community.jboss.org/message/539876#539876]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539875#539875
------
> Kabir Khan wrote:
>
> One way around this would be in mi.getReturnType() when looking
> up/creating/caching the parameterized class info to use the classloader of
> mi.getDeclaringClass().getClassLoader(), which should be able to see all the
> classes involved. However, I am still stuck on which classloader to use for
> my previous post.
This works, however for "1 - other problem" I don't really see a way to
determine the classloader. It could be the classloader of the raw type, or the
loader of any of the class infos. It might be possible to determine which of
the classloaders can see all the generic bounds by brute force, but that will
probably
a) Be slow
b) Might not be possible, i.e. maybe none of the classloaders for any of the
bounds are able to load everything.
I have tried turning off caching for these parameterized ClassInfos, which
causes some of the tests to fail. From what I can see fixing them means having
to adjust some of the tests to use assertEquals() instead of assertSame() for
parameterized ClassInfos. I think this is necessary, and that the idea of
enforcing object equality for parameterized ClassInfos is a misunderstanding :-)
Java itself does not seem to reuse the ParameterizedTypes, as shown by this
simple passing test:
public class DeleteMe extends ContainerTest
{
public DeleteMe(String name)
{
super(name);
}
public Set m1(){return null;}
public Set m2(){return null;}
public void testType() throws Exception
{
Type t1 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
Type t2 = DeleteMe.class.getDeclaredMethod("m1").getGenericReturnType();
ParameterizedType p1 = assertInstanceOf(t1, ParameterizedType.class);
ParameterizedType p2 = assertInstanceOf(t2, ParameterizedType.class);
//The param are equal, but not the same
assertEquals(p1, p2);
assertNotSame(p1, p2);
//The raw types are the same
assertSame(p1.getRawType(), p2.getRawType());
assertEquals(1, p1.getActualTypeArguments().length);
assertEquals(1, p2.getActualTypeArguments().length);
Class clazz1 = assertInstanceOf(p1.getActualTypeArguments()[0],
Class.class);
Class clazz2 = assertInstanceOf(p2.getActualTypeArguments()[0],
Class.class);
assertSame(clazz1, clazz2);
}
}
--
Reply to this message by going to Community
[http://community.jboss.org/message/539875#539875]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539766#539766
--
2 - classloader for parameterized type
I posted this last night right after my "1 - other problem", but could not see
it again today?!?
Anyway, for a test still using SomeSignature and SomeValue, but now uses the
lazy feature where I do something along the lines of
public void testClasses() throws Throwable
{
generateClasses();
ClassInfo info =
(Classinfo)getTypeInfoFactory().getTypeInfo(SomeSignature.class);
MethodInfo mi = info.getDeclaredMethod("signature", new TypeInfo[0]);
ClassInfo returnInfo = mi.getReturnType(); //Constructs the parameterized
class info internally
TypeInfo[] args = returnInfo.getActualTypeArguments(); //* Lazily loads the
type arguments
}
This fails with the call to returnInfo.getActualTypeArguments()
java.lang.IllegalStateException: java.lang.ClassNotFoundException:
org.jboss.test.classinfo.test.JavassistParameterizedClassInfoClassLoaderArgumentsTestCaseWithSignature
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getTypeInfo(JavassistTypeInfoFactoryImpl.java:840)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.createTypeInfoForTypeArgument(JavassistTypeInfoFactoryImpl.java:898)
at
org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.getActualTypeArguments(JavassistParameterizedClassInfo.java:115)
Caused by: java.lang.ClassNotFoundException:
org.jboss.test.classinfo.test.JavassistParameterizedClassInfoClassLoaderArgumentsTestCaseWithSignature
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.resolveComplexTypeInfo(IntrospectionTypeInfoFactoryImpl.java:434)
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfo(IntrospectionTypeInfoFactoryImpl.java:390)
at
org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory.getTypeInfo(IntrospectionTypeInfoFactory.java:54)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.delegateToIntrospectionImplementation(JavassistTypeInfoFactoryImpl.java:620)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:547)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:454)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:411)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getTypeInfo(JavassistTypeInfoFactoryImpl.java:836)
... 23 more
The reason is that I am using the classloader of the raw type (i.e. Set) to
load up this parameterized type, but obviously SomeValue cannot be found there.
One way around this would be in mi.getReturnType() when looking
up/creating/caching the parameterized class info to use the classloader of
mi.getDeclaringClass().getClassLoader(), which should be able to see all the
classes involved. However, I am still stuck on which classloader to use for my
previous post.
--
Reply to this message by going to Community
[http://community.jboss.org/message/539766#539766]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBREFLECT-5 - Implementing generics in JavassistClassInfo"
To view the discussion, visit: http://community.jboss.org/message/539587#539587
--
After a few false starts I have managed to reproduce the error described in my
last post, and while doing so found another problem to do with caching. Both of
these problems are related and have to do with difficulties in determining the
correct classloader to use for ParamerizedType.
1 - Other problem
> Kabir Khan wrote:
>
> > alesj wrote:
> >
> > As all of the stuff in Reflect works this way, why is this here a problem?
> Not really a problem, I just wanted to check if the object equality is
> required. It seems to work that way normally, so I'll do that for this
> instead as well.
The problem here is that if I generate some classes in classloader so they
don't exist in the main classloader. I generate this set of classes twice in
two different classloaders
public class SomeValue{}
public class SomeSignature
{
public java.util.Set signature
{
return null;
}
}
I generate the classes twice, now if I do something along the lines of
public void testClasses()
{
ClassInfo infoA = getSignatureMethodReturnTypeForClass(loaderA); //One of
the loaders loading the classes
ClassInfo infoB = getSignatureMethodReturnTypeForClass(loaderB); //Another
loader loading the classes
//These all pass
assertEquals(ClassLoader.getSystemClassLoader(),
infoA.getRawType().getClassLoader());
assertEquals(ClassLoader.getSystemClassLoader(),
infoB.getRawType().getClassLoader());
assertEquals(loaderA, infoA.getActualTypeArguments[0].getClassLoader());
//Fails - loader is loaderA
assertEquals(loaderB, infoB.getActualTypeArguments[0].getClassLoader());
}
private void getSignatureMethodReturnTypeForClass(ClassLoader loader)
{
generateClasses(getPoolForLoader(loader));
Class clazz = loader.loadClass("SomeSignature");
Method m = loader.getMethod("signature");
Type t = m.getGenericReturnType(); //instance of
java.lang.reflect.ParameterizedType
return getTypeInfoFactory().getTypeInfo(t);
}
The reason this fails is that the parameterized classinfo is cached against the
string representation of the name, i.e. "java.lang.String". This
fails with both the introspection and javassist implementations.
The root of the problem is this in the entry point to both implementations of
TypeInfoFactory, and that ParameterizedType has no getClassLoader() method, so
it is currently guessed by defaulting to the one for the raw type. The
implementations look something like
public TypeInfo getTypeInfo(Type type)
{
if (type == null)
throw new IllegalArgumentException("Null type");
if (type instanceof ParameterizedType)
return getParameterizedType((ParameterizedType) type);
...
}
public void getParameterizedType(ParameterizedType type)
{
//Check cache
ClassLoader loader = type.getRawType().getClassLoader(); // 1
TypeInfo cached = checkLoaderCacheForParameterizedType(loader,
getName(type));
if (cached != null)
return true;
//Create parameterized type wrapper
TypeInfo rawType = getTypeInfo(type.getRawType());
TypeInfo args = new TypeInfo[type.getActualTypeArguments().length];
for (int i = 0 ; i < args.length ; i++)
{
args[i] = getTypeInfo(type.getActualTypeArguments()[i];
}
ClassInfo info = createParameterizedClassInfo(rawType, args);
//Cache the lookup
cacheParameterizedTypeForLoader(loader, info);
return info;
}
So what happens is when we try to get the parameterized type for Set
with loaderA it gets cached, but against the classloader of Set, which is the
system classloader. When we try to get it with loaderB, it is found, but from
the cache for Set's classloader, i.e. the system classloader.
So maybe caching should be turned off for parameterized types? I have not yet
checked what the implications of this would be, but it would mean that object
equality checks if used will not work for parameterized types created this way.
Or maybe they should be cached against the context classloader instead?
--
Reply to this message by going to Community
[http://community.jboss.org/message/539587#539587]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"ClassPool bootstrap refactoring"
To view the discussion, visit: http://community.jboss.org/message/539493#539493
--
AbstractMCServerBase now does (once it is working properly I will move the
extra code to LifecycleEventListeners)
@Override
protected void doInitialize() throws IllegalStateException,
InvalidConfigurationException, LifecycleEventException
{
// NEW CODE - 1
/*
* Make sure we have the correct classpools set up
*/
//Initialize jboss-reflect to use the correct classpools
JBossClClassPoolConfig config = JBossClClassPoolConfig.getInstance();
RepositoryClassPoolFactory factory = new
RepositoryClassPoolFactory(config.getClassPoolRepository());
JavassistTypeInfoFactoryImpl.setPoolFactory(factory);
// NEW CODE - 1 - END
/*
* We need to start the bootstrap here so we can set the kernel
* before we fire start kernel events
*/
this.initializeBootstrap();
// Call Super implementation
super.doInitialize();
// NEW CODE - 2
//Install the bean configuring the classpools
BeanMetaDataBuilder builder =
BeanMetaDataBuilder.createBuilder("JBossClClassPoolConfig",
JBossClClassPoolConfig.class.getName());
builder.setFactoryClass(JBossClClassPoolConfig.class.getName());
builder.setFactoryMethod("getInstance");
ValueMetaData inject = builder.createContextualInject(null, null,
AutowireType.BY_NAME, InjectOption.CALLBACK);
//TODO add name to BeanMetaDataBuilder
((AbstractInjectionValueMetaData)inject).setValue("ClassLoading");
builder.addPropertyMetaData("classLoading", inject);
try
{
getKernel().getController().install(builder.getBeanMetaData());
}
catch (Throwable e)
{
// AutoGenerated
throw new RuntimeException(e);
}
// NEW CODE - 2 - END
}
The stuff in 1) sets up the classloader system so it understands the bootstrap
classloaders
The stuff in 2) "listens" for ClassLoading and registers the container as a
module Handler
--
Reply to this message by going to Community
[http://community.jboss.org/message/539493#539493]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBREFLECT-5 - Implementing generics in JavassistClassInfo" To view the discussion, visit: http://community.jboss.org/message/539484#539484 -- Having revisited how the classpools are set up ( http://community.jboss.org/thread/151095 http://community.jboss.org/thread/151095) which became apparent after looking into ( http://community.jboss.org/message/538568#538568 http://community.jboss.org/message/538568#538568) and fixed the problems to do with generating accessors for classes loaded by a parent of the jboss-reflect classloader I now end up with the following problems when starting AS: Failed to boot JBoss: java.lang.Exception: Encountered exception in server startup at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:360) at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:292) at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381) at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413) at java.lang.Thread.run(Thread.java:637) Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.annotations at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:195) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:175) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:161) at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:188) at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:345) ... 4 more Caused by: org.jboss.xb.binding.JBossXBRuntimeException: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.annotations at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment at org.jboss.xb.builder.JBossXBNoSchemaBuilder.rethrowWithLocation(JBossXBNoSchemaBuilder.java:2293) at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElementBinding(JBossXBNoSchemaBuilder.java:428) at org.jboss.xb.builder.JBossXBNoSchemaBuilder.createRootElements(JBossXBNoSchemaBuilder.java:403) at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:273) at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:336) at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:222) at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:201) at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:315) at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:177) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:370) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:191) ... 8 more Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: java.lang.ClassNotFoundException: org.jboss.beans.metadata.spi.AnnotationMetaData at org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.findTypeInfo(JavassistParameterizedClassInfo.java:153) at org.jboss.reflect.plugins.javassist.JavassistParameterizedClassInfo.getComponentType(JavassistParameterizedClassInfo.java:121) at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1447) at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-6 Skipping compilation step
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBREFLECT-6 Skipping compilation step" To view the discussion, visit: http://community.jboss.org/message/539482#539482 -- Having revisited how the classpools are set up ( http://community.jboss.org/thread/151095 http://community.jboss.org/thread/151095) which became apparent after looking into ( http://community.jboss.org/message/538568#538568 http://community.jboss.org/message/538568#538568) I got some problems such as 10:59:48,915 WARN [PropertyConfiguration] Factory: org.jboss.reflect.plugins.javassist.javassisttypeinfofact...@55ad6c98 XmlRootElement java.net.urlclassloa...@9a082e2 Failed to boot JBoss: java.lang.Exception: Encountered exception in server startup at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:360) at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:292) at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381) at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413) at java.lang.Thread.run(Thread.java:637) Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: java.lang.RuntimeException: Error retrieving annotation attribute values at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:195) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:175) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:161) at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:188) at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:345) ... 4 more Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Error retrieving annotation attribute values at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getAnnotations(JavassistTypeInfoFactoryImpl.java:699) at org.jboss.reflect.plugins.javassist.JavassistInheritableAnnotationHolder.getAnnotations(JavassistInheritableAnnotationHolder.java:78) at org.jboss.reflect.plugins.javassist.JavassistTypeInfo.getAnnotations(JavassistTypeInfo.java:790) at org.jboss.reflect.plugins.javassist.JavassistInheritableAnnotationHolder.getAnnotation(JavassistInheritableAnnotationHolder.java:91) at org.jboss.reflect.plugins.AbstractAnnotatedInfo.getUnderlyingAnnotation(AbstractAnnotatedInfo.java:55) at org.jboss.xb.builder.JBossXBBuilder.initSchema(JBossXBBuilder.java:351) at org.jboss.xb.builder.JBossXBNoSchemaBuilder.build(JBossXBNoSchemaBuilder.java:271) at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:336) at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:222) at org.jboss.xb.builder.JBossXBBuilder.build(JBossXBBuilder.java:201) at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:315) at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:177) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:370) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:191) ... 8 more Caused by: java.lang.RuntimeException: Error retrieving annotation attribute values at org.jboss.reflect.plugins.AnnotationValueFactory.createAnnotationValue(AnnotationValueFactory.java:124) at org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getAnnotations(JavassistTypeInfoFactoryImpl.java:693) ... 32 more Caused by: java.lang.RuntimeException: Error creating JavassistMethod for javax.xml.bind.annotation.XmlRootElement with classloader sun.misc.launcher$appclassloa...@517590db at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.toClass(JavassistMemberFactor
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/539244#539244 ------ > Kabir Khan wrote: > I'll try to change what I did in bootstrap to hardwire these beans and see > where that gets me: > > class="org.jboss.aop.asintegration.jboss5.VFSClassLoaderScopingPolicy"/> > > class="org.jboss.classpool.plugins.jbosscl.JBossClDelegatingClassPoolFactory"> > > property="registry"/> > > > > > class="org.jboss.aop.asintegration.jboss5.JBoss5Integration"> > bean="AOPClassPoolFactory"/> > bean="AOPClassLoaderScopingPolicy"/> > > This part of the discussion continues at http://community.jboss.org/thread/151095 http://community.jboss.org/thread/151095 -- Reply to this message by going to Community [http://community.jboss.org/message/539244#539244] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - ClassPool bootstrap refactoring
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created
the discussion
"ClassPool bootstrap refactoring"
To view the discussion, visit: http://community.jboss.org/message/539242#539242
--
Following on from http://community.jboss.org/message/539041#539041
http://community.jboss.org/message/539041#539041 I have started refactoring how
the ClassPools are initialized during bootstrap and moving code into the
classpools project. The following (uncommitted, but working) test in ClassPools
demonstrates how I see this working in the bootstrap.
/**
* Simulates the steps to be taken during AS bootstrap
*/
public void testBootstrap() throws Exception
{
//Initialize the config. This wires together the parts of the system
JBossClClassPoolConfig config = JBossClClassPoolConfig.getInstance();
assertNotNull(config.getClassPoolFactory());
assertNotNull(config.getClassPoolRepository());
assertNotNull(config.getDomainRegistry());
assertNotNull(config.getRegisterModuleCallback());
assertNull(config.getClassLoading());
//Check that the classpool factory works before we have deployed the
classpool system
ClassLoader urlCl = createChildURLLoader(null, JAR_A_URL);
ClassPool urlPool =
config.getClassPoolRepository().registerClassLoader(urlCl);
assertNotNull(urlPool);
CtClass aUrl = urlPool.get(CLASS_A);
CtClass stringUrl = urlPool.get(String.class.getName());
//Install the bean to get notified when ClassLoading is installed
BeanMetaDataBuilder builder =
BeanMetaDataBuilder.createBuilder("JBossClClassPoolConfig",
JBossClClassPoolConfig.class.getName());
builder.setFactoryClass(JBossClClassPoolConfig.class.getName());
builder.setFactoryMethod("getInstance");
ValueMetaData inject = builder.createContextualInject(null, null,
AutowireType.BY_NAME, InjectOption.CALLBACK);
((AbstractInjectionValueMetaData)inject).setValue("ClassLoading");
builder.addPropertyMetaData("classLoading", inject);
getDelegate().deploy(builder.getBeanMetaData());
//Deploy the ClassLoading. This causes the RegistryModuleCallback
//to get installed as a module registry in ClassLoading
getDelegate().deployCommon();
assertNotNull(config.getClassLoading());
testScenario = new
ClassPoolTestScenario(getClassLoaderFactory(),
config.getClassPoolRepository());
ClassPool poolA = testScenario.createLoader(new CLDeploymentBuilder("A",
JAR_A_URL));
CtClass aDomain = poolA.get(CLASS_A);
assertNotSame(aUrl, aDomain);
assertSame(stringUrl, poolA.get(String.class.getName()));
ClassPool poolB = testScenario.createLoader(new CLDeploymentBuilder("B",
JAR_B_URL));
assertSame(aDomain, poolB.get(CLASS_A));
}
The JBossClClassPoolConfig singleton wires together a lot of the things that
are needed for running this in AS (getters ommitted)
public class JBossClClassPoolConfig
{
private static volatile JBossClClassPoolConfig config;
private final DomainRegistry domainRegistry;
private final RegisterModuleCallback registerModuleCallback;
private ClassLoading classLoading;
private JBossClDelegatingClassPoolFactory classPoolFactory;
private ClassPoolRepository classPoolRepository;
private JBossClClassPoolConfig(DomainRegistry domainRegistry,
RegisterModuleCallback registerModuleCallback,
JBossClDelegatingClassPoolFactory classPoolFactory)
{
this.domainRegistry = domainRegistry;
this.registerModuleCallback = registerModuleCallback;
this.classPoolFactory = classPoolFactory;
classPoolRepository = ClassPoolRepository.getInstance();
classPoolRepository.setClassPoolFactory(classPoolFactory);
}
public static JBossClClassPoolConfig getInstance()
{
if (config == null)
{
config = initialize();
}
return config;
}
private synchronized static JBossClClassPoolConfig initialize()
{
if (config != null)
return config;
DomainRegistry domainRegistry = new VFSClassLoaderDomainRegistry();
RegisterModuleCallback registerModuleCallback = new
RegisterModuleCallback(domainRegistry);
JBossClDelegatingClassPoolFactory classPoolFactory = new
JBossClDelegatingClassPoolFactory(domainRegistry, registerModuleCallback);
return new JBossClClassPoolConfig(domainRegistry, registerModuleCallback,
classPoolFactory);
}
/**
* Set the classLoading. This should be set via a property
* by the MC
*
* @param cl the classLoading to set
*/
public void setClassLoading(ClassLoading cl)
{
if (cl != null)
cl.addModuleRegistry(registerModuleCallback);
else if (classLoading != null)
classLoading.remove
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/538975#538975 -- I put some breakpoints in RegisterModuleCallback.addModule(), JBossClDelegatingClassPool constructor, and in JavassistTypeInfoFactoryImpl.delegateToIntrospectionImplementation() (where failed ClassPool lookups end up) and it seems that there is a problem in that the aop classloader does not get registered with the classpools. The flow of these break points is: 1. RegisterModuleCallback.addModule() - bootstrap-classloader:0.0.0 2. RegisterModuleCallback.addModule() - jmx-classloader:0.0.0 3. JBossClDelegatingClassPool() - bootstrap-classloader:0.0.0 4. JBossClDelegatingClassPool() - jmx-classloader:0.0.0 5. Get TypeInfo for AspectManagerJMXRegistrar fails (aop classpool not created yet) 6. RegisterModuleCallback.addModule() - deployers-classloader:0.0.0 7. JBossClDelegatingClassPool() - deployers-classloader:0.0.0 8. Get TypeInfo for AOPAnnotationMetaDataParserDeployer fails (aop classpool not created) 9. Get TypeInfo for AOPDeploymentAopMetaDataDeployer fails (aop classpool not created) 10. Get TypeInfo for BeansDeploymentAopMetaDataDeployer fails (aop classpool not created) 11. RegisterModuleCallback.addModule() - profile-classloader:0.0.0 12. JBossClDelegatingClassPool() profile-classloader:0.0.0 Looking at the sequence of files from bootstrap.xml: * bootstrap/vfs.xml - No classloader * bootstrap/classloader.xml - defines bootstap-classloader:0.0.0 * bootstrap/stdio.xml - defines stdio-classloader:0.0.0 * bootstrap/kernel.xml - defines asynch-classloader:0.0.0 * bootstrap/aop.xml - defines aop-classloader:0.0.0 and the RegisterModuleCallback * bootstrap/jmx.xml - defines jmx-classloader:0.0.0 * bootstrap/deployers.xml - defines deployers-classloader:0.0.0 * bootstrap/profile.xml - defines deployers-classloader:0.0.0 Assuming these get deployed in order (which I will look at next) it seems strange that the RegisterModuleCallback receives bootstrap-, jmx-, deployers- and profile-classloader, but not the aop-, stdio and, asynch-classloaders -- Reply to this message by going to Community [http://community.jboss.org/message/538975#538975] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/538809#538809
------
> Kabir Khan wrote:
>
> I have modified the bootstrap project as shown in the attached patch to set
> JavassistTypeInfoFactoryImpl's classPoolFactory to be
> RepositoryClassPoolFactory. A quick check in the debugger shows this to kick
> in.
>
> I am now getting some exceptions on startup that I need to look into.
I modified JavassistTypeInfoFactoryImpl to give some extra output. When a class
can not be found it ends up in this method:
private TypeInfo delegateToIntrospectionImplementation(ClassLoader cl,
String name) throws ClassNotFoundException
{
System.out.println("==> " + name + " " + cl);
//Extra code just for debugging
ClassPool pool = poolFactory.getPoolForLoader(cl);
try
{
CtClass ct = pool.get(name);
}
catch(Exception alreadyHandled)
{
System.out.println("---> Not found in " + pool);
}
Class clazz = cl.loadClass(name);
System.out.println("---> Loaded real class from " +
clazz.getClassLoader());
try
{
CtClass ct = pool.get(name);
}
catch(Exception alreadyHandled)
{
System.out.println("---> Not found again in " + pool);
}
pool = poolFactory.getPoolForLoader(clazz.getClassLoader());
try
{
CtClass ct = pool.get(name);
System.out.println("---> Found in actual pool " + pool);
}
catch(Exception alreadyHandled)
{
System.out.println("---> Not found in actual pool " + pool);
}
//Extra code - END
IntrospectionTypeInfoFactory factory = new IntrospectionTypeInfoFactory();
return factory.getTypeInfo(name, cl);
}
Here is the output, this is during installing the beans from conf/bootstrap
17:16:06,954 INFO [JMXKernel] Legacy JMX core initialized
17:16:07,009 INFO [STDOUT] ==>
org.jboss.aop.deployers.AspectManagerJMXRegistrar
baseclassloa...@47ac1adf{jmx-classloader:0.0.0$MODULE}
17:16:08,927 INFO [STDOUT] ---> Not found in
[org.jboss.classpool.plugins.jbosscl.jbosscldelegatingclassp...@2002512083
[class path: baseclassloa...@47ac1adf{jmx-classloader:0.0.0$MODULE}:] -
dcl:baseclassloa...@47ac1adf{jmx-classloader:0.0.0$MODULE} domain:
[org.jboss.classpool.plugins.jbosscl.jbossclclasspooldom...@101ebf5c
name:DefaultDomain]]
17:16:08,930 INFO [STDOUT] ---> Loaded real class from
baseclassloa...@8a85268{aop-classloader:0.0.0$MODULE}
17:16:08,931 INFO [STDOUT] ---> Not found again in
[org.jboss.classpool.plugins.jbosscl.jbosscldelegatingclassp...@2002512083
[class path: baseclassloa...@47ac1adf{jmx-classloader:0.0.0$MODULE}:] -
dcl:baseclassloa...@47ac1adf{jmx-classloader:0.0.0$MODULE} domain:
[org.jboss.classpool.plugins.jbosscl.jbossclclasspooldom...@101ebf5c
name:DefaultDomain]]
17:16:08,931 INFO [STDOUT] ---> Found in actual pool
org.jboss.classpool.spi.abstractclassp...@697579067 [class path:
baseclassloa...@8a85268{aop-classloader:0.0.0$MODULE}:] -
dcl:baseclassloa...@8a85268{aop-classloader:0.0.0$MODULE}
17:16:09,563 INFO [STDOUT] ==>
org.jboss.aop.asintegration.jboss5.AOPAnnotationMetaDataParserDeployer
baseclassloa...@280bca{deployers-classloader:0.0.0$MODULE}
17:16:10,283 INFO [STDOUT] ---> Not found in
[org.jboss.classpool.plugins.jbosscl.jbosscldelegatingclassp...@404225673
[class path: baseclassloa...@280bca{deployers-classloader:0.0.0$MODULE}:] -
dcl:baseclassloa...@280bca{deployers-classloader:0.0.0$MODULE} domain:
[org.jboss.classpool.plugins.jbosscl.jbossclclasspooldom...@101ebf5c
name:DefaultDomain]]
17:16:10,287 INFO [STDOUT] ---> Loaded real class from
baseclassloa...@8a85268{aop-classloader:0.0.0$MODULE}
17:16:10,289 INFO [STDOUT] ---> Not found again in
[org.jboss.classpool.plugins.jbosscl.jbosscldelegatingclassp...@404225673
[class path: baseclassloa...@280bca{deployers-classloader:0.0.0$MODULE}:] -
dcl:baseclassloa...@280bca{deployers-classloader:0.0.0$MODULE} domain:
[org.jboss.classpool.plugins.jbosscl.jbossclclasspooldom...@101ebf5c
name:DefaultDomain]]
17:16:10,289 INFO [STDOUT] ---> Found in actual pool
org.jboss.classpool.spi.abstractclassp...@697579067 [class path:
baseclassloa...@8a85268{aop-classloader:0.0.0$MODULE}:] -
dcl:baseclassloa...@8a85268{aop-classloader:0.0.0$MODULE}
As you can see AspectManagerJMXRegistrar is loaded from the classloader used to
install jmx.xml, and AOPAnnotationMetaDataParserDeployer from deployers.xml's
classloader. If I use the pools for those loaders directly I get a
NotFound
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/538786#538786 -- I have modified the bootstrap project as shown in the attached patch to set JavassistTypeInfoFactoryImpl's classPoolFactory to be RepositoryClassPoolFactory. A quick check in the debugger shows this to kick in. I am now getting some exceptions on startup that I need to look into. -- Reply to this message by going to Community [http://community.jboss.org/message/538786#538786] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/538713#538713 -- The factories I created are just for unit testing, mocking the behaviour of the real one. Anyway, I see now that DefaultClassPoolFactory is always used. It seems that the default classpool has reference to the classloader loading up /server/default/conf/bindingservice.beans which is part of the default domain which explains why the default domain is able to load up the classes. I will try using RepositoryClassPoolFactory instead and modify AS startup as required. -- Reply to this message by going to Community [http://community.jboss.org/message/538713#538713] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/538568#538568
--
I've written an in-AS benchmark which I'll run tomorrow to gather some more
information about overheads of creating ClassInfos, looking up methods etc.
What I had time to look at so far shows the Javassist implementation to be ~50x
slower at obtaining the ClassInfos that the reflect one.
In the meantime, looking into why the BeanMetaData classes don't appear in the
statistics, I found this:
protected TypeInfo get(String name, ClassLoader cl, Class clazz) throws
ClassNotFoundException
{
if (name == null)
throw new IllegalArgumentException("Null name");
if (cl == null)
throw new IllegalArgumentException("Null classloader");
try
{
CtClass ctClass = poolFactory.getPoolForLoader(cl).get(name);
return get(ctClass, clazz, cl);
}
catch(NotFoundException nfe)
{
return delegateToIntrospectionImplementation(cl, name); //End up here
for a lot of the bootstrap classes
}
}
The above code was written to handle gets for generated proxy classes which
will not appear in a classpool. As we know, creating Exceptions is very
expensive, and could be at least part of the reason why the javassist
implementation.
The problem seems to be that in the bootstrap DefaultClassPoolFactory is used
until it gets replaced by the real one. Flavia, is there a way to get the real
ClassPoolFactory to kick in earlier?
--
Reply to this message by going to Community
[http://community.jboss.org/message/538568#538568]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - AnnotatedElementMetaDataLoader and bridge methods
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"AnnotatedElementMetaDataLoader and bridge methods"
To view the discussion, visit: http://community.jboss.org/message/538525#538525
--
I've made AnnotatedElementMetaDataLoader attempt to find a matching method. If
it cannot be found, a null element loader is returned (or maybe I should throw
an exception instead?)
Just so I remember in case I need to come back to it, this simple test
public class BridgeMethodTest
{
static class BaseGenerics
{
T getThing(T t)
{
return t;
}
}
static class ChildGenerics extends BaseGenerics
{
String getThing(String s)
{
return s;
}
}
public static void main(String[] args)
{
for (Method m : ChildGenerics.class.getDeclaredMethods())
System.out.println(m + " - " + m.isBridge());
}
}
gives
java.lang.String
org.jboss.test.benchmark.BridgeMethodTest$ChildGenerics.getThing(java.lang.String)
- false
java.lang.Object
org.jboss.test.benchmark.BridgeMethodTest$ChildGenerics.getThing(java.lang.Object)
- true
--
Reply to this message by going to Community
[http://community.jboss.org/message/538525#538525]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/538459#538459
--
I have implemented a first attempt at my five points above, but am still
getting longer AS startup times with the javassist-based implementation of
jboss-reflect than the introspection one.
I have added the possibility to record metrics of the invocation count and the
invocation time, and an MBean to get hold of the results which look like this:
Invocations (total time in ms) - Member name
1473 (0) -
org.jboss.metadata.javaee.support.NamedMetaData.setName(Ljava/lang/String;)V -
{G}
1281 (0) - org.jboss.metadata.web.spec.AttributeMetaData()V - {G}
1219 (0) -
org.jboss.metadata.web.spec.AttributeMetaData.setRequired(Ljava/lang/String;)V
- {G}
1132 (0) - org.jboss.metadata.javaee.spec.DescriptionImpl()V - {G}
1132 (3) -
org.jboss.metadata.javaee.spec.DescriptionImpl.setDescription(Ljava/lang/String;)V
- {G}
1127 (2) - org.jboss.metadata.javaee.spec.DescriptionsImpl()V - {G}
988 (0) -
org.jboss.metadata.javaee.support.NamedMetaDataWithDescriptions.getDescriptions()Lorg/jboss/annotation/javaee/Descriptions;
- {G}
988 (0) -
org.jboss.metadata.javaee.support.NamedMetaDataWithDescriptions.setDescriptions(Lorg/jboss/annotation/javaee/Descriptions;)V
- {G}
...
The time is not accurate, a lot of the invocations have a long "inherent time"
such as org.hornetq.jms.server.impl.JMSServerManagerImpl.start(), and for
simple setters the time is too short to be picked up. Anyway, the invocation
count gives some idea of what is going on. I noticed that the bean metadata
classes don't appear in this list, which is a bit strange so I need to figure
out why that is.
By default, to avoid the overhead of generating classes for accessors that will
not be used a lot, it is now set up to simply do what the introspection
implementation does by default, which is to just invoke the members by
reflection. The {G} and {R} after the member name indicates whether the
accessor was generated or uses reflection. For frequently used accessors, I
currently have a file called forceGenerate.txt in the bin/ folder of AS where
you can specify which accessors should use a generated class:
org.jboss.metadata.javaee.support.NamedMetaData.setName(Ljava/lang/String;)V
org.jboss.metadata.web.spec.AttributeMetaData()V
org.jboss.metadata.web.spec.AttributeMetaData.setRequired(Ljava/lang/String;)V
org.jboss.metadata.javaee.spec.DescriptionImpl()V
org.jboss.metadata.javaee.spec.DescriptionImpl.setDescription(Ljava/lang/String;)V
org.jboss.metadata.javaee.spec.DescriptionsImpl()V
org.jboss.metadata.javaee.support.NamedMetaDataWithDescriptions.getDescriptions()Lorg/jboss/annotation/javaee/Descriptions;
org.jboss.metadata.javaee.support.NamedMetaDataWithDescriptions.setDescriptions(Lorg/jboss/annotation/javaee/Descriptions;)V
org.jboss.metadata.web.spec.TagMetaData.getAttributes()Ljava/util/List;
org.jboss.metadata.web.spec.DeferredValueMetaData()V
org.jboss.metadata.web.spec.AttributeMetaData.setDeferredValue(Lorg/jboss/metadata/web/spec/DeferredValueMetaData;)V
org.jboss.metadata.web.spec.DeferredValueMetaData.setType(Ljava/lang/String;)V
org.jboss.metadata.web.spec.AttributeMetaData.setRtexprvalue(Ljava/lang/String;)V
Doing this for the top 10 used accessors improves the startup time very
slightly, but it is still a lot slower than when using the introspection
implementation. This leads me to thinking that something in this alternative
implementation is playing a bigger part in slowing this down than the
accessors. It could be something in the classpools, or maybe some
inefficiencies in JavassistTypeInfo and related classes. I'll work on creating
some benchmarks that can be run in AS and profile those to get a better idea of
what is going on.
--
Reply to this message by going to Community
[http://community.jboss.org/message/538459#538459]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Duplicate classloading with Javassist Reflect
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Duplicate classloading with Javassist Reflect" To view the discussion, visit: http://community.jboss.org/message/538388#538388 -- I did something on JavassistUtil. It might not be the answer to your problem, but in any case the jboss-reflect snapshot that should be up there does not contain anything on line 56. -- Reply to this message by going to Community [http://community.jboss.org/message/538388#538388] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/538031#538031 ------ > Kabir Khan wrote: > > ... > 2) Enable stats for the JavassistMethodInfo.invoke(), > JavassistConstructorInfo.newInstance() and JavassistFieldInfo.get()/set() so > we can run AS with that and get an idea of the usage of these joinpoints. > ... > 4) Come up with some differentiator (as mentioned earlier) to be able to > specify if a member should have JavassistMethod/-Constructor/-Field generated > or not. > ... Maybe Ales's scanning thingy could somehow integrate with these two points to automagically record annotations for the members in question? I didn't get every detail of what he said on the call, but if this indexed information is pushed into the jars, it should survive AS reboots. -- Reply to this message by going to Community [http://community.jboss.org/message/538031#538031] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/538027#538027 ------ > Kabir Khan wrote: > > Here are the times: > > > > == IntrospectionTypeInfoFactory > > > > A - Creating 100 ClassInfos 141ms > > > > B - Getting 100 fields and methods for 100 classes 50 times 1446ms > > > > C - First accessing 100 fields and methods for 100 classes 50 times 116ms > > > > D - Accessing 100 fields and methods for 100 classes 50 times 3545ms > > > > Done! > > > > > > > > > > == JavassistTypeInfoFactory > > > > A - Creating 100 ClassInfos 164ms > > > > B - Getting 100 fields and methods for 100 classes 50 times 820ms > > > > C - First accessing 100 fields and methods for 100 classes 50 times 4557ms > > > > D - Accessing 100 fields and methods for 100 classes 50 times 272ms > > > > Done! > > The output here is a bit misleading. C only accesses the members once, not 50 in order to determine the overhead of creating the JavassistMethod/-Constructor/-Field classes. I've updated the benchmark in svn to read: > > == IntrospectionTypeInfoFactory > A - Creating 100 ClassInfos 141ms > B - Getting 100 fields and methods for 100 classes 50 times 1446ms > C - First accessing 100 fields and methods for 100 classes 116ms > D - Accessing 100 fields and methods for 100 classes 50 times 3545ms > Done! > > > == JavassistTypeInfoFactory > A - Creating 100 ClassInfos 164ms > B - Getting 100 fields and methods for 100 classes 50 times 820ms > C - First accessing 100 fields and methods for 100 classes 4557ms > D - Accessing 100 fields and methods for 100 classes 50 times 272ms > Done! > -- Reply to this message by going to Community [http://community.jboss.org/message/538027#538027] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/538013#538013 -- To summarize, the steps I want to take here are: 1) Decide if we should bother to do parameter checking. If we decide to keep it, it should be done by Javassist[Method/Constructor/Field]Info and not in the generated JavassistMethod/-Constructor/-Field implementations. This can easily be turned off in the generated classes by passing in check=false to the JavassistMemberFactory create methods. 2) Enable stats for the JavassistMethodInfo.invoke(), JavassistConstructorInfo.newInstance() and JavassistFieldInfo.get()/set() so we can run AS with that and get an idea of the usage of these joinpoints. 3) Avoid creating too many JavassistMethod/-Constructor/-Field implementations. There is an overhead associated with creating these, both in terms of filling up PermGenSpace and in CPU time since each member that gets one of these needs to first generate the class and then to call ClassLoader.defineClass() which takes time. JavassistMethod/-Constructor/-Field should only be generated for Javassist[Method/Constructor/Field]Infos whose invoke()/newInstance()/get()/set() are called a lot. The data from 2) should give us some understanding of which members they are. Javassist[Method/Constructor/Field]Infos which are NOT called a lot should simply use reflection to call the target member. I think reflection should be the default. 4) Come up with some differentiator (as mentioned earlier) to be able to specify if a member should have JavassistMethod/-Constructor/-Field generated or not. 5) Let's stay with Javassist for now, and go with asm if javassist can not be improved upon in the time allowed. Creating yesterday's benchmark, I found as long as you have got the hang of one it is quite easy to look at the other. I will start off by doing some work on 2) and let you know how far I get with the others before Tuesday -- Reply to this message by going to Community [http://community.jboss.org/message/538013#538013] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - JBoss Reflect and javassist status
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created
the discussion
"JBoss Reflect and javassist status"
To view the discussion, visit: http://community.jboss.org/message/538003#538003
--
In case the volcanic ashes clear and the planes work on Tuesday so I can go on
holidays, here is the current status of the jboss-reflect on javassist
implementation.
The javassist implementation is feature complete as far as I know, we are just
waiting for javassist 3.12.0 before we can do a release.
I created a branch to test it in AS:
https://svn.jboss.org/repos/jbossas/branches/KABIR_JAVASSIST_REFLECT/
https://svn.jboss.org/repos/jbossas/branches/KABIR_JAVASSIST_REFLECT/ and a
Hudson run using that branch at
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16-KABIR-REFLECT-JAVASSIST/
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16-KABIR-REFLECT-JAVASSIST/.
There seem to be no major differences between the test runs, although that is
hard to say due to timeout issues on Hudson, and AS trunk's number of failures
changing. Once AS 6.0.0-M3 is out, it might be an idea to delete and recreate
the branch off M3 since we then know for sure that trunk completed with 0
failures. The differences between the branch's component-matrix/pom.xml and the
one in trunk are:
- 3.11.0.GA
+ 3.12.0-SNAPSHOT
- 2.1.1.SP1
+ 2.1.1.SP2
- 2.2.0.Alpha4
+ 2.2.0-SNAPSHOT
This has been added to the branches run.sh to make sure javassist is being used
by jboss-reflect:
# Setup JBoss specific properties
JAVA_OPTS="${JAVA_OPTS:+$JAVA_OPTS -Dprogram.name=$PROGNAME}"
+JAVA_OPTS="${JAVA_OPTS:+$JAVA_OPTS
-Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory}"
JAVA_OPTS="${JAVA_OPTS:--Dprogram.name=$PROGNAME}"
Apart from that everything should be the same. I use
http://www.orcaware.com/svn/wiki/Svnmerge.py svnmerge.py to periodically merge
the latest changes from Hudson trunk, to do this download svnmerge.py and then
go into your local checkout of the branch and merge using svnmerge.py, e.g:
$cd KABIR_JAVASSIST_REFLECT
$~/svnmerge.py merge
$svn commit -F svnmerge-commit-message.txt
Give it time to filter through to anonsvn and then start the Hudson run, I
think Flavia already has the admin password. If not ask QA for a password.
The main thing I am looking at now is making the javassist implementation more
performant. This is documented in http://community.jboss.org/thread/150697
JBoss Reflect Performance Javassist vs Introspection since using the javassist
implementation is currently slower than using the introspection one. I'll let
you know where I get in that thread before I leave.
It just occurred to me that another factor in currently making this slow
_could_ be the classpools since we need to look CtClasses up there. I have not
measured anything, but it is worth bearing in mind and investigating since it
is an extra layer on top of the plain classloading which is used by the
introspection implementation.
If I can think of anything else I will let you know on this thread before I go
away.
--
Reply to this message by going to Community
[http://community.jboss.org/message/538003#538003]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/537994#537994
--
In case the volcanic ashes clear and the planes work on Tuesday so I can go on
holidays, here is the current status of the jboss-reflect on javassist
implementation.
The javassist implementation is feature complete as far as I know, we are just
waiting for javassist 3.12.0 before we can do a release.
I created a branch to test it in AS:
https://svn.jboss.org/repos/jbossas/branches/KABIR_JAVASSIST_REFLECT/
https://svn.jboss.org/repos/jbossas/branches/KABIR_JAVASSIST_REFLECT/ and a
Hudson run using that branch at
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16-KABIR-REFLECT-JAVASSIST/
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-testSuite-sun16-KABIR-REFLECT-JAVASSIST/.
There seem to be no major differences between the test runs, although that is
hard to say due to timeout issues on Hudson, and AS trunk's number of failures
changing. Once AS 6.0.0-M3 is out, it might be an idea to delete and recreate
the branch off M3 since we then know for sure that trunk completed with 0
failures. The differences between the branch's component-matrix/pom.xml and the
one in trunk are:
- 3.11.0.GA
+ 3.12.0-SNAPSHOT
- 2.1.1.SP1
+ 2.1.1.SP2
- 2.2.0.Alpha4
+ 2.2.0-SNAPSHOT
This has been added to the branches run.sh to make sure javassist is being
used by jboss-reflect:
# Setup JBoss specific properties
JAVA_OPTS="${JAVA_OPTS:+$JAVA_OPTS -Dprogram.name=$PROGNAME}"
+JAVA_OPTS="${JAVA_OPTS:+$JAVA_OPTS
-Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory}"
JAVA_OPTS="${JAVA_OPTS:--Dprogram.name=$PROGNAME}"
Apart from that everything should be the same. I use
http://www.orcaware.com/svn/wiki/Svnmerge.py svnmerge.py to periodically merge
the latest changes from Hudson trunk, to do this download svnmerge.py and then
go into your local checkout of the branch and merge using svnmerge.py, e.g:
$cd KABIR_JAVASSIST_REFLECT
$~/svnmerge.py merge
$svn commit -F svnmerge-commit-message.txt
Give it time to filter through to anonsvn and then start the Hudson run, I
think Flavia already has the admin password. If not ask QA for a password.
The main thing I am looking at now is making the javassist implementation more
performant. This is documented in http://community.jboss.org/thread/150697
JBoss Reflect Performance Javassist vs Introspection since using the javassist
implementation is currently slower than using the introspection one. I'll let
you know where I get in that thread before I leave.
It just occurred to me that another factor in currently making this slow
_could_ be the classpools since we need to look CtClasses up there. I have not
measured anything, but it is worth bearing in mind and investigating since it
is an extra layer on top of the plain classloading which is used by the
introspection implementation.
If I can think of anything else I will let you know on this thread before I go
away.
--
Reply to this message by going to Community
[http://community.jboss.org/message/537994#537994]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - ClassPoolRepository vs JBossclDelegatingClassPoolRepository
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "ClassPoolRepository vs JBossclDelegatingClassPoolRepository" To view the discussion, visit: http://community.jboss.org/message/537981#537981 -- Why not just have a public static void setClassPoolRepository(ClassPoolRepository) similar to setClassLoaderScopingPolicy() and setClassPoolFactory() and initialize that from AspectManagerServiceDelegate? -- Reply to this message by going to Community [http://community.jboss.org/message/537981#537981] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/537944#537944 -- I've attached the classes I put together for measuring this. I think I included everything needed to make them run, let me know if you have any problems. I used asm 3.2. I haven't looked too deeply into why the performance is different, but I think it is due to how Bytecode and ConstPool make use of ByteVector and LongVector while their asm counterparts seem to modify the byte array directly. Javassist, on the other hand, needs to convert those to create the byte arrays. I have not done any measurements of this, but I guess with things the way they are that once the class bytes are parsed that javassist would be faster for calling things like getMethod() etc.? The reason why this becomes important is that this is something that gets called huge numbers of times. However, there are other problems with this approach of generating accessors with bytecode, which means I am not 100% sure we should go with this approach. This is that we end up with: * having to load a lot of extra classes which takes a lot of time and fills up PermGenSpace * a lot of instances (although the number of instances probably holds true when we just use java.lang.reflect.Method instead) My idea of creating bigger accessors isn't that viable either. If you have a class that has 300 members, but only 30 of those are used with the original method you end up with 30 small classes. With the "bigger accessor" idea, you end up with only one class, but with the code to access all 300 members, so that is a waste of memory. If an accessor is called a lot of times it makes sense to generate a class for it. However, if it is called only a few times, then generating and loading a class for it will be slower due to having to load the class. The main use-cases I know of are: * Configuring the properties of the MC beans. For most bean classes I think each property is only installed once. However, in other cases, e.g. the properties of the beans for the AOP metadata + the beans installed by EJB 3 probably get accessed a lot of times, so for these it would make sense to generate classes. * JBossXB parsing. It is used for parsing the schema, which only happens once, but when parsing the xml files, I think the accessors are used a lot. I think we need some kind of differentiator, so that for accessors that only get called a few times we just go with norrnal reflection, but for heavily used accessors we go with generating the classes. I'll try to come up with some numbers for how many times we need to access the member for generating the class to be the cheapest option. The question is what differentiator to use? A few ideas: * Keep a counter in Javassist[Method/Field/Constructor]Info and once it has been called several times switch to the generated class. The problem with this is, what if this counter kicks in and we end up generating the class and then we don't have enough subsequent accesses to reap the performance benefits, i.e. in this case it would slow it down. * Use some annotation to say that for a particular class we should always use generated members. If this annotation comes from MC BeanMetaData it could be put into the TypeInfo attachments. I will build some statistics into JavassistConstructorInfo.newInstance(), JavassistMethodInfo.invoke() etc. so it is possible to get a report of the type of accessor used and the number of calls to help with being able to tune it using annotations unless somebody has some different ideas. -- Reply to this message by going to Community [http://community.jboss.org/message/537944#537944] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/537846#537846 ------ > Kabir Khan wrote: > > I will play with creating an asm version of that. > BTW this is only to get something up and running sometime soon, we probably should put some work into seeing what can be done to improve ClassFile.write(), and go with that in the longer term? -- Reply to this message by going to Community [http://community.jboss.org/message/537846#537846] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/537798#537798
--
I have done some performance measurements where I compare the times taken
creating the following class, using javassist.bytecode.* and asm
public class JavassistMethod1 implements JavassistMethod
{
public Object invoke(Object target, Object[] args) throws Throwable
{
return
Integer.valueOf(((SomeClass)target).someMethod(((Integer)args[0]).intValue(),
(String)args[1])).intValue();
}
}
Which would be used to call the method:
int someMethod(int i, String);
The basic flow for what I do for both approaches is the same, whereby I do the
following lots of times to generate lots of similar classes:
A) - Create class structure
B) - Add default constructor with body to call super
C) - Add invoke method
C1) - Add invoke method body
D) - Convert class structure from A) into byte[]
E) - Define java.lang.Class by calling ClassLoader.defineClass()
F) - Call Class.newInstance()
1 - Average times (ms) to do A-F is:
|| *Classes* || *ASM* || *Javassist* || *ASM/Javassist* ||
| 1 | 1079 | 1585 | .68 |
| 15000 | 1550 | 2153 | .72 |
| 2 | 1901 | 2665 | .71 |
2 - Taking the instantiation out of the equation, so we just do A-E:
|| *Classes* || *ASM* || *Javassist* || ASM/Javassist ||
| 2 | 1290 | 1998 | .64 |
3 - Not loading the class, so we do A-D:
|| *Classes* || *ASM* || *Javassist* || *ASM/Javassist* ||
| 2 | 391 | 1115 | .35 |
| 4 | 499 | 1489 | .34 |
4 - Just doing A-C shows that javassist has a massive overhead in step D:
|| *Classes* || ASM || *Javsssist* || *ASM/Javassist* ||
| 4 | 524 | 747 | .71 |
| 10 | 823 | 1244 | .66 |
5 - Doing A-C with a simplified method body in C1 so it is just the equivalent
of {return null;}:
|| Classes || *ASM* || *Javassist* || *ASM/Javassist* ||
| 4 | 494 | 617 | .80 |
| 10 | 723 | 923 | .78 |
6 - If I don't create the method in C at all, so I just do A-B
|| *Classes* || ASM || Javassist || ASM/Javassist ||
| 4 | 449 | 589 | .76 |
| 10 | 619 | 845 | .73 |
So unfortunately Javassist is slower than ASM when it comes to creating new
classes. Both at generating the bytecode, and a lot slower at converting the
javassist.bytecode.ClassFile to a byte[].
The other overhead in this, as mentioned in a previous post, is the actual
loading and instantiation of the classes themselves. So, I think generating
less classes that do more stuff is the way forward, although that means a
bigger overhead in creating the methods which will be bigger. I will play with
creating an asm version of that.
--
Reply to this message by going to Community
[http://community.jboss.org/message/537798#537798]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/537476#537476
--
What we generate is effectively something along the lines of
public class JavassistMethod1 implements JavassistMethod
{
public Object invoke(Object target, Object[] args) throws Throwable
{
if (target == null)
throw new IllegalArgumentException("Null target");
if (target instanceof SomeClass == false)
throw new IllegalArgumentException("Wrong target");
if (args == null || args.length != 10)
throw new IllegalArgumentException("Wrong number of parameters");
if (args[0] == null)
throw new IllegalArgumentException("Parameter 1 cannot be null for
SomeClass.someMethod(long, String)");
if (args[0] != null && args[0] instanceof Long == false)
throw new IllegalArgumentException("Parameter 1 is not an instance of
Long for SomeClass.someMethod(long, String)");
if (args[1] != null && args[1] instanceof String == false)
throw new IllegalArgumentException("Parameter 2 is not an instance of
String for SomeClass.someMethod(long, String)");
return ((SomeClass)target).someMethod(((Long)args[0]).longValue(),
(String)args[1]);
}
}
Disabling the parameter checking so we end up with this instead reduces the
time spent in C from about 4.8s to 3.8s
public class JavassistMethod1 implements JavassistMethod
{
public Object invoke(Object target, Object[] args) throws Throwable
{
return ((SomeClass)target).someMethod(((Long)args[0]).longValue(),
(String)args[1]);
}
}
Profiling this, for each JavassistMethod implementation the time taken is
roughly
50% generating the bytecode for the method
30% Converting the bytecode to a byte array and creating the class
13% creating the constructor
6% setting the interfaces
Maybe a better approach would be
1) to do the parameter checking in Javassist[Constructor/Method/Field]Info
itself
2) to generate less classes? Something like:
public class SomeBeanAccessor implements JavassistBeanAccessor
{
public Object newInstance(int index, Object[] args) throws Throwable
{
if (index == 0)
return new SomeClass((String)args[0]);
else if (index == 1)
return new SomeClass((String)args[1]);
return null;
}
public Object invoke(long hash, Object target, Object[] args) throws
Throwable
{
if (hash == 121267912)
return ((SomeClass)target).someMethod(((Long)args[0]).longValue(),
(String)args[1]);
if (hash == 128172981)
return ((SomeClass)target).otherMethod(((Long)args[0]).longValue(),
(String)args[1], (String)args[2]);
}
public Object get(String name, Object target) throws Throwable
{
if (name.equals("intField")
return Integer.valueOf(((SomeClass)target).intField);
if (name.equals("stringField")
return ((SomeClass)target).stringField;
}
public void set(String name, Object target, Object value) throws Throwable
{
if (name.equals("intField")
((SomeClass)target).intField = ((Integer)value).intValue();
return;
if (name.equals("stringField")
((SomeClass)target).stringField = (String)value;
}
}
First call by Javassist[Constructor/Method/Field]Info to access the member
would result in this being created for ALL members, and cached in
JavassistTypeInfo.
--
Reply to this message by going to Community
[http://community.jboss.org/message/537476#537476]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/537449#537449 -- I've tried starting AS with the two implementations, and the overhead of creating accessor classes means javassist is slower. Javassist: ~24.5s Introspection: ~21s I need to profile this, but think this is because when configuring beans, we normally only set properties once, so we get the overhead of creating the class, but not the benefit of invoking it lots of times. I will ask Chiba if there is anything that can be done to JavassistMembersFactory to make this faster. -- Reply to this message by going to Community [http://community.jboss.org/message/537449#537449] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/537409#537409 -- I have created a simple benchmark where I test the performance of different things using the different implementations. It can be found at https://svn.jboss.org/repos/jbossas/projects/jboss-reflect/trunk/src/test/java/org/jboss/test/benchmark/AccessorBenchmark.java https://svn.jboss.org/repos/jbossas/projects/jboss-reflect/trunk/src/test/java/org/jboss/test/benchmark/AccessorBenchmark.java It first generates 100 classes, each with 100 fields and 100 methods, then it: * A) Obtains a ClassInfo for each class * B) Goes through each class and calls getDeclaredField() and getDeclaredMethod() for each field/method. This is done 50 times * C) Calls FieldInfo.get/set and MethodInfo.get/set once for each field/method * D) Same as C, but now it happens 50 times Here are the times: > > == IntrospectionTypeInfoFactory > > A - Creating 100 ClassInfos 141ms > > B - Getting 100 fields and methods for 100 classes 50 times 1446ms > > C - First accessing 100 fields and methods for 100 classes 50 times 116ms > > D - Accessing 100 fields and methods for 100 classes 50 times 3545ms > > Done! > > > > > == JavassistTypeInfoFactory > > A - Creating 100 ClassInfos 164ms > > B - Getting 100 fields and methods for 100 classes 50 times 820ms > > C - First accessing 100 fields and methods for 100 classes 50 times 4557ms > > D - Accessing 100 fields and methods for 100 classes 50 times 272ms > > Done! > * Creating the ClassInfos (A) takes about the same time with the two implementations. * Calling getDeclaredMethod()/-Field() (B) is about twice as fast using Javassist as introspection. * The first time a joinpoint is invoked is very slow with Javassist (due to generating the class), while subsequent calls are very fast I'll profile C to see if it can be made faster somehow. Although, 20,000 classes are created so my guess is that creating an output stream for the class bytes for each class and then it with the classloader is the real overhead -- Reply to this message by going to Community [http://community.jboss.org/message/537409#537409] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - Making JavassistTypeInfo serializable
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created
the discussion
"Making JavassistTypeInfo serializable"
To view the discussion, visit: http://community.jboss.org/message/534718#534718
--
Looking at https://jira.jboss.org/jira/browse/JBREFLECT-16
https://jira.jboss.org/jira/browse/JBREFLECT-16 I wanted to do the same as I
did to make the reflect flavour properly serializable, which was simply to add
this to ClassInfo, as mentioned here
http://community.jboss.org/message/534270#534270:
http://community.jboss.org/message/534270#534270:
protected Object writeReplace()
{
return new MarshalledClassInfo(getType());
}
public static class MarshalledClassInfo implements Serializable
{
private static final long serialVersionUID = 1L;
Class type;
public MarshalledClassInfo(Class type)
{
this.type = type;
}
protected Object readResolve()
{
TypeInfoFactory tif = new IntrospectionTypeInfoFactory();
return tif.getTypeInfo(type);
}
}
If I do the same for JavassistTypeInfo, then that will load the class. Is that
a bad thing? Probably...
The alternative for this simple implementation to work is to save the name and
the classloader, and classloaders are not serializable.
Or am I missing something? When deserializing a class should that happen in the
same classloader (or one with access to similar classes if serialized out of
the vm) as the one that serialized it in the first place? If the answer is yes,
then I can go forward with this.
--
Reply to this message by going to Community
[http://community.jboss.org/message/534718#534718]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534713#534713 -- https://jira.jboss.org/jira/browse/JBREFLECT-112 https://jira.jboss.org/jira/browse/JBREFLECT-112 for the proxy stuff https://jira.jboss.org/jira/browse/JBKERNEL-115 https://jira.jboss.org/jira/browse/JBKERNEL-115 for the StaticInjector stuff The kernel/kernel tests all pass now using the Javassist version of jboss-reflect :-) I'll move on to the other modules in kernel, before looking at classloader, deployers etc. -- Reply to this message by going to Community [http://community.jboss.org/message/534713#534713] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Issues using Javassist TypeInfoFactory in other projects"
To view the discussion, visit: http://community.jboss.org/message/534708#534708
------
> Kabir Khan wrote:
>
> Another issue is that dynamically created classes are not found in the
> classpools.
Rather than all the fancy BytecodeRecorder stuff, I am simply delegating to the
IntrospectionTypeInfoFactory if the class can not be found in the classpool:
[kabir ~/sourcecontrol/jboss-reflect/trunk/jboss-reflect]
$svn diff
Index:
src/main/java/org/jboss/reflect/plugins/javassist/JavassistTypeInfoFactoryImpl.java
===
---
src/main/java/org/jboss/reflect/plugins/javassist/JavassistTypeInfoFactoryImpl.java (revision
103127)
+++
src/main/java/org/jboss/reflect/plugins/javassist/JavassistTypeInfoFactoryImpl.java (working
copy)
@@ -49,6 +49,7 @@
import org.jboss.reflect.plugins.AnnotationValueImpl;
import org.jboss.reflect.plugins.EnumConstantInfoImpl;
import org.jboss.reflect.plugins.GenericsUtil;
+import org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory;
import org.jboss.reflect.plugins.javassist.classpool.ClassPoolFactory;
import org.jboss.reflect.plugins.javassist.classpool.DefaultClassPoolFactory;
import org.jboss.reflect.spi.AnnotationInfo;
@@ -284,11 +285,33 @@
}
catch(NotFoundException nfe)
{
- throw new ClassNotFoundException(nfe.getMessage());
+ return delegateToIntrospectionImplementation(cl, name);
}
}
/**
+ * Proxies, whether
+ *
+ * JDK dynamic proxies
+ * javassist ProxyFactory proxies - created by calling
ClassLoader.defineClass()
+ *
+ * are not visible to the javassist classpools, and neither will classes
generated by cglib or other
+ * frameworks, so try to load up the class from the reflect implementation.
+ *
+ * @param cl the classloader
+ * @param name the name of the class
+ * @return the info
+ * @throws ClassNotFoundException when the class cannot be found
+ */
+ private TypeInfo delegateToIntrospectionImplementation(ClassLoader cl,
String name) throws ClassNotFoundException
+ {
+ //Check the class has been loaded
+ cl.loadClass(name);
+ IntrospectionTypeInfoFactory factory = new
IntrospectionTypeInfoFactory();
+ return factory.getTypeInfo(name, cl);
+ }
+
+ /**
--
Reply to this message by going to Community
[http://community.jboss.org/message/534708#534708]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Issues using Javassist TypeInfoFactory in other projects"
To view the discussion, visit: http://community.jboss.org/message/534679#534679
--
It looks like ReflectMethodImpl.setMethod() and ReflectFieldImpl.setField() do
that already:
RMI:
public void setMethod(Method method)
{
boolean isDeclaringClassPublic = true;
if (method != null)
{
accessCheck(Modifier.isPublic(method.getModifiers()));
isDeclaringClassPublic = isDeclaringClassPublic(method);
accessCheck(isDeclaringClassPublic);
}
this.method = method;
if (method != null && (isPublic() == false || isDeclaringClassPublic ==
false))
setAccessible();
}
RFI:
public void setField(Field field)
{
if (field != null)
accessCheck(Modifier.isPublic(field.getModifiers()));
this.field = field;
if (isPublic() == false && field != null)
setAccessible();
}
Commenting out the whole block which threw the exception for
JavassistMethodInfo, and setAccessible=true for ReflectMethodInfoImpl, works
with both modes
org.jboss.test.kernel.deployment.support.StaticInjector:
private void injectToMethod(Class clazz, String method, Object value,
Class signature, boolean isPublic) throws Throwable
{
ClassInfo classInfo = configurator.getClassInfo(clazz);
MethodInfo mi = Config.findMethodInfo(classInfo, method, new
String[]{signature.getName()}, true, isPublic);
// if (isPublic == false)
// {
// // TODO - move this into Reflection?
// if (mi instanceof ReflectMethodInfoImpl)
// {
// ReflectMethodInfoImpl rmi = (ReflectMethodInfoImpl)mi;
// Method m = rmi.getMethod();
// m.setAccessible(true);
// }
// else
// throw new IllegalArgumentException("Cannot set accessible on
method info: " + mi);
// }
mi.invoke(null, new Object[]{value});
}
--
Reply to this message by going to Community
[http://community.jboss.org/message/534679#534679]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Issues using Javassist TypeInfoFactory in other projects"
To view the discussion, visit: http://community.jboss.org/message/534604#534604
--
I am also seeing this
java.lang.IllegalArgumentException: Cannot set accessible on method info:
javassistmethodi...@5578920a{name=privmain}
at
org.jboss.test.kernel.deployment.support.StaticInjector.injectToMethod(StaticInjector.java:76)
at
org.jboss.test.kernel.deployment.support.StaticInjector.injectToNonPublicMethod(StaticInjector.java:59)
at
org.jboss.test.kernel.deployment.test.BeanContainerStaticTestCase.testStaticInjection(BeanContainerStaticTestCase.java:53)
private void injectToMethod(Class clazz, String method, Object value,
Class signature, boolean isPublic) throws Throwable
{
ClassInfo classInfo = configurator.getClassInfo(clazz);
MethodInfo mi = Config.findMethodInfo(classInfo, method, new
String[]{signature.getName()}, true, isPublic);
if (isPublic == false)
{
// TODO - move this into Reflection?
if (mi instanceof ReflectMethodInfoImpl)
{
ReflectMethodInfoImpl rmi = (ReflectMethodInfoImpl)mi;
Method m = rmi.getMethod();
m.setAccessible(true);
}
else
throw new IllegalArgumentException("Cannot set accessible on method
info: " + mi);
}
mi.invoke(null, new Object[]{value});
}
If we moved the setAccessible() stuff to jboss-reflect as indicated in the
comment, we could manage the accessibility of members there?
--
Reply to this message by going to Community
[http://community.jboss.org/message/534604#534604]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Issues using Javassist TypeInfoFactory in other projects"
To view the discussion, visit: http://community.jboss.org/message/534602#534602
--
Another issue is that dynamically created classes are not found in the
classpools.
Dynamic proxies are not found at all:
0 DEBUG [JDKLazyInstantiationTestCase] setUp
org.jboss.test.kernel.lazy.test.JDKLazyInstantiationTestCase
5 DEBUG [JDKLazyInstantiationTestCase] Starting testLazy
20 DEBUG [KernelFactory] Starting JBoss Kernel construction...
53 WARN [PropertyConfiguration] Factory:
org.jboss.reflect.plugins.javassist.javassisttypeinfofact...@4393722c
466 DEBUG [KernelFactory] Completed JBoss Kernel construction. Duration: 446
milliseconds
568 ERROR [AbstractKernelController] Error installing to Instantiated:
name=beanProxy state=Described
java.lang.RuntimeException: Class not found: $Proxy0
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:311)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getTypeInfo(JavassistTypeInfoFactoryImpl.java:519)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory.getTypeInfo(JavassistTypeInfoFactory.java:51)
at
org.jboss.classadapter.plugins.BasicClassAdapterFactory.getClassAdapter(BasicClassAdapterFactory.java:54)
Neither are the javassist ProxyFactory proxies, since they just define the
class in the classloader with no way to find them from the pools:
0 DEBUG [JavassistLazyInstantiationTestCase] setUp
org.jboss.test.kernel.lazy.test.JavassistLazyInstantiationTestCase
3 DEBUG [JavassistLazyInstantiationTestCase] Starting testLazy
18 DEBUG [KernelFactory] Starting JBoss Kernel construction...
47 WARN [PropertyConfiguration] Factory:
org.jboss.reflect.plugins.javassist.javassisttypeinfofact...@4393722c
514 DEBUG [KernelFactory] Completed JBoss Kernel construction. Duration: 496
milliseconds
618 ERROR [AbstractKernelController] Error installing to Instantiated:
name=beanProxy state=Described
java.lang.RuntimeException: Class not found:
org.jboss.test.kernel.lazy.support.IRare_$$_javassist_0
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.get(JavassistTypeInfoFactoryImpl.java:311)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactoryImpl.getTypeInfo(JavassistTypeInfoFactoryImpl.java:519)
at
org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory.getTypeInfo(JavassistTypeInfoFactory.java:51)
at
org.jboss.classadapter.plugins.BasicClassAdapterFactory.getClassAdapter(BasicClassAdapterFactory.java:54)
In AOP what we did was to write the class bytes to the in memory vfs location
from the aop classpools, so that when trying to look up the CtClass later there
is a resource path for the class bytes:
URL outputURL = new URL(tempURL.toString() + "/" + classFileName);
//Write the classfile to the temporary url
synchronized (tmplock)
{
if (trace) logger.trace(this + " " + pool + ".toClass() myloader:"
+ myloader + " writing bytes to " + tempURL);
ByteArrayOutputStream byteout = new ByteArrayOutputStream();
BufferedOutputStream out = new BufferedOutputStream(byteout);
out.write(cc.toBytecode());
out.flush();
out.close();
byte[] classBytes = byteout.toByteArray();
MemoryContextFactory factory = MemoryContextFactory.getInstance();
factory.putFile(outputURL, classBytes);
Going to check with Chiba, but I'll see if I can modify javassist to allow
ProxyFactory and ProxyFactoryHelper to accept an interface like
interface ByteRecorder{
void writeBytes(String classname, byte[]) throws IOException
}
--
Reply to this message by going to Community
[http://community.jboss.org/message/534602#534602]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534599#534599 -- Some tests needed updating to understand classloaders when using the javassist type infos. Basially adding a bean that is a reflect ClassPoolFactory implementation, which has in/uncallback listeners for classloaders: https://jira.jboss.org/jira/browse/JBREFLECT-107 https://jira.jboss.org/jira/browse/JBREFLECT-107 -- Reply to this message by going to Community [http://community.jboss.org/message/534599#534599] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534495#534495 -- > ANIL SALDHANA wrote: > > Have you tried providing the perms to > "org.jboss.test.classloading.vfs.VFSClassLoader.loadClass" in your policy > file? That is the root of the problem here. Yeah, I've played with that, and that seems to work fine. The tests failing already had a policy file, just missing this permission (for my new stuff), so I assume this is ok. -- Reply to this message by going to Community [http://community.jboss.org/message/534495#534495] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Issues using Javassist TypeInfoFactory in other projects"
To view the discussion, visit: http://community.jboss.org/message/534493#534493
--
> ANIL SALDHANA wrote:
>
> I would probably start here:
> =
> on: access denied (java.lang.RuntimePermission
> accessClassInPackage.sun.reflect)
> at
> org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.makeClass(JavassistMemberFactory.java:296)
> at
> ==
>
> Place a privileged block.
That line is just a rethrow from a catch block:
final ClassLoader cl = target.getClassPool().getClassLoader();
return AccessController.doPrivileged(new
PrivilegedExceptionAction>() //Line 281
{
public Class run() throws Exception
{
return FactoryHelper.toClass(cf, cl); //Line 285
}
});
}
catch(RuntimeException e)
{
throw e;
}
catch (Exception e)
{
throw new RuntimeException(e); //Line 296
}
}
the real work is done here:
Caused by: java.security.PrivilegedActionException:
javassist.CannotCompileException: by java.security.AccessControlException:
access denied
(java.lang.RuntimePermission accessClassInPackage.sun.reflect)
at java.security.AccessController.doPrivileged(Native Method)
at
org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.makeClass(JavassistMemberFactory.java:281)
... 55 more
Caused by: javassist.CannotCompileException: by
java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClass
InPackage.sun.reflect)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:169)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:136)
at
org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory$1.run(JavassistMemberFactory.java:285)
at
org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory$1.run(JavassistMemberFactory.java:1)
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission accessClassInPackage.sun.reflect)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:327)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at
org.jboss.test.classloading.vfs.VFSClassLoader.loadClass(VFSClassLoader.java:55)
<---
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:698)
at java.lang.ClassLoader.defineClass(ClassLoader.java:544)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javassist.util.proxy.SecurityActions$6.run(SecurityActions.java:124)
at java.security.AccessController.doPrivileged(Native Method)
at javassist.util.proxy.SecurityActions.invokeMethod(SecurityActions.java:121)
at javassist.util.proxy.FactoryHelper.toClass2(FactoryHelper.java:182)
at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:163)
I'm not 100% sure, but the marked line would probably be the right place to put
it, however that might be a security violation?
--
Reply to this message by going to Community
[http://community.jboss.org/message/534493#534493]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534489#534489 -- I am getting some failures in tests that have their own classloader when security is enabled, and am unsure where to put the privileged block? Initially I got this error: 1545 ERROR [AbstractKernelController] Error installing to Instantiated: name=VFSBean1 state=Described java.lang.RuntimeException: java.security.PrivilegedActionException: javassist.CannotCompileException: by java.security.AccessControlExcepti on: access denied (java.lang.RuntimePermission accessClassInPackage.sun.reflect) at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.makeClass(JavassistMemberFactory.java:296) at org.jboss.reflect.plugins.javassist.bytecode.JavassistMemberFactory.createJavassistConstructor(JavassistMemberFactory.java:213) at org.jboss.reflect.plugins.javassist.JavassistReflectionFactory.createConstructor(JavassistReflectionFactory.java:108) at org.jboss.reflect.plugins.javassist.JavassistConstructorInfo.newInstance(JavassistConstructorInfo.java:146) at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:81) at org.jboss.kernel.plugins.dependency.DispatchJoinPoint.run(DispatchJoinPoint.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:54) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:67) at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:1) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.secureInstallAction(SimpleControllerContextAction.java:67) at org.jboss.dependency.plugins.action.AccessControllerContextAction$1.run(AccessControllerContextAction.java:80) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:103) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:103) at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:97) at org.jboss.test.kernel.dependency.support.TestUtil.install(TestUtil.java:99) at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.install(OldAbstractKernelDependencyTest.java:112) at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.assertInstall(OldAbstractKernelDependencyTest.java:130) at org.jboss.test.kernel.dependency.test.OldAbstractKernelDependencyTest.assertInstall(OldAbstractKernelDependencyTest.java:123) at org.jboss.test.kernel.dependency.test.ConstructorClassLoaderTestCase.testConstructorClassLoaderReinstall(ConstructorClassLoaderTestCase. java:231) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.jav
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534461#534461 -- I found some problems in the xml parsing since jbossxb invalidly assumed that to have actual type arguments the ClassInfo needs to be cast to ParameterizedClassInfo. The Javassist implementation does not use ParameterizedClassInfo https://jira.jboss.org/jira/browse/JBXB-245 https://jira.jboss.org/jira/browse/JBXB-245 -- Reply to this message by going to Community [http://community.jboss.org/message/534461#534461] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534446#534446 ------ > Kabir Khan wrote: > > Starting this thread to keep track of what is going wrong when using the > Javassist version of TypeInfo > > The first issue is that javassist itself did not understand things like > > @SomeAnnotation(clazz=org.blah.Something[]) > > https://jira.jboss.org/jira/browse/JASSIST-111 > https://jira.jboss.org/jira/browse/JASSIST-111 JBoss Reflect issue testing this and upgrading to javassist snapshot here http://jira.jboss.org/jira/browse/JBREFLECT-111 http://jira.jboss.org/jira/browse/JBREFLECT-111 -- Reply to this message by going to Community [http://community.jboss.org/message/534446#534446] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - Issues using Javassist TypeInfoFactory in other projects
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created the discussion "Issues using Javassist TypeInfoFactory in other projects" To view the discussion, visit: http://community.jboss.org/message/534425#534425 -- Starting this thread to keep track of what is going wrong when using the Javassist version of TypeInfo The first issue is that javassist itself did not understand things like @SomeAnnotation(clazz=org.blah.Something[]) https://jira.jboss.org/jira/browse/JASSIST-111 https://jira.jboss.org/jira/browse/JASSIST-111 -- Reply to this message by going to Community [http://community.jboss.org/message/534425#534425] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Testing jboss-reflect with a SecurityManager enabled
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Testing jboss-reflect with a SecurityManager enabled" To view the discussion, visit: http://community.jboss.org/message/534270#534270 ------ > Kabir Khan wrote: > > This is a deeper problem than I first assumed. Most things that call > AbstractClassInfoTest.testBasics() have not yet loaded things like the > fields, methods etc. so this problem does not occur. If I modify them to have > loaded these annotated members I get a lot of errors. > > I'll fix this Done for https://jira.jboss.org/jira/browse/JBREFLECT-110 https://jira.jboss.org/jira/browse/JBREFLECT-110 -- Reply to this message by going to Community [http://community.jboss.org/message/534270#534270] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Testing jboss-reflect with a SecurityManager enabled
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Testing jboss-reflect with a SecurityManager enabled" To view the discussion, visit: http://community.jboss.org/message/534171#534171 -- This is a deeper problem than I first assumed. Most things that call AbstractClassInfoTest.testBasics() have not yet loaded things like the fields, methods etc. so this problem does not occur. If I modify them to have loaded these annotated members I get a lot of errors. I'll fix this -- Reply to this message by going to Community [http://community.jboss.org/message/534171#534171] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Testing jboss-reflect with a SecurityManager enabled
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Testing jboss-reflect with a SecurityManager enabled" To view the discussion, visit: http://community.jboss.org/message/534053#534053 -- This has been committed against https://jira.jboss.org/jira/browse/JBREFLECT-109 https://jira.jboss.org/jira/browse/JBREFLECT-109. I did not need the extra permissions in ContainerTestPlugin, all that was needed was a IntrospectionEnumTestCase.properties: test.Permission.0=java.lang.RuntimePermission, accessClassInPackage.sun.reflect.annotation Without that I got this java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.sun.reflect.annotation) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:327) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at java.util.HashMap.readObject(HashMap.java:1030) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at java.util.HashMap.readObject(HashMap.java:1030) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.jboss.test.AbstractTestCase.deserialize(AbstractTestCase.java:352) at org.jboss.test.classinfo.test.AbstractClassInfoTest.access$0(AbstractClassInfoTest.java:1) at org.jboss.test.classinfo.test.AbstractClassInfoTest$1.run(AbstractClassInfoTest.java:100) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.test.classinfo.test.AbstractClassInfoTest.testBasics(AbstractClassInfoTest.java:96) at org.jboss.test.classinfo.test.ClassInfoEnumTest.testEnum(ClassInfoEnumTest.java:71) at org.jboss.test.classinfo.test.ClassInfoEnumTest.testEnumField
Re: [jboss-user] [JBoss Microcontainer Development] - Testing jboss-reflect with a SecurityManager enabled
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied
to the discussion
"Testing jboss-reflect with a SecurityManager enabled"
To view the discussion, visit: http://community.jboss.org/message/534033#534033
------
> Kabir Khan wrote:
>
> My plan there is to modify JavassistFieldInfo and JavassistMethodInfo to
> throw an exception if an attempt is made to access them if they are not
> public and there is a security manager present.
Actually, I will make this behave as their reflect counterparts
public static void checkAccess(MemberInfo info)
{
if (!info.isPublic() && System.getSecurityManager() != null)
AccessController.checkPermission(new
ReflectPermission("suppressAccessChecks"));
}
--
Reply to this message by going to Community
[http://community.jboss.org/message/534033#534033]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Microcontainer Development] - Testing jboss-reflect with a SecurityManager enabled
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] created
the discussion
"Testing jboss-reflect with a SecurityManager enabled"
To view the discussion, visit: http://community.jboss.org/message/534031#534031
--
I am enabling security for jboss-reflect and going through and adding
privileged blocks where needed. Currently I am using this test policy plugin
public class ContainerTestPolicyPlugin extends TestsPolicyPlugin
{
public ContainerTestPolicyPlugin(Class clazz)
{
super(clazz);
}
public PermissionCollection getPermissions(CodeSource codesource)
{
PermissionCollection collection = super.getPermissions(codesource);
collection.add(new RuntimePermission("accessDeclaredMembers"));
collection.add(new RuntimePermission("getClassloader"));
collection.add(new RuntimePermission("accessClassInPackage.sun.reflect"));
return collection;
}
}
Once I'm done I'll see about adding property files for individual tests, or I
might just leave this in?
Anyway, the problem I am having is for the following tests:
* BeanInfoUtilTestCase - which seems to assume that it will ALWAYS be able to
set/get fields whether they are public or private.
* Field-/MethodAccessRestrictionTestCase - which seems to assume that it can
set/get private fields when there is no security manager, but not when there is
one.
>From what I can work out BeanInfoUtilTestCase was not written with a security
>manager enabled, so I will modify BeanInfoUtilTestCase to override the
>delegate so it will never use a security manager no matter what
>ContainerTest.getDelegate() does.
The next problem is the Javassist version of the
Field-/MethodAccessRestrictionTestCase. These fail since the javassist
generated accessors (from JBREFLECT-6) are able to access private members, due
to inheriting from sun.reflect.MagicAccessorImpl, so we don't get the expected
exceptions when calling private members with a security manager enabled. My
plan there is to modify JavassistFieldInfo and JavassistMethodInfo to throw an
exception if an attempt is made to access them if they are not public and there
is a security manager present.
--
Reply to this message by going to Community
[http://community.jboss.org/message/534031#534031]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115]
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - JBREFLECT-5 - Implementing generics in JavassistClassInfo
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBREFLECT-5 - Implementing generics in JavassistClassInfo" To view the discussion, visit: http://community.jboss.org/message/533935#533935 -- When testing kernel with the JavassistTypeInfoFactory last week I got quite a few errors due to some tests trying to configure private members. Although the generated javassist joinpoint classes extend sun.reflect.MagicAccessorImpl so they can access private members the javassist compiler fell over when trying to compile the generated classes since they were trying to access private members. I have fixed those errors by implementing https://jira.jboss.org/jira/browse/JBREFLECT-6 https://jira.jboss.org/jira/browse/JBREFLECT-6, so that the JavassistReflectionFactory now generates the bytecode directly. There are still a few errors when running this in kernel, so I'll try to find what those are. Currently I am running this with security turned off, once that is turned on again there will be more, but I'll do what I can without security first, -- Reply to this message by going to Community [http://community.jboss.org/message/533935#533935] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
Re: [jboss-user] [JBoss Microcontainer Development] - Servlet Scanner plugin
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "Servlet Scanner plugin" To view the discussion, visit: http://community.jboss.org/message/533912#533912 -- Is this just for Web? If not, I think it should be made possible to differentiate. -- Reply to this message by going to Community [http://community.jboss.org/message/533912#533912] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2115] ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
