Hi, i know this thread is a bit old but discovered the option (system property) com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
it seems it prevent bytecode update to create injector (jaxb) anyone tested? *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/2/29 Romain Manni-Bucau <rmannibu...@gmail.com> > yep > > - Romain > > > > 2012/2/29 David Blevins <david.blev...@gmail.com> > >> I think we're agreeing. We require 966 Accessor implementations and 1 >> AccessorFactory to return them. >> >> At this point we're only one AccessorFactory implementation away from >> leveraging those 966 already generated Accessor implementations. >> >> That sound about right? >> >> >> -David >> >> On Feb 28, 2012, at 11:50 PM, Romain Manni-Bucau wrote: >> >> > more info: if you specified custom accessor factory as i said in "memory >> > tweaking" thread you can get rid of the default implementations: >> > >> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java#Accessor.FieldReflection >> > for >> > instance >> > >> > no call to OptimizedAccessorFactory -> no injection :) >> > >> > it can be something like: >> > >> > @XmlAccessorFactory(EjbJar.AccessorFactoryImpl.class) >> > public class EjbJar implements NamedModule { >> > public static final class AccessorFactoryImpl implements >> AccessorFactory { >> > public AccessorFactoryImpl() { >> > System.out.println(); >> > } >> > >> > @Override >> > public Accessor createFieldAccessor(Class aClass, Field field, >> boolean >> > b) throws JAXBException { >> > return new EjbJarField(field); >> > } >> > >> > @Override >> > public Accessor createPropertyAccessor(Class aClass, >> > java.lang.reflect.Method method, java.lang.reflect.Method method1) >> throws >> > JAXBException { >> > return new EjbJarGetterSetter(method, method1); >> > } >> > ... >> > } >> > >> > and then we simply start the context adding a RI property: >> > >> > JAXBContextFactory.newInstance(new Class<?>[] { EjbJar.class }, new >> > HashMap<String, Object>() {{ >> > put(JAXBRIContext.XMLACCESSORFACTORY_SUPPORT, true); >> > }}); >> > >> > - Romain >> > >> > >> > 2012/2/29 Romain Manni-Bucau <rmannibu...@gmail.com> >> > >> >> I spoke about using getter/setter from our own accessorfactory so we >> can >> >> prevent generation and use our well known getter/setter. >> >> >> >> Le 29 févr. 2012 03:44, "David Blevins" <david.blev...@gmail.com> a >> >> écrit : >> >> >> >> >> >>> On Feb 27, 2012, at 10:02 PM, Romain Manni-Bucau wrote: >> >>> >> >>>> Was my analysis so the question is do we still need to capture them >> >>> like it >> >>>> or can we use more simple setters/getters? >> >>> >> >>> The accessors are generated regardless if field or getters/setters are >> >>> used. >> >>> >> >>>> Note: the code i pasted in my previous email is the one which is >> >>> generated >> >>>> from the injector. >> >>> >> >>> You might have to give me a line number as I don't see that in the >> >>> NativeMethodAccessorImpl.java you posted in your previous email. >> >>> >> >>>> Ps: maybe i looked too fast but i didnt see jaxb-impl in tomee >> >>> >> >>> It's part of the jvm as of Java 6, so it's no longer something we >> ship. >> >>> >> >>> That said, if we wanted to certify our JAX-WS stack, we'd have to >> upgrade >> >>> to 2.2 which means putting the jaxb impl in an endorsed dir (same as >> >>> @Resource.lookup) >> >>> >> >>> -David >> >>> >> >>>> Le 28 févr. 2012 06:36, "David Blevins" <david.blev...@gmail.com> a >> >>> écrit : >> >>>> >> >>>>> >> >>>>> On Feb 26, 2012, at 11:59 PM, Romain Manni-Bucau wrote: >> >>>>> >> >>>>>> did you look >> >>>>>> >> >>>>> >> >>> >> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/reflect/NativeMethodAccessorImpl.java >> >>>>>> ? >> >>>>>> >> >>>>>> seems this class usage/generation is not a simple try { >> loadClass() } >> >>>>> catch >> >>>>>> (...) { generate(); } >> >>>>>> >> >>>>>> it is generated if it is often used (> 15 times by default if i >> didnt >> >>>>> look >> >>>>>> too quickly). >> >>>>> >> >>>>> That's a deceptively similar, but unrelated bit of code. Those are >> for >> >>>>> the java.lang.reflect API. >> >>>>> >> >>>>> I grabbed the JAXB RI source and dug around (svn co >> >>>>> https://svn.java.net/svn/jaxb~version2/tags/jaxb-2_1_9). This >> >>> appears to >> >>>>> be the mechanism it uses to determine if the class has already been >> >>>>> generated: >> >>>>> >> >>>>> >> >>>>> >> >>> >> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/com/sun/xml/internal/bind/v2/runtime/reflect/opt/Injector.java?av=f#112 >> >>>>> >> >>>>> Basically a weak hashmap of classloaders and "Injector" instances >> where >> >>>>> each "Injector" holds a hashmap of classes that have been generated. >> >>>>> >> >>>>> Not sure how we get around it other than an AccessorFactory. >> >>>>> >> >>>>>> Custom accessors is probably the key. >> >>>>> >> >>>>> Perhaps one that just instantiates the generated Accessors we've >> >>> captured. >> >>>>> >> >>>>> >> >>>>> -David >> >>>>> >> >>>>>> >> >>>>>> 2012/2/27 David Blevins <david.blev...@gmail.com> >> >>>>>> >> >>>>>>> >> >>>>>>> On Sep 26, 2011, at 12:43 AM, David Blevins wrote: >> >>>>>>> >> >>>>>>>> # JAXB Accessors >> >>>>>>>> >> >>>>>>>> One of the biggest polluters of the class space is JAXB as it >> >>> generates >> >>>>>>> accessors for all the fields. First thought is, gee, I wonder if >> we >> >>>>> can do >> >>>>>>> that at build time and keep the class definitions. If there's >> some >> >>> way >> >>>>> we >> >>>>>>> could write down those classes, it could save us a lot of trouble >> at >> >>>>>>> runtime. We'd get a great speed boost on the cold start -- which >> is >> >>>>> where >> >>>>>>> unit test performance lives. >> >>>>>>>> >> >>>>>>>> A while back I did some perf testing of our OpenEJB 3.0 speed and >> >>> JAXB >> >>>>>>> was nearly half of the time it took to boot. We have a bigger >> JAXB >> >>> tree >> >>>>>>> than we did and that can easily account for a sliver of the >> slightly >> >>>>> slower >> >>>>>>> embedded speed. >> >>>>>>>> >> >>>>>>>> The classes exist, so there has to be some way to write them to >> disk >> >>>>>>> even if there is no magical flag that will make the JAXB RI do it >> for >> >>>>> us. >> >>>>>>> Would be great to know if such a flag did exist. If someone is >> >>> looking >> >>>>>>> for a research problem, this would be a great one. >> >>>>>>> >> >>>>>>> Did some work on this. >> >>> https://issues.apache.org/jira/browse/TOMEE-143 >> >>>>>>> >> >>>>>>> With a JavaAgent, we monitor all classes created and their >> bytecode. >> >>>>>>> Anything that is a "$JaxbAccessor" class is written to disk. The >> new >> >>>>>>> openejb-jee-accessors module contains all these accessors. >> >>>>>>> >> >>>>>>> $ ls -lh target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar >> >>>>>>> -rw-r--r-- 1 dblevins dblevins 596K Feb 26 15:48 >> >>>>>>> target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar >> >>>>>>> >> >>>>>>> $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | >> >>>>> grep >> >>>>>>> 'WebApp' >> >>>>>>> 666 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_absoluteOrdering.class >> >>>>>>> 608 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_contextParam.class >> >>>>>>> 652 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_dataSource.class >> >>>>>>> 610 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_distributable.class >> >>>>>>> 654 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbLocalRef.class >> >>>>>>> 644 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_ejbRef.class >> >>>>>>> 648 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_envEntry.class >> >>>>>>> 602 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_errorPage.class >> >>>>>>> 596 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_filter.class >> >>>>>>> 610 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_filterMapping.class >> >>>>>>> 640 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_icon.class >> >>>>>>> 602 Sun Feb 26 15:48:22 PST 2012 >> >>>>>>> org/apache/openejb/jee/WebApp$JaxbAccessorF_jspConfig.class >> >>>>>>> [....] >> >>>>>>> >> >>>>>>> $ jar tvf target/openejb-jee-accessors-4.0.0-beta-3-SNAPSHOT.jar | >> >>>>> grep >> >>>>>>> -c 'class$' >> >>>>>>> 966 >> >>>>>>> >> >>>>>>> Soo... all that and it doesn't seem to work :) >> >>>>>>> >> >>>>>>> mingus:~/openejb/examples 04:13:17 >> >>>>>>> $ for n in simple-stateless* ; do (cd $n && mvn clean install); >> >>> done >> >>>>> | >> >>>>>>> egrep 'Time elapsed|JAXBContext' >> >>>>>>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: >> >>> 0.918 >> >>>>>>> sec >> >>>>>>> JAXBContext.newInstance 403 org.apache.openejb.jee.EjbJar >> >>>>>>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: >> >>> 1.341 >> >>>>>>> sec >> >>>>>>> >> >>>>>>> I think we're darn close though. >> >>>>>>> >> >>>>>>> I'd like to shift gears and work on more classpath scanning >> >>> performance >> >>>>>>> boosts, if someone wants to pickup this task and see what we might >> >>> have >> >>>>> to >> >>>>>>> do to get JAXB to see the classes we've generated, that'd be >> great. >> >>>>>>> >> >>>>>>> Could shave half a second or a second off of even a simple test. >> >>>>>>> >> >>>>>>> >> >>>>>>> -David >> >>>>>>> >> >>>>>>> >> >>>>> >> >>>>> >> >>> >> >>> >> >> >
