Re: Loading HTTP OSGI transport only when needed
Hi, Looks like we have no objections so I'm about to go ahead with removing this transport from cxf-jaxrs and cxf-minimal distributions only. Users who may be using cxf-jaxrs or cxf-minimal on Equinox/Felix/etc without ServiceMix or DOSGI RI and who would like to use this transport can just add a dependency to the cxf-rt-transports-http-osgi and use Maven/etc to wrap it into a bundle if really needed (the step which quite likely won't be required starting from CXF 3.0, when all cxf modules may become bundles), it is very easy to do and we can help if needed. The all-inclusive cxf bundle will continue shipping it. We will also look into refactoring it so that it becomes more dynamic (similarly to the way DOSGI RI creates contexts) and manageable so that users can choose to disable it if needed. When we get there, we can consider putting it back into cxf-jaxrs/cxf-minimal provided there will be some demand and perhaps even refactoring DOSGI RI to depend on it (again, assuming it will be capable of creating endpoint the way DOSGI RI can). thanks, Sergey - Original Message - From: "David Bosschaert" To: ; Sent: Tuesday, January 19, 2010 11:14 AM Subject: Re: Loading HTTP OSGI transport only when needed Hi Sergey, In CXF-DOSGi we have the option to use a similar mechanism, whereby we're registering CXFNonSpringServlets with pax web (through the OSGi HTTP Service) to make them available. The way it's done is one servlet per service which means that they don't have to share a context, but they do share the port as they're all served by a single OSGi HTTP Service underneath. We don't use the http-osgi component from CXF for this AFAIK, so I have no objection to your proposal. Best regards, David 2010/1/18 Sergey Beryozkin : Hi I'm thinking of removing the http-osgi dependency from cxf-minimal and cxf-jaxrs bundles only. Here're the reasons why : 1. The issue has been reported against a CXF JAX-RS bundle 2. CXF Minimal is used by DOSGi RI which uses its own (more dynamic) approach toward allocating contexts (I'd like to update the cxf osgi transport somehow to be more dynamic too, that is, for individual CXF endpoints be able to allocate individual contexts, as opposed to all of them having to share some root context) 3. CXF Minimal and CXF JAXRS are 'minimal' by definition, so it kind of makes sense at this stage to limit the distribution of the osgi transport to the all-inclusive bundle only. 4. Going forward (from CXF 3.0 ?), I reckon it would make sense to remove the osgi transport from the distribution all together. Instead ServiceMix CXF feature may get updated to depend on CXFBundle + CXF OSGI transport, other OSGI environments which may need it will depend on cxf bundle and on the osgi transport (bundle). Or may be we can have a CXF-All-OSGI which will include all the 'active' OSGI-related components, those causing some immediate side-effects when loaded into OSGI... The only problem I see here is that CXF 2.2.5 users have started using CXF JAX-RS or CXF Minimal in OSGI environments we're not aware of and started using the osgi transport. A bit unlikely but it will be worth checking with the users list. Has anyone tried to do it already ? Please let us know... Users can modify the CXF bundles locally and remove this transport but I'd rather the transport be lazily loaded or when really needed. I have a feeling this issue might hiner a bit the migration to later CXF versions for users which can not afford, say, easily migrating to the next Spring DM server, etc... Thoughts ? Sergey Hi Some users have reported that the CXF HTTP OSGI transport is causing issues in OSGI containers depending on the Spring DM 1.0.2 or earlier, due to Spring DM eagerly loading the CXF HTTP OSGI context but failing to deal with the (spring-)osgi-compendium related elements. The only solution which seems to work in this case is to remove a cxf osgi transport bits altogether from a bundle given that the user reporting the issue is not using this transport. This works but it is not ideal. I'm also thinking that may be DOSGI might be affected a bit too given that DOSGI users do not use this transport as well but will have a /cxf context busy already, not that they need '/cxf' but anyway... I'm just wondering, what options we might have here ? Perhaps one option is not to bundle this transport for cxf-minimal and cxf-jaxrs bundles ? Users who do need it, say ServiceMix users, can get it from the full bundle. Another option is to add a CXF OSGI HTTP transport BundleActivator and repackage META-INF/spring/cxf-osgi-transport.xml into say META-INF/cxf//spring/cxf-osgi-transport.xml. Our BundleActivator will somehow delegate to META-INF/cxf//spring/cxf-osgi-transport.xml, I don't know how yet, but I think, as far as I recall from writ
Re: Loading HTTP OSGI transport only when needed
Hi Sergey, In CXF-DOSGi we have the option to use a similar mechanism, whereby we're registering CXFNonSpringServlets with pax web (through the OSGi HTTP Service) to make them available. The way it's done is one servlet per service which means that they don't have to share a context, but they do share the port as they're all served by a single OSGi HTTP Service underneath. We don't use the http-osgi component from CXF for this AFAIK, so I have no objection to your proposal. Best regards, David 2010/1/18 Sergey Beryozkin : > Hi > > > > I'm thinking of removing the http-osgi dependency from cxf-minimal and > cxf-jaxrs bundles only. > > Here're the reasons why : > > 1. The issue has been reported against a CXF JAX-RS bundle > > 2. CXF Minimal is used by DOSGi RI which uses its own (more dynamic) > approach toward allocating contexts (I'd like to update the cxf osgi > transport somehow to be more dynamic too, that is, for individual CXF > endpoints be able to allocate individual contexts, as opposed to all of > them having to share some root context) > > 3. CXF Minimal and CXF JAXRS are 'minimal' by definition, so it kind of > makes sense at this stage to limit the distribution of the osgi > transport to the all-inclusive bundle only. > > 4. Going forward (from CXF 3.0 ?), I reckon it would make sense to > remove the osgi transport from the distribution all together. Instead > ServiceMix CXF feature may get updated to depend on CXFBundle + CXF OSGI > transport, other OSGI environments which may need it will depend on cxf > bundle and on the osgi transport (bundle). Or may be we can have a > CXF-All-OSGI which will include all the 'active' OSGI-related > components, those causing some immediate side-effects when loaded into > OSGI... > > > > The only problem I see here is that CXF 2.2.5 users have started using > CXF JAX-RS or CXF Minimal in OSGI environments we're not aware of and > started using the osgi transport. A bit unlikely but it will be worth > checking with the users list. Has anyone tried to do it already ? Please > let us know... > > > > Users can modify the CXF bundles locally and remove this transport but > I'd rather the transport be lazily loaded or when really needed. I have > a feeling this issue might hiner a bit the migration to later CXF > versions for users which can not afford, say, easily migrating to the > next Spring DM server, etc... > > > > > > > > Thoughts ? > > > > > Sergey > > > > > > > > Hi > > > > Some users have reported that the CXF HTTP OSGI transport is causing > issues in OSGI containers depending on the Spring DM 1.0.2 or earlier, > due to Spring DM eagerly loading the CXF HTTP OSGI context but failing > to deal with the (spring-)osgi-compendium related elements. > > > > The only solution which seems to work in this case is to remove a cxf > osgi transport bits altogether from a bundle given that the user > reporting the issue is not using this transport. > > > > This works but it is not ideal. > > I'm also thinking that may be DOSGI might be affected a bit too given > that DOSGI users do not use this transport as well but will have a /cxf > context busy already, not that they need '/cxf' but anyway... > > > > I'm just wondering, what options we might have here ? > > Perhaps one option is not to bundle this transport for cxf-minimal and > cxf-jaxrs bundles ? Users who do need it, say ServiceMix users, can get > it from the full bundle. > > > > Another option is to add a CXF OSGI HTTP transport BundleActivator and > repackage META-INF/spring/cxf-osgi-transport.xml into say > META-INF/cxf//spring/cxf-osgi-transport.xml. Our BundleActivator will > somehow delegate to META-INF/cxf//spring/cxf-osgi-transport.xml, I don't > know how yet, but I think, as far as I recall from writing SpringDM > tests, it might be possible to point SpringDM to some custom location. > However, before delegating, the BundleActivator will check, say a system > property which if set would disable the osgi transport. Something along > these lines. > > > > Thoughts ? > > > > cheers, Sergey > > > > P.S. I might not be able to contribute to this thread until this coming > Thursday... > > > >
Re: Loading HTTP OSGI transport only when needed
Hi I'm thinking of removing the http-osgi dependency from cxf-minimal and cxf-jaxrs bundles only. Here're the reasons why : 1. The issue has been reported against a CXF JAX-RS bundle 2. CXF Minimal is used by DOSGi RI which uses its own (more dynamic) approach toward allocating contexts (I'd like to update the cxf osgi transport somehow to be more dynamic too, that is, for individual CXF endpoints be able to allocate individual contexts, as opposed to all of them having to share some root context) 3. CXF Minimal and CXF JAXRS are 'minimal' by definition, so it kind of makes sense at this stage to limit the distribution of the osgi transport to the all-inclusive bundle only. 4. Going forward (from CXF 3.0 ?), I reckon it would make sense to remove the osgi transport from the distribution all together. Instead ServiceMix CXF feature may get updated to depend on CXFBundle + CXF OSGI transport, other OSGI environments which may need it will depend on cxf bundle and on the osgi transport (bundle). Or may be we can have a CXF-All-OSGI which will include all the 'active' OSGI-related components, those causing some immediate side-effects when loaded into OSGI... The only problem I see here is that CXF 2.2.5 users have started using CXF JAX-RS or CXF Minimal in OSGI environments we're not aware of and started using the osgi transport. A bit unlikely but it will be worth checking with the users list. Has anyone tried to do it already ? Please let us know... Users can modify the CXF bundles locally and remove this transport but I'd rather the transport be lazily loaded or when really needed. I have a feeling this issue might hiner a bit the migration to later CXF versions for users which can not afford, say, easily migrating to the next Spring DM server, etc... Thoughts ? Sergey Hi Some users have reported that the CXF HTTP OSGI transport is causing issues in OSGI containers depending on the Spring DM 1.0.2 or earlier, due to Spring DM eagerly loading the CXF HTTP OSGI context but failing to deal with the (spring-)osgi-compendium related elements. The only solution which seems to work in this case is to remove a cxf osgi transport bits altogether from a bundle given that the user reporting the issue is not using this transport. This works but it is not ideal. I'm also thinking that may be DOSGI might be affected a bit too given that DOSGI users do not use this transport as well but will have a /cxf context busy already, not that they need '/cxf' but anyway... I'm just wondering, what options we might have here ? Perhaps one option is not to bundle this transport for cxf-minimal and cxf-jaxrs bundles ? Users who do need it, say ServiceMix users, can get it from the full bundle. Another option is to add a CXF OSGI HTTP transport BundleActivator and repackage META-INF/spring/cxf-osgi-transport.xml into say META-INF/cxf//spring/cxf-osgi-transport.xml. Our BundleActivator will somehow delegate to META-INF/cxf//spring/cxf-osgi-transport.xml, I don't know how yet, but I think, as far as I recall from writing SpringDM tests, it might be possible to point SpringDM to some custom location. However, before delegating, the BundleActivator will check, say a system property which if set would disable the osgi transport. Something along these lines. Thoughts ? cheers, Sergey P.S. I might not be able to contribute to this thread until this coming Thursday...
Loading HTTP OSGI transport only when needed
Hi Some users have reported that the CXF HTTP OSGI transport is causing issues in OSGI containers depending on the Spring DM 1.0.2 or earlier, due to Spring DM eagerly loading the CXF HTTP OSGI context but failing to deal with the (spring-)osgi-compendium related elements. The only solution which seems to work in this case is to remove a cxf osgi transport bits altogether from a bundle given that the user reporting the issue is not using this transport. This works but it is not ideal. I'm also thinking that may be DOSGI might be affected a bit too given that DOSGI users do not use this transport as well but will have a /cxf context busy already, not that they need '/cxf' but anyway... I'm just wondering, what options we might have here ? Perhaps one option is not to bundle this transport for cxf-minimal and cxf-jaxrs bundles ? Users who do need it, say ServiceMix users, can get it from the full bundle. Another option is to add a CXF OSGI HTTP transport BundleActivator and repackage META-INF/spring/cxf-osgi-transport.xml into say META-INF/cxf//spring/cxf-osgi-transport.xml. Our BundleActivator will somehow delegate to META-INF/cxf//spring/cxf-osgi-transport.xml, I don't know how yet, but I think, as far as I recall from writing SpringDM tests, it might be possible to point SpringDM to some custom location. However, before delegating, the BundleActivator will check, say a system property which if set would disable the osgi transport. Something along these lines. Thoughts ? cheers, Sergey P.S. I might not be able to contribute to this thread until this coming Thursday...
