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 >>>>>>> >>>>>>> >>>>> >>>>> >>> >>>
