Hi,
After some more detailed step debugging, i figured that by overriding below
method in JAXBDataBinding i could trick cxf into reusing the same
jaxbcontext:
@Override
public JAXBContextCache.CachedContextAndSchemas
createJAXBContextAndSchemas(Set> classes, String defaultNs) throws
JAXBE
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 wrote:
>
> OH…. Two issues:
>
> 1) I don’t think the data binding ob
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 messag
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
> On Oct 7, 2015, at 9:42 AM, Jorg Heymans 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
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
> On Oct 5, 2015, at 6:12 AM, Jorg Heymans 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
> laz
Hi,
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
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 Shakir
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.
> --
10 matches
Mail list logo
