In the Navigator pane, expand Metadata Repositories and select mds-owsm, as

Maintaining the Oracle WSM Repository 17-5 Importing META-INFpolicysetsglobalapp-only-web-service-policies Importing META-INFpolicysetsglobalmigrate_example Successfully imported 6 documents For more information about the WLST commands and their arguments, see Web Services Custom WLST Commands in WebLogic Scripting Tool Command Reference. Migrating Policies Between Application Environments Policies can be migrated through the different stages of the application development and deployment cycles, such as from development to production. Oracle recommends using the importRepository and exportRepository commands for policy migration, as described in Migrating Policies on page 15-4. Exporting Policies from the Oracle WSM Repository for Use in JDeveloper In JDeveloper, you can add custom policies to the default policy store location at: C:\Documents and Settings\user-dir\ApplicationData\JDeveloper\system11.1.1.2.x.x. x\DefaultDomain\oracle\store\gmds Within this directory, Oracle WSM policies files must be included using one of the following directory structures: ■ Predefined Oracle WSM policies: owsmpoliciesoraclepolicy_file ■ Custom user policies: owsmpoliciespolicy_file When exporting policy files from the Oracle WSM Repository for use in JDeveloper, this directory structure is not maintained. You must ensure that when adding the exported policy to the JDeveloper environment that you use the required directory structure noted above. Otherwise, the policies will not be available in the JDeveloper environment. Patching Policies in the Repository You can patch the Oracle WSM Repository using either Fusion Middleware Control or the WLST commands, as described in Understanding the Different Mechanisms for Importing and Exporting Policies on page 17-2. When you create or update a policy, there are two possible scenarios to consider when you patch the repository: ■ You create a new policy or update an existing policy that uses a new policy URI. In this scenario, the patching of the repository acts as if a new file was added to the installation and, as a result, only impacts the components that expect to use the new policy. Once loaded, the policy is available to all applications. Generally speaking, using a new policy URI is the preferred model as policies are typically named to convey the behavior they represent. ■ You create a new policy or update an existing policy that uses an existing policy URI. In this scenario, the patching of the repository acts as if an existing file was overwritten with a new version and, therefore, impacts all components that are using the existing policy. Once loaded, all applications will use the new version of the policy. Reusing an existing URI is typically only done to make minor modifications to the behavior of a policy. Note that if you use WLST commands to patch the repository, you need to restart the server to ensure that the latest version of the policy is enforced. You do not need to restart if you use Fusion Middleware Control.