[jacorb-developer] TAO_IMR ImR_Client ImplRepo.idl is different between JacORB and TAO
Timothy Astle
timothy.astle at caris.com
Thu Nov 26 17:27:25 CET 2015
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?)
Continued below:
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.
>
> 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.)
>
> 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.
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).
Best wishes,
Tim
>
> -Phil
>
>> On Nov 25, 2015, at 2:10 PM, Timothy Astle <timothy.astle at caris.com> wrote:
>>
>> I just observed something and I wanted to solicit some thoughts.
>>
>> A while ago, we abandoned generating our own client stubs generated from the ImplRepo.idl since JacORB now provides these stubs. (We thought that was quite nice.) The client uses JacORB 3.7.
>>
>> Our server uses TAO, and has upgraded to use 2.2a_p6 distributed by OCI.
>>
>> We observed a problem calling the list operation from our Java client. It appears that the IDLs are now different between the two libraries. I'll point out the difference in the interface.
>>
>> https://github.com/DOCGroup/ATCD/blob/master/TAO/tao/ImR_Client/ImplRepo.idl
>>
>> /// Returns at most @a how_many servers in @a server_list. If there
>> /// are additional servers, they can be received through the
>> /// @a server_iterator. If there are no more servers, then
>> /// @a server_iterator is null.
>> /// If @a how_many == 0, then returns all servers.
>> /// If @a determine_active_status is true then
>> /// set ServerInformation::active_status attribute by determining
>> /// if the server is alive.
>> void list (in unsigned long how_many,
>> in boolean determine_active_status,
>> out ServerInformationList server_list,
>> out ServerInformationIterator server_iterator);
>>
>> https://github.com/JacORB/JacORB/blob/master/idl/tao_imr/ImplRepo.idl
>>
>> /// Returns at most <how_many> servers in <server_list>. If there
>> /// are additional servers, they can be received through the
>> /// <server_iterator>. If there are no more servers, then
>> /// <server_iterator> is null.
>> /// If how_many == 0, then returns all servers.
>> void list (in unsigned long how_many,
>> out ServerInformationList server_list,
>> out ServerInformationIterator server_iterator);
>>
>> I'm pretty sure interfacing to an Implementation Repository is not a part of the CORBA specification (from what little I recall from that large book).
>>
>> I'm just curious as to what we should do? Is there a plan for JacORB to somehow manage the versions of the ImplRepo.idl for all of the changes made in TAO? Is there some plan to try to maintain some type of compatibility for this interface between projects? Or is did we make a mistake by using the generated stubs provided by JacORB?
>>
>> I'm pretty sure I've seen the same committers working in both projects, so I'd appreciate your thoughts.
>>
>> Thanks for your time,
>>
>>
>> Tim
>> _______________________________________________
>> jacorb-developer maillist - jacorb-developer at lists.spline.inf.fu-berlin.de
>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
> --
> Phil Mesnier
> Principal Software Engineer and Partner, http://www.ociweb.com
> Object Computing, Inc. +01.314.579.0066 x225
>
>
>
>
>
--
Tim Astle
Development Manager for Web Technologies
*CARIS* <http://www.caris.com>
115 Waggoners Lane
Fredericton, New Brunswick
Canada E3B 2L4
Tel: +1.506.458.8533 Fax: +1.506.459.3849
www.caris.com <http://www.caris.com>
*Connect with CARIS*
Twitter <http://www.twitter.com/CARIS_GIS> | LinkedIn
<http://www.linkedin.com/groups?mostPopular=&gid=3217878> | Facebook
<https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878>
| Google+
<https://plus.google.com/b/114389770462919844434/114389770462919844434/posts>
| YouTube <http://www.youtube.com/user/CARISGIS>
Download your free copy of CARIS Easy View today!
www.caris.com/easyview <http://www.caris.com/easyview>
_________________________________________________________________________
This email and any files transmitted with it are confidential and
intended only for the addressee(s). If you are not the intended
recipient(s) please notify us by email reply. You should not use,
disclose, distribute or copy this communication if received in error.
Any views or opinions expressed in this email are solely those of the
author and do not necessarily represent those of the company. No binding
contract will result from this email until such time as a written
document is signed on behalf of the company.
More information about the jacorb-developer
mailing list