Actually, looking at the code, you may already be able to do this. The JAXBDataBinding has a constructor of:
JAXBDataBinding(JAXBContext context) Thus, via config or similar, you should be able to setup your own JAXBDataBinding object using a preconfigured JAXBContext. Not sure how well tested that is though. Dan On Thu December 3 2009 11:33:52 pm Basavaraja U T wrote: > Hi Dan, > > XFire has provided a mechanism to re-use the JAXBContext across different > web service publishing. > > The Bug Id - XFIRE-669. (http://jira.codehaus.org/browse/XFIRE-669) > > Seems it lets us to pass an existing JAXBContext to a JaxbServiceFactory. > The context is then used by all layers from there. i.e. we can construct > one JAXBContext object with all the ObjectFactory.class'es from wsdl2java > tool generated java files and re-use the JAXBContext object for multiple > web service publishing. > > It helps to reduce the memory usage if there is large no. of related web > services (like MTOSI solution, which has around 30-40 interfaces) are > published by an application. > > It would be great if such a mechanism is provided by CXF also. > > With regards, > Basava > > *************************************************************************** > * *********** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! > > -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Wednesday, November 18, 2009 1:37 AM > To: [email protected] > Cc: Basavaraja U T > Subject: Re: High memory usage with web service registration > > > > In a way, I'm not exactly surprised by this. I just tried debugging some > of > > the annotation stuff in the JRE and annotations are stored in > LinkedHashMaps. > Those hashmaps are definitely not the most memory efficient, especially > for > > cases where there are only one or two annotations. Only Sun/Oracle can do > much about that. > > JAXB COULD probably not output annotations in cases where the defaults > would > > match what the annotation is setting anyway. That could be an enhancement > request to them. You could possibly even write an XJC plugin that would > remove the annotations in the places where they aren't needed. That could > help. > > I'm really not sure what else to suggest. You COULD create a list of ALL > the > jaxb generated classes in all the services and configure them as extra > classes. Thus, every service would create their jaxb context based on all > the classes. We detect when they are the same and allow the services to > share a JAXB context instead of creating a new one. However, that would > allow the services to "know" more than they really should. > > Dan > > On Tue November 17 2009 2:40:06 am Basavaraja U T wrote: > > Hi All, > > > > > > > > I am facing a high memory usage problem with web service registration > > when wsdl has lots of simple and complex type definitions. I am using > > jaxb(default) databinding and memory usage is quite high, it is in the > > range of 2 to 8 MBs for each of the web service registration. I have > > around 20 web services in an application and total memory usage for web > > services registration alone is taking more than 60 MB!. > > > > > > > > I observed the behavior with cxf 2.2 and cxf 2.3 on Windows XP. > > > > I observed there were lots of annotations in java files generated from > > wsdl2java. When these annotations were removed(for testing), the memory > > usage was drastically less. > > > > > > > > Is there any way to reduce/optimize the memory usage? > > > > Is there any optimizations with respect to annotations/binding generated > > by > > > wsdl2java. > > > > > > > > With regards, > > > > Basava > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
