Hi Brad
-----Original Message----- From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: 12 November 2008 19:44 To: [email protected] Subject: Re: Configuration of CXF / jax-rs *without* Spring? Sergey, > But may be we should try to do what you suggested but using web.xml > syntax. Do you think it would be doable ? Is it possible to specify additional children to servlet params, so you can declare collections of parameters? I've never looked into it. If there was a section of the DTD/schema which allowed hierarchical parameter markup, then I suppose it could be done, but I'm guessing it is pretty flat name/value in nature. S.B > I guess these relationships can be implicit in the web.xml itself and established at the processing time. > Additional configuration possibility is to introduce a class > scanning feature for providers be automatically picked up I don't > like this feature per se but it might simplify the web.xml or or > external file config in that no providers will have to be explicitly > specified...and it will be more JAX-RS-spec-friendly may be > On the upside, this would make it extremely easy to configure services, because the servlet parameter could just be a root directory which scanned and loaded jars I suppose. > S.B : agreed - in some case it can be handy But on the downside, this doesn't allow the address to be configurable for each service. But this does bring me back to a question I raised about the documentation -- all examples I've seen have the address in the beans.xml files as "/", and the service class @Path attribute specifies the actual path. Are people using the beans.xml file addresses at all? I'm not -- I'm just using path attributes in my class and method declarations. > S.B. - It does not have to be '/' all the time - one can have a different address. I reckon the path segments which are more likely to change in the future should better be set in the config. One problem I see with scanning the classpath is that it's just too much magic - works for simple cases but might cause headaches in more complex cases. And one need to enable it from the comfiguration in the first place (point to packages which can be scanned) - user does not have to enable providers but at the cost of doing a more low-level piece of config. Another problem is that in a large project one can get a clash of providers, say, for the same media type. With Spring we can assign providers to every individual root resource class handling a specific path. But I guess we'll need to do it anyway at some time. I suppose one approach to consolidating configuration approach is to create a some kind of ServiceLoaderBean which can be used by both a servlet configured in web.xml OR instantiated as a bean in the beans.xml file. If that ServiceLoaderBean referenced an external xml file, which contained all service class declarations and config (addresses), then you've effectively consolidated the web.xml and Spring approaches: web.xml would use a servlet to wrap the loader, whereas the spring configuration would load the loader as a bean -- but the same configuration file would be in play, and there would be no need for service bean class declarations in beans.xml. > S.B. I like the idea of consolidating the configurations. Lets talk more about it... Cheers, Sergey Brad On Nov 12, 2008, at 11:13 AM, Sergey Beryozkin wrote: > Hi Brad > > Loading an external file is one option - my initial concern would be > though that we'd need to mantain another configuration format in > this case. Unless we somhow manage to basically reuse jaxrs:server > as is in a non-Spring file - we'd need to do a bit of custom XMl > processing to resolve the references but it might be doable. > > But may be we should try to do what you suggested but using web.xml > syntax. Do you think it would be doable ? > > Additional configuration possibility is to introduce a class > scanning feature for providers be automatically picked up I don't > like this feature per se but it might simplify the web.xml or or > external file config in that no providers will have to be explicitly > specified...and it will be more JAX-RS-spec-friendly may be. > > Cheers, Sergey > >> Sergey, >> >> I'll get a JIRA out there in a bit -- quick question -- what do you >> see the eventual approach to be? I'm guessing based upon the >> programmatic configuration example that a servlet wrapper which does >> the following would work: >> >> - instantiates a JAXRSServerFactoryBean >> - sets the server address >> - loads an external XML file in the form of: >> >> <ServiceBeans> >> <ServiceBean class="com.me.Foo1" address="/"/> >> <ServiceBean class="com.me.Foo2" address="/"/> >> ... >> <ServiceBean class="com.me.Foon" address="/"/> >> </ServiceBeans> >> >> and then dynamically instantiates these, setting them on the factory >> bean. >> - creates the server. >> >> If such a servlet were loaded on startup in the web.xml file, that >> seems like it would do it, no? Of course, I suppose this could just >> be >> added to the CXFServlet. >> >> Thoughts? >> >> Brad >> >> Brad O'Hearne >> Owner / Developer >> Big Hill Software >> ph.480.280.1468 >> fx.888.600.8806 >> [EMAIL PROTECTED] >> http://www.bighillsoftware.com >> >> > > > ------------------------------------------------------------------------ -------- > > >> >> >> On Nov 12, 2008, at 9:22 AM, Sergey Beryozkin wrote: >> >>> Hi Brad >>> >>> No - we can't do it yet but we'll have to be able to do some if not >>> all of the configuration from web.xml... >>> Can you open a JIRA please for this valid issue be tracked and >>> eventually prioritized ? >>> We can only do it with Spring or programmatically at the moment >>> >>> Cheers, Sergey >>> >>>> All, >>>> I was just looking at the jax-rs configuration doc in the user's >>>> guide, and it gives info for configuring jax-rs with a Spring >>>> beans.xml file. Suppose I don't want to use Spring? Can I >>>> configure jax-rs exclusively in my web.xml? >>>> Brad >>>> Brad O'Hearne >>>> Owner / Developer >>>> Big Hill Software >>>> ph.480.280.1468 >>>> fx.888.600.8806 >>>> [EMAIL PROTECTED] >>>> http://www.bighillsoftware.com >>> >>> >>> ------------------------------------------------------------------------ -------- >>> >>> >>>> >> >
