[Engine-devel] oVirt UI Plugins: Update on current progress
Hi guys,<br><br>I've spent some time working on UI Plugins proof-of-concep= t (PoC) implementation, and thought I'd share my results with you. I've att= ached a patch that reflects the current progress. <br><br>The actual PoC im=
</li></ul><p>The current PoC declares a simple plugin that gets loaded usi= ng hard-coded values in <span style=3D"font-style: italic;">PluginSourcePag= eServlet</span>. Actual plugin code registers the plugin into global <span =
--=_156c716f-6003-47a3-bcaa-20301ab51501 Content-Type: multipart/alternative; boundary="=_1a8d4419-a4c3-4d94-96e2-c9d519481224" --=_1a8d4419-a4c3-4d94-96e2-c9d519481224 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi guys, I've spent some time working on UI Plugins proof-of-concept (PoC) implement= ation, and thought I'd share my results with you. I've attached a patch tha= t reflects the current progress. The actual PoC implementation takes some inspiration from oVirt UI Plugins = wiki page, and simplifies/streamlines/improves its main concepts. The goal = is to have simple-to-use, yet flexible and robust plugin infrastructure. Ma= jor changes to the original design are outlined below. Each UI plugin runs within the context of an iframe, and therefore requires= a plugin source page that executes the actual plugin code. =E2=80=A2 iframe is essentially the sandbox for each plugin. We can dis= able plugins by detaching their iframe elements from the main document duri= ng WebAdmin runtime. This also allows us to implement features such as plug= in safe mode (no plugins loaded on WebAdmin startup). =E2=80=A2 Plugin source pages and WebAdmin host page share the same ori= gin (protocol, domain, port), with plugin source pages being served through= EngineManager application server (JBoss AS). This is to avoid cross-domain= window/iframe communication issues, when the actual plugin code running in= an iframe tries to register itself into WebAdmin main document's pluginApi= object. =E2=80=A2 There's a servlet designed to render plugin source page for a= ll plugins ( PluginSourcePageServlet ). For the given plugin, it detects it= s dependencies (3rd party JavaScript libraries) and configuration object (J= SON data), reads the actual plugin code, and assembles everything into the = resulting HTML page (to be evaluated by the plugin iframe). =E2=80=A2 iframe isolates plugin dependencies (3rd party JavaScript lib= raries) from other plugins and the main WebAdmin document. In practice, thi= s means that plugin A can use jQuery 1.7 and plugin B can use jQuery 1.6 wi= thout the fear of any clashes. =E2=80=A2 Last but not least, writing plugins in Google Web Toolkit (GW= T) should be as easy as providing your own plugin source page. Just deploy = your GWT plugin application on JBoss AS (next to engine.ear ), and point to= GWT plugin application host page. The current PoC declares a simple plugin that gets loaded using hard-coded = values in PluginSourcePageServlet . Actual plugin code registers the plugin= into global pluginApi.plugins object, with one sample event handler functi= on ( ActionButtonClick ). Just after that, the plugin reports in as ready b= y calling pluginApi.ready function. This essentially puts the plugin into u= se within WebAdmin. To simulate extension point (application event to be consumed by plugins), = when the user clicks "New server" button on "Virtual Machines" main tab, Ac= tionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHand= ler receives this event and invokes ActionButtonClick event handler functio= n on all plugins. (Note: for passing context objects from WebAdmin to plugin event handler fu= nctions, I'm planning to experiment with gwt-exporter project [1]. This wou= ld greatly simplify the way how WebAdmin exposes context-specific plugin AP= I to event handler functions.) As for the next step, I suggest to have some meeting (conference) to discus= s the PoC in detail, and outline tasks for the near future. Also, please le= t me know what you think of the PoC so far. Cheers, Vojtech [1] http://code.google.com/p/gwt-exporter/ --=_1a8d4419-a4c3-4d94-96e2-c9d519481224 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= plementation takes some inspiration from oVirt UI Plugins wiki page, and si= mplifies/streamlines/improves its main concepts. The goal is to have simple= -to-use, yet flexible and robust plugin infrastructure. Major changes to th= e original design are outlined below.<br><br><strong>Each UI plugin runs wi= thin the context of an iframe, and therefore requires a </strong><span styl= e=3D"font-style: italic; font-weight: bold;">plugin source page</span><span= style=3D"font-weight: bold;"> that executes the actual plugin code.</span>= <br><ul><li>iframe is essentially the sandbox for each plugin. We can disab= le plugins by detaching their iframe elements from the main document during= WebAdmin runtime. This also allows us to implement features such as <em>pl= ugin safe mode</em> (no plugins loaded on WebAdmin startup).</li><li>Plugin= source pages and WebAdmin host page share the same origin (protocol, domai= n, port), with plugin source pages being served through EngineManager appli= cation server (JBoss AS). This is to avoid cross-domain window/iframe commu= nication issues, when the actual plugin code running in an iframe tries to = register itself into WebAdmin main document's <span style=3D"font-style: it= alic;">pluginApi</span> object.</li><li>There's a servlet designed to rende= r plugin source page for all plugins (<span style=3D"font-style: italic;">P= luginSourcePageServlet</span>). For the given plugin, it detects its depend= encies (3rd party JavaScript libraries) and configuration object (JSON data= ), reads the actual plugin code, and assembles everything into the resultin= g HTML page (to be evaluated by the plugin iframe).</li><li>iframe isolates= plugin dependencies (3rd party JavaScript libraries) from other plugins an= d the main WebAdmin document. In practice, this means that plugin A can use= jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes= .</li><li>Last but not least, writing plugins in Google Web Toolkit (GWT) s= hould be as easy as providing your own plugin source page. Just deploy your= GWT plugin application on JBoss AS (next to <span style=3D"font-style: ita= lic;">engine.ear</span>), and point to GWT plugin application host page.<br= style=3D"font-style: italic;">pluginApi.plugins</span> object, with one sam= ple event handler function (<span style=3D"font-style: italic;">ActionButto= nClick</span>). Just after that, the plugin reports in as ready by calling = <span style=3D"font-style: italic;">pluginApi.ready</span> function. This e= ssentially puts the plugin into use within WebAdmin.<br></p><p><br></p>To s= imulate extension point (application event to be consumed by plugins), when= the user clicks "New server" button on "Virtual Machines" main tab, <span = style=3D"font-style: italic;">ActionButtonClickEvent</span> gets fired thro= ugh WebAdmin event bus. <span style=3D"font-style: italic;">PluginEventHand= ler</span> receives this event and invokes <span style=3D"font-style: itali= c;">ActionButtonClick</span> event handler function on all plugins.<br><p><= br></p><p>(Note: for passing context objects from WebAdmin to plugin event = handler functions, I'm planning to experiment with gwt-exporter project [1]= . This would greatly simplify the way how WebAdmin exposes context-specific= plugin API to event handler functions.)</p><p><br></p><p>As for the next s= tep, I suggest to have some meeting (conference) to discuss the PoC in deta= il, and outline tasks for the near future. Also, please let me know what yo= u think of the PoC so far.<br></p><br>Cheers,<br>Vojtech<br><br>[1] http://= code.google.com/p/gwt-exporter/<p><br></p><p></p></div></body></html> --=_1a8d4419-a4c3-4d94-96e2-c9d519481224-- --=_156c716f-6003-47a3-bcaa-20301ab51501 Content-Type: text/x-patch; name=WIP-UI-Plugins-PoC.patch Content-Disposition: attachment; filename=WIP-UI-Plugins-PoC.patch Content-Transfer-Encoding: base64 RnJvbSA5NGM0NThkYzk4NThlZTcyMjBhY2Y1MzMyNDU0NGI5ODE0MGM3NTJhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBWb2p0ZWNoIFN6b2NzIDx2c3pvY3NAcmVkaGF0LmNvbT4KRGF0 ZTogVGh1LCAxOSBKdWwgMjAxMiAxNDo0ODo0MCArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIFdJUDog VUkgUGx1Z2lucyBQb0MKCkNoYW5nZS1JZDogSWQyODgxMmRkYmU5MDU3NGRlMDE3OGYwYzA3ZGE3 MTNmZTlmZDhjZGEKU2lnbmVkLW9mZi1ieTogVm9qdGVjaCBTem9jcyA8dnN6b2NzQHJlZGhhdC5j b20+Ci0tLQogLi4uL3NlcnZlci9nd3QvUGx1Z2luU291cmNlUGFnZVNlcnZsZXQuamF2YSAgICAg ICAgfCAgIDQxICsrKysrKwogLi4uL3NlcnZlci9nd3QvV2ViYWRtaW5EeW5hbWljSG9zdGluZ1Nl cnZsZXQuamF2YSAgfCAgICA0ICsKIC4uLi9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vZ2luL1N5 c3RlbU1vZHVsZS5qYXZhIHwgICAgNCArCiAuLi4vdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkFw aU1hbmFnZXIuamF2YSAgICAgICB8ICAxNDMgKysrKysrKysrKysrKysrKysrKysKIC4uLi91aS93 ZWJhZG1pbi9wbHVnaW4vUGx1Z2luRGVmaW5pdGlvbnMuamF2YSAgICAgIHwgICAzMCArKysrCiAu Li4vdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkV2ZW50SGFuZGxlci5qYXZhICAgICB8ICAgMjQg KysrKwogLi4uL3dlYmFkbWluL3BsdWdpbi9ldmVudC9BY3Rpb25CdXR0b25DbGljay5qYXZhICAg fCAgICA4ICsKIC4uLi9tYWluL3ZpZXcvdGFiL01haW5UYWJWaXJ0dWFsTWFjaGluZVZpZXcuamF2 YSAgIHwgICAgOCArCiAuLi4vd2ViYWRtaW4vc3JjL21haW4vd2ViYXBwL1dFQi1JTkYvd2ViLnht bCAgICAgICB8ICAgMTAgKysKIDkgZmlsZXMgY2hhbmdlZCwgMjcyIGluc2VydGlvbnMoKyksIDAg ZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxl cy9mcm9udGVuZC9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvZnJvbnRlbmQvc2Vy dmVyL2d3dC9QbHVnaW5Tb3VyY2VQYWdlU2VydmxldC5qYXZhCiBjcmVhdGUgbW9kZSAxMDA2NDQg ZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmly dC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkFwaU1hbmFnZXIuamF2YQogY3JlYXRl IG1vZGUgMTAwNjQ0IGZyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4v amF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5EZWZpbml0aW9u cy5qYXZhCiBjcmVhdGUgbW9kZSAxMDA2NDQgZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJh ZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL1Bs dWdpbkV2ZW50SGFuZGxlci5qYXZhCiBjcmVhdGUgbW9kZSAxMDA2NDQgZnJvbnRlbmQvd2ViYWRt aW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2Vi YWRtaW4vcGx1Z2luL2V2ZW50L0FjdGlvbkJ1dHRvbkNsaWNrLmphdmEKCmRpZmYgLS1naXQgYS9m cm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL2Zyb250ZW5kL3NyYy9tYWluL2phdmEvb3JnL292aXJ0 L2VuZ2luZS91aS9mcm9udGVuZC9zZXJ2ZXIvZ3d0L1BsdWdpblNvdXJjZVBhZ2VTZXJ2bGV0Lmph dmEgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL2Zyb250ZW5kL3NyYy9tYWluL2phdmEvb3Jn L292aXJ0L2VuZ2luZS91aS9mcm9udGVuZC9zZXJ2ZXIvZ3d0L1BsdWdpblNvdXJjZVBhZ2VTZXJ2 bGV0LmphdmEKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uYzQwOGQ4ZQotLS0g L2Rldi9udWxsCisrKyBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvZnJvbnRlbmQvc3JjL21h aW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL2Zyb250ZW5kL3NlcnZlci9nd3QvUGx1Z2luU291 cmNlUGFnZVNlcnZsZXQuamF2YQpAQCAtMCwwICsxLDQxIEBACitwYWNrYWdlIG9yZy5vdmlydC5l bmdpbmUudWkuZnJvbnRlbmQuc2VydmVyLmd3dDsKKworaW1wb3J0IGphdmEuaW8uSU9FeGNlcHRp b247CitpbXBvcnQgamF2YS5pby5QcmludFdyaXRlcjsKKworaW1wb3J0IGphdmF4LnNlcnZsZXQu aHR0cC5IdHRwU2VydmxldDsKK2ltcG9ydCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0cFNlcnZsZXRS ZXF1ZXN0OworaW1wb3J0IGphdmF4LnNlcnZsZXQuaHR0cC5IdHRwU2VydmxldFJlc3BvbnNlOwor CisvKioKKyAqIFJlbmRlcnMgdGhlIEhUTUwgc291cmNlIHBhZ2UgZm9yIHRoZSBnaXZlbiBVSSBw bHVnaW4uCisgKi8KK3B1YmxpYyBjbGFzcyBQbHVnaW5Tb3VyY2VQYWdlU2VydmxldCBleHRlbmRz IEh0dHBTZXJ2bGV0IHsKKworICAgIHByaXZhdGUgc3RhdGljIGZpbmFsIGxvbmcgc2VyaWFsVmVy c2lvblVJRCA9IDFMOworCisgICAgQE92ZXJyaWRlCisgICAgcHJvdGVjdGVkIHZvaWQgZG9HZXQo SHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9uc2UgcmVzcG9uc2Up IHRocm93cyBJT0V4Y2VwdGlvbiB7CisgICAgICAgIFByaW50V3JpdGVyIHdyaXRlciA9IHJlc3Bv bnNlLmdldFdyaXRlcigpOworICAgICAgICByZXNwb25zZS5zZXRDb250ZW50VHlwZSgidGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Iik7IC8vJE5PTi1OTFMtMSQKKworICAgICAgICB3cml0ZXIuYXBw ZW5kKCI8IURPQ1RZUEUgaHRtbD48aHRtbD48aGVhZD4iKTsgLy8kTk9OLU5MUy0xJAorICAgICAg ICB3cml0ZXIuYXBwZW5kKCI8bWV0YSBodHRwLWVxdWl2PVwiY29udGVudC10eXBlXCIgY29udGVu dD1cInRleHQvaHRtbDsgY2hhcnNldD1VVEYtOFwiPiIpOyAvLyROT04tTkxTLTEkCisgICAgICAg IHdyaXRlci5hcHBlbmQoIjxzY3JpcHQgdHlwZT1cInRleHQvamF2YXNjcmlwdFwiIHNyYz1cImh0 dHBzOi8vYWpheC5nb29nbGVhcGlzLmNvbS9hamF4L2xpYnMvanF1ZXJ5LzEuNy4yL2pxdWVyeS5t aW4uanNcIj48L3NjcmlwdD4iKTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3cml0ZXIuYXBwZW5k KCI8L2hlYWQ+PGJvZHk+Iik7IC8vJE5PTi1OTFMtMSQKKworICAgICAgICB3cml0ZXIuYXBwZW5k KCI8c2NyaXB0IHR5cGU9XCJ0ZXh0L2phdmFzY3JpcHRcIj4iKTsgLy8kTk9OLU5MUy0xJAorICAg ICAgICB3cml0ZXIuYXBwZW5kKCIoZnVuY3Rpb24oIHBsdWdpbkFwaSwgcGx1Z2luQ29uZmlnICkg eyIpOyAvLyROT04tTkxTLTEkCisgICAgICAgIHdyaXRlci5hcHBlbmQoIiAgd2luZG93LmFsZXJ0 KCdJbnZva2luZyBhY3R1YWwgcGx1Z2luIGNvZGUhJyk7Iik7IC8vJE5PTi1OTFMtMSQKKyAgICAg ICAgd3JpdGVyLmFwcGVuZCgiICB3aW5kb3cuYWxlcnQoJ1JlYWRpbmcgcGx1Z2luIGNvbmZpZ3Vy YXRpb246ICcgKyBwbHVnaW5Db25maWcuZm9vKTsiKTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3 cml0ZXIuYXBwZW5kKCIgIHBsdWdpbkFwaS5wbHVnaW5zWydteVBsdWdpbiddID0geyIpOyAvLyRO T04tTkxTLTEkCisgICAgICAgIHdyaXRlci5hcHBlbmQoIiAgICBBY3Rpb25CdXR0b25DbGljazog ZnVuY3Rpb24oY29udGV4dE9iamVjdCkgeyB3aW5kb3cuYWxlcnQoJ1dvb2hvbyEnKTsgfSIpOyAv LyROT04tTkxTLTEkCisgICAgICAgIHdyaXRlci5hcHBlbmQoIiAgfTsiKTsgLy8kTk9OLU5MUy0x JAorICAgICAgICB3cml0ZXIuYXBwZW5kKCIgIHBsdWdpbkFwaS5yZWFkeSgnbXlQbHVnaW4nKTsi KTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3cml0ZXIuYXBwZW5kKCJ9KSAoIHBhcmVudC5wbHVn aW5BcGksIHsgXCJmb29cIjogMTIzIH0gKTsiKTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3cml0 ZXIuYXBwZW5kKCI8L3NjcmlwdD4iKTsgLy8kTk9OLU5MUy0xJAorCisgICAgICAgIHdyaXRlci5h cHBlbmQoIjwvYm9keT48L2h0bWw+Iik7IC8vJE5PTi1OTFMtMSQKKyAgICB9CisKK30KZGlmZiAt LWdpdCBhL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvZnJvbnRlbmQvc3JjL21haW4vamF2YS9v cmcvb3ZpcnQvZW5naW5lL3VpL2Zyb250ZW5kL3NlcnZlci9nd3QvV2ViYWRtaW5EeW5hbWljSG9z dGluZ1NlcnZsZXQuamF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvZnJvbnRlbmQvc3Jj L21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL2Zyb250ZW5kL3NlcnZlci9nd3QvV2ViYWRt aW5EeW5hbWljSG9zdGluZ1NlcnZsZXQuamF2YQppbmRleCA0MjhkY2M1Li5kY2FmNDlhIDEwMDY0 NAotLS0gYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL2Zyb250ZW5kL3NyYy9tYWluL2phdmEv b3JnL292aXJ0L2VuZ2luZS91aS9mcm9udGVuZC9zZXJ2ZXIvZ3d0L1dlYmFkbWluRHluYW1pY0hv c3RpbmdTZXJ2bGV0LmphdmEKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy9mcm9udGVu ZC9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvZnJvbnRlbmQvc2VydmVyL2d3dC9X ZWJhZG1pbkR5bmFtaWNIb3N0aW5nU2VydmxldC5qYXZhCkBAIC0zNiw2ICszNiwxMCBAQCBwdWJs aWMgY2xhc3MgV2ViYWRtaW5EeW5hbWljSG9zdGluZ1NlcnZsZXQgZXh0ZW5kcyBHd3REeW5hbWlj SG9zdFBhZ2VTZXJ2bGV0IHsKICAgICAgICAgICAgIGFwcE1vZGVEYXRhLnB1dCgidmFsdWUiLCBT dHJpbmcudmFsdWVPZihhcHBsaWNhdGlvbk1vZGUpKTsgLy8kTk9OLU5MUy0xJAogICAgICAgICAg ICAgd3JpdGVKc09iamVjdCh3cml0ZXIsICJhcHBsaWNhdGlvbk1vZGUiLCBhcHBNb2RlRGF0YSk7 IC8vJE5PTi1OTFMtMSQKICAgICAgICAgfQorCisgICAgICAgIE1hcDxTdHJpbmcsIFN0cmluZz4g cGx1Z2luRGVmaW5pdGlvbnMgPSBuZXcgSGFzaE1hcDxTdHJpbmcsIFN0cmluZz4oKTsKKyAgICAg ICAgcGx1Z2luRGVmaW5pdGlvbnMucHV0KCJteVBsdWdpbiIsICIvd2ViYWRtaW4vd2ViYWRtaW4v UGx1Z2luU291cmNlUGFnZT9wbHVnaW49bXlQbHVnaW4iKTsgLy8kTk9OLU5MUy0xJCAvLyROT04t TkxTLTIkCisgICAgICAgIHdyaXRlSnNPYmplY3Qod3JpdGVyLCAicGx1Z2luRGVmaW5pdGlvbnMi LCBwbHVnaW5EZWZpbml0aW9ucyk7IC8vJE5PTi1OTFMtMSQKICAgICB9CiAKICAgICBwcml2YXRl IEludGVnZXIgZ2V0QXBwbGljYXRpb25Nb2RlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KSB7 CmRpZmYgLS1naXQgYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWlu L2phdmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9naW4vU3lzdGVtTW9kdWxlLmphdmEg Yi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292 aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9naW4vU3lzdGVtTW9kdWxlLmphdmEKaW5kZXggMzA2OWI5 OS4uNzg5NjNhZCAxMDA2NDQKLS0tIGEvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1p bi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vZ2luL1N5c3RlbU1v ZHVsZS5qYXZhCisrKyBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21h aW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL2dpbi9TeXN0ZW1Nb2R1bGUuamF2 YQpAQCAtOSw2ICs5LDggQEAgaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4uQXBw bGljYXRpb25SZXNvdXJjZXM7CiBpbXBvcnQgb3JnLm92aXJ0LmVuZ2luZS51aS53ZWJhZG1pbi5B cHBsaWNhdGlvblRlbXBsYXRlczsKIGltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFkbWlu LnBsYWNlLkFwcGxpY2F0aW9uUGxhY2VzOwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2Vi YWRtaW4ucGxhY2UuV2ViQWRtaW5QbGFjZU1hbmFnZXI7CitpbXBvcnQgb3JnLm92aXJ0LmVuZ2lu ZS51aS53ZWJhZG1pbi5wbHVnaW4uUGx1Z2luQXBpTWFuYWdlcjsKK2ltcG9ydCBvcmcub3ZpcnQu ZW5naW5lLnVpLndlYmFkbWluLnBsdWdpbi5QbHVnaW5FdmVudEhhbmRsZXI7CiBpbXBvcnQgb3Jn Lm92aXJ0LmVuZ2luZS51aS53ZWJhZG1pbi5zeXN0ZW0uQXBwbGljYXRpb25Jbml0OwogaW1wb3J0 IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4uc3lzdGVtLkludGVybmFsQ29uZmlndXJhdGlv bjsKIApAQCAtMzEsNiArMzMsOCBAQCBwdWJsaWMgY2xhc3MgU3lzdGVtTW9kdWxlIGV4dGVuZHMg QmFzZVN5c3RlbU1vZHVsZSB7CiAgICAgICAgIGJpbmQoUGxhY2VNYW5hZ2VyLmNsYXNzKS50byhX ZWJBZG1pblBsYWNlTWFuYWdlci5jbGFzcykuaW4oU2luZ2xldG9uLmNsYXNzKTsKICAgICAgICAg YmluZChBcHBsaWNhdGlvbkluaXQuY2xhc3MpLmFzRWFnZXJTaW5nbGV0b24oKTsKICAgICAgICAg YmluZChJbnRlcm5hbENvbmZpZ3VyYXRpb24uY2xhc3MpLmFzRWFnZXJTaW5nbGV0b24oKTsKKyAg ICAgICAgYmluZChQbHVnaW5BcGlNYW5hZ2VyLmNsYXNzKS5hc0VhZ2VyU2luZ2xldG9uKCk7Cisg ICAgICAgIGJpbmQoUGx1Z2luRXZlbnRIYW5kbGVyLmNsYXNzKS5hc0VhZ2VyU2luZ2xldG9uKCk7 CiAgICAgfQogCiAgICAgdm9pZCBiaW5kQ29uZmlndXJhdGlvbigpIHsKZGlmZiAtLWdpdCBhL2Zy b250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4vamF2YS9vcmcvb3ZpcnQv ZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5BcGlNYW5hZ2VyLmphdmEgYi9mcm9udGVu ZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2lu ZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luQXBpTWFuYWdlci5qYXZhCm5ldyBmaWxlIG1vZGUg MTAwNjQ0CmluZGV4IDAwMDAwMDAuLjBiYmRkNjgKLS0tIC9kZXYvbnVsbAorKysgYi9mcm9udGVu ZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2lu ZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luQXBpTWFuYWdlci5qYXZhCkBAIC0wLDAgKzEsMTQz IEBACitwYWNrYWdlIG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4ucGx1Z2luOworCitpbXBv cnQgamF2YS51dGlsLkhhc2hNYXA7CitpbXBvcnQgamF2YS51dGlsLk1hcDsKK2ltcG9ydCBqYXZh LnV0aWwubG9nZ2luZy5Mb2dnZXI7CisKK2ltcG9ydCBjb20uZ29vZ2xlLmd3dC5jb3JlLmNsaWVu dC5KYXZhU2NyaXB0T2JqZWN0OworaW1wb3J0IGNvbS5nb29nbGUuZ3d0LmNvcmUuY2xpZW50Lkpz QXJyYXlTdHJpbmc7CitpbXBvcnQgY29tLmdvb2dsZS5nd3QuZG9tLmNsaWVudC5Eb2N1bWVudDsK K2ltcG9ydCBjb20uZ29vZ2xlLmd3dC5kb20uY2xpZW50LklGcmFtZUVsZW1lbnQ7CitpbXBvcnQg Y29tLmdvb2dsZS5nd3QuZG9tLmNsaWVudC5TdHlsZS5Cb3JkZXJTdHlsZTsKK2ltcG9ydCBjb20u Z29vZ2xlLmd3dC5kb20uY2xpZW50LlN0eWxlLlBvc2l0aW9uOworaW1wb3J0IGNvbS5nb29nbGUu Z3d0LmRvbS5jbGllbnQuU3R5bGUuVW5pdDsKKworLyoqCisgKiBUaGUgbWFpbiBjb21wb25lbnQg b2YgV2ViQWRtaW4gVUkgcGx1Z2luIGluZnJhc3RydWN0dXJlLgorICogPHA+CisgKiBTaG91bGQg YmUgYm91bmQgYXMgR0lOIGVhZ2VyIHNpbmdsZXRvbiwgY3JlYXRlZCBlYXJseSBvbiBkdXJpbmcg YXBwbGljYXRpb24gc3RhcnR1cC4KKyAqLworcHVibGljIGNsYXNzIFBsdWdpbkFwaU1hbmFnZXIg eworCisgICAgcHJpdmF0ZSBzdGF0aWMgZmluYWwgTG9nZ2VyIGxvZ2dlciA9IExvZ2dlci5nZXRM b2dnZXIoUGx1Z2luQXBpTWFuYWdlci5jbGFzcy5nZXROYW1lKCkpOworCisgICAgLy8gTWFwcyBw bHVnaW4gbmFtZXMgdG8gY29ycmVzcG9uZGluZyBpZnJhbWUgZWxlbWVudHMKKyAgICBwcml2YXRl IGZpbmFsIE1hcDxTdHJpbmcsIElGcmFtZUVsZW1lbnQ+IHBsdWdpbklGcmFtZXMgPSBuZXcgSGFz aE1hcDxTdHJpbmcsIElGcmFtZUVsZW1lbnQ+KCk7CisKKyAgICAvLyBNYXBzIHBsdWdpbiBuYW1l cyB0byBjb3JyZXNwb25kaW5nIHBsdWdpbiBvYmplY3RzIChvbmx5IGZvciBwbHVnaW5zIHdoaWNo IGFyZSBjdXJyZW50bHkgcmVhZHkpCisgICAgcHJpdmF0ZSBmaW5hbCBNYXA8U3RyaW5nLCBKYXZh U2NyaXB0T2JqZWN0PiBwbHVnaW5PYmplY3RzID0gbmV3IEhhc2hNYXA8U3RyaW5nLCBKYXZhU2Ny aXB0T2JqZWN0PigpOworCisgICAgcHVibGljIFBsdWdpbkFwaU1hbmFnZXIoKSB7CisgICAgICAg IGV4cG9zZVBsdWdpbkFwaSgpOworICAgICAgICBsb2FkUGx1Z2lucygpOworICAgIH0KKworICAg IC8qKgorICAgICAqIEludm9rZXMgdGhlIGdpdmVuIGV2ZW50IGhhbmRsZXIgZnVuY3Rpb24gb24g YWxsIHBsdWdpbnMgd2hpY2ggYXJlIGN1cnJlbnRseSByZWFkeS4KKyAgICAgKi8KKyAgICBwdWJs aWMgdm9pZCBpbnZva2VQbHVnaW5zKFN0cmluZyBmdW5jdGlvbk5hbWUsIEphdmFTY3JpcHRPYmpl Y3QgY29udGV4dE9iamVjdCkgeworICAgICAgICBmb3IgKEphdmFTY3JpcHRPYmplY3QgcGx1Z2lu T2JqZWN0IDogcGx1Z2luT2JqZWN0cy52YWx1ZXMoKSkgeworICAgICAgICAgICAgaW52b2tlUGx1 Z2luKHBsdWdpbk9iamVjdCwgZnVuY3Rpb25OYW1lLCBjb250ZXh0T2JqZWN0KTsKKyAgICAgICAg fQorICAgIH0KKworICAgIG5hdGl2ZSB2b2lkIGludm9rZVBsdWdpbihKYXZhU2NyaXB0T2JqZWN0 IHBsdWdpbk9iamVjdCwgU3RyaW5nIGZ1bmN0aW9uTmFtZSwgSmF2YVNjcmlwdE9iamVjdCBjb250 ZXh0T2JqZWN0KSAvKi17CisgICAgICAgIGlmIChjb250ZXh0T2JqZWN0ICE9IG51bGwpIHsKKyAg ICAgICAgICAgIHBsdWdpbk9iamVjdFtmdW5jdGlvbk5hbWVdKGNvbnRleHRPYmplY3QpOworICAg ICAgICB9IGVsc2UgeworICAgICAgICAgICAgcGx1Z2luT2JqZWN0W2Z1bmN0aW9uTmFtZV0oKTsK KyAgICAgICAgfQorICAgIH0tKi87CisKKyAgICAvKioKKyAgICAgKiBMb2FkcyBhbGwgcGx1Z2lu cyB0aGF0IHdlcmUgZGV0ZWN0ZWQgd2hlbiBzZXJ2aW5nIFdlYkFkbWluIGhvc3QgcGFnZS4KKyAg ICAgKi8KKyAgICB2b2lkIGxvYWRQbHVnaW5zKCkgeworICAgICAgICBQbHVnaW5EZWZpbml0aW9u cyBkZWZzID0gUGx1Z2luRGVmaW5pdGlvbnMuaW5zdGFuY2UoKTsKKworICAgICAgICBpZiAoZGVm cyAhPSBudWxsKSB7CisgICAgICAgICAgICBKc0FycmF5U3RyaW5nIHBsdWdpbk5hbWVzID0gZGVm cy5nZXRQbHVnaW5OYW1lcygpOworCisgICAgICAgICAgICBmb3IgKGludCBpID0gMDsgaSA8IHBs dWdpbk5hbWVzLmxlbmd0aCgpOyBpKyspIHsKKyAgICAgICAgICAgICAgICBTdHJpbmcgbmFtZSA9 IHBsdWdpbk5hbWVzLmdldChpKTsKKyAgICAgICAgICAgICAgICBTdHJpbmcgc291cmNlUGFnZVVy bCA9IGRlZnMuZ2V0UGx1Z2luU291cmNlUGFnZVVybChuYW1lKTsKKworICAgICAgICAgICAgICAg IGxvZ2dlci5pbmZvKCJMb2FkaW5nIHBsdWdpbiBbIiArIG5hbWUgKyAiXSBmcm9tIFVSTCAiICsg c291cmNlUGFnZVVybCk7IC8vJE5PTi1OTFMtMSQgLy8kTk9OLU5MUy0yJAorICAgICAgICAgICAg ICAgIGxvYWRQbHVnaW4obmFtZSwgc291cmNlUGFnZVVybCk7CisgICAgICAgICAgICB9CisgICAg ICAgIH0KKyAgICB9CisKKyAgICAvKioKKyAgICAgKiBMb2FkcyBhIHBsdWdpbiB1c2luZyBpdHMg c291cmNlIHBhZ2UgKEhUTUwgcGFnZSB0aGF0IGV4ZWN1dGVzIHRoZSBhY3R1YWwgcGx1Z2luIGNv ZGUpLgorICAgICAqIDxwPgorICAgICAqIFdlYkFkbWluIHJlcXVpcmVzIGFsbCBwbHVnaW5zIHRv IGhhdmUgYSBzb3VyY2UgcGFnZSBiZWNhdXNlIGVhY2ggcGx1Z2luIHJ1bnMgd2l0aGluIHRoZSBj b250ZXh0IG9mIGFuIGlmcmFtZS4KKyAgICAgKiA8cD4KKyAgICAgKiBOb3RlIHRoYXQgcGx1Z2lu IHNvdXJjZSBwYWdlIFVSTHMgYXJlIGFsd2F5cyByZWxhdGl2ZSB0byBKQm9zcyBzZXJ2ZXIgcm9v dCBwYXRoLiBTb3VyY2UgcGFnZSBVUkxzIG11c3QgdGhlcmVmb3JlCisgICAgICogYWx3YXlzIGJl Z2luIHdpdGggc2xhc2ggKHtAY29kZSAvfSkgY2hhcmFjdGVyLiBUaGlzIGFsbG93cyBXZWJBZG1p biBob3N0IHBhZ2UgYW5kIGluZGl2aWR1YWwgcGx1Z2luIHNvdXJjZSBwYWdlcworICAgICAqIHRv IHNoYXJlIHRoZSBzYW1lIG9yaWdpbiAocHJvdG9jb2wsIGRvbWFpbiwgcG9ydCkgYW5kIGF2b2lk IGNyb3NzLWRvbWFpbiB3aW5kb3cvaWZyYW1lIGNvbW11bmljYXRpb24gaXNzdWVzLgorICAgICAq LworICAgIHZvaWQgbG9hZFBsdWdpbihTdHJpbmcgcGx1Z2luTmFtZSwgU3RyaW5nIHBsdWdpblNv dXJjZVBhZ2VVcmwpIHsKKyAgICAgICAgaWYgKCFwbHVnaW5Tb3VyY2VQYWdlVXJsLnN0YXJ0c1dp dGgoIi8iKSkgeyAvLyROT04tTkxTLTEkCisgICAgICAgICAgICBsb2dnZXIud2FybmluZygiQXR0 ZW1wdGluZyB0byBsb2FkIHBsdWdpbiBbIiArIHBsdWdpbk5hbWUgKyAiXSB1c2luZyBpbnZhbGlk IFVSTCAiICsgcGx1Z2luU291cmNlUGFnZVVybCk7IC8vJE5PTi1OTFMtMSQgLy8kTk9OLU5MUy0y JAorICAgICAgICAgICAgcmV0dXJuOworICAgICAgICB9CisKKyAgICAgICAgaWYgKHBsdWdpbklG cmFtZXMuY29udGFpbnNLZXkocGx1Z2luTmFtZSkpIHsKKyAgICAgICAgICAgIGxvZ2dlci53YXJu aW5nKCJQbHVnaW4gWyIgKyBwbHVnaW5OYW1lICsgIl0gaXMgYWxyZWFkeSBsb2FkZWQiKTsgLy8k Tk9OLU5MUy0xJCAvLyROT04tTkxTLTIkCisgICAgICAgICAgICByZXR1cm47CisgICAgICAgIH0K KworICAgICAgICAvLyBDcmVhdGUgYW4gaWZyYW1lIHVzZWQgdG8gbG9hZCB0aGUgcGx1Z2luIHNv dXJjZSBwYWdlCisgICAgICAgIElGcmFtZUVsZW1lbnQgaWZyYW1lID0gRG9jdW1lbnQuZ2V0KCku Y3JlYXRlSUZyYW1lRWxlbWVudCgpOworICAgICAgICBpZnJhbWUuc2V0U3JjKHBsdWdpblNvdXJj ZVBhZ2VVcmwpOworICAgICAgICBpZnJhbWUuc2V0RnJhbWVCb3JkZXIoMCk7CisgICAgICAgIGlm cmFtZS5nZXRTdHlsZSgpLnNldFBvc2l0aW9uKFBvc2l0aW9uLkFCU09MVVRFKTsKKyAgICAgICAg aWZyYW1lLmdldFN0eWxlKCkuc2V0V2lkdGgoMCwgVW5pdC5QVCk7CisgICAgICAgIGlmcmFtZS5n ZXRTdHlsZSgpLnNldEhlaWdodCgwLCBVbml0LlBUKTsKKyAgICAgICAgaWZyYW1lLmdldFN0eWxl KCkuc2V0Qm9yZGVyU3R5bGUoQm9yZGVyU3R5bGUuTk9ORSk7CisgICAgICAgIHBsdWdpbklGcmFt ZXMucHV0KHBsdWdpbk5hbWUsIGlmcmFtZSk7CisKKyAgICAgICAgLy8gQXR0YWNoIHRoZSBpZnJh bWUgdG8gRE9NIGRvY3VtZW50IGJvZHkKKyAgICAgICAgRG9jdW1lbnQuZ2V0KCkuZ2V0Qm9keSgp LmFwcGVuZENoaWxkKGlmcmFtZSk7CisgICAgfQorCisgICAgLyoqCisgICAgICogSW5kaWNhdGVz IHRoYXQgdGhlIGdpdmVuIHBsdWdpbiBpcyByZWFkeSBmb3IgdXNlLgorICAgICAqIDxwPgorICAg ICAqIE5vdGUgdGhhdCBldmVudCBoYW5kbGVyIGZ1bmN0aW9ucyB3aWxsIGJlIGludm9rZWQgb25s eSBvbiBwbHVnaW5zIHdoaWNoIGFyZSBjdXJyZW50bHkgcmVhZHkuCisgICAgICovCisgICAgdm9p ZCBwbHVnaW5SZWFkeShTdHJpbmcgcGx1Z2luTmFtZSwgSmF2YVNjcmlwdE9iamVjdCBwbHVnaW5P YmplY3QpIHsKKyAgICAgICAgaWYgKHBsdWdpbk5hbWUgPT0gbnVsbCkgeworICAgICAgICAgICAg bG9nZ2VyLndhcm5pbmcoIlBsdWdpbiBuYW1lIGlzIG51bGwgb3IgdW5kZWZpbmVkIik7IC8vJE5P Ti1OTFMtMSQKKyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgfQorCisgICAgICAgIGlmICgh cGx1Z2luSUZyYW1lcy5jb250YWluc0tleShwbHVnaW5OYW1lKSkgeworICAgICAgICAgICAgbG9n Z2VyLndhcm5pbmcoIlBsdWdpbiBbIiArIHBsdWdpbk5hbWUgKyAiXSByZXBvcnRzIGluIGFzIHJl YWR5LCBidXQgaGFzIG5vIGlmcmFtZSBhc3NvY2lhdGVkIik7IC8vJE5PTi1OTFMtMSQgLy8kTk9O LU5MUy0yJAorICAgICAgICAgICAgcmV0dXJuOworICAgICAgICB9CisKKyAgICAgICAgcGx1Z2lu T2JqZWN0cy5wdXQocGx1Z2luTmFtZSwgcGx1Z2luT2JqZWN0KTsKKyAgICB9CisKKyAgICBuYXRp dmUgdm9pZCBleHBvc2VQbHVnaW5BcGkoKSAvKi17CisgICAgICAgIHZhciBpbnN0YW5jZSA9IHRo aXM7CisKKyAgICAgICAgLy8gRXhwb3NlIHRoZSBnbG9iYWwgcGx1Z2luQXBpIG9iamVjdAorICAg ICAgICAkd25kLnBsdWdpbkFwaSA9IHsKKworICAgICAgICAgICAgLy8gUGx1Z2lucyB3aWxsIHJl Z2lzdGVyIHRoZW1zZWx2ZXMgaW50byB0aGlzIG9iamVjdCBieSBhZGRpbmcgbmV3IHByb3BlcnR5 OgorICAgICAgICAgICAgLy8gLSBwcm9wZXJ0eSBuYW1lIGlzIHRoZSBuYW1lIG9mIHRoZSBwbHVn aW4KKyAgICAgICAgICAgIC8vIC0gcHJvcGVydHkgdmFsdWUgaXMgdGhlIHBsdWdpbiBvYmplY3Qg Y29udGFpbmluZyBldmVudCBoYW5kbGVyIGZ1bmN0aW9ucworICAgICAgICAgICAgcGx1Z2luczog e30sCisKKyAgICAgICAgICAgIHJlYWR5OiBmdW5jdGlvbihwbHVnaW5OYW1lKSB7CisgICAgICAg ICAgICAgICAgdmFyIHBsdWdpbk9iamVjdCA9IHRoaXMucGx1Z2luc1twbHVnaW5OYW1lXTsKKyAg ICAgICAgICAgICAgICBpbnN0YW5jZS5Ab3JnLm92aXJ0LmVuZ2luZS51aS53ZWJhZG1pbi5wbHVn aW4uUGx1Z2luQXBpTWFuYWdlcjo6cGx1Z2luUmVhZHkoTGphdmEvbGFuZy9TdHJpbmc7TGNvbS9n b29nbGUvZ3d0L2NvcmUvY2xpZW50L0phdmFTY3JpcHRPYmplY3Q7KShwbHVnaW5OYW1lLHBsdWdp bk9iamVjdCk7CisgICAgICAgICAgICB9CisKKyAgICAgICAgfTsKKyAgICB9LSovOworCit9CmRp ZmYgLS1naXQgYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2ph dmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luRGVmaW5pdGlvbnMu amF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4vamF2YS9v cmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5EZWZpbml0aW9ucy5qYXZh Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmQxMTE4Y2IKLS0tIC9kZXYvbnVs bAorKysgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEv b3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luRGVmaW5pdGlvbnMuamF2 YQpAQCAtMCwwICsxLDMwIEBACitwYWNrYWdlIG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4u cGx1Z2luOworCitpbXBvcnQgY29tLmdvb2dsZS5nd3QuY29yZS5jbGllbnQuSmF2YVNjcmlwdE9i amVjdDsKK2ltcG9ydCBjb20uZ29vZ2xlLmd3dC5jb3JlLmNsaWVudC5Kc0FycmF5U3RyaW5nOwor CisvKioKKyAqIE92ZXJsYXkgdHlwZSBmb3Ige0Bjb2RlIHBsdWdpbkRlZmluaXRpb25zfSBnbG9i YWwgSlMgb2JqZWN0LgorICovCitwdWJsaWMgZmluYWwgY2xhc3MgUGx1Z2luRGVmaW5pdGlvbnMg ZXh0ZW5kcyBKYXZhU2NyaXB0T2JqZWN0IHsKKworICAgIHByb3RlY3RlZCBQbHVnaW5EZWZpbml0 aW9ucygpIHsKKyAgICB9CisKKyAgICBwdWJsaWMgc3RhdGljIG5hdGl2ZSBQbHVnaW5EZWZpbml0 aW9ucyBpbnN0YW5jZSgpIC8qLXsKKyAgICAgICAgcmV0dXJuICR3bmQucGx1Z2luRGVmaW5pdGlv bnM7CisgICAgfS0qLzsKKworICAgIHB1YmxpYyBuYXRpdmUgSnNBcnJheVN0cmluZyBnZXRQbHVn aW5OYW1lcygpIC8qLXsKKyAgICAgICAgdmFyIHBsdWdpbk5hbWVzID0gW107CisgICAgICAgIGZv ciAodmFyIGtleSBpbiB0aGlzKSB7CisgICAgICAgICAgICBwbHVnaW5OYW1lcy5wdXNoKGtleSk7 CisgICAgICAgIH0KKyAgICAgICAgcmV0dXJuIHBsdWdpbk5hbWVzOworICAgIH0tKi87CisKKyAg ICBwdWJsaWMgbmF0aXZlIFN0cmluZyBnZXRQbHVnaW5Tb3VyY2VQYWdlVXJsKFN0cmluZyBwbHVn aW5OYW1lKSAvKi17CisgICAgICAgIHJldHVybiB0aGlzW3BsdWdpbk5hbWVdOworICAgIH0tKi87 CisKK30KZGlmZiAtLWdpdCBhL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3Jj L21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5FdmVu dEhhbmRsZXIuamF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21h aW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5FdmVudEhh bmRsZXIuamF2YQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi45ZjUwMWFjCi0t LSAvZGV2L251bGwKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMv bWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkV2ZW50 SGFuZGxlci5qYXZhCkBAIC0wLDAgKzEsMjQgQEAKK3BhY2thZ2Ugb3JnLm92aXJ0LmVuZ2luZS51 aS53ZWJhZG1pbi5wbHVnaW47CisKK2ltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFkbWlu LnBsdWdpbi5ldmVudC5BY3Rpb25CdXR0b25DbGlja0V2ZW50OworaW1wb3J0IG9yZy5vdmlydC5l bmdpbmUudWkud2ViYWRtaW4ucGx1Z2luLmV2ZW50LkFjdGlvbkJ1dHRvbkNsaWNrRXZlbnQuQWN0 aW9uQnV0dG9uQ2xpY2tIYW5kbGVyOworCitpbXBvcnQgY29tLmdvb2dsZS5nd3QuZXZlbnQuc2hh cmVkLkV2ZW50QnVzOworaW1wb3J0IGNvbS5nb29nbGUuaW5qZWN0LkluamVjdDsKKworLyoqCisg KiBIYW5kbGVzIFdlYkFkbWluIGFwcGxpY2F0aW9uIGV2ZW50cyB0byBiZSBjb25zdW1lZCBieSBV SSBwbHVnaW5zLgorICovCitwdWJsaWMgY2xhc3MgUGx1Z2luRXZlbnRIYW5kbGVyIHsKKworICAg IEBJbmplY3QKKyAgICBwdWJsaWMgUGx1Z2luRXZlbnRIYW5kbGVyKEV2ZW50QnVzIGV2ZW50QnVz LCBmaW5hbCBQbHVnaW5BcGlNYW5hZ2VyIG1hbmFnZXIpIHsKKyAgICAgICAgZXZlbnRCdXMuYWRk SGFuZGxlcihBY3Rpb25CdXR0b25DbGlja0V2ZW50LmdldFR5cGUoKSwgbmV3IEFjdGlvbkJ1dHRv bkNsaWNrSGFuZGxlcigpIHsKKyAgICAgICAgICAgIEBPdmVycmlkZQorICAgICAgICAgICAgcHVi bGljIHZvaWQgb25BY3Rpb25CdXR0b25DbGljayhBY3Rpb25CdXR0b25DbGlja0V2ZW50IGV2ZW50 KSB7CisgICAgICAgICAgICAgICAgbWFuYWdlci5pbnZva2VQbHVnaW5zKCJBY3Rpb25CdXR0b25D bGljayIsIG51bGwpOyAvLyROT04tTkxTLTEkCisgICAgICAgICAgICB9CisgICAgICAgIH0pOwor ICAgIH0KKworfQpkaWZmIC0tZ2l0IGEvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1p bi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL2V2ZW50 L0FjdGlvbkJ1dHRvbkNsaWNrLmphdmEgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFk bWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9wbHVnaW4vZXZl bnQvQWN0aW9uQnV0dG9uQ2xpY2suamF2YQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAw MDAwLi42MTQ1YjNkCi0tLSAvZGV2L251bGwKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxl cy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1 Z2luL2V2ZW50L0FjdGlvbkJ1dHRvbkNsaWNrLmphdmEKQEAgLTAsMCArMSw4IEBACitwYWNrYWdl IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4ucGx1Z2luLmV2ZW50OworCitpbXBvcnQgY29t Lmd3dHBsYXRmb3JtLmRpc3BhdGNoLmFubm90YXRpb24uR2VuRXZlbnQ7CisKK0BHZW5FdmVudAor cHVibGljIGNsYXNzIEFjdGlvbkJ1dHRvbkNsaWNrIHsKKworfQpkaWZmIC0tZ2l0IGEvZnJvbnRl bmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdp bmUvdWkvd2ViYWRtaW4vc2VjdGlvbi9tYWluL3ZpZXcvdGFiL01haW5UYWJWaXJ0dWFsTWFjaGlu ZVZpZXcuamF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4v amF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3NlY3Rpb24vbWFpbi92aWV3L3RhYi9N YWluVGFiVmlydHVhbE1hY2hpbmVWaWV3LmphdmEKaW5kZXggODc4OGNjNy4uMDE4ZDMxYyAxMDA2 NDQKLS0tIGEvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZh L29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vc2VjdGlvbi9tYWluL3ZpZXcvdGFiL01haW5U YWJWaXJ0dWFsTWFjaGluZVZpZXcuamF2YQorKysgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVz L3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9zZWN0 aW9uL21haW4vdmlldy90YWIvTWFpblRhYlZpcnR1YWxNYWNoaW5lVmlldy5qYXZhCkBAIC0xNyw2 ICsxNyw4IEBAIGltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLnVpY29tbW9ud2ViLm1vZGVscy52 bXMuQ29uc29sZU1vZGVsOwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkudWljb21tb253ZWIu bW9kZWxzLnZtcy5WbUxpc3RNb2RlbDsKIGltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFk bWluLkFwcGxpY2F0aW9uQ29uc3RhbnRzOwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2Vi YWRtaW4uQXBwbGljYXRpb25SZXNvdXJjZXM7CitpbXBvcnQgb3JnLm92aXJ0LmVuZ2luZS51aS53 ZWJhZG1pbi5naW4uQ2xpZW50R2luamVjdG9yUHJvdmlkZXI7CitpbXBvcnQgb3JnLm92aXJ0LmVu Z2luZS51aS53ZWJhZG1pbi5wbHVnaW4uZXZlbnQuQWN0aW9uQnV0dG9uQ2xpY2tFdmVudDsKIGlt cG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFkbWluLnNlY3Rpb24ubWFpbi5wcmVzZW50ZXIu dGFiLk1haW5UYWJWaXJ0dWFsTWFjaGluZVByZXNlbnRlcjsKIGltcG9ydCBvcmcub3ZpcnQuZW5n aW5lLnVpLndlYmFkbWluLnNlY3Rpb24ubWFpbi52aWV3LkFic3RyYWN0TWFpblRhYldpdGhEZXRh aWxzVGFibGVWaWV3OwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4udWljb21t b24uUmVwb3J0QWN0aW9uc0hlbHBlcjsKQEAgLTE2Myw2ICsxNjUsMTIgQEAgcHVibGljIGNsYXNz IE1haW5UYWJWaXJ0dWFsTWFjaGluZVZpZXcgZXh0ZW5kcyBBYnN0cmFjdE1haW5UYWJXaXRoRGV0 YWlsc1RhYmxlVmkKICAgICAgICAgICAgIHByb3RlY3RlZCBVSUNvbW1hbmQgcmVzb2x2ZUNvbW1h bmQoKSB7CiAgICAgICAgICAgICAgICAgcmV0dXJuIGdldE1haW5Nb2RlbCgpLmdldE5ld1NlcnZl ckNvbW1hbmQoKTsKICAgICAgICAgICAgIH0KKworICAgICAgICAgICAgQE92ZXJyaWRlCisgICAg ICAgICAgICBwdWJsaWMgdm9pZCBvbkNsaWNrKExpc3Q8Vk0+IHNlbGVjdGVkSXRlbXMpIHsKKyAg ICAgICAgICAgICAgICBzdXBlci5vbkNsaWNrKHNlbGVjdGVkSXRlbXMpOworICAgICAgICAgICAg ICAgIEFjdGlvbkJ1dHRvbkNsaWNrRXZlbnQuZmlyZShDbGllbnRHaW5qZWN0b3JQcm92aWRlci5p bnN0YW5jZSgpLmdldEV2ZW50QnVzKCkpOworICAgICAgICAgICAgfQogICAgICAgICB9KTsKICAg ICAgICAgZ2V0VGFibGUoKS5hZGRBY3Rpb25CdXR0b24obmV3IFdlYkFkbWluQnV0dG9uRGVmaW5p dGlvbjxWTT4oY29uc3RhbnRzLm5ld0Rlc2t0b3BWbSgpKSB7CiAgICAgICAgICAgICBAT3ZlcnJp ZGUKZGlmZiAtLWdpdCBhL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21h aW4vd2ViYXBwL1dFQi1JTkYvd2ViLnhtbCBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2Vi YWRtaW4vc3JjL21haW4vd2ViYXBwL1dFQi1JTkYvd2ViLnhtbAppbmRleCBhNTBmOGFhLi42MmYw MzEyIDEwMDY0NAotLS0gYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9t YWluL3dlYmFwcC9XRUItSU5GL3dlYi54bWwKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxl cy93ZWJhZG1pbi9zcmMvbWFpbi93ZWJhcHAvV0VCLUlORi93ZWIueG1sCkBAIC0yMyw2ICsyMywx NiBAQAogCQk8dXJsLXBhdHRlcm4+L3dlYmFkbWluL1dlYkFkbWluLmh0bWw8L3VybC1wYXR0ZXJu PgogCTwvc2VydmxldC1tYXBwaW5nPgogCisJPHNlcnZsZXQ+CisJCTxzZXJ2bGV0LW5hbWU+UGx1 Z2luU291cmNlUGFnZTwvc2VydmxldC1uYW1lPgorCQk8c2VydmxldC1jbGFzcz5vcmcub3ZpcnQu ZW5naW5lLnVpLmZyb250ZW5kLnNlcnZlci5nd3QuUGx1Z2luU291cmNlUGFnZVNlcnZsZXQ8L3Nl cnZsZXQtY2xhc3M+CisJPC9zZXJ2bGV0PgorCisJPHNlcnZsZXQtbWFwcGluZz4KKwkJPHNlcnZs ZXQtbmFtZT5QbHVnaW5Tb3VyY2VQYWdlPC9zZXJ2bGV0LW5hbWU+CisJCTx1cmwtcGF0dGVybj4v d2ViYWRtaW4vUGx1Z2luU291cmNlUGFnZTwvdXJsLXBhdHRlcm4+CisJPC9zZXJ2bGV0LW1hcHBp bmc+CisKIAk8IS0tIERlZmF1bHQgcGFnZSB0byBzZXJ2ZSAtLT4KIAk8d2VsY29tZS1maWxlLWxp c3Q+CiAJCTx3ZWxjb21lLWZpbGU+aW5kZXguaHRtbDwvd2VsY29tZS1maWxlPgotLSAKMS43LjQu NAoK --=_156c716f-6003-47a3-bcaa-20301ab51501--
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
this implies server side code running on the engine,
Actually, yes and no :) let me explain: - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :) If a GWT UI plugin web application needs to use Engine functionality, it can: - use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2] [1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
On 07/23/2012 03:26 PM, Vojtech Szocs wrote:
I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective.
As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication)
For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page).
what do you mean by a servlet here?
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
what do you mean by a servlet here?
I mean a dedicated servlet for rendering HTML page used to load the given plugin. Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin: - plugin dependencies - plugin configuration - actual plugin code On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary. Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 2:27:56 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 03:26 PM, Vojtech Szocs wrote:
I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective.
As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication)
For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page).
what do you mean by a servlet here?
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
On 07/27/2012 03:26 PM, Vojtech Szocs wrote:
what do you mean by a servlet here?
I mean a dedicated servlet for rendering HTML page used to load the given plugin.
Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin: - plugin dependencies - plugin configuration - actual plugin code
a builtin servelet to provide the plugins is fine.
On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary.
this again assumes custom code running in the engine, rather than static plugins
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 2:27:56 PM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 03:26 PM, Vojtech Szocs wrote:
I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective.
As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication)
For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page).
what do you mean by a servlet here?
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary.
this again assumes custom code running in the engine, rather than static plugins
Actually, users can deploy their plugins somewhere outside Engine JBoss (HTML page to load plugin, JavaScript representing the plugin code, plus optional server-side plugin code), and have them referenced from within WebAdmin. Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Friday, July 27, 2012 2:42:08 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/27/2012 03:26 PM, Vojtech Szocs wrote:
what do you mean by a servlet here?
I mean a dedicated servlet for rendering HTML page used to load the given plugin.
Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin: - plugin dependencies - plugin configuration - actual plugin code
a builtin servelet to provide the plugins is fine.
On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary.
this again assumes custom code running in the engine, rather than static plugins
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 2:27:56 PM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 03:26 PM, Vojtech Szocs wrote:
I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective.
As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication)
For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page).
what do you mean by a servlet here?
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin. Rather than extending the WebAdmin page with javascript, would it be possible to instead have an API that modifies that page with extensions? For example, the API tells it to add a new menu item that when launched would invoke the url registered with the extension. The new page is now rendered in a distinct window (much like early versions of GWT hosted mode created an embedded browser window). -George -----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Monday, July 23, 2012 8:27 AM To: Itamar Heim Cc: engine-devel Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin.
Yes, WebAdmin host page is served through Engine JBoss and therefore sits on its origin. WebAdmin host page loads a plugin by creating an iframe element and setting its "src" attribute to HTML page that's responsible for loading the actual plugin code. But if the plugin HTML page originates for a different origin (protocol, domain, port), plugin code that runs within an iframe element is unable to access top-level (WebAdmin host page) pluginApi object, because of Same-Origin-Policy restriction. As Itamar mentioned, we shouldn't deploy custom UI plugins on Engine JBoss, as it would complicate its maintenance from package perspective. There are currently two ways how plugins can be developed, and I'd like to discuss these on the upcoming meeting: --- 1) The "Standard" way: use standard Engine servlet (PluginSourcePageServlet in PoC) to take care of rendering plugin HTML page. This servlet will pick up all plugin dependencies, plugin configuration and actual plugin code, and produce the resulting HTML page used to load the plugin. Because this servlet runs on Engine JBoss, there will be no cross-origin issues. Pros: - well-defined way how to develop plugins (separation of dependencies, configuration and actual plugin code) - no need to take care of producing HTML plugin page (servlet will take care of that) Cons: - doesn't support custom plugin bootstrap schemes (e.g. cannot use GWT to develop plugins) - due to Same-Origin-Policy, plugin can communicate with Engine (e.g. REST API), but not with other external services (on other origins), unless you implement cross-origin communication schemes such as JSONP --- 2) The "Custom" way: run your own application server, deploy your plugin code there (client JavaScript code, plus optional server code). Instead of using standard Engine servlet, use your own application server to serve plugin HTML page. This means that you are responsible for assembling everything (plugin dependencies, configuration, code, etc.) into HTML page used to load your plugin. Pros: - supports custom plugin bootstrap schemes (e.g. can use GWT to develop plugins), since you are responsible for providing plugin HTML content - supports hosting custom server-side plugin code (in addition to plugins being able to call Engine through APIs like REST) Cons: - to work around Same-Origin-Policy (and get hold of WebAdmin's pluginApi object), your application server needs to use CORS (Cross-Origin Resource Sharing), which basically means extra HTTP response header --- Originally, I wanted to start with (1) (the "Standard" way), but we should discuss and evaluate both approaches. Vojtech ----- Original Message ----- From: "George Costea" <George.Costea@netapp.com> To: "Vojtech Szocs" <vszocs@redhat.com>, "Itamar Heim" <iheim@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Monday, July 23, 2012 3:33:12 PM Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin. Rather than extending the WebAdmin page with javascript, would it be possible to instead have an API that modifies that page with extensions? For example, the API tells it to add a new menu item that when launched would invoke the url registered with the extension. The new page is now rendered in a distinct window (much like early versions of GWT hosted mode created an embedded browser window). -George -----Original Message----- From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Monday, July 23, 2012 8:27 AM To: Itamar Heim Cc: engine-devel Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
we'll need to solve these in any case for plugins which do have an existing external service.
In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework.
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
This was actually option [1] as described in my email below.
From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
this implies server side code running on the engine,
Actually, yes and no :) let me explain:
- UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt.
- UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API.
which has additional implications on compatibility vs. ui plugins as discussed
I don't think we need to worry about this :)
If a GWT UI plugin web application needs to use Engine functionality, it can:
- use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2]
again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two.
[1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message ----- From: "Itamar Heim" <iheim@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <ecohen@redhat.com> Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress
On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page.
this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins).
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--_000_6C8AC8C50E170C4E9B44D47B39B24A480126A6B7SACEXCMBX04PRDh_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVm9qdGVjaCwNCg0KSSBqdXN0IGhhZCBhIGNoYW5jZSB0byB0cnkgdGhlIHBhdGNoIHRvZGF5 IGFuZCBpdCB3b3JrcyBncmVhdC4gIFdoZW4gSSBjbGljayB0aGUg4oCcTmV3IFNlcnZlcuKAnSBi dXR0b24gb24gdGhlIOKAnFZpcnR1YWwgTWFjaGluZXPigJ0gdGFiIEkgc2VlIHRoZSBhbGVydC4g IFdoYXQgZG8gSSBkbyB0byBhZGQgYSBuZXcgYnV0dG9uIGJlc2lkZSBvZiB0aGUg4oCcTmV3IFNl cnZlcuKAnSBidXR0b24gb3IgYXQgdGhlIGVuZCBhZnRlciB0aGUg4oCcR3VpZGUgTWXigJ0gYnV0 dG9uPyAgSSB3b3VsZCBsaWtlIHRvIGFkZCBteSBvd24gYnV0dG9uIHRoZXJlIGFuZCB0aGVuIGlu dm9rZSBteSBvd24gVUkgYnVpbHQgd2l0aCBHV1QuDQoNClRoYW5rcywNCkdlb3JnZQ0KDQpGcm9t OiBlbmdpbmUtZGV2ZWwtYm91bmNlc0BvdmlydC5vcmcgW21haWx0bzplbmdpbmUtZGV2ZWwtYm91 bmNlc0BvdmlydC5vcmddIE9uIEJlaGFsZiBPZiBWb2p0ZWNoIFN6b2NzDQpTZW50OiBGcmlkYXks IEp1bHkgMjAsIDIwMTIgNDozOCBQTQ0KVG86IGVuZ2luZS1kZXZlbA0KU3ViamVjdDogW0VuZ2lu ZS1kZXZlbF0gb1ZpcnQgVUkgUGx1Z2luczogVXBkYXRlIG9uIGN1cnJlbnQgcHJvZ3Jlc3MNCg0K SGkgZ3V5cywNCg0KSSd2ZSBzcGVudCBzb21lIHRpbWUgd29ya2luZyBvbiBVSSBQbHVnaW5zIHBy b29mLW9mLWNvbmNlcHQgKFBvQykgaW1wbGVtZW50YXRpb24sIGFuZCB0aG91Z2h0IEknZCBzaGFy ZSBteSByZXN1bHRzIHdpdGggeW91LiBJJ3ZlIGF0dGFjaGVkIGEgcGF0Y2ggdGhhdCByZWZsZWN0 cyB0aGUgY3VycmVudCBwcm9ncmVzcy4NCg0KVGhlIGFjdHVhbCBQb0MgaW1wbGVtZW50YXRpb24g dGFrZXMgc29tZSBpbnNwaXJhdGlvbiBmcm9tIG9WaXJ0IFVJIFBsdWdpbnMgd2lraSBwYWdlLCBh bmQgc2ltcGxpZmllcy9zdHJlYW1saW5lcy9pbXByb3ZlcyBpdHMgbWFpbiBjb25jZXB0cy4gVGhl IGdvYWwgaXMgdG8gaGF2ZSBzaW1wbGUtdG8tdXNlLCB5ZXQgZmxleGlibGUgYW5kIHJvYnVzdCBw bHVnaW4gaW5mcmFzdHJ1Y3R1cmUuIE1ham9yIGNoYW5nZXMgdG8gdGhlIG9yaWdpbmFsIGRlc2ln biBhcmUgb3V0bGluZWQgYmVsb3cuDQoNCkVhY2ggVUkgcGx1Z2luIHJ1bnMgd2l0aGluIHRoZSBj b250ZXh0IG9mIGFuIGlmcmFtZSwgYW5kIHRoZXJlZm9yZSByZXF1aXJlcyBhIHBsdWdpbiBzb3Vy Y2UgcGFnZSB0aGF0IGV4ZWN1dGVzIHRoZSBhY3R1YWwgcGx1Z2luIGNvZGUuDQoNCiAgKiAgIGlm cmFtZSBpcyBlc3NlbnRpYWxseSB0aGUgc2FuZGJveCBmb3IgZWFjaCBwbHVnaW4uIFdlIGNhbiBk aXNhYmxlIHBsdWdpbnMgYnkgZGV0YWNoaW5nIHRoZWlyIGlmcmFtZSBlbGVtZW50cyBmcm9tIHRo ZSBtYWluIGRvY3VtZW50IGR1cmluZyBXZWJBZG1pbiBydW50aW1lLiBUaGlzIGFsc28gYWxsb3dz IHVzIHRvIGltcGxlbWVudCBmZWF0dXJlcyBzdWNoIGFzIHBsdWdpbiBzYWZlIG1vZGUgKG5vIHBs dWdpbnMgbG9hZGVkIG9uIFdlYkFkbWluIHN0YXJ0dXApLg0KICAqICAgUGx1Z2luIHNvdXJjZSBw YWdlcyBhbmQgV2ViQWRtaW4gaG9zdCBwYWdlIHNoYXJlIHRoZSBzYW1lIG9yaWdpbiAocHJvdG9j b2wsIGRvbWFpbiwgcG9ydCksIHdpdGggcGx1Z2luIHNvdXJjZSBwYWdlcyBiZWluZyBzZXJ2ZWQg dGhyb3VnaCBFbmdpbmVNYW5hZ2VyIGFwcGxpY2F0aW9uIHNlcnZlciAoSkJvc3MgQVMpLiBUaGlz IGlzIHRvIGF2b2lkIGNyb3NzLWRvbWFpbiB3aW5kb3cvaWZyYW1lIGNvbW11bmljYXRpb24gaXNz dWVzLCB3aGVuIHRoZSBhY3R1YWwgcGx1Z2luIGNvZGUgcnVubmluZyBpbiBhbiBpZnJhbWUgdHJp ZXMgdG8gcmVnaXN0ZXIgaXRzZWxmIGludG8gV2ViQWRtaW4gbWFpbiBkb2N1bWVudCdzIHBsdWdp bkFwaSBvYmplY3QuDQogICogICBUaGVyZSdzIGEgc2VydmxldCBkZXNpZ25lZCB0byByZW5kZXIg cGx1Z2luIHNvdXJjZSBwYWdlIGZvciBhbGwgcGx1Z2lucyAoUGx1Z2luU291cmNlUGFnZVNlcnZs ZXQpLiBGb3IgdGhlIGdpdmVuIHBsdWdpbiwgaXQgZGV0ZWN0cyBpdHMgZGVwZW5kZW5jaWVzICgz cmQgcGFydHkgSmF2YVNjcmlwdCBsaWJyYXJpZXMpIGFuZCBjb25maWd1cmF0aW9uIG9iamVjdCAo SlNPTiBkYXRhKSwgcmVhZHMgdGhlIGFjdHVhbCBwbHVnaW4gY29kZSwgYW5kIGFzc2VtYmxlcyBl dmVyeXRoaW5nIGludG8gdGhlIHJlc3VsdGluZyBIVE1MIHBhZ2UgKHRvIGJlIGV2YWx1YXRlZCBi eSB0aGUgcGx1Z2luIGlmcmFtZSkuDQogICogICBpZnJhbWUgaXNvbGF0ZXMgcGx1Z2luIGRlcGVu ZGVuY2llcyAoM3JkIHBhcnR5IEphdmFTY3JpcHQgbGlicmFyaWVzKSBmcm9tIG90aGVyIHBsdWdp bnMgYW5kIHRoZSBtYWluIFdlYkFkbWluIGRvY3VtZW50LiBJbiBwcmFjdGljZSwgdGhpcyBtZWFu cyB0aGF0IHBsdWdpbiBBIGNhbiB1c2UgalF1ZXJ5IDEuNyBhbmQgcGx1Z2luIEIgY2FuIHVzZSBq UXVlcnkgMS42IHdpdGhvdXQgdGhlIGZlYXIgb2YgYW55IGNsYXNoZXMuDQogICogICBMYXN0IGJ1 dCBub3QgbGVhc3QsIHdyaXRpbmcgcGx1Z2lucyBpbiBHb29nbGUgV2ViIFRvb2xraXQgKEdXVCkg c2hvdWxkIGJlIGFzIGVhc3kgYXMgcHJvdmlkaW5nIHlvdXIgb3duIHBsdWdpbiBzb3VyY2UgcGFn ZS4gSnVzdCBkZXBsb3kgeW91ciBHV1QgcGx1Z2luIGFwcGxpY2F0aW9uIG9uIEpCb3NzIEFTIChu ZXh0IHRvIGVuZ2luZS5lYXIpLCBhbmQgcG9pbnQgdG8gR1dUIHBsdWdpbiBhcHBsaWNhdGlvbiBo b3N0IHBhZ2UuDQoNClRoZSBjdXJyZW50IFBvQyBkZWNsYXJlcyBhIHNpbXBsZSBwbHVnaW4gdGhh dCBnZXRzIGxvYWRlZCB1c2luZyBoYXJkLWNvZGVkIHZhbHVlcyBpbiBQbHVnaW5Tb3VyY2VQYWdl U2VydmxldC4gQWN0dWFsIHBsdWdpbiBjb2RlIHJlZ2lzdGVycyB0aGUgcGx1Z2luIGludG8gZ2xv YmFsIHBsdWdpbkFwaS5wbHVnaW5zIG9iamVjdCwgd2l0aCBvbmUgc2FtcGxlIGV2ZW50IGhhbmRs ZXIgZnVuY3Rpb24gKEFjdGlvbkJ1dHRvbkNsaWNrKS4gSnVzdCBhZnRlciB0aGF0LCB0aGUgcGx1 Z2luIHJlcG9ydHMgaW4gYXMgcmVhZHkgYnkgY2FsbGluZyBwbHVnaW5BcGkucmVhZHkgZnVuY3Rp b24uIFRoaXMgZXNzZW50aWFsbHkgcHV0cyB0aGUgcGx1Z2luIGludG8gdXNlIHdpdGhpbiBXZWJB ZG1pbi4NCg0KDQpUbyBzaW11bGF0ZSBleHRlbnNpb24gcG9pbnQgKGFwcGxpY2F0aW9uIGV2ZW50 IHRvIGJlIGNvbnN1bWVkIGJ5IHBsdWdpbnMpLCB3aGVuIHRoZSB1c2VyIGNsaWNrcyAiTmV3IHNl cnZlciIgYnV0dG9uIG9uICJWaXJ0dWFsIE1hY2hpbmVzIiBtYWluIHRhYiwgQWN0aW9uQnV0dG9u Q2xpY2tFdmVudCBnZXRzIGZpcmVkIHRocm91Z2ggV2ViQWRtaW4gZXZlbnQgYnVzLiBQbHVnaW5F dmVudEhhbmRsZXIgcmVjZWl2ZXMgdGhpcyBldmVudCBhbmQgaW52b2tlcyBBY3Rpb25CdXR0b25D bGljayBldmVudCBoYW5kbGVyIGZ1bmN0aW9uIG9uIGFsbCBwbHVnaW5zLg0KDQoNCg0KKE5vdGU6 IGZvciBwYXNzaW5nIGNvbnRleHQgb2JqZWN0cyBmcm9tIFdlYkFkbWluIHRvIHBsdWdpbiBldmVu dCBoYW5kbGVyIGZ1bmN0aW9ucywgSSdtIHBsYW5uaW5nIHRvIGV4cGVyaW1lbnQgd2l0aCBnd3Qt ZXhwb3J0ZXIgcHJvamVjdCBbMV0uIFRoaXMgd291bGQgZ3JlYXRseSBzaW1wbGlmeSB0aGUgd2F5 IGhvdyBXZWJBZG1pbiBleHBvc2VzIGNvbnRleHQtc3BlY2lmaWMgcGx1Z2luIEFQSSB0byBldmVu dCBoYW5kbGVyIGZ1bmN0aW9ucy4pDQoNCg0KDQpBcyBmb3IgdGhlIG5leHQgc3RlcCwgSSBzdWdn ZXN0IHRvIGhhdmUgc29tZSBtZWV0aW5nIChjb25mZXJlbmNlKSB0byBkaXNjdXNzIHRoZSBQb0Mg aW4gZGV0YWlsLCBhbmQgb3V0bGluZSB0YXNrcyBmb3IgdGhlIG5lYXIgZnV0dXJlLiBBbHNvLCBw bGVhc2UgbGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsgb2YgdGhlIFBvQyBzbyBmYXIuDQoNCkNo ZWVycywNClZvanRlY2gNCg0KWzFdIGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9nd3QtZXhwb3J0 ZXIvDQoNCg0K --_000_6C8AC8C50E170C4E9B44D47B39B24A480126A6B7SACEXCMBX04PRDh_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6NTk5MDU2MjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05 MDY3NTI1OTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SGkgVm9qdGVjaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkganVzdCBoYWQgYSBjaGFuY2UgdG8gdHJ5 IHRoZSBwYXRjaCB0b2RheSBhbmQgaXQgd29ya3MgZ3JlYXQuJm5ic3A7IFdoZW4gSSBjbGljayB0 aGUg4oCcTmV3IFNlcnZlcuKAnSBidXR0b24gb24gdGhlIOKAnFZpcnR1YWwgTWFjaGluZXPigJ0g dGFiIEkgc2VlIHRoZSBhbGVydC4mbmJzcDsgV2hhdCBkbw0KIEkgZG8gdG8gYWRkIGEgbmV3IGJ1 dHRvbiBiZXNpZGUgb2YgdGhlIOKAnE5ldyBTZXJ2ZXLigJ0gYnV0dG9uIG9yIGF0IHRoZSBlbmQg YWZ0ZXIgdGhlIOKAnEd1aWRlIE1l4oCdIGJ1dHRvbj8mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIGFk ZCBteSBvd24gYnV0dG9uIHRoZXJlIGFuZCB0aGVuIGludm9rZSBteSBvd24gVUkgYnVpbHQgd2l0 aCBHV1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdl b3JnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGVu Z2luZS1kZXZlbC1ib3VuY2VzQG92aXJ0Lm9yZyBbbWFpbHRvOmVuZ2luZS1kZXZlbC1ib3VuY2Vz QG92aXJ0Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Vm9qdGVjaCBTem9jczxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEp1bHkgMjAsIDIwMTIgNDozOCBQTTxicj4NCjxiPlRvOjwvYj4gZW5n aW5lLWRldmVsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFbmdpbmUtZGV2ZWxdIG9WaXJ0IFVJIFBs dWdpbnM6IFVwZGF0ZSBvbiBjdXJyZW50IHByb2dyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SGkgZ3V5cyw8YnI+DQo8YnI+DQpJJ3ZlIHNwZW50IHNvbWUgdGltZSB3b3JraW5nIG9uIFVJIFBs dWdpbnMgcHJvb2Ytb2YtY29uY2VwdCAoUG9DKSBpbXBsZW1lbnRhdGlvbiwgYW5kIHRob3VnaHQg SSdkIHNoYXJlIG15IHJlc3VsdHMgd2l0aCB5b3UuIEkndmUgYXR0YWNoZWQgYSBwYXRjaCB0aGF0 IHJlZmxlY3RzIHRoZSBjdXJyZW50IHByb2dyZXNzLg0KPGJyPg0KPGJyPg0KVGhlIGFjdHVhbCBQ b0MgaW1wbGVtZW50YXRpb24gdGFrZXMgc29tZSBpbnNwaXJhdGlvbiBmcm9tIG9WaXJ0IFVJIFBs dWdpbnMgd2lraSBwYWdlLCBhbmQgc2ltcGxpZmllcy9zdHJlYW1saW5lcy9pbXByb3ZlcyBpdHMg bWFpbiBjb25jZXB0cy4gVGhlIGdvYWwgaXMgdG8gaGF2ZSBzaW1wbGUtdG8tdXNlLCB5ZXQgZmxl eGlibGUgYW5kIHJvYnVzdCBwbHVnaW4gaW5mcmFzdHJ1Y3R1cmUuIE1ham9yIGNoYW5nZXMgdG8g dGhlIG9yaWdpbmFsIGRlc2lnbg0KIGFyZSBvdXRsaW5lZCBiZWxvdy48YnI+DQo8YnI+DQo8c3Ry b25nPkVhY2ggVUkgcGx1Z2luIHJ1bnMgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGlmcmFtZSwg YW5kIHRoZXJlZm9yZSByZXF1aXJlcyBhDQo8L3N0cm9uZz48Yj48aT5wbHVnaW4gc291cmNlIHBh Z2U8L2k+IHRoYXQgZXhlY3V0ZXMgdGhlIGFjdHVhbCBwbHVnaW4gY29kZS48L2I+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQppZnJhbWUgaXMgZXNzZW50aWFs bHkgdGhlIHNhbmRib3ggZm9yIGVhY2ggcGx1Z2luLiBXZSBjYW4gZGlzYWJsZSBwbHVnaW5zIGJ5 IGRldGFjaGluZyB0aGVpciBpZnJhbWUgZWxlbWVudHMgZnJvbSB0aGUgbWFpbiBkb2N1bWVudCBk dXJpbmcgV2ViQWRtaW4gcnVudGltZS4gVGhpcyBhbHNvIGFsbG93cyB1cyB0byBpbXBsZW1lbnQg ZmVhdHVyZXMgc3VjaCBhcw0KPGVtPnBsdWdpbiBzYWZlIG1vZGU8L2VtPiAobm8gcGx1Z2lucyBs b2FkZWQgb24gV2ViQWRtaW4gc3RhcnR1cCkuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUGx1Z2luIHNv dXJjZSBwYWdlcyBhbmQgV2ViQWRtaW4gaG9zdCBwYWdlIHNoYXJlIHRoZSBzYW1lIG9yaWdpbiAo cHJvdG9jb2wsIGRvbWFpbiwgcG9ydCksIHdpdGggcGx1Z2luIHNvdXJjZSBwYWdlcyBiZWluZyBz ZXJ2ZWQgdGhyb3VnaCBFbmdpbmVNYW5hZ2VyIGFwcGxpY2F0aW9uIHNlcnZlciAoSkJvc3MgQVMp LiBUaGlzIGlzIHRvIGF2b2lkIGNyb3NzLWRvbWFpbiB3aW5kb3cvaWZyYW1lIGNvbW11bmljYXRp b24gaXNzdWVzLCB3aGVuIHRoZQ0KIGFjdHVhbCBwbHVnaW4gY29kZSBydW5uaW5nIGluIGFuIGlm cmFtZSB0cmllcyB0byByZWdpc3RlciBpdHNlbGYgaW50byBXZWJBZG1pbiBtYWluIGRvY3VtZW50 J3MNCjxpPnBsdWdpbkFwaTwvaT4gb2JqZWN0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZXJlJ3Mg YSBzZXJ2bGV0IGRlc2lnbmVkIHRvIHJlbmRlciBwbHVnaW4gc291cmNlIHBhZ2UgZm9yIGFsbCBw bHVnaW5zICg8aT5QbHVnaW5Tb3VyY2VQYWdlU2VydmxldDwvaT4pLiBGb3IgdGhlIGdpdmVuIHBs dWdpbiwgaXQgZGV0ZWN0cyBpdHMgZGVwZW5kZW5jaWVzICgzcmQgcGFydHkgSmF2YVNjcmlwdCBs aWJyYXJpZXMpIGFuZCBjb25maWd1cmF0aW9uIG9iamVjdCAoSlNPTiBkYXRhKSwgcmVhZHMgdGhl IGFjdHVhbCBwbHVnaW4gY29kZSwNCiBhbmQgYXNzZW1ibGVzIGV2ZXJ5dGhpbmcgaW50byB0aGUg cmVzdWx0aW5nIEhUTUwgcGFnZSAodG8gYmUgZXZhbHVhdGVkIGJ5IHRoZSBwbHVnaW4gaWZyYW1l KS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQppZnJhbWUgaXNvbGF0ZXMgcGx1Z2luIGRlcGVuZGVuY2ll cyAoM3JkIHBhcnR5IEphdmFTY3JpcHQgbGlicmFyaWVzKSBmcm9tIG90aGVyIHBsdWdpbnMgYW5k IHRoZSBtYWluIFdlYkFkbWluIGRvY3VtZW50LiBJbiBwcmFjdGljZSwgdGhpcyBtZWFucyB0aGF0 IHBsdWdpbiBBIGNhbiB1c2UgalF1ZXJ5IDEuNyBhbmQgcGx1Z2luIEIgY2FuIHVzZSBqUXVlcnkg MS42IHdpdGhvdXQgdGhlIGZlYXIgb2YgYW55IGNsYXNoZXMuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K TGFzdCBidXQgbm90IGxlYXN0LCB3cml0aW5nIHBsdWdpbnMgaW4gR29vZ2xlIFdlYiBUb29sa2l0 IChHV1QpIHNob3VsZCBiZSBhcyBlYXN5IGFzIHByb3ZpZGluZyB5b3VyIG93biBwbHVnaW4gc291 cmNlIHBhZ2UuIEp1c3QgZGVwbG95IHlvdXIgR1dUIHBsdWdpbiBhcHBsaWNhdGlvbiBvbiBKQm9z cyBBUyAobmV4dCB0bw0KPGk+ZW5naW5lLmVhcjwvaT4pLCBhbmQgcG9pbnQgdG8gR1dUIHBsdWdp biBhcHBsaWNhdGlvbiBob3N0IHBhZ2UuPG86cD48L286cD48L2xpPjwvdWw+DQo8cD48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBjdXJyZW50IFBvQyBkZWNsYXJlcyBhIHNpbXBsZSBwbHVn aW4gdGhhdCBnZXRzIGxvYWRlZCB1c2luZyBoYXJkLWNvZGVkIHZhbHVlcyBpbg0KPGk+UGx1Z2lu U291cmNlUGFnZVNlcnZsZXQ8L2k+LiBBY3R1YWwgcGx1Z2luIGNvZGUgcmVnaXN0ZXJzIHRoZSBw bHVnaW4gaW50byBnbG9iYWwNCjxpPnBsdWdpbkFwaS5wbHVnaW5zPC9pPiBvYmplY3QsIHdpdGgg b25lIHNhbXBsZSBldmVudCBoYW5kbGVyIGZ1bmN0aW9uICg8aT5BY3Rpb25CdXR0b25DbGljazwv aT4pLiBKdXN0IGFmdGVyIHRoYXQsIHRoZSBwbHVnaW4gcmVwb3J0cyBpbiBhcyByZWFkeSBieSBj YWxsaW5nDQo8aT5wbHVnaW5BcGkucmVhZHk8L2k+IGZ1bmN0aW9uLiBUaGlzIGVzc2VudGlhbGx5 IHB1dHMgdGhlIHBsdWdpbiBpbnRvIHVzZSB3aXRoaW4gV2ViQWRtaW4uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRvIHNpbXVsYXRlIGV4dGVuc2lvbiBwb2ludCAoYXBwbGljYXRpb24gZXZlbnQgdG8gYmUgY29u c3VtZWQgYnkgcGx1Z2lucyksIHdoZW4gdGhlIHVzZXIgY2xpY2tzICZxdW90O05ldyBzZXJ2ZXIm cXVvdDsgYnV0dG9uIG9uICZxdW90O1ZpcnR1YWwgTWFjaGluZXMmcXVvdDsgbWFpbiB0YWIsDQo8 aT5BY3Rpb25CdXR0b25DbGlja0V2ZW50PC9pPiBnZXRzIGZpcmVkIHRocm91Z2ggV2ViQWRtaW4g ZXZlbnQgYnVzLiA8aT5QbHVnaW5FdmVudEhhbmRsZXI8L2k+IHJlY2VpdmVzIHRoaXMgZXZlbnQg YW5kIGludm9rZXMNCjxpPkFjdGlvbkJ1dHRvbkNsaWNrPC9pPiBldmVudCBoYW5kbGVyIGZ1bmN0 aW9uIG9uIGFsbCBwbHVnaW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4oTm90ZTogZm9yIHBhc3NpbmcgY29udGV4dCBvYmplY3RzIGZyb20g V2ViQWRtaW4gdG8gcGx1Z2luIGV2ZW50IGhhbmRsZXIgZnVuY3Rpb25zLCBJJ20gcGxhbm5pbmcg dG8gZXhwZXJpbWVudCB3aXRoIGd3dC1leHBvcnRlciBwcm9qZWN0IFsxXS4gVGhpcyB3b3VsZCBn cmVhdGx5IHNpbXBsaWZ5IHRoZSB3YXkgaG93IFdlYkFkbWluIGV4cG9zZXMgY29udGV4dC1zcGVj aWZpYyBwbHVnaW4gQVBJIHRvDQogZXZlbnQgaGFuZGxlciBmdW5jdGlvbnMuKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcyBmb3IgdGhlIG5l eHQgc3RlcCwgSSBzdWdnZXN0IHRvIGhhdmUgc29tZSBtZWV0aW5nIChjb25mZXJlbmNlKSB0byBk aXNjdXNzIHRoZSBQb0MgaW4gZGV0YWlsLCBhbmQgb3V0bGluZSB0YXNrcyBmb3IgdGhlIG5lYXIg ZnV0dXJlLiBBbHNvLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsgb2YgdGhlIFBv QyBzbyBmYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpDaGVlcnMsPGJyPg0KVm9qdGVjaDxicj4NCjxi cj4NClsxXSA8YSBocmVmPSJodHRwOi8vY29kZS5nb29nbGUuY29tL3AvZ3d0LWV4cG9ydGVyLyI+ aHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL2d3dC1leHBvcnRlci88L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6C8AC8C50E170C4E9B44D47B39B24A480126A6B7SACEXCMBX04PRDh_--
Hi George, the PoC defines a simple ActionButtonClick event which is fired when the user clicks on "New Server" button, and WebAdmin invokes ActionButtonClick function on all plugins. This is just an example to demonstrate how plugin invocation could work. If you want to add new button to VM main tab, there should be a separate event fired when the VM main tab is rendered, with plugins providing extra button definitions. Alternatively, pluginApi object can provide some API to add these buttons at time when plugin code gets loaded. Unfortunately, this isn't part of the PoC yet, as I wanted to discuss this with you before continuing with PoC implementation. As for developing plugins with GWT, I've sent a mail about this, discussing two possible ways to develop plugins. We should evaluate pros/cons of each approach and decide which way to go first.. (the PoC contains hand-written JavaScript for now though) Vojtech ----- Original Message ----- From: "George Costea" <George.Costea@netapp.com> To: "Vojtech Szocs" <vszocs@redhat.com>, "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, July 25, 2012 5:25:17 PM Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress Hi Vojtech, I just had a chance to try the patch today and it works great. When I click the “New Server” button on the “Virtual Machines” tab I see the alert. What do I do to add a new button beside of the “New Server” button or at the end after the “Guide Me” button? I would like to add my own button there and then invoke my own UI built with GWT. Thanks, George From: engine-devel-bounces@ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of Vojtech Szocs Sent: Friday, July 20, 2012 4:38 PM To: engine-devel Subject: [Engine-devel] oVirt UI Plugins: Update on current progress Hi guys, I've spent some time working on UI Plugins proof-of-concept (PoC) implementation, and thought I'd share my results with you. I've attached a patch that reflects the current progress. The actual PoC implementation takes some inspiration from oVirt UI Plugins wiki page, and simplifies/streamlines/improves its main concepts. The goal is to have simple-to-use, yet flexible and robust plugin infrastructure. Major changes to the original design are outlined below. Each UI plugin runs within the context of an iframe, and therefore requires a plugin source page that executes the actual plugin code. * iframe is essentially the sandbox for each plugin. We can disable plugins by detaching their iframe elements from the main document during WebAdmin runtime. This also allows us to implement features such as plugin safe mode (no plugins loaded on WebAdmin startup). * Plugin source pages and WebAdmin host page share the same origin (protocol, domain, port), with plugin source pages being served through EngineManager application server (JBoss AS). This is to avoid cross-domain window/iframe communication issues, when the actual plugin code running in an iframe tries to register itself into WebAdmin main document's pluginApi object. * There's a servlet designed to render plugin source page for all plugins ( PluginSourcePageServlet ). For the given plugin, it detects its dependencies (3rd party JavaScript libraries) and configuration object (JSON data), reads the actual plugin code, and assembles everything into the resulting HTML page (to be evaluated by the plugin iframe). * iframe isolates plugin dependencies (3rd party JavaScript libraries) from other plugins and the main WebAdmin document. In practice, this means that plugin A can use jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes. * Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear ), and point to GWT plugin application host page. The current PoC declares a simple plugin that gets loaded using hard-coded values in PluginSourcePageServlet . Actual plugin code registers the plugin into global pluginApi.plugins object, with one sample event handler function ( ActionButtonClick ). Just after that, the plugin reports in as ready by calling pluginApi.ready function. This essentially puts the plugin into use within WebAdmin. To simulate extension point (application event to be consumed by plugins), when the user clicks "New server" button on "Virtual Machines" main tab, ActionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHandler receives this event and invokes ActionButtonClick event handler function on all plugins. (Note: for passing context objects from WebAdmin to plugin event handler functions, I'm planning to experiment with gwt-exporter project [1]. This would greatly simplify the way how WebAdmin exposes context-specific plugin API to event handler functions.) As for the next step, I suggest to have some meeting (conference) to discuss the PoC in detail, and outline tasks for the near future. Also, please let me know what you think of the PoC so far. Cheers, Vojtech [1] http://code.google.com/p/gwt-exporter/
participants (3)
-
Costea, George -
Itamar Heim -
Vojtech Szocs