[Engine-devel] Using REST API in web UI - review call summary
by Vojtech Szocs
Hi guys,
this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something.
--
Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael & Gilad)
A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us.
As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code).
--
Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav)
[For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.]
A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like "get VMs and related data" would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding.
oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1].
For example:
sdk.getVmsWithExtraData(
callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API
callbackFiredWhenAllDataIsReady // update client only when all data is ready
)
[1] http://en.wikipedia.org/wiki/Leaky_abstraction
--
Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library.
I agree that conceptually both above mentioned projects should go into dedicated "ovirt-engine-sdk-js" git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of "ovirt-engine" git repository.
... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law)
Regards,
Vojtech
10 years, 10 months
[Engine-devel] ovirt-sdk-python 3.3.0.1 released
by Michael Pasternak
- added new collection ClusterGlusterVolumeBrickStatistics
- added NetUp 'cloned disk' importing capabilities
- to ClusterGlusterVolumeBricks.list() added new argument "all_content"
- to ClusterGlusterVolumeBricks.get() added new argument "all_content"
- to host install method added new parameter "image"
- to host add method added new parameter "display.address"
- to vm add method added new parameter "vm.cpu.mode"
- to vm add method added new overload for creating vm from snapshot
- to cluster added tunnel_migration
- to display added keyboard_layout
- to display added smartcard_enabled
- to DataCenter added Clusters sub-collection
- to StorageDomain added Disks sub-collection
- to Disks.list() added 'unregistered' argument
- to Host added display.address
- to Snapshot added commit/preview/undo actions
- to vms.add() added overload for creating vm from snapshot
- to hosts.add() added [@param host.display.address: string]
- to vm.ticket() added [@param action.ticket.value: string]
- return error if amount of fetched objects in X.get() is > 1 #890327
- session based authentication for /localhost is broken #916285
- explicitly ask for reply in xml
- Add constructor parameter validate_cert_chain=True #915225
- defend against malformed server reply
For more details see [1].
[1] http://wiki.ovirt.org/Python-sdk-changelog
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
10 years, 12 months
[Engine-devel] GUI widget for adding/removing entries
by Lior Vernia
Hello,
Lately a patch has been merged that introduces a widget for
adding/removing entries (e.g. network interfaces when creating/editing a
VM):
http://gerrit.ovirt.org/#/c/19530/
This kind of widgets is becoming common in oVirt, so the idea is to make
adding one easy rather than copying & pasting code. AddRemoveRowWidget
takes care of the plus/minus button logic, disabling an entry that
hasn't been edited, and the arranging in rows.
In order to use it, one is required to override a couple of abstract
methods that are dependent upon the specific entry implementation. An
example may be found in ProfilesInstanceTypeEditor, which handles
adding/removing network interfaces in the new/edit VM dialog.
Yours, Lior.
11 years
[Engine-devel] Using config values
by Kanagaraj
This is a multi-part message in MIME format.
--------------050008020702070900040001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi All,
The are some issues arising in configurations whenever we move up on the
versions(3.3 => 3.4), because of the way we store and interpret them.
Whenever there is a new cluster level, you will need to add a new entry
for all(most) of the configuration. Mostly a copy paste if you see from
3.2 to 3.3, except some CPU/PM type related configurations.
Better option would be to have the defaul config value in
ConfigValues.java and the overrides will go to config.sql. In this
approach you don't need a new entries to config.sql when there is a new
cluster level.
Lets take an exmaple, "SupportForceCreateVG" - This is supported from
3.1 onwards,
If you look at config.sql, you will see following entries
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');
And in ConfigValues.java
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute("false")
SupportForceCreateVG,
Now if there is 3.4 and 3.5, the user needs to add 2 more entries, which
i feel is redundant.
Instead we can make
@TypeConverterAttribute(Boolean.class)
@DefaultValueAttribute("true")
SupportForceCreateVG,
and have only the following in config.sql
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in ConfigValues.java.
Please share your thoughts on this.
Thanks,
Kanagaraj
--------------050008020702070900040001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi All,<br>
<br>
The are some issues arising in configurations whenever we move up on
the versions(3.3 => 3.4), because of the way we store and
interpret them.<br>
<br>
Whenever there is a new cluster level, you will need to add a new
entry for all(most) of the configuration. Mostly a copy paste if you
see from 3.2 to 3.3, except some CPU/PM type related configurations.<br>
Better option would be to have the defaul config value in
ConfigValues.java and the overrides will go to config.sql. In this
approach you don't need a new entries to config.sql when there is a
new cluster level.<br>
<br>
Lets take an exmaple, "SupportForceCreateVG" - This is supported
from 3.1 onwards,<br>
<br>
If you look at config.sql, you will see following entries <br>
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');
<br>
select fn_db_add_config_value('SupportForceCreateVG','true','3.1');
<br>
select fn_db_add_config_value('SupportForceCreateVG','true','3.2');
<br>
select fn_db_add_config_value('SupportForceCreateVG','true','3.3');<br>
<br>
And in ConfigValues.java<br>
<br>
@TypeConverterAttribute(Boolean.class)<br>
@DefaultValueAttribute("false")<br>
SupportForceCreateVG,<br>
<br>
Now if there is 3.4 and 3.5, the user needs to add 2 more entries,
which i feel is redundant.<br>
<br>
Instead we can make <br>
<br>
@TypeConverterAttribute(Boolean.class)<br>
@DefaultValueAttribute("true")<br>
SupportForceCreateVG,<br>
<br>
and have only the following in config.sql<br>
select fn_db_add_config_value('SupportForceCreateVG','false','3.0');<br>
<br>
if a particular value(for a specific cluster level) is not found in
Config.sql, the fallback is to use the value available in
ConfigValues.java.<br>
<br>
Please share your thoughts on this.<br>
<br>
Thanks,<br>
Kanagaraj<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</body>
</html>
--------------050008020702070900040001--
11 years
[Engine-devel] Remove Comment column in main tabs
by Mike Kolesnik
------=_Part_40758794_854245147.1385448274314
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi,
When the comment RFE was added (in 3.3), there was also a column added to many main tabs.
I would like to propose to get rid of the column (which can only house one icon or no icon),
and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.
In this case the icon should probably be scaled down a bit since its huge.
I think this would be a good alternative and save us some valued screen real estate.
Thoughts, opinions?
Regards,
Mike
------=_Part_40758794_854245147.1385448274314
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,<br></div><div><br></div><div>When the comment RFE was added (in 3.3), there was also a column added to many main tabs.<br></div><div><br></div><div>I would like to propose to get rid of the column (which can only house one icon or no icon),</div><div>and instead if there's a comment on an entity just display the icon with the tooltip adjacent to the name.<br></div><div><br></div><div>In this case the icon should probably be scaled down a bit since its huge.<br></div><div><br></div><div>I think this would be a good alternative and save us some valued screen real estate.<br></div><div><br></div><div>Thoughts, opinions?<br></div><div><br></div><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><div><br></div></div></body></html>
------=_Part_40758794_854245147.1385448274314--
11 years
Re: [Engine-devel] Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
by Eyal Edri
I updated the environment to support f20, including new slave and nighlites.
i will send a separate email on it soon to infra/users/devel.
Eyal.
----- Original Message -----
> From: "Doron Fediuck" <dfediuck(a)redhat.com>
> To: "Dan Kenigsberg" <danken(a)redhat.com>, "David Caro Estevez" <dcaroest(a)redhat.com>
> Cc: board(a)ovirt.org, "users" <users(a)ovirt.org>, eedri(a)redhat.com, "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> Sent: Thursday, November 28, 2013 1:55:13 PM
> Subject: Re: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
>
>
>
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken(a)redhat.com>
> > To: board(a)ovirt.org, "users" <users(a)ovirt.org>
> > Cc: "Doron Fediuck" <dfediuck(a)redhat.com>, eedri(a)redhat.com
> > Sent: Thursday, November 28, 2013 12:19:05 PM
> > Subject: Fedora 20 support, Was: [Users] oVirt Weekly Meeting Minutes --
> > 2013-11-27
> >
> > We've forgotten to discuss an important issue: Fedora 20, which is
> > expected to be out in two weeks:
> > http://fedoraproject.org/wiki/Releases/20/Schedule.
> > I believe that ovirt-3.4 must support it, and that ovirt-3.3.2 would
> > better do so.
> >
> > Toni has fixed two issues regarding Vdsm-networking, and they are going
> > into ovirt-3.3.2 beta. However, we must perform much more comprehensive
> > testing.
> >
> > We'd need to have f20 Jenkins slave(s), and someone in each team
> > responsible to testing functionality. Who can cover for storage, virt,
> > infra and integration?
> >
> > Dan.
> >
>
> Indeed so, thanks Dan.
> David, is this something we have resources for?
>
11 years
Re: [Engine-devel] [Users] oVirt Weekly Meeting Minutes -- 2013-11-27
by Sandro Bonazzola
Il 29/11/2013 13:13, Dan Kenigsberg ha scritto:
> On Fri, Nov 29, 2013 at 11:49:59AM +0100, Sandro Bonazzola wrote:
>> Il 29/11/2013 09:43, Gianluca Cecchi ha scritto:
>>> On Fri, Nov 29, 2013 at 8:57 AM, Sandro Bonazzola wrote:
>>>
>>>>>
>>>>> Meeting summary
>>>>> ---------------
>>>>> * Agenda and roll Call (doron, 15:02:42)
>>>>> * 3.3 update releases (doron, 15:04:23)
>>>>> * 3.4 planning (doron, 15:04:24)
>>>>> * conferences and workshops (doron, 15:04:26)
>>>>> * infra update (doron, 15:04:27)
>>>>> * other topics (doron, 15:04:29)
>>>>> * LINK: http://gerrit.ovirt.org/#/admin/projects/ovirt-release ~
>>>>> (danken, 15:12:58)
>>>>> * LINK: http://gerrit.ovirt.org/21794 (mburns, 15:15:04)
>>>>> * LINK: http://jenkins.ovirt.org/job/ovirt-release/16800/ (mburns,
>>>>> 15:15:48)
>>>>> * mburns to add sbonazzo as a maintainer to support ovirt-release
>>>>> project (doron, 15:18:17)
>>>>
>>>> ovirt-release-9 released yesterday
>>>
>>> BTW: I see that this package contains
>>> /etc/yum.repos.d/fedora-virt-preview.repo
>>> (and ovirt-release-fedora-8-1.noarch already did so)
>>> By default all lines are disabled in it.
>>> When and how this repo should be enabled? Only when using nightly or
>>> only under developers/maintainers indications?
>>
>> I think that fedora-virt-preview should be used with nightly, stable shouldn't need it.
>> However, since fedora-virt-preview contains vdsm - related packages not needed if you run only ovirt-engine (without using the same host as
>> hypervisor) I think it's better to wait for VDSM guys answer.
>
> Vdsm is not in
> http://fedorapeople.org/groups/virt/virt-preview/fedora-20/x86_64/
>
> virt-preview is not needed for ovirt-3.3, and frankly, I think it should
> be dropped from ovirt-release.
>
> It used to be needed on the nodes when vdsm required a version of
> libvirt that was not yet in Fedora. Now that we have el6 as a
> fully-supported platform, and given that el6 is missing from
> virt-preview, virt-preview is much less helpful to us.
>
> Dan.
>
So, any objection in removing virt-preview from ovirt-release?
What about nightly? Will it be needed there?
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
11 years
Re: [Engine-devel] Weird behavior of multiple SetVmTicket query
by Vojtech Szocs
------=_Part_22230002_1751095465.1384256418493
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Forwarding this email to engine-devel so that backend maintainers are aware of this issue.
Looking at the code:
- MultipleActionsRunner#Execute first creates and "validates" all commands:
A. the "for" block which iterates over getParameters()
1-> validate correlation ID, if OK create and add command, otherwise add returnValue
B the "if" block which tests getCommands().size()
1-> if single command to execute, add its "canDoActionOnly" returnValue, which is returnValue with canDoAction but without actual result object
2-> if multi commands to execute, execute chunks of max. 10 threads (sequentially, ThreadPoolUtil.invokeAll returns after all threads complete), same returnValue as above
C. the "if" block which tests canRunActions
1-> all commands are executed within SINGLE THREAD due to ThreadPoolUtil.execute(Runnable), which is kind of weird comapred to how returnValues are prepared (see B2)
2-> when executing command, code DOES NOT CARE about its returnValue, i.e. returnValue was already prepared (see B) and command execution should just update it
The problem (I think) is that C1 starts a different thread (to execute all commands) and immediately returns, i.e. code doesn't wait for thread to complete. This is why returnValues are observed on frontend as inconsistent.
Additionally, we're also mixing of two different things: canDoAction processing and returnValues processing. IMHO this should be refactored to make code easier to read.
Changes done by Alex (patch attached):
X1. returnValues changed to Collections.synchronizedList
-> this means all access to returnValues is now serial
-> iteration over synchronizedList should also be enclosed in "synchronized (list)" block, so this:
for (VdcReturnValueBase value : returnValues) ...
should be this:
synchronized (returnValues) { for (VdcReturnValueBase value : returnValues) ... }
X2. commented-out original command execution via ThreadPoolUtil.execute(Runnable)
-> new RunCommands method invokes all commands each in separate thread via ThreadPoolUtil.invokeAll
-> returnValues list is explicitly updated
Guys, what do you think?
Vojtech
----- Original Message -----
> From: "Alexander Wels" <awels(a)redhat.com>
> To: "Frantisek Kobzik" <fkobzik(a)redhat.com>
> Cc: "Vojtech Szocs" <vszocs(a)redhat.com>
> Sent: Monday, November 11, 2013 9:19:08 PM
> Subject: Re: Weird behavior of multiple SetVmTicket query
>
> Hi,
>
> I did some debugging, and the problem is a race condition in the
> MultipleActions class. The whole class seems to have a lot of multi-threading
> issues but if I modify the code to wait for the results of the actions to
> return before returning the return value, everything works fine.
>
> I am attaching a patch that solves the issue at hand, but should not be
> considered a real patch. It is just to show the issue is in the back-end not
> the front-end code. The front-end code is just exposing an issue in the back-
> end
>
> Alexander
>
> On Monday, November 11, 2013 09:53:22 AM you wrote:
> > Ok, thank you very much!
> >
> > ----- Original Message -----
> > From: "Alexander Wels" <awels(a)redhat.com>
> > To: "Frantisek Kobzik" <fkobzik(a)redhat.com>
> > Sent: Monday, November 11, 2013 2:15:43 PM
> > Subject: Re: Weird behavior of multiple SetVmTicket query
> >
> > Frantisek,
> >
> > I had seen this before, let me test and fix it for you, it is very likely
> > my
> > patch broke that.
> >
> > Alexander
> >
> > On Monday, November 11, 2013 03:43:19 AM you wrote:
> > > Hi Alex,
> > >
> > > recently I noticed problems with invoking console for multiple VMs
> > > (select
> > > more VMs in webadmin and then hit the console btn). I was sure it worked
> > > in
> > > past so i git-bisected the master branch and I discovered that this
> > > problem
> > > is apparently caused by patch [1]. For single vm console invocation it
> > > works fine, but for multiple VMs it doesn't.
> > >
> > > I did some closer investigation with a debugger and it seems that
> > > getSucceeded() on the return val of SetVmTicket command returns false in
> > > case of multiple execution despite the fact SetVmTicketCommand sets this
> > > value to true. I suppose there is some problem with propagation of
> > > command
> > > return value from BE to FE. The same goes for the encapsulated
> > > returnValue
> > > attribute (it contains value of the generated ticket). When invoking
> > > multiple consoles it is null (although it has been filled on backend).
> > > Weird.
> > >
> > > Tomas told me you did some optimizations for multiple command executions,
> > > do you know it might cause it? Please let me know if you have any idea...
> > >
> > > Cheers,
> > > F.
> > >
> > > [1]: http://gerrit.ovirt.org/#/c/17356/
>
------=_Part_22230002_1751095465.1384256418493
Content-Type: text/x-patch; name=thread_wait.patch
Content-Disposition: attachment; filename=thread_wait.patch
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL2JhY2tlbmQvbWFuYWdlci9tb2R1bGVzL2JsbC9zcmMvbWFpbi9qYXZhL29y
Zy9vdmlydC9lbmdpbmUvY29yZS9ibGwvTXVsdGlwbGVBY3Rpb25zUnVubmVyLmphdmEgYi9iYWNr
ZW5kL21hbmFnZXIvbW9kdWxlcy9ibGwvc3JjL21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL2Nv
cmUvYmxsL011bHRpcGxlQWN0aW9uc1J1bm5lci5qYXZhDQppbmRleCBhNzJmYmQ5Li4xYjRmNGRh
IDEwMDY0NA0KLS0tIGEvYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy9tYWluL2phdmEv
b3JnL292aXJ0L2VuZ2luZS9jb3JlL2JsbC9NdWx0aXBsZUFjdGlvbnNSdW5uZXIuamF2YQ0KKysr
IGIvYmFja2VuZC9tYW5hZ2VyL21vZHVsZXMvYmxsL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2Vu
Z2luZS9jb3JlL2JsbC9NdWx0aXBsZUFjdGlvbnNSdW5uZXIuamF2YQ0KQEAgLTEsNiArMSw3IEBA
DQogcGFja2FnZSBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsOw0KIA0KIGltcG9ydCBqYXZhLnV0
aWwuQXJyYXlMaXN0Ow0KK2ltcG9ydCBqYXZhLnV0aWwuQ29sbGVjdGlvbnM7DQogaW1wb3J0IGph
dmEudXRpbC5MaXN0Ow0KIGltcG9ydCBqYXZhLnV0aWwuY29uY3VycmVudC5DYWxsYWJsZTsNCiAN
CkBAIC0yMCw3ICsyMSw3IEBAIHB1YmxpYyBjbGFzcyBNdWx0aXBsZUFjdGlvbnNSdW5uZXIgew0K
ICAgICBwcml2YXRlIGZpbmFsIHN0YXRpYyBpbnQgQ09OQ1VSUkVOVF9BQ1RJT05TID0gMTA7DQog
DQogICAgIHByaXZhdGUgVmRjQWN0aW9uVHlwZSBfYWN0aW9uVHlwZSA9IFZkY0FjdGlvblR5cGUu
VW5rbm93bjsNCi0gICAgcHJpdmF0ZSBMaXN0PFZkY0FjdGlvblBhcmFtZXRlcnNCYXNlPiBfcGFy
YW1ldGVyczsNCisgICAgcHJpdmF0ZSBmaW5hbCBMaXN0PFZkY0FjdGlvblBhcmFtZXRlcnNCYXNl
PiBfcGFyYW1ldGVyczsNCiAgICAgcHJpdmF0ZSBmaW5hbCBBcnJheUxpc3Q8Q29tbWFuZEJhc2U8
Pz4+IF9jb21tYW5kcyA9IG5ldyBBcnJheUxpc3Q8Q29tbWFuZEJhc2U8Pz4+KCk7DQogICAgIHBy
b3RlY3RlZCBib29sZWFuIGlzSW50ZXJuYWw7DQogDQpAQCAtNTUsNyArNTYsNyBAQCBwdWJsaWMg
Y2xhc3MgTXVsdGlwbGVBY3Rpb25zUnVubmVyIHsNCiAgICAgICAgICAgICByZXR1cm4gbmV3IEFy
cmF5TGlzdDxWZGNSZXR1cm5WYWx1ZUJhc2U+KCk7DQogICAgICAgICB9DQogDQotICAgICAgICBB
cnJheUxpc3Q8VmRjUmV0dXJuVmFsdWVCYXNlPiByZXR1cm5WYWx1ZXMgPSBuZXcgQXJyYXlMaXN0
PFZkY1JldHVyblZhbHVlQmFzZT4oKTsNCisgICAgICAgIEFycmF5TGlzdDxWZGNSZXR1cm5WYWx1
ZUJhc2U+IHJldHVyblZhbHVlcyA9IChBcnJheUxpc3Q8VmRjUmV0dXJuVmFsdWVCYXNlPikgQ29s
bGVjdGlvbnMuc3luY2hyb25pemVkTGlzdChuZXcgQXJyYXlMaXN0PFZkY1JldHVyblZhbHVlQmFz
ZT4oKSk7DQogICAgICAgICB0cnkgew0KICAgICAgICAgICAgIFZkY1JldHVyblZhbHVlQmFzZSBy
ZXR1cm5WYWx1ZTsNCiAgICAgICAgICAgICBmb3IgKFZkY0FjdGlvblBhcmFtZXRlcnNCYXNlIHBh
cmFtZXRlciA6IGdldFBhcmFtZXRlcnMoKSkgew0KQEAgLTg4LDEyICs4OSwxMiBAQCBwdWJsaWMg
Y2xhc3MgTXVsdGlwbGVBY3Rpb25zUnVubmVyIHsNCiAgICAgICAgICAgICB9DQogDQogICAgICAg
ICAgICAgaWYgKGNhblJ1bkFjdGlvbnMpIHsNCi0gICAgICAgICAgICAgICAgVGhyZWFkUG9vbFV0
aWwuZXhlY3V0ZShuZXcgUnVubmFibGUoKSB7DQotICAgICAgICAgICAgICAgICAgICBAT3ZlcnJp
ZGUNCi0gICAgICAgICAgICAgICAgICAgIHB1YmxpYyB2b2lkIHJ1bigpIHsNCi0gICAgICAgICAg
ICAgICAgICAgICAgICBSdW5Db21tYW5kcygpOw0KLSAgICAgICAgICAgICAgICAgICAgfQ0KLSAg
ICAgICAgICAgICAgICB9KTsNCisvLyAgICAgICAgICAgICAgICBUaHJlYWRQb29sVXRpbC5leGVj
dXRlKG5ldyBSdW5uYWJsZSgpIHsNCisvLyAgICAgICAgICAgICAgICAgICAgQE92ZXJyaWRlDQor
Ly8gICAgICAgICAgICAgICAgICAgIHB1YmxpYyB2b2lkIHJ1bigpIHsNCisgICAgICAgICAgICAg
ICAgICAgICAgICBSdW5Db21tYW5kcyhyZXR1cm5WYWx1ZXMpOw0KKy8vICAgICAgICAgICAgICAg
ICAgICB9DQorLy8gICAgICAgICAgICAgICAgfSk7DQogICAgICAgICAgICAgfQ0KICAgICAgICAg
fSBjYXRjaCAoUnVudGltZUV4Y2VwdGlvbiBlKSB7DQogICAgICAgICAgICAgbG9nLmVycm9yKCJG
YWlsZWQgdG8gZXhlY3V0ZSBtdWx0aXBsZSBhY3Rpb25zIG9mIHR5cGU6ICIgKyBfYWN0aW9uVHlw
ZSwgZSk7DQpAQCAtMTMyLDYgKzEzMywxNiBAQCBwdWJsaWMgY2xhc3MgTXVsdGlwbGVBY3Rpb25z
UnVubmVyIHsNCiAgICAgICAgIH07DQogICAgIH0NCiANCisgICAgcHJvdGVjdGVkIENhbGxhYmxl
PFZkY1JldHVyblZhbHVlQmFzZT4gYnVpbGRBY3Rpb25Bc3luYyhmaW5hbCBDb21tYW5kQmFzZTw/
PiBjb21tYW5kKSB7DQorICAgICAgICByZXR1cm4gbmV3IENhbGxhYmxlPFZkY1JldHVyblZhbHVl
QmFzZT4oKSB7DQorDQorICAgICAgICAgICAgQE92ZXJyaWRlDQorICAgICAgICAgICAgcHVibGlj
IFZkY1JldHVyblZhbHVlQmFzZSBjYWxsKCkgew0KKyAgICAgICAgICAgICAgICByZXR1cm4gZXhl
Y3V0ZVZhbGlkYXRlZENvbW1hbmQyKGNvbW1hbmQpOw0KKyAgICAgICAgICAgIH0NCisgICAgICAg
IH07DQorICAgIH0NCisNCiAgICAgcHJvdGVjdGVkIFZkY1JldHVyblZhbHVlQmFzZSBydW5DYW5E
b0FjdGlvbk9ubHkoZmluYWwgaW50IGN1cnJlbnRDYW5Eb0FjdGlvbklkLCBmaW5hbCBpbnQgdG90
YWxTaXplKSB7DQogICAgICAgICBDb21tYW5kQmFzZTw/PiBjb21tYW5kID0gZ2V0Q29tbWFuZHMo
KS5nZXQoY3VycmVudENhbkRvQWN0aW9uSWQpOw0KICAgICAgICAgU3RyaW5nIGFjdGlvblR5cGUg
PSBjb21tYW5kLmdldEFjdGlvblR5cGUoKS50b1N0cmluZygpOw0KQEAgLTE1OCw2ICsxNjksMTYg
QEAgcHVibGljIGNsYXNzIE11bHRpcGxlQWN0aW9uc1J1bm5lciB7DQogICAgICAgICB9DQogICAg
IH0NCiANCisgICAgcHJvdGVjdGVkIHZvaWQgUnVuQ29tbWFuZHMoQXJyYXlMaXN0PFZkY1JldHVy
blZhbHVlQmFzZT4gcmV0dXJuVmFsdWVzKSB7DQorICAgICAgICBMaXN0PENhbGxhYmxlPFZkY1Jl
dHVyblZhbHVlQmFzZT4+IGFjdGlvblRhc2tzID0gbmV3IEFycmF5TGlzdDxDYWxsYWJsZTxWZGNS
ZXR1cm5WYWx1ZUJhc2U+PigpOw0KKyAgICAgICAgZm9yIChDb21tYW5kQmFzZTw/PiBjb21tYW5k
IDogZ2V0Q29tbWFuZHMoKSkgew0KKyAgICAgICAgICAgIGlmIChjb21tYW5kLmdldFJldHVyblZh
bHVlKCkuZ2V0Q2FuRG9BY3Rpb24oKSkgew0KKyAgICAgICAgICAgICAgICBhY3Rpb25UYXNrcy5h
ZGQoYnVpbGRBY3Rpb25Bc3luYyhjb21tYW5kKSk7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAg
fQ0KKyAgICAgICAgcmV0dXJuVmFsdWVzLmFkZEFsbChUaHJlYWRQb29sVXRpbC5pbnZva2VBbGwo
YWN0aW9uVGFza3MpKTsNCisgICAgfQ0KKw0KICAgICAvKioNCiAgICAgICogRXhlY3V0ZXMgY29t
bWFuZHMgd2hpY2ggcGFzc2VkIHZhbGlkYXRpb24gYW5kIGNyZWF0ZXMgbW9uaXRvcmluZyBvYmpl
Y3RzLg0KICAgICAgKg0KQEAgLTE3NSw2ICsxOTYsMTcgQEAgcHVibGljIGNsYXNzIE11bHRpcGxl
QWN0aW9uc1J1bm5lciB7DQogICAgICAgICBjb21tYW5kLmV4ZWN1dGVBY3Rpb24oKTsNCiAgICAg
fQ0KIA0KKyAgICBwcm90ZWN0ZWQgVmRjUmV0dXJuVmFsdWVCYXNlIGV4ZWN1dGVWYWxpZGF0ZWRD
b21tYW5kMihDb21tYW5kQmFzZTw/PiBjb21tYW5kKSB7DQorICAgICAgICBpZiAoZXhlY3V0aW9u
Q29udGV4dCA9PSBudWxsIHx8IGV4ZWN1dGlvbkNvbnRleHQuaXNNb25pdG9yZWQoKSkgew0KKyAg
ICAgICAgICAgIEV4ZWN1dGlvbkhhbmRsZXIucHJlcGFyZUNvbW1hbmRGb3JNb25pdG9yaW5nKGNv
bW1hbmQsDQorICAgICAgICAgICAgICAgICAgICBjb21tYW5kLmdldEFjdGlvblR5cGUoKSwNCisg
ICAgICAgICAgICAgICAgICAgIGNvbW1hbmQuaXNJbnRlcm5hbEV4ZWN1dGlvbigpKTsNCisgICAg
ICAgIH0NCisgICAgICAgIFRocmVhZExvY2FsUGFyYW1zQ29udGFpbmVyLnNldENvcnJlbGF0aW9u
SWQoY29tbWFuZC5nZXRDb3JyZWxhdGlvbklkKCkpOw0KKyAgICAgICAgY29tbWFuZC5pbnNlcnRB
c3luY1Rhc2tQbGFjZUhvbGRlcnMoKTsNCisgICAgICAgIHJldHVybiBjb21tYW5kLmV4ZWN1dGVB
Y3Rpb24oKTsNCisgICAgfQ0KKw0KICAgICBwdWJsaWMgdm9pZCBzZXRFeGVjdXRpb25Db250ZXh0
KEV4ZWN1dGlvbkNvbnRleHQgZXhlY3V0aW9uQ29udGV4dCkgew0KICAgICAgICAgdGhpcy5leGVj
dXRpb25Db250ZXh0ID0gZXhlY3V0aW9uQ29udGV4dDsNCiAgICAgfQ0K
------=_Part_22230002_1751095465.1384256418493--
11 years
