Community
Participate
Working Groups
Need IIOP Portable Request Interceptor in ARM Library for Profile on Server feature based on the org.omg.PortableInterceptor library. The interceptor needs to integrate with the ARM Engine library and the TPTP Workbench.
Created attachment 45215 [details] Initial implementation of the IIOP request interceptor
Fixed version and target milestone to be consistent with TPTP development process. For defects, version specified is the version where the defect was found. The target milestone is the version that has or will have the fix for it.
Created attachment 46648 [details] ArmRequestInterceptor patch for tptp.trace.arm/src-model
Created attachment 46649 [details] ArmTestInterceptor for testing interceptor functionality This is a stripped down version of the ArmRequestInterceptor provided in the preceding patch. It was used to verify the procedure of regsitering the interceptor in WAS, and to ensure that the methods that we use for setting data on the service context and pulling the data off of the service context were working properly.
Procedure for registering the ArmTestInterceptor in WAS (instructions are analagous for org.eclipse.tptp.trace.arm.internal.model.iiop.ArmRequestInterceptor): This assumes that the ArmTestInterceptor.class has been added to a jar file in C:\arminterceptor.jar. 1. Edit the bootclasspath of WAS to include arminterceptor.jar. This can be done by editing the server.xml file for the server you'll be using. In the genericJvmArguments attribute of the 'jvmEntries' element, add -Xbootclasspath/a:C:\arminterceptor.jar If the '-Xbootclasspath/a' arg is already present, simply prepend the arminterceptor.jar to the list. 2. Add the interceptor to the list of interceptors configured in server.xml. Search for the <services> element for xmi:type="orb:ObjectRequestBroker". Under this element, add the element: <interceptors xmi:id="Interceptor_##" name="ArmTestInterceptor"/> where ## is replaced by some unique number (not appearing in any other 'interceptors' elements). 3. In order to pick up the above changes, WAS needs to be restarted. In order to verify that the ArmTestInterceptor is functioning, configure it to be used on two different WAS instances that have the chaining version of Plants. Chain instance #1 to instance #2. Open the SystemErr.log (under logs/<server_name>) on instance #1. You should see a message similar to: [7/21/06 12:45:56:067 EDT] 00000040 SystemErr R SEND_REQUEST adding byte arr y to service context: [7/21/06 12:45:56:067 EDT] 00000040 SystemErr R 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 , 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29 , 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49 , 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69 , 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89 , 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107 , 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123 , 124, 125, 126, 127, -128, -127, -126, -125, -124, -123, -122, -121, -120, -119 , -118, -117, -116, -115, -114, -113, -112, -111, -110, On instance #2 (the 'receiving' machine), in SystemErr.log you should see a similar message, except it indicates that the data was received.
fixed in head.
Closed.
