Continued trimming of Aegis
Apologies if this proves less that coherent. As it was first built, Aegis centered around a map that connected Java types (specified as Class objects) and Aegis 'Type' objects. A type object does reading and writing. Obviously, such a system will treat all List objects as the same thing. Pre-Java-5, Aegis supported List and Map via XML specs that stated, for a particular method parameter or bean property, what to use as the list component or map key and value. In this situation, instead of using a generic Aegis Type object, a new one gets instantiated and hung onto by either the service model (for a parameter) or the 'BeanType' object. For Java5, this was enhanced with code that would look at the java.lang.reflect.Type information to obtain the same information. The type mapping is also used to get from xsi:type attributes to types. In the generic case, this leads to a somewhat incoherent situation. The type mapping is bidirectional: it can map a type QName to an Aegis type, or a Class to an Aegis type. For these filled-in generics, they fight with each other in the type mapping to map the Class, but they they can be unique in the QName direction. This more or less works, since the xsi type reading case only looks up by qname, and, when writing, the specific Aegis Type is available and need not be obtained from the map. Due to the duel over the Class slot in the map, there has been internal disagreement in the code over whether these specific types get registered or not. My nose has been rubbed in all of this by the JAX-RS situation. JAX-RS wants to be able to read a message, specifying what to read via both a Class and a full java.lang.reflect.Type -- in other words, a full generic. Now, if the map mapped 'Type' instead of 'Class', it would seem possible to make all this cohere. List, List, and List could all be distinctly mapped. However, working with java.lang.reflect.Type and it's subclasses is not so easy. The API has some gaps. In particular, I see no way to get from "java.util.List' and "java.lang.Integer" to a ParmeterizedType object for List. I feel as if I must be missing something, since javac must do something like this somehow. So, say that I wanted to move Aegis to book-keeping in Type. There are plenty of things that happen that require Class. Things get newInstanced, for example. So in some places it would be critical to have both a Type and a Class, or at least to have a very convenient utility for the rigamarole to get from one to the other. If I can't manufacture a ParameterizedType on demand, I have to either get rid of the old Java 1.4 support for properties of naked collection types with XML to fill in, or I need some object that is the 'union' of a Type and a manual description to use in mapping. Before I do either of this things, I thought I'd see if anyone else knows a better way.
Re: WSDL2JS
> How convoluted would it be for me at least to isolate tools like the wsdl2js > and their classes (WSDLToJavascript etc.) > and port it into J2ME-CDC or CLDC? Pretty damn convoluted, and many months of labor, if I recall the CDC, CLDC profile limitations correctly (file system issues, missing classes, potentially weird XML parser issues, resource constraints, missing java annotations, missing generics...) If you use standard WS interactions, then YES, you SHOULD be able to invoke services implemented using different technologies from a CXF client, although it is seldom trivial if your WSDL is complex. So, in theory you should be able to invoke a ksoap server from a CXF client. The best way to find out more is to just give it a shot. --oh
Re: svn commit: r809790 [1/3]
That's what padb means. If you want to be able to work with more than one List or Map, you have to use Type instead of class. I have a lot of more furniture to move to keep the distinct generics distinct before I tie a bow on it with the padb interface. On Tue, Sep 1, 2009 at 9:45 AM, Sergey Beryozkin wrote: > Hi Benson > > Are you planning to have AegisDatabinding supporting the > PropertiesAwareDataBinding interface ? Or does 'padb' mean something > else...I've looked at the source but AegisDatabinding is not implementing it > yet. If you decide to implement it then JAXRS will pass Map but > it can pass Set if it is what AegisDatabinding needs... > > thanks, Sergey > > - Original Message - From: > To: > Sent: Tuesday, September 01, 2009 2:13 AM > Subject: svn commit: r809790 [1/3] - in /cxf/trunk/rt: > databinding/aegis/src/main/java/org/apache/cxf/aegis/ > databinding/aegis/src/main/java/org/apache/cxf/aegis/databinding/ > databinding/aegis/src/main/java/org/apache/cxf/aegis/type/ > databinding/aegis/src/main/... > > > Author: bimargulies >> Date: Tue Sep 1 01:13:06 2009 >> New Revision: 809790 >> >> URL: http://svn.apache.org/viewvc?rev=809790&view=rev >> Log: >> Merge branch 'aegispadb' into trunk >> >> >
Re: WSDL2JS
I guess no replies to the previous email below means I am on my own ... At least one more Q: How convoluted would it be for me at least to isolate tools like the wsdl2js and their classes (WSDLToJavascript etc.) and port it into J2ME-CDC or CLDC? I guess primarily the tools cxf,common, cxf.tools.common and a few other classes would be involved but other than that I can find a clean separation between them and the main baseline. Any ideas? Thanks again Demetris wrote: 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
Re: svn commit: r809790 [1/3]
Hi Benson Are you planning to have AegisDatabinding supporting the PropertiesAwareDataBinding interface ? Or does 'padb' mean something else...I've looked at the source but AegisDatabinding is not implementing it yet. If you decide to implement it then JAXRS will pass Map but it can pass Set if it is what AegisDatabinding needs... thanks, Sergey - Original Message - From: To: Sent: Tuesday, September 01, 2009 2:13 AM Subject: svn commit: r809790 [1/3] - in /cxf/trunk/rt: databinding/aegis/src/main/java/org/apache/cxf/aegis/ databinding/aegis/src/main/java/org/apache/cxf/aegis/databinding/ databinding/aegis/src/main/java/org/apache/cxf/aegis/type/ databinding/aegis/src/main/... Author: bimargulies Date: Tue Sep 1 01:13:06 2009 New Revision: 809790 URL: http://svn.apache.org/viewvc?rev=809790&view=rev Log: Merge branch 'aegispadb' into trunk
Re: WARNING: very big commit coming later today....
I haven't really worked on the non-spring case much at all. I'm going to doubt that is going to be able to take advantage of any of what I've done. I'll look more into your other failure shortly. ok, I just posted it in case it could give some additional information... thanks, Sergey Dan On Tue September 1 2009 7:59:05 am Sergey Beryozkin wrote: Without Spring the exception is different : Exception in thread "main" java.lang.NoClassDefFoundError: javax/wsdl/WSDLException at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.getConstructor(Unknown Source) at org.apache.cxf.bus.extension.Extension.load(Extension.java:92) at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(Extension ManagerImpl.java:164) at org.apache.cxf.bus.extension.ExtensionManagerImpl.processExtension(Extensio nManagerImpl.java:140) at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadFragment(ExtensionMan agerImpl.java:133) at org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl .java:125) at org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl .java:94) at org.apache.cxf.bus.extension.ExtensionManagerBus.(ExtensionManagerBus .java:123) at org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:41) at org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:37) at org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:33) at org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:69) at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:106) at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:97) at org.apache.cxf.endpoint.AbstractEndpointFactory.getBus(AbstractEndpointFact ory.java:73) sorry if you didn't get a chance to complete this work yet Sergey Sergey Beryozkin wrote: > Hi Dan > > Did you finish the part 3 of this refactoring ? > I'm setting up a custom JAXRS project in Eclipse and I still have to add > a wsdl4j library to the list of dependencies though I've been able to > drop quite a few dependencies compared to a similar project I set up > earlier... > > Just in case, here is what I'm seeing : > > Caused by: org.springframework.beans.factory.BeanCreationException: Error > creating bean with name > 'org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory' defined > in class path resource [META-INF/cxf/cxf-extension-http-jetty.xml]: > Initialization of bean failed; nested exception is > java.lang.NoClassDefFoundError: javax/wsdl/Port > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact >ory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact >ory$1.run(AbstractAutowireCapableBeanFactory.java:409) at > java.security.AccessController.doPrivileged(Native Method) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact >ory.createBean(AbstractAutowireCapableBeanFactory.java:380) at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject >(AbstractBeanFactory.java:264) at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.ge >tSingleton(DefaultSingletonBeanRegistry.java:221) at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(A >bstractBeanFactory.java:261) at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs >tractBeanFactory.java:185) at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs >tractBeanFactory.java:164) at > org.springframework.context.support.AbstractApplicationContext.getBean(Ab >stractApplicationContext.java:881) at > org.apache.cxf.bus.spring.SpringBeanLocator.loadBeansOfType(SpringBeanLoc >ator.java:72) at > org.apache.cxf.transport.TransportFinder.loadAll(TransportFinder.java:138 >) at > org.apache.cxf.transport.TransportFinder.findTransportForURI(TransportFin >der.java:84) at > org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFact >oryForUri(DestinationFactoryManagerImpl.java:133) at > org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpointInfo(Abstract >JAXRSFactoryBean.java:102) at > org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpoint(AbstractJAXR >SFactoryBean.java:168) at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean >.java:83) > > > cheers, Sergey > > dkulp wrote: >> 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 t
Re: WARNING: very big commit coming later today....
I haven't really worked on the non-spring case much at all. I'm going to doubt that is going to be able to take advantage of any of what I've done. I'll look more into your other failure shortly. Dan On Tue September 1 2009 7:59:05 am Sergey Beryozkin wrote: > Without Spring the exception is different : > > Exception in thread "main" java.lang.NoClassDefFoundError: > javax/wsdl/WSDLException > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) > at java.lang.Class.getConstructor0(Unknown Source) > at java.lang.Class.getConstructor(Unknown Source) > at org.apache.cxf.bus.extension.Extension.load(Extension.java:92) > at > org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(Extension >ManagerImpl.java:164) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.processExtension(Extensio >nManagerImpl.java:140) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.loadFragment(ExtensionMan >agerImpl.java:133) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl >.java:125) at > org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl >.java:94) at > org.apache.cxf.bus.extension.ExtensionManagerBus.(ExtensionManagerBus >.java:123) at > org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:41) at > org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:37) at > org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:33) at > org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:69) > at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:106) > at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:97) > at > org.apache.cxf.endpoint.AbstractEndpointFactory.getBus(AbstractEndpointFact >ory.java:73) > > > sorry if you didn't get a chance to complete this work yet > > Sergey > > Sergey Beryozkin wrote: > > Hi Dan > > > > Did you finish the part 3 of this refactoring ? > > I'm setting up a custom JAXRS project in Eclipse and I still have to add > > a wsdl4j library to the list of dependencies though I've been able to > > drop quite a few dependencies compared to a similar project I set up > > earlier... > > > > Just in case, here is what I'm seeing : > > > > Caused by: org.springframework.beans.factory.BeanCreationException: Error > > creating bean with name > > 'org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory' defined > > in class path resource [META-INF/cxf/cxf-extension-http-jetty.xml]: > > Initialization of bean failed; nested exception is > > java.lang.NoClassDefFoundError: javax/wsdl/Port > > at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact > >ory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact > >ory$1.run(AbstractAutowireCapableBeanFactory.java:409) at > > java.security.AccessController.doPrivileged(Native Method) > > at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact > >ory.createBean(AbstractAutowireCapableBeanFactory.java:380) at > > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject > >(AbstractBeanFactory.java:264) at > > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.ge > >tSingleton(DefaultSingletonBeanRegistry.java:221) at > > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(A > >bstractBeanFactory.java:261) at > > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs > >tractBeanFactory.java:185) at > > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs > >tractBeanFactory.java:164) at > > org.springframework.context.support.AbstractApplicationContext.getBean(Ab > >stractApplicationContext.java:881) at > > org.apache.cxf.bus.spring.SpringBeanLocator.loadBeansOfType(SpringBeanLoc > >ator.java:72) at > > org.apache.cxf.transport.TransportFinder.loadAll(TransportFinder.java:138 > >) at > > org.apache.cxf.transport.TransportFinder.findTransportForURI(TransportFin > >der.java:84) at > > org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFact > >oryForUri(DestinationFactoryManagerImpl.java:133) at > > org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpointInfo(Abstract > >JAXRSFactoryBean.java:102) at > > org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpoint(AbstractJAXR > >SFactoryBean.java:168) at > > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean > >.java:83) > > > > > > cheers, Sergey > > > > dkulp wrote: > >> 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
Re: WARNING: very big commit coming later today....
Without Spring the exception is different : Exception in thread "main" java.lang.NoClassDefFoundError: javax/wsdl/WSDLException at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.getConstructor(Unknown Source) at org.apache.cxf.bus.extension.Extension.load(Extension.java:92) at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadAndRegister(ExtensionManagerImpl.java:164) at org.apache.cxf.bus.extension.ExtensionManagerImpl.processExtension(ExtensionManagerImpl.java:140) at org.apache.cxf.bus.extension.ExtensionManagerImpl.loadFragment(ExtensionManagerImpl.java:133) at org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl.java:125) at org.apache.cxf.bus.extension.ExtensionManagerImpl.load(ExtensionManagerImpl.java:94) at org.apache.cxf.bus.extension.ExtensionManagerBus.(ExtensionManagerBus.java:123) at org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:41) at org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:37) at org.apache.cxf.bus.CXFBusFactory.createBus(CXFBusFactory.java:33) at org.apache.cxf.BusFactory.getDefaultBus(BusFactory.java:69) at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:106) at org.apache.cxf.BusFactory.getThreadDefaultBus(BusFactory.java:97) at org.apache.cxf.endpoint.AbstractEndpointFactory.getBus(AbstractEndpointFactory.java:73) sorry if you didn't get a chance to complete this work yet Sergey Sergey Beryozkin wrote: > > Hi Dan > > Did you finish the part 3 of this refactoring ? > I'm setting up a custom JAXRS project in Eclipse and I still have to add a > wsdl4j library to the list of dependencies though I've been able to drop > quite a few dependencies compared to a similar project I set up earlier... > > Just in case, here is what I'm seeing : > > Caused by: org.springframework.beans.factory.BeanCreationException: Error > creating bean with name > 'org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory' defined in > class path resource [META-INF/cxf/cxf-extension-http-jetty.xml]: > Initialization of bean failed; nested exception is > java.lang.NoClassDefFoundError: javax/wsdl/Port > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) > at java.security.AccessController.doPrivileged(Native Method) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) > at > org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:881) > at > org.apache.cxf.bus.spring.SpringBeanLocator.loadBeansOfType(SpringBeanLocator.java:72) > at > org.apache.cxf.transport.TransportFinder.loadAll(TransportFinder.java:138) > at > org.apache.cxf.transport.TransportFinder.findTransportForURI(TransportFinder.java:84) > at > org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFactoryForUri(DestinationFactoryManagerImpl.java:133) > at > org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpointInfo(AbstractJAXRSFactoryBean.java:102) > at > org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpoint(AbstractJAXRSFactoryBean.java:168) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:83) > > > cheers, Sergey > > > dkulp wrote: >> >> >> 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
Re: WARNING: very big commit coming later today....
Hi Dan Did you finish the part 3 of this refactoring ? I'm setting up a custom JAXRS project in Eclipse and I still have to add a wsdl4j library to the list of dependencies though I've been able to drop quite a few dependencies compared to a similar project I set up earlier... Just in case, here is what I'm seeing : Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory' defined in class path resource [META-INF/cxf/cxf-extension-http-jetty.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: javax/wsdl/Port at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:881) at org.apache.cxf.bus.spring.SpringBeanLocator.loadBeansOfType(SpringBeanLocator.java:72) at org.apache.cxf.transport.TransportFinder.loadAll(TransportFinder.java:138) at org.apache.cxf.transport.TransportFinder.findTransportForURI(TransportFinder.java:84) at org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFactoryForUri(DestinationFactoryManagerImpl.java:133) at org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpointInfo(AbstractJAXRSFactoryBean.java:102) at org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpoint(AbstractJAXRSFactoryBean.java:168) at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:83) cheers, Sergey dkulp wrote: > > > 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
Re: generics and type mapping in Aegis
Hi Benson - Original Message - From: "Benson Margulies" To: "CXF Dev" Sent: Monday, August 31, 2009 6:33 PM Subject: generics and type mapping in Aegis Sergey's issues with JAX-RS have started me looking at how Aegis maps types. The following temptation now occurs: allow the fundamental aegis type mechanism to map generics. Somene could thus add a mapping from any X -> XML via a custom type. Of course, with type erasure, this only will pay attention to the declared type, not the dynamic type. Somehow, I feel as if this is a slippery slope we don't want to start down. However, the defined APIs for JAX-RS have started us there, with their extra arguments for generic type specs. Apparently, someone thinks that it's so important to be able to write a Collection to the top of JAX-RS to justify adding an asymmetry. Have a look at this JAXRS resource class : http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/fortest/BookEntity.java and this one : http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/fortest/AbstractEntity.java At runtime the parameter type of BookEntity.postEntity(new Book()) is Object but its Type is TypeVariable that leads to Book.class. CXF takes care of hiding these details from JAXRS providers but I'm not sure it is the case with all other JAXRS impls so one can imagine custom writers actually needing to deal with Type params...And if it were the case then it would make life more complicated for users - thus having seperate parameters lets some implemetations to avoid it. Perhaps there've been some other or just completely different motivations behind introducing Class and Type - for ex, MessageBodyWriter/Reader interfaces are parameterized so say CustomBodyWriter implements MessageBodyWriter would lead to Class being generated in some method signatures, thus allowing the runtimes to do some additional checks, with Types alone it would not be possible cheers, Sergey Anybody else got a thought here?
Re: Seeming JAX-RS mistake
Hi Benson
This interface is meant to be used with types like JAXBContext or (JAXB)
Marshaller, I think it was introduced to let users overcome the issues with the
existing JAXB releases, for some specific types be handled by custom context
providers. For ex, JAXB providers would check if ContextResolver
was registered and then, say, ContextResolver.getContext(Foo.class) will be
called.
I think that in CXF if it were say Collection then a registered
ContextResolver, if any, would not be asked for a JAXBContext for
Collection but for Foo only
cheers, Sergey
- Original Message -
From: Benson Margulies
To: Sergey Beryozkin ; CXF Dev
Sent: Tuesday, September 01, 2009 12:26 AM
Subject: Seeming JAX-RS mistake
This can't work right for generic types (like collections), since it doesn't
use java.lang.reflect.Type.
public interface ContextResolver {
/**
* Get a context of type T that is applicable to the supplied
* type.
* @param type the class of object for which a context is desired
* @return a context for the supplied type or null if a
* context for the supplied type is not available from this provider.
*/
T getContext(Class type);
}
Re: Missing OM* classes
Ok, so I've added the dependency in cxf-api/pom.xml, which allowed compilation to proceed: org.apache.ws.commons.axiom axiom-impl 1.2.7 Is this an omission? I downloaded my local copy from: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.3 Is that not the official release tag? karypid wrote: > > Hi all, > > I'm having a problems compiling CXF 2.2.3. Very early, when it reaches > "Apache CXF API" it hits errors for missing the AXIOM classes: > > [INFO] > > [INFO] Building Apache CXF API > [INFO]task-segment: [install] > > ... > > [INFO] Compiling 263 source files to > D:\aiq\jbossws\projects\cxf-2.2.3\api\target\classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] Compilation failure > > could not parse error message: > org\apache\neethi\PolicyReference.java(org\apache\neethi:PolicyReference.java):35: > > package org.apache.axiom.om does not exist > import org.apache.axiom.om.OMElement; > ^ > ... > -- View this message in context: http://www.nabble.com/Missing-OM*-classes-tp25224076p25236469.html Sent from the cxf-dev mailing list archive at Nabble.com.
