Hi Gary, AFAIK, the RI should cache contexts already based on the Classes used to create the context. Or at least thats what the JAXB spec highly recommends. If you're going to try implementing a cache in JAXBDataBinding I would recommend keying on a Set of Classes instead of the interface. Different services may be configured differently - what really matters are the classes/packages used to create the context. You can check out how I did it inside the SXC JAXBContextImpl here:
http://svn.sxc.codehaus.org/browse/sxc/trunk/sxc-jaxb/src/main/java/com/envoisolutions/sxc/jaxb/JAXBContextImpl.java?r=32 I know that some of the XmlSchema code can be sped up significantly. I started this one day, but it seemed to be a 8-10 hour exercise instead of a 1-2 hour one. They problem is the XmlSchema is needlessly recreating NamespaceContexts. But the code isn't very amenable to changing this - it needs a bit of refactoring and love :-) Another option for speedup is to extend SXC so it generates pre-compiled readers/writers for various JAXBContexts at build time. This would mean we could avoid creating an RI version of the JAXBContext altogether and startup would be nearly instantaneous. The only tricky part is determining what the set of context classes is... Hope that helps, - Dan On 7/19/07, Tully, Gary <[EMAIL PROTECTED]> wrote:
Hi, Has anyone looked at caching JAXBContexts on a per jaxws service basis? I have been looking at the cpu profile of calls to org.apache.cxf.jaxws.ServiceImpl.createPort() The bulk of the work is split between two tasks, building the JAXBBContext and building the XmlSchemaCollection from the wsdl model. In an application that makes many calls to getPort()/createPort() it may make sense to cache both of these. The XMLSchemaCollection is very much part of the WSDL Definition so a cache of the schemas could be something a JAXB specific/aware WSDLManager could maintain. The JAXBContext is a little more complex because of the variety of entry points to it's creation. As an experiment, I splashed a static cache into JAXBDataBinding.initialize() based on Service QName. Initial results were great for my simple test case but the CodeFirstTest showed up the error in my ways as it builds a context from a class rather than a complete wsdl model. Caching on interface class gives better results. A static cache will not be a winner, some one of bus or ServiceImpl will need to manage the cache or reuse factory beans but there is no clear owner of the process that results in JAXBContext creation. Before I look more into this I want to know if anyone has looked into caching JAXBContexts or has any ideas? Thanks in advance, Gary. ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
