Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 6 May 2014 12:58:14 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12661346.1375430518648.236078.1399381094672@arcas>
In-Reply-To: <JIRA.12661346.1375430518648@arcas>
References: <JIRA.12661346.1375430518648@arcas>
Subject: [jira] [Assigned] (CXF-5174) Split xkms into xkiss and xkrss parts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-5174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Schneider reassigned CXF-5174:
----------------------------------------

    Assignee: Christian Schneider

> Split xkms into xkiss and xkrss parts
> -------------------------------------
>
>                 Key: CXF-5174
>                 URL: https://issues.apache.org/jira/browse/CXF-5174
>             Project: CXF
>          Issue Type: Improvement
>            Reporter: Christian Schneider
>            Assignee: Christian Schneider
>             Fix For: 3.0.0
>
>
> Currently xkms supports both xkiss and xkrss operations in the same code.
> As can be seen in the linked issue it often makes sense to only support xkiss.
> Currently we support this using a switch.
> A better way may be to separate the xkrss Operations into a separate bundle. This bundle will expose an internal service with the interface "org.apache.cxf.xkms.handlers.Register". 
> If the main service finds such an OSGi service it will forward xkrss methods to this service. If it does not find it it will return Sender / Message Unsupported. 
> This is much better than the current aproach where we use spring to wire in the xkrss Register handler as the user can change or remove the implementation without messing with the spring context.


--
This message was sent by Atlassian JIRA
(v6.2#6252)