date:20130128

RE: Discuss: Rest interface for UserRequestService

2013-01-28 Thread Jan Bernhardt

Hi Francesco,

> -Original Message-
> From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
> Sent: Freitag, 25. Januar 2013 17:08
> To: dev@syncope.apache.org
> Subject: Re: Discuss: Rest interface for UserRequestService
> 
> On 25/01/2013 16:56, Christian Schneider wrote:
> > When doing the CXF version of the UserRequestService I found that our
> > current UserRequestController does not really follow the rest ideas.
> >
> > The problem is that it does follow the idea of doing CRUD operations
> > on resources. Some methods work with userId others with requestId. So
> > for example the are create, update and delete operations but they do
> > not mean the UserRequest but the underlying user.
> >
> > So I worked out a new interface that purely works on UserRequest and
> > only supports POST, READ and DELETE. So basically if you want to
> > create or delete or update a user you will POST a UserRequestTO in all
> cases.
> 
> Problem: you've already made all these changes *without* discussing this
> before, 

IMHO I think it is OK to commit new features without discussing method 
signature in advanced. Most time it is not possible to think of best design in 
advanced, but only while implementing a feature it becomes clear how to 
optimize method signatures. Of course if I change something that effects other 
code also, this should be discusses previously. Do you expect all committers to 
start a discussion before they introduce a new method?

Since Core REST interface is an important topic for whole project we already 
agreed to discuss each REST interface one by one. But since new REST API will 
not be used in next syncope release I was expecting that it is more important 
to get a first (nice) implementation done and then start discussion and 
refactoring afterwards. As mentioned earlier, it is not easy to make a 
"perfect" design at first and then start a discussion.

WDYT?

> once again not taking into any account the domain requirements 

I don't understand this, can you please elaborate? Domain specific requirements 
are completely mapped. There is no functionality lost by making a service 
RESTful. IMHO I think it is best to preserve all current functionality while 
optimizing request behavior to best practices of used technology. Which domain 
requirement cannot be covered by using proper RESTful design?

> nor  the compatibility with existing components, but only the technology 
> aspects.

I also don't understand this. Could you please explain some more? We previously 
agreed, that new REST API does not need to be identically  with current REST 
URLs, only functional compatibility was required. That's why I started [1] to 
document how REST API will change from Spring to CXF migration. So people using 
their own Console client will have to migrate in any case. And if this is the 
case, why not using underlying technology according to best practices? This way 
we will avoid refactoring API at a later state, when we run into issues, that 
could have been avoided by directly applying best practices of used technology. 
Since we are using JAX-B and JAX-RS annotation in new interfaces, writing a 
custom client will become much easier, since client code can be generated based 
on annotations.

Best regards.
Jan

[1] 
https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-RoleService

> We must fix this ASAP.
> 
> Regards.
> 
> > I added constructors to the UserRequestTO to make the use cases simpler.
> >
> > request to create a user:  userRequestService.create(new
> > UserRequestTO(userTO)); request to update a user:
> > userRequestService.create(new UserRequestTO(userMod)); request to
> > delete a user:  userRequestService.create(new
> > UserRequestTO(userTO.getId()));
> >
> > So what do you think about this?
> >
> > The only thing I really struggled with is the old isCreateAllowed
> > method. I implemented this using @Options and return the boolean in a
> > custom header. I am not sure if this is really the best way to do this
> > but it follows the rest principles quite closely. The alternative
> > would be to do a get on a magic path like in the current spring
> > service.
> >
> > Best regards
> >
> > Christian
> >
> > --
> > Current Interface:
> > @RequestMapping(method = RequestMethod.POST, value = "/create")
> public
> > UserRequestTO create(@RequestBody final UserTO userTO);
> >
> > @RequestMapping(method = RequestMethod.POST, value = "/update")
> public
> > UserRequestTO update(@RequestBody final UserMod userMod);
> >
> > @RequestMapping(method = RequestMethod.GET, value =
> > "/delete/{userId}") public UserRequestTO
> > delete(@PathVariable("userId") final Long userId)
> >
> > @RequestMapping(method = RequestMethod.GET, value = "/list") public
> > List list();
> >
> > @RequestMapping(method = RequestMethod.GET, value =
> > "/read/{requestId}") public UserRequestTO
> > read(@PathVariable("requestId") final Long requestId);
> >
> >

Re: Discuss: Rest interface for UserRequestService

2013-01-28 Thread Francesco Chicchiriccò

On 28/01/2013 09:45, Jan Bernhardt wrote:

Hi Francesco,

-Original Message-
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Freitag, 25. Januar 2013 17:08
To: dev@syncope.apache.org
Subject: Re: Discuss: Rest interface for UserRequestService

On 25/01/2013 16:56, Christian Schneider wrote:

When doing the CXF version of the UserRequestService I found that our
current UserRequestController does not really follow the rest ideas.

The problem is that it does follow the idea of doing CRUD operations
on resources. Some methods work with userId others with requestId. So
for example the are create, update and delete operations but they do
not mean the UserRequest but the underlying user.

So I worked out a new interface that purely works on UserRequest and
only supports POST, READ and DELETE. So basically if you want to
create or delete or update a user you will POST a UserRequestTO in all cases.

cases.

Problem: you've already made all these changes *without* discussing this
before,

IMHO I think it is OK to commit new features without discussing method 
signature in advanced. Most time it is not possible to think of best design in 
advanced, but only while implementing a feature it becomes clear how to 
optimize method signatures. Of course if I change something that effects other 
code also, this should be discusses previously. Do you expect all committers to 
start a discussion before they introduce a new method?

Of course not, but the whole point was that such change *did* affected 
other code: console's Login page, in this case.

Since Core REST interface is an important topic for whole project we already agreed to 
discuss each REST interface one by one. But since new REST API will not be used in next 
syncope release I was expecting that it is more important to get a first (nice) 
implementation done and then start discussion and refactoring afterwards. As mentioned 
earlier, it is not easy to make a "perfect" design at first and then start a 
discussion.

WDYT?

I agree with this: the problem - now fixed, thanks Christian - was that 
the aforementioned refactoring did not consider the side effects on the 
admin console, leaving it completely inaccessible.

Maybe you don't realize the impact of this, but it was huge.

I am completely fine with improving API refactory, but I also think that 
we must *all* take care of the side effects of such actions.

once again not taking into any account the domain requirements

I don't understand this, can you please elaborate? Domain specific requirements 
are completely mapped. There is no functionality lost by making a service 
RESTful. IMHO I think it is best to preserve all current functionality while 
optimizing request behavior to best practices of used technology. Which domain 
requirement cannot be covered by using proper RESTful design?

I am referring to the match between proper RESTful design (i.e. how to 
give access to a service) and the service itself.
We can make a wonderful awarded RESTful interface, but if this doesn't 
cover the identity management use cases Syncope is meant to, such 
interface is useless.

Consider the discussion we've had recently about delete: RESTful best 
practice says "must return void", we need "must return delete entity". 
We ended up with "for anything but users and roles we will adhere 
completely to best practice, for users and roles the functional 
requirement is more weighted than pure best practice".

This is an example of how I'd think we should match these two aspects.

nor  the compatibility with existing components, but only the technology 
aspects.

I also don't understand this. Could you please explain some more? We previously 
agreed, that new REST API does not need to be identically  with current REST 
URLs, only functional compatibility was required. That's why I started [1] to 
document how REST API will change from Spring to CXF migration. So people using 
their own Console client will have to migrate in any case. And if this is the 
case, why not using underlying technology according to best practices? This way 
we will avoid refactoring API at a later state, when we run into issues, that 
could have been avoided by directly applying best practices of used technology.
Since we are using JAX-B and JAX-RS annotation in new interfaces, writing a 
custom client will become much easier, since client code can be generated based 
on annotations.

We already agreed on the migration path and [1] contains really nice and 
useful information for this purpose.
Problems arise when, with purpose of building the new REST interface, 
something breaks the old REST interface - that will stay as official 
interface for upcoming 1.1.0 as well.

As said above, the broken Login page was the trigger for my e-mail, not 
the proposal for changes to the new UserRequestInterface, not the fact 
that such proposal already modified all methods of the existing 
UserRequestController.

Regards.

[1

[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration

2013-01-28 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564151#comment-13564151
 ] 

Francesco Chicchiriccò commented on SYNCOPE-289:


Hi Andrei,
executing a single IT case is back, thanks.

About the jaxrs profile (with XML content type) I was able to run

mvn -Pjaxrs -Djaxrs.content.type=application/xml

even though I got 

Tests run: 99, Failures: 27, Errors: 31, Skipped: 0

Anyway, I guess this is the expected result anyhow, right?

Any news about the errors with JDK 1.7?

Thanks.

> Prepare CXF Rest integration tests migration
> 
>
> Key: SYNCOPE-289
> URL: https://issues.apache.org/jira/browse/SYNCOPE-289
> Project: Syncope
>  Issue Type: Sub-task
>  Components: console, core
>Reporter: Andrei Shakirin
>Assignee: Andrei Shakirin
> Fix For: 1.1.0
>
>
> Moving back to 1.1.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (SYNCOPE-289) Prepare CXF Rest integration tests migration

2013-01-28 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564151#comment-13564151
 ] 

Francesco Chicchiriccò edited comment on SYNCOPE-289 at 1/28/13 9:33 AM:
-

Hi Andrei,
executing a single IT case is back, thanks.

About the jaxrs profile (with XML content type) I was able to run

mvn -Pjaxrs -Djaxrs.content.type=application/xml

even though I got 

Tests run: 99, Failures: 27, Errors: 31, Skipped: 0

Anyway, I guess this is the expected result anyhow, right?

Thanks.

  was (Author: ilgrosso):
Hi Andrei,
executing a single IT case is back, thanks.

About the jaxrs profile (with XML content type) I was able to run

mvn -Pjaxrs -Djaxrs.content.type=application/xml

even though I got 

Tests run: 99, Failures: 27, Errors: 31, Skipped: 0

Anyway, I guess this is the expected result anyhow, right?

Any news about the errors with JDK 1.7?

Thanks.
  
> Prepare CXF Rest integration tests migration
> 
>
> Key: SYNCOPE-289
> URL: https://issues.apache.org/jira/browse/SYNCOPE-289
> Project: Syncope
>  Issue Type: Sub-task
>  Components: console, core
>Reporter: Andrei Shakirin
>Assignee: Andrei Shakirin
> Fix For: 1.1.0
>
>
> Moving back to 1.1.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-231) Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with Apache CXF)

2013-01-28 Thread JIRA


[ 
https://issues.apache.org/jira/browse/SYNCOPE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564152#comment-13564152
 ] 

Francesco Chicchiriccò commented on SYNCOPE-231:


Andrei,
any news about the errors with JDK 1.7?


> Using Standard JAX-RS API in Syncope (Replace Spring Webservice Stack with 
> Apache CXF)
> --
>
> Key: SYNCOPE-231
> URL: https://issues.apache.org/jira/browse/SYNCOPE-231
> Project: Syncope
>  Issue Type: Improvement
>  Components: console, core
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
> Fix For: 1.2.0
>
> Attachments: TaskService.patch
>
>
> Current REST Interfaces are based on Spring Webservice framework. 
> Goal of this task is to replace Spring with CXF and to relay on JAX-B and 
> JAX-RS annotations rather then Spring annotations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-289) Prepare CXF Rest integration tests migration

2013-01-28 Thread Andrei Shakirin (JIRA)


[ 
https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564155#comment-13564155
 ] 

Andrei Shakirin commented on SYNCOPE-289:
-

Hi Francesco,

Yep, it is expected at the moment. Currently only ConfigurationITTestCaseJAXRS 
is green.
As I wrote in my commit comment, JAXRS tests are checked-in despite errors to 
be visible for all committers. 
We are working to fix them ASAP.
Currently you can use ConfigurationITTestCaseJAXRS to experiment with 
conetntType.

Regards,
Andrei.

> Prepare CXF Rest integration tests migration
> 
>
> Key: SYNCOPE-289
> URL: https://issues.apache.org/jira/browse/SYNCOPE-289
> Project: Syncope
>  Issue Type: Sub-task
>  Components: console, core
>Reporter: Andrei Shakirin
>Assignee: Andrei Shakirin
> Fix For: 1.1.0
>
>
> Moving back to 1.1.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[RESULT] [VOTE] Apache Syncope 1.0.5

2013-01-28 Thread Fabio Martelli

Hi all,
after 72 hours, the vote for Syncope 1.0.5 [1] *passes*
with 6 PMC + 3 non-PMC votes.

+1 (PMC / binding)
* Fabio Martelli
* Jean-Baptiste Onofré
* Francesco Chicchiriccò
* Massimiliano Perrone
* Marco Di Sabatino
* Colm O hEigeartaigh
* Jan Bernhardt
* Christian Schneider

+1 (non binding)
 * Denis Signoretto

Thanks to everyone participating.

I will now copy this release to Syncope' dist directory and promote the 
artifacts to the central Maven repository.

Best regards.

[1] 
http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-0-5-td5712232.html

[jira] [Created] (SYNCOPE-291) Move NotFoundException to core.persistence.dao

2013-01-28 Thread Christian Schneider (JIRA)

Christian Schneider created SYNCOPE-291:
---

 Summary: Move NotFoundException to core.persistence.dao
 Key: SYNCOPE-291
 URL: https://issues.apache.org/jira/browse/SYNCOPE-291
 Project: Syncope
  Issue Type: Improvement
  Components: core
Affects Versions: 1.1.0
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 1.1.0


The NotFoundException is currently located in util which is not such a
good place as it is part of the dao as well as service interfaces. 

Like discussed on the dev list we agree to move this exception to 
core.persistence.dao.
For the rest services the exception will be mapped to the rs.NotFoundException.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[RESULT] [VOTE] Apache Syncope 1.0.5

2013-01-28 Thread Fabio Martelli

Errata corrige ...

Hi all,
after 72 hours, the vote for Syncope 1.0.5 [1] *passes*
with 6 PMC + 3 non-PMC votes.

+1 (PMC / binding)
* Fabio Martelli
* Jean-Baptiste Onofré
* Francesco Chicchiriccò
* Massimiliano Perrone
* Marco Di Sabatino
* Colm O hEigeartaigh

+1 (non binding)
 * Denis Signoretto
* Jan Bernhardt
* Christian Schneider

Thanks to everyone participating.

I will now copy this release to Syncope' dist directory and promote the 
artifacts to the central Maven repository.

Best regards.

[1] 
http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-0-5-td5712232.html

Re: Discuss: Moving core.util.NotFoundException

2013-01-28 Thread Christian Schneider

Ok. So I will move the NotFoundException to core.persistence.dao  and
make it a RuntimeException.

I created issue https://issues.apache.org/jira/browse/SYNCOPE-291 to
track this.

Christian

On 24.01.2013 12:33, Francesco Chicchiriccò wrote:
> On 24/01/2013 12:25, Christian Schneider wrote:
>> The NotFoundException is currently located in util which is not such a
>> good place as it is part of the dao as well as service interfaces.
>>
>> So I propose to move this exception either to
>> 1. common.services
>>  In this case the NotFoundException could also be used in the
>> service
>> interfaces. So we would not have to handle the http specific not found
>> exception
>> 2. core.persistence.dao
>>  In this case the NotFoundException would be private to the core and
>> we would have to use e.g. the jax rs NotFoundException in the service
>> interfaces
>
> I would opt for (2), guessing that "jax rs NotFoundException" has some
> sort of more natural mapping to HTTP 404.
>
>> I also propose to change the exception to be unchecked to not force each
>> caller to catch it.
>
> +1
>
> Regards.
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Apache Syncope 1.0.5

2013-01-28 Thread Fabio Martelli

Sorry again, I have drunk too much beer this week end 

Hi all,
after 72 hours, the vote for Syncope 1.0.5 [1] *passes*
with 7 PMC + 2 non-PMC votes.

+1 (PMC / binding)
* Fabio Martelli
* Jean-Baptiste Onofré
* Francesco Chicchiriccò
* Massimiliano Perrone
* Marco Di Sabatino
* Colm O hEigeartaigh
* Jan Bernhardt

+1 (non binding)
* Denis Signoretto
* Christian Schneider

Thanks to everyone participating.

I will now copy this release to Syncope' dist directory and promote the 
artifacts to the central Maven repository.

Best regards.

[1] 
http://syncope-dev.1063484.n5.nabble.com/VOTE-Apache-Syncope-1-0-5-td5712232.html

Re: NPE in Console

2013-01-28 Thread Francesco Chicchiriccò

On 27/01/2013 18:00, Colm O hEigeartaigh wrote:

Hi Francesco,

I think this may be a genuine bug...I can reproduce the problem by
generating a new archetype for 1.1.0-SNAPSHOT, and copying the
"context.xml" from "core/src/main/resources" to "core/src/test/resources"
and then editing it to remove the "SyncPolicy" definition:

Starting the console in embedded mode gives the NPE in the "Configuration"
tab as I mentioned earlier. I should be able to start Syncope without
defining a SyncPolicy right?

Hi Colm,
I was just able to reproduce the bug you've reported above (only a minor
typo, content.xml not context.xml).

I will check this on the 1_0_X and then open an issue.
Thanks for reporting.

Regards.

On Sun, Jan 27, 2013 at 2:10 PM, Francesco Chicchiriccò
Colm O hEigeartaigh ha scritto:

Hi guys,

I am getting a NPE in the console when I click on the "Configuration"
tab
using the latest trunk code:

Root cause:

java.lang.IllegalArgumentException: Argument 'modelObject' may not be
null.
at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
at org.apache.wicket.model.ChainingModel.(ChainingModel.java:44)
at
org.apache.wicket.model.CompoundPropertyModel.(CompoundPropertyModel.java:61)
at
org.apache.syncope.console.pages.panels.PoliciesPanel$PolicyDataProvider.model(PoliciesPanel.java:301)
at
org.apache.syncope.console.pages.panels.PoliciesPanel$PolicyDataProvider.model(PoliciesPanel.java:269)

82 matches

Mail list logo