OK 1) i can easily solve but 2) means changing the way the model is
generated that is too much of a risk for me. I will just leave it as is
then.
Thanks anyway for your help !
Jorg
On Thu, Oct 8, 2015 at 1:53 PM Daniel Kulp <dk...@apache.org> wrote:
>
> OH…. Two issues:
>
> 1) I don’t think the data binding object itself can be a singleton, just
> the context it holds onto.
>
> 2) The error implies that you don’t have ALL the classes that are needed.
> For JAXWS, we internally (via ASM) will create the wrapper classes for the
> doc/lit wrapped messages if there are not classes for them. That’s likely
> why it was ending up with new JAXB contexts for each with the previous
> setup as well.
>
> I would suggest running a java2wsdl on the classes with the -wrapperbean
> flag to have it generate those wrappers. You may then need to add
> @RequestWrapper and @ResponseWrappper annotations to point to the right
> classes.
>
>
> Dan
>
>
>
>
> > On Oct 8, 2015, at 2:04 AM, Jorg Heymans <jorg.heym...@gmail.com> wrote:
> >
> > Tried this, got exception during startup :
> >
> > Caused By: org.apache.cxf.service.factory.ServiceConstructionException:
> > Service class my.ProgrammeService method getProgramme part {
> > http://my/service/programme/v0}parameters cannot be mapped to schema.
> Check
> > for use of a JAX-WS-specific type without the JAX-WS service factory
> bean.
> > at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createBareMessage(ReflectionServiceFactoryBean.java:1227)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:477)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:712)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:527)
> > [INFO] [talledLocalContainer] at
> >
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
> >
> > Config:
> >
> > <bean id="singletonJAXBDataBinding"
> class="my.SingletonJAXBDataBinding"/>
> >
> > <jaxws:client serviceClass="my.ProgrammeService" address="http://
> > ${loadbalancer}/service/programme/v0">
> > <jaxws:dataBinding>
> > <ref bean="singletonJAXBDataBinding"/>
> > </jaxws:dataBinding>
> > </jaxws:client>
> >
> > Presumably the jaxb context i have init'ed myself is not quite what cxf
> is
> > expecting ?
> >
> > Jorg
> >
> >
> >
> > On Wed, Oct 7, 2015 at 6:30 PM Daniel Kulp <dk...@apache.org> wrote:
> >
> >>
> >>> On Oct 7, 2015, at 9:42 AM, Jorg Heymans <jorg.heym...@gmail.com>
> wrote:
> >>>
> >>> The only thing i could easily try was option 2, but it did not make a
> >>> difference. We have about 6-700 entities in our schema divided over
> >> several
> >>> hundreds of packages. All of this is put in the same jaxbcontext.
> >>>
> >>> Enabling jaxb logging reveals that the context is indeed recreated for
> >> each
> >>> service (i.e. each definition of jaxws:client), and given the amount of
> >>> entities and packages it just adds up tremendously. For example jaxb
> >> seems
> >>> to search for jaxb.properties in every single package present in the
> >>> context. We see a big difference though on local deployment using fast
> >>> windows SSD machines and server side deployments on virtualized
> >>> infrastructure, on the former it is more bearable about 45 seconds.
> >>>
> >>> Also, for other application purposes i am myself already constructing
> the
> >>> jaxbcontext as a singleton. Could i not make cxf reuse that one somehow
> >> ? I
> >>> looked at JAXBContextCache but it's not so clear how i would go about
> >>> initializing it with an existing context.
> >>
> >> One option would be to subclass org.apache.cxf.jaxb.JAXBDataBinding and
> >> override the
> >>
> >> public CachedContextAndSchemas createJAXBContextAndSchemas(Set<Class<?>>
> >> classes,
> >> String
> >> defaultNs);
> >>
> >> method. The CachedContextAndSchemas object that is returned could be a
> >> singleton for your application that contains your global JAXBContext.
> >>
> >> In the spring config, you can do:
> >>
> >> <jaxws:client …..>
> >> <jaxws:dataBinding>
> >> <bean class=“org.foo.MyJAXBDataBinding”>
> >> ;;; inject whatever you need in here
> >> </bean>
> >> </jaxws:dataBinding>
> >> </jaxws:client>
> >>
> >>
> >>
> >> Dan
> >>
> >>
> >>>
> >>> Jorg
> >>>
> >>>
> >>>
> >>> On Tue, Oct 6, 2015 at 3:58 PM Daniel Kulp <dk...@apache.org> wrote:
> >>>
> >>>>
> >>>>> On Oct 5, 2015, at 6:12 AM, Jorg Heymans <jorg.heym...@gmail.com>
> >> wrote:
> >>>>> It seems that jaxb context init is still the culprit. We use the
> >>>>> com.sun.xml.bind.v2.ContextFactory , switching for example to the
> >>>>> Eclipselink implementation
> >>>>> (org.eclipse.persistence.jaxb.JAXBContextFactory) was even slower.
> >>>> Spring's
> >>>>> lazy init is no good here, makes me wonder if cxf could do a 'true'
> >> lazy
> >>>>> init and defer this expensive init of the service until actual
> methods
> >>>> are
> >>>>> called on it. Feasible ?
> >>>>
> >>>> Not really, no. We need the information from the context to check to
> >>>> make sure the methods on the clients are even valid.
> >>>>
> >>>> It’s possible that 15 clients are creating 15 unique JAXB Contexts.
> >> One
> >>>> thing you could TRY is collect ALL the classes that are used by all 15
> >>>> clients and do one of:
> >>>>
> >>>> 1) Add @XmlSeeAlso annotations or similar to pull in all the classes
> >>>>
> >>>> 2) Use the “jaxb.additionalContextClasses” property to provide a list
> of
> >>>> all the classes
> >>>> <jaxws:properties>
> >>>> <entry key="jaxb.additionalContextClasses">
> >>>> <bean
> >>>> class="org.apache.cxf.systest.jaxb.util.ClassArrayFactoryBean">
> >>>> <property name="classNames">
> >>>> <list>
> >>>>
> >>>> <value>org.apache.cxf.systest.jaxb.model.ExtendedWidget</value>
> >>>> </list>
> >>>> </property>
> >>>> </bean>
> >>>> </entry>
> >>>> </jaxws:properties>
> >>>>
> >>>> 3) Possibly create a list of all the classes and pre-initialize via
> the
> >>>> JAXBContextCache.getCachedContextAndSchemas method. I’m not 100%
> sure
> >>>> this will work.
> >>>>
> >>>>
> >>>> Basically, if you can get ONE large JAXBContext serving all the
> clients,
> >>>> it might be quicker than 15 smaller. Not really sure though.
> >>>>
> >>>> Dan
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Jorg
> >>>>>
> >>>>> On Mon, Oct 5, 2015 at 10:42 AM Jorg Heymans <jorg.heym...@gmail.com
> >
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> The wsdlLocation attribute is not specified, and to be honest i have
> >> no
> >>>>>> idea if there is any remote downloading involved during startup. We
> >> just
> >>>>>> specify id and serviceClass attribute and let cxf do its thing. I
> will
> >>>>>> try to profile and report back.
> >>>>>>
> >>>>>> Jorg
> >>>>>>
> >>>>>> On Sun, Oct 4, 2015 at 5:23 PM Andrei Shakirin <
> ashaki...@talend.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> 2.5 to 3 minutes is quite long even for 15 clients initialization.
> >>>>>>> Did you specify wsdlLocation attribute in jaxws:client? Can
> >> performance
> >>>>>>> be related to remote WSDL downloading?
> >>>>>>> Could you bind any profiling tool and discover which operation
> caused
> >>>>>>> performance problem?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Andrei.
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Jorg Heymans [mailto:jorg.heym...@gmail.com]
> >>>>>>>> Sent: Donnerstag, 1. Oktober 2015 08:45
> >>>>>>>> To: users@cxf.apache.org
> >>>>>>>> Subject: ReflectionServiceFactoryBean performance
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> We have about 15 jaxws client definitions in our application
> context
> >>>>>>> defined
> >>>>>>>> like this :
> >>>>>>>>
> >>>>>>>> <jaxws:client id="myService" serviceClass="my.service.Service"
> >>>>>>>> address="http://....."/>
> >>>>>>>>
> >>>>>>>> Initializing all of these during startup takes on average about
> 2.5
> >> to
> >>>>>>> 3 minutes.
> >>>>>>>> This is already after adding -
> >>>>>>>> Dcom.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot=true ,
> before
> >>>>>>> that it
> >>>>>>>> was more like 5-6 minutes.
> >>>>>>>>
> >>>>>>>> Is there a way to improve this ? We are going to add more services
> >> as
> >>>>>>> the
> >>>>>>>> application grows, and already now this cxf init takes up more
> than
> >>>>>>> half of our
> >>>>>>>> deployment time.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Jorg Heymans
> >>>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Daniel Kulp
> >>>> dk...@apache.org - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>>
> >>>>
> >>
> >> --
> >> Daniel Kulp
> >> dk...@apache.org - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
