Re: Revising PluginDetail JMX Methods

The PluginDetail and PluginInfo objects are returned from RMI methods, which
I think means they are serialized and read back in on the client JVM. Thus,
if we change their fields, any client application will no longer be able to
deserialize them unless it runs with the version of cruisecontrol.jar with
the altered classes. So it seems to me that we should leave PluginDetail
alone, if we want to maintain full backwards compatibility.

However, we could change how the PluginDetails are generated (in
CruiseControlController and PluginRegistry) and use the existing GenDoc
framework to do this, removing some duplication. Should this be turned into
a JIRA ticket?

  - Seth Pollen


On Tue, Nov 2, 2010 at 4:23 PM, Jeffrey Fredrick <[email protected]
> wrote:

>
> I think backwards compatibility is important.
>
> I haven't looked at the design of PluginInfo and PluginDetail, but
> shouldn't there be a way to have any legacy interface methods delegate to
> the new ones?  That give us backwards compatibility without duplicating
> implementation, yes?
>
> Jtf
>
>
> On Sat, Oct 30, 2010 at 4:47 PM, Seth Pollen <[email protected]> wrote:
>
>> I guess if we want to keep full backwards compatibility, we should just
>> leave the JMX interface alone. The motivation for my original suggestion is
>> that the old PluginDetail classes could be merged with the new PluginInfo
>> classes, reducing the duplication of functionality. But if we want to keep
>> backwards compatibility, we need the PluginDetail classes, and adding more
>> methods to use PluginInfo would be work without any real driving reason
>> behind it.
>>
>> But I am currently working on the CC-Config project, and I know that it is
>> undergoing a major rewrite, which would give us the opportunity to jump to a
>> new JMX interface if a one was introduced.
>>
>>   [ Seth Pollen ]
>>
>>
>>
>> On Fri, Oct 29, 2010 at 10:31 PM, Jeffrey Fredrick <
>> [email protected]> wrote:
>>
>>>
>>> Would this impact the RMI interface?
>>>
>>> This tool is the major one I'd worry about for backwards compatibility:
>>>
>>> http://cc-config.sourceforge.net/
>>>
>>> My bias would be to keep backwards compatibility.  Could you add new
>>> methods or add equivalent methods with alternative names with the new return
>>> types?
>>>
>>> Jtf
>>>
>>>
>>> On Fri, Oct 29, 2010 at 3:40 PM, Seth Pollen <[email protected]> wrote:
>>>
>>>> Hello all,
>>>>
>>>> Currently, there are a few methods in the JMX interface that return
>>>> PluginDetails. As a part of CC-202<http://jira.public.thoughtworks.org/browse/CC-202>,
>>>> we have introduced a new class (PluginInfo) that provides a fuller set of
>>>> behaviors and includes most of what was provided by PluginDetail. I think it
>>>> would be good to merge these two classes together, but that would involve
>>>> changing the return types of some JMX methods (such as adding and renaming
>>>> methods in PluginDetail). Will that break existing tools which use the JMX
>>>> interface? Is that an acceptable problem that we can deal with?
>>>>   Thanks.
>>>>
>>>>   - Seth
>>>>
>>>
>
> --
> CITCON
> Continuous Integration and Testing Conference
> http://www.citconf.com/
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cruisecontrol-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cruisecontrol-devel
>
>

------------------------------------------------------------------------------
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
http://p.sf.net/sfu/hpdev2dev-nov

_______________________________________________
Cruisecontrol-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-devel