WARNING: very big commit coming later today....
Just a warning, if I can get all the tests passing, I have a big commit coming in today (although broken across a couple commits that will all come at once) that touches a LOT of stuff. Basically, I'm trying to reduce the startup time. Specifically, the "BusFactory.createDefaultBus()" time.I've done some investigation and discovered a few things that are taking a lot of time: 1) JSR250 processing - this is actually fairly expensive the first time. Retrieving annotations is expensive and the JSR250 has to look at every field and method. The second time a class is used it's fast (cached), but that initial startup sucks. I've added a NoJSR250Annotations annotation that can be added to beans loaded from Spring to mark the class as not having any JSR250 annotations anywhere on it so the JSR250 processor can skip it. I've added this annotation to a bunch of places where it can be added. (not all beans can have it, obviously) This alone has about a 20% boost. 2) JAXB context creations - the JAXB based WSDL extensors are creating their JAXB context up front. If those extensors are never used (example: never use the CORBA binding) it's a pointless waste of time. I'm changing them to create them only if needed for parsing/writing. , 3) lazy-init="true" - I'm going through all the cxf-extension-*.xml files and adding lazy-init="true" to almost everything. I'm also updating other code to pull beans "if needed". This has a huge affect of lower the number of beans created at startup. Right now, a default bus creates 57 beans up front, right away (and every one is run through the JSR250 processor).With some changes, I now have this down to 20 beans (and I think I can get it down closer to 15), with only 6 going through JSR250 processing. The major affect of (3) is a lot of stuff doesn't get loaded unless it's needed. If it's needed, you'll take a hit later to get it loaded, but if it's not needed, it's not loaded.For example, if you don't use WSDL's at all (purely code first cases or JAX-RS cases), the WSDLManager is never loaded and thus none of the WSDL extensors are loaded. The "downside" of (3) is that a bunch of tests now fail that I'm trying to fix up.There are many tests that test if the "count" of registered things is a particular number, but now the number is either 0 or much less. I need to update the tests to actually ask for things first to make sure they get loaded. Anyway, it's a pretty big patch that touches a lot of files. Thus, the heads up warning. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: WARNING: very big commit coming later today....
OK Dan, interesting changes :-) Btw, once it's all on svn and a couple of days passed, I can try pointing the jbossws-cxf build to a recent snapshot to check early the integration is fine. Thanks Alessio Daniel Kulp wrote: Just a warning, if I can get all the tests passing, I have a big commit coming in today (although broken across a couple commits that will all come at once) that touches a LOT of stuff. Basically, I'm trying to reduce the startup time. Specifically, the "BusFactory.createDefaultBus()" time.I've done some investigation and discovered a few things that are taking a lot of time: 1) JSR250 processing - this is actually fairly expensive the first time. Retrieving annotations is expensive and the JSR250 has to look at every field and method. The second time a class is used it's fast (cached), but that initial startup sucks. I've added a NoJSR250Annotations annotation that can be added to beans loaded from Spring to mark the class as not having any JSR250 annotations anywhere on it so the JSR250 processor can skip it. I've added this annotation to a bunch of places where it can be added. (not all beans can have it, obviously) This alone has about a 20% boost. 2) JAXB context creations - the JAXB based WSDL extensors are creating their JAXB context up front. If those extensors are never used (example: never use the CORBA binding) it's a pointless waste of time. I'm changing them to create them only if needed for parsing/writing. , 3) lazy-init="true" - I'm going through all the cxf-extension-*.xml files and adding lazy-init="true" to almost everything. I'm also updating other code to pull beans "if needed". This has a huge affect of lower the number of beans created at startup. Right now, a default bus creates 57 beans up front, right away (and every one is run through the JSR250 processor).With some changes, I now have this down to 20 beans (and I think I can get it down closer to 15), with only 6 going through JSR250 processing. The major affect of (3) is a lot of stuff doesn't get loaded unless it's needed. If it's needed, you'll take a hit later to get it loaded, but if it's not needed, it's not loaded.For example, if you don't use WSDL's at all (purely code first cases or JAX-RS cases), the WSDLManager is never loaded and thus none of the WSDL extensors are loaded. The "downside" of (3) is that a bunch of tests now fail that I'm trying to fix up.There are many tests that test if the "count" of registered things is a particular number, but now the number is either 0 or much less. I need to update the tests to actually ask for things first to make sure they get loaded. Anyway, it's a pretty big patch that touches a lot of files. Thus, the heads up warning. -- Alessio Soldano Web Service Lead, JBoss
Re: Integrating JAX-RS runtime into DOSGi
Hi Josh I've updated the JAX-RS layer in DOSGi such that it will now discover JAXRS (and CXF specific providers) which have been registered as (global) OSGI services. At the moment I've decided not to use a ServiceTracker and instead a calling BundleContext is asked to exercise a filter expression which should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper, as well as CXF RequestHandler, ResponseHandler & ParameterHandler. I'll attempt to optimize it later on One can disable such queries for such providers and also insist that only those global providers which have identified themselves (through a specific property) that they will work reliably with CXF can be used. Alternatively, one can register an array of service/endpoint -specific providers by using "org.apache.cxf.rs.provider" property, when registering an application service. Will document it tomorrow Give it a try please whenever you get a chance and let me know if it works for you cheers, Sergey Josh Holtzman wrote: > > Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS endpoints. > > Josh > > On Aug 21, 2009 6:28 PM, "Sergey Beryozkin" wrote: > > Hi Josh > > Can you please let me know if JAXB is being used for your JAX-RS endpoints > ? > I've spotted that for HTTP Service based JAX-RS endpoints no AegisProvider > is being set - I'would actually like JAXB being used by default for JAXRS > endpoints which will be consistent with the expectations of JAX-RS users > in > general - but I'd like to confirm first that JAXB is working ok in your > case... > > thanks, Sergey > >> Sergey, > Thanks again for the detailed documentation you've provided in > this thread. > I was ab... > > -- View this message in context: http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Search field in user's guide doesn't work
On Mon August 24 2009 9:54:20 am Glen Mazza wrote: > Hello, the search functionality on this page is no longer working (possibly > related to the new layout?): > http://cxf.apache.org/docs/index.html > > Could someone in the know fix this? Well, it has to do with pulling the "links" to the docs off of http://cwiki.apache.org/CXF20DOCS and into http://cxf.apache.org/docs. Apparently, the built in search stuff doesn't work when copied over to the static site area. :-( I've changed the search field to do a "get" to the search url on cwiki for now. I'm trying to get google searches to pick up stuff in cxf.apache.org/docs, but google hasn't seemed to index that yet (neither has yahoo). I've created a sitemap and such and submitted it, hopefully they'll get it indexed soon and we might be able to flip over to a google search. Not really sure how well that will work yet though. Anyway, in an hour or two, the new index.html for docs should be synced over which, at the very least, should allow some sort of basic search. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: WARNING: very big commit coming later today....
OK. "Part 1" (I have more ideas) is in. A "default" bus has gone from over 55 beans created and initialized down to 12. Startup time for the first Bus has dropped from 2.1 seconds on my machine to 0.9. After the jit warms up and classes loaded and such, subsequent Bus creation has dropped from 105ms to about 60. Obviously, a default bus isn't much use now as nothing is loaded and doing pretty much anything is going to start triggering other parts to load in. Thus, a "full" startup isn't as dramatic, but it's definitely a good start. Dan On Tue August 25 2009 9:40:37 am Daniel Kulp wrote: > Just a warning, if I can get all the tests passing, I have a big commit > coming in today (although broken across a couple commits that will all come > at once) that touches a LOT of stuff. > > Basically, I'm trying to reduce the startup time. Specifically, the > "BusFactory.createDefaultBus()" time.I've done some investigation and > discovered a few things that are taking a lot of time: > > 1) JSR250 processing - this is actually fairly expensive the first time. > Retrieving annotations is expensive and the JSR250 has to look at every > field and method. The second time a class is used it's fast (cached), but > that initial startup sucks. I've added a NoJSR250Annotations annotation > that can be added to beans loaded from Spring to mark the class as not > having any JSR250 annotations anywhere on it so the JSR250 processor can > skip it. I've added this annotation to a bunch of places where it can be > added. (not all beans can have it, obviously) This alone has about a 20% > boost. > > 2) JAXB context creations - the JAXB based WSDL extensors are creating > their JAXB context up front. If those extensors are never used (example: > never use the CORBA binding) it's a pointless waste of time. I'm changing > them to create them only if needed for parsing/writing. , > > 3) lazy-init="true" - I'm going through all the cxf-extension-*.xml files > and adding lazy-init="true" to almost everything. I'm also updating other > code to pull beans "if needed". This has a huge affect of lower the > number of beans created at startup. Right now, a default bus creates 57 > beans up front, right away (and every one is run through the JSR250 > processor).With some changes, I now have this down to 20 beans (and I > think I can get it down closer to 15), with only 6 going through JSR250 > processing. > > The major affect of (3) is a lot of stuff doesn't get loaded unless it's > needed. If it's needed, you'll take a hit later to get it loaded, but if > it's not needed, it's not loaded.For example, if you don't use WSDL's > at all (purely code first cases or JAX-RS cases), the WSDLManager is never > loaded and thus none of the WSDL extensors are loaded. > > The "downside" of (3) is that a bunch of tests now fail that I'm trying to > fix up.There are many tests that test if the "count" of registered > things is a particular number, but now the number is either 0 or much less. > I need to update the tests to actually ask for things first to make sure > they get loaded. > > > Anyway, it's a pretty big patch that touches a lot of files. Thus, the > heads up warning. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: WSDL2JS
Hi Benson et. al., I tried running the D-OSGi in Equinox under J2ME CDC on a Nokia N800 but it failed (I downloaded and activated the single-bungle distro). So I have a feeling I will have the same luck running the CXF stack on that mobile. But I will give the WSDL2JS tool a shot as standalone and run it on a WSDL file that I can generate off the mobile either on a CXF or Axis enabled servers on a hoping that would work. Before I do I am wondering the following - I will have the client mobile generate the javascript code that I can execute via its browser to generate SOAP calls to the remote server mobile running a ksoap2 web service. My questions are, has anyone tried to invoke Axis or any other SOAP-server-engine services from a CXF client (let's say the client is executing the javascript generated from the server's WSDL)? Or do the SOAP messages generated by CXF is annotated in such a way that only its server-side can understand? All this of course provided the client stack can run on the mobile- I am working on testing that now. Thanks Benson Margulies wrote: Demetris, Let me answer/clarify what I can. There are two ways of getting Javascript: 1: ask the server to generate it via the ?js URL. 2: run the generator yourself, either via the command-line driver or the API it calls. Both of this works either code-first or contract first. That is, you start from Java classes with @nnotations, you can directly generate javascript. You don't have to make a wsdl at any point. You could do #2 on the client. However, I am ignorant of the constraints of J2ME or CLDC, so I can't tell you if you can fit the necessary set of our code onto there. --benson On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote: Hi Benson. do you mind if I ask for some clarification? 1) you can ask the server to generate and deliver the javascript client. The server will actually generate and send a javascript client to the requesting remote class correct? But if need be, can the server also generate a WSDL file - which I am assuming can be used on the client side with the WSDL2js to generate the javascript client? 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. But still there is a reduced set of CXF classes that can be run under J2ME-CDC or CLDC? I am looking for the appropriate server/container that I can run under J2ME and which can host CXF web services and I am not having much luck. I think my only option would be to use OSGi (I think Equinox and Knopflerfish can run under J2ME) in which case I will need a bundle-fied version of CXF - I am going over the Distributed OSGi pages on the CXF site hoping that is what I am looking for. Thanks again
