Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Mon, 4 Nov 2013 13:32:17 +0000 (UTC)
From: "Colm O hEigeartaigh (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12650005.1369859269701.16074.1383571937812@arcas>
In-Reply-To: <JIRA.12650005.1369859269701@arcas>
References: <JIRA.12650005.1369859269701@arcas>
Subject: [jira] [Assigned] (CXF-5048) StaticSTSProperties class requires a
 CXF message context to initialize using configure() method
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Colm O hEigeartaigh reassigned CXF-5048:
----------------------------------------

    Assignee: Colm O hEigeartaigh

> StaticSTSProperties class requires a CXF message context to initialize using configure() method
> -----------------------------------------------------------------------------------------------
>
>                 Key: CXF-5048
>                 URL: https://issues.apache.org/jira/browse/CXF-5048
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.7.3
>         Environment: OSX, Karaf 2.2.9, CXF 2.7.3, Camel 2.10.2, Jetty 7.6.7.v20120910, Karaf-Jetty 7.5.4.v20111024
>            Reporter: Dario Amiri
>            Assignee: Colm O hEigeartaigh
>             Fix For: 2.7.8, 2.6.11
>
>
> On May 29, 2013, at 12:47 PM, geecxf <[hidden email]> wrote:
> > While experimenting with the STS code I discovered that configureProperties()
> > method of the StaticSTSProperties class requires a CXF message context in
> > order to execute successfully.
> >
> > This seems a little strange to me because as far as I understand the
> > properties are set once and there is nothing about them is related to the
> > request context. The way it is implemented now you basically have to wait
> > until the service is invoked before you can initialize the properties. Is
> > there a reason why it was implemented this way?
> >
> > I ask because it just doesn't seem right. I would expect to be able to call
> > configureProperties() at some point in time before the service was invoked.
> ... [show rest of quote]
> This definitely looks like a bug.  In there, if the various properties objects are String's, then we end up doing:
>  Bus bus = PhaseInterceptorChain.getCurrentMessage().getExchange().getBus();
>             ResourceManager rm = bus.getExtension(ResourceManager.class);
> to get a ResourceManager to try and resolve those.   Most likely, we should do:
> 1) Allow setting a Bus object on the properties so that the actual bus used is settable.
> 2) If bus is null, call BusFactory.getThreadDefaultBus() instead.  
> Please log a bug.
> Dan 


--
This message was sent by Atlassian JIRA
(v6.1#6144)