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