yep - Romain
2012/2/29 David Blevins <[email protected]> > 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 <[email protected]> > > > >> 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" <[email protected]> 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" <[email protected]> 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 <[email protected]> > >>>>>> > >>>>>>> > >>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> > >>> > >
