[CONF] Apache CXF Documentation > Standardized Authentication / Authorization
Christian Schneider edited the page: Standardized Authentication / Authorization Info Ideas / Proposal CXF already supports a wide range of authentication and authorization approaches. Unfortunately they are all configured differently and do not integrate well with each other. ... An XACML policy enforcement point can retrieve the JAAS login data and do authorization against an XACML Policy Decision Point (PDP). Separating Authorization from CXF As authorization is not only relevant for webservices it makes sense to keep the authorization code separate from cxf too. So one way to implement authorization would be to put it into a blueprint extension. Of course this would cover only OSGi and blueprint but it would be a start. It could work similar to the XA transaction support. Unlike in tx support we could scan all beans for security annotations like @RolesAllowed. Then for each bean that has this annotation we could proxy it with a class that does the security check. This would allow to have minimal xml configuration. Another approach is to mark beans for security checks using xml like in tx support. This variant then would also work nicely for XACML authorization as in that case there would be no annotation to scan for. Karaf role based OSGi service Authorization Karaf 3 already supports authorization on the OSGi service level and uses JAAS for authentication. So if we do a JAAS login in CXF and the service impl code calls an OSGi service then the Karaf role based securtiy should already work out of the box.We could add annotation based Authorization to karaf code to make it even better and require less config. Exception handling and answer generation ... Failure at Authentication: javax.security.auth.login.LoginException could also be more specific like AccountLockedException Failure at Authorization: org.apache.cxf.interceptor.security.AccessDeniedException or java.security.AccessControlException. The later one is better for code separate from cxf as it does not depend on CXF. Then in the transport like the http transport we map the exception to the defined status code and http response:
[CONF] Apache CXF Documentation > Standardized Authentication / Authorization
Christian Schneider bearbeitete die Seite: Standardized Authentication / Authorization ... We could simply detect what information is provided and configure the Callbackhandlers for each variant.information we can supply. Depending on when the login should happen we could collect CallbackHandlers in the Message using Interceptors. JAAS configuration The JAAS configuration is supplied differently depending on the runtime CXF runs in. ... different Classes like a UserPrincipal or RolePrincipal. Unfortunately there are no standard interfacesThere seems to be a Group interface which allows to differentiate between Users and Groups and also allows to see group members. prefixes. So for example roles start with role- . Again there There is no standard for this approach Authorization Authorization has very diverse requirements. So we need to make sure we integrate well with different approaches. ... Karaf 3 already supports authorization on the OSGi service level and uses JAAS for authentication. So if we do a JAAS login in CXF and the service impl code calls an OSGi service then the Karaf role based securtiy should already work out of the box. Exception handling and answer generation Currently the authentication and athorization modules often also generate the answer to the caller. It might be a good idea to decouple this. In the authentication and authorization we only throw a defined Exception: Failure at Authentication: javax.security.auth.login.LoginException could also be more specific like AccountLockedException Failure at Authorization: org.apache.cxf.interceptor.security.AccessDeniedException or java.security.AccessControlException Then in the transport like the http transport we map the exception to the defined status code and http response: LoginException: HTTP Code 401 AccessDeniedException, AccessControlException: HTTP Code 403 Karaf integration Ideally we should integrate the new authentication / authorization model in a way that enable the user to switch on authentication for the karaf server without specific configurations in the user bundles that implement the services. ... Doing a full JAAS login requires to use subject.doAs to populate the AcessControlContext. This is not possible in a CXF interceptor as the interceptor only works on a message but can not call the next interceptor for doAs. So the question is where to do the JAAS login and the doAs
[CONF] Apache CXF Documentation > Standardized Authentication / Authorization
Christian Schneider hat eine Seite erstellt: Standardized Authentication / Authorization Icon Ideas / Proposal CXF already supports a wide range of authentication and authorization approaches. Unfortunately they are all configured differently and do not integrate well with each other. So the idea is to create one standardized authentication / authorization flow in CXF where the modules can then fit in. There are a lot of security frameworks out there that could be used as a basis for this. The problem is though that each framework (like Shiro or Spring Security) uses its own mechanisms which are not standardized. So by choosing one framework we would force our users to depend on this. The best standardized security framework in java is JAAS. It is already included in Java and most security frameworks can be hooked into it. So let´s investigate what we could do with JAAS. Authentication using JAAS JAAS authentication is done by creating a LoginContext and doing a login on it. Things to configure is the name of the login config and the Callback Handlers. So CXF needs mechanisms for the user to set the config name and needs to provide CallBackHandlers to supply credentials. CallbackHandlers CXF needs to supply different data to identify the users depending on the chosen authentication variant. Basic Auth: username and password from HTTP header WS-Security UserNameToken: Username and password from SOAP header Spnego: Kerberos token from HTTP header HTTPS client cert: Certificate information We could simply detect what information is provided and configure the Callbackhandlers for each variant. JAAS configuration The JAAS configuration is supplied differently depending on the runtime CXF runs in. Standalone: For standalone usage the JAAS config can simply come from a file. Servlet Container: Not sure. Is there a standard approach for this? Apache Karaf: Karaf already provides a JAAS integration so we just have to configure the JAAS config name and supply a suitable config in karaf Supplying Role and User information JAAS stores identity information in the JAAS subject. The method getPrincipals returns Principal objects which can be users, roles or even other identity information. To differentiate between roles and users there are two common approaches. different Classes like a UserPrincipal or RolePrincipal. Unfortunately there are no standard interfaces prefixes. So for example roles start with role- . Again there is no standard Authorization
[CONF] Apache CXF Documentation > JMS transactions
Christian Schneider edited the page: JMS transactions ... Code Block title Define transaction manager language xml .GeronimoTransactionManager"/> as an OSGi service reference. (This search filter can vary between application servers). ... View Online · Like · View Changes Stop watching space · Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache CXF Documentation > JMS transactions
Christian Schneider created a page: JMS transactions CXF supports resource local jms transactions and JTA transactions on CXF endpoints when using one way messages. Resource local JMS transactions This kind of transaction is easy to configure but will only roll back the JMS message. It will not directly coordinate other resources like a database transaction. Simply configure the endpoint normally and set the propety "sessionTransacted" to true. CXF will then roll back the message on if any exception happens. JTA transactions JTA transactions allow to coordinate any number of XA resources. If a CXF endpoint is configured for JTA transactions it will start a JTA transaction before calling the service impl. If no exceptions happen the transaction will be committed in case of any exception the transaction will be rolled back. This allows to e.g. transactionally consume a JMS message and write the data into a database. In case of an exception both resources will be rolled back. So either the message is consumed AND the database record is written or the message is rolled back AND the database record is not written. The first config needed for JTA is a transaction manager: Either create a transaction manager in a bean using: Define transaction manager as an OSGi service reference. (This search filter can vary between application servers). Lookup transaction manager as OSGi service using blueprint Then the name of the TransactionManager can be set in the JMS URI JMS URI with transaction manager jms:queue:myqueue?jndiTransactionManager=TransactionManager jms:jndi:myqueue?jndiTransactionManager=java:comp/env/TransactionManager The first would find a bean with id "TransactionManager" the second would look up the transaction manager in JNDI. The second config is a JCA pooling connection factory JCA pooling connection factory defined using spring
[CONF] Apache CXF Documentation > JMS Transport
Christian Schneider edited the page: JMS Transport ... Performance and pooling JMS reconnect transactions Reconnect functionality ... The JMS transport automatically reconnects when any JMS exceptions happen. The first exception will be logged with "Exception on JMS connection. Trying to reconnect" and the exception details. Then CXF will try to reconnect every 5 seconds and log "Exception on reconnect. Trying again, attempt num x". In conduits every exception when sending a message will be thrown to the caller. The conduit then closes the connection and will start a new one when sending the next message. Warning title Reconnects and pooling When using pooling make sure the pool throws away the Connection in case of errors. In ActiveMQ PooledConnection this can be achieved using setExpiryTimeout(milliseconds). In CXF 2.x the JMS server must be present before JMS endpoints are started. In cxf 3 the endpoint will start and periodically reconnect like in the case of an exception while running. View Online · Like · View Changes Stop watching space · Manage Notifications This
[CONF] Apache CXF Documentation > JMS performance and pooling
Christian Schneider created a page:
JMS performance and pooling
CXF JMS should be very fast if configured correctly. There are two major settings that affect performance: pooling and synchronous receives on client side.
Pooling
On the client side CXF creates a new JMS Session and Producer for each message. This is necessary as these JMS objects are not thread safe. Especially creating a Producer is very time intensive though as a communication with the server is necessary.
Connection Factory pools help to improve perfomance by caching the Connection, Session and Producer.
For ActiveMQ configuring pooling is quite simple:
Pooling for ActiveMQ
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.pool.PooledConnectionFactory;
ConnectionFactory cf = new ActiveMQConnectionFactory("tcp://localhost:61616");
PooledConnectionFactory pcf = new PooledConnectionFactory();
pcf.setExpiryTimeout(5000); // Make sure to set expiry timeout as the default of 0 prevents reconnect on failures
pcf.setConnectionFactory(cf);
JMSConfiguration jmsConfig = new JMSConfiguration();
jmsConfig.setConnectionFactory(pcf);
Synchronous Receives on client side
For request / reply exchanges the JMS transport sends a request and waits for a reply. Whenever possible this is done using a JMS MessageListener. In some cases though CXF has to use a synchronous Consumer.receive() instead. The problem here is that CXF needs to be able to share queues between endpoints. So a MessageListener needs to use a MessageSelector to filter the messages. This selector needs to be known in advance so the listener can be opened once.
There are two cases where this is not possible:
MessageIdAsCorrelationId: If useConduitIdSelector is false and no static conduitIdSelectorPrefix is given then the client does not set a correlation id. The server then uses the message id of the request message as correlation id. As this id can not be known in advance the client has to use a synchronous Consumer.receive. This pattern is also necessary for communication with IBM JMS endpoints as they use this by default
The user can set the JMSMessageHeadersType in the request message and there do a SetJMSCorrelationID("customid"). In this case CXF also has to use a synchronous Consumer.receive()
So the general rule here is to avoid these settings that lead to the synchronous receives.
Expected perfomance
On a fast system (Intel Core i7) and with small messages CXF can achieve a performance of about 12,000 messages per second for one way and 3,500 transactions / second for request reply (both non persistent). If you measure much lower speeds then you might have an issue with your JMS configuration.
[CONF] Apache CXF Documentation > JMS Transport
Christian Schneider edited the page: JMS Transport ... SOAP / JMS spec compliant configuration - recommended style for CXF 3 JMSConfiguration style - works in CXF 2 and 3 but is deprecated for CXF 3 CXF 2.x JMS configuration - removed in CXF 3 Advanced examples (CXF >= 3) Performance and pooling JMS reconnect functionality JMS transactions View Online · Like · View Changes Stop watching space · Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache CXF Documentation > SOAP over JMS 1.0 support
Christian Schneider edited the page:
SOAP over JMS 1.0 support
...
Code Block
java
// You just need to set the address with JMS URI
String address = "jms:jndi:dynamicQueues/test.cxf.jmstransport.queue3"
+ "?jndiInitialContextFactory"
+ "=org.apache.activemq.jndi.ActiveMQInitialContextFactory"
+ "&jndiConnectionFactoryName=ConnectionFactory&jndiURL=tcp://localhost:61500";
Hello implementor = new HelloImpl();
JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
svrFactory.setServiceClass(Hello.class);
svrFactory.setAddress(address);
// And specify the transport ID with SOAP over JMS specification
svrFactory.setTransportId(JMSSpecConstants.SOAP_JMS_SPECIFICATION_TRANSPORTID);
svrFactory.setServiceBean(implementor);
svrFactory.create();
// Alternatively using JAXWS Endpoint.create and avoiding JNDI
ConnectionFactory cf = new ActiveMQConnectionFactory("tcp://localhost:61500");
EndpointImpl ep = (EndpointImpl)Endpoint.create(impl);
ep.setBus(bus);
ep.getFeatures().add(new ConnectionFactoryFeature(cf));
ep.publish("jms:queue:test.cxf.jmstransport.queue?timeToLive=1000");
...
Code Block
java
[CONF] Apache CXF Documentation > SOAP over JMS 1.0 support
Christian Schneider edited the page: SOAP over JMS 1.0 support ... Here is an example: Code Block title Define Ways to define a Soap Service with JMS transport language xml ConnectionFactory org.apache.activemq.jndi.ActiveMQInitialContextFactory tcp://localhost:61616 PERSISTENT 5 200 com.example.jndi.InitialContextFactory 100 10 ... ... For this example: Code Block title Greeter Service with JMS transaport language xml
[CONF] Apache CXF Documentation > SOAP over JMS 1.0 support
Christian Schneider edited the page: SOAP over JMS 1.0 support ... Here is an example: Code Block title Define a Soap Service with JMS transport language xml ConnectionFactory org.apache.activemq.jndi.ActiveMQInitialContextFactory tcp://localhost:61616 PERSISTENT 5 200 com.example.jndi.InitialContextFactory 100 10 ... ... View Online · Like · View Changes Stop watching space · Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache CXF Documentation > SOAP over JMS 1.0 support
Christian Schneider edited the page: SOAP over JMS 1.0 support ... Code Block title Endpoint in spring language xml or a Client like this: Code Block title Proxy in spring language xml
[CONF] Apache CXF Documentation > SOAP over JMS 1.0 support
Christian Schneider edited the page: SOAP over JMS 1.0 support ... JMS Extension Namespace Code Block xmlns:soapjms="http://www.w3.org/2010/soapjms/" ... CXF supports three variants, "jndi", "queue", and "topic". For example: Code Block jms:jndi:SomeJndiNameForDestination?jndiInitialContextFactory=com.example.jndi.JndiFactory&priority=3 jms:queue:ExampleQueueName?timeToLive=1000 Properties are as follows: Property From Version DefaultValue Description conduitIdSelectorPrefix 3.0.0 deliveryMode PERSISTENT NON_PERSISTENT messages will kept only in memory PERSISTENT messages will be saved to disk durableSubscriptionName 3.0.0
[CONF] Apache CXF > Index
Christian Schneider edited the page: Index ... Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. News January 01, 2014 - Apache CXF Distributed OSGi (DOSGi) 1.6.0 released! This release mainly updates to cxf 2.7.8 and removes the jdom dependency. Downloads are available at the DOSGi Releases page. February 18, 2014 - Apache CXF 3.0.0-milestone1 released! ... View Online · Like · View Changes Stop watching space · Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache CXF > Index
Christian Schneider edited the page: Index ... Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. News January ... 21, 2014 - Apache CXF Distributed OSGi (DOSGi) 1.6.0 released! This release mainly updates to cxf 2.7.8 and removes the jdom dependency. ... View Online · Like · View Changes Stop watching space · Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache CXF > DOSGi Releases
Christian Schneider edited the page: DOSGi Releases Releases Release 1.6.0 (current version - 2014-01- ... 21) Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.6.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.6.0-dir.zip Source distribution cxf-dosgi-ri-source-distribution-1.6.0.tar.gz ... Multi bundle distro now created from karaf features. So less effort for new releases CXF updated to 2.7.8 jdom dependency removed Bug fixes Release 1.5.0 (2013-06-27) Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.zip Source distribution
[CONF] Apache CXF > DOSGi Releases
Christian Schneider edited the page: DOSGi Releases Releases Release 1. ... 6.0 (current version - 2014-01-18) Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.6.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.6.0-dir.zip Source distribution cxf-dosgi-ri-source-distribution-1.6.0.tar.gz Highlights Multi bundle distro now created from karaf features. So less effort for new releases CXF updated to 2.7.8 jdom dependency removed Bug fixes Release 1.5.0 Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.zip Source distribution
[CONF] Apache CXF > DOSGi Releases
Christian Schneider edited the page: DOSGi Releases ... Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.6.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.6.0-dir.zip Source distribution cxf-dosgi-ri-source-distribution-1.6.0.tar.gz Highlights Multi bundle distro now created from karaf features. So less effort for new releases CXF updated to 2.7.8 jdom dependency removed Bug fixes ... View Online · Like · View Changes Stop watching space · Manage Notifications This message was sent by Atlassian Confluence 5.0.3, Team Collaboration Software
[CONF] Apache CXF > CXF configuration ideas
CXF configuration ideas
Page edited by Christian Schneider
Changes (4)
...
h4.
{code:language=java|title=Feature definition} @Named("MyFeature") public class MyFeature extends AbstractFeature { ... } {code} Endpoint with inlined injections
{code:language=java|title=Endpoint}{code}
{code:language=java|title=Proxy}{code}
@WebService public class MyServiceImpl implements MyService { @Inject MyRessource res1; // Inject arbitrary user ressources@Inject @Named("MyFeature") Feature feature1; // Inject named feature @Inject List features; // Inject all features known to this context ... } {code} We might also support some kind of Endpoint description classes to separate endpoint definition from the actual implementation. Not sure how to wire this with CDI. Any ideas? For the proxy I am not sure which is the best annotation based approach. One idea is to have one or more factories for producers. {code:language=java|title=Annotation based Proxy definitions} public class MyServiceProducer {@Produce MyService createMyService() { return new JAXWSProxyFactory("http://myserver:8080/myService");}@Produce @MyMarker // CDI Qualifiers to distinguish services of the same interface type MyService createMyService() { } } {code} {code:language=java|title=XML based proxy definition} {code} {code:language=java|title=Annotation based JAXRS Endpoint definition} {code}
Full Content
Environment
CXF is intended to work in a wide range of containers / frameworks:
Plain Java
Spring XML and annotation based
Blueprint
JavaEE (CDI)
It for each of the important cases it should be as easy and natural to configure CXF for the developer.
Problem description
Currently CXF provides a lot of integration points with frameworks as well as CXF proprietary ways of configuration.
Out current approach has several drawbacks:
Integration with some frameworks creates problems with other frameworks. For example the aries blueprint namespaces make it impossible to use gemini blueprint
CXF configuration is often quite unnatural for users of the respective frameworks. For example if you define a Feature using the service loader approach you cannot inject resources into it
Using other framework is often difficult as we do not have nice plain java ways to setup e.g. endpoints
CXF defines special annotations. These are processed in a CXF proprietary way that does not allow to mix these with annotations of the user framework of choice
Idea
The general idea is to step back and keep injection out of CXF as much as possible and instead rely more on the frameworks to do this job. This should make CXF much more embedable and less complex. We still can have some glue code for the frameworks but at as few points as possible.
A good example for this is camel which defines a registry concept that is implemented differently for each framework. In spring it relies on the spring context in blueprint on the blueprint context, in OSGi on services. The camel registry is not perfect but a good step in the right direction.
In the following checpters we should look into the respective frameworks and discuss how CXF integration should work ideally.
Spring
XML
Annotation based
Blueprint
CDI
Feature definition
@Named("MyFeature")
public class MyFeature extends AbstractFeature {
...
}
Endpoint with inlined injections
Endpoint
@WebService
public class MyServiceImpl implements MyService {
@Inject MyRessource res1; // Inject arbitrary user ressources
@Inject @Named("MyFeature") Feature feature1; // Inject named feature
@Inject List features; // Inject all features known to this context
...
}
We might also support some kind of Endpoint description classes to separate endpoint definition from the actual implementation. Not sure how to wire this with CDI. Any ideas?
For the proxy I am not sure which is the best annotation based approach. One idea is to have one or more factories for producers.
Annotation based Proxy definitions
public class MyServiceProducer {
@Produce MyService createMyService() {
return new JAXWSProxyFactory("http://myserver:8080/myService");
}
@Produce @MyMarker // CDI Qualifiers to distinguish services of the same interface type
MyService createMyService() {
}
}
XML based proxy definition
Annotation based JAXRS Endpoint definition
Stop watching space
|
Change email notification preferences
View Online
|
View Changes
[CONF] Apache CXF > CXF configuration ideas
CXF configuration ideas
Page edited by Christian Schneider
Changes (2)
...
h4. Endpoint
{code:language=java|title=Endpoint}{code} {code:language=java|title=Proxy}{code}
Full Content
Environment
CXF is intended to work in a wide range of containers / frameworks:
Plain Java
Spring XML and annotation based
Blueprint
JavaEE (CDI)
It for each of the important cases it should be as easy and natural to configure CXF for the developer.
Problem description
Currently CXF provides a lot of integration points with frameworks as well as CXF proprietary ways of configuration.
Out current approach has several drawbacks:
Integration with some frameworks creates problems with other frameworks. For example the aries blueprint namespaces make it impossible to use gemini blueprint
CXF configuration is often quite unnatural for users of the respective frameworks. For example if you define a Feature using the service loader approach you cannot inject resources into it
Using other framework is often difficult as we do not have nice plain java ways to setup e.g. endpoints
CXF defines special annotations. These are processed in a CXF proprietary way that does not allow to mix these with annotations of the user framework of choice
Idea
The general idea is to step back and keep injection out of CXF as much as possible and instead rely more on the frameworks to do this job. This should make CXF much more embedable and less complex. We still can have some glue code for the frameworks but at as few points as possible.
A good example for this is camel which defines a registry concept that is implemented differently for each framework. In spring it relies on the spring context in blueprint on the blueprint context, in OSGi on services. The camel registry is not perfect but a good step in the right direction.
In the following checpters we should look into the respective frameworks and discuss how CXF integration should work ideally.
Spring
XML
Annotation based
Blueprint
CDI
Endpoint
Proxy
Stop watching space
|
Change email notification preferences
View Online
|
View Changes
[CONF] Apache CXF > CXF configuration ideas
CXF configuration ideas Page added by Christian Schneider Environment CXF is intended to work in a wide range of containers / frameworks: Plain Java Spring XML and annotation based Blueprint JavaEE (CDI) It for each of the important cases it should be as easy and natural to configure CXF for the developer. Problem description Currently CXF provides a lot of integration points with frameworks as well as CXF proprietary ways of configuration. Out current approach has several drawbacks: Integration with some frameworks creates problems with other frameworks. For example the aries blueprint namespaces make it impossible to use gemini blueprint CXF configuration is often quite unnatural for users of the respective frameworks. For example if you define a Feature using the service loader approach you cannot inject resources into it Using other framework is often difficult as we do not have nice plain java ways to setup e.g. endpoints CXF defines special annotations. These are processed in a CXF proprietary way that does not allow to mix these with annotations of the user framework of choice Idea The general idea is to step back and keep injection out of CXF as much as possible and instead rely more on the frameworks to do this job. This should make CXF much more embedable and less complex. We still can have some glue code for the frameworks but at as few points as possible. A good example for this is camel which defines a registry concept that is implemented differently for each framework. In spring it relies on the spring context in blueprint on the blueprint context, in OSGi on services. The camel registry is not perfect but a good step in the right direction. In the following checpters we should look into the respective frameworks and discuss how CXF integration should work ideally. Spring XML Annotation based Blueprint CDI Endpoint Stop watching space | Change email notification preferences View Online
[CONF] Apache CXF > Index
Index
Page edited by Christian Schneider
Changes (7)
...
h2. News
*May 15, 2013 - Apache CXF 2.7.5/2.6.8 released!*
*Jul 02, 2013 - Apache CXF Distributed OSGi (DOSGi) 1.5.0 released\!*
This release of DOSGi ccontains a lot of bug fixes. As the most visual change the single bundle distro has been removed as it required a lot of additional effort for testing and release management. Downloads are available at the [CXF:DOSGi Releases] page. *May 15, 2013 - Apache CXF 2.7.5/2.6.8 released\!*
The Apache CXF team is proud to announce the availability of the latest patch releases. Over 40 JIRA issues were fixed for 2.7.5 which many of those fixes back ported to 2.6.8.
...
For REST, CXF also supports a JAX-RS frontend. * *Ease of use:* CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.x XML support to make configuration a snap, and much more.
* *Binary and Legacy Protocol Support:* CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.
To get started using CXF, check out the [downloads|Download], the [user's guide|http://cxf.apache.org/docs/index.html], or the [mailing lists|Mailing Lists] to get more information\!
{section}
...
* SAAJ - SOAP with Attachments API for Java (SAAJ) - [JSR-67|http://jcp.org/aboutJava/communityprocess/mrel/jsr067/index3.html]
h5. WS-\* and related Specifications Support
* Basic support: WS-I Basic Profile 1.1 * Quality of Service: WS-Reliable Messaging
...
Full Content
Apache CXF: An Open-Source Services Framework
Overview
Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.
News
Jul 02, 2013 - Apache CXF Distributed OSGi (DOSGi) 1.5.0 released!
This release of DOSGi ccontains a lot of bug fixes. As the most visual change the single bundle distro has been removed as it required a lot of additional effort for testing and release management.
Downloads are available at the DOSGi Releases page.
May 15, 2013 - Apache CXF 2.7.5/2.6.8 released!
The Apache CXF team is proud to announce the availability of the latest patch releases. Over 40 JIRA issues were fixed for 2.7.5 which many of those fixes back ported to 2.6.8.
This is mostly a patch release to fix problems and issues that users have encountered. There is also a critical security issue resolved in these releases (information forthcoming). Users are STRONGLY encouraged to upgrade as soon as possible.
This release requires the Woodstox 4.2.0 StAX Parser to be available on the classpath.
Downloads are available here.
Features
CXF includes a broad feature set, but it is primarily focused on the following areas:
Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the WS-I Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Security, WS-SecurityPolicy, WS-SecureConverstation, and WS-Trust (partial).
Frontends: CXF supports a variety of "frontend" programming models.
CXF implements the JAX-WS APIs. CXF JAX-WS support includes some extensions to the standard that make it significantly easier to use, compared to the reference implementation: It will automatically generate code for request and response bean classes, and does not require a WSDL for simple cases.
It also includes a "simple frontend" which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.
For REST, CXF also supports a JAX-RS frontend.
Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.x XML support to make configuration a snap, and much more.
Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.
To get started using CXF, check out the downloads, the user's guide, or the mailing lists to get
[CONF] Apache CXF > DOSGi Releases
DOSGi Releases Page edited by Christian Schneider Changes (3) h2. Releases h3. Release 1.5.0 (current version) ||Description||File|| |Multi-bundle distribution (tar.gz)|[cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.tar.gz| http://repository.apache.org/service/local/repositories/releases/content/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.5.0/cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.tar.gz]| |Multi-bundle distribution (zip)|[cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.zip|http://repository.apache.org/service/local/repositories/releases/content/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.5.0/cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.zip]| |Source distribution|[cxf-dosgi-ri-source-distribution-1.5.0.tar.gz|http://repository.apache.org/service/local/repositories/releases/content/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.5.0/cxf-dosgi-ri-source-distribution-1.5.0-dist.tar.gz]| h4. Highlights * Single bundle distribution removed to simplyfy release process and testing * Many bugfixes h3. Release 1.4.0 (current version) ... h4. Distributions h3. Release 1.3.1 1.3.1 is the current release of Distributed OSGi, as of April 10th 2012. For more information on what's new in this release, please see the README and release notes in each distribution. The various distributions can be downloaded as follows: ... h2. Snapshots You can download 1.56-SNAPSHOT distributions from the following locations: *Multi-Bundle distribution* [download from here|https://repository.apache.org/content/groups/snapshots/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.5-SNAPSHOT/cxf-dosgi-ri-multibundle-distribution-1.5-SNAPSHOT.zip] here|https://repository.apache.org/content/groups/snapshots/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.6-SNAPSHOT/cxf-dosgi-ri-multibundle-distribution-1.6-SNAPSHOT.zip] h3. Archived Releases ... Full Content Releases Release 1.5.0 (current version) Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.5.0-dir.zip Source distribution cxf-dosgi-ri-source-distribution-1.5.0.tar.gz Highlights Single bundle distribution removed to simplyfy release process and testing Many bugfixes Release 1.4.0 (current version) Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.4.0-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.4.0-dir.zip Single-bundle distribution cxf-dosgi-ri-singlebundle-distribution-1.4.0.jar Source distribution cxf-dosgi-ri-source-distribution-1.4.0.tar.gz Highlights 41 issues resolved (see jira) Karaf feature for easy installation in Apache Karaf Zookeeper discovery now supports automatic reconnects and Cluster configuration DOSGi is now independent of spring dm Custom intents are now created by publishing e.g. CXF Features as services Big refactorings make the code much easier to understand Known issues The default aegis data format will not work with Apache Karaf 2.3.0. (See DOSGI-153). Please upgrade to Apache Karaf 2.3.1 The sytem package exports in the felix multibundle distro may not bee suitable to all felix versions Migration There is one incompatible change in this release. Previously custom intents were defined by using a special spring dm file below osgi-inf in the bundle that exports a service. From DOSGi 1.4.0 on custom intents can be defined by exporting the intent (e.g. a feature) as an OSGi service with a special property "org.apache.cxf.dosgi.IntentName" for the name of the intent. See dosgi custom intents. Distributions Release 1.3.1 1.3.1 is the current release of Distributed OSGi, as of April 10th 2012. For more information on what's new in this release, please see the README and release notes in each distribution. The various distributions can be downloaded as follows: Description File Multi-bundle distribution (tar.gz) cxf-dosgi-ri-multibundle-distribution-1.3.1-dir.tar.gz Multi-bundle distribution (zip) cxf-dosgi-ri-multibundle-distribution-1.3.1-dir.zip Single-bundle distribution cxf-dosgi-ri-singlebundle-distribution-1.3.1.jar Source distribution cxf-dosgi-ri-source-distribution-1.3.1.tar.gz Snapshots You can download 1.6-SNAPSHOT distributions from the following locations: Multi-Bundle distribution download from here Archived Releases 1.3 was released February 6th, 2012. Description File Multi-bundle distribution (tar.gz)
[CONF] Apache CXF > DOSGi release build
DOSGi release build Page edited by Christian Schneider Changes (1) ... * go to https://repository.apache.org, log in with you apache id, find your staging repo and close it h2. Check completeness * Check the tag is there in subversion and contains the correct version in the poms * Check that the release notes are correct * Check that the staging repo is visible and contains the correct release version h2. Send vote mail to dev list ... Full Content Preparations Make sure your .m2/settings.xml contains your user and password apache.snapshots.https your-user your-password apache.releases.https your-user your-passwd Make sure you have a pgp key Make sure all jira issues for the version are resolved Export the jira issues from the jira roadmap view of the version you are doing and update distribution/multi-bundle/src/main/release/release_notes.txt Do the release in maven mvn release:prepare mvn release:perform go to https://repository.apache.org, log in with you apache id, find your staging repo and close it Check completeness Check the tag is there in subversion and contains the correct version in the poms Check that the release notes are correct Check that the staging repo is visible and contains the correct release version Send vote mail to dev list Release maven repo Stop watching space | Change email notification preferences View Online | View Changes | Add Comment
[CONF] Apache CXF > DOSGi release build
DOSGi release build Page edited by Christian Schneider Changes (1) ... * mvn release:prepare * mvn release:perform * go to https://repository.apache.org, log in with you apache id, find your staging repo and close it h2. Send vote mail to dev list ... Full Content Preparations Make sure your .m2/settings.xml contains your user and password apache.snapshots.https your-user your-password apache.releases.https your-user your-passwd Make sure you have a pgp key Make sure all jira issues for the version are resolved Export the jira issues from the jira roadmap view of the version you are doing and update distribution/multi-bundle/src/main/release/release_notes.txt Do the release in maven mvn release:prepare mvn release:perform go to https://repository.apache.org, log in with you apache id, find your staging repo and close it Send vote mail to dev list Release maven repo Stop watching space | Change email notification preferences View Online | View Changes | Add Comment
[CONF] Apache CXF > DOSGi release build
DOSGi release build Page added by Christian Schneider Preparations Make sure your .m2/settings.xml contains your user and password apache.snapshots.https your-user your-password apache.releases.https your-user your-passwd Make sure you have a pgp key Make sure all jira issues for the version are resolved Export the jira issues from the jira roadmap view of the version you are doing and update distribution/multi-bundle/src/main/release/release_notes.txt Do the release in maven mvn release:prepare mvn release:perform Send vote mail to dev list Release maven repo Stop watching space | Change email notification preferences View Online | Add Comment
