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