cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r810091 - in /websites/production/cxf/content: cache/docs.pageCache docs/26-migration-guide.html
Date Mon, 26 Mar 2012 18:48:02 GMT
Author: buildbot
Date: Mon Mar 26 18:48:02 2012
New Revision: 810091

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/26-migration-guide.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/26-migration-guide.html
==============================================================================
--- websites/production/cxf/content/docs/26-migration-guide.html (original)
+++ websites/production/cxf/content/docs/26-migration-guide.html Mon Mar 26 18:48:02 2012
@@ -123,7 +123,7 @@ Apache CXF -- 2.6 Migration Guide
            <div class="wiki-content">
 <div id="ConfluenceContent"><h3><a shape="rect" name="2.6MigrationGuide-NewFeatures"></a>New
Features</h3>
 
-<ul><li>The big OSGi bundle used in the Karaf features.xml has been replaced
with the individual modules which are now all individual bundles.   The big OSGi bundle is
still built, but some features may not be available if that is used instead of the little
bundles.</li><li>New ability to configure HTTP Conduits from the OSGi config:admin
service</li><li>New ability to configure the CXF created HTTP Jetty ports from
config:admin service</li><li>OAuth 2 support</li></ul>
+<ul><li>The big OSGi bundle used in the Karaf features.xml has been replaced
with the individual modules which are now all individual bundles.   The big OSGi bundle is
still built, but some features may not be available if that is used instead of the little
bundles.</li><li>New ability to configure HTTP Conduits from the OSGi config:admin
service</li><li>New ability to configure the CXF created HTTP Jetty ports from
config:admin service</li><li>OAuth 2 support</li><li>STS updates to
support Renew and Cancel as well as updates to support more pluggable token validations.</li></ul>
 
 
 <h3><a shape="rect" name="2.6MigrationGuide-RemovedModules"></a>Removed
Modules</h3>
@@ -135,13 +135,12 @@ Apache CXF -- 2.6 Migration Guide
 <ul><li>All API's that take or return "generic" classes have been update to properly
define the generic part.  For example, methods like:<br clear="none">
 "Class getServiceClass()" have been updated to be "Class&lt;?&gt; getServiceClass()"</li><li>To
resolve some of the "split-package" issues between jars, SOME (very few) classes did have
their packages changed.
 	<ul><li>org.apache.cxf.jaxb.JAXBUtils   -&gt;   org.apache.cxf.common.jaxb.JAXBUtils
  (and a couple other classes in that jaxb package)</li><li>Many of the internal
"Impl" classes and "Managers" (like BindingFactoryManagerImpl, CXFBusLifeCycleManager, etc...)
have moved into org.apache.cxf.bus.managers.  Users should always rely on the interfaces they
implement anyway.</li></ul>
-	</li></ul>
-
+	</li><li>The selectedConduit field of AbstractConduitSelector has been removed
as a ConduitSelector may be used to select multiple conduits depending on scenarios and the
selectedConduit field may not accurately reflect the conduit that had been selected depending
on the state of the threads, clients, etc...</li></ul>
 
 
 
 <h3><a shape="rect" name="2.6MigrationGuide-DependencyChanges"></a>Dependency
Changes</h3>
-<ul><li>The org.apache.cxf.tools.* classes that were in cxf-api have been moved
into cxf-tools-common or cxf-tools-validator.</li><li>The org.apache.cxf.ws.policy
classes that were in cxf-api have been moved into cxf-rt-ws-policy.</li><li>cxf-common-utilities
is no longer available.  All the classes in there were moved into cxf-api to represent a complete
"api".</li><li>Various classes in cxf-rt-core and cxf-rt-ws-addr have been moved
up to cxf-api to resolve split-package issues.   Dependencies on cxf-rt-core would have transitively
brought in cxf-api anyway, so there should be little impact.</li><li>Spring is
now an optional component of the http-jetty transports module.</li></ul>
+<ul><li>The org.apache.cxf.tools.* classes that were in cxf-api have been moved
into cxf-tools-common or cxf-tools-validator.</li><li>The org.apache.cxf.ws.policy
classes that were in cxf-api have been moved into cxf-rt-ws-policy.</li><li>cxf-common-utilities
is no longer available.  All the classes in there were moved into cxf-api to represent a complete
"api".</li><li>Various classes in cxf-rt-core and cxf-rt-ws-addr have been moved
up to cxf-api to resolve split-package issues.   Dependencies on cxf-rt-core would have transitively
brought in cxf-api anyway, so there should be little impact.</li><li>Spring is
now an optional component of the http-jetty transports module and other modules.  Applications
that may have pulled in Spring transitively via CXF will be required to declare required spring
dependencies in their own poms directly.</li></ul>
 
 
 



Mime
View raw message