[jacorb-developer] TAO_IMR ImR_Client ImplRepo.idl is different between JacORB and TAO

[Phil Mesnier]

Hi Tim,

Since the ImR is proprietary, backwards compatibility is not a requirement. However I do try to avoid breaking changes. In this case the discontinuity occurred nearly 3 years ago. We never detected it because the list operation was not part of our funder's use case. Honestly I had forgotten that TAO's ImplRepo.idl had been duplicated in the JacORB repository. I think the duplication was a compromise since we needed that and the ServerObject interfaces to support managing JacORB servers with the TAO IMR but of course we couldn't make an inter-product dependency.

> On Nov 26, 2015, at 10:27 AM, Timothy Astle <timothy.astle at caris.com> wrote:
> 
> I guess part of the way forward depends on if the ImplRepo.idl was supposed to be backwards compatible in the first place.  If not, there are a few options.  If so, then I think the proper approach would be to refactor the IDL so that it continues to work.  (But perhaps I'm over simplifying things?)
> 

Last night I did an experimental refactoring of the list operation to restore the old list operation. Unfortunately my TAO tests are yielding core files. Even if I get that sorted out then I've got the same problem for TAO users with different patch levels of TAO deployed. That is the situation my current funder is in. Their customer has a very complex deployment involving 100s of host machines running scores of server processes. Everything in their environment is script-driven, using the tao_imr CLI tool to start/stop/list servers. They are the ones who requested the new constraint on the list operation, so I can't do something disruptive to them.

It's too bad that a request interceptor cannot modify the argument list, that would be the a simple solution. We could make a DII/DSI based proxy that forwards all requests as is, and if it is a 3-arg list, it transforms it into a 4-arg call defaulting the new arg value. There may be a way to use interface versioning, but I don't know if TAO ever got around to supporting that, apart from not breaking the IDL compiler.

> Continued below:
> 

Ditto:

> 
> On 25/11/2015 10:35 PM, Phil Mesnier wrote:
>> Hi Tim,
>> 
>> You are correct that the Implementation Repository is considered a "proprietary" service by the spec.
>> 
>> OCI has been working on the TAO implementation repository for a customer who has very severe demands on the ImR. They have funded many major changes including the change to the list operation. I had to do some digging, it seems the list operation was extended prior to the release of TAO 2.2a but after the contribution of the tao_imr idl's to JacORB. It is unfortunate that the signature of the list operation was modified rather than adding a new operation, but it happened.
>> 
>> So there are two ways to reconcile this conflict. Update the tao_imr/ImplRepo.idl in JacORB or refactor TAO's ImplRepo.idl to restore the old list signature and add a "listExt" operation with the new signature.  Or I could do both. There have been some nifty extensions added to the ImR since TAO 2.2a was released.
> 
> I think personally, I'd favour the listExt approach.  I'd take a guess that others users are about to this this problem at some point, and hopefully they could just skip over the revision with the inconsistency in the method signature.  Only after updating the TAO ImplRepo, would I consider bringing those changes back to JacORB.
> 

Given the longevity of the inconsistency, I'd say you are the only ones who have tried making a rich ImR admin client in JacORB. The other users of the interface as I've mentioned are my current customers, using the TAO administrative client utility, and I can't break their ability to roll out upgrades over time.


>> 
>> Now the aforementioned customer uses the TAO supplied command line utility for in the control of the ImR, but I don't know how to refactor TAO's ImplRepo.idl in a way that doesn't break anyone else's client. Of course the likelihood of that is small.
> 
> Is the concern that people are using the current TAO ImplRepo.idl that has the list's signature changed?  If so, and if you view that the ImplRepo.idl should maintain backwards compatibility, I don't think I'd be too concerned.  I'd view it as an accident (bug) and that they'd have to change a small bit of code.  (Unless I'm missing something or misunderstanding your question.)
> 

I was thinking of unnamed 3rd parties that may have deployed IMR Locators and these would have trouble if they upgrade some but not all. You do seem to make the case that the JacORB copy of the ImplRepo.idl  should be brought in line with TAO 2.2a, or maybe it should be separate interfaces for TAO 2.0a, which is what you have, and a second interface for TAO 2.2a with the modified list and a separate AdministrationExt interface with extra operations. I don't know how to distinguish those at an application level though. The IOR carries an ORB Identifier that just declares it is TAO, not which TAO. I could add a new tagged component but that is not an easy solution.

Probably the most expedient solution for you is to refresh the JacORB copy of the ImplRepo.idl file and you patch your code to add a "false" constant in all your list calls and be done with it.

>> 
>> How extensively does your application code make use of the ImplementationRepository::Administration interface? How about the list() operation in particular? If you only use it in a couple of places, the easiest solution is to just update the ImplRepo.idl that's shared and then you can add the "determine_active_status" flag to your code.
> 
> We use the Administration to do IMR things, like get the list of services, add them, activate them and remove them.  I'm not sure how to answer "extensively", but it's critical to the functionality of the software, but not sprinkled around it willy-nilly :)
> 
> Here's a bit more context though.  We're issuing a major release of our software, so backwards compatibility is not supported between the client and server.  But I'm concerned that the change in the ImplRepo.idl is a bug, and that'll cause me grief down the road as the behaviour could be corrected, which will affect my updating of JacORB and TAO (and part of the reason we updated TAO was for MSVC2013 support) for years to come, whether it be a temporary workaround, or fixing on particular versions of libraries.  We found this problem rather late unfortunately and I'm even considering if it's possible to use a previous release of TAO, though that may not be that easy.

TAO 2.0a ought to build fine with MSVC2013. However, that would be denying yourself a lot of significant features of TAO such as a more robust ImR, load balancing integrated with the naming service, dynamic ORB and POA thread pools to name a few. 

Are you registering JacORB servers with the TAO ImR? I recall we had to add awareness of JacORB servers into the TAO ImR, so that may be the feature that forces you to stick with TAO 2.2a.

> 
> Anyway, I really do appreciate your thoughts and your time.  If you can provide me with a hint on recommended approach, I can discuss a suitable plan on my end (such as possibly patching the ImplRepo.idl locally).
> 

I think the local patch to ImplRepo.idl and patch the handful of calls in your code. I'll fix the IDL in the product and whenever the next release comes out you'll be in synch.

HTH,
Phil

--
Phil Mesnier
Principal Software Engineer and Partner,   http://www.ociweb.com
Object Computing, Inc.                     +01.314.579.0066 x225