Re: Whiteboard pattern for JAX-RS services
Ok great, thanks Sergey and David! I'll just expose the service twice for now, and update my DS descriptors when the 4.2 spec is released, and when Cxf supports the new syntax. Josh On Friday, June 12, 2009, David Bosschaert wrote: > Hi Josh, > > With the upcoming OSGi 4.2 remote services spec (should be out this > summer) you should be able to do this with a single service that > specifies two configuration types. > Let's say the configuration types are pojo (for the web service - > maybe we need to give this a more descriptive name) and rest, in that > case you could set the following properties on your service: > osgi.remote.interfaces=* > osgi.remote.configuration.type=[pojo, rest] > osgi.remote.configuration.pojo.address=http://localhost:8000/ws > osgi.remote.configuration.rest.address=http://localhost:9000/rest > The Distributed OSGi implementation should export the services using > all the configuration types it understands, so in the case of CXF it > will export it twice, once as a Web Service and once using JAXRS... > > Would something like this work for you? > > BTW some of the propety names will change in the final OSGi spec, but > I'm planning to keep the old ones around too for backward > compatibility. I've used the old names here as the new ones aren't > finalized yet... > > Cheers, > > David > > 2009/6/12 Josh Holtzman : >> In the patch I submitted, I don't think there's a way to expose a service as >> both a wsdl-based endpoint and a restful endpoint. I've been using the >> wsdl-based endpoints for DOSGi communication (hence, my initial focus on >> JAX-WS and the JAXB databinding), and registering jax-rs resources >> separately. I suppose I could register the same service instance twice, >> each with different service properties. Do you think that is the best >> solution for exposing multiple endpoints per service? >> >> Thanks, >> Josh >> >> >> On Fri, Jun 12, 2009 at 8:11 AM, David Bosschaert < >> david.bosscha...@gmail.com> wrote: >> >>> Yeah, so simply putting the property >>> osgi.remote.interfaces=* >>> on an OSGi service that is put in the OSGi service registry makes it >>> available remotely through CXF/DOSGi. If you select the JAX/RS >>> configueration type (which is currently being worked on) it should >>> make it available via JAX-RS >>> >>> Isn't that exactly the whiteboard pattern as desired? I don't really >>> see the value of picking *another* osgi service property for this >>> purpose as well... >>> >>> David >>> >>> 2009/6/12 Sergey Beryozkin : >>> > Hi Josh >>> > >>> > It seems that in DOSGi RI this is actually what is being done. When a >>> > service is being registered a DSW provider picks up this event and >>> > creates an endpoint. So it should work in the case of JAX-RS & JAX-WS >>> > with the help of properties you introduced in your patch. >>> > >>> > David told me that if a property osgi.remote.interfaces is set to '*' >>> > then it should let DSW to handle unbounded number of interfaces. >>> > >>> > I like the idea of message providers being picked up from the >>> > whiteboard, it is certainly bound to work better in OSGI than say >>> > scanning the classpath. >>> > I'll consider enhancing the DOSGi DSW accordingly. >>> > >>> > Enhancing the CXF bundle on its own (possibly indirectly by introducing >>> > another helper bundle as you suggested) is an interesting idea but the >>> > question is what to do next - that is how to configure such services for >>> > ex. >>> > >>> > What do you think ? Do you have some scenarios in mind that may not be >>> > easy to do with DOSGi ? >>> > >>> > Thanks, Sergey >>> > >>> > >>> > -Original Message- >>> > From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of >>> > Josh Holtzman >>> > Sent: 12 June 2009 15:00 >>> > To: dev@cxf.apache.org >>> > Subject: Whiteboard pattern for JAX-RS services >>> > >>> > I've got some code that allows OSGI bundles to use the whiteboard >>> > pattern to >>> > register restful services. When a service is registered with a specific >>> > property, say, "jaxrs.resource=true" the JAX-RS implementation registers >>> > that service as a JAX-RS resource. The same could be done with message >>> > body >>> > readers and writers, too. In my implementation, the JAX-RS servlet is >>> > registered under the "/rest/*" URL, and all of the JAX-RS resources fall >>> > below that, so /rest/foo can be provided by one bundle and /rest/bar >>> > could >>> > be provided by another. >>> > >>> > Is this something the CXF folks would be interested in adding? If so, >>> > does >>> > it belong in the cxf-minimal bundle, or as its own add-on bundle? If >>> > people >>> > are familiar with pax-web and pax-web-extender-whiteboard, they'll >>> > recognize >>> > that this kind of thing can be broken out into its own bundle. In the >>> > pax-web case, though, they decided to merge the whiteboard functionality >>> > into their main bundle. >
RE: Whiteboard pattern for JAX-RS services
Yes, you can expose the same service bean using JAXWS & JAXRS. So registering the same instance using diff frontend property should work. The only limitation at the moment is that a different address needs to be specified, that is say it should be "http://localhost:8080:services/jaxws"; and "http://localhost:8080:services/jaxrs"; - but I'll try to enhance the JAX-RS runtime to register a message dispatcher which will ensure JAXRS & JAXWS endpoints can share the same address. Cheers, Sergey -Original Message- From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of Josh Holtzman Sent: 12 June 2009 16:39 To: dev@cxf.apache.org Subject: Re: Whiteboard pattern for JAX-RS services In the patch I submitted, I don't think there's a way to expose a service as both a wsdl-based endpoint and a restful endpoint. I've been using the wsdl-based endpoints for DOSGi communication (hence, my initial focus on JAX-WS and the JAXB databinding), and registering jax-rs resources separately. I suppose I could register the same service instance twice, each with different service properties. Do you think that is the best solution for exposing multiple endpoints per service? Thanks, Josh On Fri, Jun 12, 2009 at 8:11 AM, David Bosschaert < david.bosscha...@gmail.com> wrote: > Yeah, so simply putting the property > osgi.remote.interfaces=* > on an OSGi service that is put in the OSGi service registry makes it > available remotely through CXF/DOSGi. If you select the JAX/RS > configueration type (which is currently being worked on) it should > make it available via JAX-RS > > Isn't that exactly the whiteboard pattern as desired? I don't really > see the value of picking *another* osgi service property for this > purpose as well... > > David > > 2009/6/12 Sergey Beryozkin : > > Hi Josh > > > > It seems that in DOSGi RI this is actually what is being done. When a > > service is being registered a DSW provider picks up this event and > > creates an endpoint. So it should work in the case of JAX-RS & JAX-WS > > with the help of properties you introduced in your patch. > > > > David told me that if a property osgi.remote.interfaces is set to '*' > > then it should let DSW to handle unbounded number of interfaces. > > > > I like the idea of message providers being picked up from the > > whiteboard, it is certainly bound to work better in OSGI than say > > scanning the classpath. > > I'll consider enhancing the DOSGi DSW accordingly. > > > > Enhancing the CXF bundle on its own (possibly indirectly by introducing > > another helper bundle as you suggested) is an interesting idea but the > > question is what to do next - that is how to configure such services for > > ex. > > > > What do you think ? Do you have some scenarios in mind that may not be > > easy to do with DOSGi ? > > > > Thanks, Sergey > > > > > > -Original Message- > > From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of > > Josh Holtzman > > Sent: 12 June 2009 15:00 > > To: dev@cxf.apache.org > > Subject: Whiteboard pattern for JAX-RS services > > > > I've got some code that allows OSGI bundles to use the whiteboard > > pattern to > > register restful services. When a service is registered with a specific > > property, say, "jaxrs.resource=true" the JAX-RS implementation registers > > that service as a JAX-RS resource. The same could be done with message > > body > > readers and writers, too. In my implementation, the JAX-RS servlet is > > registered under the "/rest/*" URL, and all of the JAX-RS resources fall > > below that, so /rest/foo can be provided by one bundle and /rest/bar > > could > > be provided by another. > > > > Is this something the CXF folks would be interested in adding? If so, > > does > > it belong in the cxf-minimal bundle, or as its own add-on bundle? If > > people > > are familiar with pax-web and pax-web-extender-whiteboard, they'll > > recognize > > that this kind of thing can be broken out into its own bundle. In the > > pax-web case, though, they decided to merge the whiteboard functionality > > into their main bundle. > > > > Full disclosure: I've been using another JAX-RS impl to do this, but > > with > > the CXF impl passing the 1.0 TCK, I figured that it's time to > > re-evaluate :) > > > > Thanks, > > Josh > > >
Re: Whiteboard pattern for JAX-RS services
Hi Josh, With the upcoming OSGi 4.2 remote services spec (should be out this summer) you should be able to do this with a single service that specifies two configuration types. Let's say the configuration types are pojo (for the web service - maybe we need to give this a more descriptive name) and rest, in that case you could set the following properties on your service: osgi.remote.interfaces=* osgi.remote.configuration.type=[pojo, rest] osgi.remote.configuration.pojo.address=http://localhost:8000/ws osgi.remote.configuration.rest.address=http://localhost:9000/rest The Distributed OSGi implementation should export the services using all the configuration types it understands, so in the case of CXF it will export it twice, once as a Web Service and once using JAXRS... Would something like this work for you? BTW some of the propety names will change in the final OSGi spec, but I'm planning to keep the old ones around too for backward compatibility. I've used the old names here as the new ones aren't finalized yet... Cheers, David 2009/6/12 Josh Holtzman : > In the patch I submitted, I don't think there's a way to expose a service as > both a wsdl-based endpoint and a restful endpoint. I've been using the > wsdl-based endpoints for DOSGi communication (hence, my initial focus on > JAX-WS and the JAXB databinding), and registering jax-rs resources > separately. I suppose I could register the same service instance twice, > each with different service properties. Do you think that is the best > solution for exposing multiple endpoints per service? > > Thanks, > Josh > > > On Fri, Jun 12, 2009 at 8:11 AM, David Bosschaert < > david.bosscha...@gmail.com> wrote: > >> Yeah, so simply putting the property >> osgi.remote.interfaces=* >> on an OSGi service that is put in the OSGi service registry makes it >> available remotely through CXF/DOSGi. If you select the JAX/RS >> configueration type (which is currently being worked on) it should >> make it available via JAX-RS >> >> Isn't that exactly the whiteboard pattern as desired? I don't really >> see the value of picking *another* osgi service property for this >> purpose as well... >> >> David >> >> 2009/6/12 Sergey Beryozkin : >> > Hi Josh >> > >> > It seems that in DOSGi RI this is actually what is being done. When a >> > service is being registered a DSW provider picks up this event and >> > creates an endpoint. So it should work in the case of JAX-RS & JAX-WS >> > with the help of properties you introduced in your patch. >> > >> > David told me that if a property osgi.remote.interfaces is set to '*' >> > then it should let DSW to handle unbounded number of interfaces. >> > >> > I like the idea of message providers being picked up from the >> > whiteboard, it is certainly bound to work better in OSGI than say >> > scanning the classpath. >> > I'll consider enhancing the DOSGi DSW accordingly. >> > >> > Enhancing the CXF bundle on its own (possibly indirectly by introducing >> > another helper bundle as you suggested) is an interesting idea but the >> > question is what to do next - that is how to configure such services for >> > ex. >> > >> > What do you think ? Do you have some scenarios in mind that may not be >> > easy to do with DOSGi ? >> > >> > Thanks, Sergey >> > >> > >> > -Original Message- >> > From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of >> > Josh Holtzman >> > Sent: 12 June 2009 15:00 >> > To: dev@cxf.apache.org >> > Subject: Whiteboard pattern for JAX-RS services >> > >> > I've got some code that allows OSGI bundles to use the whiteboard >> > pattern to >> > register restful services. When a service is registered with a specific >> > property, say, "jaxrs.resource=true" the JAX-RS implementation registers >> > that service as a JAX-RS resource. The same could be done with message >> > body >> > readers and writers, too. In my implementation, the JAX-RS servlet is >> > registered under the "/rest/*" URL, and all of the JAX-RS resources fall >> > below that, so /rest/foo can be provided by one bundle and /rest/bar >> > could >> > be provided by another. >> > >> > Is this something the CXF folks would be interested in adding? If so, >> > does >> > it belong in the cxf-minimal bundle, or as its own add-on bundle? If >> > people >> > are familiar with pax-web and pax-web-extender-whiteboard, they'll >> > recognize >> > that this kind of thing can be broken out into its own bundle. In the >> > pax-web case, though, they decided to merge the whiteboard functionality >> > into their main bundle. >> > >> > Full disclosure: I've been using another JAX-RS impl to do this, but >> > with >> > the CXF impl passing the 1.0 TCK, I figured that it's time to >> > re-evaluate :) >> > >> > Thanks, >> > Josh >> > >> >
Re: Whiteboard pattern for JAX-RS services
In the patch I submitted, I don't think there's a way to expose a service as both a wsdl-based endpoint and a restful endpoint. I've been using the wsdl-based endpoints for DOSGi communication (hence, my initial focus on JAX-WS and the JAXB databinding), and registering jax-rs resources separately. I suppose I could register the same service instance twice, each with different service properties. Do you think that is the best solution for exposing multiple endpoints per service? Thanks, Josh On Fri, Jun 12, 2009 at 8:11 AM, David Bosschaert < david.bosscha...@gmail.com> wrote: > Yeah, so simply putting the property > osgi.remote.interfaces=* > on an OSGi service that is put in the OSGi service registry makes it > available remotely through CXF/DOSGi. If you select the JAX/RS > configueration type (which is currently being worked on) it should > make it available via JAX-RS > > Isn't that exactly the whiteboard pattern as desired? I don't really > see the value of picking *another* osgi service property for this > purpose as well... > > David > > 2009/6/12 Sergey Beryozkin : > > Hi Josh > > > > It seems that in DOSGi RI this is actually what is being done. When a > > service is being registered a DSW provider picks up this event and > > creates an endpoint. So it should work in the case of JAX-RS & JAX-WS > > with the help of properties you introduced in your patch. > > > > David told me that if a property osgi.remote.interfaces is set to '*' > > then it should let DSW to handle unbounded number of interfaces. > > > > I like the idea of message providers being picked up from the > > whiteboard, it is certainly bound to work better in OSGI than say > > scanning the classpath. > > I'll consider enhancing the DOSGi DSW accordingly. > > > > Enhancing the CXF bundle on its own (possibly indirectly by introducing > > another helper bundle as you suggested) is an interesting idea but the > > question is what to do next - that is how to configure such services for > > ex. > > > > What do you think ? Do you have some scenarios in mind that may not be > > easy to do with DOSGi ? > > > > Thanks, Sergey > > > > > > -Original Message- > > From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of > > Josh Holtzman > > Sent: 12 June 2009 15:00 > > To: dev@cxf.apache.org > > Subject: Whiteboard pattern for JAX-RS services > > > > I've got some code that allows OSGI bundles to use the whiteboard > > pattern to > > register restful services. When a service is registered with a specific > > property, say, "jaxrs.resource=true" the JAX-RS implementation registers > > that service as a JAX-RS resource. The same could be done with message > > body > > readers and writers, too. In my implementation, the JAX-RS servlet is > > registered under the "/rest/*" URL, and all of the JAX-RS resources fall > > below that, so /rest/foo can be provided by one bundle and /rest/bar > > could > > be provided by another. > > > > Is this something the CXF folks would be interested in adding? If so, > > does > > it belong in the cxf-minimal bundle, or as its own add-on bundle? If > > people > > are familiar with pax-web and pax-web-extender-whiteboard, they'll > > recognize > > that this kind of thing can be broken out into its own bundle. In the > > pax-web case, though, they decided to merge the whiteboard functionality > > into their main bundle. > > > > Full disclosure: I've been using another JAX-RS impl to do this, but > > with > > the CXF impl passing the 1.0 TCK, I figured that it's time to > > re-evaluate :) > > > > Thanks, > > Josh > > >
Re: Whiteboard pattern for JAX-RS services
Yeah, so simply putting the property osgi.remote.interfaces=* on an OSGi service that is put in the OSGi service registry makes it available remotely through CXF/DOSGi. If you select the JAX/RS configueration type (which is currently being worked on) it should make it available via JAX-RS Isn't that exactly the whiteboard pattern as desired? I don't really see the value of picking *another* osgi service property for this purpose as well... David 2009/6/12 Sergey Beryozkin : > Hi Josh > > It seems that in DOSGi RI this is actually what is being done. When a > service is being registered a DSW provider picks up this event and > creates an endpoint. So it should work in the case of JAX-RS & JAX-WS > with the help of properties you introduced in your patch. > > David told me that if a property osgi.remote.interfaces is set to '*' > then it should let DSW to handle unbounded number of interfaces. > > I like the idea of message providers being picked up from the > whiteboard, it is certainly bound to work better in OSGI than say > scanning the classpath. > I'll consider enhancing the DOSGi DSW accordingly. > > Enhancing the CXF bundle on its own (possibly indirectly by introducing > another helper bundle as you suggested) is an interesting idea but the > question is what to do next - that is how to configure such services for > ex. > > What do you think ? Do you have some scenarios in mind that may not be > easy to do with DOSGi ? > > Thanks, Sergey > > > -Original Message- > From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of > Josh Holtzman > Sent: 12 June 2009 15:00 > To: dev@cxf.apache.org > Subject: Whiteboard pattern for JAX-RS services > > I've got some code that allows OSGI bundles to use the whiteboard > pattern to > register restful services. When a service is registered with a specific > property, say, "jaxrs.resource=true" the JAX-RS implementation registers > that service as a JAX-RS resource. The same could be done with message > body > readers and writers, too. In my implementation, the JAX-RS servlet is > registered under the "/rest/*" URL, and all of the JAX-RS resources fall > below that, so /rest/foo can be provided by one bundle and /rest/bar > could > be provided by another. > > Is this something the CXF folks would be interested in adding? If so, > does > it belong in the cxf-minimal bundle, or as its own add-on bundle? If > people > are familiar with pax-web and pax-web-extender-whiteboard, they'll > recognize > that this kind of thing can be broken out into its own bundle. In the > pax-web case, though, they decided to merge the whiteboard functionality > into their main bundle. > > Full disclosure: I've been using another JAX-RS impl to do this, but > with > the CXF impl passing the 1.0 TCK, I figured that it's time to > re-evaluate :) > > Thanks, > Josh >
RE: Whiteboard pattern for JAX-RS services
Hi Josh It seems that in DOSGi RI this is actually what is being done. When a service is being registered a DSW provider picks up this event and creates an endpoint. So it should work in the case of JAX-RS & JAX-WS with the help of properties you introduced in your patch. David told me that if a property osgi.remote.interfaces is set to '*' then it should let DSW to handle unbounded number of interfaces. I like the idea of message providers being picked up from the whiteboard, it is certainly bound to work better in OSGI than say scanning the classpath. I'll consider enhancing the DOSGi DSW accordingly. Enhancing the CXF bundle on its own (possibly indirectly by introducing another helper bundle as you suggested) is an interesting idea but the question is what to do next - that is how to configure such services for ex. What do you think ? Do you have some scenarios in mind that may not be easy to do with DOSGi ? Thanks, Sergey -Original Message- From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of Josh Holtzman Sent: 12 June 2009 15:00 To: dev@cxf.apache.org Subject: Whiteboard pattern for JAX-RS services I've got some code that allows OSGI bundles to use the whiteboard pattern to register restful services. When a service is registered with a specific property, say, "jaxrs.resource=true" the JAX-RS implementation registers that service as a JAX-RS resource. The same could be done with message body readers and writers, too. In my implementation, the JAX-RS servlet is registered under the "/rest/*" URL, and all of the JAX-RS resources fall below that, so /rest/foo can be provided by one bundle and /rest/bar could be provided by another. Is this something the CXF folks would be interested in adding? If so, does it belong in the cxf-minimal bundle, or as its own add-on bundle? If people are familiar with pax-web and pax-web-extender-whiteboard, they'll recognize that this kind of thing can be broken out into its own bundle. In the pax-web case, though, they decided to merge the whiteboard functionality into their main bundle. Full disclosure: I've been using another JAX-RS impl to do this, but with the CXF impl passing the 1.0 TCK, I figured that it's time to re-evaluate :) Thanks, Josh
Re: CXF Roadmap
WS-Trust WS-Management Is interesting us Daniel ;) Richard Daniel Kulp wrote: I've updated the roadmap with stuff *I* know about: http://cwiki.apache.org/confluence/display/CXF/Roadmap Since we JUST moved trunk 2.3 development, it's a bit early. If others have cool stuff to add, please add it to the list. Dan On Fri June 12 2009 9:50:29 am Richard Opalka wrote: Hi CXF Team, what's the current CXF roadmap from WS-* point of view? What specs are you going to work on next and what is the schedule for them? The roadmap as defined here: http://cxf.apache.org/roadmap.html just specifies "Other WS-* stuff" Richard -- Richard Opalka JBoss Software Engineer Mail: ropa...@redhat.com Mobile: +420 731 186 942
Re: CXF Roadmap
I've updated the roadmap with stuff *I* know about: http://cwiki.apache.org/confluence/display/CXF/Roadmap Since we JUST moved trunk 2.3 development, it's a bit early. If others have cool stuff to add, please add it to the list. Dan On Fri June 12 2009 9:50:29 am Richard Opalka wrote: > Hi CXF Team, > >what's the current CXF roadmap from WS-* point of view? > What specs are you going to work on next and what is the schedule for them? > The roadmap as defined here: > > http://cxf.apache.org/roadmap.html > > just specifies "Other WS-* stuff" > > Richard -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: CXF Roadmap
Hi Eoghan, I'm interested mainly in WS-Trust and WS-Management now ;) Richard Eoghan Glynn wrote: One thing I've had at the back of my mind is WS-RM 1.1 support. Is that something that would be of interest to you? Cheers, Eoghan 2009/6/12 Richard Opalka : Hi CXF Team, what's the current CXF roadmap from WS-* point of view? What specs are you going to work on next and what is the schedule for them? The roadmap as defined here: http://cxf.apache.org/roadmap.html just specifies "Other WS-* stuff" Richard -- Richard Opalka JBoss Software Engineer Mail: ropa...@redhat.com Mobile: +420 731 186 942 -- Richard Opalka JBoss Software Engineer Mail: ropa...@redhat.com Mobile: +420 731 186 942
Whiteboard pattern for JAX-RS services
I've got some code that allows OSGI bundles to use the whiteboard pattern to register restful services. When a service is registered with a specific property, say, "jaxrs.resource=true" the JAX-RS implementation registers that service as a JAX-RS resource. The same could be done with message body readers and writers, too. In my implementation, the JAX-RS servlet is registered under the "/rest/*" URL, and all of the JAX-RS resources fall below that, so /rest/foo can be provided by one bundle and /rest/bar could be provided by another. Is this something the CXF folks would be interested in adding? If so, does it belong in the cxf-minimal bundle, or as its own add-on bundle? If people are familiar with pax-web and pax-web-extender-whiteboard, they'll recognize that this kind of thing can be broken out into its own bundle. In the pax-web case, though, they decided to merge the whiteboard functionality into their main bundle. Full disclosure: I've been using another JAX-RS impl to do this, but with the CXF impl passing the 1.0 TCK, I figured that it's time to re-evaluate :) Thanks, Josh
Re: CXF Roadmap
One thing I've had at the back of my mind is WS-RM 1.1 support. Is that something that would be of interest to you? Cheers, Eoghan 2009/6/12 Richard Opalka : > Hi CXF Team, > > what's the current CXF roadmap from WS-* point of view? > What specs are you going to work on next and what is the schedule for them? > The roadmap as defined here: > > http://cxf.apache.org/roadmap.html > > just specifies "Other WS-* stuff" > > Richard > > -- > Richard Opalka > JBoss Software Engineer > > Mail: ropa...@redhat.com > Mobile: +420 731 186 942 > >
CXF Roadmap
Hi CXF Team, what's the current CXF roadmap from WS-* point of view? What specs are you going to work on next and what is the schedule for them? The roadmap as defined here: http://cxf.apache.org/roadmap.html just specifies "Other WS-* stuff" Richard -- Richard Opalka JBoss Software Engineer Mail: ropa...@redhat.com Mobile: +420 731 186 942
RE: Integrating JAX-RS runtime into DOSGi
Fantastic, thanks a million. I might not be able to apply it today as I'd like to finish some initial WADL work but I will start working with it on Monday Cheers, Sergey -Original Message- From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of Josh Holtzman Sent: 12 June 2009 14:20 To: dev@cxf.apache.org Subject: Re: Integrating JAX-RS runtime into DOSGi I've attached the jaxws/jaxrs/databinding patch to https://issues.apache.org/jira/browse/CXF-2252 Thanks, Josh On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin wrote: > Hi, > > I agree, putting the jaxrs-specific resources into OSGI-INF/cxf/jaxrs > makes sense. > I'll wait for Josh to submit his patch and then I'll add a simple demo > and also tests if needed. Josh has already kindly shown all the code in > his code review page, but I'd rather him collecting another major patch > point than me just copying his code. > > Cheers, Sergey > > -Original Message- > From: Eoghan Glynn [mailto:eogl...@gmail.com] > Sent: 12 June 2009 09:58 > To: dev@cxf.apache.org > Subject: Re: Integrating JAX-RS runtime into DOSGi > > 2009/6/12 David Bosschaert : > > > > 2009/6/11 Sergey Beryozkin : > > ... > >> The only question I have is where this model info should reside, in > >> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan > > > > We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents > > files, so maybe somewhere in the OSGI-INF/cxf area? > > > > Yeah, makes sense to gather all the CXF-specific elements under > OSGI-INF/cxf. > > Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch. > > Cheers, > Eoghan >
Re: Integrating JAX-RS runtime into DOSGi
I've attached the jaxws/jaxrs/databinding patch to https://issues.apache.org/jira/browse/CXF-2252 Thanks, Josh On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin wrote: > Hi, > > I agree, putting the jaxrs-specific resources into OSGI-INF/cxf/jaxrs > makes sense. > I'll wait for Josh to submit his patch and then I'll add a simple demo > and also tests if needed. Josh has already kindly shown all the code in > his code review page, but I'd rather him collecting another major patch > point than me just copying his code. > > Cheers, Sergey > > -Original Message- > From: Eoghan Glynn [mailto:eogl...@gmail.com] > Sent: 12 June 2009 09:58 > To: dev@cxf.apache.org > Subject: Re: Integrating JAX-RS runtime into DOSGi > > 2009/6/12 David Bosschaert : > > > > 2009/6/11 Sergey Beryozkin : > > ... > >> The only question I have is where this model info should reside, in > >> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan > > > > We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents > > files, so maybe somewhere in the OSGI-INF/cxf area? > > > > Yeah, makes sense to gather all the CXF-specific elements under > OSGI-INF/cxf. > > Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch. > > Cheers, > Eoghan >
RE: Integrating JAX-RS runtime into DOSGi
Hi, I agree, putting the jaxrs-specific resources into OSGI-INF/cxf/jaxrs makes sense. I'll wait for Josh to submit his patch and then I'll add a simple demo and also tests if needed. Josh has already kindly shown all the code in his code review page, but I'd rather him collecting another major patch point than me just copying his code. Cheers, Sergey -Original Message- From: Eoghan Glynn [mailto:eogl...@gmail.com] Sent: 12 June 2009 09:58 To: dev@cxf.apache.org Subject: Re: Integrating JAX-RS runtime into DOSGi 2009/6/12 David Bosschaert : > > 2009/6/11 Sergey Beryozkin : > ... >> The only question I have is where this model info should reside, in >> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan > > We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents > files, so maybe somewhere in the OSGI-INF/cxf area? > Yeah, makes sense to gather all the CXF-specific elements under OSGI-INF/cxf. Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch. Cheers, Eoghan
Re: Integrating JAX-RS runtime into DOSGi
2009/6/12 David Bosschaert : > > 2009/6/11 Sergey Beryozkin : > ... >> The only question I have is where this model info should reside, in >> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan > > We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents > files, so maybe somewhere in the OSGI-INF/cxf area? > Yeah, makes sense to gather all the CXF-specific elements under OSGI-INF/cxf. Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch. Cheers, Eoghan
Re: Integrating JAX-RS runtime into DOSGi
Hi Sergey, 2009/6/11 Sergey Beryozkin : ... > The only question I have is where this model info should reside, in > META-INF/cxf-dosgi ? I'll check with Favid/Eoghan ... > thanks, Sergey We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific intents files, so maybe somewhere in the OSGI-INF/cxf area? Cheers, David
