[ovirt-devel] REST API CSRF protection header name

2014-12-02 Thread Vojtech Szocs 
Hi,

since 3.5 the oVirt REST API features CSRF protection
mechanism via CSRFProtectionFilter, see [1] for details.

[1] http://gerrit.ovirt.org/#/c/29681/

I'd like to ask what's the motivation behind calling the
CSRF token header "JSESSIONID". I think the header name
should reflect its logical purpose to avoid confusion.

Could we rename this header to something more appropriate
like "OVIRT-REST-CSRF-TOKEN" or similar? It would better
reflect the purpose of this (CSRF protection) header.

In future, we can still have another request header with
name "JSESSIONID" for transmitting session ID from client
to server, however this potential new header would have
different purpose (transfer session ID vs. CSRF token).
Each header should have name reflecting its purpose.

(This is just a suggestion.)

Thanks,
Vojtech
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Some ideas on oVirt Java SDK

2014-12-02 Thread Vojtech Szocs 


- Original Message -
> From: "Juan Hernández" 
> To: "Vojtech Szocs" 
> Cc: devel@ovirt.org, "Michael Pasternak" 
> Sent: Tuesday, December 2, 2014 10:02:36 AM
> Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
> 
> On 12/01/2014 06:36 PM, Vojtech Szocs wrote:
> > 
> > 
> > - Original Message -
> >> From: "Juan Hernández" 
> >> To: "Vojtech Szocs" 
> >> Cc: devel@ovirt.org
> >> Sent: Monday, December 1, 2014 4:24:45 PM
> >> Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
> >>
> >> On 12/01/2014 04:13 PM, Vojtech Szocs wrote:
> >>>
> >>>
> >>> - Original Message -
>  From: "Juan Hernández" 
>  To: "Michael Pasternak" , "Vojtech Szocs"
>  , devel@ovirt.org
>  Sent: Monday, December 1, 2014 9:54:51 AM
>  Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
> 
>  On 11/30/2014 12:26 PM, Michael Pasternak wrote:
> > Hey Vojtech,
> >
> > How are you?, please see my reply inline.
> >
> >
> >
> > On Friday, November 28, 2014 5:26 PM, Vojtech Szocs
> > mailto:vsz...@redhat.com>> wrote:
> >
> >
> > Hi guys,
> >
> > since the initial (small, working & well-tested) version of oVirtJS
> > JavaScript SDK is finished [*], I've started working on GWT wrapper
> > for oVirtJS.
> >
> > While analyzing/reverse-engineering oVirt Java SDK, some thoughts
> > came to my mind, and I wanted to share them with you.
> >
> > [*] TODO(vszocs) upload new patchset with all recent changes
> >
> > First, the way XJC (JAXB binding compiler that generates Java beans
> > out of REST XSD schema) is invoked looks a bit weird to me, as Java
> > SDK's XsdCodegen does this:
> >
> >   Runtime.getRuntime().exec(command)
> >
> > Why not simply use existing Maven plugins to invoke XJC?
> > - either: https://github.com/highsource/maven-jaxb2-plugin
> > 
> >
> >
> > [MP] sdk was using jaxb to begin with, it was replaced with XJC just
> > recently,
> > btw Juan, what was the motivation behind this?
> 
>  This didn't change, the use of "xjc" is there since commit 95a25a4, Nov
>  12 2012.
> 
>  Note that using Maven for this isn't as simple as it may look. The
>  development model of the SDK is that the maven build does *not* generate
>  any code, it just builds what has been manually generated previously.
> >>>
> >>> To clarify, my question was meant for "ovirt-engine-sdk-java-codegen"
> >>> project and its org.ovirt.engine.sdk.codegen.Main class that produces
> >>> Java classes out of XSD as part of XsdCodegen.generate() method.
> >>>
> >>> But if XsdCodegen invokes XJC programatically, what is the purpose of:
> >>>
> >>>   org.jvnet.jaxb2.maven2:maven-jaxb22-plugin:generate
> >>>
> >>> in "ovirt-engine-sdk-java-codegen" project's pom.xml?
> >>>
> >>> Is it related to what XsdCodegen is doing?
> >>>
> >>
> >> The code generator invokes "xjc" directly in order to generate from the
> >> XML schema the code that will eventually be part of the generated SDK.
> >> In order to do its work it needs to parse the RSDL metadata, and for
> >> that it uses JAXB and classes generated from the XML schema. Those
> >> classes are generated as part of the build process of the code
> >> generator. So the XML schema is converted into Java classes twice: once
> >> for the internal use of the generator (during build time of the
> >> generator), and another time for the generated SDK (during run time of
> >> the generator). This is convenient in order to avoid dependencies
> >> between the generator and the SDK.
> > 
> > Thanks for clarification.
> > 
> > IMHO calling XJC just to generate JAXB code that parses RSDL data
> > is an overkill. In oVirtJS GWT wrapper project, I'm parsing RSDL
> > as XML file directly.
> > 
> 
> The "xjc" compiler isn't called directly to generate the code to parse
> RSDL, it is called to generate the code of the SDK.

Yes, that's what XsdCodegen is doing.

> 
> The code that the generator uses internally is generated using the Maven
> plugin (which in turn calls "xjc").

Yes, that's what maven-jaxb22-plugin is doing
in ovirt-engine-sdk-java-codegen/pom.xml file.

> 
> We could argue about the convenience of using JAXB or manually parsing
> the RSDL, but it won't take us anywhere. If you find it convenient
> parsing it directly just do it.
> 
> > Conceptually, RSDL definition shouldn't even be inside api.xsd:
> > 
> >   
> > 
> > Above ^^ is unrelated to REST entity schema, it describes RSDL
> > schema. It's inside api.xsd just to parse RSDL via JAXB. Entity
> > schema and RSDL schema are two separate things.
> > 
> > I suggest to split above into separate file, i.e. rsdl.xsd
> > and reference shared types (like "Version") from api.xsd.
> > This would be the proper separation these two schemas.
> > 
>

Re: [ovirt-devel] Important change in UI plugins REST API integration

2014-12-02 Thread Vojtech Szocs 


- Original Message -
> From: "Alon Bar-Lev" 
> To: "Sven Kieske" 
> Cc: devel@ovirt.org
> Sent: Tuesday, December 2, 2014 9:43:18 AM
> Subject: Re: [ovirt-devel] Important change in UI plugins RESTAPI 
> integration
> 
> 
> 
> - Original Message -
> > From: "Sven Kieske" 
> > To: devel@ovirt.org
> > Sent: Tuesday, December 2, 2014 10:41:00 AM
> > Subject: Re: [ovirt-devel] Important change in UI plugins REST API
> > integration
> > 
> > 
> > 
> > On 01/12/14 20:26, Vojtech Szocs wrote:
> > > In other words, usability of REST session ID is now strictly
> > > scoped to GUI user being authenticated. If the user logs in,
> > > (always) new REST session ID will be passed to all UI plugins.
> > > If the user logs out, REST session ID will not work anymore.
> > 
> > What if I use just REST for logging in and doing something
> > without any GUI interaction at all?

This announcement was about UI plugins in WebAdmin. If you use
Engine REST API without any GUI interaction involved, you aren't
affected in any way.

> > 
> > this reads a little like: you always need an open web gui
> > to be able to use REST, which does not make sense at all.

Sorry if my email confused you. It should read like: if you're
an author of oVirt UI plugin for WebAdmin, please beware that
REST API session ID (automatically acquired by UI plugin infra
on behalf of all UI plugins) will not work after GUI logout.

> 
> If you provide your own credentials nothing changed.
> 
> The change is only effecting RESTAPI usage within the user interface using
> the credentials obtained interactively from the user within login page.
> 
> > So I guess I'm misreading this?
> > 
> > --
> > Mit freundlichen Grüßen / Regards
> > 
> > Sven Kieske
> > 
> > Systemadministrator
> > Mittwald CM Service GmbH & Co. KG
> > Königsberger Straße 6
> > 32339 Espelkamp
> > T: +49-5772-293-100
> > F: +49-5772-293-333
> > https://www.mittwald.de
> > Geschäftsführer: Robert Meyer
> > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> > Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How To Auto Set oVirt RESTApi Session？

2014-12-02 Thread Vojtech Szocs 


- Original Message -
> From: "Alexander Wels" 
> To: "王成俊" 
> Cc: devel@ovirt.org
> Sent: Tuesday, December 2, 2014 1:59:21 PM
> Subject: Re: [ovirt-devel] How To Auto Set oVirt RESTApi Session？
> 
> On Tuesday, December 02, 2014 09:45:49 AM 王成俊 wrote:
> > Hi,awels:
> > 
> >  Thanks for your reply!
> > 
> >  I make this servlet to run the backend action which
> > names "LoginAdminUser", because I want to check admin log in with it,so
> > that my engine no need to log in through engine's loginpopupview.

Hm, so you're trying to automate WebAdmin GUI login? Can you please
explain your use case without any technical (servlet etc.) details?

> > 
> >  But when I log in through my servlet,the restapi can not get the
> > user's certificate.
> > 
> >  Can you tell me how to set and resume the restapi session in my case?
> > 
> >  Thanks!
> > 
> > Best Regards!
> > 
> 
> You can login to the REST api using standard http connection techniques. For
> instance basic auth you can login doing the following:
> 
> http://%40:@/ovirt-engine/api
> 
> Will list the available REST api.
> 
> But I am still not clear on what you are trying to do. Are you trying to
> write
> your own external servlet, that calls the REST api to do things for you? Or
> are you trying to write a servlet that lives inside the context of the engine
> and implements a new action?
> 
> Also please reply all, so we can keep the discussion on the mailing list so
> other people can find it in the future.
> 
> Alexander
> 
> 
> > 2014-12-02 5:42 GMT+08:00 Alexander Wels :
> > > On Monday, December 01, 2014 04:56:04 PM 王成俊 wrote:
> > > > Dear Sir：
> > > > 
> > > >  I am a new one in studing ovirt engine.Now,I have a Servlet in
> > > > 
> > > > org.ovirt.engine.ui.frontend.server.gwt package.
> > > > 
> > > >  I want to call
> > > > 
> > > > *Frontend.getInstance().getLoginHandler().**onLoginSuccess(userName,
> > > > password, domain)* to set session for restapi in this servlet.
> > > > 
> > > >  But when I visit this servlet,it occur to show me an error
> > > >  which
> > > > 
> > > > just like "*JBWEB71: root cause java.lang.ClassNotFoundException:
> > > > org.ovirt.engine.ui.uicompat.IFrontendActionAsyncCallback from [Module
> > > > "deployment.engine.ear.webadmin.war:main" from Service Module
> > > > Loader]*". I found that this error is occured by calling*
> > > > Frontend.getInstance()*.
> > > > 
> > > >  Can you tell me how to resolve this problem or a new way to
> > > >  set
> > > > 
> > > > and resume restapi session in a servlet package of
> > > > org.ovirt.engine.ui.front.server.gwt like the RestApiSessionManager in
> > > > org.ovirt.engine.ui.webadmin.plugin.restapi package?
> > > > 
> > > >thanks!
> > > > 
> > > > Best Regards!
> > > 
> > > Hi,
> > > 
> > > The problem you are experiencing is the fact the Frontend.getInstance()
> > > is
> > > a
> > > frontend (client, which get compiled to javascript) class, and the
> > > servlet
> > > is
> > > on the server side where this class is not defined (as it is frontend
> > > only).
> > > Maybe if you could explain what you are trying to do we could assist
> > > better.
> > > 
> > > We have a mechanism of getting the REST api session on the front end when
> > > you
> > > log in. On the backend you don't really need that, since you are on the
> > > backend. So your question sort of confuses me at this point.
> > > 
> > > Alexander
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed

2014-12-02 Thread Dan Kenigsberg 
On Tue, Dec 02, 2014 at 06:44:50AM +0100, Sandro Bonazzola wrote:
> Hi,
> We were supposed to start composing oVirt 3.5.1 RC today *2014-12-02 08:00 
> UTC* from 3.5 branch.
> We have still blockers for oVirt 3.5.1 RC release so we need to postpone it 
> untill they'll be fixed.
> The new tentative date for 3.5.1 RC composition is set to *2014-12-09 08:00 
> UTC
> 
> The bug tracker [1] shows 2 open blocker:
> Bug IDWhiteboard  Status  Summary
> 1168689   infra   ASSIGNEDUpgrading from 3.4.4 to 3.5.1 
> snapshot the vdsm rpm throw an exception

This one actuall has two patches merged. I moved it back to ASSIGNED by
mistake, as I did not notice the section added to
http://gerrit.ovirt.org/#/c/35763/2/vdsm.spec.in

Anyway, this bloke is behind us.

> 1160846   sla NEW Can't add disk to VM without 
> specifying disk profile when the storage domain has more than one disk profile
> 
> In order to stabilize the release a new branch ovirt-engine-3.5.1 will be 
> created from the same git hash used for composing the RC.
> 
> Maintainers:
> - Please be sure that 3.5 snapshot allow to create VMs before *2014-12-08 
> 15:00 UTC*
> - Please be sure that no pending patches are going to block the release 
> before *2014-12-08 15:00 UTC*
> - If any patch must block the RC release please raise the issue as soon as 
> possible.
> 
> There are still 69 bugs [2] targeted to 3.5.1.
> Excluding node and documentation bugs we still have 46 bugs [3] targeted to 
> 3.5.1.
> 
> Maintainers / Assignee:
> - Please add the bugs to the tracker if you think that 3.5.1 should not be 
> released without them fixed.
> - Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1:
>   it will ease gathering the blocking bugs for next releases.
> - Please fill release notes, the page has been created here [4]
> 
> Community:
> - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the 
> test page [5]
> 
> 
> [1] http://bugzilla.redhat.com/1155170
> [2] http://goo.gl/7G0PDV
> [3] http://goo.gl/6gUbVr
> [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes
> [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] oVirt Node Weekly Meeting Minutes - December 2nd 2014

2014-12-02 Thread Fabian Deutsch 
Minutes:http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.html
Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.txt
Log:
http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.log.html

=
#ovirt: oVirt Node Weekly Meeting
=


Meeting started by fabiand at 14:06:16 UTC. The full logs are available
at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-12-02-14.06.log.html
.



Meeting summary
---
* Agenda  (fabiand, 14:06:42)
  * oVirt 3.5  (fabiand, 14:07:53)

* oVirt 3.5  (fabiand, 14:08:23)

* Other Items  (fabiand, 14:09:56)

* oVirt 3.5  (fabiand, 14:11:26)
  * Latest Node scratch build is the one from two weeks ago  (fabiand,
14:13:51)
  * LINK:

https://fedorapeople.org/~fabiand/node/3.5/ovirt-node-iso-3.5.0.ovirt35.20141114.0.el6.iso
(fabiand, 14:14:37)
  * Some stabilizing patches got merged  (fabiand, 14:14:53)
  * Most work focused on the hosted-engine feature  (fabiand, 14:15:48)
  * many HE related patches got reviewed and merged during the last few
days  (fabiand, 14:18:36)
  * Basic HE features seems to work fine  (fabiand, 14:18:48)
  * Joining an existing HA HE is not yet supported  (fabiand, 14:19:03)
  * Targetting 3.5.1 to include ovirt-node. ovirt-node-plugins-vdsm and
ovirt-node-plugin-he rpms  (fabiand, 14:21:06)
  * ovirt-node-plugin-vdsm is looking good  (fabiand, 14:22:42)
  * vdsm-plugin also needs an update to address an el7 issue  (fabiand,
14:24:11)

* Other Items  (fabiand, 14:24:49)
  * Jenkins  (fabiand, 14:26:03)
  * tlitovsk working on jenkins automation  (fabiand, 14:29:27)
  * working on local builders, once working, pushing those changes to
upstream  (fabiand, 14:29:46)
  * Next-Gen Node  (fabiand, 14:31:06)
  * Start thinking about next-gen node and 3.6  (fabiand, 14:44:15)
  * generic registration is a potential feature for 3.6  (fabiand,
14:44:26)
  * Using puppet for configuration changes should get investigated
(fabiand, 14:44:37)
  * Seperating the insatller from the TUI (packaging) is something for
3.6  (fabiand, 14:44:49)
  * Possibly re-visit other cfg mgmt systems like ansible and chef
(fabiand, 14:51:22)
  * systemd has good sides.  (fabiand, 14:52:38)
  * tlitovsk has the idea of baking a configuration into an ISO
(fabiand, 14:58:48)
  * fabiand would liek to reuse existing tools for next-gen node
modifications  (fabiand, 14:59:20)
  * tlitovsk and fabiand to speak about where to do decision making
(fabiand, 15:00:29)
  * fabiand would like to separate rootfs from delivery format (ISO)
(fabiand, 15:03:01)

Meeting ended at 15:04:21 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* fabiand (172)
* tlitovsk (16)
* rbarry (15)
* dougsland (13)
* ovirtbot (4)
* sbonazzo (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Really slow VDSM on F21

2014-12-02 Thread Petr Horacek 
Hello,

has anyone else noticed VDSM's problems on Fedora 21?

The problem is that when I start vdsmd via systemd, it takes
about a minute to start the listener (returning Connection
to 0.0.0.0:54321 refused) and next few minutes it returns
'Recovering from crash or Initializing'. After that, `getVdsCaps`
takes cca 20 secs to finish.

I tried to change niceness in vdsmd.service but it's still the same.

When I start vdsm directly (/usr/share/vdsm/vdsm as vdsm user) it
starts within a second as it should.

Have you an idea why this happens?

Best regards,
Petr
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How To Auto Set oVirt RESTApi Session？

2014-12-02 Thread Alexander Wels 
On Tuesday, December 02, 2014 09:45:49 AM 王成俊 wrote:
> Hi,awels:
> 
>  Thanks for your reply!
> 
>  I make this servlet to run the backend action which
> names "LoginAdminUser", because I want to check admin log in with it,so
> that my engine no need to log in through engine's loginpopupview.
> 
>  But when I log in through my servlet,the restapi can not get the
> user's certificate.
> 
>  Can you tell me how to set and resume the restapi session in my case?
> 
>  Thanks!
> 
> Best Regards!
> 

You can login to the REST api using standard http connection techniques. For 
instance basic auth you can login doing the following:

http://%40:@/ovirt-engine/api

Will list the available REST api.

But I am still not clear on what you are trying to do. Are you trying to write 
your own external servlet, that calls the REST api to do things for you? Or 
are you trying to write a servlet that lives inside the context of the engine 
and implements a new action?

Also please reply all, so we can keep the discussion on the mailing list so 
other people can find it in the future.

Alexander


> 2014-12-02 5:42 GMT+08:00 Alexander Wels :
> > On Monday, December 01, 2014 04:56:04 PM 王成俊 wrote:
> > > Dear Sir：
> > > 
> > >  I am a new one in studing ovirt engine.Now,I have a Servlet in
> > > 
> > > org.ovirt.engine.ui.frontend.server.gwt package.
> > > 
> > >  I want to call
> > > 
> > > *Frontend.getInstance().getLoginHandler().**onLoginSuccess(userName,
> > > password, domain)* to set session for restapi in this servlet.
> > > 
> > >  But when I visit this servlet,it occur to show me an error
> > >  which
> > > 
> > > just like "*JBWEB71: root cause java.lang.ClassNotFoundException:
> > > org.ovirt.engine.ui.uicompat.IFrontendActionAsyncCallback from [Module
> > > "deployment.engine.ear.webadmin.war:main" from Service Module
> > > Loader]*". I found that this error is occured by calling*
> > > Frontend.getInstance()*.
> > > 
> > >  Can you tell me how to resolve this problem or a new way to set
> > > 
> > > and resume restapi session in a servlet package of
> > > org.ovirt.engine.ui.front.server.gwt like the RestApiSessionManager in
> > > org.ovirt.engine.ui.webadmin.plugin.restapi package?
> > > 
> > >thanks!
> > > 
> > > Best Regards!
> > 
> > Hi,
> > 
> > The problem you are experiencing is the fact the Frontend.getInstance() is
> > a
> > frontend (client, which get compiled to javascript) class, and the servlet
> > is
> > on the server side where this class is not defined (as it is frontend
> > only).
> > Maybe if you could explain what you are trying to do we could assist
> > better.
> > 
> > We have a mechanism of getting the REST api session on the front end when
> > you
> > log in. On the backend you don't really need that, since you are on the
> > backend. So your question sort of confuses me at this point.
> > 
> > Alexander

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Some ideas on oVirt Java SDK

2014-12-02 Thread Juan Hernández 
On 12/01/2014 06:36 PM, Vojtech Szocs wrote:
> 
> 
> - Original Message -
>> From: "Juan Hernández" 
>> To: "Vojtech Szocs" 
>> Cc: devel@ovirt.org
>> Sent: Monday, December 1, 2014 4:24:45 PM
>> Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK
>>
>> On 12/01/2014 04:13 PM, Vojtech Szocs wrote:
>>>
>>>
>>> - Original Message -
 From: "Juan Hernández" 
 To: "Michael Pasternak" , "Vojtech Szocs"
 , devel@ovirt.org
 Sent: Monday, December 1, 2014 9:54:51 AM
 Subject: Re: [ovirt-devel] Some ideas on oVirt Java SDK

 On 11/30/2014 12:26 PM, Michael Pasternak wrote:
> Hey Vojtech,
>
> How are you?, please see my reply inline.
>
>
>
> On Friday, November 28, 2014 5:26 PM, Vojtech Szocs
> mailto:vsz...@redhat.com>> wrote:
>
>
> Hi guys,
>
> since the initial (small, working & well-tested) version of oVirtJS
> JavaScript SDK is finished [*], I've started working on GWT wrapper
> for oVirtJS.
>
> While analyzing/reverse-engineering oVirt Java SDK, some thoughts
> came to my mind, and I wanted to share them with you.
>
> [*] TODO(vszocs) upload new patchset with all recent changes
>
> First, the way XJC (JAXB binding compiler that generates Java beans
> out of REST XSD schema) is invoked looks a bit weird to me, as Java
> SDK's XsdCodegen does this:
>
>   Runtime.getRuntime().exec(command)
>
> Why not simply use existing Maven plugins to invoke XJC?
> - either: https://github.com/highsource/maven-jaxb2-plugin
> 
>
>
> [MP] sdk was using jaxb to begin with, it was replaced with XJC just
> recently,
> btw Juan, what was the motivation behind this?

 This didn't change, the use of "xjc" is there since commit 95a25a4, Nov
 12 2012.

 Note that using Maven for this isn't as simple as it may look. The
 development model of the SDK is that the maven build does *not* generate
 any code, it just builds what has been manually generated previously.
>>>
>>> To clarify, my question was meant for "ovirt-engine-sdk-java-codegen"
>>> project and its org.ovirt.engine.sdk.codegen.Main class that produces
>>> Java classes out of XSD as part of XsdCodegen.generate() method.
>>>
>>> But if XsdCodegen invokes XJC programatically, what is the purpose of:
>>>
>>>   org.jvnet.jaxb2.maven2:maven-jaxb22-plugin:generate
>>>
>>> in "ovirt-engine-sdk-java-codegen" project's pom.xml?
>>>
>>> Is it related to what XsdCodegen is doing?
>>>
>>
>> The code generator invokes "xjc" directly in order to generate from the
>> XML schema the code that will eventually be part of the generated SDK.
>> In order to do its work it needs to parse the RSDL metadata, and for
>> that it uses JAXB and classes generated from the XML schema. Those
>> classes are generated as part of the build process of the code
>> generator. So the XML schema is converted into Java classes twice: once
>> for the internal use of the generator (during build time of the
>> generator), and another time for the generated SDK (during run time of
>> the generator). This is convenient in order to avoid dependencies
>> between the generator and the SDK.
> 
> Thanks for clarification.
> 
> IMHO calling XJC just to generate JAXB code that parses RSDL data
> is an overkill. In oVirtJS GWT wrapper project, I'm parsing RSDL
> as XML file directly.
> 

The "xjc" compiler isn't called directly to generate the code to parse
RSDL, it is called to generate the code of the SDK.

The code that the generator uses internally is generated using the Maven
plugin (which in turn calls "xjc").

We could argue about the convenience of using JAXB or manually parsing
the RSDL, but it won't take us anywhere. If you find it convenient
parsing it directly just do it.

> Conceptually, RSDL definition shouldn't even be inside api.xsd:
> 
>   
> 
> Above ^^ is unrelated to REST entity schema, it describes RSDL
> schema. It's inside api.xsd just to parse RSDL via JAXB. Entity
> schema and RSDL schema are two separate things.
> 
> I suggest to split above into separate file, i.e. rsdl.xsd
> and reference shared types (like "Version") from api.xsd.
> This would be the proper separation these two schemas.
> 

The RSDL is just one resource offered by the RESTAPI, like a VM or a
host. It supports multiple formats (XML, JSON, etc) and it is consumed
by clients. So its entities, like any other entity, must be described in
the XML schema. We only have one XML schema, and we can split it as it
would break backwards compatibility.

>>

> (REST api uses jaxb as well so we used to have 1x1 mappings)
>  
>
> - or: http://mojo.codehaus.org/jaxb2-maven-plugin/
> 
>
>
> [MP] same.
>
>
> Second, and most imp

Re: [ovirt-devel] Important change in UI plugins REST API integration

2014-12-02 Thread Alon Bar-Lev 


- Original Message -
> From: "Sven Kieske" 
> To: devel@ovirt.org
> Sent: Tuesday, December 2, 2014 10:41:00 AM
> Subject: Re: [ovirt-devel] Important change in UI plugins REST API
> integration
> 
> 
> 
> On 01/12/14 20:26, Vojtech Szocs wrote:
> > In other words, usability of REST session ID is now strictly
> > scoped to GUI user being authenticated. If the user logs in,
> > (always) new REST session ID will be passed to all UI plugins.
> > If the user logs out, REST session ID will not work anymore.
> 
> What if I use just REST for logging in and doing something
> without any GUI interaction at all?
> 
> this reads a little like: you always need an open web gui
> to be able to use REST, which does not make sense at all.

If you provide your own credentials nothing changed.

The change is only effecting RESTAPI usage within the user interface using the 
credentials obtained interactively from the user within login page.

> So I guess I'm misreading this?
> 
> --
> Mit freundlichen Grüßen / Regards
> 
> Sven Kieske
> 
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +49-5772-293-100
> F: +49-5772-293-333
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Important change in UI plugins REST API integration

2014-12-02 Thread Sven Kieske 


On 01/12/14 20:26, Vojtech Szocs wrote:
> In other words, usability of REST session ID is now strictly
> scoped to GUI user being authenticated. If the user logs in,
> (always) new REST session ID will be passed to all UI plugins.
> If the user logs out, REST session ID will not work anymore.

What if I use just REST for logging in and doing something
without any GUI interaction at all?

this reads a little like: you always need an open web gui
to be able to use REST, which does not make sense at all.

So I guess I'm misreading this?

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel