axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe (JIRA)" <>
Subject [jira] Updated: (AXIS2-2335) need to be able to change service policy on the fly...
Date Mon, 11 Jun 2007 18:21:27 GMT


Deepal Jayasinghe updated AXIS2-2335:

    Priority: Blocker  (was: Major)

Its your call.


> need to be able to change service policy on the fly...
> ------------------------------------------------------
>                 Key: AXIS2-2335
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Improvement
>          Components: kernel
>    Affects Versions: 1.1.1
>         Environment: Windows XP, Tomcat 4.1, Axis2, using rampart 1.1
>            Reporter: Jackson Wynn
>            Assignee: Sanka Samaranayake
>            Priority: Blocker
> I  need to be able to dynamically change the security policy of a specified axis service,
where new security policies are constructed from static policy components contained in the
services.xml, combined with policy components read in from external policy files downloaded
separately to the server. This work is motivated by one of the rampart sample applications
that loads policy files on the fly - I want to be able to demonstrate on-the-fly policy changes
in an axis service as well..
> I wrote some service code that merges and normalizes policy components into a single
policy object, which is applied to the axisService using applyPolicy(). I was able to verify
in a debugger that the new policy object is correctly formed and stored in the axisService's
policyInclude. The problem that I'm seeing is that the configurationContext that my service
code updates with this new policy info is not the same instance that is used to initialize
the messageContext for incoming SOAP messages. This second configurationContext is created
when the AxisServlet is initialized, before my new policy is constructed, and there does not
appear to be anyway to access this configurationContext instance within my service code. 
> One possible solution would be for the ConfigurationContextFactory to maintain a reference
to the initial configurationContext instance that it creates and to provide a static method
that can be used to retrieve it from within the service code.  I'm putting this in as an improvement
request, but I'm not sure why there is a global context that is not globally accessible. I
don't know the axis kernel well enough to understand why this would be a bad idea.
> Is there any other way to access the configurationContext instance maintained by the
> Any ideas would be appreciated!
> Thanks,
> Jackson Wynn
> Lead Infosec Engineer - G026
> The MITRE Corporation
> Bedford, MA

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message