Changing File Adapter target directory - container bounce required?

Question

I edited USPSshipment.wsdl in the FulfillmentESB project to reflect my desired target directory (/home/oracle/usps_ship instead of C:\temp) and then re-registered the project with ESB.
The registration completed normally, and I verified that the edited USPSshipment.wsdl file exists in the deploy and content directories in the ESB home. Also, checking the WSDL file from the ESB console showed the new value.
However, until I bounced the OC4J_soa container, order submissions continued to use the C:\Temp target. After I bounced the container, the next order submission went to the desired /home/oracle/usps_ship.
What is the expected cacheing behavior here? Is there a programmatic way to clear the cache after an ESB deploy. It is too restrictive if I have to bounce the whole container serving ESB and BPEL (perhaps many processes and ESB adapters) just to make a change in one particular project.
Thanks.

Answer 1

Using the SOA Demo, FulfillementESB project ~
Example: Immediate reflection of change w/o further action
If I change the Shipment router filter criteria (Fulfillment_Shipment.esbsvc) to cut at say $750 instead of $500, then re-register FulfillmentESB with OrderBookingIS, JDeveloper reports:
Registration of Services Successful
Fulfillment Shipment Updates
The next submitted order follows the new criteria (e.g. a $600 order goes out USPS).
Example: Change not reflected in runtime, until OC4J container restarted
If I change the target physical directory of the USPS Shipment file adapter (USPSShipment.wsdl), then re-register FulfillmentESB with OrderBookingIS, JDeveloper reports:
Registration of Services Successful
However, the next submitted orders continue to be written to the previous target physical directory. Checking the value of the re-deployed USPSShipment.wsdl at the ESB host filesystem and through the ESB console shows the updated value, but the old copy is being actually used to process the message.
Restarting the OC4J container, causes the updated USPSShipment.wsdl to be referenced for messages submitted thereafter.
-Todd
Message was edited by:
tbeets