Willem, The issue is that they CAN be modified after that. One popular modification is to grab the EndpointInfo out of it and change the address. Other things like adding interceptors to the BindingInfo, changing properties on the service (like to enable schema validation), etc... are all modifications that affect the servicemodel.
Databinding is "less" of an issue, but still one. For example, the databinding has an "mtomThreshold" and a namespaceMap that can be set programatically. In both of those cases, a modification should only affect the proxy on which the modification is made. Thus, the servicemodel would need a full "clone", which may not be easy to do. It's certainly a lot more code to add. That said, I don't think it's a bad idea at all. On the contrary, it's a good idea. It's just a bit of work. Dan On Tuesday 04 March 2008, Willem Jiang wrote: > Hi Dan, > > I think we could cache the ServiceInfo object and DataBinding object > which will take lots of time to be created and can't be modified after > that. Any thought? > > Willem > > Daniel Kulp wrote: > > On Tuesday 04 March 2008, Christopher Cheng wrote: > >> I haven't read the codes of Axis, but I have been using it for 2 > >> years and it doesn't have this problem. > >> Having an overhead for 5-8 seconds is not an option for a > >> production system in term of performance > >> > >> What you are saying is that all the services must implement > >> Clonable interface? > > > > No, not the services themselves. Just our interal service model > > stuff that holds all the metadata. Basically, when creating a new > > service, we need to calculate the metadata. We should cache that > > if possible. > > > > Dan > > > >> On Tue, Mar 4, 2008 at 4:48 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > >>> Christopher, > >>> > >>> We cannot just "reuse" the Service model objects as they are > >>> completely modifiable at runtime. For example, one proxy could be > >>> reconfigured with new address or have additional interceptors > >>> added or similar. Those shouldn't affect others. > >>> > >>> On option that propably would make sense is to add a fast "clone" > >>> functionality to the entire service model so we could cache one, > >>> and then clone it whenever one is really needed. All the > >>> individual versions could be modified and not affect the original. > >>> However, doing that would be quite a bit of work as there are a > >>> LOT of classes that would need to be updated to support that. > >>> > >>> Patches towards that end would be great. :-) > >>> > >>> Dan > >>> > >>> On Monday 03 March 2008, Christopher Cheng wrote: > >>>> wsdl is indeed cached in WSDLManagerImpl.definitionsMap > >>>> > >>>> After reading the codes, I have some questions. My workstation is > >>>> a PentiumD 3GHz with 1.5GB RAM > >>>> > >>>> In the class > >>>> "org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buil > >>>>d Serv iceFromWSDL(String url)", > >>>> "setService(factory.create());" takes 3 seconds > >>>> "getDataBinding().initialize(getService());" takes 2 seconds > >>>> > >>>> These 2 methods are called even in 2nd calls. Can you also cache > >>>> the services perhaps using jakarta commons-pool? or eh-cache? > >>>> > >>>> By the way, I found that the wsdl is put into the definitionMap > >>>> twice if " WSDLManagerImpl.getDefinition(URL url)" is called. > >>>> First in "getDefintion(URL url)" at line 147 and second in > >>>> "loadDefinition(String url)" at line 201. > >>>> > >>>> > >>>> On Mon, Mar 3, 2008 at 4:22 PM, Christopher Cheng < > >>>> > >>>> [EMAIL PROTECTED]> wrote: > >>>>> wsdl is indeed cached in WSDLManagerImpl.definitionsMap > >>>>> > >>>>> After reading the codes, I have some questions. My workstation > >>>>> is a PentiumD 3GHz with 1.5GB RAM > >>>>> > >>>>> In the class " > >>>>> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buil > >>>>> dSer viceFromWSDL(String url)", > >>>>> "setService(factory.create());" takes 3 seconds > >>>>> "getDataBinding().initialize(getService());" takes 2 seconds > >>>>> > >>>>> These 2 methods are called even in 2nd calls. Can you also cache > >>>>> the services perhaps using jakarta commons-pool? or eh-cache? > >>>>> > >>>>> By the way, I found that the wsdl is put into the definitionMap > >>>>> twice if " WSDLManagerImpl.getDefinition(URL url)" is called. > >>>>> First in "getDefintion(URL url)" at line 147 and second in > >>>>> "loadDefinition(String url)" at line 201. > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Mar 3, 2008 at 9:43 AM, Willem Jiang > >>>>> <[EMAIL PROTECTED]> > >>>>> > >>>>> wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I just went through the code, we really cache the WSDL > >>>>>> definition in CXF. > >>>>>> Could you send your test case and wsdl file to me ? I may need > >>>>>> to trace it for more information. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Willem > >>>>>> > >>>>>> Christopher Cheng wrote: > >>>>>>> I think the issue is still there. I used a for loop to > >>>>>>> execute the > >>>>>> > >>>>>> same > >>>>>> > >>>>>>> call, all takes approximately the same time to create > >>>>>>> service. I guess > >>>>>> > >>>>>> that > >>>>>> > >>>>>>> the service itself is not cached. > >>>>>>> > >>>>>>> On Sun, Mar 2, 2008 at 11:43 AM, Willem Jiang > >>>>>>> <[EMAIL PROTECTED]> > >>>>>>> > >>>>>>> wrote: > >>>>>>>> Here is the JIRA[1] which describe the same thing that you > >>>>>>>> want. I don't know if it was really resolved, could you try > >>>>>>>> the latest released CXF 2.0.4 for it. > >>>>>>>> > >>>>>>>> If the issue is still there, please let me know , I will > >>>>>>>> put it to my next week todo list. > >>>>>>>> > >>>>>>>> [1]https://issues.apache.org/jira/browse/CXF-699 > >>>>>>>> [2]http://cwiki.apache.org/CXF/download.html > >>>>>>>> > >>>>>>>> Willem. > >>>>>>>> > >>>>>>>> Christopher Cheng wrote: > >>>>>>>>> I am migrating from Axis1.2 to CXF 2.0.3 > >>>>>>>>> > >>>>>>>>> I understand that it will take a long time to build for > >>>>>>>>> the first > >>>>>> > >>>>>> time. > >>>>>> > >>>>>>>> What > >>>>>>>> > >>>>>>>>> I am wondering is that why it takes so long for the second > >>>>>>>>> and third > >>>>>>>> > >>>>>>>> time? > >>>>>>>> > >>>>>>>>> Is there any caching of services? Axis does not seem to > >>>>>>>>> have this > >>>>>> > >>>>>> issue. > >>>>>> > >>>>>>>>> Christopher Cheng wrote: > >>>>>>>>>> Attached is the log > >>>>>>>>>> > >>>>>>>>>> ----- Original Message ----- > >>>>>>>>>> From: "Willem Jiang" <[EMAIL PROTECTED]> > >>>>>>>>>> To: <[email protected]> > >>>>>>>>>> Sent: Saturday, March 01, 2008 8:53 PM > >>>>>>>>>> Subject: Re: service caching? > >>>>>>>>>> > >>>>>>>>>>> Hi > >>>>>>>>>>> > >>>>>>>>>>> Could you set the logger level to FINE ? > >>>>>>>>>>> So we can get more information about the service > >>>>>>>>>>> publishing. > >>>>>>>>>>> > >>>>>>>>>>> Willem. > >>>>>>>>>>> > >>>>>>>>>>> Christopher Cheng wrote: > >>>>>>>>>>>> When I call the service as a client, it takes 5 seconds > >>>>>>>>>>>> to load. > >>>>>> > >>>>>> I am > >>>>>> > >>>>>>>>>>>> not > >>>>>>>>>>>> sure whether it takes 5 seconds to create the service > >>>>>>>>>>>> or it takes > >>>>>> > >>>>>> 5 > >>>>>> > >>>>>>>>>>>> seconds > >>>>>>>>>>>> to look up for ciper filters. I am wondering if the > >>>>>>>>>>>> services are cached... > >>>>>>>>>>>> Feb 29, 2008 2:14:42 PM > >>>>>>>>>>>> org.apache.cxf.service.factory.ReflectionServiceFactory > >>>>>>>>>>>> Bean buildServiceFromWSDL > >>>>>>>>>>>> INFO: Creating Service > >>>>>>>>>>>> {https://webservices.sabre.com/websvc}OTA_HotelAvailSer > >>>>>>>>>>>> vice<https://webservices.sabre.com/websvc%7DOTA_HotelAva > >>>>>>>>>>>> ilService> > >>>>>>>>>>>> <https://webservices.sabre.com/websvc%7DOTA_HotelAvailS > >>>>>>>>>>>> ervic e> > >>>>>> > >>>>>> <https://webservices.sabre.com/websvc%7DOTA_HotelAvailService> > >>>>>> from > >>> > >>> WSDL: > >>>>>>>>>>>> file:/C:/Java/abacus-webconnect-1.14.0.rc1 > >>>>>>>> > >>>>>>>> /wsdl/OTA_HotelAvailLLS1.4.1RQ.wsdl > >>>>>>>> > >>>>>>>>>>>> Feb 29, 2008 2:14:47 PM > >>>>>>>>>>>> org.apache.cxf.transport.https.SSLUtils getCiphersuites > >>>>>>>>>>>> INFO: The cipher suites have not been configured, > >>>>>>>>>>>> falling back to > >>>>>>>> > >>>>>>>> cipher > >>>>>>>> > >>>>>>>>>>>> suite filters. > >>>>>>>>>>>> Feb 29, 2008 2:14:47 PM > >>>>>>>>>>>> org.apache.cxf.transport.https.SSLUtils > >>>>>>>>>>>> getCiphersFromList INFO: The cipher suites have been > >>>>>>>>>>>> set to > >>>>>> > >>>>>> SSL_RSA_WITH_RC4_128_MD5, > >>>>>> > >>>>>>>>>>>> SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_DES_CBC_SHA, > >>>>>>>>>>>> SSL_DHE_RSA_WITH_DES_CBC_SHA, > >>>>>>>>>>>> SSL_DHE_DSS_WITH_DES_CBC_SHA, > >>>>>>>>>>>> SSL_RSA_EXPORT_WITH_RC4_40_MD5, > >>>>>> > >>>>>> SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, > >>>>>> > >>>>>>>>>>>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, > >>>>>>>>>>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, > >>>>>>>>>>>> SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, > >>>>>>>>>>>> SSL_DH_anon_WITH_RC4_128_MD5, > >>>>>>>>>>>> TLS_DH_anon_WITH_AES_128_CBC_SHA, > >>>>>> > >>>>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, > >>>>>> > >>>>>>>>>>>> SSL_DH_anon_WITH_DES_CBC_SHA, > >>>>>>>>>>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, > >>>>>>>>>>>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, > >>>>>>>>>>>> TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, > >>>>>>>>>>>> TLS_KRB5_EXPORT_WITH_RC4_40_SHA, > >>>>>>>>>>>> TLS_KRB5_EXPORT_WITH_RC4_40_MD5, > >>>>>> > >>>>>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, > >>>>>> > >>>>>>>>>>>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5. Feb 29, 2008 > >>>>>>>>>>>> 2:14:48 PM > >>>>>> > >>>>>> org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallba > >>>>>> ckon Close > >>>>>> > >>>>>>>>>>>> I have put this in my cxf.xml as in > >>>>>>>>>>>> http://cwiki.apache.org/CXF20DOC/client-http-transport. > >>>>>>>>>>>> html , but > >>>>>> > >>>>>> it > >>>>>> > >>>>>>>>>>>> doesn't > >>>>>>>>>>>> help... <http:conduit name="*.http-conduit"> > >>>>>>>>>>>> <http:tlsClientParameters > >>>>>>>>>>>> secureSocketProtocol="SSL"> <sec:cipherSuitesFilter> > >>>>>>>>>>>> <!-- these filters ensure that a > >>>>>>>>>>>> ciphersuite with export-suitable or null encryption is > >>>>>>>>>>>> used, but exclude anonymous Diffie-Hellman key change > >>>>>> > >>>>>> as > >>>>>> > >>>>>>>>>>>> this is vulnerable to man-in-the-middle > >>>>>>>>>>>> attacks > >>>>>> > >>>>>> --> > >>>>>> > >>>>>>>>>>>> <sec:include>.*_EXPORT_.*</sec:include> > >>>>>>>>>>>> > >>>>>>>>>>>> <sec:include>.*_EXPORT1024_.*</sec:include> > >>>>>>>>>>>> <sec:include>.*_WITH_DES_.*</sec:include> > >>>>>>>>>>>> <sec:include>.*_WITH_NULL_.*</sec:include> > >>>>>>>>>>>> <sec:exclude>.*_DH_anon_.*</sec:exclude> > >>>>>>>>>>>> </sec:cipherSuitesFilter> > >>>>>>>>>>>> </http:tlsClientParameters> > >>>>>>>>>>>> </http:conduit> > >>>>>>>>>> > >>>>>>>>>> http://www.nabble.com/file/p15773252/cxf.log cxf.log > >>> > >>> -- > >>> J. Daniel Kulp > >>> Principal Engineer, IONA > >>> [EMAIL PROTECTED] > >>> http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
